I´ve dedicated some time to research Bitcoin security and resiliency and I´m investigating some possible attacks and corresponding patches. The problem is that I cannot use more of my work time for the project, since I must earn my living. Since I really would like to go forward with this research, It would be great if the community (the developers, the exchanges, all of us) could donate bitcoins to create vulnerability bounties. This would give an incentive for researchers like me to leave out other tasks and focus on Bitcoin. Also bounties would reduce the risk that vulnerabilities are sold in black markets.

For example, we could give bounties (sorted by severity) for:

1. Remote code execution
2. Stealing money by exploiting bugs using specialty crafted transactions/blocks.
3. Low cost Denial of Service of the whole Bitcoin network
4. Lost of privacy / pseudo-anonymity.

In the first 3 cases people should immediately download a new client version to allow the network to keep running.

I think we won´t find many vulnerabilities of type 1-2 but we might find many vulnerabilities of type 3-4. A vulnerability of type 3 may render Bitcoin out of reach for days, and this would cost exchangers (and most of us) a lot of money.

What do you think?

Best regards,
 Sergio.

Thanks Meni Rosenfeld for your support.

I didn´t get angry, I was just a bit ironic. I don´t mind Gabi´s comments, he may be right, and the idea of returning coins is bad. It was not my idea, anyway. It was Hamacher, & Katzenbeisse, as I said.

Though I (as most of the people of the world) would like to be treated politely. Gabi is probably a (clever) teenager. Teenagers tend to talk like that. 

I see trees of green, red roses too
I see them bloom for me and you
And I think to myself, what a wonderful world
...

Regards!

Never again I shall propose such a bad idea. I swear.

There are tons of rules in Bitcoin, just take a look at the source code: each line is in fact a rule. The only difference is that there are rules that are backwards compatible and others that are not.

