Topic: Jacob Appelbaum: "Bitcoin Prediction: Major bugs in the near future ..." - page 2. (Read 14850 times)

Oddly enough, this is probably correct.  The enforced limits are very likely to be non-optimal.

Also, all other possible values are equally likely to be non-optimal.

Twitter user @smarimc claims to have found a protocol level bug that allows the Bitcoin network to be used for a DDoS attack.

The new bitcoin paper is filled with inaccuracies, as was stated by Jgarzik earlier.

1. Enforced limits are not optimal

First, how do you know? Second, the only things enforced by the block chain is block creation speed. The rest are completely client side. You would be better off designing a better client with the same protocol.

2. Not truly decentralized

See previous comments. Run whatever version you like, ie, whatever version of the protocol you support. Anyone can fork it should they wish, though most have doubts about the success of any forks without insane action by one of the core dev team here.

3. Unmanageable storage requirements

Client side (again). Pruning is planned out, but not implemented. Headers only mode is being worked on.

4. Unconfirmed transactions are not safe

Saying unconfirmed txs aren't safe is like saying that promissory notes from a stranger on the street aren't safe.

5. Current distribution is unfair

Oh, this again.

Everything you've posted is off-topic.  This was about the speculation of one twitter user, not a boasting grounds for you to show of that you know how to use LaTeX.

Where I first intended to ignore any posts containing any off-topics, disdain or worse (#56) of which above quotes are only an example (much more in the 21.000.000 limit thread), I've come to the conclusion that I'm not willing to waste my time in this way. Therefore I will not continue to post in this thread.

I am definitly willing to continue discussing what has been discussed, as long as it is done in a civilised manner. I can be reached at the forum mentioned in the above quote.

That might or might not be true. A well defined system should not have to depend on exponentially growing computer power.


If a new node comes along, one has to convince this node that account balances are correct. Multiple transactions lead to one account balance (that's why they'd take more storage). If only the account balance is stored, the transaction information cannot be recovered. If a hash of the transactions is stored in the chain, this hash cannot be used to prove account balances. Therefore a hash of account balances should be stored in the chain.

i note that forum.newbitcoin.org is all the way up to eight posts now.

five of which belong to mr. appelbaum.

...and one of which includes this bit of prescience:

1. The solution is that computer ressources will continue growing exponentially. Bitcoin data will do definately, no matter whether you prune some trash.

3. The client can just download the blockchain and throw it away, keeping account balances and hashes of the last block in a local database.

*facepalm*

This is stated in satoshi's original paper, and should be patently obvious to anyone.  Block chain confirmations equal transaction security.


Pretty much.  The vast majority of this stuff is covered in satoshi's original paper, the wiki or FAQs -- all of which are easily accessible.

Section 2, misunderstanding of how the network works, particularly in regards to relays.  Explained earlier.

Section 3.1, a spender looking to send a transaction with a fee big enough for you to care will be well connected.  80+ connections is trivial today.

Section 3.2, some of those limits are hard, and some are soft.  There is nothing to suggest that any other value for the hard limits would be any better than the ones we have.  The soft limits can be (and have been) changed as the network evolved.

Section 3.3, those developers are actively helping other people create alternative implementations of the software.  The developers all understand which limits are hard and which are soft.  What is your excuse for not having researched the matter?  Any hardcoded checkpoint blocks that are not in agreement with the rest of the network will  prevent those implementations from catching on, this applies equally well to new versions of the original client as it does to upcoming alternatives.

Section 3.4, pruning code already exists.  It is not widespread because there is no need for it yet.

Section 3.5, I'm sorry you don't understand the script system.  It isn't a vector for malware infestation, and probably never will be because it only supports a small number of cryptographic and mathematical functions.

Section 3.6, we all knew that unconfirmed transactions were unsafe before you arrived to show us.  Your notion of nodes forgetting transactions, however, is pretty silly.  Even more silly is that they have to forget them in such a way that they remember not to get them again when another node offers.

Section 3.7, I'm sorry you showed up too late to the party.  For what it is worth, I did too; I have around 10 coins to my name.  I also observe that the universe doesn't give a fuck what you consider fair, and neither does anyone else.

The rest of your proposal is harder to dissect because it consists of a series of conjectures with no evidence backing them up.  Here are the highlights.

Sections 4.1 and 4.2, storing balances instead of transactions won't give much space savings.  Addresses are no more limited than transactions, unless you think you have some way to limit each person to one address.

Section 4.3, I LOL'd.  Hint, the hard part is mining, not pushing transactions around.

Section 4.4 is madness.  The chain will reshuffle thousands of times each day.

Section 4.5 why the hell would anyone care how many hashes you did?  Are your hashes valuable in some way?  In bitcoin, there are answers to these questions, and those answers are critical to the functioning of the system.

Section 5, Conclusion.  You don't understand any of the important decisions that went into the design of bitcoin.  Either that or you are a very special kind of troll.

Edit: Oops, section 3.6, changed safe to unsafe

Have to ask: who can't withdraw, payer can't revoke his transaction (or double-spend) or payee can't use the payed money?


No, I don't think it is a problem either, only a limitation. I wanted to make readers aware of it, as I am proposing a system with running balances stored in the block chain (and with the same limitation).

There you have me! I know of no proper solution for that either unfortunately...

I only worked out (with a simulation, math was too complicated for me) how much more space. I didn't feel like working this out for the current Bitcoin transaction-storing blockchain, didn't feel that that was up to me.

It would surprise me if the block chain format wouldn't have to be changed for it, but must admit I didn't give that too much thought as there's more issues that I'd like it to change for.

I would state it like this: When you make a transaction, and it does not get in the block chain, you can't withdraw it either.

I don't consider it a huge problem, but I can't see that there is any solution possible to that problem.

Thanks bcearl. I hope you will excuse me, I try to stick to the bugs I think I found. But if you found a different one, please have the current devs look into it!

What I am not sure about now: Do you agree that transactions are not safe if not included in the block chain? (And 'buried' under enough blocks?)

Your pruning suggestion will not work, because the number of accounts will also grow.


And you don't have to change the block chain format for achieving that anyway.

@Stevie: Your paper paragraph 3.6 is a serious bug, but in a very different way than discribed:

The is no danger of double spending as long as payees wait for confirmations in the block chain.

But there is a vulnerability. Think of the following:

1. A wants to pay B some BTC.
2. A draws that transaction X (signet with his key).
3. The transaction gets not included in the block chain.

What now? A can now ignore that or draw another transaction Y. Maybe transaction Y got into the block chain.

What attack is possible now? Right: B can steal coins from A by sending the already drawn transaction X into the block chain generation.

Start refusing?  Hmm.  I suggest you take a look at the source code to the default client.  There are already rules in place regarding which transactions to forward.

If I have time, I'll write a detailed refutation.  But no promises, Mondays are usually fairly busy, and I probably won't have time.

Right, another one using bold language without taking me on on the main issues. Actually there's nothing wrong with the example given in section 2. I changed the source code, and where before transactions would require (at that time 0.01 bitcoins) transaction fee, after my change it wouldn't. Of course it is easy for the other nodes to start refusing my transactions, I didn't state otherwise and I think it's been done already.

If you do a line by line rebuttal, I'm sure you will find something valid if you try hard enough. But, from now on I'll only respond to critique that affects the main issues that I stated, so spare yourself the time. I'll also respond only to critique (and have been doing so allready) that is put politely and does not involve any disdain or false accusations. I trust there's people out there that will understand the incapacity of people using such manners.

Ugh.  That newbitcoin paper is a trainwreck.

In section 2, for example, the author has no clue how the network works.  It is trivial for a person to change their node so that it does not include transaction fees.  Much less trivial, however, is getting the rest of the network to forward them, or miners to accept them.  (Yes, I know that at least one mining pool always accepts free transactions, and it is trivial to connect to it.  I'm speaking more broadly here.)

I gave up another couple of pages in.  I sorta wanted to do a page by page rebuttal, but it would really need to be more like line by line.

Ignoring, for a moment, the glaring problems and misconceptions in your paper, it's horribly and arrogantly written.  You wrote down some internal musings that don't really flow into eachother, changed any "I"s to "the author"s, deemed it worthy to slap an abstract on it and convert it to PDF, and have posted it in nearly every thread you've posted in.  To me, It seems you like to play the scholar, and fancy yourself an intellectual without understanding how to write a cogent and thorough paper.