Re: [Bitcoin-development] Running a full node
Dear all, +1 ! Thanks to those who sent me some details and links. My node is up and running on 5.56.40.1:8333 Techno : Linux HA + dual homed Internet transit. It should be stable as from now. Best regards -- Francis Le 06/11/2014 11:53, Francis GASCHET a écrit : Dear all, I'm currently discovering the Bitcoin's universe. I installedbitcoind on my PC and I'm currently testing different things on testnet. I just read an article saying that the risk for Bitcoin in the future is the decreasing number of full nodes, with appropriate resources. There are only few of them in France ! My company operates a dual homed Internet access and has some capacity to host an HA server in a secured environment. So I'm thinking about setting up a full node. But I'd like to know what storage, RAM and bandwidth resources are needed. I guess that the problem is not the CPU. Thanks in advance for details. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP draft - Auxiliary Header Format
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 tier.no...@gmail.com 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
Re: [Bitcoin-development] BIP draft - Auxiliary Header Format
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 tier.no...@gmail.com 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 tier.no...@gmail.com 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
