[Bitcoin-development] F2Pool has enabled full replace-by-fee

[Peter Todd]

Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.


I'm a user. What does this mean for me?
---------------------------------------

In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.

Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.

Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.

In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.


I'm a business. What does this mean for me?
-------------------------------------------

If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.

If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.


I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------

Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.

Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.

Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.


Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------

For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.

The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.

Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.


What about centralised wallets?
-------------------------------

Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.


Confidence factors
------------------

Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.

None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁎ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.


Transaction processing contracts with miners
--------------------------------------------

The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.

There's a number of serious problems with this:

1) Mining contracts can be used to double-spend

...even when they're being used "honestly".

Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.

Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.

Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.


2) They still don't work, without 51% attacking other miners

Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.


3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions

Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.

Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.


Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------

I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.

If you choose to take a risk you should accept the consequences.


How do I actually use full RBF?
-------------------------------

First get the full-RBF patch to v0.10.2:

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

The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
Secondly, try out my replace-by-fee-tools at:

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

You can watch double-spends on the network here:

http://respends.thinlink.com/


References
----------

1) "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, May 23rd 2015, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-***@lists.sourceforge.net/msg07795.html

2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734

3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations

4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/

5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html

6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-***@lists.sourceforge.net/msg07813.html

7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,
Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
http://eprint.iacr.org/2015/578

[Gavin Andresen]

I just sent the following email to F2Pool:


I was disappointed to see Peter Todd claiming that you have (or will?) run
his replace-by-fee patch.

I strongly encourage you to wait until most wallet software supports
replace-by-fee before doing that, because until that happens replace-by-fee
just makes it easier to steal from bitcoin-accepting merchants.

I will tell you the same thing about 8MB blocks: until most merchants
support bigger blocks I will strongly encourage you keep creating
less-than-1MB blocks. If we want Bitcoin to succeed more quickly, we should
all be thinking about what is good for the whole system: users, merchants,
exchanges and miners.

As always, if you have questions or concerns feel free to email me.

[Peter Todd]

Post by Gavin Andresen
I was disappointed to see Peter Todd claiming that you have (or will?) run
his replace-by-fee patch.
I strongly encourage you to wait until most wallet software supports
replace-by-fee before doing that, because until that happens replace-by-fee
just makes it easier to steal from bitcoin-accepting merchants.

Do you mean just full-RBF, or FSS-RBF as well?


Speaking of, could we get a confirmation that Coinbase is, or is not,
one of the merchant service providers trying to get hashing power
contracts with mining pools for guaranteed transaction acceptance? IIRC
you are still an advisor to them. This is a serious concern for the
reasons I outlined in my post.

Equally if anyone else from Coinbase would like to chime in that'd be
great.

[Adrian Macneil]

Post by Peter Todd
For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by the 20%.

This seems to be more of a problem with centralized mining than zeroconf
transactions.

Speaking of, could we get a confirmation that Coinbase is, or is not,

Post by Peter Todd
one of the merchant service providers trying to get hashing power
contracts with mining pools for guaranteed transaction acceptance? IIRC
you are still an advisor to them. This is a serious concern for the
reasons I outlined in my post.

We have no contracts in place or plans to do this that I am aware of.

However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into
this as a way to prevent fraud.

In the long term, I would love to see a safe, decentralized solution for
accepting zeroconf transactions. However, right now there is no such
solution supported by any wallets in use, and I don't think breaking the
current bitcoin behavior for everyone is the best way to achieve this.

Adrian

[Peter Todd]

Post by Adrian Macneil

Post by Peter Todd
For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by the 20%.

This seems to be more of a problem with centralized mining than zeroconf
transactions.

You're mistaking cause and effect: the contracts will drive
centralization of mining, as only the larger, non-anonymous, players
have the ability to enter into such contracts.

Post by Adrian Macneil
Speaking of, could we get a confirmation that Coinbase is, or is not,

Post by Peter Todd
one of the merchant service providers trying to get hashing power
contracts with mining pools for guaranteed transaction acceptance? IIRC
you are still an advisor to them. This is a serious concern for the
reasons I outlined in my post.

We have no contracts in place or plans to do this that I am aware of.
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into
this as a way to prevent fraud.

What happens if the mining pools who are mining double-spends aren't
doing it delibrately? Sybil attacking pools appears to have been done
before to get double-spends though, equally there are many other changes
the reduce the reliability of transaction confirmations. For instance
the higher demands on bandwidth of a higher blocksize will inevitably
reduce the syncronicity of mempools, resulting in double-spend
opportunities. Similarly many proposals to limit mempool size allow
zeroconf double-spends.

In that case would you enter into such contracts?

[Adrian Macneil]

Post by Peter Todd

Post by Adrian Macneil
We have no contracts in place or plans to do this that I am aware of.
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into
this as a way to prevent fraud.

What happens if the mining pools who are mining double-spends aren't
doing it delibrately? Sybil attacking pools appears to have been done
before to get double-spends though, equally there are many other changes
the reduce the reliability of transaction confirmations. For instance
the higher demands on bandwidth of a higher blocksize will inevitably
reduce the syncronicity of mempools, resulting in double-spend
opportunities. Similarly many proposals to limit mempool size allow
zeroconf double-spends.
In that case would you enter into such contracts?

We take it as it comes.

Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.

If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).

Long term we would prefer to see an open, decentralized solution, such as
payment channels / green addresses / lightening networks. However, I think
as a community we are a long way away from choosing a standard here and
implementing it across all popular wallet software and merchant processors.

Adrian

[Peter Todd]

Post by Adrian Macneil

Post by Peter Todd
In that case would you enter into such contracts?

We take it as it comes.
Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.

Unless you're sybil attacking the network and miners, consuming valuable
resources and creating systemic risks of failure like we saw with
Chainalysis, I don't see how you're getting "very small" double-spend
probabilities.

You realise how the fact that F2Pool is using full-RBF right now does
strongly suggest that the chances of a double-spend are not only low,
but more importantly, vary greatly? Any small change in relaying policy
or even network conditions creates opportunities to double-spend.

Post by Adrian Macneil
If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).

You know, you're creating an interesting bit of game theory here: if I'm
a miner who doesn't already have a mining contract, why not implement
full-RBF to force Coinbase to offer me one? One reason might be because
other miners with such a contract - a majority - are going to be asked
by Coinbase to reorg you out of the blockchain, but then we have a
situation where a single entity has control of the blockchain.

For the good of Bitcoin, and your own company, you'd do well to firmly
state that under no condition will Coinbase ever enter into mining
contracts.

[Adrian Macneil]

Post by Peter Todd
Unless you're sybil attacking the network and miners, consuming valuable
resources and creating systemic risks of failure like we saw with
Chainalysis, I don't see how you're getting "very small" double-spend
probabilities.

So connecting to many nodes just because we can and it's not technically
prevented is bad for the network and creating systemic risks of failure,
but relaying harmful double spend transactions just because you can and
it's not technically prevented, is good for everyone?

Post by Peter Todd
You know, you're creating an interesting bit of game theory here: if I'm
a miner who doesn't already have a mining contract, why not implement
full-RBF to force Coinbase to offer me one? One reason might be because
other miners with such a contract - a majority - are going to be asked
by Coinbase to reorg you out of the blockchain, but then we have a
situation where a single entity has control of the blockchain.

If someone did enter into contracts with miners to mine certain
transactions, and had a guarantee that the miners would not build on
previous blocks which included double spends, then they would only need
contracts with 51% of the network anyway. So it wouldn't really matter if
you were a small time miner and wanted to run full-RBF.

Post by Peter Todd
For the good of Bitcoin, and your own company, you'd do well to firmly
state that under no condition will Coinbase ever enter into mining
contracts.

I don't personally see what good this does for bitcoin. Now you are
suggesting that we should prevent a 51% attack by using policy and
promises, rather than a technical solution. How is this any better than us
relying on existing double spend rules which are based on policy and
promises?

[Peter Todd]

Post by Adrian Macneil

Post by Peter Todd
Unless you're sybil attacking the network and miners, consuming valuable
resources and creating systemic risks of failure like we saw with
Chainalysis, I don't see how you're getting "very small" double-spend
probabilities.

So connecting to many nodes just because we can and it's not technically
prevented is bad for the network and creating systemic risks of failure,

Well it is actually; that's why myself, Wladimir van der Laan, and
Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
attack.

The Bitcoin P2P network is resilliant to failure when the chance of any
one node going down is uncorrelated with others. For instance if you
accidentally introduced a bug in your nodes that failed to relay
transactions/blocks properly, you'd simultaneously be disrupting a large
portion of the network all at once.

How many nodes is Coinbase connecting too? What software are they
running? What subnets are they using? In particular, are they all on one
subnet or multiple?

Post by Adrian Macneil
but relaying harmful double spend transactions just because you can and
it's not technically prevented, is good for everyone?

You realise that Hearn/Andresen/Harding's double-spend-relaying patch,
included in Bitcoin XT, relays double-spend transactions right? Do you
consider that harmful?

Post by Adrian Macneil

Post by Peter Todd
You know, you're creating an interesting bit of game theory here: if I'm
a miner who doesn't already have a mining contract, why not implement
full-RBF to force Coinbase to offer me one? One reason might be because
other miners with such a contract - a majority - are going to be asked
by Coinbase to reorg you out of the blockchain, but then we have a
situation where a single entity has control of the blockchain.

If someone did enter into contracts with miners to mine certain
transactions, and had a guarantee that the miners would not build on
previous blocks which included double spends, then they would only need
contracts with 51% of the network anyway. So it wouldn't really matter if
you were a small time miner and wanted to run full-RBF.

But of course, you'd never 51% the network right? After all it's not
possible to guarantee that your miner won't mine double-spends, as there
is no single consensus definition of which transaction came first, nor
can there be.

Or do you see things differently? If I'm a small miner should I be
worried my blocks might be rejected by the majority with hashing power
contracts because I'm unable to predict which transactions Coinbase
believes should go in the blockchain?

Post by Adrian Macneil

Post by Peter Todd
For the good of Bitcoin, and your own company, you'd do well to firmly
state that under no condition will Coinbase ever enter into mining
contracts.

I don't personally see what good this does for bitcoin. Now you are
suggesting that we should prevent a 51% attack by using policy and
promises, rather than a technical solution. How is this any better than us
relying on existing double spend rules which are based on policy and
promises?

Well, I think I've shown how dangerous mining contracts can be to the
overall health of the Bitcoin ecosystem; I'm simply asking you to
promise not to make use of this dangerous option regardless of what
happens. Like I said, if for whatever reason the first-seen mempool
behavior proves to be insufficient at preventing double-spends from your
perspective, you did suggest you might use mining contracts to ensure
txs you want mined get mined, over others.


1) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/

[Adrian Macneil]

Post by Peter Todd

Post by Adrian Macneil
So connecting to many nodes just because we can and it's not technically
prevented is bad for the network and creating systemic risks of failure,

Well it is actually; that's why myself, Wladimir van der Laan, and
Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
attack.
The Bitcoin P2P network is resilliant to failure when the chance of any
one node going down is uncorrelated with others. For instance if you
accidentally introduced a bug in your nodes that failed to relay
transactions/blocks properly, you'd simultaneously be disrupting a large
portion of the network all at once.

This is exactly what your RBF patch is doing. By your own logic, nodes on
the network should be allowed to relay (or not relay) whatever they wish.

Post by Peter Todd
How many nodes is Coinbase connecting too? What software are they
running? What subnets are they using? In particular, are they all on one
subnet or multiple?

We're running about a dozen nodes running regular Bitcoin Core in various
subnets. We aren't doing anything particularly out of the ordinary here.
Nothing that would fall under your definition of a sybil attack or harmful
to the network.

Post by Peter Todd

Post by Adrian Macneil
You know, you're creating an interesting bit of game theory here: if I'm

Post by Peter Todd
a miner who doesn't already have a mining contract, why not implement
full-RBF to force Coinbase to offer me one? One reason might be because
other miners with such a contract - a majority - are going to be asked
by Coinbase to reorg you out of the blockchain, but then we have a
situation where a single entity has control of the blockchain.

If someone did enter into contracts with miners to mine certain
transactions, and had a guarantee that the miners would not build on
previous blocks which included double spends, then they would only need
contracts with 51% of the network anyway. So it wouldn't really matter if
you were a small time miner and wanted to run full-RBF.

But of course, you'd never 51% the network right? After all it's not
possible to guarantee that your miner won't mine double-spends, as there
is no single consensus definition of which transaction came first, nor
can there be.
Or do you see things differently? If I'm a small miner should I be
worried my blocks might be rejected by the majority with hashing power
contracts because I'm unable to predict which transactions Coinbase
believes should go in the blockchain?

