Re: [Bitcoin-development] Version bits proposal

[Jorge Timón]

It would also help to see the actual code changes required, which I'm sure
will be much shorter than the explanation itself.
On May 27, 2015 5:47 AM, "Luke Dashjr"  wrote:

> On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
> > Feel free to comment. As the gist does not support notifying participants
> > of new comments, I would suggest using the mailing list instead.
>
> I suggest adding a section describing how this interacts with and changes
> GBT.
>
> Currently, the client tells the server what the highest block version it
> supports is, and the server indicates a block version to use in its
> template,
> as well as optional instructions for the client to forcefully use this
> version
> despite its own maximum version number. Making the version a bitfield
> contradicts the increment-only assumption of this design, and since GBT
> clients are not aware of overall network consensus state, reused bits can
> easily become confused. I suggest, therefore, that GBT clients should
> indicate
> (instead of a maximum supported version number) a list of softforks by
> identifier keyword, and the GBT server respond with a template indicating:
> - An object of softfork keywords to bit values, that the server will
> accept.
> - The version number, as presently conveyed, indicating the preferred
> softfork
> flags.
>
> Does this sound reasonable, and/or am I missing anything else?
>
> Luke
>
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version bits proposal

[Luke Dashjr]

On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
> Feel free to comment. As the gist does not support notifying participants
> of new comments, I would suggest using the mailing list instead.

I suggest adding a section describing how this interacts with and changes GBT.

Currently, the client tells the server what the highest block version it 
supports is, and the server indicates a block version to use in its template, 
as well as optional instructions for the client to forcefully use this version 
despite its own maximum version number. Making the version a bitfield 
contradicts the increment-only assumption of this design, and since GBT 
clients are not aware of overall network consensus state, reused bits can 
easily become confused. I suggest, therefore, that GBT clients should indicate 
(instead of a maximum supported version number) a list of softforks by 
identifier keyword, and the GBT server respond with a template indicating:
- An object of softfork keywords to bit values, that the server will accept.
- The version number, as presently conveyed, indicating the preferred softfork 
flags.

Does this sound reasonable, and/or am I missing anything else?

Luke

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version bits proposal

[Douglas Roark]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2015/5/26 21:48, Pieter Wuille wrote:
> here is a proposal for how to coordinate future soft-forking
> consensus changes:
> https://gist.github.com/sipa/bf69659f43e763540550
> 
> It supports multiple parallel changes, as well as changes that get 
> permanently rejected without obstructing the rollout of others.
> 
> Feel free to comment. As the gist does not support notifying 
> participants of new comments, I would suggest using the mailing
> list instead.

Hi Pieter. Thanks for posting the proposal. I think the concept itself
is pretty solid. I know some people have been proposing alternate
methods too. I hope they'll share here, assuming they haven't already.
As is, my comments concern typos and general copy editing.

- - Just speaking in general, I found the BIP to be a bit hard to read.
AFAIK, the basic facts are accurate. I just found myself having to
re-read certain passages two or three times. A little polish wouldn't
hurt. For example, using the "it" pronoun can be confusing, such as
multiple uses in the abstract. Specifying what "it" is (e.g., "The
proposed change relies on...") would really help. In addition, the way
the "W" value is handled seems like it could be improved a bit. I know
the wording is accurate. Seeing 1000 change to 1001 is still a little
weird.
- - In "Multi-stage soft forks," I presume the second sentence should
end as follows: "[...] with additional validation rules that get
enabled one by _one_." Depending on semantics, I'd consider changing
"one by one" to "incremental steps," but that's your call.
- - I found the "High bits" section to be confusing at first. It looks
like you chose to show everything as little endian data, matching
what's actually in the block. My personal preference would be to
represent the data, for readability purposes, as big endian. I doubt
I'm the only one who finds big endian to be much easier to process
mentally.
- - Some sort of legend showing A, I, W, etc. would really help, as
opposed to just running into them as one goes along. Otherwise, the
alphabet soup can be a bit confusing.

Thanks again.

- -- 
- ---
Douglas Roark
Senior Developer
Armory Technologies, Inc.
d...@bitcoinarmory.com
PGP key ID: 92ADC0D7
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVZSx5AAoJEGybVGGSrcDXrYEQAOIrsggoZv0LdJHZjPGpEkeb
7ULhO4krZtQmKXjWDP0KnHAsFiyo5EOh1fYFRZz11OCqO4QmteTLPbodZFz47tKp
tIYv5uc0qYhjfo5uLkzxuUky08VE4dUoELfqdbNciC45xHras7Wh/+KXc1a20Fib
TaisWx9aL6VfPf7urM8b6mQ9XMba4YB3e2syAY8AA+qAEEP4DK2V6tuOQJD3kxP2
tbHtJnDvkDoXEY6tnL7fePo9X/IrlXLi8vNWGqPIf/hoiHmdvU+ORwHta7z9YeIO
zi4LRs8n8sYmifY4nt6Wkkc1aoPsmpoXmI3tKgFM2h5bfdg0n3fN3K0nTMWtnR6z
HUq8JhrQkZUP8uunN/23bt94FZolvnHTdL9YuWoyrlJ0gQri5YxV1BAN4hM9oCZy
1SqlSmFRplIFWu45q8/I5duDSphmA4NP2qc59QRjftcGYpNxmzaeSViiCDWzAjI9
qTLZgLTa/nf3TFN8oU8RwquGpwD82/fFo9V+uKdNGj79kdV8WOv4sa9q63OTVimJ
w+r4l1gDZYyToe0heKtV2kL9Tt4HTn23bj7EvU+98uaKEpfWSP8a3BN9mPR7ork/
lNRGEGQ0tvkeDUzKy9IHuAjXo2XkKctbBRJwZJCGc5WW2sN0HdSu/GFPXrOOLf0J
JXqeKpfaS0UriFXkxVHO
=8uNL
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mark Friedenbach]

Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign successive versions of a transaction, each time incrementing the
sequence field by some amount. Relay nodes perform transaction replacement
according to some policy rule making use of the sequence numbers, e.g.
requiring sequence numbers in a replacement to be monotonically increasing.

As it happens, this cannot be made safe in the bitcoin protocol as deployed
today, as there is no enforcement of the rule that miners include the most
recent transaction in their blocks. As such, any protocol relying on a
transaction replacement policy can be defeated by miners choosing not to
follow that policy, which they may even be incentivised to do so (if older
transactions provide higher fee per byte, for example). Transaction
replacement is presently disabled in Bitcoin Core.

These shortcomings can be fixed in an elegant way by giving sequence
numbers new consensus-enforced semantics as a relative lock-time: if a
sequence number is non-final (MAX_INT), its bitwise inverse is interpreted
as either a relative height or time delta which is added to the height or
median time of the block containing the output being spent to form a
per-input lock-time. The lock-time of each input constructed in this manor,
plus the nLockTime of the transaction itself if any input is non-final must
be satisfied for a transaction to be valid.

For example, a transaction with an txin.nSequence set to 0xff9b [==
~(uint32_t)100] is prevented by consensus rule from being selected for
inclusion in a block until the 100th block following the one including the
parent transaction referenced by that input.

In this way one may construct, for example, a bidirectional micropayment
channel where each change of direction increments sequence numbers to make
the transaction become valid prior to any of the previously exchanged
transactions.

This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be
implemented in the same way: by checking transaction data only and not
requiring contextual information like the block height or timestamp.

An example implementation of this concept, as a policy change to the
mempool processing of Bitcoin Core is available on github:

https://github.com/maaku/bitcoin/tree/sequencenumbers
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Version bits proposal

[Pieter Wuille]

Hello everyone,

here is a proposal for how to coordinate future soft-forking consensus
changes: https://gist.github.com/sipa/bf69659f43e763540550

