Very very simple yet powerful 51% solution

[Nicolas Dorier]

1. The ones adding the IDs to trust lists would be users and client developers. Random new IDs would not be in the lists. Yet there is no central authority.
2.  However if 50-60% of the network is mining with known and trusted IDs then it doesnt matter if a new pool or "attacker" makes blocks with unknown IDs/no IDs they will still be accepted.

So, in your system each individual decides what ID is trusted, which is good.
But the question is : with millions of potential different node at a single point of time, how do you keep track of your "trusted" nodes.

To fix the problem, such individual will be tempted to use a list provided by someone else, who will decide who is trusted on its behalf.
When sufficient people give right to "act on its behalf" we will tend to a centralized repo of trusted ID.  If he does not use a centralized repo of trusted ID, then he will be able to keep track of only a small number of them.
Also making a new node would be impossible, because you would need to convince everybody to put you in the trust list. (especially when, as you said in your example, there is only 20 of them)
This is a major barrier of entrance that keep competition out, and thus protect current mining pools. Your solution, in my mind, protect mining pools instead of increasing decentralization.

I would opt for another idea, the untrusted list. If a pool get 51% you put it in untrusted to shrink its profit and thus processing power.
However, such solution can be so easily worked around by a mining pool by hidding everything that can identify itself, that it is not worth implementing. (But could do easily if you really want)

[laurentmt]

1. Establish a way mining pools can document they made a block - pool IDs.

This tweet by @adam3us (Adam Back) may interest you.

@coindesk @jgarzik @BitPay miners anonymity needed to protect payment neutrality policy, this gives irrevocability hence low tx cost we want

[Carlton Banks]

Sounds pretty much like a way of giving nodes the ability to do a DOS attack against miners arbitrarily.

And it's much worse than the hashing share 51% attack, as the resources you need to do it and succeed are: as many copies of bitcoin core running as possible, attaching untrusted status against miner IDs that are behaving in the interests of the network. It makes an attack against the network much much cheaper, especially if your flooding attack distrusts every single miner, then there's no blocks.

[Realpra]

So, in your system each individual decides what ID is trusted, which is good.
But the question is : with millions of potential different node at a single point of time, how do you keep track of your "trusted" nodes.

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.

This tweet (https://twitter.com/adam3us/status/484295259439243264) by @adam3us (Adam Back) may interest you.

BitPay miners anonymity needed to protect payment neutrality policy, this gives irrevocability hence low tx cost we want

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.

And it's much worse than the hashing share 51% attack, as the resources you need to do it and succeed are: as many copies of bitcoin core running as possible, attaching untrusted status against miner IDs that are

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.

[temen]

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

[taylortyler]

2. Let individual full nodes add or remove pool IDs to/from a "trust list".

What's to prevent an attacker from running a full node that has them added to their "trust list"?

This could mean the entire network could prevent a pool from getting blocks just because they don't like them, unless we assume these protocols only come into place if the block finder has 51% of the network hashrate?

You in Raleigh?

[laurentmt]

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

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 !

[gmaxwell]

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

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.

[laurentmt]

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.

[Realpra]

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.

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.

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.

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)

[gmaxwell]

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:

Ok so we put a signature of the block or block height into the coinbase script or somewhere else.

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.

[azeteki]

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.

[azeteki]

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.

[laurentmt]

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)

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.

[azeteki]

Question: which proportion of your client is required in the network before we start observing its influence ?

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.

3. A full node will not relay untrusted/unknown blocks  for ~1 hour IF 40% of the past 100 blocks were from unknown/untrusted pool IDs/ +50% from one single trusted ID.

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

4. A full node will not accept blocks if 99% of past 100 blocks were from unknown/untrusted pool IDs.

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

[laurentmt]

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

[DeathAndTaxes]

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

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.

[laurentmt]

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

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.

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

[Realpra]

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

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.

Ignoring the wrongheadedness of the overall design for a moment, the actual proposed implementation is still broken:

Ok so we put a signature of the block or block height into the coinbase script or somewhere else.

You cannot include a signature of the block into the coinbase because the block

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.

Miners don't really care about the propagation of blocks to all nodes (users).  What matters is the propagation of blocks to other miners.

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.

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.

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.

[azeteki]

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.

What are YOUR solutions to the 51% attack?

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?