Yes I agree with what you mean but this requires Alice to broadcast an
additional transaction. Also, Alice is supposed to be able to 'cancel'
the transaction in the first 24hours, not after them.
Best,
Alejandro.
On 9/6/18 6:33 PM, Matt Corallo wrote:
I think you misunderstood my proposal. What you'd do is the transaction
is spendable by either Bob OR (Bob AND Alice) and before
broadcast/during construction/whatever sign a new transaction that
spends it and is only spendable by Alice, but is timelocked for 24
hours. At the 24h mark, Alice broadcasts the transaction and once it is
confirmed only Alice can claim the money.
On 09/06/18 10:59, Alejandro Ranchal Pedrosa wrote:
Dear Matt,
Notice that what you suggest has some substantial differences. With your
suggestion of a multisig option with a 24h timelock, once you give Alice
the chance to spend that UTXO without a negative timelock (as we argue),
by means of, say, a transaction that she can use, you cannot enforce
that this is not used by Alice after the 24hs. Perhaps it is possible,
tweaking the Lightning Channel design of Breach Remedy txs, to penalize
Alice if she does this, but this requires Bob to check the Blockchain in
case he needs to publish a proof-of-fraud, think of adding extra funds
to the transaction to account for penalization, etc.
Feel free to correct me if I got it wrong in your email.
Best,
Alejandro.
On Thu, Sep 6, 2018 at 3:32 PM Matt Corallo <lf-li...@mattcorallo.com
<mailto:lf-li...@mattcorallo.com>> wrote:
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@lists.linuxfoundation.org
<mailto:bitcoin-dev@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,
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
