From: Satoshi Nakamoto <[email protected]>
Date: Wed, Mar 9, 2011 at 7:39 PM
To: Mike Hearn <[email protected]>
Subject: Re: Open sourced my Java SPV impl
>See these threads:
>http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119
>http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
>I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening.
The network won't forget, and the owner's client will keep rebroadcasting it. The overflow transaction was remembered by the network for several months even as the remaining 0.3.8 nodes diminished.
Priority includes age, so as a transaction waits it ages and will eventually have enough priority.
See one of the links above where I contemplate sending an honest double-spend to increase the fee. It's a lot of work but could be done. I don't think it's worth it right now.
The current system, where nodes make sure to include enough fee for current conditions and the network makes sure all transactions get processed eventually, works well enough. Gavin is fixing the oversight where nodes didn't check the priority of their own transactions when writing them.
Users still worried about processing speed uncertainty should think of it as encouragement to include a fee.
>There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?
I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it.
It was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started.
>There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:
>
>http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171
>
>But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in >your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all >miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage >costs and bandwidth for client-mode implementations?
No, other chains do not follow Bitcoin's rules. They are completely independent chains. They share nothing except the miners. The other network's definition of proof-of-work is to make a solved (according to their own chain's difficulty) Bitcoin-format block that has a hash of their own block in it. They don't care if the Bitcoin block is valid or used by Bitcoin, but it allows miners to work both chains at once.
Procedure to hash a BitDNS block:
- hash the BitDNS block
- construct a Bitcoin block
- insert the BitDNS hash into the scriptSig of tx 0 in the Bitcoin block
- hash the Bitcoin block
The BitDNS block is valid if that hash is below BitDNS's target.
The BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash:
- the Bitcoin block header
- the merkle branch to tx 0
- tx 0 (btw, tx 0's prev hash is always 0 so leaving that out saves 32 bytes)
Note that it doesn't matter if the fodder "Bitcoin block" was actually valid in the Bitcoin chain, though it could have been. To BitDNS, it's just a bunch of salt necessary to do its convoluted hash calculation. If a miner is only mining for BitDNS and doesn't care about Bitcoin, it would use a blank Bitcoin block of all zeroes (except the nonce).
To further expand the idea for extensibility, consider instead of putting the BitDNS block hash in tx 0, you put the root of a merkle tree that includes BitDNS. This is the merkle tree that is conceptually at the top.