You seem so concerned that we are actively trying to harm or control the
network. We're simply trying to drive bitcoin adoption by making it easy
for people to spend their bitcoin with merchants online. The problems we
face are no different from other merchant processors, or small independent
merchants accepting online or point-of-sale payments.

We've historically had relatively little interest in what miners were doing
(until RBF came out) - for the most part it didn't affect our business.
However, most large merchants would be simply uninterested in accepting
bitcoin if we forced their customers to wait 10-60 minutes for their
payments to confirm. Many have inventory management systems which can not
even place items on hold that long.

If full-RBF sees any significant adoption by miners, then it will actively
harm bitcoin adoption by reducing or removing the ability for online or POS
merchants to accept bitcoin payments at all. I do not see a single benefit
to running full-RBF.

FWIW, I'm fine with the first-seen-safe RBF, that seems like a sensible
addition and a good way to allow fees to be added or increased on existing
transactions, without harming existing applications of bitcoin.

Adrian

[Peter Todd]

Post by Adrian Macneil

Post by Peter Todd

Post by Adrian Macneil
So connecting to many nodes just because we can and it's not technically
prevented is bad for the network and creating systemic risks of failure,

Well it is actually; that's why myself, Wladimir van der Laan, and
Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
attack.
The Bitcoin P2P network is resilliant to failure when the chance of any
one node going down is uncorrelated with others. For instance if you
accidentally introduced a bug in your nodes that failed to relay
transactions/blocks properly, you'd simultaneously be disrupting a large
portion of the network all at once.

This is exactly what your RBF patch is doing. By your own logic, nodes on
the network should be allowed to relay (or not relay) whatever they wish.

Ah, seems you misunderstand the problem.

By properly we're concerned that things do get relayed, not that they do
not. In particularl with blocks a fairly to relay valid blocks will
quickly lead to a loss of consensus.

Post by Adrian Macneil

Post by Peter Todd
How many nodes is Coinbase connecting too? What software are they
running? What subnets are they using? In particular, are they all on one
subnet or multiple?

We're running about a dozen nodes running regular Bitcoin Core in various
subnets. We aren't doing anything particularly out of the ordinary here.
Nothing that would fall under your definition of a sybil attack or harmful
to the network.

Right, so those dozen nodes, how many outgoing connections are they
making?

Post by Adrian Macneil

Post by Peter Todd
But of course, you'd never 51% the network right? After all it's not
possible to guarantee that your miner won't mine double-spends, as there
is no single consensus definition of which transaction came first, nor
can there be.
Or do you see things differently? If I'm a small miner should I be
worried my blocks might be rejected by the majority with hashing power
contracts because I'm unable to predict which transactions Coinbase
believes should go in the blockchain?

You seem so concerned that we are actively trying to harm or control the
network. We're simply trying to drive bitcoin adoption by making it easy
for people to spend their bitcoin with merchants online. The problems we
face are no different from other merchant processors, or small independent
merchants accepting online or point-of-sale payments.
We've historically had relatively little interest in what miners were doing
(until RBF came out) - for the most part it didn't affect our business.
However, most large merchants would be simply uninterested in accepting
bitcoin if we forced their customers to wait 10-60 minutes for their
payments to confirm. Many have inventory management systems which can not
even place items on hold that long.

While your goals may be reasonable, again, the question is how are you
going to achieve them? Do you accept that you may be in a position where
you can't guarantee confirmations? Again, what's your plan to deal with
this? For instance, I know Coinbase is contractually obliged to accept
zeroconf payments with at least some of your customers - how strong are
those agreements?

What we're worried about is your plan appears to include nothing
concrete beyond the possibility of getting contracts with hashing power,
maybe even just a majority of hashing power. This is something that
should concern everyone in the Bitcoin ecosystem, and it'd help if you
clearly stated what your intentions are.

[Matt Whitlock]

Post by Adrian Macneil
If full-RBF sees any significant adoption by miners, then it will actively
harm bitcoin adoption by reducing or removing the ability for online or POS
merchants to accept bitcoin payments at all.

Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. The reason we don't yet see such technology permeating the ecosystem is because, to date, zero-conf transactions have been irreversible "enough," but this has only been a happy accident; it was never promised, and it should not be relied upon.

------------------------------------------------------------------------------

[Frank Flores]

Has anyone from Mycelium weighed in on this? Is their doublespend attack
detection broken with this kind of irresponsible behavior?

Post by Adrian Macneil

Post by Adrian Macneil
If full-RBF sees any significant adoption by miners, then it will

actively

Post by Adrian Macneil
harm bitcoin adoption by reducing or removing the ability for online or

POS

Post by Adrian Macneil
merchants to accept bitcoin payments at all.

Retail POS merchants probably should not be accepting vanilla Bitcoin
payments, as Bitcoin alone does not (and cannot) guarantee the
irreversibility of a transaction until it has been buried several blocks
deep in the chain. Retail merchants should be requiring a co-signature from
a mutually trusted co-signer that vows never to sign a double-spend. The
reason we don't yet see such technology permeating the ecosystem is
because, to date, zero-conf transactions have been irreversible "enough,"
but this has only been a happy accident; it was never promised, and it
should not be relied upon.
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Jeff Garzik]

Double spend detection is by definition best-effort.

The purpose of bitcoin is to provide security (confirmations) to otherwise
insecure, possibly double spent transactions.

Post by Frank Flores
Has anyone from Mycelium weighed in on this? Is their doublespend attack
detection broken with this kind of irresponsible behavior?

Post by Adrian Macneil

Post by Adrian Macneil
If full-RBF sees any significant adoption by miners, then it will

actively

Post by Adrian Macneil
harm bitcoin adoption by reducing or removing the ability for online or

POS

Post by Adrian Macneil
merchants to accept bitcoin payments at all.

Retail POS merchants probably should not be accepting vanilla Bitcoin
payments, as Bitcoin alone does not (and cannot) guarantee the
irreversibility of a transaction until it has been buried several blocks
deep in the chain. Retail merchants should be requiring a co-signature from
a mutually trusted co-signer that vows never to sign a double-spend. The
reason we don't yet see such technology permeating the ecosystem is
because, to date, zero-conf transactions have been irreversible "enough,"
but this has only been a happy accident; it was never promised, and it
should not be relied upon.
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
*MONEY IS OVER!*
IF YOU WANT IT
<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Andreas Petersson]

I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.

In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
and the fraud frequency is also much lower.

0-conf concerns were never a problem in practice. except for 2-way atms
i have never heard of a problem that was caused by double spends.
while adding these measures is generally positive, requiring them means
excluding 99.9% of the potential users. so you might as well not do it.

RBF as implemented by F2Pool just flat out lowers Bitcoins utility
value. So it's a bad thing.

for any online or automated system, waiting for a handful of
confirmations was always recommended practice.

Post by Matt Whitlock
Retail POS merchants probably should not be accepting vanilla Bitcoin
payments, as Bitcoin alone does not (and cannot) guarantee the
irreversibility of a transaction until it has been buried several
blocks deep in the chain. Retail merchants should be requiring a
co-signature from a mutually trusted co-signer that vows never to sign
a double-spend.

[Mark Friedenbach]

What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.

Post by Andreas Petersson
I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.
In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
and the fraud frequency is also much lower.
0-conf concerns were never a problem in practice. except for 2-way atms
i have never heard of a problem that was caused by double spends.
while adding these measures is generally positive, requiring them means
excluding 99.9% of the potential users. so you might as well not do it.
RBF as implemented by F2Pool just flat out lowers Bitcoins utility
value. So it's a bad thing.
for any online or automated system, waiting for a handful of
confirmations was always recommended practice.

Post by Matt Whitlock
Retail POS merchants probably should not be accepting vanilla Bitcoin
payments, as Bitcoin alone does not (and cannot) guarantee the
irreversibility of a transaction until it has been buried several
blocks deep in the chain. Retail merchants should be requiring a
co-signature from a mutually trusted co-signer that vows never to sign
a double-spend.

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

[Aaron Voisine]

Post by Mark Friedenbach
What retail needs is escrowed microchannel hubs (what lightning provides,

for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.

They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.


Aaron Voisine
co-founder and CEO
breadwallet.com

Post by Mark Friedenbach
What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.

Post by Andreas Petersson
I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.
In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
and the fraud frequency is also much lower.
0-conf concerns were never a problem in practice. except for 2-way atms
i have never heard of a problem that was caused by double spends.
while adding these measures is generally positive, requiring them means
excluding 99.9% of the potential users. so you might as well not do it.
RBF as implemented by F2Pool just flat out lowers Bitcoins utility
value. So it's a bad thing.
for any online or automated system, waiting for a handful of
confirmations was always recommended practice.

Post by Matt Whitlock
Retail POS merchants probably should not be accepting vanilla Bitcoin
payments, as Bitcoin alone does not (and cannot) guarantee the
irreversibility of a transaction until it has been buried several
blocks deep in the chain. Retail merchants should be requiring a
co-signature from a mutually trusted co-signer that vows never to sign
a double-spend.

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

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

[Eric Lombrozo]

It all comes down to managing risk. If you’ve got a decent risk model with capped losses and safe recovery mechanisms
and it’s still profitable
it’s fine. But most payment processors and merchants right now probably don’t have particularly good risk models and are making many dangerous assumptions
and probably would not be able to gracefully handle very many risk scenarios.

- Eric Lombrozo

What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe.

They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine.
Aaron Voisine
co-founder and CEO
breadwallet.com <http://breadwallet.com/>
What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe.
I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.
In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
and the fraud frequency is also much lower.
0-conf concerns were never a problem in practice. except for 2-way atms
i have never heard of a problem that was caused by double spends.
while adding these measures is generally positive, requiring them means
excluding 99.9% of the potential users. so you might as well not do it.
RBF as implemented by F2Pool just flat out lowers Bitcoins utility
value. So it's a bad thing.
for any online or automated system, waiting for a handful of
confirmations was always recommended practice.

Retail POS merchants probably should not be accepting vanilla Bitcoin
payments, as Bitcoin alone does not (and cannot) guarantee the
irreversibility of a transaction until it has been buried several
blocks deep in the chain. Retail merchants should be requiring a
co-signature from a mutually trusted co-signer that vows never to sign
a double-spend.

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

[Luke Dashjr]

Post by Aaron Voisine
They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.

They never will be. You can get a decent rate of success merely by making one
transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg,
1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason
unconfirmed transactions aren't double spent today is because nobody is
seriously *trying*.

Luke

------------------------------------------------------------------------------

[Eric Lombrozo]

Post by Luke Dashjr

Post by Aaron Voisine
They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.

They never will be. You can get a decent rate of success merely by making one
transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg,
1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason
unconfirmed transactions aren't double spent today is because nobody is
seriously *trying*.
Luke

Newspapers are often sold in vending machines that make it possible for anyone to just pay the price of one and take them all
and most of the time they are not that carefully monitored. Why? Because most people have better things to do than try to steal a few newspapers. They probably were much more closely monitored earlier in their history
but once it became clear that despite the obvious attack vector very few people actually try to game it, vendors figured it wasn’t really that big a risk. Same thing applies to people trying to steal a piece of bubble gum at the cash register at a convenience store by double-spending.

- Eric Lombrozo

Post by Luke Dashjr
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Ivan Brightly]

Yep - similarly: you live in a neighborhood with a local coffee store. Sure
you could use a stolen credit card or a fake $5 bill, but it's not worth
the risk of being caught for a $3 coffee. And on the other side, the store
can deal with 1% of transactions getting reversed or having a fake bill so
they don't change their procedures.

Perfection is not necessary in all situations.

Post by Aaron Voisine

Post by Luke Dashjr

Post by Aaron Voisine
They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged

back. As

Post by Luke Dashjr

Post by Aaron Voisine
long as it's reasonably good in practice, that's fine.

They never will be. You can get a decent rate of success merely by

making one

Post by Luke Dashjr
transaction propagate fast (eg, 1 input, 1 output) and the other slow

(eg,

Post by Luke Dashjr
1000 inputs, 1000 outputs) and choosing your peers carefully. The only

reason

Post by Luke Dashjr
unconfirmed transactions aren't double spent today is because nobody is
seriously *trying*.
Luke

Newspapers are often sold in vending machines that make it possible for
anyone to just pay the price of one and take them all
and most of the time
they are not that carefully monitored. Why? Because most people have better
things to do than try to steal a few newspapers. They probably were much
more closely monitored earlier in their history
but once it became clear
that despite the obvious attack vector very few people actually try to game
it, vendors figured it wasn’t really that big a risk. Same thing applies to
people trying to steal a piece of bubble gum at the cash register at a
convenience store by double-spending.
- Eric Lombrozo
------------------------------------------------------------------------------

Post by Luke Dashjr
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Cameron Hejazi]