It supports multiple parallel changes, as well as changes that get
permanently rejected without obstructing the rollout of others.

Feel free to comment. As the gist does not support notifying participants
of new comments, I would suggest using the mailing list instead.

This is joint work with Peter Todd and Greg Maxwell.

-- 
Pieter
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Peter Todd]

On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote:
> What is wrong with the man testing some ideas on his custom branch? This
> is how improvements come to life. I saw in the BIPs some really
> interesting ideas and nice brainstorming which came from Peter Todd.
> 
> Now, my question, if replace by fee doesn't allow me to change the
> inputs or the outputs, I can only add outputs... what can I do with this
> feature? If I sent a tx and want to replace it with a higher fee one,
> the higher fee one can only have maybe additional change addresses or
> another payment, if the inputs suffice? Do we have any real use cases?

You're a bit mistaken there: standard RBF lets you change anything, and
FSS RBF lets you modify inputs and add outputs and/or make the value of
outputs higher.

> P.S. is it planned to include this by default in bitcoin core 10.0.3 or
> it will remain just on Peter's branch?

Any significant change to mempool policy like RBF is very unlikely to be
incorporated in the Bitcoin Core v0.10.x branch, simply because it'd be
too large a change for a minor, mostly bugfix, release.

Having said that, I already maintain a standard RBF branch for v0.10.x,
and have been asked by a major minor to backport FSS RBF for v0.10.x as
well.

-- 
'peter'[:-1]@petertodd.org
0b9e6c1ce35e6e06c01b1f381840bcd9297f307cb1e6aae8


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Tom Harding]

On 5/26/2015 4:11 PM, Gregory Maxwell wrote:
> On Tue, May 26, 2015 at 11:00 PM, Tom Harding  wrote:
>> The bitcoin transaction is part of a real-world "deal" with unknown
>> connections to the other parts
> I'm having a hard time parsing this.  You might as well say that its
> part of a weeblix for how informative it is, since you've not defined
> it.

For example, you are paying for concert tickets.  The deal is concert 
tickets for bitcoin.  Or you're buying a company with 3 other investors.


>> not the case if paying parties are kicked out of the deal, and possibly
>> don't learn about it right away.
> The signatures of a transaction can always be changed any any time,
> including by the miner, as they're not signed.

Miners can't update the signature on input #0 after removing input #1.


>
>> A subset of parties to an Armory simulfunding transaction (an actual
>> multi-input use case) could replace one signer's input after they broadcast
>> it.
> They can already do this.

Replacement is about how difficult it is to change the tx after it is 
broadcast and seen by observers.


>> Maybe the
>> receiver cares where he is paid from or is basing a subsequent decision on
>> it.  Maybe a new output is being added, whose presence makes the transaction
>> less likely to be confirmed quickly, with that speed affecting the business.
> The RBF behavior always moves in the direction of more prefered or
> otherwise the node would not switch to the replacement. Petertodd
> should perhaps make that more clear.
>
> But your "maybe"s are what I was asking you to clarify. You said it
> wasn't hard to imagine; so I was asking for specific clarification.

Pick any one "maybe".  They're only maybes because it's not realistic 
for them all to happen at once.


>
>> With Kalle's Proof of Payment proposed standard, one payer in a two-input
>> transaction could decide to boot the other, and claim the concert tickets
>> all for himself.  The fact that he pays is not the only consideration in the
>> real world -- what if these are the last 2 tickets?
> They can already do that.

Not without replacement, after broadcast, unless they successfully pay 
twice.


>
>> I'd argue that changing how an input is signed doesn't change the deal.  For
>> example if a different 2 of 3 multisig participants sign, those 3 people
>> gave up that level of control when they created the multisig.
> Then why do you not argue that changing the input set does not change
> the weeblix?
>
> Why is one case of writing out a participant different that the other
> case of writing out a participant?

In the multisig input case, each signer already accepted the possibility 
of being written out.  Peter Todd's proposal is in the spirit of not 
willfully making unconfirmed txes less reliable.  I'm suggesting that 
multi-input signers should be included in the set of people for whom 
they don't get less reliable.


>
>> Replacement is new - we have a choice what kind of warnings we need to give
>> to signers of multi-input transactions.  IMHO we should avoid needing a
>> stronger warning than is already needed for 0-conf.
> How could a _stronger_ warning be required?

We'd have to warn signers to multi-input txes instead of just warning 
receivers.


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Gregory Maxwell]

On Tue, May 26, 2015 at 11:00 PM, Tom Harding  wrote:
> The bitcoin transaction is part of a real-world "deal" with unknown
> connections to the other parts

I'm having a hard time parsing this.  You might as well say that its
part of a weeblix for how informative it is, since you've not defined
it.

> not the case if paying parties are kicked out of the deal, and possibly
> don't learn about it right away.

The signatures of a transaction can always be changed any any time,
including by the miner, as they're not signed.

> A subset of parties to an Armory simulfunding transaction (an actual
> multi-input use case) could replace one signer's input after they broadcast
> it.

They can already do this.

> Maybe the
> receiver cares where he is paid from or is basing a subsequent decision on
> it.  Maybe a new output is being added, whose presence makes the transaction
> less likely to be confirmed quickly, with that speed affecting the business.

The RBF behavior always moves in the direction of more prefered or
otherwise the node would not switch to the replacement. Petertodd
should perhaps make that more clear.

But your "maybe"s are what I was asking you to clarify. You said it
wasn't hard to imagine; so I was asking for specific clarification.

> With Kalle's Proof of Payment proposed standard, one payer in a two-input
> transaction could decide to boot the other, and claim the concert tickets
> all for himself.  The fact that he pays is not the only consideration in the
> real world -- what if these are the last 2 tickets?

They can already do that.

> I'd argue that changing how an input is signed doesn't change the deal.  For
> example if a different 2 of 3 multisig participants sign, those 3 people
> gave up that level of control when they created the multisig.

Then why do you not argue that changing the input set does not change
the weeblix?

Why is one case of writing out a participant different that the other
case of writing out a participant?

> Replacement is new - we have a choice what kind of warnings we need to give
> to signers of multi-input transactions.  IMHO we should avoid needing a
> stronger warning than is already needed for 0-conf.

How could a _stronger_ warning be required?

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Tom Harding]

On 5/26/2015 12:10 PM, Gregory Maxwell wrote:
> On Tue, May 26, 2015 at 5:54 PM, Tom Harding  wrote:
>>   It's not difficult to
>> imagine real-world consequences to not having contributed to the
>> transaction.
> I'm having a hard time. Can you help me understand a specific case
> where this makes a difference.
>

The bitcoin transaction is part of a real-world "deal" with unknown 
connections to the other parts.  New inputs combined with new or 
increased outputs can be thought of as a second deal sharing the same 
envelope. That's not the case if paying parties are kicked out of the 
deal, and possibly don't learn about it right away.

A subset of parties to an Armory simulfunding transaction (an actual 
multi-input use case) could replace one signer's input after they 
broadcast it.  Whether that's a problem depends on real-world 
connections.  Maybe the receiver cares where he is paid from or is 
basing a subsequent decision on it.  Maybe a new output is being added, 
whose presence makes the transaction less likely to be confirmed 
quickly, with that speed affecting the business.

With Kalle's Proof of Payment proposed standard, one payer in a 
two-input transaction could decide to boot the other, and claim the 
concert tickets all for himself.  The fact that he pays is not the only 
consideration in the real world -- what if these are the last 2 tickets?

Mempool policy shouldn't help one payer make a unilateral decision to 
become the sole party to a deal after various parties have seen it 
broadcast.


> The inherent malleability of signatures makes it unreliable to depend
> on the signature content of a transaction until its good and buried,
> regardless.

I'd argue that changing how an input is signed doesn't change the deal.  
For example if a different 2 of 3 multisig participants sign, those 3 
people gave up that level of control when they created the multisig.

Replacement is new - we have a choice what kind of warnings we need to 
give to signers of multi-input transactions.  IMHO we should avoid 
needing a stronger warning than is already needed for 0-conf.



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Jeff Garzik]

That attitude and doxxing is not appropriate for this list.


On Tue, May 26, 2015 at 4:30 PM,  wrote:

> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
> and you have big banks as clients. Shit like replace-by-fee and leading
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
> 
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Adam Back]

I think the point is the replacement tx spends the same inputs (plus
additional inputs), so if the original tx is accepted, and your
replacement rejected, thats good news - you dont have to pay the
higher fee, the extra input remains unspent (and can be used later for
other purpose) and the extra change address is unused.

(If you had bundled extra transactions into the replacement, spending
from the additional inputs, then you'll need to resubmit those as a
separate transaction).

(You have to keep in mind re-orgs so for example the original tx could
be put into a block, and then that block could get reorged by another
block that grows into a longer chain with the replacement tx in it (or
vice versa)).

Adam

On 26 May 2015 at 23:09, Danny Thorpe  wrote:
> Thanks for the clarification.
>
> So, since RBF applies only to pending transactions in the mempool awaiting
> incorporation into a block, there is a window of opportunity in which the
> pending tx is incorporated into a block at the same time that the spender is
> constructing and publishing a replacement for that pending tx.
>
> The replacement transaction would be rejected by the peer network as a
> double spend because it conflicts with the now confirmed original tx, and
> the spender will have to go back and create a new stand-alone transaction to
> accomplish what they hoped to do with an RBF replacement.
>
> So an implementation that wishes to take advantage of RBF will still need to
> have a "plan B" implementation path to handle the corner case of a
> replacement tx being rejected as a double spend.
>
> Is this correct?
>
> I'm just trying to get my head around the implementation cost vs benefit of
> RBF in the context of my applications.
>
> Thanks,
> -Danny
>
> On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille 
> wrote:
>>
>> It's just a mempool policy rule.
>>
>> Allowing the contents of blocks to change (other than by mining a
>> competing chain) would be pretty much the largest possible change to
>> Bitcoin's design
>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Danny Thorpe]

Thanks for the clarification.

So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender
is constructing and publishing a replacement for that pending tx.

The replacement transaction would be rejected by the peer network as a
double spend because it conflicts with the now confirmed original tx, and
the spender will have to go back and create a new stand-alone transaction
to accomplish what they hoped to do with an RBF replacement.

So an implementation that wishes to take advantage of RBF will still need
to have a "plan B" implementation path to handle the corner case of a
replacement tx being rejected as a double spend.

Is this correct?

I'm just trying to get my head around the implementation cost vs benefit of
RBF in the context of my applications.

Thanks,
-Danny

On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille 
wrote:

> It's just a mempool policy rule.
>
> Allowing the contents of blocks to change (other than by mining a
> competing chain) would be pretty much the largest possible change to
> Bitcoin's design
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Adam Back]

Well so for example it could have an additional input (to increase the
BTC paid into the transaction) and pay more to an existing change
address and higher fee, or add an additional change address, and leave
a larger fee, or if you had a right-sized coin add an additional input
that all goes to fees.

(As well as optionally tacking on additional pending payments to other
addresses funded from the higher input).

Adam

On 26 May 2015 at 22:29, s7r  wrote:
> What is wrong with the man testing some ideas on his custom branch? This
> is how improvements come to life. I saw in the BIPs some really
> interesting ideas and nice brainstorming which came from Peter Todd.
>
> Now, my question, if replace by fee doesn't allow me to change the
> inputs or the outputs, I can only add outputs... what can I do with this
> feature? If I sent a tx and want to replace it with a higher fee one,
> the higher fee one can only have maybe additional change addresses or
> another payment, if the inputs suffice? Do we have any real use cases?
>
> P.S. is it planned to include this by default in bitcoin core 10.0.3 or
> it will remain just on Peter's branch?
>
> On 5/26/2015 11:30 PM, joli...@airmail.cc wrote:
>> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
>> and you have big banks as clients. Shit like replace-by-fee and leading
>> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
>>
>> Peter Todd - 8930511 Canada Ltd.
>> 1214-1423 Mississauga Valley Blvd.
>> Mississauga ON L5A 4A5
>> Canada
>>
>> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
>>
>> On 2015-05-26 00:10, Peter Todd wrote:
>>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
 CPFP also solves it just fine.
>>>
>>> CPFP is a significantly more expensive way of paying fees than RBF,
>>> particularly for the use-case of defragmenting outputs, with cost
>>> savings ranging from 30% to 90%
>>>
>>>
>>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>>> --
>>>
>>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>>> bytes of txin, 182 bytes total.
>>>
>>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in
>>> size.
>>> I forget to click on the "priority fee" option, so it goes out with the
>>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>>> transaction fees.
>>>
>>> On the other hand, had I use RBF, my wallet would have simply
>>> rebroadcast t1 with the change address decreased. The rules require you
>>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the
>>> new
>>> fee level, or 218uBTC of fees in total.
>>>
>>> Cost savings: 48%
>>>
>>>
>>> Case 2: Paying multiple recipients in succession
>>> 
>>>
>>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>>> work demonstrating cryptographic protocols. I need to create a new
>>> transaction t2 spending t1's change address. Normally t2 would be
>>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>>
>>> With RBF on the other hand I can simply double-spend t1 with a
>>> transaction paying both Alice and Bob. This new transaction is 260
>>> bytes
>>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>>
>>> Cost savings: 84%
>>>
>>>
>>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>>> 
>>>
>>> The above situation gets even worse with multisig. t1 in the multisig
>>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>>> a 399 byte transaction, with just 36uBTC in additional fees.
>>>
>>> Cost savings: 90%
>>>
>>>
>>> Case 4: Dust defragmentation
>>> 
>>>
>>> My wallet has a two transaction outputs that it wants to combine into
>>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>>
>>> Prior to the transaction confirming I find I need to spend those funds
>>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>>> to pay fees for both transactions at once, resulting in a combined
>>> total
>>> fee of 556uBTC. If this situation happens frequently, defragmenting
>>> UTXOs is likely to cost more in additional fees than it saves.
>>>
>>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>>> b

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[s7r]

What is wrong with the man testing some ideas on his custom branch? This
is how improvements come to life. I saw in the BIPs some really
interesting ideas and nice brainstorming which came from Peter Todd.

Now, my question, if replace by fee doesn't allow me to change the
inputs or the outputs, I can only add outputs... what can I do with this
feature? If I sent a tx and want to replace it with a higher fee one,
the higher fee one can only have maybe additional change addresses or
another payment, if the inputs suffice? Do we have any real use cases?

P.S. is it planned to include this by default in bitcoin core 10.0.3 or
it will remain just on Peter's branch?

On 5/26/2015 11:30 PM, joli...@airmail.cc wrote:
> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks 
> and you have big banks as clients. Shit like replace-by-fee and leading 
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
> 
> Peter Todd - 8930511 Canada Ltd.
> 1214-1423 Mississauga Valley Blvd.
> Mississauga ON L5A 4A5
> Canada
> 
> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
> 
> On 2015-05-26 00:10, Peter Todd wrote:
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>>> CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> --
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in 
>> size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the 
>> new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> 
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260 
>> bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> 
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> 
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined 
>> total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>>   costs you more than you save
>>
>> --
>> One dashboard for servers and applications across 
>> Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance 

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Pieter Wuille]

It's just a mempool policy rule.

Allowing the contents of blocks to change (other than by mining a competing
chain) would be pretty much the largest possible change to Bitcoin's
design
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Danny Thorpe]

Apologies if this has already been stated and I missed it, but:

Can transactions in a buried block be overridden/replaced by RBF?

Or is RBF strictly limited to transactions that have not yet been
incorporated into a block?

Thanks,
-Danny

On Mon, May 25, 2015 at 10:13 PM, Peter Todd  wrote:

> Summary
> ---
>
> First-seen-safe replace-by-fee (FSS RBF) does the following:
>
> 1) Give users effective ways of getting "stuck" transactions unstuck.
> 2) Use blockchain space efficiently.
>
> without:
>
> 3) Changing the status quo with regard to zeroconf.
>
> The current Bitcoin Core implementation has "first-seen" mempool
> behavior. Once transaction t1 has been accepted, the transaction is
> never removed from the mempool until mined, or double-spent by a
> transaction in a block. The author's previously proposed replace-by-fee
> replaced this behavior with simply accepting the transaction paying the
> highest fee.
>
> FSS RBF is a compromise between these two behaviors. Transactions may be
> replaced by higher-fee paying transactions, provided that all outputs in
> the previous transaction are still paid by the replacement. While not as
> general as standard RBF, and with higher costs than standard RBF, this
> still allows fees on transaction to be increased after the fact with
> less cost and higher efficiency than child-pays-for-parent in many
> common situations; in some situations CPFP is unusable, leaving RBF as
> the only option.
>
>
> Semantics
> -
>
> For reference, standard replace-by-fee has the following criteria for
> determining whether to replace a transaction.
>
> 1) t2 pays > fees than t1
>
> 2) The delta fees pay by t2, t2.fee - t1.fee, are >= the minimum fee
>required to relay t2. (t2.size * min_fee_per_kb)
>
> 3) t2 pays more fees/kb than t1
>
> FSS RBF adds the following additional criteria to replace-by-fee before
> allowing a transaction t1 to be replaced with t2:
>
> 1) All outputs of t1 exist in t2 and pay >= the value in t1.
>
> 2) All outputs of t1 are unspent.
>
> 3) The order of outputs in t2 is the same as in t1 with additional new
>outputs at the end of the output list.
>
> 4) t2 only conflicts with a single transaction, t1
>
> 5) t2 does not spend any outputs of t1 (which would make it an invalid
>transaction, impossible to mine)
>
> These additional criteria respect the existing "first-seen" behavior of
> the Bitcoin Core mempool implementation, such that once an address is
> payed some amount of BTC, all subsequent replacement transactions will
> pay an equal or greater amount. In short, FSS-RBF is "zeroconf safe" and
> has no affect on the ability of attackers to doublespend. (beyond of
> course the fact that any changes what-so-ever to mempool behavior are
> potential zeroconf doublespend vulnerabilities)
>
>
> Implementation
> --
>
> Pull-req for git HEAD: https://github.com/bitcoin/bitcoin/pull/6176
>
> A backport to v0.10.2 is pending.
>
> An implementation of fee bumping respecting FSS rules is available at:
>
> https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py
>
>
> Usage Scenarios
> ---
>
> Case 1: Increasing the fee on a single tx
> -
>
> We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
> with the minimal relay fee, 2.26uBTC. Increasing the fee while
> respecting FSS-RBF rules requires the addition of one more txin, with
> the change output value increased appropriately, resulting in
> transaction t2, size 374 bytes. If the change txout is sufficient for
> the fee increase, increasing the fee via CPFP requires a second
> 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another
> input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total
> of 566 bytes.
>
> Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in
>   cases where the original transaction didn't have a change
>   output.
>
>
> Case 2: Paying multiple recipients in succession
> 
>
> We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice.
> We now need to pay Bob. With plain RBF we'd just add a new outptu and
> reduce the value of the change address, a 90% savings. However with FSS
> RBF, decreasing the value is not allowed, so we have to add an input.
>
> If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can
> be created, 2*226=452 bytes in total. With FSS RBF we can replace t1
> with a 2-in-3-out tx paying both, increasing the value of the change
> output appropriately, resulting in 408 bytes transaction saving 10%
>
> Similar to the above example in the case where the change address of t1
> is insufficient to pay Bob the end result is one less transaction output
> in the wallet, defragmenting it. Spending these outputs later on would
> require two 148 byte inputs compared to one with RBF, resulting in an
> overall savings of 25%

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Mark Friedenbach]

Please let's at least have some civility and decorum on this list.

On Tue, May 26, 2015 at 1:30 PM,  wrote:

> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
> and you have big banks as clients. Shit like replace-by-fee and leading
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
>
> Peter Todd - 8930511 Canada Ltd.
> 1214-1423 Mississauga Valley Blvd.
> Mississauga ON L5A 4A5
> Canada
>
>
> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
>
> On 2015-05-26 00:10, Peter Todd wrote:
> > On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
> >> CPFP also solves it just fine.
> >
> > CPFP is a significantly more expensive way of paying fees than RBF,
> > particularly for the use-case of defragmenting outputs, with cost
> > savings ranging from 30% to 90%
> >
> >
> > Case 1: CPFP vs. RBF for increasing the fee on a single tx
> > --
> >
> > Creating an spending a P2PKH output uses 34 bytes of txout, and 148
> > bytes of txin, 182 bytes total.
> >
> > Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
> > Alice. This results in a 1in/2out transaction t1 that's 226 bytes in
> > size.
> > I forget to click on the "priority fee" option, so it goes out with the
> > minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
> > creating a new transaction t2 that's 192 bytes in size. I want to pay
> > 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
> > transaction fees.
> >
> > On the other hand, had I use RBF, my wallet would have simply
> > rebroadcast t1 with the change address decreased. The rules require you
> > to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the
> > new
> > fee level, or 218uBTC of fees in total.
> >
> > Cost savings: 48%
> >
> >
> > Case 2: Paying multiple recipients in succession
> > 
> >
> > Suppose that after I pay Alice, I also decide to pay Bob for his hard
> > work demonstrating cryptographic protocols. I need to create a new
> > transaction t2 spending t1's change address. Normally t2 would be
> > another 226 bytes in size, resulting in 226uBTC additional fees.
> >
> > With RBF on the other hand I can simply double-spend t1 with a
> > transaction paying both Alice and Bob. This new transaction is 260
> > bytes
> > in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
> > consumed broadcasting it, resulting in an additional 36uBTC of fees.
> >
> > Cost savings: 84%
> >
> >
> > Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
> > 
> >
> > The above situation gets even worse with multisig. t1 in the multisig
> > case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
> > in fees. With RBF we rewrite t1 with an additional output, resulting in
> > a 399 byte transaction, with just 36uBTC in additional fees.
> >
> > Cost savings: 90%
> >
> >
> > Case 4: Dust defragmentation
> > 
> >
> > My wallet has a two transaction outputs that it wants to combine into
> > one for the purpose of UTXO defragmentation. It broadcasts transaction
> > t1 with two inputs and one output, size 340 bytes, paying zero fees.
> >
> > Prior to the transaction confirming I find I need to spend those funds
> > for a priority transaction at the 1mBTC/KB fee level. This transaction,
> > t2a, has one input and two outputs, 226 bytes in size. However it needs
> > to pay fees for both transactions at once, resulting in a combined
> > total
> > fee of 556uBTC. If this situation happens frequently, defragmenting
> > UTXOs is likely to cost more in additional fees than it saves.
> >
> > With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
> > bytes in size, paying 374uBTC. Even better, if one of the two inputs is
> > sufficiently large to cover my costs I can doublespend t1 with a
> > 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
> >
> > Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
> >   costs you more than you save
> >
> >
> --
> > One dashboard for servers and applications across
> > Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable
> > Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> ___

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[joliver]

You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks 
and you have big banks as clients. Shit like replace-by-fee and leading 
the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.

