Re: [Bitcoin-development] Update to Double-Spend Deprecation Window Proposal

2015-02-09 Thread Tom Harding
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


Re: [Bitcoin-development] Update to Double-Spend Deprecation Window Proposal

2015-02-08 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is an incredibly dangerous and foolish proposal that opens up the Bitcoin 
network to serious vulnerabilities, both from attackers outside the network, as 
well as miners trying to gain an advantage over their competition.

Ultimately it's flawed for the same root problem that proof-of-stake proposals 
suffer from: the p2p network just isn't a reliable broadcast medium. 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.

You can measure propagation times and other metrics all you want, but 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. 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.

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.

Frankly if this idea gets traction it should serve as a warning to all miners 
that it's time they adopt replace-by-fee to set a clear precedent that they 
have no obligations other than the same economic self-interest- not vague 
notions of honesty - that makes Bitcoin work in the first place.

BTW you quote Hal Finney and Satoshi in your proposal to try to lend support to 
it. Don't do that - appealing to authority is a surefire way to get people to 
ignore you. Its particularly bad when the authorities being appealed too 
haven't participated in consensus research for years; you're referencing stuff 
from a time when Bitcoin was barely understood.


On 8 February 2015 21:38:55 GMT-06:00, Tom Harding t...@thinlink.com wrote:

This update strengthens the incentive not to confirm double-spends
after
time T (30 seconds).  To grow and stabilize adoption, it is necessary
to
influence the miner of the block after a deprecated block, who in turn
is concerned with the block after that. Accordingly, the disincentive
is
changed from a simple delay to a temporary chain work penalty, which
can
be negative.  Hal Finney first suggested this in 2011.

The penalty is graduated in two steps based on the respend gap, for
reasons explained within.  I believe it is the minimum required to
achieve the intended result.

Double-Spend Deprecation Window
https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md


--
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
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQFQBAEBCAA6BQJU2FR4MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTd/B/9CG8fiJIZWnyxTsvnK
InGRfFMef8yvbALEt4/Io75Iv6Y6xYw0TbkLdk8r38/iFD5RlE6edYQe90QKA903
D6nxKQU0b1vW53cTptetzpvR6utkFogw3nqPRAy5SrDAdjJrg2Z78QrUQv+pSeYs
U9Mlw/22Z34vRI4VHpY9jeEtyj2lKNZvlBj/BtOeSHYsXB3R4tVmtp4DRiXc5FVr
i9NcOSBqKSzvG5bgx1S6QmMakSD/9LaoBrBWFiU2FZV/jX9x+dR31OdrVWr06OJU
zlR2Xyn3P+KwG8IeJR0K3sk72/vvEN+pntG+SMhtfrwjCgDKYGvULbcELR41EcmA
/X0i
=hGv0
-END PGP SIGNATURE-


--
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


[Bitcoin-development] Update to Double-Spend Deprecation Window Proposal

2015-02-08 Thread Tom Harding

This update strengthens the incentive not to confirm double-spends after 
time T (30 seconds).  To grow and stabilize adoption, it is necessary to 
influence the miner of the block after a deprecated block, who in turn 
is concerned with the block after that. Accordingly, the disincentive is 
changed from a simple delay to a temporary chain work penalty, which can 
be negative.  Hal Finney first suggested this in 2011.

The penalty is graduated in two steps based on the respend gap, for 
reasons explained within.  I believe it is the minimum required to 
achieve the intended result.

Double-Spend Deprecation Window
https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md


--
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