* [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
@ 2018-09-06 9:19 Alejandro Ranchal Pedrosa
2018-09-06 13:31 ` Matt Corallo
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Alejandro Ranchal Pedrosa @ 2018-09-06 9:19 UTC (permalink / raw)
To: bitcoin-dev; +Cc: TUCCI Sara, Önder GÜRCAN
[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]
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
[-- Attachment #2: Gurcan2018. On Cancellation of Transactions in Bitcoin-like Blockchains.pdf --]
[-- Type: application/pdf, Size: 785408 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-06 9:19 [bitcoin-dev] A BIP proposal for transactions that are 'cancellable' Alejandro Ranchal Pedrosa
@ 2018-09-06 13:31 ` Matt Corallo
[not found] ` <CABaiX-2L9oVdta=aRH91uE=iPRv4cX6zU0=+oF+2oWqnu=64YQ@mail.gmail.com>
2018-09-06 15:16 ` Gregory Maxwell
2018-09-06 16:14 ` vizeet srivastava
2 siblings, 1 reply; 11+ messages in thread
From: Matt Corallo @ 2018-09-06 13:31 UTC (permalink / raw)
To: Alejandro Ranchal Pedrosa, Bitcoin Protocol Discussion,
Alejandro Ranchal Pedrosa via bitcoin-dev, bitcoin-dev
Cc: TUCCI Sara, Önder GÜRCAN
[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]
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> 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
[-- Attachment #2: Type: text/html, Size: 2298 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-06 9:19 [bitcoin-dev] A BIP proposal for transactions that are 'cancellable' Alejandro Ranchal Pedrosa
2018-09-06 13:31 ` Matt Corallo
@ 2018-09-06 15:16 ` Gregory Maxwell
2018-09-06 20:32 ` Brandon Smith
2018-09-06 16:14 ` vizeet srivastava
2 siblings, 1 reply; 11+ messages in thread
From: Gregory Maxwell @ 2018-09-06 15:16 UTC (permalink / raw)
To: a.ranchalpedrosa, Bitcoin Dev; +Cc: sara.tucci, Onder.GURCAN
Functionality such as this does not currently exist not because no one
thought of it before, but because it has been proposed many times
before and determined to be harmful. The existing design of CLTV/CSV
were carefully constructed to make it impossible for a transaction to
go from valid to invalid based on the time. The most naive
construction-- e.g. push the current time/height on the stack-- would
have that property and was specifically avoided.
When a spend goes from valid to invalid it means that a reorganization
will destroy coins even completely absent any dishonest actions of the
coins prior owner in the coins recent casual history. Effectively a
coin with any kind of non-monotone validity event in its recent
history functions like a recently generated coin: a coin that reorgs
destroy. Bitcoin addresses the issue for recently generated coins by
not permitting their use for 100 blocks. I've yet to see an argument
for a use case for non-monotone validity that still sounds useful once
the negative effects are addressed (e.g. by subjecting coins that have
gone through them to a maturity limitation).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-06 9:19 [bitcoin-dev] A BIP proposal for transactions that are 'cancellable' Alejandro Ranchal Pedrosa
2018-09-06 13:31 ` Matt Corallo
2018-09-06 15:16 ` Gregory Maxwell
@ 2018-09-06 16:14 ` vizeet srivastava
2 siblings, 0 replies; 11+ messages in thread
From: vizeet srivastava @ 2018-09-06 16:14 UTC (permalink / raw)
To: Alejandro Ranchal Pedrosa, Bitcoin Protocol Discussion
Cc: TUCCI Sara, Önder GÜRCAN
[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]
I feel it is breaking a principle that if a transaction is valid it remains
valid. There might be dangerous repercussions to breaking that rule. For
instance chain of transaction become invalid which might lead to losses.
On Thu 6 Sep, 2018, 6:37 PM Alejandro Ranchal Pedrosa via bitcoin-dev, <
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,
>
> --
> Alejandro Ranchal Pedrosa, Önder Gürcan and Sara Tucci-Piergiovanni
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2874 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
[not found] ` <CABaiX-2L9oVdta=aRH91uE=iPRv4cX6zU0=+oF+2oWqnu=64YQ@mail.gmail.com>
@ 2018-09-06 16:33 ` Matt Corallo
2018-09-07 7:07 ` Alejandro Ranchal Pedrosa
0 siblings, 1 reply; 11+ messages in thread
From: Matt Corallo @ 2018-09-06 16:33 UTC (permalink / raw)
To: Alejandro Ranchal Pedrosa; +Cc: Bitcoin Dev
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-lists@mattcorallo•com
> <mailto:lf-lists@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,
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-06 15:16 ` Gregory Maxwell
@ 2018-09-06 20:32 ` Brandon Smith
2018-09-07 5:02 ` Terry McLaughlin
2018-09-07 7:12 ` Alejandro Ranchal Pedrosa
0 siblings, 2 replies; 11+ messages in thread
From: Brandon Smith @ 2018-09-06 20:32 UTC (permalink / raw)
To: Gregory Maxwell, Bitcoin Protocol Discussion
Cc: sara.tucci, Onder.GURCAN, a.ranchalpedrosa
I made a similar proposal about 7 months ago, and documented some of the
discussion points here:
https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz.mediawiki
On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev wrote:
> Functionality such as this does not currently exist not because no one
> thought of it before, but because it has been proposed many times
> before and determined to be harmful. The existing design of CLTV/CSV
> were carefully constructed to make it impossible for a transaction to
> go from valid to invalid based on the time. The most naive
> construction-- e.g. push the current time/height on the stack-- would
> have that property and was specifically avoided.
>
> When a spend goes from valid to invalid it means that a reorganization
> will destroy coins even completely absent any dishonest actions of the
> coins prior owner in the coins recent casual history. Effectively a
> coin with any kind of non-monotone validity event in its recent
> history functions like a recently generated coin: a coin that reorgs
> destroy. Bitcoin addresses the issue for recently generated coins by
> not permitting their use for 100 blocks. I've yet to see an argument
> for a use case for non-monotone validity that still sounds useful once
> the negative effects are addressed (e.g. by subjecting coins that have
> gone through them to a maturity limitation).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-06 20:32 ` Brandon Smith
@ 2018-09-07 5:02 ` Terry McLaughlin
2018-09-07 7:12 ` Alejandro Ranchal Pedrosa
1 sibling, 0 replies; 11+ messages in thread
From: Terry McLaughlin @ 2018-09-07 5:02 UTC (permalink / raw)
To: Brandon Smith, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
Please help me guide me in the direction I need to go
On Thursday, September 6, 2018, Brandon Smith via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I made a similar proposal about 7 months ago, and documented some of the
> discussion points here:
>
> https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz.
> mediawiki
>
> On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev
> wrote:
> > Functionality such as this does not currently exist not because no one
> > thought of it before, but because it has been proposed many times
> > before and determined to be harmful. The existing design of CLTV/CSV
> > were carefully constructed to make it impossible for a transaction to
> > go from valid to invalid based on the time. The most naive
> > construction-- e.g. push the current time/height on the stack-- would
> > have that property and was specifically avoided.
> >
> > When a spend goes from valid to invalid it means that a reorganization
> > will destroy coins even completely absent any dishonest actions of the
> > coins prior owner in the coins recent casual history. Effectively a
> > coin with any kind of non-monotone validity event in its recent
> > history functions like a recently generated coin: a coin that reorgs
> > destroy. Bitcoin addresses the issue for recently generated coins by
> > not permitting their use for 100 blocks. I've yet to see an argument
> > for a use case for non-monotone validity that still sounds useful once
> > the negative effects are addressed (e.g. by subjecting coins that have
> > gone through them to a maturity limitation).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2814 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-06 16:33 ` Matt Corallo
@ 2018-09-07 7:07 ` Alejandro Ranchal Pedrosa
0 siblings, 0 replies; 11+ messages in thread
From: Alejandro Ranchal Pedrosa @ 2018-09-07 7:07 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Dev
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-lists@mattcorallo•com
>> <mailto:lf-lists@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,
>>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-06 20:32 ` Brandon Smith
2018-09-07 5:02 ` Terry McLaughlin
@ 2018-09-07 7:12 ` Alejandro Ranchal Pedrosa
2018-09-07 12:51 ` Brandon Smith
1 sibling, 1 reply; 11+ messages in thread
From: Alejandro Ranchal Pedrosa @ 2018-09-07 7:12 UTC (permalink / raw)
To: Brandon Smith, Gregory Maxwell, Bitcoin Protocol Discussion; +Cc: Onder.GURCAN
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
Hi all,
Thank you for the link, and also to Gregory for the remarks. I did not
know about this previous proposal. I think the last paragraph of future
work is interesting:
"It may be interesting to add enhance OP_CHECKSEQUENCEVERIFY
<https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki> to
allow outputs that are spendable by Alice until time foo, always
spendable by Bob, and spendable by Joe only after time bar, or other
such cases"
Perhaps it would allow this functionality, while keeping the validity of
coins, if the new OP_zzz took an additional argument than suggested,
such that the first one is the timelimit for Alice to keep the coin (say
in the first 24 hours), and after those 24 hours the ownership goes to
the third argument, say Bob.
That is, it is not possible to use only specifying the owner in the
first 24 hours. Would this be considered harmful?
Best,
Alejandro.
On 9/6/18 10:32 PM, Brandon Smith wrote:
> ade a similar proposal about 7 months ago, and documented some of the
> discussion points here:
[-- Attachment #2: Type: text/html, Size: 1584 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-07 7:12 ` Alejandro Ranchal Pedrosa
@ 2018-09-07 12:51 ` Brandon Smith
2018-09-07 13:47 ` TUCCI Sara
0 siblings, 1 reply; 11+ messages in thread
From: Brandon Smith @ 2018-09-07 12:51 UTC (permalink / raw)
To: Alejandro Ranchal Pedrosa; +Cc: Bitcoin Protocol Discussion, Onder.GURCAN
I believe you may be missing the overall points in the "Nail In the
Coffin" and "Temporary Discussion" sections. In summary:
1: Any UTXO spending a script with an expiration must be treated
similarly to Coinbase (I proposed a solution to this, but it's complex
and may have unforeseen implications).
2: All existing software assumes that a transaction once valid stays
valid. Any proposal to change this must ensure that existing wallets and
users aren't immediately open to being scammed by malicious actors
sending low fee expiring transactions.
The more tenable ways to move forward on improving the ecosystem around
delayed transactions and refunds are: Lightning, improved fee
estimation, and improved mempool eviction / re-propagation resistance.
The original reason that I began looking into this is because I noticed
that during high fee periods, transactions could re-propagate between
mempools of differing policies resulting in coins being stuck unusable
for far longer than the expected 1-2 week eviction. I don't know of any
concrete work going into investigating or improving this.
HTH,
--Brandon
On 2018-09-07 (Fri) at 09:12:40 +0200, Alejandro Ranchal Pedrosa wrote:
> Hi all,
>
> Thank you for the link, and also to Gregory for the remarks. I did not
> know about this previous proposal. I think the last paragraph of future
> work is interesting:
>
> "It may be interesting to add enhance OP_CHECKSEQUENCEVERIFY
> <https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki> to
> allow outputs that are spendable by Alice until time foo, always
> spendable by Bob, and spendable by Joe only after time bar, or other
> such cases"
>
> Perhaps it would allow this functionality, while keeping the validity of
> coins, if the new OP_zzz took an additional argument than suggested,
> such that the first one is the timelimit for Alice to keep the coin (say
> in the first 24 hours), and after those 24 hours the ownership goes to
> the third argument, say Bob.
>
> That is, it is not possible to use only specifying the owner in the
> first 24 hours. Would this be considered harmful?
>
> Best,
>
> Alejandro.
>
> On 9/6/18 10:32 PM, Brandon Smith wrote:
> > ade a similar proposal about 7 months ago, and documented some of the
> > discussion points here:
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
2018-09-07 12:51 ` Brandon Smith
@ 2018-09-07 13:47 ` TUCCI Sara
0 siblings, 0 replies; 11+ messages in thread
From: TUCCI Sara @ 2018-09-07 13:47 UTC (permalink / raw)
To: Brandon Smith, Alejandro Ranchal Pedrosa
Cc: Bitcoin Protocol Discussion, GÜRCAN Onder
Hello Gregory, all
Thank you so much for your feedback. Our main objective in the research paper was in fact to study the "what-if" situation in which Bitcoin offered the cancellation of the transaction from the user's point of view. Our main interest was the model of the user-agents and quantify the possible "satisfaction" that the user can obtain while also quantifying a possible greater satisfaction with the respect to the current situation. When we wrote the document, we thought about the "implementability" of the cancellation through non-monotonous validity to obtain a more realistic model, but being very cautious in proposing or claiming any kind of mechanism. Of course we never thought that nobody ever proposed it before, that's why when we finished writing the paper, many questions remained unanswered and we decided to send you the document, to get your opinion, which is very useful for improving the current model.
Although Bitcoin will never implement the mechanism because arguments for non-monotonous validity use case will not emerge, I think this type of study can be useful to conclude on that opportunity or as Brandon suggested to move to other approaches, like Lightning (even though even for Lightning several limitations still there exist !).
Sara
P.S.
Sorry for possible multiple copies of the message, I needed to subscribe to the mailing list and to repost __
On 07/09/2018, 14:51, "Brandon Smith" <freedom@reardencode•com> wrote:
I believe you may be missing the overall points in the "Nail In the
Coffin" and "Temporary Discussion" sections. In summary:
1: Any UTXO spending a script with an expiration must be treated
similarly to Coinbase (I proposed a solution to this, but it's complex
and may have unforeseen implications).
2: All existing software assumes that a transaction once valid stays
valid. Any proposal to change this must ensure that existing wallets and
users aren't immediately open to being scammed by malicious actors
sending low fee expiring transactions.
The more tenable ways to move forward on improving the ecosystem around
delayed transactions and refunds are: Lightning, improved fee
estimation, and improved mempool eviction / re-propagation resistance.
The original reason that I began looking into this is because I noticed
that during high fee periods, transactions could re-propagate between
mempools of differing policies resulting in coins being stuck unusable
for far longer than the expected 1-2 week eviction. I don't know of any
concrete work going into investigating or improving this.
HTH,
--Brandon
On 2018-09-07 (Fri) at 09:12:40 +0200, Alejandro Ranchal Pedrosa wrote:
> Hi all,
>
> Thank you for the link, and also to Gregory for the remarks. I did not
> know about this previous proposal. I think the last paragraph of future
> work is interesting:
>
> "It may be interesting to add enhance OP_CHECKSEQUENCEVERIFY
> <https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki> to
> allow outputs that are spendable by Alice until time foo, always
> spendable by Bob, and spendable by Joe only after time bar, or other
> such cases"
>
> Perhaps it would allow this functionality, while keeping the validity of
> coins, if the new OP_zzz took an additional argument than suggested,
> such that the first one is the timelimit for Alice to keep the coin (say
> in the first 24 hours), and after those 24 hours the ownership goes to
> the third argument, say Bob.
>
> That is, it is not possible to use only specifying the owner in the
> first 24 hours. Would this be considered harmful?
>
> Best,
>
> Alejandro.
>
> On 9/6/18 10:32 PM, Brandon Smith wrote:
> > ade a similar proposal about 7 months ago, and documented some of the
> > discussion points here:
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-09-07 13:47 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-06 9:19 [bitcoin-dev] A BIP proposal for transactions that are 'cancellable' Alejandro Ranchal Pedrosa
2018-09-06 13:31 ` Matt Corallo
[not found] ` <CABaiX-2L9oVdta=aRH91uE=iPRv4cX6zU0=+oF+2oWqnu=64YQ@mail.gmail.com>
2018-09-06 16:33 ` Matt Corallo
2018-09-07 7:07 ` Alejandro Ranchal Pedrosa
2018-09-06 15:16 ` Gregory Maxwell
2018-09-06 20:32 ` Brandon Smith
2018-09-07 5:02 ` Terry McLaughlin
2018-09-07 7:12 ` Alejandro Ranchal Pedrosa
2018-09-07 12:51 ` Brandon Smith
2018-09-07 13:47 ` TUCCI Sara
2018-09-06 16:14 ` vizeet srivastava
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox