[Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Adam Back]

I agree with Mike & Jeff.  Blowing up 0-confirm transactions is vandalism.

bitcoin transactions are all probabilistic.  there is a small chance
1-confirm transactions can be reversed, and a different but also
usable chance that 0-confirm transactions can be reversed.  I know
0-confirm is implemented in policy and not consensus, but it provides
fast transactions and a lot of the current ecosystem is using it for
low value transactions.  why would anyone want to vandalise that.

to echo Mike bitcoin itself kind of depends on some honest majority,
we can otherwise get to situations soon enough where its more
profitable to double-spend than mine honestly as subsidy drops and
transaction values increase even without 0-confirm transactions.
subsidy doesnt last forever (though it lasts a really long time) and
even right now if you involve values that dwarf subsidy you could make
a "criminally rational" behaviour that was more profitable.  we even
saw 0-confirm odds-attacks against satoshi dice clones.  but if we
assume the "criminal rational" model, its a is a race to the bottom
logic, and bitcoin is already broken if we have someone who wants to
go for it with high values.  that'd be scorched earth also.

(I read the rest of the arguments, i understood them, I disagree, no
need to repeat in reply.)

So how about instead, to be constructive, whether you agree with the
anti-arson view or not, lets talk about solutions.  Here's one idea:

We introduce a new signature type that marks itself as can be spent by
miners if a double-spend is seen (before 1-confirm.)  We'd define a
double-spend as a spend that excludes outputs to avoid affecting valid
double-spend scenarios.  And we add behaviour to relay those
double-spends (at priority).  We may even want the double-spend to be
serialisation incomplete but verifiable to deter back-channel payments
to pretend not to receive one, in collusion with the double-spending
party.

Now the risk to the sender is if they accidentally double-spend.  How
could they do that?  By having a hardware or software crash where they
sent a tx but crashed before writing a record of having sent it.  The
correct thing to do would be to transactionally write the transaction
before sending it.  Still you can get a fail if the hardware
irrecoverably fails, and you have to resume from backup.  Or if you
run multiple non-synced wallets on the same coins.

Typically if you recover from backup the 1-confirmation window will
have passed so the risk is limited.

The feature is opt-in so you dont have to put high value coins at risk
of failure.

(Its related to the idea of a one-use signature, where two signatures
reveals a simultaneous equation that can recover the private key;
except here the miner is allowed to take the coins without needing the
private key).

Its soft-forkable because its a new transaction type.

ps I agree with Greg also that longer-term more scalable solutions are
interesting, but I'd like to see the core network work as a stepping
stone.  As Justus observed: the scalable solutions so far have had
non-ideal ethos tradeoffs so are not drop-in upgrades to on-chain
0-confirm.

Adam

On 22 February 2015 at 04:06, Jeff Garzik <jgarzik@bitpay.com> wrote:
> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>>> This isn't some theoretical exercise.  Like it or not many use
>>> insecure 0-conf transactions for rapid payments.  Deploying something
>>> that makes 0-conf transactions unusable would have a wide, negative
>>> impact on present day bitcoin payments, thus "scorched earth"
>
>> And maybe by maintaining first seen policies we're harming the system
>> in the long term by encouraging people to widely deploy systems based
>> on extremely weak assumptions.
>
> Lacking a coded, reviewed alternative, that's only a platitude.
> Widely used 0-conf payments are where we're at today.  Simply ceasing
> the "maintaining [of] first seen policies" alone is simply not a
> realistic option.  The negative impact to today's userbase would be
> huge.
>
> Instant payments need a security upgrade, yes.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2796 bytes --]

On Sun, Feb 22, 2015 at 08:02:03AM +0000, Adam Back wrote:

FWIW I've been advocating this kind of thing in various forms for
literally years, including to hold fidelity bonded banks honest - what
you now call 'federated sidechains' - and most recently Feb 12th on
#bitcoin-dev:

19:56 < petertodd> leakypat: now, do note that an advanced version [of replace-by-fee scorched earth] could be to make another tx that alice and bob setup in advance such that if alcie doublespends, bob gets the money *and* alice pays a bunch of cash to miners fees
19:57 < petertodd> leakypat: this would work espectially well if we improved the scripting system so a script could evaluate true based on proof-of-doublespend
19:58 < leakypat> Yeah, proof of double spend would ideally be done at the protocol level
19:59 < petertodd> leakypat: if satoshi hadn't make the multiple things that CHECKSIG does into one opcode it'd be really easy, but alas...

