Jacob Appelbaum: "Bitcoin Prediction: Major bugs in the near future ..."

[bcearl]

@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.

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?)

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.

[1713537654]

1713537654

[1713537654]

1713537654

[1713537654]

1713537654

[Stevie1024]

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.

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.

[Stevie1024]

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?)

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.

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

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

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).

[kjj]

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

[jgarzik]

Do you agree that transactions are not safe if not included in the block chain?

*facepalm*

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

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.

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.

[bcearl]

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.

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

2. 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.

3. 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.

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.

[Jaime Frontero]

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:

You seem to be right, looks like not many people are ready to anticipate to what's coming. Think their 'investments' might be blurring their view. Or I'm just plain wrong of course...

[Stevie1024]

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.

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

2. 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.

3. 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.

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

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

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.

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.

[Stevie1024]

*facepalm*

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.

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:

You seem to be right, looks like not many people are ready to anticipate to what's coming. Think their 'investments' might be blurring their view. Or I'm just plain wrong of course...

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.

[Quantumplation]

Where I first intended to ignore any posts containing any off-topics

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.

[Garrett Burgwardt]

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.

[torbank]

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

[kjj]

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.

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.

[jgarzik]

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

Then he should contact the dev team:  http://www.bitcoin.org/

It is known that there are certain ways to DoS a P2P node, but amplification attacks and DDoS are a different beast.

[Montpelerin]

Hmmmmm...

[paulie_w]

so did anything ever come of this?

[flug]

I guess the price wouldn't be $16 right now if a major bug had been found. Trouble is, if he ever does find a major bug in the future, no one will believe him.

[Gabi]

I agree.  For one thing it relies on encryption and a public log.  Encryption can be broken and with bitcoins as is, you can't force new encryption standards on old bitcoins.  As for the public log, if someone branches from it or introduces their own log then we loose credibility of the currency.

Bitcoins is a good proof of concept, but I think the concept will be taken over and improved upon by companies who don't respect the same level of anonymity that Bitcoins and Tor promote.

Good luck breaking SHA 256 

[bcearl]

I agree.  For one thing it relies on encryption and a public log.  Encryption can be broken and with bitcoins as is, you can't force new encryption standards on old bitcoins.  As for the public log, if someone branches from it or introduces their own log then we loose credibility of the currency.

Bitcoins is a good proof of concept, but I think the concept will be taken over and improved upon by companies who don't respect the same level of anonymity that Bitcoins and Tor promote.

Good luck breaking SHA 256 

SHA256 is irrelevant in that context. Good luck breaking ECDSA.

[paulie_w]

sorry to resurrect a dead thread, but did anything ever come of this?