[Bitcoin-development] replace-by-fee v0.10.0rc4

[Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

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

My replace-by-fee patch is now available for the v0.10.0rc4 release:

    https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4

Along with demo scripts of the functionality:

    https://github.com/petertodd/replace-by-fee-tools

New to this version is a comprehensive set of unittests under
qa/replace-by-fee

Additionally the preferential peering support now preferentially peers
with Bitcoin XT¹ nodes that support Andresen/Harding's double-spend
relaying² patch. While Bitcoin XT nodes don't accept double-spends into
their mempool, they do relay them perfectly well and thus are an asset
to those doing replace-by-fee mining.³

I've had a number of requests from miners for a version of
replace-by-fee against Luke-Jr's Eligius patches⁴; I'll be also
releasing that shortly once this release has undergone some more
testing.


What's replace-by-fee?
----------------------

Currently most Bitcoin nodes accept the first transaction they see
spending an output to the mempool; all later transactions are rejected.
Replace-by-fee changes this behavior to accept the transaction paying
the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
children are also considered - a chain of transactions is only replaced
if the replacement has a higher fee than the sum of all replaced
transactions.

Doing this aligns standard node behavior with miner incentives: earn the
most amount of money per block. It also makes for a more efficient
transaction fee marketplace, as transactions that are "stuck" due to bad
fee estimates can be "unstuck" by double-spending them with higher
paying versions of themselves. With scorched-earth techniques⁵ it gives
a path to making zeroconf transactions economically secure by relying on
economic incentives, rather than "honesty" and alturism, in the same way
Bitcoin mining itself relies on incentives rather than "honesty" and
alturism.

Finally for miners adopting replace-by-fee avoids the development of an
ecosystem that relies heavily on large miners punishing smaller ones for
misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
attack miners who include doublespends in their blocks - an unavoidable
consequence of imperfect p2p networking in a decentralized system - or
even Hearn's proposal⁷ that a majority of miners be able to vote to
confiscate the earnings of the minority and redistribute them at will.


Installation
------------

Once you've compiled the replace-by-fee-v0.10.0rc4 branch just run your
node normally. With -debug logging enabled, you'll see messages like the
following in your ~/.bitcoin/debug.log indicating your node is replacing
transactions with higher-fee paying double-spends:

    2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes

Additionally you can tell if you are connected to other replace-by-fee
nodes, or Bitcoin XT nodes, by examining the service bits advertised by
your peers:

    $ bitcoin-cli getpeerinfo | grep services | egrep '((0000000000000003)|(0000000004000001))'
            "services" : "0000000000000003",
            "services" : "0000000004000001",
            "services" : "0000000004000001",
            "services" : "0000000000000003",
            "services" : "0000000004000001",
            "services" : "0000000004000001",
            "services" : "0000000000000003",
            "services" : "0000000000000003",

Replace-by-fee nodes advertise service bit 26 from the experimental use
range; Bitcoin XT nodes advertise service bit 1 for their getutxos
support. The code sets aside a certain number of outgoing and incoming
slots just for double-spend relaying nodes, so as long as everything is
working you're node should be connected to like-minded nodes a within 30
minutes or so of starting up.

If you *don't* want to advertise the fact that you are running a
replace-by-fee node, just checkout a slightly earlier commit in git; the
actual mempool changes are separate from the preferential peering
commits. You can then connect directly to a replace-by-fee node using
the -addnode command line flag.

1) https://github.com/bitcoinxt/bitcoinxt
2) https://github.com/bitcoin/bitcoin/pull/3883
3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html

-- 
'peter'[:-1]@petertodd.org
000000000000000013c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 617 bytes --]

Peter,

An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core.

To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. 

Tamas Blummer
Bits of Proof

[-- Attachment #1.2: Type: text/html, Size: 1626 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

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

On Thu, Feb 12, 2015 at 08:23:29AM +0100, Tamas Blummer wrote:
> Peter,
> 
> An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core.
> 
> To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. 

Absolutely nothing in the replace-by-fee patch is consensus critical;
your objection is entirely an artifact of the poor modularity of the
Bitcoin Core codebase, something that is being actively improved on as
we speak.

Anyway, the logic of dealing with double-spends and keeping mempools
synced is pretty trivial:

    for i in range(len(tx.vout)):
        for double_spent_tx in mempool.mapNextTx[COutPoint(tx.GetHash(), i)]:
            mempool.remove(double_spent_tx, recursive=True)
    mempool.add(tx)

IOW, assume every transaction your "border router" gives you is now the
one and only true transaction, and everything conflicting with it must
go.

All the complexity of replace-by-fee is in deciding when one transaction
should replace another(s). Other than that the code is simple and very
similar to block handling logic.

-- 
'peter'[:-1]@petertodd.org
00000000000000000948f5c1f1a8c8073cc7d5161b98474e33904f8a1d6b0330

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --]



On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
> Why don't you use getrawmempool RPC call to synchronize mempool contents?



Since RPC interface does not scale to serve a multi user service.
In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.

POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. 
These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.


On Feb 12, 2015, at 8:45 AM, Peter Todd <pete@petertodd.org> wrote:
> IOW, assume every transaction your "border router" gives you is now the
> one and only true transaction, and everything conflicting with it must
> go.


You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting 
double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .

Tamas Blummer
Bits of Proof


[-- Attachment #1.2: Type: text/html, Size: 2998 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

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

On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote:
> On Feb 12, 2015, at 8:45 AM, Peter Todd <pete@petertodd.org> wrote:
> > IOW, assume every transaction your "border router" gives you is now the
> > one and only true transaction, and everything conflicting with it must
> > go.
> 
> 
> You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting 
> double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .

Wait, what the heck do you mean by "only if it is actually replacing an
earlier"?

How does my replace-by-fee patch *not* do that?

-- 
'peter'[:-1]@petertodd.org
000000000000000012613986506ef6592952234a6a04946ef946ff0836405ad4

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 244 bytes --]


On Feb 12, 2015, at 9:49 AM, Peter Todd <pete@petertodd.org> wrote:
> 
> How does my replace-by-fee patch *not* do that?

Does it broadcast a double spend only if it IS replacing an earlier? If yes, I am fine with it.

Tamas Blummer


[-- Attachment #1.2: Type: text/html, Size: 1326 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Troy Benjegerdes]

On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote:
> 
> 
> On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
> > Why don't you use getrawmempool RPC call to synchronize mempool contents?
> 
> 
> 
> Since RPC interface does not scale to serve a multi user service.
> In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus.
> 
> POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. 
> These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to.
> 

If a proprietary stack has problems with replace-by-fee then it's probably 
succeptible to malicious attack because an attacker could just broadcast
one transaction to the network and then replace it when they are able to
mine a block themselves.

> 
> On Feb 12, 2015, at 8:45 AM, Peter Todd <pete@petertodd.org> wrote:
> > IOW, assume every transaction your "border router" gives you is now the
> > one and only true transaction, and everything conflicting with it must
> > go.
> 
> 
> You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting 
> double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic .
> 

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Alex Mizrahi]

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

> To remain useful as border router, the replace-by-fee patched core should
> only relay double spend if it actually replaces an earlier transaction, as
> otherwise the replace logic that is according to your commit more than just
> fee comparison, would have to be replicated in the proprietary stack and
> mempool might get out of sync with that of the border router.
>

Why don't you use getrawmempool RPC call to synchronize mempool contents?

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

I know you will ignore this as usual, but the entire replace-by-fee folly
is based on your fundamental misunderstanding of miner incentives.

Miners are *not* incentivised to earn the most money in the next block
possible. They are incentivised to maximise their return on investment.
Making Bitcoin much less useful reduces demand for the bitcoins they are
mining, reducing coinbase and fee income in future blocks. Quite possibly,
to the point where those miners are then making a loss.

Your "scorched earth" plan is aptly named, as it's guaranteed to make
unconfirmed payments useless. If enough miners do it they will simply break
Bitcoin to the point where it's no longer an interesting payments system
for lots of people. Then miners who have equipment to pay off will be
*really* screwed, not to mention payment processors and all the investors
in them.

I'm sure you can confuse a few miners into thinking your ideas are a
super-duper way to maximise their income, and in the process might
facilitate a pile of payment fraud. But they aren't. This one is about as
sensible as your "let's never increase the block size"  and "let's kill SPV
clients" crusades - badly thought out and bad for Bitcoin.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Natanael]

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

Den 12 feb 2015 12:58 skrev "Mike Hearn" <mike@plan99.net>:
[...]

> Your "scorched earth" plan is aptly named, as it's guaranteed to make
unconfirmed payments useless.

Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.

NoRiskWallet: https://github.com/baleato/bitcoin-hackathon

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> Are you not counting collateralized multisignature notaries? Its an
> extended version of the Greenaddress.it model.
>
It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the disadvantages of centralised trust.

If unconfirmed payments become flaky enough that people stop using them,
then a portion of the Bitcoin community will find workarounds like trusted
third parties, trusted hardware, whatever and will just struggle one. Other
people will look at the new tradeoffs/complexity, and decide that Bitcoin
is no longer better for them than banks.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Natanael]

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

Den 12 feb 2015 13:49 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.
>
> It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the disadvantages of centralised trust.

That trust you put in them is extremely limited, and temporary.

First of all, the standard multisignature notary model applies like how I
originally described it in my blog post over a year ago.

You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.

After confirmation in the blockchain, you have standard Bitcoin transaction
security.
To profit, the notary would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.

To provide security for high value transactions, NRW adds a collateral
transaction that the notary stands for and signs in advance, and gives to
the seller. The key here is that it is constructed such that if the
original payment gets doublespent, then this collateral transaction to the
seller becomes spendable.

So there is two outcomes - either the customer or the notary pays the
seller. The customer can't force a doublespend. The notary can't steal or
freeze funds (due to nlocktime fund recovery option). The seller knows
he'll get the funds for sure before delivering the goods. Nobody is at
risk.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> You can prove a doublespend instantly by showing two conflicting
> transactions both signed by thar party. This pair can be distributed as a
> proof of malice globally in seconds via a push messaging mechanism.
>
There have been lots of e-cash schemes proposed in the academic literature
that work like this, or variants of it. Schemes where participants are
anonymous until they double spend are popular.

Let's re-write your proposal but substituting the word notary for miner:

To profit, the *miner* would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.


That's the exact argument we're having. The assertion is that a "rational"
notary would kill his own business to increase his profits in the next few
hours. So you're just arguing that a notary is different to a miner,
without spelling out exactly why.

Does the notary have to make a big up front investment? If so, why is that
different to mining investment?

Is the notary non-anonymous and afraid of being charged with payment fraud?
If so, note that big miners do lots of non-anonymous things too, like
renting warehouses and importing specialised equipment.

Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Natanael]

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

Den 12 feb 2015 14:44 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.
>
> There have been lots of e-cash schemes proposed in the academic
literature that work like this, or variants of it. Schemes where
participants are anonymous until they double spend are popular.
>
> Let's re-write your proposal but substituting the word notary for miner:
>
>> To profit, the miner would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.
>
> That's the exact argument we're having. The assertion is that a
"rational" notary would kill his own business to increase his profits in
the next few hours. So you're just arguing that a notary is different to a
miner, without spelling out exactly why.
>
> Does the notary have to make a big up front investment? If so, why is
that different to mining investment?

Miners are transient. You don't depend on any given subset of them.
Centralized e-currency give you no choice but to trust one set of notaries.

The notary don't have any large maintenance costs. The initial investment
is small, they don't need more than a few servers and maybe a HSM and some
office. In the non-collateral version, they're a centralized entity. Note
that in the fully centralized model, if the notary goes bad you're screwed.
Your tokens are useless or maybe gone.

Essentially you can't know if you're up for the long con or not.

Anybody can set up a miner with capital investments. No individual miner
has a large impact on the system as a whole.

In Bitcoin, you aren't dependent on any one multisignature notary. One
going gown only represents a small loss and done temporarily locked funds.
Anybody can set up a multisignature notary, but people won't trust you
unless you show you're trustable - you need to market yourself to get to
the point where a malicious doublespend can be profitable.

You can't really replicate the collateralized multisignature notary model
in centralized systems. Because having the e-currency bank be the notary
means they have the same powers a 51% miner would have - they can block the
transaction claiming the collateral, they can censor any other transactions
at will, and all your funds depend on them and the market's trust in them.

> Is the notary non-anonymous and afraid of being charged with payment
fraud? If so, note that big miners do lots of non-anonymous things too,
like renting warehouses and importing specialised equipment.

As notaries can be small operations, they can perform the doublespend as
they escape across the border.

> Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?

With collateralized multisignature notaries, my assumption is that
organizations that are related to Bitcoin transactions that has sufficient
sums of unallocated funds would use them for collateral in a scheme like
this (almost every large organization in the world have some unallocated
funds somewhere).

As sellers have almost no risk of losing money to them, any notary backed
by somebody they know and trust would be good enough

As buyers also have no risk, they'd use them when they want to make quick
payments.

-----

You seem to be making a lot of arguments from the status quo. I don't care
what people have been doing, preserving every habit isn't a sacred goal. I
care about stable incentives and long term predictability regarding what
behavior is safe. Behavior that becomes unsafe if incentives change is bad
and shouldn't be relied on.

Also, Bitcoin is the concensus mechanism. As mentioned, trying to provide a
guarantee for what will end up in the blocks without servers involved is to
reinvent Bitcoin within Bitcoin. I can go Xzibit on you all day long if you
like!  What you consider an attack is irrelevant. You assume a certain
behavior is desired without first making sure it is reliable.

Depending on that which isn't guaranteed is baaaad, and breaking other
people's assumptions is by itself NOT an attack if there never was a
guarantee or even as little as an implicit understanding it is safe.

Your also assume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.

Besides, zero-conf will never be secure if you don't add external
contextual information as a requirement when validating blocks. Otherwise
defecting miners will frequently doublespend against you. And adding such
information is messy and probably not secure in itself, as it opens up for
gaming the system through network level attacks.

And your remarks against game theory seems unwarranted.

The game theorists that are wrong are typically wrong for one of the
following reasons;

* Their model is wrong. The system, the actors and/or the options available
are misunderstood.
* The actors don't understand the avaliable incentives and go for trial and
error (the most optimal choices for attack and defense are found at random
or not at all, and not always adopted until it has stood the test of time).
* That option is on the to-do list, just wait.
* There's easier and/or more profitable attacks (a variant of #1 if the
game theorist said it is certain to happen).

You should NOT EVER rely on security-through-opportunity-cost for the
attacker or assume you can always keep doing what you always did. Once the
bigger targets are gone, you're next.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> > So you're just arguing that a notary is different to a miner, without
> spelling out exactly why.
>
I'm afraid I still don't understand why you think notaries would build long
term businesses but miners wouldn't, in this model.

I think you are saying because notaries have identity, brand awareness and
because they have big up front bonds, that means they will be trustworthy.

Well, sure. It's the same model governments use and is why being a money
transmitter in the USA is so difficult: you need to put up large sums of
money as collateral and have your fingerprints taken 48 times. *Then* you
can start advertising to get customers!

The reason mining is such a nice model is it doesn't have these sorts of
requirements.

> As notaries can be small operations ..... [snip] ...... (almost every
> large organization in the world have some unallocated funds somewhere).
>
Which is it? Are notaries small operations or large operations?

I think exploring new consensus models with semi-trusted notaries is
interesting, but it's not Bitcoin.

> Depending on that which isn't guaranteed is baaaad, and breaking other
> people's assumptions is by itself NOT an attack if there never was a
> guarantee or even as little as an implicit understanding it is safe.
>
Please don't try and apply this logic in the real world :( Rephrased:

"*That's a nice house. I noticed it's made of wood. I'm going to start
fires until it burns down, because there is no guarantee your house won't
burn down in future and it's important you understand that wooden houses
aren't safe. Really I'm just doing you a favour*."

Don't get me wrong. I'm all for what *you're* doing - please do continue to
research and explore alternative trust configurations! This is helpful and
useful work. Perhaps we will find something that solves the burger problem
in a way that satisfies everyone.

I'm really not a fan of Peter's approach, which is "hey let's try and cause
as many problems as possible to try and prove a point, without having
created any solutions". Replace-by-fee-scorched-earth doesn't work and
isn't a solution. Miners can easily cut payment fraudsters in on the stolen
money, and as they'd need to distribute custom double-spending wallets to
make the scheme work it'd be very easy to do.

> Your also ssume people will expect the Bitcoin network to keep zero-conf
> safe forever and that Bitcoin valuation is tied to that. Given the options
> available and current state of things, I'm assuming that's wrong.
>
Why? You think ability to make payments in a few seconds is some irrelevant
curiousity?

Let's put it this way. If BitPay's business model evaporates tomorrow,
along with all the merchants they support, do you think that'd have any
effect on Bitcoin's value? If not, why not?

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Natanael]

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

Den 12 feb 2015 15:53 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> > So you're just arguing that a notary is different to a miner, without
spelling out exactly why.
>
> I'm afraid I still don't understand why you think notaries would build
long term businesses but miners wouldn't, in this model.
>
> I think you are saying because notaries have identity, brand awareness
and because they have big up front bonds, that means they will be
trustworthy.

Miners aren't contractors, they don't have to care about repeat business.
Individual miners don't have enough impact to have a negative impact on
their own capital investment. Zero-conf transactions also aren't that tied
to the Bitcoin valuation.

Multisignature notaries need to convince people to select them. They want
to know that even with collateral, their funds won't be temporarily locked
up and unspendable for days at a time.

What services would miners provide here, do you think?

> Well, sure. It's the same model governments use and is why being a money
transmitter in the USA is so difficult: you need to put up large sums of
money as collateral and have your fingerprints taken 48 times. Then you can
start advertising to get customers!

Obviously you need to have collateral to provide collateral. Can't make
cryptographic verifiable guarantees if you don't have the resources to back
them.

> The reason mining is such a nice model is it doesn't have these sorts of
requirements.

And also can't make these assurances. Any minority miner can be overrun.

>> As notaries can be small operations ..... [snip] ...... (almost every
large organization in the world have some unallocated funds somewhere).
>
> Which is it? Are notaries small operations or large operations?

The operation itself is small. A few people maintaining a few servers.

The collateral needed depends on how many and how large simultaneous
transactions they want to provide assurances for, so they can chose to be a
small player for one niche market or large and global if they have the
funds for it.

> I think exploring new consensus models with semi-trusted notaries is
interesting, but it's not Bitcoin.

Methods for decentralized consensus that aren't PoW also aren't Bitcoin.

> Please don't try and apply this logic in the real world :( Rephrased:
>
> "That's a nice house. I noticed it's made of wood. I'm going to start
fires until it burns down, because there is no guarantee your house won't
burn down in future and it's important you understand that wooden houses
aren't safe. Really I'm just doing you a favour."

Actually that IS often a bad idea. But fortunately the risk and threat is
low, and mitigation is well understood.

> I'm really not a fan of Peter's approach, which is "hey let's try and
cause as many problems as possible to try and prove a point, without having
created any solutions". Replace-by-fee-scorched-earth doesn't work and
isn't a solution. Miners can easily cut payment fraudsters in on the stolen
money, and as they'd need to distribute custom double-spending wallets to
make the scheme work it'd be very easy to do.

Security analysis requires having the mindset of an attacker. Sometimes
that reveals suboptimal choices. Then you want them changed to more stable
choices such that once the incentives change, the risk already is gone.
Minimization of damage, simply put.

>> Your also ssume people will expect the Bitcoin network to keep zero-conf
safe forever and that Bitcoin valuation is tied to that. Given the options
available and current state of things, I'm assuming that's wrong.
>
> Why? You think ability to make payments in a few seconds is some
irrelevant curiousity?

No. But you can't be certain it is secure without having a solid reliable
mechanism to provide such a guarantee.

You want zero-conf to stay safe without involvement of servers? Then
please, try to find a way to secure it. Right now you're assuming it can
remain safe based on circumstances which can change and assumptions about
market participant's valuations that likely aren't true.

> Let's put it this way. If BitPay's business model evaporates tomorrow,
along with all the merchants they support, do you think that'd have any
effect on Bitcoin's value? If not, why not?

It would. They'd tank. But you're assuming too much about the basis for
valuation.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Justus Ranvier]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/12/2015 03:20 PM, Natanael wrote:
> Multisignature notaries need to convince people to select them.
> They want to know that even with collateral, their funds won't be
> temporarily locked up and unspendable for days at a time.
> 
> What services would miners provide here, do you think?
> 
>> Well, sure. It's the same model governments use and is why being
>> a money
> transmitter in the USA is so difficult: you need to put up large
> sums of money as collateral and have your fingerprints taken 48
> times. Then you can start advertising to get customers!
> 
> Obviously you need to have collateral to provide collateral. Can't
> make cryptographic verifiable guarantees if you don't have the
> resources to back them.

tl;dr: Bitcoin users aren't getting very excited about somebody's pet
hub-and-spoke project, so they decide to distribute a patch that will
change Bitcoin's behavior such that people are forced to adopt them.

Scorched earth, indeed.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJU3McnAAoJECpf2nDq2eYjxI8P/iClVQKNhGPr0K4D8KktUDUS
CB8Gu6Rg4VqgjzwhSd1AD1CAhSkxRRgNfHOkxeu2n1wA/fs9V/x66W9G33OyHvf4
1M+BwkiNszxvfxvZVkXyPa/eqa8/alIs1jEhb19dBRn6sJ6EQyca93PG00wDhhRU
JbHeYj2pYYMuu+xRpJWhRdUOpJOsLu5E9XMocS12wun7+zQCs4QfoLVcGhMv3+Ug
iS3/H1NNQJegIFMQzgi5hr7CxClZ+MrsLDO7MBEZknjr0toEJXe7c5Logwc3oF8h
klhFeSnhexCHNeDSGKDhG89hrgWPSDDuuyMRa3e3L4xsT2zAFcsmw0ScCmyNSto4
gUCy1gQsShDJSvsYvqjJkOcL5UfP2WLQiVJecpblf1R/tgjC0SsBoPeRMT/DeSjV
xpcjUrAUzkIBuEcunFarkt7wBvL/4pvGnbYcx3uW2YX50oO7LjCcgwJLMW4ecsvn
zAoc+aXqeORo2SAI3tTJKqpnn5K2k7DVTiFt1vzHVR7OxnKa/+sXk+bCkQi9/dAL
bWjiBUV8hXBVIt0UBgj7Q5wgQSoAXI0D816GIA2Qb9XQfmpRb8QTmf9kQ1DrcV68
Qt1KOHPY1yCynqLMxN3ONWu4JMF+YYwrxx47Gg7wSJr5q70mHNlLljfnfb5PNLtS
J6t2/QfPTMmyN3V6xkbU
=hna5
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 14416 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Oleg Andreev]

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


> On 12 Feb 2015, at 13:49, Mike Hearn <mike@plan99.net> wrote:
> If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks.

How about a Ripple-like IOU-based payment network that is 100% decentralized, for "dumb and daily" payments only? IOUs will propagate from node to node and will trusted because of a "joint escrow" transaction between each pair of nodes (locking up certain amount on both ends in 2-of-2 multisig). Total amount of debt from one node to another will be limited to 50% of the locked amount (e.g. if both nodes lock up $20 each, they allow debt up to $10 in each direction). When debt is reaching its limit, it's being "cleared" by debtor via a real BTC transaction or simply by "closing" the contract transaction with correct proportion on outputs to pay off the debt.

Every node may require an arbitrary fee for a service of providing his funds to back IOUs, when making a payment, merchant/customer may find several possible "paths" and choose the quickest/cheapest one to use. Centralization is possible at a proportional capital expense. If some node wants to be Visa-scale with millions of contracts and a lot of fees to earn, they'll have to lock up huge amount of money. This puts natural limit on centralization or associated risk. 

Example:

I pay $10. The following path is discovered and signed off by the Merchant who accepts an ad-hoc 0.3% fee:

Me: $10 -> $9.99 (Alice) -> $9.98 (Bob) -> $9.97 (Merchant).

Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant. Clearing of debts happens independently between each participant based on their debt-to-capital ratio and whether any party wishes to exit. Of course, if several paths are discovered within a reasonable timeframe, Merchant will choose the cheapest one. And maybe abort transaction if the proposed path is too expensive (e.g. total fee is >1%).

Pros:

- Decentralized.
- Mere seconds to settle a payment.
- Infinite scalability (no global consensus). Each payment involves 5-7 nodes only.
- No trusted parties or federation (trust is "purchased" using "joint escrow" txs on blockchain)
- No funny currency, IOUs denominated in BTC.
- No global consensus or protocol. Nodes can be semi-compatible, upgrade independently. All risks are local.

Political problems solved:

- No need to debate zeroconf transactions. We don't *need* them anymore to buy a coffee.
- No need to debate block size limit. It'd still be nice to raise it when needed, but for 99% of transactions we'll have a good decentralized solution off-chain, so the issue is less pressing.

Cons:

- Some amount of cash needs to be locked up with random nodes most of the time. If one of the nodes is offline, payments can't be cleared through that node. Although, it could not be a big problem as the network is useful for small-ish payments and every node will have 10-15 contracts, so it will tolerate occasional unavailability of some of them. 





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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Alex Mizrahi]

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

> Miners are *not* incentivised to earn the most money in the next block
> possible. They are incentivised to maximise their return on investment.
>

This would be right if you assume that all Bitcoin miners act as a single
entity. In that case it is true that that entity's goal is to maximize
overall ROI.

But each miner makes decisions on his own. Are you familiar with a concept
of Nash equilibrium, prisoner's dilemma, etc?

The fact that nobody is using this kind of a behavior right now doesn't
mean that we can rely on it.

For example, Peercoin was horribly broken in 6 months after its release
(e.g. people reported that they are able to generate 50 consecutive blocks
simply by bringing a cold wallet online) and yet nobody bothered to exploit
it, and it managed to acquire non-negligible "market cap".

So we have an empiric evidence that proof-of-stake miners are motivated to
keep network secure. So, maybe, we should switch to proof-of-stake, if it
was demonstrated that it is secure?

There are good reasons to not switch to proof-of-stake. Particularly, the
kind which is used in Peercoin is not game-theoretically sound. So even if
it works right now, it can fail in a big way once attackers will really get
around to it. An attack requires significant knowledge, effort and,
possibly, capital, so it might be only feasible on a certain scale.

So, well, anyway, suppose Peter Todd is the only person interested in
maintaining replace-by-fee patches right now, and you can talk him into
abandoning them.
OK, perhaps zero-confirmation payments will be de-facto secure for a couple
of years. And thus a lot of merchants will rely on zero-confirmation
payments protected by nothing but a belief in honest miners, as it is damn
convenient.

But, let's say, 5 years from now, some faction of miners who own
soon-to-be-obsolete equipment will decide to boost their profits with a
replace-by-fee pool and a corresponding wallet. They can market it as "1 of
10 hamburgers are free" if they have 10% of the total hashpower.

So would you take a responsibility for pushing the approach which isn't
game-theoretically sound?

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> But, let's say, 5 years from now, some faction of miners who own
> soon-to-be-obsolete equipment will decide to boost their profits with a
> replace-by-fee pool and a corresponding wallet. They can market it as "1 of
> 10 hamburgers are free" if they have 10% of the total hashpower.
>

Yes, like any P2P network Bitcoin cannot work if a sufficiently large
number of miners decide to attack it. This is an ancient argument. It came
up the moment Bitcoin was first invented.

But this argument could have been made at any time in Bitcoin's entire
history. Lots of miners have dropped out due to hardware obsolescence, yet
massive double spending hasn't happened. Perhaps the system is not as
simple as you boil it down to be.

Anyway, what would happen in that event is within a few days some people
would stop selling Bitcoin for hamburgers, others would find workarounds,
and the fees collected from the double spends would be worth very little.
Nobody wins.

So would you take a responsibility for pushing the approach which isn't
> game-theoretically sound?
>

"The approach" is how Bitcoin has always worked.

People have been using game theory to predict the imminent demise of
Bitcoin since I first found it. Just one example:   "Bitcoin will collapse
when the 50->25 BTC drop happens" was promoted as a dead cert thing by game
theorists. Every miner becomes unprofitable and stops at once!

So far game theory based predictions tend to be proven wrong by reality, so
this sort of argument doesn't impress me much.

Anyway, going around this loop again is pointless. I brought up the counter
argument so people who see this thread don't mistakenly think Peter's
position is some kind of de-facto consensus about how Bitcoin should work.
Not because I love rehashing the same arguments every six months ad nauseum.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Alex Mizrahi]

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

> Yes, like any P2P network Bitcoin cannot work if a sufficiently large
> number of miners decide to attack it.
>

1. They won't be attacking Bitcoin, they will attack merchants who accept
payments with 0 confirmations. This attack has nothing to do with Bitcoin
consensus mechanism (as Bitcoin protocol doesn't provide a consensus over
mempool contents), thus it is not an attack on Bitcoin.
2. In the example I used, having 10% of hashpower is enough to offer 10%
success rate. Would you mind having 1 out of 10 hamburgers for free? If a
system can be attacked by a tiny fraction, it is a shitty system.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> 1. They won't be attacking Bitcoin, they will attack merchants who accept
> payments with 0 confirmations.
>

Which is basically all of them other than exchanges. Any merchant that uses
BitPay or Coinbase, for instance, or any physical shop.

If you want to play word games and redefine "Bitcoin" to be something other
than what people are actually using, go right ahead. You will win the
argument under your own definitions which nobody else is using.

In your scenario I won't be able to get hamburgers for free because people
will stop selling them for ordinary bitcoin transactions. Most will say,
you know what, just pay me with Visa instead. And a few might knuckle down
and set up some network of PKI-like trusted third parties that interacts
with the block chain in some way.

Though eventually, if that were to happen, cunning merchants will notice
that having received a transaction counter-signed by a TTP they don't
actually have to broadcast it or pay miner fees at all. They can just keep
it around in their wallet and pass it along to the next guy when they
purchase something with those coins. Eventually whoever ends up not being
able to find a matching TTP gets to be the sucker who pays all the miner
fees at once, because he is the only one who actually needs their services.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 369 bytes --]

Mike,

You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some.

Some other’s might have seen the replaced transaction, but that only indicates for sure that the signer is fraudulent.

What should a node do that really cares of good reputation? Ignore both to be on the safe side?

Tamas Blummer


[-- Attachment #1.2: Type: text/html, Size: 1628 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> You can not consider the outcome resulting by replace-by-fee fraudulent,
> as it could be the world as observed by some.
>

Fraudulent in what sense?

If you mean the legal term, then you'd use the legal "beyond reasonable
doubt" test. You mined a double spend that ~everyone thinks came 5 minutes
later once? OK, that could be a fluke. Reasonable doubt. You do it 500
times in a row? Probably not a fluke.

If you mean under a technical definition then I think Tom Harding has been
researching this topic, though I've only kept half an eye on it. I guess
it's some statistical approximation of the above, i.e. sufficient to ensure
good incentives with only small false positive losses. Sort of like how the
block chain algorithm already works w.r.t orphans.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 610 bytes --]


On Feb 12, 2015, at 3:16 PM, Mike Hearn <mike@plan99.net> wrote:
> You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some.
> 
> Fraudulent in what sense?

Assume a wallet that sends double spend of the coin spent for services with higher fees to some of its nodes simultaneously.
Merchants will catch and reject most of the attempts, but that will not stop the scheme in a setup where customer are anonymous and distant.

Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure.

Tamas Blummer



[-- Attachment #1.2: Type: text/html, Size: 2170 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tom Harding]

On 2/12/2015 6:25 AM, Tamas Blummer wrote:
>
> Miner will see a mixed picture and will struggle to act “honestly” on 
> a statistical measure.

The statistics come from the aggregate actions of all nodes, especially 
those miners who watch p2p transactions and assemble blocks.

Any one node makes deterministic decisions based on its own observation 
-- just like today's valid/invalid decision based on whether a blocktime 
is within the next 2 hours or not.

The idea is that miners will exclude respends because they put the block 
at risk of being forked off, with no offsetting payback.  The design 
point is to make sure this is sufficiently unlikely to happen 
accidentally, or via some attack vector.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Alex Mizrahi]

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

> "The approach" is how Bitcoin has always worked.
>

Mike, you're making "it worked before, and thus it will work in future"
kind of an argument.
It is an extremely shitty kind of an argument. And it can be used to
justify any kind of bullshit.
E.g. any scamcoin which haven't yet collapsed will work forever.

As I mentioned, it depends on scale. Highly sophisticated attacks are only
feasible when scale is sufficiently big.
I.e. when you have millions of dollars transacted each day it is one thing,
but if you process billions of dollars, it becomes a whole another matter.

The best way to profit from zero-confirmation payment disruption is through
derivatives: short-sell Bitcoin while performing this attack. But this kind
of an attack depends on a number of conditions:

1. highly liquid and reliable derivative market
2. sufficiently stable exchange rate
3. significant attack impact: lots of merchants relying on
zero-confirmation payments, and lots of customers paying this way
4. significant amounts of capital available to the attacker

These conditions are not yet met, and were never met in the Bitcoin's
history so far.
This is why I wrote "5 years from now", I believe that we might reach those
conditions around that time.

Direct impact of an attack might actually be low (but even if it is just
0.1%, 0.1% of 1 billion is 10 million, which isn't bad), but attacker might
profit from the panic it causes.

Note that I'm talking about situation where Bitcoin-aware PoS solutions are
deployed on a big scale, so cost of upgrade might be huge.

So anyway, in my opinion, it is actually great that Bitcoin is still
relatively small: we have an opportunity to analyze and improve things.
But you seem to be hostile to people who do that (and who do not share your
opinion), which is kinda uncool.

Also, you do not bother to back your intuition with rigorous reasoning,
while also attacking people who offer alternatives with non-rigorous
slipper-slope kind of arguments. Which is doubly uncool.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> So anyway, in my opinion, it is actually great that Bitcoin is still
> relatively small: we have an opportunity to analyze and improve things.
> But you seem to be hostile to people who do that (and who do not share
> your opinion), which is kinda uncool.
>

To clarify once more, I'm all for people researching and building ways to
make Bitcoin better and safer. And debating that here is cool too.

The "replace by fee" patches don't do this; as you said yourself the whole
scorched earth thing makes no sense. It's not a solution to anything and
it's important people realise that.

Perhaps it will help if I spell out why this whole approach won't work (but
can easily damage bitcoin a lot along the way).

Normal Bitcoin nodes pick which transaction to put into a block by simply
selecting whichever they saw arrive first, as determined by the arrival
order of network packets. This rule is simple and has multiple advantages
for people using Bitcoin to buy and sell things.

Replace-by-fee changes this so nodes select whichever chain of unconfirmed
transactions pays the highest miner fees. Up until the point that a
transaction appears in a block, anyone can broadcast a double spend (or a
spend of an unconfirmed transaction) which pays higher fees than before,
causing that tx chain to become the candidate for chain inclusion.

Peter argues that this is stable and makes unconfirmed transactions safe
because a fraudster can buy something, walk out of the shop, and broadcast
a double spend with a higher fee. But then the merchant can re-spend the
original payment back to themselves with an *even* higher fee than that.
Then the fraudster can re-spend their double spend with an *even* higher
fee than that, and so on back and forth, until *all* the money has been
spent to miner fees. Thus the merchant loses their goods but the fraudster
has still "paid" in some sense because they don't get the money either.

This argument makes no sense for two reasons.

The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
"double spend this" button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.

The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the "scorched earth". Even with no miner
collaboration, this means the big company is down the cost of the product
*but* so is the little company who lost everything. Whoever can outspend
the other wins.


We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix "anyone can burn the money they
gave you after walking out of the shop".

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Natanael]

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

Den 12 feb 2015 16:15 skrev "Mike Hearn" <mike@plan99.net>:
>
> The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
"double spend this" button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.
>
> The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the "scorched earth". Even with no miner
collaboration, this means the big company is down the cost of the product
but so is the little company who lost everything. Whoever can outspend the
other wins.
>
> We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix "anyone can burn the money they
gave you after walking out of the shop".

I see no fundamental difference in outcome from miner collusion in
scorched-fee (which isn't guaranteed to pay the "right" pool!) and miner
collusion in knowingly mining a doublespend transaction.

Both outcomes pay the miner and thief equally when successful. The merchant
loses in both.

Zero-conf needs something else for security. A guarantee it can not be
doublespent in the relevant time frame.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> I see no fundamental difference in outcome from miner collusion in
> scorched-fee (which isn't guaranteed to pay the "right" pool!) and miner
> collusion in knowingly mining a doublespend transaction.
>
Well, they're the same thing. Replace-by-fee *is* miner collusion in
knowingly mining a double spend, just triggered in a certain way.

Remember that you aren't paying the bad pool, the bad pool is paying you.
Whichever pool benefits from the scorched earth protocol can simply pick an
address out of the transaction it perceived as starting the protocol, and
pay that.

> Zero-conf needs something else for security. A guarantee it can not be
> doublespent in the relevant time frame.
>
I think this is the core point which many of these debates revolve around.

No payment system provides *guarantees*, though some are stronger than
others. All they do is manage risk.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Natanael]

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

Den 12 feb 2015 16:42 skrev "Mike Hearn" <mike@plan99.net>:
> Remember that you aren't paying the bad pool, the bad pool is paying you.
Whichever pool benefits from the scorched earth protocol can simply pick an
address out of the transaction it perceived as starting the protocol, and
pay that.

My counterargument: with zero-conf but no replace-by-fee scorched earth,
there would instead be a market which thieves use where pools would offer
to execute doublespends that pay the thief and the pool, and where the
pools would set what terms and payouts they ask for.

All bidding pools with acceptable terms get a doublespend transaction that
pays that specific pool and the thief, the first to mine theirs win (and
the merchant loses).

Your protocol requires less setup, but that's the only notable difference
(besides risk of paying non-participating pools with scorched earth).

No notable difference in security for merchants.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Btc Drak]

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

On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn <mike@plan99.net> wrote:

> Peter argues that this is stable and makes unconfirmed transactions safe
>> because a fraudster can buy something, walk out of the shop, and broadcast
>> a double spend with a higher fee. But then the merchant can re-spend the
>> original payment back to themselves with an *even* higher fee than that.
>> Then the fraudster can re-spend their double spend with an *even* higher
>> fee than that, and so on back and forth, until *all* the money has been
>> spent to miner fees. Thus the merchant loses their goods but the fraudster
>> has still "paid" in some sense because they don't get the money either.
>>
>
> This argument makes no sense for two reasons.
>
> The first is that this setup means miners can steal arbitrary payments if
> they work together with the sender of the money. The model assumes this
> collaboration won't happen, but it will. Because no existing wallet has a
> "double spend this" button, to make the scheme work the dishonest miners
> must create and distribute such a wallet that implements the whole
> scorched-earth protocol. At that point it's easy for miners to reward the
> payment fraudster with some of the stolen money the merchant lost, meaning
> it now makes sense for the fraudster to always do this. The situation isn't
> stable at all.
>
> The second is that it incentivises competitors to engage in payment fraud
> against each other. A big rich coffee shop chain that is facing competition
> from a small, scrappy newcomer can simply walk into the new shop and buy
> things, then trigger the "scorched earth". Even with no miner
> collaboration, this means the big company is down the cost of the product
> *but* so is the little company who lost everything. Whoever can outspend
> the other wins.
>

I think that is a misdirection on your part. The point of replace-by-fee is
to make 0-confirms reliably unreliable. Currently people can "get away"
with 0-confirms but it's only because most people arent actively double
spending, and when they do it is for higher value targets. Double spend
attacks *are* happening a lot more frequently than is being admitted here,
according to Peter from work with various clients.

Like single address reuse, people have gotten used to something which is
bad. Generally accepting 0-conf is also a bad idea(tm) and instant
confirmation solutions should be sought elsewhere. There are already
interesting solutions and concepts: greenaddress for example, and
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than
supporting and promoting risky 0-confirms, we need to spend time on better
alternative solutions that will work for everyone and not during the
honeymoon phase where attackers are fewer.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Oleg Andreev]

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


> I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can "get away" with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. 
> 
> Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer.

Here's value-free assessment of the issue here:

1. Zero-conf txs are unsafe.
2. We'd all want to have a safer instant payments solution if possible.
3. As a social artifact, today zeroconf txs happen to work for some people in some situations.
4. Replace-by-fee will break #3 and probably hasten development of #2.

The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner.

I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons).

TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined.



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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Justus Ranvier]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/12/2015 05:24 PM, Oleg Andreev wrote:
> 
>> I think that is a misdirection on your part. The point of
>> replace-by-fee is to make 0-confirms reliably unreliable.
>> Currently people can "get away" with 0-confirms but it's only
>> because most people arent actively double spending, and when they
>> do it is for higher value targets. Double spend attacks are
>> happening a lot more frequently than is being admitted here,
>> according to Peter from work with various clients.
>> 
>> Like single address reuse, people have gotten used to something
>> which is bad. Generally accepting 0-conf is also a bad idea(tm)
>> and instant confirmation solutions should be sought elsewhere.
>> There are already interesting solutions and concepts:
>> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
>> channels for example. Rather than supporting and promoting risky
>> 0-confirms, we need to spend time on better alternative solutions
>> that will work for everyone and not during the honeymoon phase
>> where attackers are fewer.
> 
> Here's value-free assessment of the issue here:
> 
> 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> instant payments solution if possible. 3. As a social artifact,
> today zeroconf txs happen to work for some people in some
> situations. 4. Replace-by-fee will break #3 and probably hasten
> development of #2.
> 
> The discussion boils down to whether we should make #2 happen
> sooner by breaking remnants of #3 sooner.
> 
> I personally would rather not break anything, but work as fast as
> possible on #2 so no matter when and how #3 becomes utterly broken,
> we have a better solution. This implies that I also don't want to
> waste time debating with Peter Todd and others. I want to be ready
> with a working tool when zeroconf completely fails (with that patch
> or for some other reasons).
> 
> TL;DR: those who are against the patch are better off building a
> decentralized clearing network rather than wasting time on debates.
> When we have such network, we might all want this patch to be used
> for all the reasons Peter has already outlined.

You've left out of the discussion that many (or all) proposed
solutions for 2 either reduce privacy, or security, or both.

That fact should not be ignored or swept under the rug.

There's also no mention of the degree to which child-pays-for-parent
achieves the stated aims of the original proposal (clearing mempool of
stuck transactions, increasing payee assurance of conformation)
without introducing incentives to double spend or forcing people into
privacy/security sacrifices.


- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5
6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM
HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4
bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF
2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45
RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap
V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232
FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs
G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF
n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM
7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8
XjbkwrkFIuKfUJyfIuR+
=ony0
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 14416 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Allen Piscitello]

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

You cannot close Pandora's box.  Whether or not this type of patch should
exist is irrelevant.  It does, and there are incentives to use it by
miners.  These are the bounds we have to deal with and the world we must
adapt to.

On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier <justusranvier@riseup.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 05:24 PM, Oleg Andreev wrote:
> >
> >> I think that is a misdirection on your part. The point of
> >> replace-by-fee is to make 0-confirms reliably unreliable.
> >> Currently people can "get away" with 0-confirms but it's only
> >> because most people arent actively double spending, and when they
> >> do it is for higher value targets. Double spend attacks are
> >> happening a lot more frequently than is being admitted here,
> >> according to Peter from work with various clients.
> >>
> >> Like single address reuse, people have gotten used to something
> >> which is bad. Generally accepting 0-conf is also a bad idea(tm)
> >> and instant confirmation solutions should be sought elsewhere.
> >> There are already interesting solutions and concepts:
> >> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
> >> channels for example. Rather than supporting and promoting risky
> >> 0-confirms, we need to spend time on better alternative solutions
> >> that will work for everyone and not during the honeymoon phase
> >> where attackers are fewer.
> >
> > Here's value-free assessment of the issue here:
> >
> > 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> > instant payments solution if possible. 3. As a social artifact,
> > today zeroconf txs happen to work for some people in some
> > situations. 4. Replace-by-fee will break #3 and probably hasten
> > development of #2.
> >
> > The discussion boils down to whether we should make #2 happen
> > sooner by breaking remnants of #3 sooner.
> >
> > I personally would rather not break anything, but work as fast as
> > possible on #2 so no matter when and how #3 becomes utterly broken,
> > we have a better solution. This implies that I also don't want to
> > waste time debating with Peter Todd and others. I want to be ready
> > with a working tool when zeroconf completely fails (with that patch
> > or for some other reasons).
> >
> > TL;DR: those who are against the patch are better off building a
> > decentralized clearing network rather than wasting time on debates.
> > When we have such network, we might all want this patch to be used
> > for all the reasons Peter has already outlined.
>
> You've left out of the discussion that many (or all) proposed
> solutions for 2 either reduce privacy, or security, or both.
>
> That fact should not be ignored or swept under the rug.
>
> There's also no mention of the degree to which child-pays-for-parent
> achieves the stated aims of the original proposal (clearing mempool of
> stuck transactions, increasing payee assurance of conformation)
> without introducing incentives to double spend or forcing people into
> privacy/security sacrifices.
>
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5
> 6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM
> HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4
> bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF
> 2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45
> RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap
> V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232
> FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs
> G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF
> n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM
> 7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8
> XjbkwrkFIuKfUJyfIuR+
> =ony0
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Alan Reiner]

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

I'll add fuel to the fire here, and express that I believe that
replace-by-fee is good in the long-term.  Peter is not breaking the
zero-conf, it was already broken, and not admitting it creates a false
sense of security.  I don't want to see systems that are built on the
assumption that zero-conf tx are safe solely because it has always
appeared safe.  You can argue about rational miner behaviors all day,
but in a decentralized system you have no idea what miners consider
rational, or speculate about their incentives. 

If there's one thing I learned playing poker (many years ago), was that
always assuming your opponent is rational can lose you a lot of money. 
You made play that, in hindsight, was terrible given what he actually
had.  But you assumed no sane or rational person in his position would
make such a play so you discounted it in your decision-making process. 
You're "right" that his actions were terrible and irrational, but he
still won your money because you discounted his ability to make such a
"bad" play.  Here, you are speculating that an "opponent" uses the same
values/motivations/rationality as yourself, and then building systems
that depend on that being true.  Even if it "should" be true doesn't
mean that it is true and will remain that way.  And you will get burned
by it eventually.

The Bitcoin network achieves something that we didnt' think was possible
10 years ago:  a totally trustless, decentralized ledger.  The cost?  It
takes time for the decentralized network to reach consensus that
transactions "happened".  That is quite literally the trade-off that we
make: you can centralize things by putting a bank in the middle and
getting instant confirmation, or you decentralize and let the network
reach consensus over time without the central authority.   If you want
instant confirmations, you're going to need to add centralization
because Bitcoin never offered it.  I support efforts to dispel any such
myths as soon as possible and encourage building robust solutions
(payment channels, insured zero-conf services, etc.).

-Alan


On 02/12/2015 07:37 PM, Allen Piscitello wrote:
> You cannot close Pandora's box.  Whether or not this type of patch should exist is irrelevant.  It
does, and there are incentives to use it by miners.  These are the
bounds we have to deal with and the world we must adapt to.
>
> On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
<justusranvier@riseup.net <mailto:justusranvier@riseup.net>> wrote:
>
> On 02/12/2015 05:24 PM, Oleg Andreev wrote:
>
> >> I think that is a misdirection on your part. The point of
> >> replace-by-fee is to make 0-confirms reliably unreliable.
> >> Currently people can "get away" with 0-confirms but it's only
> >> because most people arent actively double spending, and when they
> >> do it is for higher value targets. Double spend attacks are
> >> happening a lot more frequently than is being admitted here,
> >> according to Peter from work with various clients.
> >>
> >> Like single address reuse, people have gotten used to something
> >> which is bad. Generally accepting 0-conf is also a bad idea(tm)
> >> and instant confirmation solutions should be sought elsewhere.
> >> There are already interesting solutions and concepts:
> >> greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
> >> channels for example. Rather than supporting and promoting risky
> >> 0-confirms, we need to spend time on better alternative solutions
> >> that will work for everyone and not during the honeymoon phase
> >> where attackers are fewer.
>
> > Here's value-free assessment of the issue here:
>
> > 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
> > instant payments solution if possible. 3. As a social artifact,
> > today zeroconf txs happen to work for some people in some
> > situations. 4. Replace-by-fee will break #3 and probably hasten
> > development of #2.
>
> > The discussion boils down to whether we should make #2 happen
> > sooner by breaking remnants of #3 sooner.
>
> > I personally would rather not break anything, but work as fast as
> > possible on #2 so no matter when and how #3 becomes utterly broken,
> > we have a better solution. This implies that I also don't want to
> > waste time debating with Peter Todd and others. I want to be ready
> > with a working tool when zeroconf completely fails (with that patch
> > or for some other reasons).
>
> > TL;DR: those who are against the patch are better off building a
> > decentralized clearing network rather than wasting time on debates.
> > When we have such network, we might all want this patch to be used
> > for all the reasons Peter has already outlined.
>
> You've left out of the discussion that many (or all) proposed
> solutions for 2 either reduce privacy, or security, or both.
>
> That fact should not be ignored or swept under the rug.
>
> There's also no mention of the degree to which child-pays-for-parent
> achieves the stated aims of the original proposal (clearing mempool of
> stuck transactions, increasing payee assurance of conformation)
> without introducing incentives to double spend or forcing people into
> privacy/security sacrifices.
>
>
>
>    
------------------------------------------------------------------------------
>     Dive into the World of Parallel Programming. The Go Parallel Website,
>     sponsored by Intel and developed in partnership with Slashdot
Media, is your
>     hub for all things parallel software development, from weekly thought
>     leadership blogs to news, videos, case studies, tutorials and
more. Take a
>     look and join the conversation now. http://goparallel.sourceforge.net/
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
<mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Justus Ranvier]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/12/2015 07:15 PM, Alan Reiner wrote:
> I'll add fuel to the fire here, and express that I believe that 
> replace-by-fee is good in the long-term.  Peter is not breaking
> the zero-conf, it was already broken, and not admitting it creates
> a false sense of security.  I don't want to see systems that are
> built on the assumption that zero-conf tx are safe solely because
> it has always appeared safe.  You can argue about rational miner
> behaviors all day, but in a decentralized system you have no idea
> what miners consider rational, or speculate about their incentives.
> 
As noted elsewhere in the thread, there are two problems with this
analysis:

1. It asserts that zero-confirmation transactions are in a binary
state of safe/broken instead of recognizing that relying on them is a
non-binary risk analysis on the part of a merchant.

2. Assumptions about what is profitable for miners are based on all
miners having short time horizons for calculating profits.

In addition, I'll add that there is an assumption that honest actors
can not alter their behavior in response to changing conditions.

Since scorched-earth solutions to problems are apparently acceptable
now, what would stop more honest node operators from patching their
nodes to blacklist any peer that relays replace-by-fee transactions,
and maybe even publish an IP address list of those peers?

Punishing Bitcoin users for not adopting somebody's pet solution to a
problem neither responsible nor ethical.

Child-pays-for-parent allows for stuck transactions to be cleared from
the mempool, and allows recipients of zero-conf transactions to adjust
their risk exposure as much or as little as they like.

It's a solution that gives Bitcoin users more freedom, instead of
trying to coerce them into pre-determined directions.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
F9dKdL5zCGofvU/U5BVq
=kEMr
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 14416 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

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

On Thu, Feb 12, 2015 at 07:34:22PM +0000, Justus Ranvier wrote:
> In addition, I'll add that there is an assumption that honest actors
> can not alter their behavior in response to changing conditions.
> 
> Since scorched-earth solutions to problems are apparently acceptable
> now, what would stop more honest node operators from patching their
> nodes to blacklist any peer that relays replace-by-fee transactions,
> and maybe even publish an IP address list of those peers?

None of those solutions are compatible with decentralized networks for a
lot of reasons. Given the inability to prevent sybil attacks your
suggestions lead to people being unfairly punished for poor connectivity
that may be entirely out of their control. They also make maintaining a
Bitcoin node and mining the blockchain require a significant amount of
hands on maintenance, again incompatible with a decentralized system.

-- 
'peter'[:-1]@petertodd.org
00000000000000000a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Justus Ranvier]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/12/2015 07:45 PM, Peter Todd wrote:
> None of those solutions are compatible with decentralized networks
> for a lot of reasons. Given the inability to prevent sybil attacks
> your suggestions lead to people being unfairly punished for poor
> connectivity that may be entirely out of their control. They also
> make maintaining a Bitcoin node and mining the blockchain require a
> significant amount of hands on maintenance, again incompatible with
> a decentralized system.

So maybe scorched-earth solutions aren't a good idea after all.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJU3QO8AAoJECpf2nDq2eYj4bUP/R8Lwjpdvc8Wu573+cGVRI88
/J8fURgYTxS9yvNNGRRHDYkHiqAcGI4sHIQQkqGs+A6mdDTbq6bJ04RjHoznlYbj
TcpaKQkEynVSD5AjMnZ7Z/zLsc+qjFChNGNgxC3k4AW5UdBgo3VTE8HR1rVXM5C3
JLCSKv8uCRkHJxRlXZwE9/sZTZAAuLFVdTQb6sfi4Kb4Ztn8P2K2IsEnOlFwv1cZ
ZNByxa56iBbNrVQa7hbbNXauIGOkj0fM3MB75JUQK/dHnW5d19bNHRIG0vnTtczH
eoVvEdMtpSF/e7S6Kzx5xfcmCQsBRX7JIHyuZpBYAgr1HxjXOrdvqgWQCWDSUtNO
ybzYwNKUbSCgbp6tbVTQuskm0QKVRcrrqMPZepPcgjQ/FLB8EALqarROkJTop/3p
8YatD3iq77SdnOfmFMZCFGHzn4UaxturRdEYIfeqz2Ia0YyyH3GWs1juhazyH+CM
u6HbXXrq6AJmKWLYbSK1ycUBo9OhFObT9X3XswsWa0uNtSwLveqlvaI77UHkJbnr
U9Ek9V0WznV1H9hn6qJpKyS/d+M64dfGjBSo79b50IxvlKrHKBPZkdHfSUyjnMFW
rl9uE0jB6oLFUcqchypJ89HUeso7fD/8l36w0Z4TkMrcAy9V0RIj6P5nBYBU1U1s
cLblEvdmUqmt4t+D1o4K
=YnGT
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 14416 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Allen Piscitello]

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

Nothing will stop that.  Bitcoin needs to deal with those issues, not stick
our heads in the sand and pretend they don't exist out of benevolence.
This isn't a pet solution, but the rules of the protocol and what is
realistically possible given the nature of distributed consensus.  Relying
on altruism is a recipe for failure.

On Thu, Feb 12, 2015 at 1:34 PM, Justus Ranvier <justusranvier@riseup.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 07:15 PM, Alan Reiner wrote:
> > I'll add fuel to the fire here, and express that I believe that
> > replace-by-fee is good in the long-term.  Peter is not breaking
> > the zero-conf, it was already broken, and not admitting it creates
> > a false sense of security.  I don't want to see systems that are
> > built on the assumption that zero-conf tx are safe solely because
> > it has always appeared safe.  You can argue about rational miner
> > behaviors all day, but in a decentralized system you have no idea
> > what miners consider rational, or speculate about their incentives.
> >
> As noted elsewhere in the thread, there are two problems with this
> analysis:
>
> 1. It asserts that zero-confirmation transactions are in a binary
> state of safe/broken instead of recognizing that relying on them is a
> non-binary risk analysis on the part of a merchant.
>
> 2. Assumptions about what is profitable for miners are based on all
> miners having short time horizons for calculating profits.
>
> In addition, I'll add that there is an assumption that honest actors
> can not alter their behavior in response to changing conditions.
>
> Since scorched-earth solutions to problems are apparently acceptable
> now, what would stop more honest node operators from patching their
> nodes to blacklist any peer that relays replace-by-fee transactions,
> and maybe even publish an IP address list of those peers?
>
> Punishing Bitcoin users for not adopting somebody's pet solution to a
> problem neither responsible nor ethical.
>
> Child-pays-for-parent allows for stuck transactions to be cleared from
> the mempool, and allows recipients of zero-conf transactions to adjust
> their risk exposure as much or as little as they like.
>
> It's a solution that gives Bitcoin users more freedom, instead of
> trying to coerce them into pre-determined directions.
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
> vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
> hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
> kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
> F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
> P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
> pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
> sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
> b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
> j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
> LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
> F9dKdL5zCGofvU/U5BVq
> =kEMr
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Justus Ranvier]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/12/2015 07:47 PM, Allen Piscitello wrote:
> Nothing will stop that.  Bitcoin needs to deal with those issues,
> not stick our heads in the sand and pretend they don't exist out of
> benevolence. This isn't a pet solution, but the rules of the
> protocol and what is realistically possible given the nature of
> distributed consensus.  Relying on altruism is a recipe for
> failure.

If there's a risk of fire burning down wooden buildings, pass out fire
extinguishers and smoke detectors, not matches.

The latter makes one an arsonist.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJU3QRrAAoJECpf2nDq2eYjLtwP/3t0uplMwjpt6MP0wrPwOfkJ
tRRyAaSkEsZi3+XjU2GVThG7kAlP2oIGFnoHc1QldhlEeWEJgPZyn7qq+mPx+I5+
OKb0PhSwRpTe0lh+r1dGyVqN+sSfbasJ9RSXYPmw1OW9ud4WOsgOh+oBTQWfuhvc
p32Fxxx5JKjc4AnCVajSzNlPlXrBy3pFfL5F1ek4Wu+H0haz39VE/EYAWlXjyWxT
vhUzv+9bcy3r8pe3eYUAmsXYLZAKb/9hWJdht6SKd509BlV6LVSrUh8Y2SJ3PYKt
z3l4WmiUXkkdk1blqtLDyfUTEZSnBK8X4esj8Sp53WfOXNkgBKe1vr4EhTXaEQMU
KD1e5s12xspPYgJdW9TWacIYKp3Ft3yBODJOTNZL3j0ryzYA+KU5ZumdHIm10J3S
J1IDQBraONESinHybGPKYtUCikTkl6TemW/CpfjRhQONov4708FIg+KQAo6ui56N
otfDGEwqH1qKgbt5DugdEBtxDmYmcYdFjID2+ZLwK6ngat8UAw2dQoCnUtkZ7w+i
Oxz4cm1vIRjv+BYipQjg4IRRZNvpEXSolz6u91qqj8SlXXdY7sZ3B5HwtGSOVX5y
l3NxYVOazA/NA/zcCG9ZPjr/O5sKJ40IjcLbTHvE1POuiF167xF2+U2Sdf/43d9d
cE68utrIaurfJsDA/L/+
=pTe/
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 14416 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Natanael]

On Thu, Feb 12, 2015 at 8:52 PM, Justus Ranvier
<justusranvier@riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 07:47 PM, Allen Piscitello wrote:
>> Nothing will stop that.  Bitcoin needs to deal with those issues,
>> not stick our heads in the sand and pretend they don't exist out of
>> benevolence. This isn't a pet solution, but the rules of the
>> protocol and what is realistically possible given the nature of
>> distributed consensus.  Relying on altruism is a recipe for
>> failure.
>
> If there's a risk of fire burning down wooden buildings, pass out fire
> extinguishers and smoke detectors, not matches.
>
> The latter makes one an arsonist.

Controlled fires is a valid tactic when necessary to reduce harm. It
is frequently used in areas with periods of extreme heat including
Australia. By burning off grids, you isolate the majority of flammable
matter into "islands". An accident fire would cause much more damage.

Placing yourself in the way of the fire and asking them to find
another solution isn't that bright. It is only a matter of time until
a fire starts, controlled or not! If you want another solution, go
figure one out yourself!

More to the point, it is unreasonable to knowingly expose yourself to
risk of harm and blame everybody else who isn't making your life
easier without you having to change anything. If the majority decides
that the best option to reduce harm for everybody requires that you
move out of the way and find another way to do things, you're better
off moving.

Telling people it is fine to keep being careless when there's a fire
hazard is "the real crime", because that would cause more harm than
what those who try to get the system changed does.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Allen Piscitello]

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

You keep making moral judgements.  Reality is, if you live in a world with
arsonists, you need to have a building that won't catch on fire, or has
fire extinguishers in place.  Do not depend on arsonists ignoring you
forever as your security model.  Penetration testing to know what
weaknesses exist, what limitations exist, and what can be improved is
essential.  Keeping your head in the sand and hoping people choose to do
the right thing only ends one way.

On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier <justusranvier@riseup.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 07:47 PM, Allen Piscitello wrote:
> > Nothing will stop that.  Bitcoin needs to deal with those issues,
> > not stick our heads in the sand and pretend they don't exist out of
> > benevolence. This isn't a pet solution, but the rules of the
> > protocol and what is realistically possible given the nature of
> > distributed consensus.  Relying on altruism is a recipe for
> > failure.
>
> If there's a risk of fire burning down wooden buildings, pass out fire
> extinguishers and smoke detectors, not matches.
>
> The latter makes one an arsonist.
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJU3QRrAAoJECpf2nDq2eYjLtwP/3t0uplMwjpt6MP0wrPwOfkJ
> tRRyAaSkEsZi3+XjU2GVThG7kAlP2oIGFnoHc1QldhlEeWEJgPZyn7qq+mPx+I5+
> OKb0PhSwRpTe0lh+r1dGyVqN+sSfbasJ9RSXYPmw1OW9ud4WOsgOh+oBTQWfuhvc
> p32Fxxx5JKjc4AnCVajSzNlPlXrBy3pFfL5F1ek4Wu+H0haz39VE/EYAWlXjyWxT
> vhUzv+9bcy3r8pe3eYUAmsXYLZAKb/9hWJdht6SKd509BlV6LVSrUh8Y2SJ3PYKt
> z3l4WmiUXkkdk1blqtLDyfUTEZSnBK8X4esj8Sp53WfOXNkgBKe1vr4EhTXaEQMU
> KD1e5s12xspPYgJdW9TWacIYKp3Ft3yBODJOTNZL3j0ryzYA+KU5ZumdHIm10J3S
> J1IDQBraONESinHybGPKYtUCikTkl6TemW/CpfjRhQONov4708FIg+KQAo6ui56N
> otfDGEwqH1qKgbt5DugdEBtxDmYmcYdFjID2+ZLwK6ngat8UAw2dQoCnUtkZ7w+i
> Oxz4cm1vIRjv+BYipQjg4IRRZNvpEXSolz6u91qqj8SlXXdY7sZ3B5HwtGSOVX5y
> l3NxYVOazA/NA/zcCG9ZPjr/O5sKJ40IjcLbTHvE1POuiF167xF2+U2Sdf/43d9d
> cE68utrIaurfJsDA/L/+
> =pTe/
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Ross Nicoll]

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arriving slightly late to the discussion, apologies.

Personally I wouldn't have written that patch, but I know development of
hostile patches happens out of sight, and if it can be written, we have
to presume it will be written eventually. I'd have preferred a patch
that only replaced non-final txes, which is the use-case I have for
transaction replacement, but that's easy to add back in.

I'm certainly not terribly convinced of the security of vanilla
zero-confirmation transactions myself, for reasons including but not
limited to this case. I also think it's important to understand that
people do make irrational decisions, and trusting network security on
everyone behaving perfectly rationally is not a workable model either.

TLDR; me too

Ross

On 12/02/15 20:36, Allen Piscitello wrote:
> You keep making moral judgements.  Reality is, if you live in a world with
> arsonists, you need to have a building that won't catch on fire, or has
> fire extinguishers in place.  Do not depend on arsonists ignoring you
> forever as your security model.  Penetration testing to know what
> weaknesses exist, what limitations exist, and what can be improved is
> essential.  Keeping your head in the sand and hoping people choose to do
> the right thing only ends one way.
>
> On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier <justusranvier@riseup.net>
> wrote:
>
> On 02/12/2015 07:47 PM, Allen Piscitello wrote:
> >>> Nothing will stop that.  Bitcoin needs to deal with those issues,
> >>> not stick our heads in the sand and pretend they don't exist out of
> >>> benevolence. This isn't a pet solution, but the rules of the
> >>> protocol and what is realistically possible given the nature of
> >>> distributed consensus.  Relying on altruism is a recipe for
> >>> failure.
>
> If there's a risk of fire burning down wooden buildings, pass out fire
> extinguishers and smoke detectors, not matches.
>
> The latter makes one an arsonist.
>
>>
>>
>>
------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more.
Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU31/yAAoJEJFC5fflM8475YIIAI7nxgxUdkKiMePMqtvPOi25
U+WCxjvIK0ZRTAV30POC7fKLT2mK0gPusSS7LtNJpPKvpC98VcSD5HWE49K80Yo9
9+QI7X7xBau1jjLo+27uOex0bJ6JwP1DSMpC12AQbMmi4FnyG+M5FMkr5/OnSxeF
cd4lT2UF7yTJPRy0+A9LwertL5Sv1yeOJJ9jtWuXgixapmHN+1Zm2VkGnur55V64
vnonlixlUMwnZNxDVoRhjTWm1P/lmCejvmvTRvcBomUlAEgRQF4TtF4YMBYXS97S
5WYrxOHLgTfTWr3FJuOnd+CVBRgZGw3u30ktaSErelyMG19lJOusBPdHTQFkV30=
=eWPj
-----END PGP SIGNATURE-----


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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

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

On Thu, Feb 12, 2015 at 08:15:01PM +0100, Alan Reiner wrote:
> The Bitcoin network achieves something that we didnt' think was possible
> 10 years ago:  a totally trustless, decentralized ledger.  The cost?  It
> takes time for the decentralized network to reach consensus that
> transactions "happened".  That is quite literally the trade-off that we
> make: you can centralize things by putting a bank in the middle and
> getting instant confirmation, or you decentralize and let the network
> reach consensus over time without the central authority.   If you want
> instant confirmations, you're going to need to add centralization
> because Bitcoin never offered it.  I support efforts to dispel any such
> myths as soon as possible and encourage building robust solutions
> (payment channels, insured zero-conf services, etc.).

Speaking of, a relatively simple thing that would help dispel these
notions would be if some wallets supported replace-by-fee-using
fee-bumping and an "attempt undo" button. Armory is an (unfortunately!)
special case because it uses a full node and has good privacy
guarantees, but most wallets could implement this by just sending the
doublespend transactions to any node advertising either the
replace-by-fee or GETUTXO's service bits.

1) https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html

-- 
'peter'[:-1]@petertodd.org
00000000000000000a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Gregory Maxwell]

On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn <mike@plan99.net> wrote:
> history. Lots of miners have dropped out due to hardware obsolescence, yet
> massive double spending hasn't happened.

How many thousands of BTC must be stolen by miners before you'd agree
that it has, in fact, happened?
(https://bitcointalk.org/index.php?topic=321630.0)

On Thu, Feb 12, 2015 at 3:27 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> The fundamental engineering truths diverge from that misty goal:
> Bitcoin is a settlement system, by design.
>
> The process of consensus "settles" upon a timeline of transactions,
> and this process -- by design -- is necessarily far from instant.
> Alt-coins that madly attempt 10-second block times etc. are simply a
> vain attempt to paper over this fundamental design attribute:
> consensus takes time.
>
> As such, the blockchain can never support All The Transactions, even
> if block size increases beyond 20MB.  Further layers are -- by design
> -- necessary if we want to achieve the goal of a decentralized payment
> network capable of supporting full global traffic.

I just wanted to pull this out and say that I agree with this
completely; to the point where I'm continually surprised to see people
expressing other views (but they do).

I don't have much opinion about replace-by-fee; It has pluses and
minuses. In the past I've considered it a "oh perhaps best to not talk
about that" idea. I think making zero conf actively less secure would
be generally regrettable, though it might make building alternatives
for fast and acceptably safe transactions more attractive sooner. I do
favor a version of replace by fee that adds the extra constraint that
all prior outputs must be paid equal or more; which would capture many
of the 'opps paid too little' without opening up the malicious double
spends quite as much (so soon).

One challenge is that without rather smart child-pays-for-parent logic
the positive argument for replace by fee doesn't really work.

On Thu, Feb 12, 2015 at 12:52 PM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
> This would be right if you assume that all Bitcoin miners act as a single
> entity. In that case it is true that that entity's goal is to maximize
> overall ROI.
>
> But each miner makes decisions on his own. Are you familiar with a concept
> of Nash equilibrium, prisoner's dilemma, etc?
>
> The fact that nobody is using this kind of a behavior right now doesn't mean
> that we can rely on it.
>
> For example, Peercoin was horribly broken in 6 months after its release
> (e.g. people reported that they are able to generate 50 consecutive blocks
> simply by bringing a cold wallet online) and yet nobody bothered to exploit
> it, and it managed to acquire non-negligible "market cap".

As a point for historical accuracy: PPC was actively attacked with
stake grinding and had to use developer signed blocks to prevent the
attacker from mining all the blocks and then later made a hard fork to
make it harder, and retains the developer block signing to stop it.

This doesn't contradict your point, which I agree with: an absence of
attacks doesn't mean an absence of vulnerability, and people counting
on things that they wouldn't if they understood them better is
something to avoid. And the prior point about game theory is one I
think some people have a hard time with: partipants are looking out
for their own interests, not some global optimum.  It may not be the
case that everyone (or even anyone) is maximally short sighted; but
it's even more unreasonable to assume that no one will ever break rank
and do something selfish.

I don't know that RBF even needs to be debated on these terms, since
there is an argument for RBF as good even if we assume miners are all
fully protocol conforming.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

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

On Thu, Feb 12, 2015 at 07:49:29PM +0000, Gregory Maxwell wrote:
> One challenge is that without rather smart child-pays-for-parent logic
> the positive argument for replace by fee doesn't really work.

That's actually incorrect now, as a mechanism for implementing
scorched-earth without child-pays-for-parent using SIGHASH_ANYONECANPAY
is available:

http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html

I greatly prefer this mechanism as it's an opt-in mechanism - many
wallets double-spend on occasion by accident - and can have the
incentives be adjusted to suit the % of hashing power that actual
supports replace-by-fee. (and the % probability you'll see the
doublespend)

My patch implements 90% of the logic required for the above to work,
however I've intentionally limited the total depth of recursion when the
replacement is being evaluated as an interm anti-DoS measure in the
spirit of belt-and-suspenders engineering. This can certainly be
improved on, e.g. by limiting total mempool size.

-- 
'peter'[:-1]@petertodd.org
00000000000000000a16bcc766361414571a5f961698acc46c27bd79c26ac15c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mike Hearn]

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

>
> > history. Lots of miners have dropped out due to hardware obsolescence,
> yet
> > massive double spending hasn't happened.
>
> How many thousands of BTC must be stolen by miners before you'd agree
> that it has, in fact, happened?
> (https://bitcointalk.org/index.php?topic=321630.0)
>

Hmm. I think this is a disagreement over the term massive. I was meaning we
don't see double spending like we see carding fraud in the traditional
online payments world. We can talk about Finney attacks by linking to
specific discussions of specific events, because they are very rare, which
is why merchants generally ignore the possibility. I didn't mean the
numeric value of lost coins added up so far.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 318 bytes --]

Mike,

Peter’s pull request might be a foot gun, but we are here to find out. One can’t claim Bitcoin core code is there to fork and then be disappointed if some really do it.

I am not sure protecting unconfirmed transactions ranks higher than fostering innovation not to depend on the same. 

Tamas Blummer


[-- Attachment #1.2: Type: text/html, Size: 989 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Alex Mizrahi]

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

> Your "scorched earth" plan is aptly named, as it's guaranteed to make
> unconfirmed payments useless.
>

"Scorched earth" makes no sense by itself. However, it can be a part of a
bigger picture. Imagine an insurance service which will make sure that
merchants are compensated for every scorched-earth or double-spend
transaction, as long they pay 0.1% premium from their revenue.

Merchants won't really care how it works as long as it does. All they know
is that they need to use a particular open-source wallet, and they will
receive a payment no matter what.
You won't need a TTP to process each payment.

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Jeff Garzik]

Repeating past statements, it is acknowledged that Peter's scorched
earth replace-by-fee proposal is aptly named, and would be widely
anti-social on the current network.

At a high level, we can see that this thread is contentious because
this covers _what we want bitcoin to be_, and that is an opinion
(versus engineering fact), and it varies from person to person.

However, hope is the denial of reality...instead we should walk
forward with our eyes open[1].  My interest in bitcoin originates from
the science fiction concept of "credits"[2], a universal money that
transcends national borders and even planets.  That is what I hoped
bitcoin would be.  "universal payments" is both a laudable goal and a
shopworn bitcoin marketing slogan.

The fundamental engineering truths diverge from that misty goal:
Bitcoin is a settlement system, by design.

The process of consensus "settles" upon a timeline of transactions,
and this process -- by design -- is necessarily far from instant.
Alt-coins that madly attempt 10-second block times etc. are simply a
vain attempt to paper over this fundamental design attribute:
consensus takes time.

As such, the blockchain can never support All The Transactions, even
if block size increases beyond 20MB.  Further layers are -- by design
-- necessary if we want to achieve the goal of a decentralized payment
network capable of supporting full global traffic.

Bitcoin payments are like IP packets -- one way, irreversible.  For
larger value transfers this attaches attendent risk of loss -- as
we've seen in the field time & again.  The world's citizens en masse
will not speak to each other with bitcoin (IP packets), but rather
with multiple layers (HTTP/TCP/IP) that enable safe and secure value
transfer or added features such as instant transactions.

This opinion is not a conspiracy to "put the bankers back in charge"
-- it is a simple acknowledgement of bitcoin's design.  The consensus
system settles on a timeline.

Bitcoin transactions are, by definition, not instant.
Zero confirmation transactions are, by definition, not secure.

Proposals such as Oleg's are _necessary_ to fully build out the
bitcoin system.  Avoid short-sighted, short-term thinking that views
the lowest layer (one-way value xfer) at the most optimal layer at
which free persons will transact freely & instantly across planet
Earth.

It is foolish to think the entire world will connect directly to the
P2P block network and broadcast all the morning coffees to all the
miners.  That's not how the system works.  It is a settlement layer.
We _must_ build decentralized layered solutions on top of bitcoin,
rather than stuffing everything into bitcoin itself.















[1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot
[2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html




On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn <mike@plan99.net> wrote:
> I know you will ignore this as usual, but the entire replace-by-fee folly is
> based on your fundamental misunderstanding of miner incentives.
>
> Miners are not incentivised to earn the most money in the next block
> possible. They are incentivised to maximise their return on investment.
> Making Bitcoin much less useful reduces demand for the bitcoins they are
> mining, reducing coinbase and fee income in future blocks. Quite possibly,
> to the point where those miners are then making a loss.
>
> Your "scorched earth" plan is aptly named, as it's guaranteed to make
> unconfirmed payments useless. If enough miners do it they will simply break
> Bitcoin to the point where it's no longer an interesting payments system for
> lots of people. Then miners who have equipment to pay off will be really
> screwed, not to mention payment processors and all the investors in them.
>
> I'm sure you can confuse a few miners into thinking your ideas are a
> super-duper way to maximise their income, and in the process might
> facilitate a pile of payment fraud. But they aren't. This one is about as
> sensible as your "let's never increase the block size"  and "let's kill SPV
> clients" crusades - badly thought out and bad for Bitcoin.
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Troy Benjegerdes]

On Thu, Feb 12, 2015 at 10:27:53AM -0500, Jeff Garzik wrote:
> Repeating past statements, it is acknowledged that Peter's scorched
> earth replace-by-fee proposal is aptly named, and would be widely
> anti-social on the current network.
>
> At a high level, we can see that this thread is contentious because
> this covers _what we want bitcoin to be_, and that is an opinion
> (versus engineering fact), and it varies from person to person.

I find Peter's proposal relatively mild. I'd prefer that instead of
exchanges going bankrupt, that there be direct blockchain support
for key revocation and 'burning' stolen coins, and an economic 
ecosystem that supports insurance underwriters that pay out when
someone inevitably gets hacked. This would definitely be 'scorched
earth' at one level, but I think would make for a far more
transparent and friendly system.

> However, hope is the denial of reality...instead we should walk
> forward with our eyes open[1].  My interest in bitcoin originates from
> the science fiction concept of "credits"[2], a universal money that
> transcends national borders and even planets.  That is what I hoped
> bitcoin would be.  "universal payments" is both a laudable goal and a
> shopworn bitcoin marketing slogan.
>
> The fundamental engineering truths diverge from that misty goal:
> Bitcoin is a settlement system, by design.

Most money/payment systems include some method to reverse or undo
payments made in error. In these systems, the longer settlement times
you mention below are a feature, not a bug, and give more time for 
a human to react to errors and system failures.

> The process of consensus "settles" upon a timeline of transactions,
> and this process -- by design -- is necessarily far from instant.
> Alt-coins that madly attempt 10-second block times etc. are simply a
> vain attempt to paper over this fundamental design attribute:
> consensus takes time.
> 
> As such, the blockchain can never support All The Transactions, even
> if block size increases beyond 20MB.  Further layers are -- by design
> -- necessary if we want to achieve the goal of a decentralized payment
> network capable of supporting full global traffic.
>
> Bitcoin payments are like IP packets -- one way, irreversible.  For
> larger value transfers this attaches attendent risk of loss -- as
> we've seen in the field time & again.  The world's citizens en masse
> will not speak to each other with bitcoin (IP packets), but rather
> with multiple layers (HTTP/TCP/IP) that enable safe and secure value
> transfer or added features such as instant transactions.

I see a world in which we have many blockchains, along with not-quite
blockchain things like ripple that approximate that vision you have 
of 'credits'. But we cannot have one chain to rule them all, for there
are inherent engineering trade-offs that one chain can never resolve.

There appear to be some things we will never come to a consensus on, 
such as transaction reversibility, or what the optimal money supply
algorithm is. However we might learn a great deal from sharing code
and ideas. So in that line, see my thoughts on reversibility [3][4]

> This opinion is not a conspiracy to "put the bankers back in charge"
> -- it is a simple acknowledgement of bitcoin's design.  The consensus
> system settles on a timeline.
> 
> Bitcoin transactions are, by definition, not instant.
> Zero confirmation transactions are, by definition, not secure.
> 
> Proposals such as Oleg's are _necessary_ to fully build out the
> bitcoin system.  Avoid short-sighted, short-term thinking that views
> the lowest layer (one-way value xfer) at the most optimal layer at
> which free persons will transact freely & instantly across planet
> Earth.
> 
> It is foolish to think the entire world will connect directly to the
> P2P block network and broadcast all the morning coffees to all the
> miners.  That's not how the system works.  It is a settlement layer.
> We _must_ build decentralized layered solutions on top of bitcoin,
> rather than stuffing everything into bitcoin itself.
 
I'll say the same about not stuffing everthing on top of the same 
blockchain. We might very well have coffee shops that take coffecoin.
But Bitcoin will never be able to scale out horizontally like altcoins
can.
 
> 
> [1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot
> [2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html
[3] https://bitbucket.org/tmagik/catoshi/issue/24
[4] https://bitbucket.org/tmagik/catoshi/issue/27

 
> 
> On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn <mike@plan99.net> wrote:
> > I know you will ignore this as usual, but the entire replace-by-fee folly is
> > based on your fundamental misunderstanding of miner incentives.
> >
> > Miners are not incentivised to earn the most money in the next block
> > possible. They are incentivised to maximise their return on investment.
> > Making Bitcoin much less useful reduces demand for the bitcoins they are
> > mining, reducing coinbase and fee income in future blocks. Quite possibly,
> > to the point where those miners are then making a loss.
> >
> > Your "scorched earth" plan is aptly named, as it's guaranteed to make
> > unconfirmed payments useless. If enough miners do it they will simply break
> > Bitcoin to the point where it's no longer an interesting payments system for
> > lots of people. Then miners who have equipment to pay off will be really
> > screwed, not to mention payment processors and all the investors in them.
> >
> > I'm sure you can confuse a few miners into thinking your ideas are a
> > super-duper way to maximise their income, and in the process might
> > facilitate a pile of payment fraud. But they aren't. This one is about as
> > sensible as your "let's never increase the block size"  and "let's kill SPV
> > clients" crusades - badly thought out and bad for Bitcoin.
> >
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> 
> 
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Adam Gibson]

On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> 
> Most money/payment systems include some method to reverse or undo 
> payments made in error. In these systems, the longer settlement
> times you mention below are a feature, not a bug, and give more
> time for a human to react to errors and system failures.
> 

Settlement has to be final somewhere. That is the whole point of it.
Transfer costs in current electronic payment systems are a direct
consequence of their non-finality. That's the point Satoshi was making
in the introduction to the whitepaper: "With the possibility of
reversal, the need for trust spreads".

There is nothing wrong with having reversible mechanisms built on top
of Bitcoin, and indeed it makes sense for most activity to happen at
those higher layers. It's easy to build things that way, but
impossible to build them the other way: you can't build a
non-reversible layer on top of a reversible layer.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Troy Benjegerdes]

On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
> 
> 
> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> > 
> > Most money/payment systems include some method to reverse or undo 
> > payments made in error. In these systems, the longer settlement
> > times you mention below are a feature, not a bug, and give more
> > time for a human to react to errors and system failures.
> > 
> 
> Settlement has to be final somewhere. That is the whole point of it.
> Transfer costs in current electronic payment systems are a direct
> consequence of their non-finality. That's the point Satoshi was making
> in the introduction to the whitepaper: "With the possibility of
> reversal, the need for trust spreads".

The problem with that statement is I trust a merchant that I went into
a store and made a payment with personally more than I trust the firmware
on my hard drive [1].

The attack surface of devices in your computer is huge. A motivated attacker
just needs to get an intern into a company that makes some kind of component
or system that's in your computer, cloud server, hardware wallet, or what 
have you that has firmware capable of reading your private keys.

With the possibility of mass trojaned hardware, if we are going to trust 
the system, it must somehow allow reversal through a human-in-the-loop.
 
> There is nothing wrong with having reversible mechanisms built on top
> of Bitcoin, and indeed it makes sense for most activity to happen at
> those higher layers. It's easy to build things that way, but
> impossible to build them the other way: you can't build a
> non-reversible layer on top of a reversible layer.

We built 'reliable' TCP on top of unreliable ethernet networks. My experience
with networking was if you tried to guarantee message delivery at the lowest
level, the system got exceedingly complicated, expensive, and brittle.

Most applications, in particular paying someone you already trust, are quite
happy running on reversible systems, and in some cases more reliable and 
lower risk. (carrying non-reversible cash is generally considered risky)

The problem is that if the base currency is assumed to be non-reversible, 
then it's brittle and becomes 'too big to fail'.

Where the blockchain improves on everything else is in transparency. If you
reverse transactions a lot, it will be obvious from an analysis. I would much
rather deal with a known, predictable, and relatively continous transaction
reversal rate (percentage) than have to deal with sudden failures where 
some anonymous bad actor makes off with a fortune.

We already have zero-conf double-spend transaction reversal, why not explicitly
extend that a little in a way that senders and receivers have a choice to 
use it, or not?


[1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Jorge Timón]

I agree "scorched hearth" is a really bad name for the 0 conf protocol
based on game theory. I would have preferred "stag hunt" since that's
basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
but I like the protocol and I think it would be interesting to
integrate it in the  payment protocol.
Even if that protocol didn't existed or didn't worked, replace-by-fee
is purely part of a node's policy, not part of consensus.
From the whitepaper, 0 conf transactions being secure by the good will
of miners was never an assumption, and it is clear to me that the
system cannot provide those guaranties based on such a weak scheme. I
believe thinking otherwise is naive.
As to consider non-standard policies "an attack to bitcoin" because
"that's not how bitcoin used to work", then I guess minimum relay fee
policies can also be considered "an attack to bitcoin" on the same
grounds.
Lastly, "first-seen-wins" was just a simple policy to bootstrap the
system, but I expect that most nodes will eventually move to policies
that are economically rational for miners such as replace-by-fee.
Not only I disagree this will be "the end of bitcoin" or "will push
the price of the btc miners are mining down", I believe it will be
something good for bitcoin.
Since this is apparently controversial I don't want to push for
replace-by-fee to become the new standard policy (something that would
make sense to me). But once the policy code is sufficiently modular as
to support several policies I would like bitcoin core to have a
CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
policy checks at all).
One step at a time I guess...


On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
> On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
>>
>>
>> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
>> >
>> > Most money/payment systems include some method to reverse or undo
>> > payments made in error. In these systems, the longer settlement
>> > times you mention below are a feature, not a bug, and give more
>> > time for a human to react to errors and system failures.
>> >
>>
>> Settlement has to be final somewhere. That is the whole point of it.
>> Transfer costs in current electronic payment systems are a direct
>> consequence of their non-finality. That's the point Satoshi was making
>> in the introduction to the whitepaper: "With the possibility of
>> reversal, the need for trust spreads".
>
> The problem with that statement is I trust a merchant that I went into
> a store and made a payment with personally more than I trust the firmware
> on my hard drive [1].
>
> The attack surface of devices in your computer is huge. A motivated attacker
> just needs to get an intern into a company that makes some kind of component
> or system that's in your computer, cloud server, hardware wallet, or what
> have you that has firmware capable of reading your private keys.
>
> With the possibility of mass trojaned hardware, if we are going to trust
> the system, it must somehow allow reversal through a human-in-the-loop.
>
>> There is nothing wrong with having reversible mechanisms built on top
>> of Bitcoin, and indeed it makes sense for most activity to happen at
>> those higher layers. It's easy to build things that way, but
>> impossible to build them the other way: you can't build a
>> non-reversible layer on top of a reversible layer.
>
> We built 'reliable' TCP on top of unreliable ethernet networks. My experience
> with networking was if you tried to guarantee message delivery at the lowest
> level, the system got exceedingly complicated, expensive, and brittle.
>
> Most applications, in particular paying someone you already trust, are quite
> happy running on reversible systems, and in some cases more reliable and
> lower risk. (carrying non-reversible cash is generally considered risky)
>
> The problem is that if the base currency is assumed to be non-reversible,
> then it's brittle and becomes 'too big to fail'.
>
> Where the blockchain improves on everything else is in transparency. If you
> reverse transactions a lot, it will be obvious from an analysis. I would much
> rather deal with a known, predictable, and relatively continous transaction
> reversal rate (percentage) than have to deal with sudden failures where
> some anonymous bad actor makes off with a fortune.
>
> We already have zero-conf double-spend transaction reversal, why not explicitly
> extend that a little in a way that senders and receivers have a choice to
> use it, or not?
>
>
> [1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mark Friedenbach]

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

Thank you Jorge for the contribution of the Stag Hunt terminology. It is
much better than a politically charged "scorched earth".
On Feb 21, 2015 11:10 AM, "Jorge Timón" <jtimon@jtimon.cc> wrote:

> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> based on game theory. I would have preferred "stag hunt" since that's
> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
> but I like the protocol and I think it would be interesting to
> integrate it in the  payment protocol.
> Even if that protocol didn't existed or didn't worked, replace-by-fee
> is purely part of a node's policy, not part of consensus.
> >From the whitepaper, 0 conf transactions being secure by the good will
> of miners was never an assumption, and it is clear to me that the
> system cannot provide those guaranties based on such a weak scheme. I
> believe thinking otherwise is naive.
> As to consider non-standard policies "an attack to bitcoin" because
> "that's not how bitcoin used to work", then I guess minimum relay fee
> policies can also be considered "an attack to bitcoin" on the same
> grounds.
> Lastly, "first-seen-wins" was just a simple policy to bootstrap the
> system, but I expect that most nodes will eventually move to policies
> that are economically rational for miners such as replace-by-fee.
> Not only I disagree this will be "the end of bitcoin" or "will push
> the price of the btc miners are mining down", I believe it will be
> something good for bitcoin.
> Since this is apparently controversial I don't want to push for
> replace-by-fee to become the new standard policy (something that would
> make sense to me). But once the policy code is sufficiently modular as
> to support several policies I would like bitcoin core to have a
> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
> policy checks at all).
> One step at a time I guess...
>
>
> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
> >>
> >>
> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> >> >
> >> > Most money/payment systems include some method to reverse or undo
> >> > payments made in error. In these systems, the longer settlement
> >> > times you mention below are a feature, not a bug, and give more
> >> > time for a human to react to errors and system failures.
> >> >
> >>
> >> Settlement has to be final somewhere. That is the whole point of it.
> >> Transfer costs in current electronic payment systems are a direct
> >> consequence of their non-finality. That's the point Satoshi was making
> >> in the introduction to the whitepaper: "With the possibility of
> >> reversal, the need for trust spreads".
> >
> > The problem with that statement is I trust a merchant that I went into
> > a store and made a payment with personally more than I trust the firmware
> > on my hard drive [1].
> >
> > The attack surface of devices in your computer is huge. A motivated
> attacker
> > just needs to get an intern into a company that makes some kind of
> component
> > or system that's in your computer, cloud server, hardware wallet, or what
> > have you that has firmware capable of reading your private keys.
> >
> > With the possibility of mass trojaned hardware, if we are going to trust
> > the system, it must somehow allow reversal through a human-in-the-loop.
> >
> >> There is nothing wrong with having reversible mechanisms built on top
> >> of Bitcoin, and indeed it makes sense for most activity to happen at
> >> those higher layers. It's easy to build things that way, but
> >> impossible to build them the other way: you can't build a
> >> non-reversible layer on top of a reversible layer.
> >
> > We built 'reliable' TCP on top of unreliable ethernet networks. My
> experience
> > with networking was if you tried to guarantee message delivery at the
> lowest
> > level, the system got exceedingly complicated, expensive, and brittle.
> >
> > Most applications, in particular paying someone you already trust, are
> quite
> > happy running on reversible systems, and in some cases more reliable and
> > lower risk. (carrying non-reversible cash is generally considered risky)
> >
> > The problem is that if the base currency is assumed to be non-reversible,
> > then it's brittle and becomes 'too big to fail'.
> >
> > Where the blockchain improves on everything else is in transparency. If
> you
> > reverse transactions a lot, it will be obvious from an analysis. I would
> much
> > rather deal with a known, predictable, and relatively continous
> transaction
> > reversal rate (percentage) than have to deal with sudden failures where
> > some anonymous bad actor makes off with a fortune.
> >
> > We already have zero-conf double-spend transaction reversal, why not
> explicitly
> > extend that a little in a way that senders and receivers have a choice to
> > use it, or not?
> >
> >
> > [1]
> http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Jeff Garzik]

"scorched earth" refers to the _real world_ impact such policies would
have on present-day 0-conf usage within the bitcoin community.

All payment processors AFAIK process transactions through some scoring
system, then accept 0-conf transactions for payments.

This isn't some theoretical exercise.  Like it or not many use
insecure 0-conf transactions for rapid payments.  Deploying something
that makes 0-conf transactions unusable would have a wide, negative
impact on present day bitcoin payments, thus "scorched earth"

Without adequate decentralized solutions for instant payments,
deploying replace-by-fee widely would simply push instant transactions
even more into the realm of centralized, walled-garden services.






On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach <mark@friedenbach.org> wrote:
> Thank you Jorge for the contribution of the Stag Hunt terminology. It is
> much better than a politically charged "scorched earth".
>
> On Feb 21, 2015 11:10 AM, "Jorge Timón" <jtimon@jtimon.cc> wrote:
>>
>> I agree "scorched hearth" is a really bad name for the 0 conf protocol
>> based on game theory. I would have preferred "stag hunt" since that's
>> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
>> but I like the protocol and I think it would be interesting to
>> integrate it in the  payment protocol.
>> Even if that protocol didn't existed or didn't worked, replace-by-fee
>> is purely part of a node's policy, not part of consensus.
>> >From the whitepaper, 0 conf transactions being secure by the good will
>> of miners was never an assumption, and it is clear to me that the
>> system cannot provide those guaranties based on such a weak scheme. I
>> believe thinking otherwise is naive.
>> As to consider non-standard policies "an attack to bitcoin" because
>> "that's not how bitcoin used to work", then I guess minimum relay fee
>> policies can also be considered "an attack to bitcoin" on the same
>> grounds.
>> Lastly, "first-seen-wins" was just a simple policy to bootstrap the
>> system, but I expect that most nodes will eventually move to policies
>> that are economically rational for miners such as replace-by-fee.
>> Not only I disagree this will be "the end of bitcoin" or "will push
>> the price of the btc miners are mining down", I believe it will be
>> something good for bitcoin.
>> Since this is apparently controversial I don't want to push for
>> replace-by-fee to become the new standard policy (something that would
>> make sense to me). But once the policy code is sufficiently modular as
>> to support several policies I would like bitcoin core to have a
>> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
>> policy checks at all).
>> One step at a time I guess...
>>
>>
>> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
>> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
>> >>
>> >>
>> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
>> >> >
>> >> > Most money/payment systems include some method to reverse or undo
>> >> > payments made in error. In these systems, the longer settlement
>> >> > times you mention below are a feature, not a bug, and give more
>> >> > time for a human to react to errors and system failures.
>> >> >
>> >>
>> >> Settlement has to be final somewhere. That is the whole point of it.
>> >> Transfer costs in current electronic payment systems are a direct
>> >> consequence of their non-finality. That's the point Satoshi was making
>> >> in the introduction to the whitepaper: "With the possibility of
>> >> reversal, the need for trust spreads".
>> >
>> > The problem with that statement is I trust a merchant that I went into
>> > a store and made a payment with personally more than I trust the
>> > firmware
>> > on my hard drive [1].
>> >
>> > The attack surface of devices in your computer is huge. A motivated
>> > attacker
>> > just needs to get an intern into a company that makes some kind of
>> > component
>> > or system that's in your computer, cloud server, hardware wallet, or
>> > what
>> > have you that has firmware capable of reading your private keys.
>> >
>> > With the possibility of mass trojaned hardware, if we are going to trust
>> > the system, it must somehow allow reversal through a human-in-the-loop.
>> >
>> >> There is nothing wrong with having reversible mechanisms built on top
>> >> of Bitcoin, and indeed it makes sense for most activity to happen at
>> >> those higher layers. It's easy to build things that way, but
>> >> impossible to build them the other way: you can't build a
>> >> non-reversible layer on top of a reversible layer.
>> >
>> > We built 'reliable' TCP on top of unreliable ethernet networks. My
>> > experience
>> > with networking was if you tried to guarantee message delivery at the
>> > lowest
>> > level, the system got exceedingly complicated, expensive, and brittle.
>> >
>> > Most applications, in particular paying someone you already trust, are
>> > quite
>> > happy running on reversible systems, and in some cases more reliable and
>> > lower risk. (carrying non-reversible cash is generally considered risky)
>> >
>> > The problem is that if the base currency is assumed to be
>> > non-reversible,
>> > then it's brittle and becomes 'too big to fail'.
>> >
>> > Where the blockchain improves on everything else is in transparency. If
>> > you
>> > reverse transactions a lot, it will be obvious from an analysis. I would
>> > much
>> > rather deal with a known, predictable, and relatively continous
>> > transaction
>> > reversal rate (percentage) than have to deal with sudden failures where
>> > some anonymous bad actor makes off with a fortune.
>> >
>> > We already have zero-conf double-spend transaction reversal, why not
>> > explicitly
>> > extend that a little in a way that senders and receivers have a choice
>> > to
>> > use it, or not?
>> >
>> >
>> > [1]
>> > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>> > more
>> > Get technology previously reserved for billion-dollar corporations, FREE
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik <jgarzik@bitpay.com> wrote:
>"scorched earth" refers to the _real world_ impact such policies would
>have on present-day 0-conf usage within the bitcoin community.

I think you guys are reading too much into the name... Replace-by-fee is called "replace-by-fee" because it considers whether to replace or not based on fee; the idea came about in an discussion about replacement based on nSequence.

I forget whether it was myself or John Dillon who came up with the name "scorched earth", but it just refers to the game theory behind the *specific* idea of the receiver combating a zeroconf double-spend by sending all the funds to fees. Scorched earth as in "You're trying to defraud me, so I'm not going yo play this game or negotiate, I'm just going to immediately do what is most likely to make you lose the maximum amount of money to punish you for your vandalism."

>All payment processors AFAIK process transactions through some scoring
>system, then accept 0-conf transactions for payments.
>
>This isn't some theoretical exercise.  Like it or not many use
>insecure 0-conf transactions for rapid payments.  Deploying something
>that makes 0-conf transactions unusable would have a wide, negative
>impact on present day bitcoin payments, thus "scorched earth"

I'm not so convinced, precisely because we've seen zeroconf fail in pretty bad ways; the people most vulnerable to losses have generally changed the way they operate. (e.g. ATM's that no longer rely on zeroconf security, instead waiting for confirmations, installing cameras, etc.)

My #1 concern right now is person-to-person trading, and people doing that tend to wait for confirmations or otherwise protect themselves. (e.g. reputation systems)

>Without adequate decentralized solutions for instant payments,
>deploying replace-by-fee widely would simply push instant transactions
>even more into the realm of centralized, walled-garden services.

Agreed. Deploying it has been something I've made into a long, drawn out, protracted process for precisely that reason. OTOH I sometimes wonder if I've gone too far with that - the services that themselves try to guarantee zeroconf right now through metrics are themselves highly centralised, and there's a big risk of them driving mining centralisation itself when they fail.
-----BEGIN PGP SIGNATURE-----

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6S2N
AAoJEMCF8hzn9LncrFUH/1xhuPhYJnjTCxhpv2h5ZJOT3wLsrU1oEDmD5fWy/4wG
7ppr3EiHNX7nB42fgeSGZF8fW1VuBjivJa9ra3IvFysFfaD40Kyre2FTnN03+vTC
Upa5ykPzOMqZIHkSf8N1xMbz4SXHHPWu8wPMzj/QGvUpllNiOWn/6Vooqrcp7f6Y
NJFykSq+vDNMOUWCiJG8hhoKiOcZhTH0Aj9qPcGs9WhgsF7wDAX7pg6iO6Y5qmt5
LdFcut2caL6mIxpExm0F9V+lyeam/3gvAU3eecHY77KOxRxFTO1xfQXEJFTWN92h
+M9BXQZ1UifjTZWMzK0kp3SRJuVSXg4KOAapQFBLTzU=
=3Mmw
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Jorge Timón]

On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> "scorched earth" refers to the _real world_ impact such policies would
> have on present-day 0-conf usage within the bitcoin community.

When I posted this: http://sourceforge.net/p/bitcoin/mailman/message/32263765/
Peter Todd clarified that the concept was referred to as "scorched earth"
http://sourceforge.net/p/bitcoin/mailman/message/32264039/

Like I said I don't like the name and would prefer "stag hunting"
which is more formal and precise.
Some people seem to use the same term for "the potential undesirable
consequences of widely deployed replace-by-fee policies".
I'm not sure that concept deserves its own term.

> All payment processors AFAIK process transactions through some scoring
> system, then accept 0-conf transactions for payments.
>
> This isn't some theoretical exercise.  Like it or not many use
> insecure 0-conf transactions for rapid payments.  Deploying something
> that makes 0-conf transactions unusable would have a wide, negative
> impact on present day bitcoin payments, thus "scorched earth"

And maybe by maintaining first seen policies we're harming the system
in the long term by encouraging people to widely deploy systems based
on extremely weak assumptions.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Jeff Garzik]

On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>> This isn't some theoretical exercise.  Like it or not many use
>> insecure 0-conf transactions for rapid payments.  Deploying something
>> that makes 0-conf transactions unusable would have a wide, negative
>> impact on present day bitcoin payments, thus "scorched earth"

> And maybe by maintaining first seen policies we're harming the system
> in the long term by encouraging people to widely deploy systems based
> on extremely weak assumptions.

Lacking a coded, reviewed alternative, that's only a platitude.
Widely used 0-conf payments are where we're at today.  Simply ceasing
the "maintaining [of] first seen policies" alone is simply not a
realistic option.  The negative impact to today's userbase would be
huge.

Instant payments need a security upgrade, yes.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Eric Lombrozo]

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

It seems to me we're confusing two completely different motivations for
double-spending. One is the ability to replace a fee, the other is the
ability to replace outputs.

If the double-spend were to merely add or remove inputs (but keep at least
one input in common, of course), it seems fairly safe to assume it's the
former, a genuine fee replacement. Even allowing for things like coinjoin,
none of the payees would really care either way.

Conversely, if at least one of the inputs were kept but none of the outputs
were, we can be confident it's the the latter.

It is possible to build a wallet that always does the former when doing fee
replacement by using another transaction to create an output with exactly
the additional desired fee.

If we can clearly distinguish these two cases then the fee replacement case
can be handled by relaying both and letting miners pick one or the other
while the output replacement case could be handled by rewarding everything
to a miner (essentially all outputs are voided...made unredeemable...and
all inputs are added to coinbase) if the miner includes the two conflicting
transactions in the same block.

Wouldn't this essentially solve the problem?

- Eric Lombrozo
On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay.com> wrote:

> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com>
> wrote:
> >> This isn't some theoretical exercise.  Like it or not many use
> >> insecure 0-conf transactions for rapid payments.  Deploying something
> >> that makes 0-conf transactions unusable would have a wide, negative
> >> impact on present day bitcoin payments, thus "scorched earth"
>
> > And maybe by maintaining first seen policies we're harming the system
> > in the long term by encouraging people to widely deploy systems based
> > on extremely weak assumptions.
>
> Lacking a coded, reviewed alternative, that's only a platitude.
> Widely used 0-conf payments are where we're at today.  Simply ceasing
> the "maintaining [of] first seen policies" alone is simply not a
> realistic option.  The negative impact to today's userbase would be
> huge.
>
> Instant payments need a security upgrade, yes.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Eric Lombrozo]

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

I should note that my proposal does require a change to the consensus
rules...but getting bitcoin to scale will require this no matter what.

- Eric Lombrozo
On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:

> It seems to me we're confusing two completely different motivations for
> double-spending. One is the ability to replace a fee, the other is the
> ability to replace outputs.
>
> If the double-spend were to merely add or remove inputs (but keep at least
> one input in common, of course), it seems fairly safe to assume it's the
> former, a genuine fee replacement. Even allowing for things like coinjoin,
> none of the payees would really care either way.
>
> Conversely, if at least one of the inputs were kept but none of the
> outputs were, we can be confident it's the the latter.
>
> It is possible to build a wallet that always does the former when doing
> fee replacement by using another transaction to create an output with
> exactly the additional desired fee.
>
> If we can clearly distinguish these two cases then the fee replacement
> case can be handled by relaying both and letting miners pick one or the
> other while the output replacement case could be handled by rewarding
> everything to a miner (essentially all outputs are voided...made
> unredeemable...and all inputs are added to coinbase) if the miner includes
> the two conflicting transactions in the same block.
>
> Wouldn't this essentially solve the problem?
>
> - Eric Lombrozo
> On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay.com> wrote:
>
>> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com>
>> wrote:
>> >> This isn't some theoretical exercise.  Like it or not many use
>> >> insecure 0-conf transactions for rapid payments.  Deploying something
>> >> that makes 0-conf transactions unusable would have a wide, negative
>> >> impact on present day bitcoin payments, thus "scorched earth"
>>
>> > And maybe by maintaining first seen policies we're harming the system
>> > in the long term by encouraging people to widely deploy systems based
>> > on extremely weak assumptions.
>>
>> Lacking a coded, reviewed alternative, that's only a platitude.
>> Widely used 0-conf payments are where we're at today.  Simply ceasing
>> the "maintaining [of] first seen policies" alone is simply not a
>> realistic option.  The negative impact to today's userbase would be
>> huge.
>>
>> Instant payments need a security upgrade, yes.
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Eric Lombrozo]

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

In case it wasn't clear in my earlier post, there's of course a third
possibility - namely, some outputs are kept but not all. Here, it is
generally impossible to tell whether the motivation was fee replacement,
output replacement, or both. My proposal is to always treat these instances
as output replacement and punish the sender. The sender needs to make it
unambiguously clear it's only a fee replacement by creating a new
transaction that produces an output with the desired extra fee and then
adding an input that spends it to the original transaction.
- Eric Lombrozo

On Sunday, February 22, 2015, Eric Lombrozo <elombrozo@gmail.com> wrote:

> I should note that my proposal does require a change to the consensus
> rules...but getting bitcoin to scale will require this no matter what.
>
> - Eric Lombrozo
> On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail.com
> <javascript:_e(%7B%7D,'cvml','elombrozo@gmail.com');>> wrote:
>
>> It seems to me we're confusing two completely different motivations for
>> double-spending. One is the ability to replace a fee, the other is the
>> ability to replace outputs.
>>
>> If the double-spend were to merely add or remove inputs (but keep at
>> least one input in common, of course), it seems fairly safe to assume it's
>> the former, a genuine fee replacement. Even allowing for things like
>> coinjoin, none of the payees would really care either way.
>>
>> Conversely, if at least one of the inputs were kept but none of the
>> outputs were, we can be confident it's the the latter.
>>
>> It is possible to build a wallet that always does the former when doing
>> fee replacement by using another transaction to create an output with
>> exactly the additional desired fee.
>>
>> If we can clearly distinguish these two cases then the fee replacement
>> case can be handled by relaying both and letting miners pick one or the
>> other while the output replacement case could be handled by rewarding
>> everything to a miner (essentially all outputs are voided...made
>> unredeemable...and all inputs are added to coinbase) if the miner includes
>> the two conflicting transactions in the same block.
>>
>> Wouldn't this essentially solve the problem?
>>
>> - Eric Lombrozo
>> On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay.com
>> <javascript:_e(%7B%7D,'cvml','jgarzik@bitpay.com');>> wrote:
>>
>>> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>>> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com
>>> <javascript:_e(%7B%7D,'cvml','jgarzik@bitpay.com');>> wrote:
>>> >> This isn't some theoretical exercise.  Like it or not many use
>>> >> insecure 0-conf transactions for rapid payments.  Deploying something
>>> >> that makes 0-conf transactions unusable would have a wide, negative
>>> >> impact on present day bitcoin payments, thus "scorched earth"
>>>
>>> > And maybe by maintaining first seen policies we're harming the system
>>> > in the long term by encouraging people to widely deploy systems based
>>> > on extremely weak assumptions.
>>>
>>> Lacking a coded, reviewed alternative, that's only a platitude.
>>> Widely used 0-conf payments are where we're at today.  Simply ceasing
>>> the "maintaining [of] first seen policies" alone is simply not a
>>> realistic option.  The negative impact to today's userbase would be
>>> huge.
>>>
>>> Instant payments need a security upgrade, yes.
>>>
>>> --
>>> Jeff Garzik
>>> Bitcoin core developer and open source evangelist
>>> BitPay, Inc.      https://bitpay.com/
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> <javascript:_e(%7B%7D,'cvml','Bitcoin-development@lists.sourceforge.net');>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo <elombrozo@gmail.com> wrote:
>In case it wasn't clear in my earlier post, there's of course a third
>possibility - namely, some outputs are kept but not all. Here, it is
>generally impossible to tell whether the motivation was fee
>replacement,
>output replacement, or both. My proposal is to always treat these
>instances
>as output replacement and punish the sender. The sender needs to make
>it
>unambiguously clear it's only a fee replacement by creating a new
>transaction that produces an output with the desired extra fee and then
>adding an input that spends it to the original transaction.

That's a really old idea - I proposed it about two years ago. The optimal way is to allow any txout to be replaced with one with an equal or greater nValue and same scriptPubKey, as well as additional txouts added. (obviously so long as none are removed)

Alas, there's lots of situations where this restricts you from doing useful things, for instance collapsing multiple payments into one by repeated updating to reduce tx size. Equally the benefit is marginal at best given how insecure unconfirmed transactions are - breaking what is already broken isn't a negative.

-----BEGIN PGP SIGNATURE-----

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O
AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3
YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr
GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn
pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ
NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl
NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs=
=1vbN
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Eric Lombrozo]

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

On Sunday, February 22, 2015, Peter Todd <pete@petertodd.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo <elombrozo@gmail.com
> <javascript:;>> wrote:
> >In case it wasn't clear in my earlier post, there's of course a third
> >possibility - namely, some outputs are kept but not all. Here, it is
> >generally impossible to tell whether the motivation was fee
> >replacement,
> >output replacement, or both. My proposal is to always treat these
> >instances
> >as output replacement and punish the sender. The sender needs to make
> >it
> >unambiguously clear it's only a fee replacement by creating a new
> >transaction that produces an output with the desired extra fee and then
> >adding an input that spends it to the original transaction.
>
> That's a really old idea - I proposed it about two years ago. The optimal
> way is to allow any txout to be replaced with one with an equal or greater
> nValue and same scriptPubKey, as well as additional txouts added.
> (obviously so long as none are removed)
>
>
That won't work because in general it is impossible to know which
transaction is the original. Did we add outputs to transaction A? Or remove
outputs from transaction B?


> Alas, there's lots of situations where this restricts you from doing
> useful things, for instance collapsing multiple payments into one by
> repeated updating to reduce tx size. Equally the benefit is marginal at
> best given how insecure unconfirmed transactions are - breaking what is
> already broken isn't a negative.
>
>
I think you're unnecessarily complicating use cases.

As for 0-conf security, there are instances where 0-conf transactions make
a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such
services which could be immediately shut off upon detection of a
double-spend.


> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O
> AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3
> YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr
> GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn
> pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ
> NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl
> NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs=
> =1vbN
> -----END PGP SIGNATURE-----
>
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Jeff Garzik]

On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> As for 0-conf security, there are instances where 0-conf transactions make a
> lot of sense - i.e. paying for utilities, ISP, web hosting, or other such
> services which could be immediately shut off upon detection of a
> double-spend.

Indeed.  0-conf risk calculus must include business conditions.

Business cases such as placing an order for a physical good, making an
in-person purchase at a brick-n-mortar store, or subscriptions already
have countermeasures in place if funds go astray.  Order fulfilment
can be stopped, subscriptions cancelled, photos handed to police.

A thief wants to maximize return, which usually means either stealing
a few large amounts or many small amounts.  Double-spending against a
SatoshiDICE clone is easy to automate.  Many other purchase situations
are difficult to repeat without getting caught, or the level of effort
(cost) is greater than the payout of double-spending a small amount.
0-conf is typically only used for small amounts, where useful theft
relies on high repetition.

Purely online, mostly anonymous services like SatoshiDICE will be
easily attacked if they accept 0-conf transactions as there is little
customer/reputation relationship to leverage.  However, that
observation cannot be easily applied to most other businesses.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Troy Benjegerdes]

So let's play this out a little.. Let's call it "Solomon's spend[1]"

Exchange gets hacked, bitcoins move.

The exchange has a contract with an insurance company and miners for 
'scorched earth' theft response that creates a double-spend of the 
original transaction.

So now there's a 10,000 bitcoin incentive for miners to roll back the
chain and start (re)mining the block where the theft occurred.

The exchange gets an insurance payout, some miner wins the lottery, and
the thief gets nothing. Seems like a good deal, what am I missing?

[1] http://en.wikipedia.org/wiki/Judgment_of_Solomon

On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote:
> I should note that my proposal does require a change to the consensus
> rules...but getting bitcoin to scale will require this no matter what.
> 
> - Eric Lombrozo
> On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:
> 
> > It seems to me we're confusing two completely different motivations for
> > double-spending. One is the ability to replace a fee, the other is the
> > ability to replace outputs.
> >
> > If the double-spend were to merely add or remove inputs (but keep at least
> > one input in common, of course), it seems fairly safe to assume it's the
> > former, a genuine fee replacement. Even allowing for things like coinjoin,
> > none of the payees would really care either way.
> >
> > Conversely, if at least one of the inputs were kept but none of the
> > outputs were, we can be confident it's the the latter.
> >
> > It is possible to build a wallet that always does the former when doing
> > fee replacement by using another transaction to create an output with
> > exactly the additional desired fee.
> >
> > If we can clearly distinguish these two cases then the fee replacement
> > case can be handled by relaying both and letting miners pick one or the
> > other while the output replacement case could be handled by rewarding
> > everything to a miner (essentially all outputs are voided...made
> > unredeemable...and all inputs are added to coinbase) if the miner includes
> > the two conflicting transactions in the same block.
> >
> > Wouldn't this essentially solve the problem?
> >
> > - Eric Lombrozo
> > On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay.com> wrote:
> >
> >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com>
> >> wrote:
> >> >> This isn't some theoretical exercise.  Like it or not many use
> >> >> insecure 0-conf transactions for rapid payments.  Deploying something
> >> >> that makes 0-conf transactions unusable would have a wide, negative
> >> >> impact on present day bitcoin payments, thus "scorched earth"
> >>
> >> > And maybe by maintaining first seen policies we're harming the system
> >> > in the long term by encouraging people to widely deploy systems based
> >> > on extremely weak assumptions.
> >>
> >> Lacking a coded, reviewed alternative, that's only a platitude.
> >> Widely used 0-conf payments are where we're at today.  Simply ceasing
> >> the "maintaining [of] first seen policies" alone is simply not a
> >> realistic option.  The negative impact to today's userbase would be
> >> huge.
> >>
> >> Instant payments need a security upgrade, yes.
> >>
> >> --
> >> Jeff Garzik
> >> Bitcoin core developer and open source evangelist
> >> BitPay, Inc.      https://bitpay.com/
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> >> Get technology previously reserved for billion-dollar corporations, FREE
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >

> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk

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


-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Neil Fincham]

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

> Seems like a good deal, what am I missing?

The disruption caused to every other user or the bitcoin network.
Transactions unconfirmed, history is rewritten, the poor Byzantine General
who sent his soldiers off to battle finds out that his scouts have been
paid to change their reports.

Neil

On 2 March 2015 at 06:59, Troy Benjegerdes <hozer@hozed.org> wrote:

> So let's play this out a little.. Let's call it "Solomon's spend[1]"
>
> Exchange gets hacked, bitcoins move.
>
> The exchange has a contract with an insurance company and miners for
> 'scorched earth' theft response that creates a double-spend of the
> original transaction.
>
> So now there's a 10,000 bitcoin incentive for miners to roll back the
> chain and start (re)mining the block where the theft occurred.
>
> The exchange gets an insurance payout, some miner wins the lottery, and
> the thief gets nothing. Seems like a good deal, what am I missing?
>
> [1] http://en.wikipedia.org/wiki/Judgment_of_Solomon
>
> On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote:
> > I should note that my proposal does require a change to the consensus
> > rules...but getting bitcoin to scale will require this no matter what.
> >
> > - Eric Lombrozo
> > On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:
> >
> > > It seems to me we're confusing two completely different motivations for
> > > double-spending. One is the ability to replace a fee, the other is the
> > > ability to replace outputs.
> > >
> > > If the double-spend were to merely add or remove inputs (but keep at
> least
> > > one input in common, of course), it seems fairly safe to assume it's
> the
> > > former, a genuine fee replacement. Even allowing for things like
> coinjoin,
> > > none of the payees would really care either way.
> > >
> > > Conversely, if at least one of the inputs were kept but none of the
> > > outputs were, we can be confident it's the the latter.
> > >
> > > It is possible to build a wallet that always does the former when doing
> > > fee replacement by using another transaction to create an output with
> > > exactly the additional desired fee.
> > >
> > > If we can clearly distinguish these two cases then the fee replacement
> > > case can be handled by relaying both and letting miners pick one or the
> > > other while the output replacement case could be handled by rewarding
> > > everything to a miner (essentially all outputs are voided...made
> > > unredeemable...and all inputs are added to coinbase) if the miner
> includes
> > > the two conflicting transactions in the same block.
> > >
> > > Wouldn't this essentially solve the problem?
> > >
> > > - Eric Lombrozo
> > > On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay.com> wrote:
> > >
> > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon.cc>
> wrote:
> > >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com>
> > >> wrote:
> > >> >> This isn't some theoretical exercise.  Like it or not many use
> > >> >> insecure 0-conf transactions for rapid payments.  Deploying
> something
> > >> >> that makes 0-conf transactions unusable would have a wide, negative
> > >> >> impact on present day bitcoin payments, thus "scorched earth"
> > >>
> > >> > And maybe by maintaining first seen policies we're harming the
> system
> > >> > in the long term by encouraging people to widely deploy systems
> based
> > >> > on extremely weak assumptions.
> > >>
> > >> Lacking a coded, reviewed alternative, that's only a platitude.
> > >> Widely used 0-conf payments are where we're at today.  Simply ceasing
> > >> the "maintaining [of] first seen policies" alone is simply not a
> > >> realistic option.  The negative impact to today's userbase would be
> > >> huge.
> > >>
> > >> Instant payments need a security upgrade, yes.
> > >>
> > >> --
> > >> Jeff Garzik
> > >> Bitcoin core developer and open source evangelist
> > >> BitPay, Inc.      https://bitpay.com/
> > >>
> > >>
> > >>
> ------------------------------------------------------------------------------
> > >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > >> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards
> > >> with Interactivity, Sharing, Native Excel Exports, App Integration &
> more
> > >> Get technology previously reserved for billion-dollar corporations,
> FREE
> > >>
> > >>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> > >> _______________________________________________
> > >> Bitcoin-development mailing list
> > >> Bitcoin-development@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >>
> > >
>
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
>
> ----------------------------------------------------------------------------
> Troy Benjegerdes                 'da hozer'
> hozer@hozed.org
> 7 elements      earth::water::air::fire::mind::spirit::soul
> grid.coop
>
>       Never pick a fight with someone who buys ink by the barrel,
>          nor try buy a hacker who makes money by the megahash
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Troy Benjegerdes]

Bitcoin was/is a disruptive technology for credit card payment processors,
and replace-by-fee/stag-hunt is a disruptive technology for Bitcoin payment
processors.

I think whether you call it scorched earth is a bit more of a reflection of
whether you stand to make money, or lose money from the distruption.

Personally, I think 'first-seen' is a dangerous scorched-earth policy that
only benefits the people who own the internet routers that determine what
is seen first.

But from the standpoint of consensus, can we at least agree that it's a
*node policy* decision, and the market particpants should be free to choose
whichever policy works best for them?

Otherwise, I think the only way to make 'first-seen' work is by adding 
a timestamp to CTransaction.

On Sat, Feb 21, 2015 at 05:47:28PM -0500, Jeff Garzik wrote:
> "scorched earth" refers to the _real world_ impact such policies would
> have on present-day 0-conf usage within the bitcoin community.
> 
> All payment processors AFAIK process transactions through some scoring
> system, then accept 0-conf transactions for payments.
> 
> This isn't some theoretical exercise.  Like it or not many use
> insecure 0-conf transactions for rapid payments.  Deploying something
> that makes 0-conf transactions unusable would have a wide, negative
> impact on present day bitcoin payments, thus "scorched earth"
> 
> Without adequate decentralized solutions for instant payments,
> deploying replace-by-fee widely would simply push instant transactions
> even more into the realm of centralized, walled-garden services.
> 
> 
> 
> 
> 
> 
> On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach <mark@friedenbach.org> wrote:
> > Thank you Jorge for the contribution of the Stag Hunt terminology. It is
> > much better than a politically charged "scorched earth".
> >
> > On Feb 21, 2015 11:10 AM, "Jorge Timón" <jtimon@jtimon.cc> wrote:
> >>
> >> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> >> based on game theory. I would have preferred "stag hunt" since that's
> >> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
> >> but I like the protocol and I think it would be interesting to
> >> integrate it in the  payment protocol.
> >> Even if that protocol didn't existed or didn't worked, replace-by-fee
> >> is purely part of a node's policy, not part of consensus.
> >> >From the whitepaper, 0 conf transactions being secure by the good will
> >> of miners was never an assumption, and it is clear to me that the
> >> system cannot provide those guaranties based on such a weak scheme. I
> >> believe thinking otherwise is naive.
> >> As to consider non-standard policies "an attack to bitcoin" because
> >> "that's not how bitcoin used to work", then I guess minimum relay fee
> >> policies can also be considered "an attack to bitcoin" on the same
> >> grounds.
> >> Lastly, "first-seen-wins" was just a simple policy to bootstrap the
> >> system, but I expect that most nodes will eventually move to policies
> >> that are economically rational for miners such as replace-by-fee.
> >> Not only I disagree this will be "the end of bitcoin" or "will push
> >> the price of the btc miners are mining down", I believe it will be
> >> something good for bitcoin.
> >> Since this is apparently controversial I don't want to push for
> >> replace-by-fee to become the new standard policy (something that would
> >> make sense to me). But once the policy code is sufficiently modular as
> >> to support several policies I would like bitcoin core to have a
> >> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
> >> policy checks at all).
> >> One step at a time I guess...
> >>
> >>
> >> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
> >> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
> >> >>
> >> >>
> >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> >> >> >
> >> >> > Most money/payment systems include some method to reverse or undo
> >> >> > payments made in error. In these systems, the longer settlement
> >> >> > times you mention below are a feature, not a bug, and give more
> >> >> > time for a human to react to errors and system failures.
> >> >> >
> >> >>
> >> >> Settlement has to be final somewhere. That is the whole point of it.
> >> >> Transfer costs in current electronic payment systems are a direct
> >> >> consequence of their non-finality. That's the point Satoshi was making
> >> >> in the introduction to the whitepaper: "With the possibility of
> >> >> reversal, the need for trust spreads".
> >> >
> >> > The problem with that statement is I trust a merchant that I went into
> >> > a store and made a payment with personally more than I trust the
> >> > firmware
> >> > on my hard drive [1].
> >> >
> >> > The attack surface of devices in your computer is huge. A motivated
> >> > attacker
> >> > just needs to get an intern into a company that makes some kind of
> >> > component
> >> > or system that's in your computer, cloud server, hardware wallet, or
> >> > what
> >> > have you that has firmware capable of reading your private keys.
> >> >
> >> > With the possibility of mass trojaned hardware, if we are going to trust
> >> > the system, it must somehow allow reversal through a human-in-the-loop.
> >> >
> >> >> There is nothing wrong with having reversible mechanisms built on top
> >> >> of Bitcoin, and indeed it makes sense for most activity to happen at
> >> >> those higher layers. It's easy to build things that way, but
> >> >> impossible to build them the other way: you can't build a
> >> >> non-reversible layer on top of a reversible layer.
> >> >
> >> > We built 'reliable' TCP on top of unreliable ethernet networks. My
> >> > experience
> >> > with networking was if you tried to guarantee message delivery at the
> >> > lowest
> >> > level, the system got exceedingly complicated, expensive, and brittle.
> >> >
> >> > Most applications, in particular paying someone you already trust, are
> >> > quite
> >> > happy running on reversible systems, and in some cases more reliable and
> >> > lower risk. (carrying non-reversible cash is generally considered risky)
> >> >
> >> > The problem is that if the base currency is assumed to be
> >> > non-reversible,
> >> > then it's brittle and becomes 'too big to fail'.
> >> >
> >> > Where the blockchain improves on everything else is in transparency. If
> >> > you
> >> > reverse transactions a lot, it will be obvious from an analysis. I would
> >> > much
> >> > rather deal with a known, predictable, and relatively continous
> >> > transaction
> >> > reversal rate (percentage) than have to deal with sudden failures where
> >> > some anonymous bad actor makes off with a fortune.
> >> >
> >> > We already have zero-conf double-spend transaction reversal, why not
> >> > explicitly
> >> > extend that a little in a way that senders and receivers have a choice
> >> > to
> >> > use it, or not?
> >> >
> >> >
> >> > [1]
> >> > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> > with Interactivity, Sharing, Native Excel Exports, App Integration &
> >> > more
> >> > Get technology previously reserved for billion-dollar corporations, FREE
> >> >
> >> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> >> > _______________________________________________
> >> > Bitcoin-development mailing list
> >> > Bitcoin-development@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> >> Get technology previously reserved for billion-dollar corporations, FREE
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> > ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> 
> 
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Lawrence Nahum]

Mike Hearn <mike <at> plan99.net> writes:

> 
> 
> I know you will ignore this as usual, but the entire replace-by-fee folly 
is based on your fundamental misunderstanding of miner incentives.

I disagree, I think it is inevitable (but then of course I'm probably biased 
and why wouldn't I disagree given I run a service that allows for zero 
confirmation/double spend protection with third party trust.)

Fixing it now avoids having people build on top of very weak/broken 
foundations (see Coinbase https://botbot.me/freenode/bitcoin-
wizards/msg/29818058/) which would cause bigger problems down the line.

One thing I don't understand from your position is how do you propose 
handling transactions being stuck for days or longer because of low fees?

Even with floating fees you can have a sudden inflow of high fees 
transactions taking over post broadcasting your transaction.

I also assume restricted replacement is very hard, especially from a UX point 
of view and adds undue complexity

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tom Harding]

On 2/11/2015 10:47 PM, Peter Todd wrote:
> ... replace-by-fee ...

Replace-by-fee creates the power to repudiate an entire tree of 
payments, and hands this power individually to the owner of each input 
to the top transaction.  Presumably this is why the original replacement 
code at least required that all of the same inputs be spent, even if the 
original outputs got jilted.

Replace-by-fee strengthens the existing *incentive discontinuity* at 
1-conf, and shouts it from the rooftops.  There is diffraction around 
hard edges.  Expect more Finney attacks, even paid ones, if 
replace-by-fee becomes common.  Regardless of how reliable 0-conf can 
ever be (much more reliable than today imho), discontinuities are very 
undesirable.

There is no money in mining other people's double-spends.  Miners of all 
sizes would welcome a fair way to reduce them to improve the quality of 
the currency, whether or not that way is DSDW.  You mischaracterize DSDW 
as being in any way trust- or vote-based.  It is based on statistics, 
which is bitcoin-esque to the core.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Josh Lehan]

Probably out of my league, but I will respond here anyway.

I am in favor of replace-by-fee, but only if it were to be applied to a very limited subset of transactions: namely, transactions that seek to supplement, not replace, the original transaction.

In other words, a replacement transaction would only be accepted if it were adding additional value (additional transaction inputs and/or outputs).  Otherwise, the original transaction would stand.  Reducing any of the promised outputs, or diverting them to some other recipient, would not be allowed.

This would solve the problem of a stuck transaction: a transaction that is taking seemingly forever to confirm, because one forgot to pay the miner’s fee, something that happened to me once.

Stuck transactions are bad, both for the recipient (they aren’t getting paid) and the sender (some of their funds are still tied up, because change from that transaction has not returned yet).

