Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Danny Thorpe
Please forgive my ignorance, but why should Bitcoin users have a say in block size limits? It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no? Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be.

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Danny Thorpe
What prevents RBF from being used for fraudulent payment reversals? Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast a double spend of that transaction to pay Alice nothing? Your only cost is the higher network fee of the 2nd tx. Thanks, -Danny On Mon, May 25, 2015

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Danny Thorpe
Apologies if this has already been stated and I missed it, but: Can transactions in a buried block be overridden/replaced by RBF? Or is RBF strictly limited to transactions that have not yet been incorporated into a block? Thanks, -Danny On Mon, May 25, 2015 at 10:13 PM, Peter Todd

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Danny Thorpe
Thanks for the clarification. So, since RBF applies only to pending transactions in the mempool awaiting incorporation into a block, there is a window of opportunity in which the pending tx is incorporated into a block at the same time that the spender is constructing and publishing a replacement

Re: [Bitcoin-development] Bitcoin transaction

2015-05-12 Thread Danny Thorpe
See the Open Assets protocol specification for technical details on how a colored coin (of the Open Asset flavor) is represented in a bitcoin transaction. https://github.com/OpenAssets/open-assets-protocol http://www.CoinPrism.com also has a discussion forum where some colored coin devs hang

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-12 Thread Danny Thorpe
Having thousands of utxos floating around for a single address is clearly a bad thing - it creates a lot of memory load on bitcoin nodes. However, having only one utxo for an address is also a bad thing, for concurrent operations. Having several utxos available to spend is good for parallelism,