Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

As you point out, depending on the mempool, sometimes a miner makes more fee by including A and B, while other times a miner makes more fee by including C (the replacement for A and B) and D (a hypothetical transaction that cannot be fit into a block that contains A and B but can be fit into a

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

I don't think this is a realistic concern. The incentive compatibility _already_ exists (just in reverse: miners are refusing transactions that would increase their total fees in the next block), and as the mempool is already generally competitive enough it's actually worse the way it is. But

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev wrote: > Peter Todd wrote: > > In fact I considered only requiring an increase in fee rate, based on the > > theory that if absolute fee went down, the transaction must be smaller and > > thus > > miners could overall earn

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

I can see how merging after the fact could be more practical than appending existing transactions. I think what Moral Agent suggested is the same as your original proposal, namely dropping rule 3. Only fee per weight unit increase from rule 4 would matter. The minimum per WU increase could be

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

>I'm confused, the mempool only sees 1 transaction at a time, first A, then >later B. "the original transactions", plural, should not exist in the mempool. > >B's fee and rate needs to be larger than A's, but B will be greater than or >equal to A anyway. So, just increasing the fee rate will

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

So, OP, in your scenario, you have 1 transaction in the mempool, A, then you want to spend the change before confirmation, so you broadcast a new transaction, B, which replaces A. > Because the size of the merged transaction is smaller than the original transactions, unless there is a

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Tue, Jan 23, 2018 at 10:49:34PM +, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev > wrote: > > Interesting. I didn't think about this before, but it seems like bip125 is > > rather incentive

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Tue, Jan 23, 2018 at 09:31:00PM +, Gregory Maxwell wrote: > On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev > wrote: > > Most transactions don't have change?! Under what circumstance? For most > > use-cases the reverse is true: almost all

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> 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:

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev wrote: > Interesting. I didn't think about this before, but it seems like bip125 is > rather incentive incompatible right now? If we're assuming a competitive > mempool, it really doesn't seem

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

Interesting. I didn't think about this before, but it seems like bip125 is rather incentive incompatible right now? If we're assuming a competitive mempool, it really doesn't seem generally rational to accept a replacement transaction of a lower fee rate. So how about if we change the fee

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

Another way to limit abuse would be to have the fee *rate* be required to increase, which is kind of the spirit of RBF, applied to this situation. That is to say, if you wished to replace transactions A and B with C which spends the same inputs as A and B, then the following must be true before C

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev wrote: > Most transactions don't have change?! Under what circumstance? For most > use-cases the reverse is true: almost all all transactions have change, > because > it's rare for the inputs to

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

Getting back on topic: > It would definitely introduce DoS vectors by making it much cheaper to use > relay bandwidth. I think I'm missing something, as I don't really understand this DoS vector. Relay bandwidth is already very cheap and easy to use by repeatedly fee bumping. And it's not

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> Most transactions don't have change?! Under what circumstance? For most > use-cases the reverse is true: almost all all transactions have change, > because > it's rare for the inputs to exactly math the requested payment. It's actually a common misconception. With good coin selection, I am

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev 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

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> 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

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

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

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> 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 <

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

> 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

[bitcoin-dev] Transaction Merging (bip125 relaxation)

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