Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-02-12 š Original message:On Thu, Feb 12, 2015 at ...
š
Original date posted:2015-02-12
š Original message:On Thu, Feb 12, 2015 at 07:49:29PM +0000, Gregory Maxwell wrote:
> One challenge is that without rather smart child-pays-for-parent logic
> the positive argument for replace by fee doesn't really work.
That's actually incorrect now, as a mechanism for implementing
scorched-earth without child-pays-for-parent using SIGHASH_ANYONECANPAY
is available:
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
I greatly prefer this mechanism as it's an opt-in mechanism - many
wallets double-spend on occasion by accident - and can have the
incentives be adjusted to suit the % of hashing power that actual
supports replace-by-fee. (and the % probability you'll see the
doublespend)
My patch implements 90% of the logic required for the above to work,
however I've intentionally limited the total depth of recursion when the
replacement is being evaluated as an interm anti-DoS measure in the
spirit of belt-and-suspenders engineering. This can certainly be
improved on, e.g. by limiting total mempool size.
--
'peter'[:-1]@petertodd.org
00000000000000000a16bcc766361414571a5f961698acc46c27bd79c26ac15c
-------------- 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/20150212/d0cc7c13/attachment.sig>
š Original message:On Thu, Feb 12, 2015 at 07:49:29PM +0000, Gregory Maxwell wrote:
> One challenge is that without rather smart child-pays-for-parent logic
> the positive argument for replace by fee doesn't really work.
That's actually incorrect now, as a mechanism for implementing
scorched-earth without child-pays-for-parent using SIGHASH_ANYONECANPAY
is available:
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
I greatly prefer this mechanism as it's an opt-in mechanism - many
wallets double-spend on occasion by accident - and can have the
incentives be adjusted to suit the % of hashing power that actual
supports replace-by-fee. (and the % probability you'll see the
doublespend)
My patch implements 90% of the logic required for the above to work,
however I've intentionally limited the total depth of recursion when the
replacement is being evaluated as an interm anti-DoS measure in the
spirit of belt-and-suspenders engineering. This can certainly be
improved on, e.g. by limiting total mempool size.
--
'peter'[:-1]@petertodd.org
00000000000000000a16bcc766361414571a5f961698acc46c27bd79c26ac15c
-------------- 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/20150212/d0cc7c13/attachment.sig>