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
bloc
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 I
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 mo
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
>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 cau
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 considerable
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 incompatible right now? If we're assuming a compe
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 all transactions have change,
> > becau
> 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/#c
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 generally rational to accept a replacement
> tra
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 requi
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
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 exactly math the requested payment.
It's
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 obvio
> 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 able
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 r
> 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 sa
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 accum
> 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@
> 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
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
21 matches
Mail list logo
