Very very simple yet powerful 51% solution

[laurentmt]

2. Evil: My idea follows protocol, are you seriously saying I found a lethal hole in the Bitcoin code?  

@realpra

I didn't say that your idea is evil, I said that running a untested idea in production environment is evil.
This is a basic principle of software engineering. If we can't agree on that, I fear it's going to be difficult to have a constructive discussion.

By the way, considering that :
- any node respecting a few rules can join the network without being excluded,
- for now, many mining pools can be identified thanks to the address appearing in coinbase txs,
- running a bunch of full node is not so expensive if attacker is motivated and has some fundings,
I would say that, yes, there's lethal holes, if not for the whole network, at least for mining pools.
According to me, problem is not in bitcoin code but in current mining pools' behavior (address reuse). But may be I missed something and I'm wrong.

Anyway, I keep thinking that if you're serious about your idea (i.e. you want to implement it and you want to convince people to use it) the first step is to show that it does not harm the network with a simulation. This is without any doubt the cheapest way to come up with an effective and deployed solution.

[Realpra]

2. Evil: My idea follows protocol, are you seriously saying I found a lethal hole in the Bitcoin code?  

I didn't say that your idea is evil, I said that running a untested idea in production environment is evil.
This is a basic principle of software engineering. If we can't agree on that, I fear it's going to be difficult to have a constructive discussion.

I am a programmer and I have worked for a professional software company for almost two years. This company is the best in the world in its field.

If you think untested/partially tested code never happens in production I'm guessing you can't have much software experience.

Its undesireable, calling it evil is crazy talk.

I would say that, yes, there's lethal holes, if not for the whole network, at least for mining pools.

Forget my idea. I think you don't understand Bitcoins P2P protocol. No offense, but the worst thing some new node type can do is get itself ignored/kicked off.

I would love to test my idea and develop it, but unfortunately I don't have those resources so I have put up a bounty for a simple fix and described it.

That is even if it did work; it doesn't seem to. I fail to see what stops miners from gaining multiple cryptographic identities and bypassing the whole thing. You even allude to this yourself. So why bother?

Yes that would be possible, but they would HAVE to be trusted ids if they wanted more than 50% control - trust which they would loose it again if they started misusing said trust by severely pissing off users enough to get kicked off the trust lists.

So trust me there is a point and that is to put Bitcoin in the hands of the USERS.

[laurentmt]

I am a programmer and I have worked for a professional software company for almost two years. This company is the best in the world in its field.
If you think untested/partially tested code never happens in production I'm guessing you can't have much software experience.
Its undesireable, calling it evil is crazy talk.

Well, well, well.
I'm a software engineer (for more than 15 years) and I repeat it : "untested code put in production is evil" (understand "bad" or "faulty" but not "malicious" or "vicious"). The fact that it happens does not mean it's a good practice. Never. Just ask yourself if you would like to fly in a plane while knowing that its system embeds some untested code. Period.

Forget my idea. I think you don't understand Bitcoins P2P protocol. No offense, but the worst thing some new node type can do is get itself ignored/kicked off.

If you test your idea with a unique node in the network, for sure you'll be able to check that your node doesn't crash but you won't be able to check its effects at network level because it won't have any visible effect. I don't pretend to be a p2p expert but I know a few things about networks / network dynamics and the difference between what you can check at node level and what you can check at network level (emergent behaviors).

3. Unified lists: My solution only requires 1% trust overlap ok?
That means if you trust ANY of the pools you know of today.. you have consensus.. congrats.

I see now. So you intend the main feature to be slowed block propagation.
Block propagation can cause a fork too, though. In fact it already does (re: the fact we ever have orphaned blocks at all).
It is resolved quickly enough because we have no barriers.

I fear that it's the point on which Realpra disagrees with all of us. Considering that none of us is able to convince him, my last best effort is to recommend the reading of this paper from microsoft research.

In the case of transactions, stopping the propagation is a reasonable trade off, that protects the network from transaction spam, at the expense of individual users. However, in the case of blocks, stopping the propagation is not reasonable.

I was trying to be constructive, but Realpra's free to burn 2k$. This is his money.

At last, a well known story, to meditate

A little bird was flying south for the winter.  It was so cold; the bird froze up and fell to the ground in a large field. While it was lying there, a cow came by and dropped some dung on it.  As the frozen bird lay there in the pile of cow dung, it began to realize how warm it was. He lay there all warm and happy, and soon began to sing for joy. A passing cat heard the bird singing and came to investigate. Following the sound, the cat discovered the bird under the pile of cow dung, and promptly dug him out and ate him.