Many thanks for the feedback Peter. Please if you would, see below On 2/8/2015 10:32 PM, Peter Todd wrote: > Seeing a transaction is not a guarantee that any other node has seen it; not > seeing a transaction is not a guarantee other nodes have not seen a spend.
In no way does proposal rely on such assumptions. It develops local rules which result in a desirable outcome for the network as a whole, under the applicable statistics. > you're measuring a network that isn't under attack; Bitcoin must be robust > against attacks, and it must not create incentives to launch them. Two specific attacks are addressed at some length. No one is keener than I to learn of new ones, or flaws in those treatments. > Institutionalising the punishment of miners being they did not have perfect > connectivity - an unattainable goal in a trust less, decentralised system - > is athema to the goals of having a decentralised systmem and will only lead > to smaller mining operations being punished for being the victim of attacks > on their network connectivity that are only made profitable by this proposal. Building from unavoidable imperfections is the necessary spirit when interfacing with physical reality. I would defer to miners whether these specific worries outweigh the benefits of helping to achieve a 30 second network, rather than a 10±10 minute network. > Equally your proposal actually makes it *easier* to pull off apparently > single-confirm double-spend attacks - any miner who ignores a block > containing the apparent double-spend is just as likely to be aiding an > attacker trying to get a 1-conf transaction double-spent. This forces > *everyone* to waiting *longer* before accepting a transaction because now > even a single-confirmation is no longer good evidence of an accepted > transaction. In an ecosystem where hardly anyone relies on zeroconf anyway > your putting a much larger group of people at risk who weren't at risk before. I agree on one point -- it is necessary to let transactions mature for something on the order of 15 to 30 seconds before mining them, as discussed in proposal. I quite disagree regarding Finney (1-conf) attacks. In fact this proposal is the only one I've seen that actually stops most Finney attacks -- all those where the block comes more than 30 seconds after tx1. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
