Topic: Very very simple yet powerful 51% solution (Read 3859 times)

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.

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.


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

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.

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.

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.

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

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 can come up with lots of solutions that would involve violating core assumptions. I'm sure gmaxwell and others can do much better than me.
None of us _want_ to see the network go down. But the solution, if one exists, must have upsides greater than its' downsides.
I don't believe yours does. It's not intended as an insult.

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?

This is basically exactly the barrel you are looking down RIGHT now.

1. Pools and their operators are mostly known and a handful controls everything.
2. Government finds them and takes over (or evil pool does).
3. Now only government approved transactions occur, NO transactions occur or chargebacks could become standard.

Once an attack occurs and no solution is in place, multiple solutions will take place, but too slowly and too many and Bitcoin is fragmented to death.
It would not survive this, even if patched later.

People would switch to the first coin with a solution which would likely be an altcoin or an alt of Bitcoin.

... or we could just boot up my client idea.

I have later stated and in my edit of the first post that you could sign the transactions minus the coinbase only. Thus you are NOT signing the "block" but contents.

I have been in too many forum debates to put up with someone who wants me to be wrong no matter what - even when solutions are obvious.
So I will focus on technicals from here on and not entirely opinion based argumentation.

This is not entirely correct. No one gives a damn about miners. It is the users and acceptors of Bitcoin that give it value and if 90% of them use a client that protects them against selfish and centralized miners then that IS Bitcoin.

But yes the usually well-connected miners would not notice this new type of node for a long time.

This is wrong.
The hardfork punish mode for 100% untrusted blocks could be disabled in the beginning. Then the clients would only delay the normal blocks. It would be no different than someone closing their normal fullnode and opening it the next day.

[quote author"people"]consensus falling apart + my idea is evil yada yada unified lists, anonoymity
[/quote]
1. Consensus falling apart: Since my idea would ONLY and I repeat ONLY hardfork in the event of 100 untrusted blocks in a row (if enabled) it would require a significant amount of nodes (>+10%) to ONLY have 1% trust overlap for any consensus issues.
Since "trust" JUST means "anyone who spits out okish blocks" this would be insanely unlikely and the client could warn the user to trust more WELL before that happened.

I want to elaborate on this case: ~90+ blocks from untrusted sources what could that mean? It would literally NEVER happen UNLESS the network was deep in an attack!

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

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.

4. Anonymity: I have outlined several ways someone could mine anonymously in my system. (using someone elses block content/signature, not using IDs at all and the fact that the trust IDs are pseudonymous just like Bitcoin for Christ sake!)

I'm sorry but saying "I'm wrong because I'm wrong" just doesn't work.
Saying its "not anonymous because its not anonymous" also doesn't work. It is not true.
Etc..
I've been in this kind of forum debate a billion times.


What are YOUR solutions to the 51% attack?
We have a situation where bigger=better/more economic so what exactly stops pools just growing and growing until we have "GovPool" and nothing else?
I'm waiting...
Oh you just have unfounded criticism duly noted, bye bye.

@DeathAndTaxes
Sure, you're right but the fact is that OP (or someone else) could implement a similar solution which does not require miners opt in. Right now, the easy solution would be to use the fact that many mining pools reuse the same bitcoin address in coinbase transactions. Of course, miners could defeat this strategy by changing their behavior. But we can imagine that OP (or someone else) adapts his strategy by using what I called "Pools of full nodes" in a previous post.

+1
The more I know about bitcoin, the more I feel I don't know anything about it. There's a lot of very subtle choices which have been made, which are very important for network security but too often outside the radar of many devs.

@gmaxwell: WRT to mining pools reusing bitcoin addresses in coinbase transactions, shouldn't we consider that it goes against "anonymous mining" principle ?

Miners don't really care about the propagation of blocks to all nodes (users).  What matters is the propagation of blocks to other miners.  If 51% of the miners opted out of such a "delay system" it would have no effect on the extension of the longest chain.  It would however be exploitable by attackers because the nodes of users would falsely be showing a chain which is inferior to the longest chain.  This is very similar to an isolated attack except this would be one that users opt in to be exploited.  It is cliche but information IS power.  Information asymmetry is even more powerful (I know something you don't know) and exploitable in lots of ways.   Optimally nodes should be well connected so they gain access to as much information about the network as possible.  Anything which puts up barriers to the flow of information reduces security.

Somewhat meta but it may be useful to formally write out the assumptions in the security system used by Bitcoin.  All security systems are based on assumptions.  For example an assumption of ECC and thus ECDSA and thus Bitcoin is that the discrete logarithm problem is and will continue to be intractable.  Putting all these assumptions on paper would lead to some information sharing and hopefully improve the thought process of "solutions".  You can't improve on a system until you understand the system.

@azeteki