Some time ago I watched the video "28c3: Bitcoin - An Analysis" by Hamacher, & Katzenbeisse that, among other things, suggests Bitcoin is "doomed to vanish" because of the number of lost coins per year. (see http://www.youtube.com/watch?v=hlWyTqL1hFA).

Lost coins are inaccessible unspent transactions because scriptPubKey is invalid or because the owner of the related private key lost the key.

The video proposal is to give back the lost coins to the community. There is a a simple way to do it: every year (at a certain point, using the block number as index) all coins that were not transferred for the last 5 years are returned to a miners prize pool. The prize pool is divided in equally sized shares and for that year each block mined has an additional price of one share.

With this scheme, every user who owns bitcoins and want to keep them should, every 5 years, transfer the money to another of his addresses.

A 5 year interval does not hurt people using Bitcoins for lifetime savings, and gives enough time to those people to be notified of the change in the protocol.

What do you think?

Regards, Sergio.

Alternate protocols do not hurt Bitcoin as Bitcoin can evolve and incorporate these new ideas. Bitcoin value lies on the community size, not on the protocol itself.

I'm working on a cryptocurrency where miners mix transactions without the need of private keys. I use something like universal re-encryption and a new cryptographic construct that I called "Trapdoor Shuffles".

Also the coin allows coin subdivision and combination without disclosing the amounts (I think it's the first e-cash system with this property).

I will post the paper when it's ready. It already has a name: PAPCash (Practical Anonymous Peer-to-peer e-cash)

Bye! Sergio.

It seems a good app to start modeling. I will test it! Thanks!

What if you want to build or buy a hash-crunching machine  with FPGA/ASIC  like this http://www.butterflylabs.com/.

Then then you only pay the cost only once: so both attacks scenarios seems equally relevant.

But It's true that if you had the hardware, them you would use it as many times as possible, and then the 10-second block currency would suffer for 6 times more attacks than the 10-minute block currency.

This is only partially true: If the attacker owns or buys the hardware to setup a 51% attack on a 10-seconds-per-block currency (with a 6 block confirmation interval) then the attack will require the use of such hardware for 60 seconds. In a 10-minute-per-block currency the attacker would have to use it for 60 minutes, so the only difference is electricity cost (which wouldn't be much) .

6 confirmations of 10-seconds currency has similar security than 6 confirmations of 10-minute currency.

If the attacker hires the CPU from another facility (Amazon Cloud, etc.) to setup a 51% attack, then the attack on the 10-seconds currency is 6 times cheaper (as you said in your post), since you hire computing TIME and not computing hardware.

So the security depends on the capabilities of the attacker and in very general terms, the shorter the block interval, the better.

This is, IMHO, the most simpler way to analyze it.

Regards,
 Sergio.

The information is interesting, but I cannot compute from the graph data the metrics I need.

I'm trying to build a model of the Bitcoin network to analyze the effect of block chain competitions on the current state of Bitcoin and versions with reduced block interval. The objective is to publish a paper on the resilience of the network and estimate the probability of a sustained block chain competition

I need to figure out:

1. What is the diameter of the Bitcoin network?

2. How much time it takes a Bitcoin mined block to propagate to every node?

3. How much time it takes a single node to broadcast a block after it has received it?

4. What is the strategy of nodes and miners in the presence of competing chains? Do they abort and switch to the longer chain?

5. How many nodes are connected by each node by default ?

Can anyone help with any of these items?

Sergio.

No. I specifically left Total anonymization out of the MAVEPAY paper, since anonymization gos against performance in every protocol I´ve seen. MAVEPAY aim is to have the best performance, and so pseudo-anonymous transactions are more expensive in MAVEPAY and total anonymization is not granted by the protocol.

I´m working on the paper of a system with total anonymization as the design rule. I´ve already designed it. Nevertheless, it uses a lot of PK crypto (signatures, trapdoor mixes, universal re-encryption, zero knowledge proofs). I think its performance would be 10 tps (and the bottleneck would be hard disk block chain storage).

Sergio.

Dear gmaxwell,
 Some comments on Bitcoin were favor to it, and not against. The fact that Bitcoin has no free-rides is a pro and not a con!
MAVEPAY, on the contrary, has the DRAWBACK that it cannot allow fees to be paid in all types of messages. Bitcoin is better in this respect: you can (if you want) pay fees in every message, so that the network has a incentive to include them in a mining block.

The sentence  "Every transaction can (and usually must) pay a fee" is somehow misleading, and you're right I should have said  "Every transaction can (and generally do) pay a fee".

Regarding the issue of eternal storage of transactions you're completely right: it's not a problem of the protocol but a problem of the implementation. I know there are now strong efforts to formally describe the protocol (as in the thread "Satoshi Client Operation: Overview"). Nevertheless still Satoshi Bitcoin client source code is the main reference for the description of the protocol.

Last but not least, I want to thank gmaxwell of reading the paper and make these useful comments. Since the published paper is preliminary, I will correct them in the final one.

Regards,
 Sergio.

It is much easier, since in MAVEPAY there are "accounts", you just create an account with two key-chains.

Every enhancement will be much easier for a scheme with user/group accounts, than with transactions only.

Without joking, I admit that Bitcoin does not require MAVEPAY now and Technomage is completely right.

And the fact that I posted the paper in Bitcoin forum proves that I do not want to make another block chain. I'd like to point out that Bitcoin can grow stronger, whenever it needs to.

I'm telling Bitcoin users: don't worry about scalability, when time comes, the we can switch to this protocol.

BUT still some ideas keep spinning in my mind...

What if Bitcoin is not growing fast enough as it could?

What if Bitcoin could grow 100X in a year if used as de-facto online coin for trading in virtual worlds?

What if peer-to-peer poker could be played on the Internet without e-casinos, and each bet is made with a Bitcoin transaction?

What if we are in the edge of a disruption?

Everybody says, we are at 0.1 tps, and Bitcoin community do not need more. This "Community" could grow from 50K users to 5M users in a few months if suddenly one of the things I say becomes real.

The future, is unknown.

There is no prototype. (I programmed it in my mind).
You can easily take BitcoinJ, change the port, and add basic MAVEPAY functionality. I bet it can be programmed in no more than 300 lines of code.

If anyone is interested in programing it, I will help.

Technomage is completely right. Nobody should care if you and me can run a full node. Soon Bitcoin will be completely centralized, as banks. Nobody will be able to run a full node. Then banks will start changing the rules. Also, computers are disappearing, people will only use smartphones...
Then why are we doing all this?
Let´s just stop using Bitcoin and keep using USD or Argentinian Pesos. Or better, let´s use Google Wallet, whose app is really a thin client.

Why did I spend some many nights writing such a paper? I should have been playing tennis with a banker. 

Best regards,
 Sergio.

In MAVEPAY you should never submit the last command of a transaction (which commits the transaction) if there are two competing block chains that are 12 or more block long. That's is just unreal, since I find almost impossible that such competition arises if the network is not disjoint. So you can just forget that comment on the paper, as I does not imply any real limitation but only a warning:

 "Keep an eye on chain competitions. If they are too long, then probably the network was split for some time. Do not finish your transactions. Wait until one of the chains is 6 blocks longer than the other. "

Also, If you reduce the block interval from 10 minutes to 30 seconds (which could be possible, depending on the network diameter and propagation time) then a competition of certain length may occur from time to time.


Sergio.

I checked the code that computes maximum Bitcoin transaction/second.

I found that the limiting factor was NOT CPU, but hard disk space. In requires the HD to be replaced every 1.7 years because it fills up with the block chain. (I assumed that disks should not have to be replaced before the 4.5 average computer lifetime).

Obviously, the Markle tree magic can decrease the space requirements, but I'm comparing Bitcoin as it is today, and MAVEPAY as it can be with a few hundreds lines of code. The paper clear states that I'm not considering possible Bitcoin improvements (there are so many!)

Sergio.