public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
@ 2018-01-23 23:31 Adam Ficsor
  0 siblings, 0 replies; 21+ messages in thread
From: Adam Ficsor @ 2018-01-23 23:31 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

> It's quite easy to get no change with a not-dumb algorithm selecting
coins if you have a decent number of outputs well under the value
you're paying.

I have been playing around quite a lot these lines, too and created some
content that is worth to look at:
https://github.com/nopara73/ZeroLink/#coin-selection
Also, you can try a simpler privacy oriented coin control implementation
with HiddenWallet:
https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2

-- 
Best,
Ádám

[-- Attachment #2: Type: text/html, Size: 1156 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread
* [bitcoin-dev] Transaction Merging (bip125 relaxation)
@ 2018-01-22 17:40 Rhavar
  2018-01-22 18:16 ` Alan Evans
  2018-01-22 20:00 ` Peter Todd
  0 siblings, 2 replies; 21+ messages in thread
From: Rhavar @ 2018-01-22 17:40 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2903 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2018-01-28 18:08 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-23 23:31 [bitcoin-dev] Transaction Merging (bip125 relaxation) Adam Ficsor
  -- strict thread matches above, loose matches on Subject: below --
2018-01-22 17:40 Rhavar
2018-01-22 18:16 ` Alan Evans
2018-01-22 18:18   ` Rhavar
2018-01-22 18:50     ` Moral Agent
2018-01-22 18:59       ` Rhavar
2018-01-22 20:00 ` Peter Todd
2018-01-22 20:09   ` Rhavar
2018-01-23 16:31   ` Rhavar
2018-01-23 21:56     ` Moral Agent
2018-01-23 22:19       ` Rhavar
2018-01-23 22:49         ` Gregory Maxwell
2018-01-24  7:44           ` Peter Todd
2018-01-24 13:43             ` Alan Evans
2018-01-24 16:05               ` Rhavar
2018-01-28 16:43                 ` Sjors Provoost
2018-01-28 17:29                   ` David A. Harding
2018-01-28 17:58                     ` Rhavar
2018-01-28 18:08                     ` Moral Agent
2018-01-23 21:31   ` Gregory Maxwell
2018-01-24  7:28     ` Peter Todd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox