Moral Agent [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-22 📝 Original message:Along the same lines, I ...
📅 Original date posted:2018-01-22
📝 Original message:Along the same lines, I wonder if unrelated people with tx that are not
confirming could cooperate to merge their disparate tx into a CoinJoin tx
with a higher fee rate?
Perhaps they could even replace old tx with economically equivalent summary
transactions?
The mempool seems like nature's accumulator for pre-mining compression
opportunities.
On Mon, Jan 22, 2018 at 1:18 PM, Rhavar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If you spent your change from transaction A, that would be safe. There'd
> be no way you John could end up with 2 BTC from you then.
>
> Yes, that's what the following paragraph says -- along with it's
> limitations =)
>
> -Ryan
>
>
> -------- Original Message --------
> On January 22, 2018 1:16 PM, Alan Evans <thealanevans at gmail.com> wrote:
>
> > So now I still owe John 1 BTC, however it's not immediately clear if it's
> safe to send to him
>
> If you spent your change from transaction A, that would be safe. There'd
> be no way you John could end up with 2 BTC from you then.
>
> On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> So my half-baked idea is very simple:
>>
>> Allow users to merge multiple unconfirmed transactions, stripping
>> extraneous inputs and change as they go.
>>
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum
>> paid by the original transactions."
>>
>> Because the size of the merged transaction is smaller than the original
>> transactions, unless there is a considerable feerate bump, this rule isn't
>> possible to observe.
>>
>>
>> I my question is: is it possible or reasonable to relax this rule? If
>> this rule was removed in its entirety, does it introduce any DoS vectors?
>> Or can it be changed to allow my use-case?
>>
>>
>> ---
>> Full backstory: I have been trying to use bip125 (Opt-in Full
>> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I
>> owe John 1 bitcoin, and have promised to pay him immediately: Instead of
>> creating a whole new transaction if I have an in-flight (unconfirmed)
>> transaction, I can follow the rules of bip125 to create a replacement that
>> accomplishes this goal.
>>
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it
>> without difficulty.
>>
>> However, the real problem is tracking the mess. Consider this sequence of
>> events:
>> 1) I have unconfirmed transaction A
>> 2) I replace it with B, which pays John 1 BTC
>> 3) Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>>
>> One possible solution is to only consider a transaction "replaceable" if
>> it has change, so if the original transaction confirms -- payments can
>> immediately be made that source the change, and provide safety in a reorg.
>>
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>>
>> There's a few other hacks you can do to make it work in a few more cases,
>> but nothing that is realistic to expect anyone to implement any time soon.
>>
>> However, if there was a straight foward way to merge N unconfirmed
>> transactions, it would be easy get into production, and potentially offer
>> some pretty nice savings for everyone.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/8273b051/attachment.html>;
📝 Original message:Along the same lines, I wonder if unrelated people with tx that are not
confirming could cooperate to merge their disparate tx into a CoinJoin tx
with a higher fee rate?
Perhaps they could even replace old tx with economically equivalent summary
transactions?
The mempool seems like nature's accumulator for pre-mining compression
opportunities.
On Mon, Jan 22, 2018 at 1:18 PM, Rhavar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If you spent your change from transaction A, that would be safe. There'd
> be no way you John could end up with 2 BTC from you then.
>
> Yes, that's what the following paragraph says -- along with it's
> limitations =)
>
> -Ryan
>
>
> -------- Original Message --------
> On January 22, 2018 1:16 PM, Alan Evans <thealanevans at gmail.com> wrote:
>
> > So now I still owe John 1 BTC, however it's not immediately clear if it's
> safe to send to him
>
> If you spent your change from transaction A, that would be safe. There'd
> be no way you John could end up with 2 BTC from you then.
>
> On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> So my half-baked idea is very simple:
>>
>> Allow users to merge multiple unconfirmed transactions, stripping
>> extraneous inputs and change as they go.
>>
>> This is currently not possible because of the bip125 rule:
>> "The replacement transaction pays an absolute fee of at least the sum
>> paid by the original transactions."
>>
>> Because the size of the merged transaction is smaller than the original
>> transactions, unless there is a considerable feerate bump, this rule isn't
>> possible to observe.
>>
>>
>> I my question is: is it possible or reasonable to relax this rule? If
>> this rule was removed in its entirety, does it introduce any DoS vectors?
>> Or can it be changed to allow my use-case?
>>
>>
>> ---
>> Full backstory: I have been trying to use bip125 (Opt-in Full
>> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I
>> owe John 1 bitcoin, and have promised to pay him immediately: Instead of
>> creating a whole new transaction if I have an in-flight (unconfirmed)
>> transaction, I can follow the rules of bip125 to create a replacement that
>> accomplishes this goal.
>>
>> From a "coin selection" point of view, this was significantly easier than
>> I had anticipated. I was able to encode the rules in my linear model and
>> feed in all my unspent and in-flight transactions and it can solve it
>> without difficulty.
>>
>> However, the real problem is tracking the mess. Consider this sequence of
>> events:
>> 1) I have unconfirmed transaction A
>> 2) I replace it with B, which pays John 1 BTC
>> 3) Transaction A gets confirmed
>>
>> So now I still owe John 1 BTC, however it's not immediately clear if
>> it's safe to send to him without waiting $n transactions. However even
>> for a small $n, this breaks my promise to pay him immediately.
>>
>> One possible solution is to only consider a transaction "replaceable" if
>> it has change, so if the original transaction confirms -- payments can
>> immediately be made that source the change, and provide safety in a reorg.
>>
>> However, this will only work <50% of the time for me (most transactions
>> don't have change) and opens a pandora's box of complexity.
>>
>> There's a few other hacks you can do to make it work in a few more cases,
>> but nothing that is realistic to expect anyone to implement any time soon.
>>
>> However, if there was a straight foward way to merge N unconfirmed
>> transactions, it would be easy get into production, and potentially offer
>> some pretty nice savings for everyone.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/8273b051/attachment.html>;