Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2018-09-06 📝 Original message:I think a simple approach ...
📅 Original date posted:2018-09-06
📝 Original message:I think a simple approach to what you want to accomplish is to simply have a multisig option with a locktime pre-signed transaction which is broadcastable at the 24h mark and has different spendability. This avoids introducing reorg-induced invalidity.
On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Pedrosa via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hello everyone,
>
>We would like to propose a new BIP to extend OP_CSV (and/or OP_CLTV) in
>order for these to allow and interpret negative values. This way,
>taking the example shown in BIP 112:
>
>HASH160 <revokehash> EQUAL
>IF
> <Bob's pubkey>
>ELSE
> "24h" CHECKSEQUENCEVERIFY DROP
> <Alice's pubkey>
>ENDIF
>CHECKSIG
>
>that gives ownership only to Bob for the first 24 hours and then to
>whichever spends first, we basically propose using the negative bit
>value:
>
>HASH160 <revokehash> EQUAL
>IF
> <Bob's pubkey>
>ELSE
> "-24h" CHECKSEQUENCEVERIFY DROP
> <Alice's pubkey>
>ENDIF
>CHECKSIG
>
>meaning that both would have ownership for the first 24 hours, but
>after that only Bob would own such coins. Its implementation should
>not be too tedious, and in fact it simply implies considering negative
>values that are at the moment discarded as for the specification of
>BIP-112, leaving the sign bit unused.
>
>This, we argue, an increase the fairness of the users, and can at times
>be more cost-effective for users to do rather than trying a
>Replace-By-Fee
>transaction, should they want to modify such payment.
>
>We would like to have a discussion about this before proposing the
>BIP, for which we are preparing the text.
>
>You can find our paper discussing it here:
>https://hal-cea.archives-ouvertes.fr/cea-01867357 (find attached as
>well)
>
>Best,
>
>--
>Alejandro Ranchal Pedrosa, Önder Gürcan and Sara Tucci-Piergiovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180906/4ff7a84e/attachment-0001.html>;
📝 Original message:I think a simple approach to what you want to accomplish is to simply have a multisig option with a locktime pre-signed transaction which is broadcastable at the 24h mark and has different spendability. This avoids introducing reorg-induced invalidity.
On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Pedrosa via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hello everyone,
>
>We would like to propose a new BIP to extend OP_CSV (and/or OP_CLTV) in
>order for these to allow and interpret negative values. This way,
>taking the example shown in BIP 112:
>
>HASH160 <revokehash> EQUAL
>IF
> <Bob's pubkey>
>ELSE
> "24h" CHECKSEQUENCEVERIFY DROP
> <Alice's pubkey>
>ENDIF
>CHECKSIG
>
>that gives ownership only to Bob for the first 24 hours and then to
>whichever spends first, we basically propose using the negative bit
>value:
>
>HASH160 <revokehash> EQUAL
>IF
> <Bob's pubkey>
>ELSE
> "-24h" CHECKSEQUENCEVERIFY DROP
> <Alice's pubkey>
>ENDIF
>CHECKSIG
>
>meaning that both would have ownership for the first 24 hours, but
>after that only Bob would own such coins. Its implementation should
>not be too tedious, and in fact it simply implies considering negative
>values that are at the moment discarded as for the specification of
>BIP-112, leaving the sign bit unused.
>
>This, we argue, an increase the fairness of the users, and can at times
>be more cost-effective for users to do rather than trying a
>Replace-By-Fee
>transaction, should they want to modify such payment.
>
>We would like to have a discussion about this before proposing the
>BIP, for which we are preparing the text.
>
>You can find our paper discussing it here:
>https://hal-cea.archives-ouvertes.fr/cea-01867357 (find attached as
>well)
>
>Best,
>
>--
>Alejandro Ranchal Pedrosa, Önder Gürcan and Sara Tucci-Piergiovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180906/4ff7a84e/attachment-0001.html>;