Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-22 📝 Original message:On Sun, Feb 22, 2015 at ...
📅 Original date posted:2015-02-22
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/4a274018/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/4a274018/attachment.sig>;