Peter Todd - 8930511 Canada Ltd.
1214-1423 Mississauga Valley Blvd.
Mississauga ON L5A 4A5
Canada

https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511

On 2015-05-26 00:10, Peter Todd wrote:
> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>> CPFP also solves it just fine.
> 
> CPFP is a significantly more expensive way of paying fees than RBF,
> particularly for the use-case of defragmenting outputs, with cost
> savings ranging from 30% to 90%
> 
> 
> Case 1: CPFP vs. RBF for increasing the fee on a single tx
> --
> 
> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
> bytes of txin, 182 bytes total.
> 
> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in 
> size.
> I forget to click on the "priority fee" option, so it goes out with the
> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
> creating a new transaction t2 that's 192 bytes in size. I want to pay
> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
> transaction fees.
> 
> On the other hand, had I use RBF, my wallet would have simply
> rebroadcast t1 with the change address decreased. The rules require you
> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the 
> new
> fee level, or 218uBTC of fees in total.
> 
> Cost savings: 48%
> 
> 
> Case 2: Paying multiple recipients in succession
> 
> 
> Suppose that after I pay Alice, I also decide to pay Bob for his hard
> work demonstrating cryptographic protocols. I need to create a new
> transaction t2 spending t1's change address. Normally t2 would be
> another 226 bytes in size, resulting in 226uBTC additional fees.
> 
> With RBF on the other hand I can simply double-spend t1 with a
> transaction paying both Alice and Bob. This new transaction is 260 
> bytes
> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
> consumed broadcasting it, resulting in an additional 36uBTC of fees.
> 
> Cost savings: 84%
> 
> 
> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
> 
> 
> The above situation gets even worse with multisig. t1 in the multisig
> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
> in fees. With RBF we rewrite t1 with an additional output, resulting in
> a 399 byte transaction, with just 36uBTC in additional fees.
> 
> Cost savings: 90%
> 
> 
> Case 4: Dust defragmentation
> 
> 
> My wallet has a two transaction outputs that it wants to combine into
> one for the purpose of UTXO defragmentation. It broadcasts transaction
> t1 with two inputs and one output, size 340 bytes, paying zero fees.
> 
> Prior to the transaction confirming I find I need to spend those funds
> for a priority transaction at the 1mBTC/KB fee level. This transaction,
> t2a, has one input and two outputs, 226 bytes in size. However it needs
> to pay fees for both transactions at once, resulting in a combined 
> total
> fee of 556uBTC. If this situation happens frequently, defragmenting
> UTXOs is likely to cost more in additional fees than it saves.
> 
> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
> sufficiently large to cover my costs I can doublespend t1 with a
> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
> 
> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>   costs you more than you save
> 
> --
> One dashboard for servers and applications across 
> Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable 
> Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Matt Whitlock]

On Tuesday, 26 May 2015, at 11:22 am, Danny Thorpe wrote:
> What prevents RBF from being used for fraudulent payment reversals?
> 
> Pay 1BTC to Alice for hard goods, then after you receive the goods
> broadcast a double spend of that transaction to pay Alice nothing? Your
> only cost is the higher network fee of the 2nd tx.

The "First-Seen-Safe" replace-by-fee presently being discussed on this list 
disallows fraudulent payment reversals, as it disallows a replacing transaction 
that pays less to any output script than the replaced transaction paid.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Allen Piscitello]

I am not the one presenting this as some kind of novel attack on
transactions in general.

On Tue, May 26, 2015 at 1:43 PM, Raystonn  wrote:

> Trust, regulation, law, and the threat of force.  Are you serious?
>  On 26 May 2015 11:38 am, Allen Piscitello 
> wrote:
>
> What prevents you from writing a bad check using today's systems?
>
> On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe 
> wrote:
>
> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods
> broadcast a double spend of that transaction to pay Alice nothing? Your
> only cost is the higher network fee of the 2nd tx.
>
> Thanks,
> -Danny
>
> On Mon, May 25, 2015 at 5:10 PM, Peter Todd  wrote:
>
> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
> > CPFP also solves it just fine.
>
> CPFP is a significantly more expensive way of paying fees than RBF,
> particularly for the use-case of defragmenting outputs, with cost
> savings ranging from 30% to 90%
>
>
> Case 1: CPFP vs. RBF for increasing the fee on a single tx
> --
>
> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
> bytes of txin, 182 bytes total.
>
> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
> I forget to click on the "priority fee" option, so it goes out with the
> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
> creating a new transaction t2 that's 192 bytes in size. I want to pay
> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
> transaction fees.
>
> On the other hand, had I use RBF, my wallet would have simply
> rebroadcast t1 with the change address decreased. The rules require you
> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
> fee level, or 218uBTC of fees in total.
>
> Cost savings: 48%
>
>
> Case 2: Paying multiple recipients in succession
> 
>
> Suppose that after I pay Alice, I also decide to pay Bob for his hard
> work demonstrating cryptographic protocols. I need to create a new
> transaction t2 spending t1's change address. Normally t2 would be
> another 226 bytes in size, resulting in 226uBTC additional fees.
>
> With RBF on the other hand I can simply double-spend t1 with a
> transaction paying both Alice and Bob. This new transaction is 260 bytes
> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>
> Cost savings: 84%
>
>
> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
> 
>
> The above situation gets even worse with multisig. t1 in the multisig
> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
> in fees. With RBF we rewrite t1 with an additional output, resulting in
> a 399 byte transaction, with just 36uBTC in additional fees.
>
> Cost savings: 90%
>
>
> Case 4: Dust defragmentation
> 
>
> My wallet has a two transaction outputs that it wants to combine into
> one for the purpose of UTXO defragmentation. It broadcasts transaction
> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>
> Prior to the transaction confirming I find I need to spend those funds
> for a priority transaction at the 1mBTC/KB fee level. This transaction,
> t2a, has one input and two outputs, 226 bytes in size. However it needs
> to pay fees for both transactions at once, resulting in a combined total
> fee of 556uBTC. If this situation happens frequently, defragmenting
> UTXOs is likely to cost more in additional fees than it saves.
>
> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
> sufficiently large to cover my costs I can doublespend t1 with a
> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>
> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>   costs you more than you save
>
> --
> 'peter'[:-1]@petertodd.org
> 134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> 

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Raystonn]

Trust, regulation, law, and the threat of force.  Are you serious?

On 26 May 2015 11:38 am, Allen Piscitello  wrote:What prevents you from writing a bad check using today's systems?On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe  wrote:What prevents RBF from being used for fraudulent payment reversals?  Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast a double spend of that transaction to pay Alice nothing? Your only cost is the higher network fee of the 2nd tx.Thanks,-DannyOn Mon, May 25, 2015 at 5:10 PM, Peter Todd  wrote:On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
> CPFP also solves it just fine.

CPFP is a significantly more expensive way of paying fees than RBF,
particularly for the use-case of defragmenting outputs, with cost
savings ranging from 30% to 90%


Case 1: CPFP vs. RBF for increasing the fee on a single tx
--

Creating an spending a P2PKH output uses 34 bytes of txout, and 148
bytes of txin, 182 bytes total.

Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
I forget to click on the "priority fee" option, so it goes out with the
minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
creating a new transaction t2 that's 192 bytes in size. I want to pay
1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
transaction fees.

On the other hand, had I use RBF, my wallet would have simply
rebroadcast t1 with the change address decreased. The rules require you
to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
fee level, or 218uBTC of fees in total.

Cost savings: 48%


Case 2: Paying multiple recipients in succession


Suppose that after I pay Alice, I also decide to pay Bob for his hard
work demonstrating cryptographic protocols. I need to create a new
transaction t2 spending t1's change address. Normally t2 would be
another 226 bytes in size, resulting in 226uBTC additional fees.

