Sybil attacks in Bitcoin are merely DoS attacks unless the attacker is willing to pay the rather large expense of making a fake block. You've turned that relatively minor attack into a dangerous and profitable one.

Anyway, I'm busy enough that I'm happy to let attackers demonstrate that attack for me.

It's fairly easy to manipulate actually; sybil attacks are not that hard to do. (there's evidence they're being used against people accepting zeroconf) I demonstrated a 1BTC fee tx due to the estimator failing. Right now there is a cap of 100mBTC, but obviously that can drain your wallet pretty quickly.

I spoke to them about that - they said the Bloom filter standard was broken in that there was no way to advertise support for other protocol features with very when you don't support NODE_BLOOM...



You mean Pieter Wuille is doing the malleability fixes wrong... So rather than being silly about it, how about you publish your criticisms on the development mailing list by replying to Pieter's request for comments so we can come up with a good long term design. I've already published mine with regard to how the "whack-a-mole" approach Pieter is taking is likely to miss cases, and we should additionally do a soft-fork with new txid-less signature modes. Anyway he's convinced me that it won't be actually harmful, and the code I've implemented will still be useful whatever approach we take.

Note that usually what you call "endless criticism" is called design review. Its gets results too, like how recently a estimate fees design flaw was caught that could allow an attacker - or bad luck - to empty peoples' wallets completely to fees.

Eh, you don't need to bring the word "agenda" into this discussion - Mike proposes a lot of ideas that the core devs are opposed too, often strongly. For instance getutxos was strongly opposed by Pieter, Jeff, and Gregory with only Gavin in support and Wladimir moderately supporting. Similarly double spend relaying is something Mike supports that has had little support other than Gavin. There's also fee estimation, particularly SPV nodes getting fee estimates in an untrusted way. As for his stance on soft-forks, basically no-one agrees with him that they're a bad thing. And of course there's Coinbase reallocation....

Seems to me the guy is annoyed that his ideas aren't getting support more than anything else. This isn't a funding issue, this is because the ideas aren't something others agree with.

OTOH look at Pieter's quite reasonable BIP to fix transaction malleability, which has plenty of development effort going to implementing it - I personally have written two patches, one merged, going towards implementing it. Of course, you don't hear about that because its a good, well-argued, idea that hasn't generated any controversy.

Meh, Mike proposes terrible ideas all the time. Predictably it's getting shot down, and will probably sit there unmerged forever, just like his pull-req to turn the totally broken nSequence replacement back on. Heck, I'm only really replying because I'm quite fond of polishing my writing skills; it'd probably be more productive to get it merged and attack it later.

Speaking of, if you want to have some fun with dumb unauthenticated applications: https://github.com/petertodd/bitcoin/tree/bloom-data-hiding-attack

Also, your double-spend attempt thing is missing dozens of double-spends that I'm seeing on my replace-by-fee nodes.

As you should know every transaction you include increases your orphan rate. Prior to the v0.9 fee drop transaction fees were probably already low enough that adding transactions to your blocks actually cost you money, based on careful measurement and analysis done by myself and others; lowering them by another order of magnitude definitely put them below that limit. FWIW I've spoken to some mining pools and large mining operations who have also told me this was their reason for rejecting the 0.9 fee drop.

After all, why risk orphaning a block, worth ~$16,000 USD, when an entire block full of v0.9 transaction fees is only worth $6.50 USD? If they're "leaving money on the table" they sure as hell aren't leaving much.

I suggest you spend some time playing with my replace-by-fee tools, especially the doublespend.py script. Double-spending zeroconf transactions is really easy.

tl;dr: Mine with Replace-by-Fee v0.9.1 and you'll earn 1% more per block found, or 0.25BTC.

I'm running an experiment right now with replace-by-fee. Basically I'm doing continuously testing it, such that at any one time the extra fees from the test represents about 1% of the block reward. A site considering using the "scorched earth" defense to make accepting zeroconf transactions safer wanted me to get an idea of how willing miners would be to upgrade - I figured 1% would be an interesting starting point.

You'll need to compile and run the above tree. It's based on the v0.9.1 release with one small patch. Other replace-by-fee peers are automatically found on the network - you don't need to add replace-by-fee peers explicitly for it to work.

As for what this is all about, replace-by-fee simply means that rather than only accepting the first transaction you see to your mempool, you accept whatever one pays the most fees. It's a simple rule that results in the most profit per block, lets users re-issue transactions with higher fees if needed, and makes it clear to everyone that relying on unconfirmed transactions by themselves is insecure rather than giving people a false sense of security. Most importantly it ensures people use Bitcoin in a secure way, relying on crypto and incentives rather than relying on trust, which will help keep Bitcoin mining free of regulation and decentralized.

