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