With RBF on the other hand I can simply double-spend t1 with a
transaction paying both Alice and Bob. This new transaction is 260 bytes
in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
consumed broadcasting it, resulting in an additional 36uBTC of fees.

Cost savings: 84%


Case 3: Paying multiple recipients from a 2-of-3 multisig wallet


The above situation gets even worse with multisig. t1 in the multisig
case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
in fees. With RBF we rewrite t1 with an additional output, resulting in
a 399 byte transaction, with just 36uBTC in additional fees.

Cost savings: 90%


Case 4: Dust defragmentation


My wallet has a two transaction outputs that it wants to combine into
one for the purpose of UTXO defragmentation. It broadcasts transaction
t1 with two inputs and one output, size 340 bytes, paying zero fees.

Prior to the transaction confirming I find I need to spend those funds
for a priority transaction at the 1mBTC/KB fee level. This transaction,
t2a, has one input and two outputs, 226 bytes in size. However it needs
to pay fees for both transactions at once, resulting in a combined total
fee of 556uBTC. If this situation happens frequently, defragmenting
UTXOs is likely to cost more in additional fees than it saves.

With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
bytes in size, paying 374uBTC. Even better, if one of the two inputs is
sufficiently large to cover my costs I can doublespend t1 with a
1-in-2-out tx just 226 bytes in size, paying 226uBTC.

Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
              costs you more than you save

--
'peter'[:-1]@petertodd.org
134ce6577d4122094479f548b997baf84367eaf0c190bc9f
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you 

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Gregory Maxwell]

On Tue, May 26, 2015 at 5:54 PM, Tom Harding  wrote:
>  It's not difficult to
> imagine real-world consequences to not having contributed to the
> transaction.

I'm having a hard time. Can you help me understand a specific case
where this makes a difference.

It appears to be a gratuitous requirement;  if I have another unused
input that happens to be larger by the required fee-- why not just use
it?

The inherent malleability of signatures makes it unreliable to depend
on the signature content of a transaction until its good and buried,
regardless. And an inability to replace an input means you could not
RBF for additional fees without taking change in more cases; there
ought to be a benefit to that.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Adam Back]

The general idea for replace by fee is that it would be restricted so
as to make it safe, eg all the original addresses should receive no
less bitcoin (more addresses can be added).

The scorched earth game theory stuff (allowing removing recipients) is
kind of orthogonal.

Adam

On 26 May 2015 at 19:22, Danny Thorpe  wrote:
> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast
> a double spend of that transaction to pay Alice nothing? Your only cost is
> the higher network fee of the 2nd tx.
>
> Thanks,
> -Danny
>
> On Mon, May 25, 2015 at 5:10 PM, Peter Todd  wrote:
>>
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>> > CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> --
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> 
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260 bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> 
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> 
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>>   costs you more than you save
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>>
>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> -

Re: [Bitcoin-development] Long-term mining incentives

[Thomas Voegtlin]

Hello Mike,

> 
> Are you aware of my proposal for network assurance contracts?
> 

Yes I am aware of that; sorry for not mentioning it. I think it is an
interesting proposal, but I would not rely on it today, because it
includes a large share of unproven social experiment.

(Bitcoin too is a social experiment, but so far it has been working)


> But I agree with Gavin that attempting to plan for 20 years from now is
> ambitious at best. Bitcoin might not even exist 20 years from now, or might
> be an abandoned backwater a la USENET.

I agree with that, but I don't think it can be used as a way to justify
how decisions are made today.

The opposition to block size increase comes from two things:
(1) The perceived risk of increased centralization.
(2) Long-term considerations on the need for fee pressure.

I believe you and Gavin have properly addressed (1). Concerning (2), I
think the belief that miners can eventually be funded by a fee market is
wishful thinking. Thus, I am not against the proposed block size increase.

However, the issue of long-term mining incentives remains. So far, the
only proven method to incentivize mining has been direct block reward.

The easiest solution to ensure long-term viability of Bitcoin would be
to put an end to the original block halving schedule, and to keep the
block reward constant (this is what Monero does, btw). That solution is
inflationary, but in practice, users happen to lose private keys all the
time. The rate of coins loss would eventually converge to whatever rate
of emission is chosen, because the care people take of their coins
depends on their value.

Another solution, that does not break Bitcoin's social contract, would
be to keep the original block halving schedule, but to allow miners to
also redeem lost coins (defined as: coins that have not moved for a
fixed number of years. Some time averaging of the lost coins may be
needed in order to prevent non-productive miner strategies). That
solution would create less uncertainty on the actual money supply, and
better acceptability.

I do not expect such a solution to be adopted before miner incentives
become a problem. Neither am I attempting to predict the future; a
completely different solution might be found before the problem arises,
or Bitcoin might stop to exist for some other reason.

However, if I had to decide today, I would choose such a solution,
instead of relying on completely unproven mechanisms.

More important, since we need to decide about block size today, I want
to make it clear that my support is motivated by that long-term
possibility. I believe that the "we will need fee pressure" argument can
reasonably be dismissed, not because we don't know how Bitcoin will work
in 20 years, but because we know how it works today, and it is not
thanks to fee pressure.

Thomas

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Aaron Voisine]

See the "first-seen-safe replace-by-fee" thread


Aaron Voisine
co-founder and CEO
breadwallet.com

On Tue, May 26, 2015 at 11:22 AM, Danny Thorpe 
wrote:

> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods
> broadcast a double spend of that transaction to pay Alice nothing? Your
> only cost is the higher network fee of the 2nd tx.
>
> Thanks,
> -Danny
>
> On Mon, May 25, 2015 at 5:10 PM, Peter Todd  wrote:
>
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>> > CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> --
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> 
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260 bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> 
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> 
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>>   costs you more than you save
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>>
>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring s

[Bitcoin-development] please remove me from the list

[Da Xu]

Thanks.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Allen Piscitello]

What prevents you from writing a bad check using today's systems?

On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe 
wrote:

> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods
> broadcast a double spend of that transaction to pay Alice nothing? Your
> only cost is the higher network fee of the 2nd tx.
>
> Thanks,
> -Danny
>
> On Mon, May 25, 2015 at 5:10 PM, Peter Todd  wrote:
>
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>> > CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> --
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> 
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260 bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> 
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> 
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>>   costs you more than you save
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>>
>>
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Per

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Danny Thorpe]

What prevents RBF from being used for fraudulent payment reversals?

Pay 1BTC to Alice for hard goods, then after you receive the goods
broadcast a double spend of that transaction to pay Alice nothing? Your
only cost is the higher network fee of the 2nd tx.

Thanks,
-Danny

On Mon, May 25, 2015 at 5:10 PM, Peter Todd  wrote:

> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
> > CPFP also solves it just fine.
>
> CPFP is a significantly more expensive way of paying fees than RBF,
> particularly for the use-case of defragmenting outputs, with cost
> savings ranging from 30% to 90%
>
>
> Case 1: CPFP vs. RBF for increasing the fee on a single tx
> --
>
> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
> bytes of txin, 182 bytes total.
>
> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
> I forget to click on the "priority fee" option, so it goes out with the
> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
> creating a new transaction t2 that's 192 bytes in size. I want to pay
> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
> transaction fees.
>
> On the other hand, had I use RBF, my wallet would have simply
> rebroadcast t1 with the change address decreased. The rules require you
> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
> fee level, or 218uBTC of fees in total.
>
> Cost savings: 48%
>
>
> Case 2: Paying multiple recipients in succession
> 
>
> Suppose that after I pay Alice, I also decide to pay Bob for his hard
> work demonstrating cryptographic protocols. I need to create a new
> transaction t2 spending t1's change address. Normally t2 would be
> another 226 bytes in size, resulting in 226uBTC additional fees.
>
> With RBF on the other hand I can simply double-spend t1 with a
> transaction paying both Alice and Bob. This new transaction is 260 bytes
> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>
> Cost savings: 84%
>
>
> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
> 
>
> The above situation gets even worse with multisig. t1 in the multisig
> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
> in fees. With RBF we rewrite t1 with an additional output, resulting in
> a 399 byte transaction, with just 36uBTC in additional fees.
>
> Cost savings: 90%
>
>
> Case 4: Dust defragmentation
> 
>
> My wallet has a two transaction outputs that it wants to combine into
> one for the purpose of UTXO defragmentation. It broadcasts transaction
> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>
> Prior to the transaction confirming I find I need to spend those funds
> for a priority transaction at the 1mBTC/KB fee level. This transaction,
> t2a, has one input and two outputs, 226 bytes in size. However it needs
> to pay fees for both transactions at once, resulting in a combined total
> fee of 556uBTC. If this situation happens frequently, defragmenting
> UTXOs is likely to cost more in additional fees than it saves.
>
> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
> sufficiently large to cover my costs I can doublespend t1 with a
> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>
> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>   costs you more than you save
>
> --
> 'peter'[:-1]@petertodd.org
> 134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-d

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Tom Harding]

I think this is a significant step forward.

I suggest you also need to ensure that no inputs can be removed or 
changed (other than scriptsigs) -- only added.  Otherwise, the semantics 
change too much for the original signers.  Imagine a tx with two inputs 
from different parties.  Should it be easy for party 1 to be able to 
eliminate party 2 as a contributor of funds?  It's not difficult to 
imagine real-world consequences to not having contributed to the 
transaction.  And unless you can think of a reason, tx-level attributes 
like nLocktime should not change either.

The result would be something very like CPFP, but with the new inputs 
and outputs merged into the original tx, keeping most of the overhead 
savings you describe.

It should be submitted to bitcoin/bitcoin because like most inconsistent 
relay policies, inconsistently deployed FSS RBF invites attacks (see 
https://gist.github.com/aalness/a78e3e35b90f52140f0d).

Generally, to be kind to zeroconf:

  - Align relay and validation rules
  - Keep first-seen
  - Relay double-spends as alerts
  - Allow nLocktime transactions into the mempool a bit before they 
become final
  - ...

It's not unlike making a best-effort to reduce sources of malleability.  
FSS RBF should be compatible with this if deployed consistently.



On 5/25/2015 10:13 PM, Peter Todd wrote:
> Summary
> ---
>
> First-seen-safe replace-by-fee (FSS RBF) does the following:
>
> 1) Give users effective ways of getting "stuck" transactions unstuck.
> 2) Use blockchain space efficiently.
>
> without:
>
> 3) Changing the status quo with regard to zeroconf.
>
> The current Bitcoin Core implementation has "first-seen" mempool
> behavior. Once transaction t1 has been accepted, the transaction is
> never removed from the mempool until mined, or double-spent by a
> transaction in a block. The author's previously proposed replace-by-fee
> replaced this behavior with simply accepting the transaction paying the
> highest fee.
>
> FSS RBF is a compromise between these two behaviors. Transactions may be
> replaced by higher-fee paying transactions, provided that all outputs in
> the previous transaction are still paid by the replacement. While not as
> general as standard RBF, and with higher costs than standard RBF, this
> still allows fees on transaction to be increased after the fact with
> less cost and higher efficiency than child-pays-for-parent in many
> common situations; in some situations CPFP is unusable, leaving RBF as
> the only option.
>
>
> Semantics
> -
>
> For reference, standard replace-by-fee has the following criteria for
> determining whether to replace a transaction.
>
> 1) t2 pays > fees than t1
>
> 2) The delta fees pay by t2, t2.fee - t1.fee, are >= the minimum fee
> required to relay t2. (t2.size * min_fee_per_kb)
>
> 3) t2 pays more fees/kb than t1
>
> FSS RBF adds the following additional criteria to replace-by-fee before
> allowing a transaction t1 to be replaced with t2:
>
> 1) All outputs of t1 exist in t2 and pay >= the value in t1.
>
> 2) All outputs of t1 are unspent.
>
> 3) The order of outputs in t2 is the same as in t1 with additional new
> outputs at the end of the output list.
>
> 4) t2 only conflicts with a single transaction, t1
>
> 5) t2 does not spend any outputs of t1 (which would make it an invalid
> transaction, impossible to mine)
>
> These additional criteria respect the existing "first-seen" behavior of
> the Bitcoin Core mempool implementation, such that once an address is
> payed some amount of BTC, all subsequent replacement transactions will
> pay an equal or greater amount. In short, FSS-RBF is "zeroconf safe" and
> has no affect on the ability of attackers to doublespend. (beyond of
> course the fact that any changes what-so-ever to mempool behavior are
> potential zeroconf doublespend vulnerabilities)
>
>
> Implementation
> --
>
> Pull-req for git HEAD: https://github.com/bitcoin/bitcoin/pull/6176
>
> A backport to v0.10.2 is pending.
>
> An implementation of fee bumping respecting FSS rules is available at:
>
> https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py
>
>
> Usage Scenarios
> ---
>
> Case 1: Increasing the fee on a single tx
> -
>
> We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
> with the minimal relay fee, 2.26uBTC. Increasing the fee while
> respecting FSS-RBF rules requires the addition of one more txin, with
> the change output value increased appropriately, resulting in
> transaction t2, size 374 bytes. If the change txout is sufficient for
> the fee increase, increasing the fee via CPFP requires a second
> 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another
> input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total
> of 566 bytes.
>
> Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in
>cases where the original transac

Re: [Bitcoin-development] Bitcoin Survey Paper

[Daniel Kraft]

Hi Florian!

On 2015-05-26 15:54, Florian Tschorsch wrote:
> some time ago, we became interested in Bitcoin, but gathering relevant
> work and getting an overview was kind of painful. We took it as a sign
> that a survey paper on Bitcoin is desperately needed.
> 
> Since then we observed the activities of the Bitcoin community. Recently
> we finished a technical report that is our attempt to contribute the
> lacking Bitcoin survey. Maybe it will be of interest to some of you:
> https://eprint.iacr.org/2015/464

Thanks for the work you (and your collegue) put into this paper!  It is
definitely a good step in the right direction!

> Feedback is highly appreciated and would help to improve the quality of
> future revisions.

Do you know [1]?  I've only glanced at both papers, but it seems that's
also a research paper about Bitcoin & co.

  [1] http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf

Apart from that, let me advertise myself a little bit. ;)  In case you
are interested in the difficulty mechanism (which you only mention
briefly), I've recently written about it [2] (official publication) [3]
(preprint without paywall).

  [2] http://link.springer.com/article/10.1007/s12083-015-0347-x
  [3] http://www.domob.eu/research/DifficultyControl.pdf

Good luck with your further research!

Yours,
Daniel

-- 
http://www.domob.eu/
OpenPGP: 1142 850E 6DFF 65BA 63D6  88A8 B249 2AC4 A733 0737
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri



signature.asc
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bitcoin Survey Paper

[Florian Tschorsch]

Hi all,

some time ago, we became interested in Bitcoin, but gathering relevant
work and getting an overview was kind of painful. We took it as a sign
that a survey paper on Bitcoin is desperately needed.

Since then we observed the activities of the Bitcoin community. Recently
we finished a technical report that is our attempt to contribute the
lacking Bitcoin survey. Maybe it will be of interest to some of you:
https://eprint.iacr.org/2015/464

Feedback is highly appreciated and would help to improve the quality of
future revisions.

Cheers, Florian.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Andreas Schildbach]