Post by Ivan Brightly
Yep - similarly: you live in a neighborhood with a local coffee store.
Sure you could use a stolen credit card or a fake $5 bill, but it's not
worth the risk of being caught for a $3 coffee. And on the other side, the
store can deal with 1% of transactions getting reversed or having a fake
bill so they don't change their procedures.

These analogies being brought are based on the goal of quick
payments, which is different from the goal of Bitcoin:
cryptographically sound, distributed consensus.

Post by Ivan Brightly
Perfection is not necessary in all situations.

If you want zeroconf transactions, first realize that this goal currently
has no sound solution in Bitcoin and until it does, supporting it should
not be a part of the agenda. There are two paths going forward, not
independent of one another, that would achieve the goal of quick payments
for your coffee etc:
- Research/implement a solution that is consistent with the goal of Bitcoin
- Rely on a cosigning central authority

If you think the latter option is nasty, remember that people,
like corporations, can be nasty as well. Do not rely on the good faith of
people.

Cameron

[Chun Wang]

Post by Adrian Macneil
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into this
as a way to prevent fraud.

This might be useful to you: https://www.f2pool.com/api/mempool

------------------------------------------------------------------------------

[Adrian Macneil]

Great. Thank you for this!

Adrian

Post by Chun Wang

Post by Adrian Macneil
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into

this

Post by Adrian Macneil
as a way to prevent fraud.

This might be useful to you: https://www.f2pool.com/api/mempool

[Stephen Morse]

It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?

Best,
Stephen

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
---------------------------------------
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
-------------------------------------------
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
-------------------------------
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
------------------
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁎ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
--------------------------------------------
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
-------------------------------
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
https://github.com/petertodd/replace-by-fee-tools
http://respends.thinlink.com/
References
----------
1) "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, May 23rd 2015, Bitcoin-development mailing list,
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,
Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
http://eprint.iacr.org/2015/578
--
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Chun Wang]

Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.

On Fri, Jun 19, 2015 at 9:33 PM, Stephen Morse

Post by Stephen Morse
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
Best,
Stephen

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
---------------------------------------
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
-------------------------------------------
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
-------------------------------
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
------------------
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁴ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
--------------------------------------------
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
-------------------------------
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
https://github.com/petertodd/replace-by-fee-tools
http://respends.thinlink.com/
References
----------
1) "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, May 23rd 2015, Bitcoin-development mailing list,
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,
Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
http://eprint.iacr.org/2015/578
--
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

------------------------------------------------------------------------------

[Peter Todd]

Post by Chun Wang
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.

No worries, let me know if you have any issues. You have my phone
number.

While my own preference - and a number of other devs - is full-RBF,
either one is a good step forward for Bitcoin.

[Lawrence Nahum]

Post by Chun Wang
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.

FSS RBF is better than no RBF but we think it is better to use full RBF.

We think Full RBF is better for a number of reasons:

-user experience
-efficiency
-cost
-code complexity

We think FSS RBF is great progress but ultimately less efficient and more
complicated to keep alive something that never worked properly.

And why would miner pick the option paying less when other miners run the
option paying more? It may be soon more than 1-5% of block reward.

A lot of users don't have multiple UTXO handy.

Full RBF is the best, second FSS RBF and we'd be looking into supporting
them both separately so that miners and users can pick whichever they
prefer.

If users only had one UTXO it makes sense to use Full RBF since there are no
other options.

Disclosure: GreenAddress always believed zero conf transactions are not
secure and that miners have the incentive to run FBF; this bias doesn't make
the above less true



------------------------------------------------------------------------------

[Peter Todd]

Post by Stephen Morse
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
We are
interested in the replace-by-fee patch, but I am not following the
development closely, more background info is needed, like what the
difference between standard and zeroconf versions? Thanks.

Great!

Basically both let you replace one transaction with another that pays a
higher fee. First-seen-safe replace-by-fee adds the additional criteria
that all outputs of the old transaction still need to be paid by the new
transaction, with >= as many Bitcoins. Basically, it makes sure that if
someone was paid by tx1, then tx2 will still pay them.

I've written about how wallets can use RBF and FSS-RBF to more
efficiently use the blockchain on the bitcoin-development mailing list:

http://www.mail-archive.com/bitcoin-***@lists.sourceforge.net/msg07813.html
http://www.mail-archive.com/bitcoin-***@lists.sourceforge.net/msg07829.html

Basically, for the purpose of increasing fees, RBF is something like %50
cheaper than CPFP, and FSS-RBF is something like %25 cheaper.

In addition, for ease of implementation, my new FSS-RBF has a number of
other restrictions. For instance, you can't replace multiple
transactions with one, you can't replace a transaction whose outputs
have already been spent, you can't replace a transaction with one that
spends additional unconfirmed inputs, etc. These restrictions aren't
"set in stone", but they do make the code simpler and less likely to
have bugs.

In comparison my previous standard RBF patch can replace multiple
transactions with one, can replace long chains of transactions, etc.
It's willing to do more computation before deciding if a transaction
should be replaced, with more complex logic; it probably has a higher
chance of having a bug or DoS attack.

You've probably seen the huge controversy around zeroconf with regard to
standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
it also doesn't make it any more dangerous, so politically with regard
to zeroconf it makes no difference. You *can* still use it doublespend
by taking advantage of how different transactions are accepted
differently, but that's true of *every* change we've ever made to
Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
zeroconf in the same way.


Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
supporting miners to figure out what transactions are being mined, are
services having any hope of avoiding getting ripped off. For the average
user their wallets do a terrible job of showing whether or not an
unconfirmed transaction will go through. For example, Schildbach's
Bitcoin wallet for Android has no code at all to detect double-spends
until they get mined, and I've been able to trick it into showing
completely invalid transactions. In fact, currently Bitcoin XT will
relay invalid transactions that are doublepsends, and Schildbach's
wallet displays them as valid, unconfirmed, payments. It's really no
surprise to me that nearly no-one in the Bitcoin ecosystem accepts
unconfirmed transactions without some kind of protection that doesn't
rely on first-seen-safe mempool behavior. For instance, many ATM's these
days know who their customers are due to AML requirements, so while you
can deposit Bitcoins and get your funds instantly, the protection for
the ATM operator is that they can go to the police if you rip them off;
I've spoken to ATM operators who didn't do this who've lost hundreds or
even thousands of dollars before giving up on zeroconf.

My big worry with zeroconf is a service like Coinbase or Shapeshift
coming to rely on it, and then attempting to secure it by gaining
control of a majority of hashing power. For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by the 20%. There's
no way in a decentralized network to come to consensus about what
transactions are or are not valid without mining itself, so you could
end up in a situation where unless you're part of one of the big pools
you can't reliably mine at all because your blocks may get rejected for
containing doublespends.

One of my goal with standard replace-by-fee is to prevent this scenario
by forcing merchants and others to implement ways of accepting zeroconf
transactions safely that work in a decentralized environment regardless
of what miners do; we have a stronger and safer Bitcoin ecosystem if
we're relying on math rather than trust to secure our zeroconf
transactions. We're also being more honest to users, who right now often
have the very wrong impression that unconfirmed transactions are safe to
accept - this does get people ripped off all too often!


Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
waiting to get some feedback:

https://github.com/bitcoin/bitcoin/pull/6176

Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
working on porting it to v0.10.2, and once that's done I'm going to put
up a bounty for anyone who can find a DoS attack in the patch. If no-one
claims the bounty after a week or two I think I'll start feeling
confident about using it in production.

[Chun Wang]

Before F2Pool's launch, I performed probably the only successful
bitcoin double spend in the March 2013 fork without any mining power.
[ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
the full RBF is. We are going to switch to FSS RBF in a few hours.
Sorry.

Post by Peter Todd

Post by Stephen Morse
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
We are
interested in the replace-by-fee patch, but I am not following the
development closely, more background info is needed, like what the
difference between standard and zeroconf versions? Thanks.

Great!
Basically both let you replace one transaction with another that pays a
higher fee. First-seen-safe replace-by-fee adds the additional criteria
that all outputs of the old transaction still need to be paid by the new
transaction, with >= as many Bitcoins. Basically, it makes sure that if
someone was paid by tx1, then tx2 will still pay them.
I've written about how wallets can use RBF and FSS-RBF to more
Basically, for the purpose of increasing fees, RBF is something like %50
cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
In addition, for ease of implementation, my new FSS-RBF has a number of
other restrictions. For instance, you can't replace multiple
transactions with one, you can't replace a transaction whose outputs
have already been spent, you can't replace a transaction with one that
spends additional unconfirmed inputs, etc. These restrictions aren't
"set in stone", but they do make the code simpler and less likely to
have bugs.
In comparison my previous standard RBF patch can replace multiple
transactions with one, can replace long chains of transactions, etc.
It's willing to do more computation before deciding if a transaction
should be replaced, with more complex logic; it probably has a higher
chance of having a bug or DoS attack.
You've probably seen the huge controversy around zeroconf with regard to
standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
it also doesn't make it any more dangerous, so politically with regard
to zeroconf it makes no difference. You *can* still use it doublespend
by taking advantage of how different transactions are accepted
differently, but that's true of *every* change we've ever made to
Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
zeroconf in the same way.
Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
supporting miners to figure out what transactions are being mined, are
services having any hope of avoiding getting ripped off. For the average
user their wallets do a terrible job of showing whether or not an
unconfirmed transaction will go through. For example, Schildbach's
Bitcoin wallet for Android has no code at all to detect double-spends
until they get mined, and I've been able to trick it into showing
completely invalid transactions. In fact, currently Bitcoin XT will
relay invalid transactions that are doublepsends, and Schildbach's
wallet displays them as valid, unconfirmed, payments. It's really no
surprise to me that nearly no-one in the Bitcoin ecosystem accepts
unconfirmed transactions without some kind of protection that doesn't
rely on first-seen-safe mempool behavior. For instance, many ATM's these
days know who their customers are due to AML requirements, so while you
can deposit Bitcoins and get your funds instantly, the protection for
the ATM operator is that they can go to the police if you rip them off;
I've spoken to ATM operators who didn't do this who've lost hundreds or
even thousands of dollars before giving up on zeroconf.
My big worry with zeroconf is a service like Coinbase or Shapeshift
coming to rely on it, and then attempting to secure it by gaining
control of a majority of hashing power. For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by the 20%. There's
no way in a decentralized network to come to consensus about what
transactions are or are not valid without mining itself, so you could
end up in a situation where unless you're part of one of the big pools
you can't reliably mine at all because your blocks may get rejected for
containing doublespends.
One of my goal with standard replace-by-fee is to prevent this scenario
by forcing merchants and others to implement ways of accepting zeroconf
transactions safely that work in a decentralized environment regardless
of what miners do; we have a stronger and safer Bitcoin ecosystem if
we're relying on math rather than trust to secure our zeroconf
transactions. We're also being more honest to users, who right now often
have the very wrong impression that unconfirmed transactions are safe to
accept - this does get people ripped off all too often!
Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
https://github.com/bitcoin/bitcoin/pull/6176
Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
working on porting it to v0.10.2, and once that's done I'm going to put
up a bounty for anyone who can find a DoS attack in the patch. If no-one
claims the bounty after a week or two I think I'll start feeling
confident about using it in production.
--
000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------

[Jeff Garzik]

Yes, FSS RBF is far better.

Post by Chun Wang
Before F2Pool's launch, I performed probably the only successful
bitcoin double spend in the March 2013 fork without any mining power.
[ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
the full RBF is. We are going to switch to FSS RBF in a few hours.
Sorry.

Post by Peter Todd

Post by Stephen Morse
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since

the

Post by Peter Todd

Post by Stephen Morse
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
We are
interested in the replace-by-fee patch, but I am not following the
development closely, more background info is needed, like what the
difference between standard and zeroconf versions? Thanks.

Great!
Basically both let you replace one transaction with another that pays a
higher fee. First-seen-safe replace-by-fee adds the additional criteria
that all outputs of the old transaction still need to be paid by the new
transaction, with >= as many Bitcoins. Basically, it makes sure that if
someone was paid by tx1, then tx2 will still pay them.
I've written about how wallets can use RBF and FSS-RBF to more
Basically, for the purpose of increasing fees, RBF is something like %50
cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
In addition, for ease of implementation, my new FSS-RBF has a number of
other restrictions. For instance, you can't replace multiple
transactions with one, you can't replace a transaction whose outputs
have already been spent, you can't replace a transaction with one that
spends additional unconfirmed inputs, etc. These restrictions aren't
"set in stone", but they do make the code simpler and less likely to
have bugs.
In comparison my previous standard RBF patch can replace multiple
transactions with one, can replace long chains of transactions, etc.
It's willing to do more computation before deciding if a transaction
should be replaced, with more complex logic; it probably has a higher
chance of having a bug or DoS attack.
You've probably seen the huge controversy around zeroconf with regard to
standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
it also doesn't make it any more dangerous, so politically with regard
to zeroconf it makes no difference. You *can* still use it doublespend
by taking advantage of how different transactions are accepted
differently, but that's true of *every* change we've ever made to
Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
zeroconf in the same way.
Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
supporting miners to figure out what transactions are being mined, are
services having any hope of avoiding getting ripped off. For the average
user their wallets do a terrible job of showing whether or not an
unconfirmed transaction will go through. For example, Schildbach's
Bitcoin wallet for Android has no code at all to detect double-spends
until they get mined, and I've been able to trick it into showing
completely invalid transactions. In fact, currently Bitcoin XT will
relay invalid transactions that are doublepsends, and Schildbach's
wallet displays them as valid, unconfirmed, payments. It's really no
surprise to me that nearly no-one in the Bitcoin ecosystem accepts
unconfirmed transactions without some kind of protection that doesn't
rely on first-seen-safe mempool behavior. For instance, many ATM's these
days know who their customers are due to AML requirements, so while you
can deposit Bitcoins and get your funds instantly, the protection for
the ATM operator is that they can go to the police if you rip them off;
I've spoken to ATM operators who didn't do this who've lost hundreds or
even thousands of dollars before giving up on zeroconf.
My big worry with zeroconf is a service like Coinbase or Shapeshift
coming to rely on it, and then attempting to secure it by gaining
control of a majority of hashing power. For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by the 20%. There's
no way in a decentralized network to come to consensus about what
transactions are or are not valid without mining itself, so you could
end up in a situation where unless you're part of one of the big pools
you can't reliably mine at all because your blocks may get rejected for
containing doublespends.
One of my goal with standard replace-by-fee is to prevent this scenario
by forcing merchants and others to implement ways of accepting zeroconf
transactions safely that work in a decentralized environment regardless
of what miners do; we have a stronger and safer Bitcoin ecosystem if
we're relying on math rather than trust to secure our zeroconf
transactions. We're also being more honest to users, who right now often
have the very wrong impression that unconfirmed transactions are safe to
accept - this does get people ripped off all too often!
Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
https://github.com/bitcoin/bitcoin/pull/6176
Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
working on porting it to v0.10.2, and once that's done I'm going to put
up a bounty for anyone who can find a DoS attack in the patch. If no-one
claims the bounty after a week or two I think I'll start feeling
confident about using it in production.
--
000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab

------------------------------------------------------------------------------

Post by Peter Todd
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Jeffrey Paul]

It seems to me that FSS RBF must enforce identical OP_RETURN data on the output scripts as the first seen transaction, as well, to safely continue support for various other applications built atop the blockchain.

Is there a canonical implementation of FSS RBF around somewhere I can review?

Best,
-jp
--
Jeffrey Paul [phone]
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2

Post by Chun Wang
Before F2Pool's launch, I performed probably the only successful
bitcoin double spend in the March 2013 fork without any mining power.
[ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
the full RBF is. We are going to switch to FSS RBF in a few hours.
Sorry.

Post by Peter Todd

Post by Stephen Morse
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
We are
interested in the replace-by-fee patch, but I am not following the
development closely, more background info is needed, like what the
difference between standard and zeroconf versions? Thanks.

Great!
Basically both let you replace one transaction with another that pays a
higher fee. First-seen-safe replace-by-fee adds the additional criteria
that all outputs of the old transaction still need to be paid by the new
transaction, with >= as many Bitcoins. Basically, it makes sure that if
someone was paid by tx1, then tx2 will still pay them.
I've written about how wallets can use RBF and FSS-RBF to more
Basically, for the purpose of increasing fees, RBF is something like %50
cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
In addition, for ease of implementation, my new FSS-RBF has a number of
other restrictions. For instance, you can't replace multiple
transactions with one, you can't replace a transaction whose outputs
have already been spent, you can't replace a transaction with one that
spends additional unconfirmed inputs, etc. These restrictions aren't
"set in stone", but they do make the code simpler and less likely to
have bugs.
In comparison my previous standard RBF patch can replace multiple
transactions with one, can replace long chains of transactions, etc.
It's willing to do more computation before deciding if a transaction
should be replaced, with more complex logic; it probably has a higher
chance of having a bug or DoS attack.
You've probably seen the huge controversy around zeroconf with regard to
standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
it also doesn't make it any more dangerous, so politically with regard
to zeroconf it makes no difference. You *can* still use it doublespend
by taking advantage of how different transactions are accepted
differently, but that's true of *every* change we've ever made to
Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
zeroconf in the same way.
Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
supporting miners to figure out what transactions are being mined, are
services having any hope of avoiding getting ripped off. For the average
user their wallets do a terrible job of showing whether or not an
unconfirmed transaction will go through. For example, Schildbach's
Bitcoin wallet for Android has no code at all to detect double-spends
until they get mined, and I've been able to trick it into showing
completely invalid transactions. In fact, currently Bitcoin XT will
relay invalid transactions that are doublepsends, and Schildbach's
wallet displays them as valid, unconfirmed, payments. It's really no
surprise to me that nearly no-one in the Bitcoin ecosystem accepts
unconfirmed transactions without some kind of protection that doesn't
rely on first-seen-safe mempool behavior. For instance, many ATM's these
days know who their customers are due to AML requirements, so while you
can deposit Bitcoins and get your funds instantly, the protection for
the ATM operator is that they can go to the police if you rip them off;
I've spoken to ATM operators who didn't do this who've lost hundreds or
even thousands of dollars before giving up on zeroconf.
My big worry with zeroconf is a service like Coinbase or Shapeshift
coming to rely on it, and then attempting to secure it by gaining
control of a majority of hashing power. For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by the 20%. There's
no way in a decentralized network to come to consensus about what
transactions are or are not valid without mining itself, so you could
end up in a situation where unless you're part of one of the big pools
you can't reliably mine at all because your blocks may get rejected for
containing doublespends.
One of my goal with standard replace-by-fee is to prevent this scenario
by forcing merchants and others to implement ways of accepting zeroconf
transactions safely that work in a decentralized environment regardless
of what miners do; we have a stronger and safer Bitcoin ecosystem if
we're relying on math rather than trust to secure our zeroconf
transactions. We're also being more honest to users, who right now often
have the very wrong impression that unconfirmed transactions are safe to
accept - this does get people ripped off all too often!
Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
https://github.com/bitcoin/bitcoin/pull/6176
Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
working on porting it to v0.10.2, and once that's done I'm going to put
up a bounty for anyone who can find a DoS attack in the patch. If no-one
claims the bounty after a week or two I think I'll start feeling
confident about using it in production.
--
000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

------------------------------------------------------------------------------

[Jeff Garzik]

Post by Peter Todd
Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
supporting miners to figure out what transactions are being mined, are
services having any hope of avoiding getting ripped off. For the average
user their wallets do a terrible job of showing whether or not an

This is no excuse for further degrading the overall network security.

There are many issues to address in the bitcoin ecosystem. It negatively
impacts users to roll out "scorched earth" replace-by-fee given today's
ecosystem.

Yes, zero conf security is poor. An outright attack on zero conf degrades
user security even more.

[Peter Todd]

Post by Stephen Morse
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?

Incidentally, because someone asked that message was sent two weeks ago.


Also, a shout-out to Marshal Long of FinalHash for his help with
(FSS)-RBF deployment and for getting F2Pool and myself in touch, as well
as his work in talking getting pools on board with BIP66.

[Adrian Macneil]

Extremely disappointed to hear this. This change turns double spending from
a calculable (and affordable) risk for merchant payment processors into
certain profit for scammers, and provides no useful benefit for consumers.

I sincerely hope that F2Pool reconsider, given that RBF will decrease the
overall utility of bitcoin and reduce the number of people using it for
online purchases.

Adrian

Post by Stephen Morse
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
Best,
Stephen

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
---------------------------------------
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
-------------------------------------------
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
-------------------------------
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
------------------
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁎ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
--------------------------------------------
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
-------------------------------
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
https://github.com/petertodd/replace-by-fee-tools
http://respends.thinlink.com/
References
----------
1) "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, May 23rd 2015, Bitcoin-development mailing list,
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,
Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
http://eprint.iacr.org/2015/578
--
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[j***@riseup.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-19 10:39, Peter Todd wrote:

Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions
with
me. This means that transactions that F2Pool has will be replaced if
a
conflicting transaction pays a higher fee. There are no requirements
for
the replacement transaction to pay addresses that were paid by the
previous transaction.


Intentional fraud is a bad thing to add to a financial protocol.

A user who creates conflicting transactions, one that pays someone else
and another which does not pay them, and broadcasts both of them, has
just self-incriminated themselves by producing prima facie evidence of
fraud.

It may be the case that since Bitcoin spans multiple legal jurisdictions
and can be use anonymously that the victims of such fraud can not rely
on legal recourse, and it may also be the case that proof of work is how
Bitcoin deals with the aforementioned factors, but regardless
un-prosecutable fraud is still fraud and anyone who encourages it should
be recognied as a bad actors.

Committing vandalism and encouraging fraud to prove a point may be
something the network can't stop on a technical level, but there's no
reason not to call it out for what it is.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhCsXAAoJECpf2nDq2eYjA08P/ApDFcIGws55TsgDFxPhDpN+
Iq9a06mPbXVjUfRxP5ZwmJuiM+XzHQ4QL3C2BH0OETatIV+bh7GP2mGHPcUAISYt
1j4TKhurnC+mqN+YAsiI5hQsws8DvPYXBTYYn0savaJTbq6/Q77+xvfRgNxofcPW
EHpnl/5wcmYGgp3mVyStGJ+qIP17yywzCLnSA3WEPaZG/9/FPrIq3Ptw2+RHod79
nzDiFBiKLK8E5NPbdbXS+gkjkkBA/QeCzZObpMOeWMriu/PIifVi8KssLSznnEwx
r7hiv6ISW47BTzkRbjxmXmGep3wfl8MjH7BZq3g0uyiApMdmjohIJ2lyuvOXdh7s
47+4r2xA8gG+z0aQTmCx5TS75T0Hnj3I78ZtCVr31Ip2OLbNI1mQ2gPR2zaoZkUZ
atp2XCssHDlY2s30k5hAnIHxuN6CkyGkZCECSuv46Z3ok6ll/nIP80qB7BBzVlP1
xfSOPZh57J31U8PxZBZcwgdRg+HBiExvg484grE+h18izxcrjNfPRSWP4+7nEZtK
LN7JL7YcmhVfhqKTSd6+C4bD2LsKsrcMiUhH1xHkD/hzAxc7egL6lgYTHJjU+yPu
BTIh0VHJxBgroHB45Vq6loa4B3l4ZCl4Ykw8Opm7NJIfueJ0l0ySyJXi6ix4bjVf
ZRF0Ot9RP0M0fHEwOpT6
=s0w/
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Peter Todd]

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
Intentional fraud is a bad thing to add to a financial protocol.
A user who creates conflicting transactions, one that pays someone else
and another which does not pay them, and broadcasts both of them, has
just self-incriminated themselves by producing prima facie evidence of
fraud.

Depends.

If you ask me to pay you 1BTC at address A and I create tx1 that pays
1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
defrauding you, I'm just reducing the value of my change address to pay
a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.

Yet from the point of view of an external observer they have no idea why
the transaction outputs reduced in size, nor any way of knowing if fraud
did or did not occur.

Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel out
that debt", in which case I'm not breaking any contract at all by giving
you less money than I first promised - the contract has changed.

Again, none of this can or should be observable to anyone other than the
parties directly involved.

Post by Peter Todd
It may be the case that since Bitcoin spans multiple legal jurisdictions
and can be use anonymously that the victims of such fraud can not rely
on legal recourse, and it may also be the case that proof of work is how
Bitcoin deals with the aforementioned factors, but regardless
un-prosecutable fraud is still fraud and anyone who encourages it should
be recognied as a bad actors.
Committing vandalism and encouraging fraud to prove a point may be
something the network can't stop on a technical level, but there's no
reason not to call it out for what it is.

What do you think of Bitcoin XT then? It relays double-spends, which
makes it much easier to get double-spends to miners than before. In
particular you see a lot of zero-fee transactions being replaced by
fee-paying transactions, relayed through Bitcoin XT nodes and then
mined. Is that encouraging fraud?

[Eric Lombrozo]

OK, a few things here:

The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time
and relaxing this assumption without adequately assessing the risk (i.e. I’ve never been hacked before so I can assume it’s safe) is extremely dangerous at best and just horrid security practice at worst. Your users might not thank you for not getting hacked - but they surely will not like it when you DO get hacked
and lack a proper recovery plan.

Furthermore, the protocol itself makes no assumptions regarding the intentions behind someone signing two conflicting transactions. There are many potential use cases where doing so could make a lot of sense. Had the protocol been designed along the lines of, say, tendermint
where signing multiple conflicting blocks results in loss of one’s funds
then the protocol itself disincentivizes the behavior without requiring any sort of altruistic, moralistic assumptions. That would also mean we’d need a different mechanism for the use cases that things like RBF address.

Thirdly, taken to the extreme, the viewpoint of “signing a conflicting transaction is fraud and vandalism” means that if for whatever reason you attempt to propagate a transaction and nobody mines it for a very long time, you’re not entitled to immediately reclaim those funds
they must remain in limbo forever.


- Eric Lombrozo

Post by Peter Todd

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
Intentional fraud is a bad thing to add to a financial protocol.
A user who creates conflicting transactions, one that pays someone else
and another which does not pay them, and broadcasts both of them, has
just self-incriminated themselves by producing prima facie evidence of
fraud.

Depends.
If you ask me to pay you 1BTC at address A and I create tx1 that pays
1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
defrauding you, I'm just reducing the value of my change address to pay
a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
Yet from the point of view of an external observer they have no idea why
the transaction outputs reduced in size, nor any way of knowing if fraud
did or did not occur.
Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel out
that debt", in which case I'm not breaking any contract at all by giving
you less money than I first promised - the contract has changed.
Again, none of this can or should be observable to anyone other than the
parties directly involved.

Post by Peter Todd
It may be the case that since Bitcoin spans multiple legal jurisdictions
and can be use anonymously that the victims of such fraud can not rely
on legal recourse, and it may also be the case that proof of work is how
Bitcoin deals with the aforementioned factors, but regardless
un-prosecutable fraud is still fraud and anyone who encourages it should
be recognied as a bad actors.
Committing vandalism and encouraging fraud to prove a point may be
something the network can't stop on a technical level, but there's no
reason not to call it out for what it is.

What do you think of Bitcoin XT then? It relays double-spends, which
makes it much easier to get double-spends to miners than before. In
particular you see a lot of zero-fee transactions being replaced by
fee-paying transactions, relayed through Bitcoin XT nodes and then
mined. Is that encouraging fraud?
--
000000000000000003932458055c68d4ee2b6d68441c4764efbdf6b0b1683717
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[j***@riseup.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Eric Lombrozo
The Bitcoin network was designed (or should be designed) with the
requirement that it can withstand deliberate double-spend attacks that
can come from anywhere at any time…and relaxing this assumption
without adequately assessing the risk (i.e. I’ve never been hacked
before so I can assume it’s safe) is extremely dangerous at best and
just horrid security practice at worst. Your users might not thank you
for not getting hacked - but they surely will not like it when you DO
get hacked…and lack a proper recovery plan.
Furthermore, the protocol itself makes no assumptions regarding the
intentions behind someone signing two conflicting transactions. There
are many potential use cases where doing so could make a lot of sense.
Had the protocol been designed along the lines of, say,
tendermint…where signing multiple conflicting blocks results in loss
of one’s funds…then the protocol itself disincentivizes the behavior
without requiring any sort of altruistic, moralistic assumptions. That
would also mean we’d need a different mechanism for the use cases that
things like RBF address.
Thirdly, taken to the extreme, the viewpoint of “signing a conflicting
transaction is fraud and vandalism” means that if for whatever reason
you attempt to propagate a transaction and nobody mines it for a very
long time, you’re not entitled to immediately reclaim those funds…they
must remain in limbo forever.

I'm not talking about changing the protocol - I'm talking about the
business relationships between users of Bitcoin.

I would expect a payment processor to inform the merchants of relevant
double spends that it observes on the network, even if the payment is
actually successful, so that the merchant can decide for themselves
whether or not to pursue it out of band.

Mining is a kind of technical fallback that allows the network to
resolve human misbehavior without human intervention. If nobody ever
attempted to make a fraudulent payment, we wouldn't need mining at all
because the signed transaction itself is proof of intention to pay. That
it exists doesn't suddenly make fraud less fraudulent and mean that
users who are in a position to pursue out of band recourse shouldn't do
so.

I agree that there are valid reasons for replacing transactions in the
mempool, I just think they should be implemented in a way that doesn't
facilitate fraud.

I'd also like to note that "prima facie" doesn't mean "always", it means
that "the default assumption, unless proven otherwise."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDqcAAoJECpf2nDq2eYjX/UP/RlVIGqzwvdKftFW8kRW1+Dk
3befE2vEIEWFAShNt0pk7/Isqk7prRWQDKP+VNZSJfaoyE3akOe7s3OPWuevVRqM
Y1N658hYnG6NPebkyp5zUQkjT3mXVxOo9Fw9k7JyHgkWaDcwx330z2n6yztleodq
7hlKdW6sZrgqHw+DoF0Zal3QPN0WYm0XAno3uy71RXOs5cAoUxViuVzWHY0oReTQ
uggTggT1A5acmyOM7v65h9Cb2AKcLvHKfSEIwVQbHxYMOT+3GIJOXPKAluh8MjB3
oWg8ERy5dEEHu5kF/MLPQMg5yVQACuQmO2dlmtRoOs3mUQQj+q7dEil/dZMIp0f+
unDKIwLhXMa0sZ+63123UOgaKGZkF7afed3ueniJWQM80VS0WoZvZYhQadT/sCED
Ntfxifi1ZqCiKFeshyN9z7jDC8QEJ3N176Kr/wX76h/vvnPYicMEcfRgSE8EGd10
+oRQQpYzb69WPSFRhhrR3yG9Dev1JfzNPEaIKKYerDk9Vo3OnQ3VaaqBNZwBDo46
4r3O5orFES/ZxMdzWE1cWp99n4T4L6KxdZXmfQSYHehUJBnt62vKuEk9X/Li2ZWo
i3dr3yxx8xhKGGjsSjG03arz70bkXE7SvrICPOs9OEAdGlJI2liLrSWzYU9BbTle
eWvElyVQJsJHgAU8ygvn
=77NP
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Matt Whitlock]

Post by j***@riseup.net
I'd also like to note that "prima facie" doesn't mean "always", it means
that "the default assumption, unless proven otherwise."

Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.

------------------------------------------------------------------------------

[Eric Lombrozo]

If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay


Post by Matt Whitlock

Post by j***@riseup.net
I'd also like to note that "prima facie" doesn't mean "always", it means
that "the default assumption, unless proven otherwise."

Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.

[Matt Whitlock]

Even if you could prove "intent to pay," this would be almost useless. I can sincerely intend to do a lot of things, but this doesn't mean I'll ever actually do them.

I am in favor of more zero-confirmation transactions being reversed / double-spent. Bitcoin users largely still believe that accepting zero-conf transactions is safe, and evidently it's going to take some harsh lessons in reality to correct this belief.

If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay…

Post by Matt Whitlock

Post by j***@riseup.net
I'd also like to note that "prima facie" doesn't mean "always", it means
that "the default assumption, unless proven otherwise."

Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.

------------------------------------------------------------------------------

[Peter Todd]

Post by Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay


Indeed.

For instance, one of the ideas behind my Proofchains work is that you
could hind all details of a smartcontract-whatchamacallit protocol
behind single-use-seals in a consensus blockchain. Closing those seals,
that is spending the appropriate txouts, represents things in the
protocol which are absolutely unobservable to anyone without the data
behind those hashes, an extreme version of the above.


Incidentally, some patent prior-art exposure:

https://github.com/proofchains/python-proofchains

:)