Implementing it as a general purpose scripting language improvement has
a lot of advantages, not least of which is that you no longer need to
rely entirely on inherently unreliable P2P networking: Promise to never
create two signatures for a specific BIP32 root pubkey and make
violating that promise destroy and/or reallocate a fidelity bond whose
value is locked until some time into the future. Since the fidelity bond
is a separate pool of funds, detection of the double-spend can happen
later.

Equally, that *is* what replace-by-fee scorched-earth does without the
need for a soft-fork, minus the cryptographic proof and with a bit less
flexibility.

> I agree with Mike & Jeff.  Blowing up 0-confirm transactions is vandalism.

Is releasing a version of Bitcoin Core with different IsStandard() rules
than the previous version vandalism? Is mining with a different policy
than other people vandalism? Is mining at a pool that gets sybil
attacked vandalism? Are my replace-by-fee tools an act of vandalism?
Because every one of those things causes people to get double-spent in
the real world, even losing tens of thousands of dollars until they get
some sense and stop treating unconfirmed transactions as confirmed.

Is it vandalism if you decide to host a wedding right next to a hairpin
corner at a rally race and complain to me that mud is getting on the
pretty white dresses? Is it vandalism if I tell that wedding party to
fuck off before someone gets hurt? Is it vandalism if some racers take
the mudguards off for a few laps to see if we can encourage them to
leave before someone gets *actually* hurt? Or someone decides that the
solution is to pave the track over and hold a bicycle race instead...

-- 
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

Den 22 feb 2015 13:36 skrev "Peter Todd" <pete@petertodd.org>:
> Implementing it as a general purpose scripting language improvement has
> a lot of advantages, not least of which is that you no longer need to
> rely entirely on inherently unreliable P2P networking: Promise to never
> create two signatures for a specific BIP32 root pubkey and make
> violating that promise destroy and/or reallocate a fidelity bond whose
> value is locked until some time into the future. Since the fidelity bond
> is a separate pool of funds, detection of the double-spend can happen
> later.

Somebody sent me a zero-confirmation transaction, or one that got orphaned
after one block. I created a transaction spending that UTXO, and another.