More info:

Why you should mine with replace-by-fee

Double-spending unconfirmed transactions is a lot easier than most people realize

No-one is running a pre-0.8 node right now; a few months ago there were a number of them, including unpatched ones. Like I say, it's non-deterministic behavior rather than deterministic.

BIP-0030 is a soft-fork, and yes, 100BTC was permanently destroyed.

Heck, a 0 of m CHECKMULTISIG is valid...

Your P2SH transaction is from prior the P2SH turn-on date, which is why it was allowed into the blockchain at that time.

You're missing a few early ones:

The max blocksize was reduced from 32MiB (an accidental limit?) to the present 1MB.

Various limits were added/lowered on PUSHDATA length, sigops, etc. (this happened multiple times)


OP_RETURN marks tx as invalid was also associated with changing the scripting system to evaluate scriptSig and scriptPubKey separately, rather than concatenated together with OP_CODESEPARATOR in the middle.

Also the Berkely DB bug is arguably not really a hard-fork as it wasn't deterministically triggerable - only most, not all, 0.7 nodes had issues with it.

Academic discussions aside, in any case what has been actually implemented in Dark Wallet is that you have two classes of users: people who want to send money now, and people who have coins that they want to mix. The latter don't have any particular requirements on the exact amounts they want mixed, so they copy the amounts the former are sending, guaranteeing that at least two outputs are identical and have two possible senders. Blockchain.info's CoinJoin implementation is similar, with blockchain.info operating maintaining a pool of funds that is used to copy exact output amounts.

Future implementations can and will improve on these concepts, but again, what's implemented now takes output indistinguishably into account and provides reasonably good privacy already.

That's exactly the kinds of solutions that will be implemented in the future for CoinJoin. They haven't yet been implemented purely as a matter of priorities: 1) Don't lose funds. 2) Don't reveal users' identities. 3) Be robust against attacks.

Exactly. Right now about $8,000 a day is being paid in transaction fees - an attacker would have to spend multiple times that per day to cause problems. Of course, transaction fees are ultimately just a supply-and-demand market - if an "attacker" wants to outbid all other buyers for a limited resource, are they really attacking anything?

There are other issues too, e.g. the DoS attack vulnerabilities caused by Bloom filters, but there are fairly reasonable ways to fix those issues. Again, when you put a price on something, so-called DoS attackers become well heeled customers!


Thanks!

In my experience Hearn's views are rarely supported by other developers.

Bitcoin's P2P network is far more DoS resistant than most because we already have a valuable token - Bitcoins themselves - that we can use to make DoS attacks expensive. For instance even though transactions are flood-filled to every node DoS attacking the network by flooding it with transactions is sufficiently expensive that such attacks rarely happen. Tricks to make such floods less expensive are considered exploits and fixed. Of course if you want to use the P2P network for free, you can be outspent by attackers, but such is life in an anonymous system. It's notably most of Hearn's work experience was at Google combating email spam via adding centralization to email and strongly tying your ability to send an email to you email provider's identity, and by extension your own. Compare that to Adam Back's early work combating email spam via hashcash, a decentralized technology that eventually lead to Bitcoin itself.

Ultimately in any system security has a cost. In centralized systems that cost tends to be your privacy and freedom, in decentralized systems that cost is direct and monetary.


We've always known Bitcoin faces serious threats, e.g. scalability, mining centralization, blacklists, etc. Whether or not they're going to be solved is an open question, however it is clear there do exist potential solutions.

I don't have to actually! The replace-by-fee supporting nodes preferentially peer with each other, so there's always peers to relay your transactions. Since those nodes are well connected they have a pretty good shot of getting your tx to a miner who is accepting a higher fee but not the lower one you tried first. In practice this already works really well when bumping fees past the 0.8/0.9 fee drop, or between the various 0.8/0.8 tweaks to fee acceptance.

Just to be clear, the above is a complete, working, implementation of the idea. Any wallet software that handles double-spends and mutability correctly can implement it without much difficulty.

See my replace-by-fee-tools, specifically bump-fee.py for an alternative based on increasing your bid. Not always convenient by itself - fee estimation is still useful - but being able to increase fees after the fact lets you be much more aggressive in your fee estimates.

Payments with merge avoidance are more expensive for the payee to redeem so you do have to ask permission.

Note BTW that the intent of merge avoidance - as described in Mike Hearn's original writeup - was to be an alternative to CoinJoin that still had some privacy while also allowing blacklists to be applied. Merge flexibility w/ CoinJoin is a much better idea and fights against blacklisting. Similarly cut-thru payments, which the payment protocol can support.