[j***@riseup.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie”
assumptions. Otherwise, I would recommend not relying on the existence
of a signed transaction as proof of intent to pay…

Again, I'm not talking about any changes to the protocol. The mining
mechanism in the Bitcoin protocol is the fallback method of resolving
fraud that isn't prevented or resolved via other mechanisms.

There are plenty of other ways economic actors resolve their
disagreements other than blockchain adjudication. Sometimes when both
parties are identified and reside in the same legal jurisdiction,
contract violations and fraud can be adjudicated in courts. In some
situations, the parties involved may have access to private dispute
resolution techniques.

Sometimes the stakeholders in the network act to preserve the long term
value of their investments, even if it means passing short-term profits.
The more of those stakeholders there are in Bitcoin, the more effective
it is to make the case for choices that are long-term beneficial.

The degree to which anyone should rely on a signed transaction as
assurance of future payment is not a question with a universal answer.
It depends on the particular details of the situation, and the parties
involved, and their own risk tolerances and time preferences. There's no
right answer for everyone, which is why "let's break zeroconf because
*I* don't think it's safe enough" is a kind of vandalism.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEkhAAoJECpf2nDq2eYj8qAP/0qYP7FJDjke1qNARGkySjC5
8fSuefu8bus/O2fNYsvPf0OcHeqepLUtQ/hgTml5AHaF1Fa9iZopVr8nZv0NFMuF
sv9RfkBKvnnrLWre3e/kQIdKzdMXompEsDwGfIeM3qvVV9AD3mKrz/YNmjs60+hU
rEdLCX8xw3ZvF3CGOzE1KnOMbADEd7i3E/Pm1n7pLVdRAg2CIU+w6mjErgucSdvB
kQ9SNAVQngjhMJyVbxsQh/+/xgecdqeZ07aaGsLhiw6zML2Tz8KMhrjJ9xw9+7h0
Gze+JdqxpgH4QrvD8KMDnlZjM+cWDUGyoVfsRvrVvPdW6kejU1r1B5Pf6dJg9TwZ
kK48RJFdd2rpAkz/kAbvQtoNMxSxhm2gKKFLEMi7g8MZUiGa/Rxj0tWL7OL9SA1U
VfpUzgAovoat9lBQM92T5vcS6kfhiNgAmF24ULGGYIhts77Ae6h8Fl3TECtnR0dM
1U1yio4Im1TfUDfjqNSK+ZjVpzkQli0R057y6XzI9HWkSYo94WyjNVoUlUozuAam
/2+tUMTrMYPeApRv+1nv13InYO8RZiFqs0E4w4TmB5V4Xt6uGUz4Olioyuo0NqMO
lBZwa1ZWKw4fLgHHDu9FhTEOXsOcX5W0gEgcoqMlzTzyoapekk9Esd0pAFLYxYMY
YQyAWtWUA4JBbgLxlB8Y
=x8eh
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Tier Nolan]

Post by Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie” assumptions.
Otherwise, I would recommend not relying on the existence of a signed
transaction as proof of intent to pay


Outputs could be marked as "locked". If you are performing a zero
confirmation spend, then the recipient could insist that you flag the
output for them as non-reducible.

This reduces privacy since it would be obvious which output was change. If
both are locked, then the fee can't be increased.

This would be information that miners could ignore though.

Creating the right incentives is hard though. Blocks could be
"discouraged" if they have a double spend that is known about for a while
which reduces payment for a locked output.

[Jorge Timón]

If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay…

Non-repudiation can be built on top of the payment protocol layer.

------------------------------------------------------------------------------

[j***@riseup.net]

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

Post by Jorge Timón

Post by Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie”
assumptions. Otherwise, I would recommend not relying on the existence
of a signed transaction as proof of intent to pay…

Non-repudiation can be built on top of the payment protocol layer.

Non-repudiation is an intrinsic property of the ECDSA signatures which
Bitcoin uses - it's not a feature that needs to be built.

There's no way to accidentally sign a transaction and accidentally
announce it publicly. There is no form of third-party error that can
result in a payee receiving an erroneous contract.

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

iQIcBAEBAgAGBQJVhfkXAAoJECpf2nDq2eYjTwIP/ApsURTKJgAsSYb4/lvoujAE
EhOUBfmb+WkrEceASWGgmXFfQBQW7c99sT46cA1HdCPLZMtYhZYPubtYRouSupfF
vOfeKLsZsUXCadeLuzxP7av3PJhmvB1CO1Rv8CLBQptKUFkzyM3CypBviNTy33X6
KL2zyAMERpCVOejg7MSP3IUXIjgG1ayEm+mzwqi4j2Ms0h+oT6I/krAKV0J9SwJC
PtLq/JRRriVtb2FE+biEqYRYfeOcZDYNbr+/y0HPtqqMxg6azNwx1z2aG5A+ziCd
EvVqVJXU3TAINQdIvVS4ACF1J+ttMJ99r8VW0yN7o3fEckuRr3pyymx4I+XExSX5
ujflqadRGUS8ZenUPTPUbLfhARnmBwLM94L+xiQvIwiinxxtOKn3WW1oDv9FNp0l
99fkv9mbV5RnYlkMfWMn2AcwcBv7TSgpFGsZY4wBn/mgFh1PotGc2tA5kU79cz8R
+F/k49+GwfgTPML7UhIGtjQjPreeqDyHNtv9XHtyp8LF5vO1na4oHSO6SeU4rIXH
4oIjw+Q6X/2L/fp8QNLB+onmKWobcl1Ec+0H+ZfQBujtew5BHFwcPwFmlC4tofiJ
7r8QjoPsRhJmaxm+MJOK/BIzhZErkMz26AQ/tfY4jtJCuLbEDdMLtC9hYVuiDHIb
HBxxif83dALjX1Sgid66
=o9dG
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Eric Lombrozo]

Signed PGP part

Post by Jorge Timón

Post by Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie”
assumptions. Otherwise, I would recommend not relying on the existence
of a signed transaction as proof of intent to pay


Non-repudiation can be built on top of the payment protocol layer.

Non-repudiation is an intrinsic property of the ECDSA signatures which
Bitcoin uses - it's not a feature that needs to be built.
There's no way to accidentally sign a transaction and accidentally
announce it publicly. There is no form of third-party error that can
result in a payee receiving an erroneous contract.

Justus,

We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity?

Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction.


Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions
and the fact that determination of intent isn’t always entirely clear
we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it
but perhaps the sender would have changed their mind before it actually did get accepted.”

- Eric Lombrozo

[j***@riseup.net]

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

Post by Eric Lombrozo

Signed PGP part

Post by Jorge Timón

Post by Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie”
assumptions. Otherwise, I would recommend not relying on the existence
of a signed transaction as proof of intent to pay…

Non-repudiation can be built on top of the payment protocol layer.

Non-repudiation is an intrinsic property of the ECDSA signatures which
Bitcoin uses - it's not a feature that needs to be built.
There's no way to accidentally sign a transaction and accidentally
announce it publicly. There is no form of third-party error that can
result in a payee receiving an erroneous contract.

Justus,
We don’t even have a concept of identity in the Bitcoin protocol, let
alone non-repudiation. What good is non-repudiation if there’s no way
to even associate a signature with a legal entity?
Sure, we could use the ECDSA signatures in transactions as part of a
non-repudiation scheme - but the recipient would have to also have a
means to establish the identity of the sender and associate it with
the the transaction.
Furthermore, in light of the fact that there *are* fully legitimate
use cases for sending conflicting transactions…and the fact that
determination of intent isn’t always entirely clear…we should refrain
from attaching any further significance transaction signatures other
than that “the sender was willing to have it included in the
blockchain if a miner were to have seen it and accepted it…but perhaps
the sender would have changed their mind before it actually did get
accepted.”

Bitcoin has no concept of identity, but in any type of commercial
transaction the parties involved must know some minimal amount of
identity information in order to transact at all.

Except for some identifiable special cases, I think a payee is perfectly
justified in treating a double spend of a payment sent to them as part
of a commercial transaction as a fraud attempt and employing whatever
non-Bitcoin recourse mechanisms, if any, they have access to.

- From the perspective of the network, the obviously correct action for
any node or miner is to relay the first version of any transaction they
see. The primary purpose of mining is to resolve this
otherwise-unresolvable problem of determining which transaction among a
set of conflicting transactions happened first.

If a node or miner wants to deviate from the obviously correct
behaviour, and if they want to avoid harming the value of the network,
they should be particularly careful to make sure their deviation from
"first seen" doesn't introduce harmful unintended side effects, like
making fraud easier.

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

iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT
LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7
FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617
APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5
WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d
5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA
fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm
gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be
646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv
hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+
GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2
po6di9uOSlLq0BJJfSrM
=HbNG
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------

[Eric Lombrozo]

Signed PGP part

Post by Eric Lombrozo

Signed PGP part

Post by Jorge Timón

Post by Eric Lombrozo
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie”
assumptions. Otherwise, I would recommend not relying on the existence
of a signed transaction as proof of intent to pay


Non-repudiation can be built on top of the payment protocol layer.

Non-repudiation is an intrinsic property of the ECDSA signatures which
Bitcoin uses - it's not a feature that needs to be built.
There's no way to accidentally sign a transaction and accidentally
announce it publicly. There is no form of third-party error that can
result in a payee receiving an erroneous contract.

Justus,
We don’t even have a concept of identity in the Bitcoin protocol, let
alone non-repudiation. What good is non-repudiation if there’s no way
to even associate a signature with a legal entity?
Sure, we could use the ECDSA signatures in transactions as part of a
non-repudiation scheme - but the recipient would have to also have a
means to establish the identity of the sender and associate it with
the the transaction.
Furthermore, in light of the fact that there *are* fully legitimate
use cases for sending conflicting transactions
and the fact that
determination of intent isn’t always entirely clear
we should refrain
from attaching any further significance transaction signatures other
than that “the sender was willing to have it included in the
blockchain if a miner were to have seen it and accepted it
but perhaps
the sender would have changed their mind before it actually did get
accepted.”

Bitcoin has no concept of identity, but in any type of commercial
transaction the parties involved must know some minimal amount of
identity information in order to transact at all.
Except for some identifiable special cases, I think a payee is perfectly
justified in treating a double spend of a payment sent to them as part
of a commercial transaction as a fraud attempt and employing whatever
non-Bitcoin recourse mechanisms, if any, they have access to.
From the perspective of the network, the obviously correct action for
any node or miner is to relay the first version of any transaction they
see. The primary purpose of mining is to resolve this
otherwise-unresolvable problem of determining which transaction among a
set of conflicting transactions happened first.
If a node or miner wants to deviate from the obviously correct
behaviour, and if they want to avoid harming the value of the network,
they should be particularly careful to make sure their deviation from
"first seen" doesn't introduce harmful unintended side effects, like
making fraud easier.

The contract between the buyer and seller is actually outside the Bitcoin network. Yes, a merchant that gets cheated could seek some other recourse in such an event
but the behavior you’re claiming as “obviously correct” is NOT obviously correct. In fact, there are arguments against this “obviously correct” way even if we were to accept the premise that the signature implies a promise to pay (which I think many reasonable individuals would also dispute). For instance, by relaying conflicting transactions it makes it potentially easier for others to discover the double-spend attempt (of course, this requires wallets to not be lazy about this
perhaps such relays could be flagged or placed in a special message type).

- Eric Lombrozo

[Eric Lombrozo]

One more thing I would like to add to this thread: I want to make it unequivocally clear that I believe what is making double-spends easier has relatively little to do with the protocol and almost everything to do with poor software and poor security policy on the merchant end. Perhaps it isn’t prudent to push out changes to the relay policy that make these exploits even easier right now - but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient so that we have more room for changes on things like relay policy without significant disruption to the network.

- Eric Lombrozo

[Tom Harding]

Perhaps it isn’t prudent to push out changes to the relay policy that make these exploits even easier right now - but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient so that we have more room for changes on things like relay policy without significant disruption to the network.

There's no need to worry about causing more problems by relaying
double-spends. After a year of watching, it's clear that already only
20% of hash power strictly obeys first-seen.

Loading Image...

It may be surprising that
- The period of ambiguity is very short - just 2 seconds
(this makes sense, given the .5s median propagation time)
- Fast double-spends between 2 and 15 seconds are less successful
- The steady-state 80% respend success rate is reached after just 15
seconds

The >30s data point includes txes that were respent after a long time,
sometimes months. Those longer-term respends are to be expected, as
people reclaim stuck txes.

Paying attention to double-spends is an opportunity for wallets and
merchants . With 140 Bitcoin XT nodes online, you're probably already
receiving them. Most wallets, including vanilla core, don't even alert
when a double-spend of a wallet transaction appears in a block - even
though there may still be time to withhold delivery of the goods/services.

If FSS RBF gains miner share, fewer successful zero-conf double-spends
will occur. Only radical twisted logic finds that to be an undesirable
result.



------------------------------------------------------------------------------

[Jeff Garzik]

Post by Eric Lombrozo
but we NEED to be applying some kind of pressure on the merchant end to
upgrade their stuff to be more resilient

Can you be specific? What precise technical steps would you have BitPay
and Coinbase do? We upgrade our stuff to... what exactly?

[Eric Lombrozo]

Post by Eric Lombrozo
but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient
Can you be specific? What precise technical steps would you have BitPay and Coinbase do? We upgrade our stuff to... what exactly?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/ <https://bitpay.com/>

Thanks for asking *the* question, Jeff. We often get caught up in these philosophical debates
but at the end of the day we need something concrete.

Even more important than the specific software you’re using is the security policy.

If you must accept zero confirmation transactions, there are a few concrete things you can do to reduce your exposure:

1) limit the transaction amounts for zero confirmation transactions - do not accept them for very high priced goods
especially if they require physical shipping.
2) limit the total amount of unconfirmed revenue you’ll tolerate at any given moment - if the amount is exceeded, require confirmations.
3) give merchants of subscription services (i.e. servers, hosting, etc
) the ability to shut the user out if a double-spend is detected.
4) collect legal information on purchasers (or have the merchants collect this information) so you have someone to go after if they try to screw you
5) create a risk profile for users
and flag suspicious behavior (i.e. someone trying to purchase a bunch of stuff that totally doesn’t fit into their purchasing habits).
6) get insurance (although right now reasonably-priced insurance is probably pretty hard to obtain since statistics are generally of little use
we’re entering uncharted territory).
7) set up a warning system and a “panic” button so that if you start to see an attack you can immediately disable all zero confirmation transactions system-wide.
8) independently verify all inbound transactions and connect to multiple network nodes
check them against one another.


As for software tools to accomplish these things, we can talk about that offline :)


- Eric Lombrozo

[Eric Lombrozo]

Post by Eric Lombrozo

Post by Eric Lombrozo
but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient
Can you be specific? What precise technical steps would you have BitPay and Coinbase do? We upgrade our stuff to... what exactly?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/ <https://bitpay.com/>

Thanks for asking *the* question, Jeff. We often get caught up in these philosophical debates
but at the end of the day we need something concrete.
Even more important than the specific software you’re using is the security policy.
1) limit the transaction amounts for zero confirmation transactions - do not accept them for very high priced goods
especially if they require physical shipping.
2) limit the total amount of unconfirmed revenue you’ll tolerate at any given moment - if the amount is exceeded, require confirmations.
3) give merchants of subscription services (i.e. servers, hosting, etc
) the ability to shut the user out if a double-spend is detected.
4) collect legal information on purchasers (or have the merchants collect this information) so you have someone to go after if they try to screw you
5) create a risk profile for users
and flag suspicious behavior (i.e. someone trying to purchase a bunch of stuff that totally doesn’t fit into their purchasing habits).
6) get insurance (although right now reasonably-priced insurance is probably pretty hard to obtain since statistics are generally of little use
we’re entering uncharted territory).
7) set up a warning system and a “panic” button so that if you start to see an attack you can immediately disable all zero confirmation transactions system-wide.
8) independently verify all inbound transactions and connect to multiple network nodes
check them against one another.
As for software tools to accomplish these things, we can talk about that offline :)
- Eric Lombrozo

I should also point out that pretty much all of these suggestions (except for maybe 8) would apply to ANY payment system
they are NOT specific to Bitcoin whatsoever. Any serious payment processor should have these sorts of policies engrained as part of company culture
or else one day (probably not too long from now) you’ll be out of business. The mere suggestion that changing relay policy would pose significant threats to the bottom line of a payment processor is about the height of amateurishness, IMHO.


- Eric Lombrozo

[Btc Drak]

Eric,

BitPay clearly do understand the risks of 0-conf. In case you were not
aware BitPay does not particularly "accept zero confirm transactions". When
a payment is seen on the network the payment screen reports the invoice has
been paid, but that's front-end user facing. On the back end it's marked as
paid but the API exposes the the confirmation status allowing the merchant
to make business decisions about when to progress to fulfilment. A good
example of this is Neteller (a sort of paypal variant) which allows one to
fund the account with fiat using Bitcoin, via Bitpay. When you pay the
bitpay invoice, your account is marked as payment pending until there are
some confirmations.

Coinbase does not expose the confirmation status and from what I understand
(not checked myself) they guarantee payment to merchants for 0-confirm,
regardless of whether they confirm or not.

I want to address something stated by Justus, that signing a payment
message and broadcasting somehow solidifies intent and going back on that
would be fraud. This seriously conflates cryptographic certainty with human
behaviour. For one, humans make mistakes all the time. We get tired, we get
distracted, we make copy paste errors. It's entirely possible on sends a
payment only to find it's been sent to the wrong address or the wrong
amount has been sent or the fee is wrong. Software may also misbehave
(Electrum for example has a weird UI glitch with fees where the specified
fee can be overwritten). r/bitcoin it littered with sad examples. What
ECDSA signing tells is that it was signed by your private key, but nothing
else. It does not say if *you* signed it, or that the message you signed
was correct.

Post by Jeff Garzik

Post by Eric Lombrozo
but we NEED to be applying some kind of pressure on the merchant end to
upgrade their stuff to be more resilient

Can you be specific? What precise technical steps would you have BitPay
and Coinbase do? We upgrade our stuff to... what exactly?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
Thanks for asking *the* question, Jeff. We often get caught up in these
philosophical debates
but at the end of the day we need something concrete.
Even more important than the specific software you’re using is the security policy.
If you must accept zero confirmation transactions, there are a few
1) limit the transaction amounts for zero confirmation transactions - do
not accept them for very high priced goods
especially if they require
physical shipping.
2) limit the total amount of unconfirmed revenue you’ll tolerate at any
given moment - if the amount is exceeded, require confirmations.
3) give merchants of subscription services (i.e. servers, hosting, etc
)
the ability to shut the user out if a double-spend is detected.
4) collect legal information on purchasers (or have the merchants collect
this information) so you have someone to go after if they try to screw you
5) create a risk profile for users
and flag suspicious behavior (i.e.
someone trying to purchase a bunch of stuff that totally doesn’t fit into
their purchasing habits).
6) get insurance (although right now reasonably-priced insurance is
probably pretty hard to obtain since statistics are generally of little
use
we’re entering uncharted territory).
7) set up a warning system and a “panic” button so that if you start to
see an attack you can immediately disable all zero confirmation
transactions system-wide.
8) independently verify all inbound transactions and connect to multiple
network nodes
check them against one another.
As for software tools to accomplish these things, we can talk about that offline :)
- Eric Lombrozo
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Eric Lombrozo]

Eric,
BitPay clearly do understand the risks of 0-conf. In case you were not aware BitPay does not particularly "accept zero confirm transactions". When a payment is seen on the network the payment screen reports the invoice has been paid, but that's front-end user facing. On the back end it's marked as paid but the API exposes the the confirmation status allowing the merchant to make business decisions about when to progress to fulfilment. A good example of this is Neteller (a sort of paypal variant) which allows one to fund the account with fiat using Bitcoin, via Bitpay. When you pay the bitpay invoice, your account is marked as payment pending until there are some confirmations.

I am glad to hear that. Yes, it absolutely makes sense to let the merchant to make business decisions still pending confirmation (i.e. should I actually ship?)

Coinbase does not expose the confirmation status and from what I understand (not checked myself) they guarantee payment to merchants for 0-confirm, regardless of whether they confirm or not.

Then Coinbase is essentially taking on the role of an insurer
are they taking the appropriate precautions to limit potential losses? Can they make up for these losses with fees? And if not (or if they don’t really have a quantifiable risk model) could they survive a worst-case scenario with at most a surface wound? (i.e. a systemic attack involving many machines in many different places all attacking at once).

It would be absolutely the height of idiocy to guarantee payment on merchandise that has yet to ship, i.e. So I hope these reports are wrong :)


- Eric Lombrozo

[Jeff Garzik]

Post by Eric Lombrozo
Thanks for asking *the* question, Jeff. We often get caught up in these
philosophical debates
but at the end of the day we need something concrete.
Even more important than the specific software you’re using is the security policy.
If you must accept zero confirmation transactions, there are a few
1) limit the transaction amounts for zero confirmation transactions - do
not accept them for very high priced goods
especially if they require
physical shipping.
2) limit the total amount of unconfirmed revenue you’ll tolerate at any
given moment - if the amount is exceeded, require confirmations.
3) give merchants of subscription services (i.e. servers, hosting, etc
)
the ability to shut the user out if a double-spend is detected.

Already done -- BitPay merchants choose their level of transaction
security. Level of confirmations is directly exposed to merchants, so that
they choose the level of risk for themselves.

Physically shipped orders and subscriptions are actually the easy cases and
are already handled. These can accept 0-conf for an initial order phase,
then have the luxury of time to wait for confirmations before shipping /
canceling a subscription.

Electronic goods instantly delivered are the toughest use case. Even
there, merchants choose their level of risk.

Post by Eric Lombrozo
4) collect legal information on purchasers (or have the merchants collect
this information) so you have someone to go after if they try to screw you

The system requests this information on orders yes. Merchants also collect
this info as their needs dictate.

Post by Eric Lombrozo
5) create a risk profile for users
and flag suspicious behavior (i.e.
someone trying to purchase a bunch of stuff that totally doesn’t fit into
their purchasing habits).
6) get insurance (although right now reasonably-priced insurance is
probably pretty hard to obtain since statistics are generally of little
use
we’re entering uncharted territory).
7) set up a warning system and a “panic” button so that if you start to
see an attack you can immediately disable all zero confirmation
transactions system-wide.
8) independently verify all inbound transactions and connect to multiple
network nodes
check them against one another.

Definitely looking at or have implemented this sort of stuff. I cannot get
into detail in public...

[Aaron Voisine]

We should use relay and default tx selection rules to raise the cost of
double spend attacks as far as it is easy and practical to do so. This
increases the value of the bitcoin network by making it practical to use in
more situations for more people. Merchants of course can't rely on them
being cryptographically safe, but the safer they are, the more useful.

The argument that since they can't be made perfectly safe, they should be
as easy as possible to reverse so that merchants learn not to rely on them,
is an incorrect one that reduces the usefulness and value of bitcoin.
Merchants will learn very quickly what the costs of accepting bitcoin
payments are, and the lower they are, the greater bitcoin merchant adoption
will be.


Aaron Voisine
co-founder and CEO
breadwallet.com

Post by Eric Lombrozo
One more thing I would like to add to this thread: I want to make it
unequivocally clear that I believe what is making double-spends easier has
relatively little to do with the protocol and almost everything to do with
poor software and poor security policy on the merchant end. Perhaps it
isn’t prudent to push out changes to the relay policy that make these
exploits even easier right now - but we NEED to be applying some kind of
pressure on the merchant end to upgrade their stuff to be more resilient so
that we have more room for changes on things like relay policy without
significant disruption to the network.
- Eric Lombrozo
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[j***@riseup.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Matt Whitlock

Post by j***@riseup.net
I'd also like to note that "prima facie" doesn't mean "always", it means
that "the default assumption, unless proven otherwise."

Why would you automatically assume fraud by default? Shouldn't the
null hypothesis be the default? Without any information one way or
another, you ought to make *no assumption* about the fraudulence or
non-fraudulence of any given double-spend.

If we have ECDSA proof that an entity intentionally made and publicly
announced incompatible promises regarding the disposition of particular
Bitcoins under their control, then why shouldn't that be assumed to be a
fraud attempt unless shown otherwise?

There are ways of achiving transaction fee adjustment after broadcast
that do not present the appearance of, or opportunity for, fraud. If
those options are available and the user chooses not to use them in
favor of the option that does, that makes bad intentions even more
probable.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEasAAoJECpf2nDq2eYjcwIP/25yoRpNvZkkdFfYiBKaiL/g
XRH8iFAyM5q3/75sA23vD/fzCNGIRRWYyp8PWk+23NF1gdsgVU6gFNNCUmDbjANv
nWTt2Bd926St24jcU+OxMewSGlxpenDSFDNQVtxhNFKst6hoPatwK1Zfa0Eq7/Qw
+r0H2Pse1ulrN4P1n5xnrYMq2w/GF3zinNZbrn2KOZCnsDa8lKlP8y9eNFHBJ//Z
wDrOcfZ1WLhf5/5xlV1NiH0tdxzABilH0ITimm2LCKbj3JcSJayZlyu4n3NypE0E
cVFeYpBaVZW9wuKUv/va5fzcyWDFPAo+OrR2B3siAb8nfY1jONXNhuV3yZ76pzMr
j39lvuSpoTbLobnEWMCJQ5bI/ngbhatT57gqMfF92sO0YjMe/gi/iU6urR9fi5Gz
3Ov6QA78vxzy/YduFjkc/1FV2dNdbGJtq6b0stmz5TtM1uljeGUoj6JZ8kOJ0EXn
857KFAqEd3hG9eYtBdFQcYeV2ShndALBQE0k3cqQvV6XYdHwHuTY15i1nq+u91MZ
VwsR1M69PrDX5Ps6qo1F6QYJA/fA4fyOZ9dwIvh+cgtu4wBptr/NOpL3XH0kE2+G
b2FRGOwdb2KlejIXSL9p4mfJTX9lmk4twbZe2Spjiy4FinOUyzxEobNoUTMcFCU7
Zu2i5yjMlJzrDB8yXz/N
=xtXD
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Jeff Garzik]

Post by j***@riseup.net
If we have ECDSA proof that an entity intentionally made and publicly
announced incompatible promises regarding the disposition of particular
Bitcoins under their control, then why shouldn't that be assumed to be a
fraud attempt unless shown otherwise?

Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.

[j***@riseup.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Jeff Garzik
Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.

Is there not a dedicated field in a transaction (nSequence) for express
purpose of indicating when a protocol like this is in use?

As far as I know, transactions which are using those protocols can be
easily differentiated from those that aren't (which is probably good
from a payment assurance standpoint and bad from a privacy standpoint).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhFW3AAoJECpf2nDq2eYjkegQAINcnzIPbO/bKqNv14TOonb8
9g/pfvMSQyZjUiu4rB6Iwtn+h1hyLkPc3cdSFV4diQSWeG7Q27ZJzH1T1kYdKp4W
DDH8DwD8PtOu+dgRK9eBsy9h72OncA4JTFhnAXMgfLVBY9eRqXk/DWlzwV/WOn/j
3G5xKKOOeHmKJCaKFwdpZghraLouS72AKSdxCNvleRc4zllV+zqWyHHssNDg7sGH
b/62O3DBZXdlzIEzK8/IeaNMY+UXd984/yQ8KCrHCKjc9uiUjNUCCw4JPo4rB/ZA
Itoc8b6pexRs8h40FdXGYAwvN5xQgcaOL7SsN2nNx/DQWYf+1krBO8Iy4kYw2KGl
8JctcHBOI2gLCxTpB2cWeGPwBQbKJhPsmxTxaTNw5fC6ycAnjoJ2bO1Uz0KfwdnI
2jmwxccB9KauC9zNthxGbvdsHOxE8foZ6AnSDI/qbYQK6MqtSnsa7BUn8vc/y4Uf
bVCsxiywVlHttCJqPh5v16rejCcH2el5Rd5PVCkEagxYFfLA3681ZJKD22UV742l
n8ii7RUJXeps6zjRAc35Ccj5qjhB4SP4qYvKmyEoltYbw1EwXbm93UCsFpuxmQ9g
GbQ/jZXsB1cmHBC+c+3X6SaU6eZdy2jDHsICP7sMx2CrZpcZZO058bqRbmdk8JE6
JI17MYG0ofTLfdCfkgEG
=en1q
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Jeff Garzik]

Post by j***@riseup.net

Post by Jeff Garzik
Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.

Is there not a dedicated field in a transaction (nSequence) for express
purpose of indicating when a protocol like this is in use?

No. You cannot know which is the 'right' or wrong transaction. One tx has
obvious nSequence adjustments, the other - the refund transaction - may not.

[j***@riseup.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Jeff Garzik
No. You cannot know which is the 'right' or wrong transaction. One tx has
obvious nSequence adjustments, the other - the refund transaction - may not.

I'm still not seeing a case where a node could see conflicting
transactions on the network as part of a micropayment channel, and not
know it was observing the resolution of a channel rather than a likely
retail double spend.

If both transactions have been broadcast, then one of the conflicting
members of the set will have nSequence adjustments.

Maybe a clever griefer could try to make their retail double spend look
like a micropayment channel, but it seems like they'd be missing the
other identifiable markers of that protocol.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhFhqAAoJECpf2nDq2eYjWtgP/2ir11TUfxoIIzK9t0groKY3
yMR32HP3caDLKdc5ML41jf0l0cp7a54sFPuRE+Am8rkg9ogcf6fho/hCwLnhhNb4
YYBqJ2pzqCU1uN8jwPYSwSw3AO+F+hPE8gcm7lKD297a1k9xpYayAFjChJowoyNT
Wuq9YDkakQeSjV1aCiRHuXNxqnnbymf9xHEiB0buVnSgnyXrgZNCnefAo8DeXYqi
FTSceakNwdkklddK5ObNNK9ZoLpjHhX6hZwRiXsOoG+WUzXhLQ+BsyIFzsCKxQk1
cXjTvLn+Ub9FasRCK5KXMBkkPa1U5JLs1nTn6eTbPyroTs10WLkXWjIpZHrkf7ZW
9RsxoKIRaJur8gbYd6BMvV5rgkfGdb6j24pVNxFF2t89SLo44H0NvqE6koNzgubG
4DyXZ+UlzxzwRVBNDeF4pdlKZGsz2ycvQPuNHRoaZY2IsieMBN/5HEqGNOmXsvKf
tCg1SInO/FkE4njCxSW0R31s2KXCpgVCuq3qmoIKZobDdx7AC8GnpY1rdxUGpVoy
USJwZ2IOgtNfl/rBtOpkp/BaUCmCYOiUj13/ycDrqWvnM4TmiDdzJNEZNfez5UQp
Uvgvstoo88sewv9hGsuBWX0nC+ze/m43ZRReFhQDsypEaOw6pL2LSG9dD3tzulax
TrbPXPlN55NarQ3nmPIW
=Hj0x
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Milly Bitcoin]

