I was going to look into creating reference code for this. The first BIP could be reasonably easy, since it just needs to check for the presence of the 2 special transactions. That would mean that it doesn't actually create version 3 blocks at all. Ideally, I would make it easy for miners to mine version 3 blocks. I could add a new field to the getblocktemplate that has the 2 transactions ready to go. What do pools actually use for generating blocks. I assume it's custom code but that they use (near) standard software for the memory pool? On Mon, Nov 10, 2014 at 11:39 PM, Tier Nolan wrote: > I have added the network BIP too. It only has the aheaders message and > the extra field for getheaders. > > > https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header-network.mediawiki > > The transaction definitions are still at: > > https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki > > On Mon, Nov 10, 2014 at 9:21 PM, Tier Nolan wrote: > >> I updated the BIP to cover only the specification of the transactions >> that need to be added. I will create a network BIP tomorrow. >> >> On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan >> wrote: >> >>> The aheaders message is required to make use of the data by SPV >>> clients. This could be in a separate BIP though. I wanted to show that >>> the merkle path to the aux-header transaction could be efficiently encoded, >>> but a reference to the other BIP would be sufficient. >>> >>> For the other messages, the problem is that the hash of the aux header >>> is part of the block, but the aux header itself is not. That means that >>> the aux header has to be sent for validation of the block. >>> >>> I will change it so that the entire aux-header is encoded in the block. >>> I think encoding the hash in the final transaction and the full aux-header >>> in the 2nd last one is the best way to do it. This has the added advantage >>> of reducing the changes to block data storage, since the aux-header doesn't >>> have to be stored separately. >>> >>> >>> On Mon, Nov 10, 2014 at 12:52 AM, Gregory Maxwell >>> wrote: >>> >>>> Some initial comments... >>>> >>>> Tying in the protocol changes is really confusing and the fact that >>>> they seem to be required out the gates would seemingly make this much >>>> harder to deploy. Is there a need to do that? Why can't the p2p part >>>> be entirely separate from the comitted data? >>>> >>>> On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan >>>> wrote: >>>> > I made some changes to the draft. The merkleblock now has the >>>> auxiliary >>>> > header information too. >>>> > >>>> > There is a tradeoff between overhead and delayed transactions. Is >>>> 12.5% >>>> > transactions being delayed to the next block unacceptable? Would >>>> adding >>>> > padding transactions be an improvement? >>>> > >>>> > Creating the "seed" transactions is an implementation headache. >>>> > >>>> > Each node needs to have control over an UTXO to create the final >>>> transaction >>>> > in the block that has the digest of the auxiliary header. This means >>>> that >>>> > it is not possible to simply start a node and have it mine. It has to >>>> > somehow be given the private key. If two nodes were given the same >>>> key by >>>> > accident, then one could end up blocking the other. >>>> > >>>> > On one end of the scale is adding a transaction with a few thousand >>>> outputs >>>> > into the block chain. The signatures for locktime restricted >>>> transactions >>>> > that spend those outputs could be hard-coded into the software. This >>>> is the >>>> > easiest to implement, but would mean a large table of signatures. The >>>> > person who generates the signature list would have to be trusted not >>>> to >>>> > spend the outputs early. >>>> > >>>> > The other end of the scale means that mining nodes need to include a >>>> wallets >>>> > to manage their UTXO entry. Miners can split a zero value output >>>> into lots >>>> > of outputs, if they wish. >>>> > >>>> > A middle ground would be for nodes to be able to detect the special >>>> > transactions and use them. A server could send out timelocked >>>> transactions >>>> > that pay to a particular address but the transaction would be >>>> timelocked. >>>> > The private key for the output would be known. However, miners who >>>> mine >>>> > version 2 blocks wouldn't be able to spend them early. >>>> > >>>> > >>>> > On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan >>>> wrote: >>>> >> >>>> >> I created a draft BIP detailing a way to add auxiliary headers to >>>> Bitcoin >>>> >> in a bandwidth efficient way. The overhead per auxiliary header is >>>> only >>>> >> around 104 bytes per header. This is much smaller than would be >>>> required by >>>> >> embedding the hash of the header in the coinbase of the block. >>>> >> >>>> >> It is a soft fork and it uses the last transaction in the block to >>>> store >>>> >> the hash of the auxiliary header. >>>> >> >>>> >> It makes use of the fact that the last transaction in the block has >>>> a much >>>> >> less complex Merkle branch than the other transactions. >>>> >> >>>> >> >>>> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki >>>> >> >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ >>>> > >>>> > _______________________________________________ >>>> > Bitcoin-development mailing list >>>> > Bitcoin-development@lists.sourceforge.net >>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>>> > >>>> >>> >>> >> >