📅 Original date posted:2015-02-22
📝 Original message: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 at bitpay.com> wrote:
> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Adam Back [ARCHIVE] /
npub1ac…lswfj
2023-06-07 15:30:53
in reply to nevent1q…dvh3
Author Public Key
npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfjPublished at
2023-06-07 15:30:53Event JSON
{
"id": "428a28a6b2725d671f4e767b0bd33dc86dde25941e548c161aef3950f41aaba2",
"pubkey": "ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a",
"created_at": 1686151853,
"kind": 1,
"tags": [
[
"e",
"00335b798bd3386560c6501fdcb4ac491a0b697640f4bb1d0fb0617840851a89",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-02-22\n📝 Original message:I agree with Mike \u0026 Jeff. Blowing up 0-confirm transactions is vandalism.\n\nbitcoin transactions are all probabilistic. there is a small chance\n1-confirm transactions can be reversed, and a different but also\nusable chance that 0-confirm transactions can be reversed. I know\n0-confirm is implemented in policy and not consensus, but it provides\nfast transactions and a lot of the current ecosystem is using it for\nlow value transactions. why would anyone want to vandalise that.\n\nto echo Mike bitcoin itself kind of depends on some honest majority,\nwe can otherwise get to situations soon enough where its more\nprofitable to double-spend than mine honestly as subsidy drops and\ntransaction values increase even without 0-confirm transactions.\nsubsidy doesnt last forever (though it lasts a really long time) and\neven right now if you involve values that dwarf subsidy you could make\na \"criminally rational\" behaviour that was more profitable. we even\nsaw 0-confirm odds-attacks against satoshi dice clones. but if we\nassume the \"criminal rational\" model, its a is a race to the bottom\nlogic, and bitcoin is already broken if we have someone who wants to\ngo for it with high values. that'd be scorched earth also.\n\n(I read the rest of the arguments, i understood them, I disagree, no\nneed to repeat in reply.)\n\nSo how about instead, to be constructive, whether you agree with the\nanti-arson view or not, lets talk about solutions. Here's one idea:\n\nWe introduce a new signature type that marks itself as can be spent by\nminers if a double-spend is seen (before 1-confirm.) We'd define a\ndouble-spend as a spend that excludes outputs to avoid affecting valid\ndouble-spend scenarios. And we add behaviour to relay those\ndouble-spends (at priority). We may even want the double-spend to be\nserialisation incomplete but verifiable to deter back-channel payments\nto pretend not to receive one, in collusion with the double-spending\nparty.\n\nNow the risk to the sender is if they accidentally double-spend. How\ncould they do that? By having a hardware or software crash where they\nsent a tx but crashed before writing a record of having sent it. The\ncorrect thing to do would be to transactionally write the transaction\nbefore sending it. Still you can get a fail if the hardware\nirrecoverably fails, and you have to resume from backup. Or if you\nrun multiple non-synced wallets on the same coins.\n\nTypically if you recover from backup the 1-confirmation window will\nhave passed so the risk is limited.\n\nThe feature is opt-in so you dont have to put high value coins at risk\nof failure.\n\n(Its related to the idea of a one-use signature, where two signatures\nreveals a simultaneous equation that can recover the private key;\nexcept here the miner is allowed to take the coins without needing the\nprivate key).\n\nIts soft-forkable because its a new transaction type.\n\nps I agree with Greg also that longer-term more scalable solutions are\ninteresting, but I'd like to see the core network work as a stepping\nstone. As Justus observed: the scalable solutions so far have had\nnon-ideal ethos tradeoffs so are not drop-in upgrades to on-chain\n0-confirm.\n\nAdam\n\nOn 22 February 2015 at 04:06, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\u003e On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\u003e On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\u003e\u003e\u003e This isn't some theoretical exercise. Like it or not many use\n\u003e\u003e\u003e insecure 0-conf transactions for rapid payments. Deploying something\n\u003e\u003e\u003e that makes 0-conf transactions unusable would have a wide, negative\n\u003e\u003e\u003e impact on present day bitcoin payments, thus \"scorched earth\"\n\u003e\n\u003e\u003e And maybe by maintaining first seen policies we're harming the system\n\u003e\u003e in the long term by encouraging people to widely deploy systems based\n\u003e\u003e on extremely weak assumptions.\n\u003e\n\u003e Lacking a coded, reviewed alternative, that's only a platitude.\n\u003e Widely used 0-conf payments are where we're at today. Simply ceasing\n\u003e the \"maintaining [of] first seen policies\" alone is simply not a\n\u003e realistic option. The negative impact to today's userbase would be\n\u003e huge.\n\u003e\n\u003e Instant payments need a security upgrade, yes.\n\u003e\n\u003e --\n\u003e Jeff Garzik\n\u003e Bitcoin core developer and open source evangelist\n\u003e BitPay, Inc. https://bitpay.com/\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server\n\u003e from Actuate! Instantly Supercharge Your Business Reports and Dashboards\n\u003e with Interactivity, Sharing, Native Excel Exports, App Integration \u0026 more\n\u003e Get technology previously reserved for billion-dollar corporations, FREE\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=190641631\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "866451dfc22f5f5dd354c71168aa5ce2505fbe298ba5a137f0c1905cd7fc9b59d8a1d1d19eb2bd13ad6a900d7a4f80c95daa3fa001b8230ac346203b370c23b4"
}