With replace-by-fee, the sender of a transaction can send it again, with additional inputs (to pay more miner’s fees) and additional outputs (to receive the change, if any is desired, from those inputs).  So, now the sender is self-empowered to “shove through” their stuck transaction, by voluntarily choosing to pay more for it, a market-driven solution to the problem.

There are really good reasons to not allow replace-by-fee as a general policy that can apply to all transactions, as others have already mentioned.  However, I still believe the idea has merit, for this special limited case of supplementing a transaction.

Josh Lehan


> On Feb 11, 2015, at 22:47, Peter Todd <pete@petertodd.org> wrote:
> 
> My replace-by-fee patch is now available for the v0.10.0rc4 release:
> 
>    https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
> 
> Along with demo scripts of the functionality:
> 
>    https://github.com/petertodd/replace-by-fee-tools
> 
> New to this version is a comprehensive set of unittests under
> qa/replace-by-fee
> 
> Additionally the preferential peering support now preferentially peers
> with Bitcoin XT¹ nodes that support Andresen/Harding's double-spend
> relaying² patch. While Bitcoin XT nodes don't accept double-spends into
> their mempool, they do relay them perfectly well and thus are an asset
> to those doing replace-by-fee mining.³
> 
> I've had a number of requests from miners for a version of
> replace-by-fee against Luke-Jr's Eligius patches⁴; I'll be also
> releasing that shortly once this release has undergone some more
> testing.
> 
> 
> What's replace-by-fee?
> ----------------------
> 
> Currently most Bitcoin nodes accept the first transaction they see
> spending an output to the mempool; all later transactions are rejected.
> Replace-by-fee changes this behavior to accept the transaction paying
> the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
> children are also considered - a chain of transactions is only replaced
> if the replacement has a higher fee than the sum of all replaced
> transactions.
> 
> Doing this aligns standard node behavior with miner incentives: earn the
> most amount of money per block. It also makes for a more efficient
> transaction fee marketplace, as transactions that are "stuck" due to bad
> fee estimates can be "unstuck" by double-spending them with higher
> paying versions of themselves. With scorched-earth techniques⁵ it gives
> a path to making zeroconf transactions economically secure by relying on
> economic incentives, rather than "honesty" and alturism, in the same way
> Bitcoin mining itself relies on incentives rather than "honesty" and
> alturism.
> 
> Finally for miners adopting replace-by-fee avoids the development of an
> ecosystem that relies heavily on large miners punishing smaller ones for
> misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
> attack miners who include doublespends in their blocks - an unavoidable
> consequence of imperfect p2p networking in a decentralized system - or
> even Hearn's proposal⁷ that a majority of miners be able to vote to
> confiscate the earnings of the minority and redistribute them at will.
> 
> 
> Installation
> ------------
> 
> Once you've compiled the replace-by-fee-v0.10.0rc4 branch just run your
> node normally. With -debug logging enabled, you'll see messages like the
> following in your ~/.bitcoin/debug.log indicating your node is replacing
> transactions with higher-fee paying double-spends:
> 
>    2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes
> 
> Additionally you can tell if you are connected to other replace-by-fee
> nodes, or Bitcoin XT nodes, by examining the service bits advertised by
> your peers:
> 
>    $ bitcoin-cli getpeerinfo | grep services | egrep '((0000000000000003)|(0000000004000001))'
>            "services" : "0000000000000003",
>            "services" : "0000000004000001",
>            "services" : "0000000004000001",
>            "services" : "0000000000000003",
>            "services" : "0000000004000001",
>            "services" : "0000000004000001",
>            "services" : "0000000000000003",
>            "services" : "0000000000000003",
> 
> Replace-by-fee nodes advertise service bit 26 from the experimental use
> range; Bitcoin XT nodes advertise service bit 1 for their getutxos
> support. The code sets aside a certain number of outgoing and incoming
> slots just for double-spend relaying nodes, so as long as everything is
> working you're node should be connected to like-minded nodes a within 30
> minutes or so of starting up.
> 
> If you *don't* want to advertise the fact that you are running a
> replace-by-fee node, just checkout a slightly earlier commit in git; the
> actual mempool changes are separate from the preferential peering
> commits. You can then connect directly to a replace-by-fee node using
> the -addnode command line flag.
> 
> 1) https://github.com/bitcoinxt/bitcoinxt
> 2) https://github.com/bitcoin/bitcoin/pull/3883
> 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
> 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
> 5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
> 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
> 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 000000000000000013c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tom Harding]

On 2/11/2015 10:47 PM, Peter Todd wrote:
> My replace-by-fee patch is now available for the v0.10.0rc4 release:
>
>      https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
>

This patch immediately simplifies successful double-spends of 
unconfirmed transactions.  But the idea that it "gives a path to making 
zeroconf transactions economically secure" is quite dubious.

* You don't provide sufficient means to detect and relay double-spends, 
which is necessary to trigger a scorched-earth reaction.  Not all 
double-spends will conform to your replacement rules.

   * Maybe XT nodes would help to overcome this.  But meanwhile, in the 
ANYONECANPAY design, Bob's replacement is a triple-spend.  Even XT nodes 
won't relay it.

* It's unclear when, if ever, any senders/receivers will actually try to 
use scorched-earth as a double-spend deterrent.


Also, this patch significantly weakens DoS protections:

* It removes the early conflict check, making all conflict processing 
more expensive

   * There is no attempt to protect against the same transaction being 
continually replaced with the fee bumped by a minimal amount.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

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

On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote:
> On 2/11/2015 10:47 PM, Peter Todd wrote:
> >My replace-by-fee patch is now available for the v0.10.0rc4 release:
> >
> >     https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
> >
> 
> This patch immediately simplifies successful double-spends of
> unconfirmed transactions.  But the idea that it "gives a path to
> making zeroconf transactions economically secure" is quite dubious.
> 
> * You don't provide sufficient means to detect and relay
> double-spends, which is necessary to trigger a scorched-earth
> reaction.  Not all double-spends will conform to your replacement
> rules.

No, OTOH if they don't then the situation is no difference from what we
have now, and replace-by-fee does no harm. Meanwhile, relaying of bare
double-spend signatures can be implemented in the future, as I suggested
last year for your/Andresen's double-spend relaying patch.

Did you notice the even more obvious way to defeat ANYONECANPAY scorched
earth with that patch?

>   * Maybe XT nodes would help to overcome this.  But meanwhile, in
> the ANYONECANPAY design, Bob's replacement is a triple-spend.  Even
> XT nodes won't relay it.

So? RBF nodes will.

> * It's unclear when, if ever, any senders/receivers will actually
> try to use scorched-earth as a double-spend deterrent.

I suspect many won't, because few people need to rely on unconfirmed
transactions anyway.

> Also, this patch significantly weakens DoS protections:
> 
> * It removes the early conflict check, making all conflict
> processing more expensive

If you're going to consider replacement, conflict processing will
definitely be more expensive. :)

An actual DoS attacker would do their DoS attack in a way where conflict
processing has nothing to do with it, so this change does no actual
harm.

>   * There is no attempt to protect against the same transaction
> being continually replaced with the fee bumped by a minimal amount.

What exact git commit were you looking at? I did have an early one that
did have a bug along those lines, now fixed.

The current version ensures every replacement pays at least as much
additional fees as would normally cost to broadcast that much data on
the network, and additionally requires the fees/KB to always increase;
under all circumstances it should be no more of a DoS threat than
low-fee transactions are otherwise. I'd like to know if there is a flaw
in that code however!

-- 
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Tom Harding]

On 2/22/2015 9:12 AM, Peter Todd wrote:
> Did you notice the even more obvious way to defeat ANYONECANPAY 
> scorched earth with that patch? 

Let's see.  I could pay 10 people 1 BTC each with one tx, then 
double-spend it with fees of 2BTC.  Now at least three of the 10 have to 
work together if they want to scorched-earth me, since an individual or 
two-party claw-back wouldn't have high enough fees. Oops!

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Not that issue - that's both easily avoidable, and has nothing to do with the replace-by-fee patch. I'm talking about something in the specific patch - good test to see if you've fully reviewed it.


On 22 February 2015 14:25:24 GMT-05:00, Tom Harding <tomh@thinlink.com> wrote:
>On 2/22/2015 9:12 AM, Peter Todd wrote:
>> Did you notice the even more obvious way to defeat ANYONECANPAY
>> scorched earth with that patch?
>
>Let's see.  I could pay 10 people 1 BTC each with one tx, then
>double-spend it with fees of 2BTC.  Now at least three of the 10 have
>to
>work together if they want to scorched-earth me, since an individual or
>
>two-party claw-back wouldn't have high enough fees. Oops!
-----BEGIN PGP SIGNATURE-----

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6k8q
AAoJEMCF8hzn9LncssUH/0acS1lhG8igRWBusnpDD+on+ryXNlTDKZGExzUKy7Wq
7SzYfMX8LAf/0Wbzs6wtyGzVjQOGmcM0XTAFN+Rp2rP3ZuSzAqO41Re+aUkiB67y
4PD8R05DmDgbc257HwIQM1aa+NPzzW5p8C+HnyZKpUqMNUAZOUVks22oRGywUXQY
WrNKiSFQMxW0l1thjX63/x3iXjV92gxyd9qWK8uPAokwNEdULPU5S1mlZbji+MaJ
cfR6WB02JR/GHPDK1rwmM8vAwQY82CMOJK3HB+1Dx88NvN5Ucn+ppVFtNETHA5g8
e7UcFeXXeMRF2AMwc9lFEmYsXmSAMJrTFeO981KoOHs=
=fESj
-----END PGP SIGNATURE-----

[Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1

[Peter Todd]

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

My replace-by-fee patch is now available for the v0.10.1 release:

    https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1

No new features in this version; this is simply a rebase for the Bitcoin
Core v0.10.1 release. (there weren't even any merge conflicts) As with
the Bitcoin Core v0.10.1, it's recommended to upgrade.


The following text is the copied verbatim from the previous release:

What's replace-by-fee?
----------------------

Currently most Bitcoin nodes accept the first transaction they see
spending an output to the mempool; all later transactions are rejected.
Replace-by-fee changes this behavior to accept the transaction paying
the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
children are also considered - a chain of transactions is only replaced
if the replacement has a higher fee than the sum of all replaced
transactions.

Doing this aligns standard node behavior with miner incentives: earn the
most amount of money per block. It also makes for a more efficient
transaction fee marketplace, as transactions that are "stuck" due to bad
fee estimates can be "unstuck" by double-spending them with higher
paying versions of themselves. With scorched-earth techniques⁵ it gives
a path to making zeroconf transactions economically secure by relying on
economic incentives, rather than "honesty" and alturism, in the same way
Bitcoin mining itself relies on incentives rather than "honesty" and
alturism.

Finally for miners adopting replace-by-fee avoids the development of an
ecosystem that relies heavily on large miners punishing smaller ones for
misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
attack miners who include doublespends in their blocks - an unavoidable
consequence of imperfect p2p networking in a decentralized system - or
even Hearn's proposal⁷ that a majority of miners be able to vote to
confiscate the earnings of the minority and redistribute them at will.


Installation
------------

Once you've compiled the replace-by-fee-v0.10.1 branch just run your
node normally. With -debug logging enabled, you'll see messages like the
following in your ~/.bitcoin/debug.log indicating your node is replacing
transactions with higher-fee paying double-spends:

    2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes

Additionally you can tell if you are connected to other replace-by-fee
nodes, or Bitcoin XT nodes, by examining the service bits advertised by
your peers:

    $ bitcoin-cli getpeerinfo | grep services | egrep '((0000000000000003)|(0000000004000001))'
            "services" : "0000000000000003",
            "services" : "0000000004000001",
            "services" : "0000000004000001",
            "services" : "0000000000000003",
            "services" : "0000000004000001",
            "services" : "0000000004000001",
            "services" : "0000000000000003",
            "services" : "0000000000000003",

Replace-by-fee nodes advertise service bit 26 from the experimental use
range; Bitcoin XT nodes advertise service bit 1 for their getutxos
support. The code sets aside a certain number of outgoing and incoming
slots just for double-spend relaying nodes, so as long as everything is
working you're node should be connected to like-minded nodes a within 30
minutes or so of starting up.

If you *don't* want to advertise the fact that you are running a
replace-by-fee node, just checkout a slightly earlier commit in git; the
actual mempool changes are separate from the preferential peering
commits. You can then connect directly to a replace-by-fee node using
the -addnode command line flag.

1) https://github.com/bitcoinxt/bitcoinxt
2) https://github.com/bitcoin/bitcoin/pull/3883
3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html

-- 
'peter'[:-1]@petertodd.org
0000000000000000059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1

[Kevin Greene]

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

I feel compelled to re-share Mike Hearn's counter-argument *against *
replace-by-fee:
https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Please carefully consider the effects of replace-by-fee before applying
Peter's patch.

On Sun, May 3, 2015 at 9:36 PM, Peter Todd <pete@petertodd.org> wrote:

> My replace-by-fee patch is now available for the v0.10.1 release:
>
>     https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1
>
> No new features in this version; this is simply a rebase for the Bitcoin
> Core v0.10.1 release. (there weren't even any merge conflicts) As with
> the Bitcoin Core v0.10.1, it's recommended to upgrade.
>
>
> The following text is the copied verbatim from the previous release:
>
> What's replace-by-fee?
> ----------------------
>
> Currently most Bitcoin nodes accept the first transaction they see
> spending an output to the mempool; all later transactions are rejected.
> Replace-by-fee changes this behavior to accept the transaction paying
> the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
> children are also considered - a chain of transactions is only replaced
> if the replacement has a higher fee than the sum of all replaced
> transactions.
>
> Doing this aligns standard node behavior with miner incentives: earn the
> most amount of money per block. It also makes for a more efficient
> transaction fee marketplace, as transactions that are "stuck" due to bad
> fee estimates can be "unstuck" by double-spending them with higher
> paying versions of themselves. With scorched-earth techniques⁵ it gives
> a path to making zeroconf transactions economically secure by relying on
> economic incentives, rather than "honesty" and alturism, in the same way
> Bitcoin mining itself relies on incentives rather than "honesty" and
> alturism.
>
> Finally for miners adopting replace-by-fee avoids the development of an
> ecosystem that relies heavily on large miners punishing smaller ones for
> misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
> attack miners who include doublespends in their blocks - an unavoidable
> consequence of imperfect p2p networking in a decentralized system - or
> even Hearn's proposal⁷ that a majority of miners be able to vote to
> confiscate the earnings of the minority and redistribute them at will.
>
>
> Installation
> ------------
>
> Once you've compiled the replace-by-fee-v0.10.1 branch just run your
> node normally. With -debug logging enabled, you'll see messages like the
> following in your ~/.bitcoin/debug.log indicating your node is replacing
> transactions with higher-fee paying double-spends:
>
>     2015-02-12 05:45:20 replacing tx
> ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with
> c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for
> 0.00798 BTC additional fees, -1033 delta bytes
>
> Additionally you can tell if you are connected to other replace-by-fee
> nodes, or Bitcoin XT nodes, by examining the service bits advertised by
> your peers:
>
>     $ bitcoin-cli getpeerinfo | grep services | egrep
> '((0000000000000003)|(0000000004000001))'
>             "services" : "0000000000000003",
>             "services" : "0000000004000001",
>             "services" : "0000000004000001",
>             "services" : "0000000000000003",
>             "services" : "0000000004000001",
>             "services" : "0000000004000001",
>             "services" : "0000000000000003",
>             "services" : "0000000000000003",
>
> Replace-by-fee nodes advertise service bit 26 from the experimental use
> range; Bitcoin XT nodes advertise service bit 1 for their getutxos
> support. The code sets aside a certain number of outgoing and incoming
> slots just for double-spend relaying nodes, so as long as everything is
> working you're node should be connected to like-minded nodes a within 30
> minutes or so of starting up.
>
> If you *don't* want to advertise the fact that you are running a
> replace-by-fee node, just checkout a slightly earlier commit in git; the
> actual mempool changes are separate from the preferential peering
> commits. You can then connect directly to a replace-by-fee node using
> the -addnode command line flag.
>
> 1) https://github.com/bitcoinxt/bitcoinxt
> 2) https://github.com/bitcoin/bitcoin/pull/3883
> 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
> 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
> 5)
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
> 6)
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
> 7)
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9
>
>
> ------------------------------------------------------------------------------
> 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
>
>

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

[Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet

[Peter Todd]

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

My replace-by-fee patch is now available for the Bitcoin Core v0.10.2
release:

    https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2

This release fixes a serious DoS attack present in previous releases.
Upgrading is strongly recommended for relay nodes, and mandatory for
miners. Users of Luke-Jr's gentoo distribution should either disable RBF
until a patch is released, or run their node behind a patched node.

Previously replacements that spent outputs the transactions they
conflicted with would be accepted. This would lead to orphaned
transactions in the mempool, a potential bandwidth DoS attack for relay
nodes, and even worse, on mining nodes would cause Bitcoin to crash when
CreateNewBlock() was called.

Thanks goes to to Suhas Daftuar for finding this issue.


Additionally, while investigating this issue I found that
Andresen/Harding's relay doublespends patch¹, included in Bitcoin XT²,
also fails to verify that doublespends don't spend outputs of the
transactions they conflict with. As the transactions aren't accepted to
the mempool the issue is simply a variant of the bandwidth DoS attack
that's a well-known issue of Bitcoin XT. However, interestingly in
testing I found that Schildbach's Android Bitcoin Wallet³ fails to
detect this case, and displays the transaction as a valid unconfirmed
transaction, potentially leading to the user being defrauded with a
doublespend.  While a well-known issue in general - Schildbach's
implementation trusts peers to only send it valid transactions and
doesn't even detect doublespends it receives from peers - it's
interesting how in this case the attacker doesn't need to also do a
sybil attack.

1) https://github.com/bitcoin/bitcoin/pull/3883
2) https://github.com/bitcoinxt/bitcoinxt
3) https://play.google.com/store/apps/details?id=de.schildbach.wallet

-- 
'peter'[:-1]@petertodd.org
0000000000000000026ca21b4a83e1a818be96db4b532b7e9be2f60d47efff0a

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]