Indeed. My question was more related to the 2nd scenario (miners include IDs in blocks).
The main effect of OP's idea is to slow down the propagation of blocks. Thus, it seems logical that for a given network topology, the strength of this effect would depend on the number of 'Ids nodes' using OP's solution.

Connections among peers in bitcoin network are evenly distributed to create an expander graph and to avoid hub nodes which are prone to targeted attacks (see part of this thread related to bitcoin network topology). If we imagine a solution which doesn't break the consensus, I think it would require a given proportion of 'Ids nodes' to reach the initial goal (rejection of blocks by the whole network).

Without some sort of additional bootstrap condition? Until miners begin to include an ID, nothing happens and anyone using this client is twiddling their thumbs.


'ID clients' would simply act as dumb receivers because blocks do not have ID's yet.


'ID clients' would sit at block 100 forever. Or at 'checkpoint_block' + 100.

With a bootstrap condition and assuming miners actually began to include ID's then you enter all of the issues listed earlier re: consensus falling apart.

It's at the brainstorm level; it's not a proposal yet.

It does not sound to me like a good strategy for several reasons:

• I like your enthusiasm but you can't simply erase the concerns voiced by others commentors about the risk of consensus splits.
• main network is a production environment. I'm not sure that 51% problem can be tested in testnet and testing ideas in prod. env. is EVIL
• I think that you define a wrong objective for your test (which client works the best). The objective should be to determine if the network works better when it includes a proportion of your client. Question: which proportion of your client is required in the network before we start observing its influence ?

On my side, I think the proposed solution has several flaws, but if you want to go forward with this idea, your first step should be to create a network simulator which proves that the concept doesn't harm the network. This kind of simulator should be open, allowing anybody to check and validate that assumptions are correct and that the solution doesn't harm the network.

A network simulator has already been developed in javascript. May be you can reuse it for your needs. There's also netlogo which is a nice environment to prototype simulations.

Also, as gmaxwell alludes to above; arguably a consensus failure is worse than a short-ish miner-induced reorg.

While you have two competing chains, anyone with a small amount of technical know-how is able to spend on both chains, abusing anyone who hasn't figured out there's a fork yet.

I don't think this can work at all.
If it even can work, what you'd have at the end would no longer be Bitcoin.

First of all, everyone needs the same trust list.
'it only takes effect if 99% of blocks are untrusted' is the case you're actually defending against.
So it needs to work and not cause consensus failure, however rare it may be.

Same deal for relaying. You would have to block acceptance in addition to relaying.
Otherwise, you'll have a local chain that you refuse to share with anyone else, orphaning yourself from portions of the network.
Even if you do so, you'll still end up with disagreement on the latest blockhash.
The network would gather into forks with similar enough 'trust lists', until a disagreement is found and it splinters even further.
Adding or removing items would require going back over the entire chain, since you could have refused a block that you've now decided to trust.
Unless you have rules like 'only trust ID x after date x'.

Secondly, assuming the above wasn't an issue somehow:
I don't see how anyone (whether it's an individual user, or a group acting on behalf) could maintain a reasonable trust list.
Allow too many ID's, and that could potentially mean a single mining entity has tons available to them.
Allow too few, and you block legitimate miners from the network (ultimately centralising Bitcoin even further).

Both of the above issues ignore the issue of how to uniquely identify users over the network (basically, one vote one miner).
If you can solve that, you don't really even need PoW. Just have a distributed vote.

If widely used this "solution" would be hazardous to the network: in cases where it would do anything at all it would cause severe consensus splits (and the resulting reorganizations of length long enough to permit successful double-spending), without some centralized process to ensure complete uniformity of the "approved list" even users of this approach could become consensus-split and it would encourage miner consolidation and registration with an approval authority to avoid being on the losing side of such a split / or suffering block delay 'punishment'. It would almost certantly result in taking the currently broken status-quo where there are only a few miners at all and nearly setting it in stone, and it would set us up for an ugly path where miners now had identities and it was interesting to start talking about other restrictions for them.

Ignoring the wrongheadedness of the overall design for a moment, the actual proposed implementation is still broken:
You cannot include a signature of the block into the coinbase because the block (which includes the coinbase) cannot be modified once it is mined. If you include a signature of the height than once a block has been released at that height an attacker can just move it into a new block they mine at that height— impersonating them with the rebinding.  ... this sort of thing can be fixed, but if you cannot get right even some of the boring details why do you think you have a overall design that does anything except causes harm?

While I fully support someone taking realpra's money, if he keeps insisting after having these things explained to him, do so with no expectation of adoption. I certantly would have nothing to do with any project distributing an approved miner ID list, since influence over would be a risk to my personal health and welfare (not to mention that of the Bitcoin system), and I'm confident that very few people would be foolish enough to run such software.