On 05/25/2015 11:05 PM, Peter Todd wrote:
> On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote:
>>> I see this behavior all the time. I am using the latest release, as far as 
>>> I know. Version 4.30.
>>>
>>> The same behavior occurs in the Testnet3 variant of the app. Go in there 
>>> with an empty wallet and receive one payment and wait for it to confirm. 
>>> Then send a payment and, before it confirms, try to send another one. The 
>>> wallet won't let you send the second payment. It'll say something like, 
>>> "You need x.xx more bitcoins to make this payment." But if you wait for 
>>> your first payment to confirm, then you'll be able to make the second 
>>> payment.
>>>
>>> If it matters, I configure the app to connect only to my own trusted 
>>> Bitcoin node, so I only ever have one active connection at most. I notice 
>>> that outgoing payments never show as "Sent" until they appear in a block, 
>>> presumably because the app never sees the transaction come in over any 
>>> connection.
>>
>> Yes, that's the issue. Because you're connecting only to one node, you
>> don't get any instant confirmations -- due to a Bitcoin protocol
>> limitation you can only get them from nodes you don't post the tx to.
> 
> Odd, I just tried the above as well - with multiple peers connected -
> and had the exact same problem.

It should work, I'm testing this regularly. Can you report an issue
through the app and attach your log when this happens again?



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

[Mike Hearn]

Very interesting Matt.

For what it's worth, in future bitcoinj is very likely to bootstrap from
Cartographer nodes (signed HTTP) rather than DNS, and we're also steadily
working towards Tor by default. So this approach will probably stop working
at some point. As breaking PorcFest would kind of suck, we might want a
ZeroConf/Rendezvous solution in place so local LANs can capture Bitcoin
traffic away from Tor (with some notification to the user, presumably).



On Tue, May 26, 2015 at 7:47 AM, Matt Whitlock 
wrote:

> On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote:
> > On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
> > > On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
> > > > Do any wallets actually do this yet?
> > >
> > > Not that I know of, but they do seed their address database via DNS,
> which you can poison if you control the LAN's DNS resolver. I did this for
> a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well
> over a hundred lightweight wallets, all trying to connect to the Bitcoin
> P2P network over a very bandwidth-constrained Internet link, so I poisoned
> the DNS and rejected all outbound connection attempts on port 8333, to
> force all the wallets to connect to a single local full node, which had
> connectivity to a single remote node over the Internet. Thus, all the
> lightweight wallets at the festival had Bitcoin network connectivity, but
> we only needed to backhaul the Bitcoin network's transaction traffic once.
> >
> > Interesting!
> >
> > What festival was this?
>
> The Porcupine Freedom Festival ("PorcFest") in New Hampshire last summer.
> I strongly suspect that it's the largest gathering of Bitcoin users at any
> event that is not specifically Bitcoin-themed. There's a lot of overlap
> between the Bitcoin and liberty communities. PorcFest draws somewhere
> around 1000-2000 attendees, a solid quarter of whom have Bitcoin wallets on
> their mobile devices.
>
> The backhaul was a 3G cellular Internet connection, and the local Bitcoin
> node and network router were hosted on a Raspberry Pi with some Netfilter
> tricks to restrict connectivity. The net result was that all Bitcoin nodes
> (lightweight and heavyweight) on the local Wi-Fi network were unable to
> connect to any Bitcoin nodes except for the local node, which they
> discovered via DNS. I also had provisions in place to allow outbound
> connectivity to the API servers for Mycelium, Blockchain, and Coinbase
> wallets, by feeding the DNS resolver's results in real-time into a
> whitelisting Netfilter rule utilizing IP Sets.
>
> For your amusement, here's the graphic for the banner that I had made to
> advertise the network at the festival (*chuckle*):
> http://www.mattwhitlock.com/bitcoin_wifi.png
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] No Bitcoin For You

[Jim Phillips]

I think all the suggestions recommending cutting the block time down also
suggest reducing the rewards to compensate.

--
*James G. Phillips IV*



*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*

On Tue, May 26, 2015 at 12:43 AM, gabe appleton 
wrote:

> Sync time wouldn't be longer compared to 20MB, it would (eventually) be
> longer under either setup.
>
> Also, and this is probably a silly concern, but wouldn't changing block
> time change the supply curve? If we cut the rate in half or a power of two,
> that affects nothing, but if we want to keep it in round numbers, we need
> to do it by 10, 5, or 2. I feel like most people would bank for 10 or 5,
> both of which change the supply curve due to truncation.
>
> Again, it's a trivial concern, but probably one that should be addressed.
> On May 25, 2015 11:52 PM, "Jim Phillips"  wrote:
>
>> Incidentally, even once we have the "Internet of Things" brought on by
>> 21, Inc. or whoever beats them to it, I would expect the average home to
>> have only a single full node "hub" receiving the blockchain and
>> broadcasting transactions created by all the minor SPV connected devices
>> running within the house. The in-home full node would be peered with high
>> bandwidth full-node relays running at the ISP or in the cloud. There are
>> more than enough ISPs and cloud compute providers in the world such that
>> there should be no concern at all about centralization of relays. Full
>> nodes could some day become as ubiquitous on the Internet as authoritative
>> DNS servers. And just like DNS servers, if you don't trust the nodes your
>> ISP creates or it's too slow or censors transactions, there's nothing
>> preventing you from peering with nodes hosted by the Googles or OpenDNSs
>> out there, or running your own if you're really paranoid and have a few
>> extra bucks for a VPS.
>>
>> --
>> *James G. Phillips IV*
>> 
>> 
>>
>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>> immortals." -- David Ogilvy*
>>
>>  *This message was created with 100% recycled electrons. Please think
>> twice before printing.*
>>
>> On Mon, May 25, 2015 at 10:23 PM, Jim Phillips 
>> wrote:
>>
>>> I don't see how the fact that my 2Mbps connection causes me to not be a
>>> very good relay has any bearing on whether or not the network as a whole
>>> would be negatively impacted by a 20MB block. My inability to rapidly
>>> propagate blocks doesn't really harm the network. It's only if MOST relays
>>> are as slow as mine that it creates an issue. I'm one node in thousands
>>> (potentially tens or hundreds of thousands if/when Bitcoin goes
>>> mainstream). And I'm an individual. There's no reason at all for me to run
>>> a full node from my home, except to have my own trusted and validated copy
>>> of the blockchain on a computer I control directly. I don't need to act as
>>> a relay for that and as long as I can download blocks faster than they are
>>> created I'm fine. Also, I can easily afford a VPS server or several to run
>>> full nodes as relays if I am feeling altruistic. It's actually cheaper for
>>> me to lease a VPS than to keep my own home PC on 24/7, which is why I have
>>> 2 of them.
>>>
>>> And as a business, the cost of a server and bandwidth to run a full node
>>> is a drop in the bucket. I'm involved in several projects where we have
>>> full nodes running on leased servers with multiple 1Gbps connections. It's
>>> an almost zero cost. Those nodes could handle 20MB blocks today without
>>> thinking about it, and I'm sure our nodes are just a few amongst thousands
>>> just like them. I'm not at all concerned about the network being too
>>> centralized.
>>>
>>> What concerns me is the fact that we are using edge cases like my home
>>> PC as a lame excuse to debate expanding the capacity of the network.
>>>
>>> --
>>> *James G. Phillips IV*
>>> 
>>> 
>>>
>>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>>> immortals." -- David Ogilvy*
>>>
>>>  *This message was created with 100% recycled electrons. Please think
>>> twice before printing.*
>>>
>>> On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle 
>>> wrote:
>>>
  Indeed Jim, your internet connection makes a good reason why I don't
 like 20mb blocks (right now). It would take you well over a minute to
 download the block before you could even relay it on, so much slow down in
 propagation! Yes I do see how decreasing the time to create blocks is a bit
 of a band-aid fix, and to use tge term I've seen mentioned here "kicking
 the can down the road" I agree that