Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM/ <div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=665.msg14243#msg14243">Quote from: throughput on September 27, 2010, 01:48:18 PM</a></div><div class="quote"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=665.msg14096#msg14096">Quote from: nelisky on September 26, 2010, 10:14:31 AM</a></div><div class="quote">Satoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn <img alt="Smiley" border="0" src="/static/img/emoticons/smiley.gif"/><br/></div><br/>I'm sure, Satoshi should better plan documenting the protocol as a standard, so we will have interoperable implementations,<br/>free from his dictatorship and tyranny. That is solely my own opinion.<br/><br/>For the techical issue discussed: It is clear, that the "node" instance, that holds the blocks database, connects to the network,<br/>exchanges data with peers and with users, is architecturally independent from the "wallet" instance(s).<br/>Wallet(s) may be viewed as peer(s), that request the block data and publish transactions/blocks, like network peers do now.<br/><br/>So it is feasible to have "block chain" daemon, that will cache block database on disk and may also act as an intermediary<br/>between the local users and "the network", so it will have no secret keys at all, no sensitive information.<br/>And the local "wallets" will have no networking part, no network interoperability problems, except for connecting to the daemon. So there will be no "bind to port 8XXX" issue.<br/>They will be free from the P2P stuff, will only work in a client-server paradigm, will trust the server for executing their requests, but will not trust the server with any secret information.<br/>And so, they may be as simple, as system-on-a-chip cards, capable of iterating through the blocks/transactions list, but not required to store it. The block chain database may also return narrow results, parameterised by the list of public keys, like "getreceivedbyaddr" does now.<br/><br/>Generation should happen at admin's local wallet, not at the networking node. That means "wallets" will be permitted to publish not only transactions, but solved blocks too.<br/><br/>For current codebase this is a major refactoring, I'm sure Satoshi will veto on it, and he may have his own merits.<br/>So the only hope is the alternative implementations, that aren't possible without the standard.<br/><br/></div><br/>Well put, the standard is certainly needed to move this into mainstream, and source code as documentation sucks. But that is slightly longer, more important goal, not one I will hold off on projects for. I'm sure you agree the standard definition alone will take a good amount of time, especially when people look at it and start saying what if, or wouldn't it be better if... Then we still have to develop standards compliant clients.<br/><br/>I'm not saying that effort isn't worth it, much the opposite, it's mandatory for the immediate future. This hack jobs we do are actually a great way to get to know how things are being done, thus gathering any knowledge to help in describing the protocol <img alt="Smiley" border="0" src="/static/img/emoticons/smiley.gif"/></div> text/html