I welcome all the comments and the technical feedback. Its the votes I don't understand who seemingly know some technical detail the rest of us do not.

I suppose I should not put too much weight to random votes on a forum.

If the ID is created by the miner signing the transactions except the coinbase transaction then you could have "Signers" who would only create blocks and sign them.
Then they would publish this block of transactions and the signature.

Then any miner could become "trusted" by just mining these same transactions and including the signature. A single trusted "Signer" would mean that every miner could mine entirely anonymously.

I don't know if you are wrong in your interpretations, but I do not think my system would cause any problems with anonymity of miners. They used reputation IDs on Silk Road and Bitcoin itself is "only" pseudonymous.


But here is the thing: My idea is possible NOW, no changes required. I think we established that much in the thread though I had to change things a little. So if we have a group tomorrow running this kind of "reputation client" and another running the normal clients no one would notice.
There could only be two outcomes:
1. The reputation client works the best during an attack and everyone switches.
2. The normal clients work the best during an attack and everyone switches.

2000$ to whoever codes it. (Contact me for "it" details)

Realpra's proposal has activated the "thought experiment" mode in my brain.  

For now, there's nothing in the protocol like the pool id suggested by OP.
But we can see that addresses used by mining pools for coinbases outputs play a very similar role, since most mining pools reuse the same address.
I guess that bc.i builds its statistics with a heuristic based on this behavior.

From this observation, we could imagine that some full nodes decide to use their custom version, implementing custom rules to broadcast blocks (like those proposed by OP) according to the address appearing in the coinbase.

One could argue that mining pools could defeat this strategy by using a new address for each block.

That point leads me to a weird idea.

Could we imagine that some actors decide to create pools of full nodes (PFN) organized with the following principles:

• some nodes in the pool have a special role: they're also member of a mining pool and act like "trojan horses". They broadcast informations to the PFN, allowing to identify future blocks created by the mining pool (like the new address used by the mining pool -or anything that can be used to identify the block-).
• a central node could be used to gather informations retrieved by first nodes and notify others nodes about the policy (which blocks must be broadcast or "penalized").
• the others nodes are just here to apply the policy by broadcasting or not the blocks. PFNs with large number of nodes are more powerfull since they have more impact on the propagation of blocks*

What kind of policy these kinds of pools would apply ?

• "Regulation" of mining pools as proposed by the OP
• "Pay for broadcast" fee: the number of PFN nodes which broadcast a block is proportional to a fee paid by the mining pool to the PFN. This fee could appear in the block as an output of the coinbase transaction sent to a given address**. This fee would be used by the PFN to fund the running nodes and get some profits.
• A mining pool funds a PFN to penalize its concurrents (that's bad).
• ...

Don't get me wrong. I don't say this is a good idea. May be it just opens the Pandora's box.
I just wonder if this kind of model could emerge and what are the possible outcomes (positive or negative).
The advantage of thought experiments is they don't break anything.


*: If I'm right, cost of running a full node is estimated to 20$/yr. I don't know what is the threshold for a PFN to be considered as having a significant impact but 80k$/yr to own 50% of the actual network doesn't seem like a huge cost for a funded company expecting some profits from this activity.

**: The agreement between the mining pool and the PFN could also be hidden. The fees being periodically paid, using normal transactions.

Right "anonymous" in this context is about participation having "membership", not about privacy (though anonymous and anonymous do sometimes go hand in hand).  Sorry about that, it's a bit of terminology overload that occurs in the literature.

Hi Realpra,

No intent on my side to sabotage your work and I think it's the same for the others commentators. I truly apologize if you felt things that way. Comments/critics can sometimes be done in a very positive spirit, in order to strengthen an idea.

WRT to my quote, I think you misunderstand what gmaxwell & adam3us mean by anonymity. I think it's not about knowing the name of a miner (or whatever personal data) but it's related to anything which identifies the miner (even if it's just a reputation id). Well, I'm not an expert and I may be wrong in my interpretation. May be you should submit this idea to adam3us.

Anyway, I fully support your effort to address a difficult and important subject. Keep up the good work !

You in Raleigh?

Don't give up

resisting of change is just human and every great thinker and visionary has suffered from public opinion. If people vote for no it doesn't mean that you're wrong about this.

I think this as good idea but my script blockers dont show any voting system on screen

My system would keep track of pools not nodes. There are about 8000 nodes, but only 20 pools have the vast majority of hashing power.

A cryptographic reputation ID is not the same as knowing who the miner is.

Miners would still be as anonymous as ever in this system.

This wouldn't do anything. The normal network would just continue.

Even if I run a thousand nodes today saying have 1 million the network would ignore me and this is no different.


Ok I'm a little annoyed that no one understands this/have found any flaws in it, yet they are confident to vote it wouldn't work. I think I came to the wrong place with this.