So at that point I have UTXO_orphaned based on the sender's UTXO_origin and
my UTXO_old (because I've had it unspent for a long time), both in one
transaction, creating UTXO_new.

Now he doublespend UTXO_origin to create a UTXO_doublespend (which
conflicts with UTXO_orphaned). He conspires with a miner to get it into a
block.

Now what? Can my UTXO_old effectively be tainted forever because UTXO_new
got invalidated together with UTXO_orphaned? Will that transaction be a
valid proof of doublespend against a new UTXO_replacement I created?

Or otherwise, if only transactions where all UTXO's are currently valid
works as doublespend proofs, aren't you still just left without protection
against any one miner that conspires with doublespend attempting thieves?

In other words, you are unprotected and potentially at greater risk if you
create a transaction depending on another zero-confirmation transaction.

[-- Attachment #2: Type: text/html, Size: 1896 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Matt Whitlock]

On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote:
> In other words, you are unprotected and potentially at greater risk if you
> create a transaction depending on another zero-confirmation transaction.

This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money.

I keep telling people not to accept transactions with zero confirmations, but no one listens.

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock <bip@mattwhitlock.name> wrote:
>On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote:
>> In other words, you are unprotected and potentially at greater risk
>if you
>> create a transaction depending on another zero-confirmation
>transaction.
>
>This happened to one of the merchants at the Bitcoin 2013 conference in
>San Jose. They sold some T-shirts and accepted zero-confirmation
>transactions. The transactions depended on other unconfirmed
>transactions, which never confirmed, so this merchant never got their
>money.

Great example! Systems that appear more secure than they really are to uninformed users are dangerous. Same reason why brain wallets are such scary technology, and equally, why I like to give a few dollars away every so often to the guys brute forcing weak ones.

>I keep telling people not to accept transactions with zero
>confirmations, but no one listens.

In my experience there's a pattern of "accept unconfirmed; get burned badly/see someone else get burned; stop relying on them" Although of course, there's some bias in that people contact me asking what to do after they get burned. :)
-----BEGIN PGP SIGNATURE-----

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6eKG
AAoJEMCF8hzn9LncGz0H/ivA9J4MqsVnkPm9JVAIXgZiT7rAVO0Rp1lO/8PGPS6K
dXBFXESicszeBx5yeyQrLUFh58DVgp21sFHSMNTKmujDJJgxNf/ygffN9dTLriwt
PJcDWvxPzqyLy2e/CloRonxwlO3+Umv1OiPs1yy7a7auDVAEm1xvh/pc3A48u1bO
++cyxZs8j5yv3Ms2n/FmGekhL9jZHJAgmiVnSks0cMqq9+cYipEjy+FEq3KFGlFI
4iZ58f57g6W7bVqM+9Z6dbLczWobnQ+nfo7lFZWgGdbhKf4Jv7tHOcfSw4nbmJz4
OgWmKtM724h7abOIrqJnTF0u10dmapVv+lRtjiGXo8c=
=7W03
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> This happened to one of the merchants at the Bitcoin 2013
> conference in San Jose. They sold some T-shirts and accepted
> zero-confirmation transactions. The transactions depended on other
> unconfirmed transactions, which never confirmed, so this merchant
> never got their money.
> 
> I keep telling people not to accept transactions with zero
> confirmations, but no one listens.

A better solution is to track the failure rate of zero confirmation
transactions, and adjust prices accordingly to cover the expected loss.

This is what every merchant *already does* since no payment method has
a 0% fraud rate.

Even physical cash has a probability of being counterfeit, and the
prices you pay for things at a convenience store already have that
risk priced in.

The idea that zero confirmation transactions require a 100% guarantee
is a strawman, especially since there exists no number of
confirmations the actually produce a 100% irreversibility guarantee.

Zero confirmation transactions can work as long as the risk of
reversal is measurable and reasonably stable.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJU6f0FAAoJECpf2nDq2eYjWJsP/3I6b9KL2tr7wEGUyiUJvn95
wR/DQw3jRoC6rP1OqZAHpePksboEtd1yTxhtnH9UEMzvzFrGeQwKaSgM0s6zbIIm
38BXH6uiTzxI2PUWxv8HDNsPvwAlj0l4EkV9E8DthK9MTDVAk5E/SFUlwgc4tdYB
QinntAYknjIJd7dKVXlIaBrXg0UmTaXDKq9yoQIBTl9SE8xYbbRM154XAjVmqVrZ
h88ZGkaIbpHbBEjbUpqVpPIKM/Ts4b6NwLSfloY7W+Mmvgn3p6EB4V6rt3HuV/wN
L5A0RPbAESGsg0MpRcIprpAq4aiO6Qt0p6wMrZ9x6a+cx1w/RuJx7Sb3zflDjBgk
FmEwqIKJJqWoTEtR2nCEkmDvwx48RJQQppEHJgdUCmxjELpJMKkvtz9Oc4CRP0ty
6JUnBmxNTHRJLL+0nn1sq5WAhTLIQaH3RcVn/SjNk2zjoUXUdx+1pIEyBaZnOckW
e54SraX0KEEZNpTXHA3xJV0d2gA068CChG/TFqMO9uhohWz9jz6NZl7jFLwdBjgb
Wmbid/V/bl6W/ehCiOwLDM/sOer/BDoZPqGt/j2cJZO9gP+wVdiRkojl3f97vd9k
qhGV3QUsc8uiseZNxeIv2hty34KzUPz2ISPM25ZnQMavIevg3Yg0l4O7Hwnk49oK
1nhyoqk+scfLpo7vd6Ke
=fVAx
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 17801 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

Den 22 feb 2015 17:00 skrev "Justus Ranvier" <justusranvier@riseup.net>:
>
> On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> > This happened to one of the merchants at the Bitcoin 2013
> > conference in San Jose. They sold some T-shirts and accepted
> > zero-confirmation transactions. The transactions depended on other
> > unconfirmed transactions, which never confirmed, so this merchant
> > never got their money.
> >
> > I keep telling people not to accept transactions with zero
> > confirmations, but no one listens.
>
> A better solution is to track the failure rate of zero confirmation
> transactions, and adjust prices accordingly to cover the expected loss.
>
> This is what every merchant *already does* since no payment method has
> a 0% fraud rate.
>
> Even physical cash has a probability of being counterfeit, and the
> prices you pay for things at a convenience store already have that
> risk priced in.
>
> The idea that zero confirmation transactions require a 100% guarantee
> is a strawman, especially since there exists no number of
> confirmations the actually produce a 100% irreversibility guarantee.

The problem with this approach is that it is worthless as a predictor. We
aren't dealing with traffic safety and road design - we are dealing with
adaptive attackers and malicious miners and pools.

Anything which does not invalidate blocks carrying doublespends WILL allow
malicious miners and pools to conspire with thieves to steal money. The
probability of being hit will then be (their proliferation in your business
area) * (their fraction of the mining power).

That might seem to give small numbers for most sets of reasonable
assumptions. But the problem is that's only an average, and the people
being hit might have small profit margins - one successful attack can place
hundreds of merchants in red numbers and force them to shut down.

You should never expose yourself to attacks which you can't defend against
and which can be fatal. In particular not if there's nothing in the
environment that is capable of limiting the size or numbers of any attacks.
And there's no such thing today in Bitcoin.

This is why I sketched out the multisignature notary approach, and why some
decided to extend that approach with collateral (NoRiskWallet) to further
reduce trust in the notary. This is the single most practical approach I
know of today to achieve ACTUAL SECURITY for unconfirmed transactions.

Don't like it? See if you can do better!

Just don't rely on zero-confirmation transactions!

[-- Attachment #2: Type: text/html, Size: 2983 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/22/2015 10:17 AM, Natanael wrote:
> The problem with this approach is that it is worthless as a
> predictor. We aren't dealing with traffic safety and road design -
> we are dealing with adaptive attackers and malicious miners and
> pools.
> 
> Anything which does not invalidate blocks carrying doublespends
> WILL allow malicious miners and pools to conspire with thieves to
> steal money. The probability of being hit will then be (their
> proliferation in your business area) * (their fraction of the
> mining power).
> 
> That might seem to give small numbers for most sets of reasonable 
> assumptions. But the problem is that's only an average, and the
> people being hit might have small profit margins - one successful
> attack can place hundreds of merchants in red numbers and force
> them to shut down.
> 
> You should never expose yourself to attacks which you can't defend
> against and which can be fatal. In particular not if there's
> nothing in the environment that is capable of limiting the size or
> numbers of any attacks. And there's no such thing today in
> Bitcoin.
> 
> This is why I sketched out the multisignature notary approach, and
> why some decided to extend that approach with collateral
> (NoRiskWallet) to further reduce trust in the notary. This is the
> single most practical approach I know of today to achieve ACTUAL
> SECURITY for unconfirmed transactions.
> 
> Don't like it? See if you can do better!
> 
> Just don't rely on zero-confirmation transactions!

You just disproved your own argument.

It is possible to predict risk, and therefore to price the risk.

You also noted that for some Bitcoin users, the price of that risk is
too high for the types of transactions in which wish to engage.

In what way does that translated into a universal requirement for
everybody to use multisignature notaries?

Surely the users who can afford the risk can use zero conf if they
like, and those who can't can use multisig notaries?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJU6gLmAAoJECpf2nDq2eYj8/AQAJfMtBqjo1Z2Z0A7OhE9iaYD
PqWXdRaCFwyV49RSDrRROrB9Vc7CENQsweHBSnNEmSj6la/YfjyobmaR5BMtTq73
ZaXOFYSGVa9S0j+1qTvz2MorBd6ocxckdunfN7N/uVb4NQRYTHUT8N7AyJgRFYO9
ElQU/8TcNCSRqSQc3z8rnUc8eN1+DgqkMDHM754huOgA0fz0OlxnLCddcCvLr0t7
ZPCtZI94FWQSWhzTK2oa41hh01xG+Eg5GhqGzM7WBqM6+d/CgNcUVeMnVOkkhgav
AmlE81Km9R4AlrsGT/CcGgaC+FvBhqmDYHAGOUG3hLP+MXMe4qA5TRoRKHFvq4Gw
nF6q+leI7z/TkKeiDcyEKKen5cU01SnZlVRnncccIxsjzNjCiBdXOTP6o0pTd34j
5VJQ04mF4sla5AaaSDtsbkZuMdqIZDMn1tWxbmXRQ2cUbCGoi4yYiUlqjetrs4e1
i7NopccLNVDwjGRRnaSs4KkpuW7s23XwKm6WVehrP7S9s1Bqc+84C/rL1G4IF3Ul
vOz+dfxpS+yeGdEDOxb92voKo+fvL/N1sH2+cqTemuYWArDOn1kK/qKdaEfnl9p2
VcPJWuik6Ywomg4fCWmTQWcDxbWiUT/Gb/niONOYQ6iJG7mU4SH9LFBDd8qV+ljN
RqUYrOBf/PaMneNxwJp+
=w36r
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 17801 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

- Sent from my tablet
Den 22 feb 2015 17:25 skrev "Justus Ranvier" <justusranvier@riseup.net>:
>
> You just disproved your own argument.
>
> It is possible to predict risk, and therefore to price the risk.

Your fault is that you assume the predictions can be reliable and
trustable.

They can not be.

The data you have available has none of the indicators you actually NEED to
make predictions. You're making extrapolations from the past, not
calculations based on recent trends and behavior globally.

> You also noted that for some Bitcoin users, the price of that risk is
> too high for the types of transactions in which wish to engage.
>
> In what way does that translated into a universal requirement for
> everybody to use multisignature notaries?

It isn't universal. It is just the most practical solution if you need
instant confirmation for high value transactions with customers you don't
yet trust.

> Surely the users who can afford the risk can use zero conf if they
> like, and those who can't can use multisig notaries?

Use whatever you want. I don't care. I will warn you about the risks and
make suggestions, but I won't force you to do anything differently.

[-- Attachment #2: Type: text/html, Size: 1496 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

>
> This happened to one of the merchants at the Bitcoin 2013 conference in
> San Jose. They sold some T-shirts and accepted zero-confirmation
> transactions. The transactions depended on other unconfirmed transactions,
> which never confirmed, so this merchant never got their money.
>

Beyond the fact that this risk can be priced in when enough data is
available, I'd be interested to talk to this merchant and dig into what
happened a bit.

For example:

   1. Was the dependent tx non-standard?
   2. Was it double spent?
   3. Could a wallet have co-operated with the P2P network to detect and
   flag whatever the issue was?

My own experience has been that when this happens, it's usually not the
result of outright maliciousness (especially not at a Bitcoin t-shirt
seller at a Bitcoin conference!) but rather something messed up somewhere
and the software in use just didn't detect it well enough.

[-- Attachment #2: Type: text/html, Size: 1205 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]

Den 22 feb 2015 14:29 skrev "Natanael" <natanael.l@gmail.com>:
>
>
> Den 22 feb 2015 13:36 skrev "Peter Todd" <pete@petertodd.org>:
>
> > Implementing it as a general purpose scripting language improvement has
> > a lot of advantages, not least of which is that you no longer need to
> > rely entirely on inherently unreliable P2P networking: Promise to never
> > create two signatures for a specific BIP32 root pubkey and make
> > violating that promise destroy and/or reallocate a fidelity bond whose
> > value is locked until some time into the future. Since the fidelity bond
> > is a separate pool of funds, detection of the double-spend can happen
> > later.
>
> Somebody sent me a zero-confirmation transaction, or one that got
orphaned after one block. I created a transaction spending that UTXO, and
another.
>
> So at that point I have UTXO_orphaned based on the sender's UTXO_origin
and my UTXO_old (because I've had it unspent for a long time), both in one
transaction, creating UTXO_new.
>
> Now he doublespend UTXO_origin to create a UTXO_doublespend (which
conflicts with UTXO_orphaned). He conspires with a miner to get it into a
block.
>
> Now what? Can my UTXO_old effectively be tainted forever because UTXO_new
got invalidated together with UTXO_orphaned? Will that transaction be a
valid proof of doublespend against a new UTXO_replacement I created?
>
> Or otherwise, if only transactions where all UTXO's are currently valid
works as doublespend proofs, aren't you still just left without protection
against any one miner that conspires with doublespend attempting thieves?
>
> In other words, you are unprotected and potentially at greater risk if
you create a transaction depending on another zero-confirmation transaction.

Additional comments:

If you punish the creation of UTXO_replacement, you will punish people who
was lead to think zero-confirmation transactions were safe and thus that
chains of zero-confirmation transactions also were safe.

If you don't, but STILL accept chains of zero-confirmation transactions
were not all of them are covered by fidelity bonds, then you failed to
protect yourself against thieves who creates chains of unconfirmed
transactions.

Another question: if all transactions in the chain are covered by fidelity
bonds for their own value, which one pays out to who? Does only the first
one pay out, and only to the last party in the chain? Or to every
subsequent party after him? In full or just a fraction? Why, why not? You
might not know which of these serviced their customers in full without
getting full value back in exchange due to the doublespend.

What if the fidelity bond is too small, do you stop accepting it as a
zero-confirmation transaction?

Do you even accept chains of unconfirmed transactions at all?

[-- Attachment #2: Type: text/html, Size: 3267 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Adam Back]

My actual point outside of the emotive stuff (and I should've stayed
away from that too) is how about we explore ways to improve practical
security of fast confirmation transactions, and if we find something
better, then we can help people migrate to that before deprecating the
current weaker 0-conf transactions.

If I understand this is also your own motivation.

Feel free to comment on or improve the proposal or find other approaches.

Adam

On 22 February 2015 at 12:34, Peter Todd <pete@petertodd.org> wrote:
> On Sun, Feb 22, 2015 at 08:02:03AM +0000, Adam Back wrote:
>
> FWIW I've been advocating this kind of thing in various forms for
> literally years, including to hold fidelity bonded banks honest - what
> you now call 'federated sidechains' - and most recently Feb 12th on
> #bitcoin-dev:
>
> 19:56 < petertodd> leakypat: now, do note that an advanced version [of replace-by-fee scorched earth] could be to make another tx that alice and bob setup in advance such that if alcie doublespends, bob gets the money *and* alice pays a bunch of cash to miners fees
> 19:57 < petertodd> leakypat: this would work espectially well if we improved the scripting system so a script could evaluate true based on proof-of-doublespend
> 19:58 < leakypat> Yeah, proof of double spend would ideally be done at the protocol level
> 19:59 < petertodd> leakypat: if satoshi hadn't make the multiple things that CHECKSIG does into one opcode it'd be really easy, but alas...
>
> Implementing it as a general purpose scripting language improvement has
> a lot of advantages, not least of which is that you no longer need to
> rely entirely on inherently unreliable P2P networking: Promise to never
> create two signatures for a specific BIP32 root pubkey and make
> violating that promise destroy and/or reallocate a fidelity bond whose
> value is locked until some time into the future. Since the fidelity bond
> is a separate pool of funds, detection of the double-spend can happen
> later.
>
> Equally, that *is* what replace-by-fee scorched-earth does without the
> need for a soft-fork, minus the cryptographic proof and with a bit less
> flexibility.
>
>> I agree with Mike & Jeff.  Blowing up 0-confirm transactions is vandalism.
>
> Is releasing a version of Bitcoin Core with different IsStandard() rules
> than the previous version vandalism? Is mining with a different policy
> than other people vandalism? Is mining at a pool that gets sybil
> attacked vandalism? Are my replace-by-fee tools an act of vandalism?
> Because every one of those things causes people to get double-spent in
> the real world, even losing tens of thousands of dollars until they get
> some sense and stop treating unconfirmed transactions as confirmed.
>
> Is it vandalism if you decide to host a wedding right next to a hairpin
> corner at a rally race and complain to me that mud is getting on the
> pretty white dresses? Is it vandalism if I tell that wedding party to
> fuck off before someone gets hurt? Is it vandalism if some racers take
> the mudguards off for a few laps to see if we can encourage them to
> leave before someone gets *actually* hurt? Or someone decides that the
> solution is to pave the track over and hold a bicycle race instead...
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Bryan Bishop]

On Sun, Feb 22, 2015 at 8:11 AM, Adam Back <adam@cypherspace.org> wrote:
> away from that too) is how about we explore ways to improve practical
> security of fast confirmation transactions, and if we find something
> better, then we can help people migrate to that before deprecating the
> current weaker 0-conf transactions.

Scenario: Users are using some system in a way that the system was not
intended to be used. Let me also further constrain the scenario and
suggest that the function (pretend that means instantaneous confirmed
transactions) that the user wants is impossible. So in this scenario,
is it your job as some developer to change the system to do something
it wasn't designed to do? I mean, you certainly weren't the one
telling them they should accept zero confirmation transactions. Also,
I make no claims as to whether this scenario maps accurately to the
current topic.

- Bryan
http://heybryan.org/
1 512 203 0507

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On Sun, Feb 22, 2015 at 02:11:31PM +0000, Adam Back wrote:
> My actual point outside of the emotive stuff (and I should've stayed
> away from that too) is how about we explore ways to improve practical
> security of fast confirmation transactions, and if we find something
> better, then we can help people migrate to that before deprecating the
> current weaker 0-conf transactions.
> 
> If I understand this is also your own motivation.

Indeed, which is why I wrote some easy-to-use and highly effective tools
to pull off double-spends and made sure to publicise them and their
effectiveness widely. They've had their desired effect and very few
people are relying on unconfirmed transactions anymore. As for the
remaining, next week alone I'll be volunteering one or two hours of my
consulting time to discuss solutions with a team doing person-to-person
trading for instance.

Like I've said repeatedly, the current "weaker" 0-conf transactions gets
people new to Bitcoin - both individuals and companies - burnt over and
over again because inevitably someone eventually gets motivated and
breaks them, and suddenly they lose stacks of money.

Keeping *that* kind of "security" around rather than depreciating it
ASAP and being honest about what Bitcoin can do does no-one any good.

Anyway, there is no one magic solution to this stuff - the best
solutions vary greatly on the situation.

-- 
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[joliver]

On 2015-02-22 14:33, Peter Todd wrote:
> On Sun, Feb 22, 2015 at 02:11:31PM +0000, Adam Back wrote:
>> My actual point outside of the emotive stuff (and I should've stayed
>> away from that too) is how about we explore ways to improve practical
>> security of fast confirmation transactions, and if we find something
>> better, then we can help people migrate to that before deprecating the
>> current weaker 0-conf transactions.
>> 
>> If I understand this is also your own motivation.
> 
> Indeed, which is why I wrote some easy-to-use and highly effective 
> tools
> to pull off double-spends and made sure to publicise them and their
> effectiveness widely. They've had their desired effect and very few
> people are relying on unconfirmed transactions anymore.

You mean you wrote a bunch of FUD about zeroconf transactions while 
working for companies like Coinbase and GreenAddress that were trying to 
sell 100% centralized solutions? Lets just be clear on this.

I and many other people tried your replace-by-fee tools and found out 
that they worked **maybe** 1-2% of the time. You claimed 95% success 
rates.

> As for the
> remaining, next week alone I'll be volunteering one or two hours of my
> consulting time to discuss solutions with a team doing person-to-person
> trading for instance.

A "team"

You mean a **Company**? We don't need yet another 100% centralized 
LocalBitcoins snooping on our transactions.

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

On Sun, Feb 22, 2015 at 03:18:05PM +0000, joliver@airmail.cc wrote:
> > Indeed, which is why I wrote some easy-to-use and highly effective 
> > tools
> > to pull off double-spends and made sure to publicise them and their
> > effectiveness widely. They've had their desired effect and very few
> > people are relying on unconfirmed transactions anymore.
> 
> You mean you wrote a bunch of FUD about zeroconf transactions while 
> working for companies like Coinbase and GreenAddress that were trying to 
> sell 100% centralized solutions? Lets just be clear on this.

You lot spend so much time trying to claim I'm working for people I'm
not that I have a bad feeling I'm going to end up having to explain what
an internet troll is to "friendly" Revenue Canada tax auditor...

> I and many other people tried your replace-by-fee tools and found out 
> that they worked **maybe** 1-2% of the time. You claimed 95% success 
> rates.

That tool was intentionally shipped with unclear instructions and nearly
all the double-spend strategies turned off by default; you can easily
increase that number with a little understanding.

> > As for the
> > remaining, next week alone I'll be volunteering one or two hours of my
> > consulting time to discuss solutions with a team doing person-to-person
> > trading for instance.
> 
> A "team"
> 
> You mean a **Company**? We don't need yet another 100% centralized 
> LocalBitcoins snooping on our transactions.

"[Bitcoin-development] Eliminating double-spends with two-party
self-escrow for high value transactions",
Peter Todd, Apt 26th 2014,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05166.html

(note that the above should be updated to use CHECKLOCKTIMEVERIFY)

-- 
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]