"prima facie" generally means that in a court case the burden of proof
shifts from one party to another. For instance, if you have a federal
trademark registration that is prima fascia evidence of those rights
even though they could still be challenged. To say a prosecutor would
have prima fascia evidence of a crime because double spend was detected
is quite a stretch.

Post by Matt Whitlock

Post by j***@riseup.net
I'd also like to note that "prima facie" doesn't mean "always", it means
that "the default assumption, unless proven otherwise."

Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------

[Gigas Gaming Inc.]

This is no longer a mailing list, this is a chatroom.
Please remove this email from your list, you are now interfering with
official company business.

Thanks

------------------------------------------------------------------------------

[Jameson Lopp]

You are free to remove yourself; the URL is at the bottom of every email:
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <

Post by Gigas Gaming Inc.
This is no longer a mailing list, this is a chatroom.
Please remove this email from your list, you are now interfering with
official company business.
Thanks
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[John Bodeen]

from their website, humorous bits highlighted

*October 14, 2014 *In latest Hiatus new, the company has taken on yet
another crazy project but this one is going to benefit the world in which
it entered not long ago. The company had done a lot of research on crypto
currencies, built one for itself, for testing purposes (GigasCorpCoin) and
found the underlaying problem of Bitcoin and was poised to solve it.
Company execs decided it would be a good investment to launch its own coin
and back it itself.
The company is currently in motion and will hire an expert to do some of
the coding by October 14, 2015. Company President refused to be
interviewed due to too much work that needs done for this secret and
upcoming project.
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <

Post by Gigas Gaming Inc.
This is no longer a mailing list, this is a chatroom.
Please remove this email from your list, you are now interfering with
official company business.
Thanks
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Brian Hoffman]

damn he was just on the verge of solving the underlaying problem with Bitcoin and you interrupted his focus.

Post by John Bodeen
from their website, humorous bits highlighted
October 14, 2014
In latest Hiatus new, the company has taken on yet another crazy project but this one is going to benefit the world in which it entered not long ago. The company had done a lot of research on crypto currencies, built one for itself, for testing purposes (GigasCorpCoin) and found the underlaying problem of Bitcoin and was poised to solve it. Company execs decided it would be a good investment to launch its own coin and back it itself.
The company is currently in motion and will hire an expert to do some of the coding by October 14, 2015. Company President refused to be interviewed due to too much work that needs done for this secret and upcoming project.
You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
This is no longer a mailing list, this is a chatroom.
Please remove this email from your list, you are now interfering with
official company business.
Thanks
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Jameson Lopp]

You're only strengthening Gigas' point about the mailing list by posting
derisive emails. Take your nonconstructive comments elsewhere.

- Jameson

Post by Brian Hoffman
damn he was just on the verge of solving the underlaying problem with
Bitcoin and you interrupted his focus.
from their website, humorous bits highlighted

*October 14, 2014 *In latest Hiatus new, the company has taken on yet
another crazy project but this one is going to benefit the world in which
it entered not long ago. The company had done a lot of research on crypto
currencies, built one for itself, for testing purposes (GigasCorpCoin) and
found the underlaying problem of Bitcoin and was poised to solve it.
Company execs decided it would be a good investment to launch its own coin
and back it itself.
The company is currently in motion and will hire an expert to do some of
the coding by October 14, 2015. Company President refused to be
interviewed due to too much work that needs done for this secret and
upcoming project.
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <

Post by Gigas Gaming Inc.
This is no longer a mailing list, this is a chatroom.
Please remove this email from your list, you are now interfering with
official company business.
Thanks
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

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

[Jorge Timón]

The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…

I disagree with this premise. Please, don't take this as an argument
from authority fallacy, but I will cite Satoshi to express what I
think the assumptions while using the system should be:

"As long as a majority of CPU power is controlled by nodes that are
not cooperating to attack the network, they'll generate the longest
chain and outpace attackers."

I can't say for sure what was meant by "attacking the network" in this
context but I personally mean trying to rewrite valid and
proof-of-work-timestamped history.
Unconfirmed transactions are simply not part of history yet. Ordering
unconfirmed transactions in a consensus compatible way without a
universal clock is impossible, that's why we're using proof of work in
the first place.

Alternative policies are NOT attacks on the network.

------------------------------------------------------------------------------

[Eric Lombrozo]

Post by Jorge Timón

Post by Eric Lombrozo
The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time


I disagree with this premise. Please, don't take this as an argument
from authority fallacy, but I will cite Satoshi to express what I
"As long as a majority of CPU power is controlled by nodes that are
not cooperating to attack the network, they'll generate the longest
chain and outpace attackers."
I can't say for sure what was meant by "attacking the network" in this
context but I personally mean trying to rewrite valid and
proof-of-work-timestamped history.
Unconfirmed transactions are simply not part of history yet. Ordering
unconfirmed transactions in a consensus compatible way without a
universal clock is impossible, that's why we're using proof of work in
the first place.
Alternative policies are NOT attacks on the network.

Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.

- Eric Lombrozo

[Eric Lombrozo]

I should also add that I think many in this space believe they have assessed the risk as acceptable but haven’t really considered how to cap potential losses nor made contingency plans for when the inevitable attacks *do* come.

- Eric Lombrozo

Post by Eric Lombrozo

Post by Jorge Timón

Post by Eric Lombrozo
The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time


I disagree with this premise. Please, don't take this as an argument
from authority fallacy, but I will cite Satoshi to express what I
"As long as a majority of CPU power is controlled by nodes that are
not cooperating to attack the network, they'll generate the longest
chain and outpace attackers."
I can't say for sure what was meant by "attacking the network" in this
context but I personally mean trying to rewrite valid and
proof-of-work-timestamped history.
Unconfirmed transactions are simply not part of history yet. Ordering
unconfirmed transactions in a consensus compatible way without a
universal clock is impossible, that's why we're using proof of work in
the first place.
Alternative policies are NOT attacks on the network.

Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
- Eric Lombrozo

[Eric Lombrozo]

Post by Eric Lombrozo

Post by Jorge Timón

Post by Eric Lombrozo
The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time


I disagree with this premise. Please, don't take this as an argument
from authority fallacy, but I will cite Satoshi to express what I
"As long as a majority of CPU power is controlled by nodes that are
not cooperating to attack the network, they'll generate the longest
chain and outpace attackers."
I can't say for sure what was meant by "attacking the network" in this
context but I personally mean trying to rewrite valid and
proof-of-work-timestamped history.
Unconfirmed transactions are simply not part of history yet. Ordering
unconfirmed transactions in a consensus compatible way without a
universal clock is impossible, that's why we're using proof of work in
the first place.
Alternative policies are NOT attacks on the network.

Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
- Eric Lombrozo

I think the misunderstanding was in perhaps my earlier statement seemed like I was suggesting that it’s the protocol’s responsibility to protect merchants from double-spends. On the contrary - I think we agree - the protocol CANNOT make any guarantees to ANYONE until we do converge on a history. The “design” I speak of here is more on the merchant side.

- Eric Lombrozo

[j***@riseup.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post by Peter Todd
If you ask me to pay you 1BTC at address A and I create tx1 that pays
1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
defrauding you, I'm just reducing the value of my change address to pay
a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
Yet from the point of view of an external observer they have no idea why
the transaction outputs reduced in size, nor any way of knowing if fraud
did or did not occur.

If there are two transactions which spend the same inputs, and each
transaction has completely different output scripts, then this is prima
facie fraudulent. https://en.wikipedia.org/wiki/Prima_facie

If the two transactions have identical output scripts, and one output is
reduced in value to increase the transaction fee, that has the
appearance of honest dealing. There is a possibility that the payer has
chose to under-pay their payee in order to over-pay the miner, but
that's not what a reasonable observer would assume at first glance.

Adding outputs to a transaction, while keeping all the existing outputs
exactly how they are is another way of increasing the transaction fee of
a transaction and is prima facie non-fraudulent.

Note that child-pays-for-parent has none of this ambiguity.

Post by Peter Todd
What do you think of Bitcoin XT then? It relays double-spends, which
makes it much easier to get double-spends to miners than before. In
particular you see a lot of zero-fee transactions being replaced by
fee-paying transactions, relayed through Bitcoin XT nodes and then
mined. Is that encouraging fraud?

I haven't closely looked into the features of Bitcoin XT because I'm
hoping that it never becomes relevant. I do want to see a heterogenous
implementation network develop, but Bitcoin XT doesn't really count
since it's a derivative of the Bitcoin Core codebase.

In general, I think every signed Bitcoin transaction sent between
different parties is part of a valid, enforceable contract (using common
law definitions which predate any particular legal jurisdiction).
Handling contracts and money is Serious Business and so the decision of
how software should respond to double spends should not be made
frivolously.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDcpAAoJECpf2nDq2eYj23gP/ja9zqWZBoI/EfTJM0ZDVVY1
7lNwPJrAhO7oKQOKDrqhimA0TPRkoU0rCoYXSUEWn5X8ZIFlz9SQnGwXjIxt7PfG
yZTxF+vJbFCDifNcUlF7DRs07cavEFM9AOutYi8PyVg0LoV5+0VMhhWT4Kc5vnlZ
4Tw91r1lvtI9MCif+KFpida/PnPlhvIfjASEuaK+vYx3ro1ovSUesh558xZmCZ9A
Jfs+EwXBrxDO0zC0fatnaoRMkYQN7i/Dq1PFis7OHcZYBaQwgQTUoF8/wASvr8fQ
dPXJNzhgpYYXeu4IsYH/Of9HkEw+N+/0DEW07asJJ5OIgQmcyoGn+ph8QzrPqG5m
Rgb9BAmpqfCX+KrG6VDxU7xHLebwPhrPoYMIppvf77xhB2mV8c7Xky16Y/1tmxcH
NLOL/WQelNBqCvx2+6c9yDJsJoY12Z0n1tdbIfp3m65xcFzqHPFPtTpsNl0p/gX7
xOMSEUdSVyjvsJjXxWOG3B06+dVRqjS0Pr9ERjjviqx40XVpg4Q0b6y+LL0ZVweE
vs8ECN4y3vB7Qg2swYryVA7kNBh6GwCs7pMCh0DFw1mynGKndCKD+cPh8r3taP1u
8SlrKaD33schk4x70kxbtUzU+C7Yb5187Ct4U5kmsXhz1sypu4ebFPuWbJYG/Sjl
uEW4Vcn+HxlNI/rhxBw4
=odRL
-----END PGP SIGNATURE-----


------------------------------------------------------------------------------

[Jeff Garzik]

This is very disappointing. "scorched earth" replace-by-fee implemented
first at a pool, without updating wallets and merchants, is very
anti-social and increases the ability to perform Finney attacks and
double-spends.

The community is progressing more towards a safer replace-by-fee model, as
indicated by the following code change:
https://github.com/bitcoin/bitcoin/pull/6176

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
---------------------------------------
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
-------------------------------------------
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
-------------------------------
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
------------------
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁎ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
--------------------------------------------
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
-------------------------------
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
https://github.com/petertodd/replace-by-fee-tools
http://respends.thinlink.com/
References
----------
1) "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, May 23rd 2015, Bitcoin-development mailing list,
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,
Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
http://eprint.iacr.org/2015/578
--
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[odinn]

[Dario Sneidermanis]

se, lo re putearon a Peter Todd en reddit por esto

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
---------------------------------------
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
-------------------------------------------
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
-------------------------------
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
------------------
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁎ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
--------------------------------------------
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
-------------------------------
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
https://github.com/petertodd/replace-by-fee-tools
http://respends.thinlink.com/
References
----------
1) "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, May 23rd 2015, Bitcoin-development mailing list,
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,
Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
http://eprint.iacr.org/2015/578
--
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Dario Sneidermanis]

Sorry about that, ignore me

Post by Dario Sneidermanis
se, lo re putearon a Peter Todd en reddit por esto

Post by Peter Todd
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
---------------------------------------
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
-------------------------------------------
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
-------------------------------
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
------------------
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁎ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
--------------------------------------------
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
-------------------------------
https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
https://github.com/petertodd/replace-by-fee-tools
http://respends.thinlink.com/
References
----------
1) "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, May 23rd 2015, Bitcoin-development mailing list,
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun,
Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
http://eprint.iacr.org/2015/578
--
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development