Rhavar [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-22 📝 Original message:> Perhaps they could even ...
📅 Original date posted:2018-01-22
📝 Original message:> Perhaps they could even replace old tx with economically equivalent summary transactions?
I imagine with schnorr signatures, the incentives will emerge for that to make sense. But right now if I want to merge my transaction with an untrusted party in general we're only really going to be saving like 12 bytes of overhead or something. But if I'm merging my own transactions, I can get that fixed overhead, strip extraneous inputs and merge my change outputs (which also means in the future it's cheaper to spend).
Although it's obviously a lot worse for privacy, I do like the pattern of broadcast the transaction standalone and then merge it for savings. It helps keep the more or less fire-and-forget style, without a ridiculous amount of complexity "if this happens, do this, if this, then this, ..."
-Ryan
-Ryan
-------- Original Message --------
On January 22, 2018 1:50 PM, Moral Agent <ethan.scruples at gmail.com> wrote:
> 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/074be1a4/attachment.html>;
📝 Original message:> Perhaps they could even replace old tx with economically equivalent summary transactions?
I imagine with schnorr signatures, the incentives will emerge for that to make sense. But right now if I want to merge my transaction with an untrusted party in general we're only really going to be saving like 12 bytes of overhead or something. But if I'm merging my own transactions, I can get that fixed overhead, strip extraneous inputs and merge my change outputs (which also means in the future it's cheaper to spend).
Although it's obviously a lot worse for privacy, I do like the pattern of broadcast the transaction standalone and then merge it for savings. It helps keep the more or less fire-and-forget style, without a ridiculous amount of complexity "if this happens, do this, if this, then this, ..."
-Ryan
-Ryan
-------- Original Message --------
On January 22, 2018 1:50 PM, Moral Agent <ethan.scruples at gmail.com> wrote:
> 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/074be1a4/attachment.html>;