TUCCI Sara [ARCHIVE] on Nostr: 📅 Original date posted:2018-09-07 📝 Original message:Hello Gregory, all Thank ...
📅 Original date posted:2018-09-07
📝 Original message: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 at 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:
📝 Original message: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 at 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: