Very very simple yet powerful 51% solution

[Realpra]

Hi.

I am the "technical speaker" for the Danish Bitcoin Foundation. I am also currently programming my own project directly interfacing with the Bitcoin protocol.

This is my proposed solution to 51% attacks, centralization issues, selfish mining and any such. This simple solution takes care of them all.
Someone could do this very quickly and I am willing to personally pledge 2000$ towards it.

The reason I don't do it is that I'm already swamped with two "public good" Bitcoin projects, a full time job and a family.

Layman's terms
1. Establish a way mining pools can document they made a block - pool IDs.
2. Let individual full nodes add or remove pool IDs to/from a "trust list".
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.
4. A full node will not accept blocks if 99% of past 100 blocks were from unknown/untrusted pool IDs.
(exact percentages do not matter that much)

What it will do
Basically as the network is now it wouldn't do anything. Everything would be fine.

Once ~10% of full nodes upgrade miners would have an incentive to ID their blocks - simply for faster block propagation.

IF the network however came under attack such as:
A Many targeted double spends by a corrupt pool.
B Selfish mining escalation.
C No transactions in blocks.

THEN the solution would elegantly force the attacker to include at least some few blocks that could not be rolled back by the attacker and that contained transactions.
If the attacker DID not allow for other's blocks the attackers blocks would simply be ignored.

Once a "trusted" block was found the attacker can work on that and again make 99 blocks, so this is NOT a white/black list solution.

Ok so there's a catch right? It's a hard fork? Slow? Bullshit extra chains? Exotic crypto? Tatiana coin infusion? (no offense Tatiana)
No, none of the above.
There are literally ZERO drawbacks.

Technical detail
1. The protocol allows for a coinbase transaction script to have arbitrary data.
2. We can use this to let pools sign blocks with an "ID".
3. A pool would sign say the hashes of non coinbase transactions with their ID (w. SECP256k1).
4. Put the signature bytes in the coinbase transaction script.
5. This should be easy to put and read in blocks.
6. Only the pool has the PRIVATE_ID_KEY and the contents of the block are now signed.
7. The ID_PUBKEY can then be used as an ID.
8. No changes in protocol, zip, nada. Just an optional check for certain data.
9. Add the largest 20 pools to the trust list and no one ever has to talk about 51% again.
10. Its totally organic too, anyone can start a new pool and create an ID for themselves. Even botnets are still in, they just can't take over.

What it would really do:
Skeptic: I heard Bitcoin is under attack and will die?
You: Naw that can't happen because miners would then kill the coin and then... bla bla bla incentives... maybe ... bla bla bla and besides tree chains could fix it.... bla bla.
Skeptic: Huh?

--> To this -->

Skeptic: I heard Bitcoin is under attack and will die?
You: Nodes would reject that and kill it because all blocks would come from like the same dude.
Skeptic: Ah ok... is it still a ponzi though?

[1714899793]

1714899793

[1714899793]

1714899793

[ncsupanda]

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?

[Realpra]

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

Nothing.
Same way I can create a node where I have all 21 million coins.

It's a question of consensus, if the majority of Bitcoiners want a decentrallized Bitcoin during an attack that BECOMES the real Bitcoin.

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?

Pools are not blocked. Its just their blocks that will not be accepted if they make all the blocks.

Its not a blacklist.

The reason it is okay to have "untrusted" blocks in the chain is that you don't care as long as you don't have frequent rollbacks and your transaction goes through.

This is why this solution ONLY cares if ALL the blocks are from an untrusted source.

[gmaxwell]

If you're going to remove the non-membership of mining and require certified (and ... presumably licensed by states, since the process will make it easy to pin them down) you might as well eliminate the mining, use signatures, and call it SWIFT.

There are perfectly legitimate uses for signature based systems— they have useful security/performance tradeoffs— but they're very much at odds with Bitcoin's security model. In Bitcoin mining is anonymous (in the sense that it has no membership) as part of the process of making it decenteralized and somewhat censorship resistant.

Anything that lets you tell if blocks are from the "same dude" creates hooks to force miners to only mine particular transactions.

(WRT "protocol changes", the coins produced by the coinbase transaction cannot be spent for 100 blocks)

[Realpra]

If you're going to remove the non-membership of mining and require certified (and ... presumably licensed by states, since the process will make it easy to pin them down) you might as well eliminate the mining, use signatures, and call it SWIFT.

There are perfectly legitimate uses for signature based systems— they have useful security/performance tradeoffs— but they're very much at odds with Bitcoin's security model. In Bitcoin mining is anonymous (in the sense that it has no membership) as part of the process of making it decenteralized and somewhat censorship resistant.

Anything that lets you tell if blocks are from the "same dude" creates hooks to force miners to only mine particular transactions.

You are 100% incorrect you need to go up and read my post again.

I propose nothing close to what you are describing.
Anyone can mine even with no ID in my system - that includes sole mining. You have quite simply misunderstood like all of it.

(WRT "protocol changes", the coins produced by the coinbase transaction cannot be spent for 100 blocks)

I'm confused, I'm pretty sure coinbase coins are the same as other coins and I propose no change to that.. plz read before posting/voting.

[cr1776]

(WRT "protocol changes", the coins produced by the coinbase transaction cannot be spent for 100 blocks)

I'm confused, I'm pretty sure coinbase coins are the same as other coins and I propose no change to that.. plz read before posting/voting.

Coinbase coins are not the same as gmaxwell stated.
You said "3. A pool would send some BTC from the coinbase to TRUST_ADDRESS.
4. In the SAME block the pool sends from TRUST_ADDRESS to where-ever."

They can't be "spent" for 100 blocks as was stated to do so would require a protocol change.

[kolinko]

You are 100% incorrect you need to go up and read my post again.

Actually, he's correct. It's you who should reread what you wrote. Seriously.

[gmaxwell]

You are 100% incorrect you need to go up and read my post again.

I read it multiple times as I did not find it clear at all.  Communications is hard. You could help me out by picking apart why some of the things I cited do not apply and that might help my understanding.

Anyone can mine even with no ID in my system - that includes sole mining. You have quite simply misunderstood like all of it.

If anyone can mine with no ID and no disadvantage what prevents every miner (including the attacker) from using a unique ID in every single block, and thus being indistinguishable?  

Alternatively, if you pin blocks based on the decisions of some of these "optional" IDs to the detriment of IDless miners, what prevents the ID-ed miners from pinning a particular otherwise-non-consensus blockchain (e.g. to enforce some economic policy in excess of the system's rules).

I'm pretty sure coinbase coins are the same as other coins and I propose no change to that.. plz read before posting/voting.

Coinbase outputs cannot be spent until they mature 100 blocks later. This addresses some incentive concerns related to miner honest and prevents a fungibility difference from the fact that recently generated coins are at greater risk of irreversible loss since they cannot be restored if they fall out of the chain in a reorg.

This is a fairly basic part of the Bitcoin system.

[kolinko]

(To elaborate on why gmaxwell is right)
Your solution requires "pool trust lists", or "pool ids". If I want to become a new independent miner, or a new pool, I need to get on that list. Obviously, those lists need to be exactly the same for all the bitcoin users - if a bitcoin node has a different list, then it will be running a hard fork of bitcoin, because anything after a first block mined by a pool that the node trusts, and the other nodes don't, will be a different blockchain.

Ergo, your solution requires that there be a single list of trusted pools, and that list is what people define as "Bitcoin". And if you have a closed list of pools, you can as well retire the whole proof of work, and just say that everyone on the list gets one vote on accepting/rejecting the next block.

It's not a stupid solution really - aside from SWIFT, also Ripple uses it if I'm not mistaken.

[gmaxwell]

It's not a stupid solution really - aside from SWIFT, also Ripple uses it if I'm not mistaken.

Right— well ripple has seemed to leave the membership process undefined (as this proposal seems to have done as well) which is probably a huge liability. ... but the whole notion of a federation of semi-trusted parties isn't a bad one— it's one I've recycled many times myself as an example of a way to do high throughput low value transactions with scale no truly decentralized system can provide. ... But I don't think that kind of the system can really be the underlying basis of a complete worldwide currency because it is still fundamentally based on trust. If it could: we would have had it already long ago— multiple-signer federation isn't a new idea relative to digital-cash.

[kolinko]

But I don't think that kind of the system can really be the underlying basis of a complete worldwide currency

A loose thought - what if such a system were a "sidechain" to Bitcoin?

Let's say that we run N of M oracles that hold keys to a multisig address. And oracles are running an alternate transaction system (modelled on SWIFT or Ripple, or whatever). That system would be using bitcoin as a currency (so bitcoin would still be basis for the value), but would not be blockchain based.

So now - people would trust in Bitcoin because blockchain guarantees impartiality, and security, but would use that other system for performing most transactions.

Kinda like Coinbase really, but hosted on distributed oracles You could imagine a day when there are a couple such competing transaction systems, and bitcoin is sent between them only when really necessary. Just like with dollar, and many banking systems holding it.

The question would be - if such a situation were to occur, and block reward was close to zero, how would the network survive? In other words - what if a majority of transactions in future happen outside of blockchain?

Another question - if by chance, one of such transaction systems, had a majority of volume, wouldn't bitcoin become a sidechain to that system really? (e.g. 99% merchants use x-bitcoin for transactions, and most people keep their bitcoin within x-coin. What happens if x-bitcoin decides to mint new bitcoins?)

[gmaxwell]

Let's say that we run N of M oracles that hold keys to a multisig address. And oracles are running an alternate transaction system (modelled on SWIFT or Ripple, or whatever). That system would be using bitcoin as a currency (so bitcoin would still be basis for the value), but would not be blockchain based.

Sure, this is what I'd hoped ripple would become— back before opencoin bought it and turned in into yet-another-alt-coin. (and I had to go and revise a bunch of my posts to remove recommendations to look at the ripple system when it changed entirely).  (And one of the reasons I've been concerned about proposals to raise the block size limits— a world where much of the txn volume moved to fast txn processing systems might look a lot different from ours now and may need lower limits— or very different ones— to retain security in the long term).

[kolinko]

Sure, this is what I'd hoped ripple would become— back before opencoin bought it and turned in into yet-another-alt-coin. (and I had to go and revise a bunch of my posts to remove recommendations to look at the ripple system when it changed entirely).

Wow, interesting

[Realpra]

Coinbase coins are not the same as gmaxwell stated.
You said "3. A pool would send some BTC from the coinbase to TRUST_ADDRESS.
4. In the SAME block the pool sends from TRUST_ADDRESS to where-ever."

They can't be "spent" for 100 blocks as was stated to do so would require a protocol change.

Very well this is not critical. There are a multitude of ways to put data such as a signature in the blocks:
1. Coinbase transactions allow arbitrary data in their script.
2. OP_RETURN (experimental though)

I have edited my post to use coinbase data instead.

Actually, he's correct. It's you who should reread what you wrote. Seriously.

See above.

I apologize for my tone, I thought he had skimmed my post.

If you're going to remove the non-membership of mining and require certified (and ... presumably licensed by states, since the process will make it easy to pin them down) ...

1. I will not.
2. No state license, JUST a cryptographic signature that "TRUST_ADDRESS"-owner created this block - who-ever he is.

... but they're very much at odds with Bitcoin's security model. In Bitcoin mining is anonymous (in the sense that it has no membership)

1. Yes anonymity is important. That is why no membership is required and its just a signature the pool makes.
2. You can STILL mine with my solution as untrusted. My idea would ONLY really do something if all the blocks came from a single trusted party or from various unknown/untrusted sources.
3. It is not a proof of trust, but just proof a certain perhaps anonymous source made the block and you only care in extreme cases.

Anything that lets you tell if blocks are from the "same dude" creates hooks to force miners to only mine particular transactions.

1. Since it is only a cryptographic signature you don't know WHO it is. It could be a botnet that no one knows anything about but they just happen to make fairly normal blocks
so they get added to the trust list.
2. Miners can still mine whatever they like, this makes no change to that at all. You can still make 100% empty blocks. Only if it becomes an issue people will remove you from the trust list.

(WRT "protocol changes", the coins produced by the coinbase transaction cannot be spent for 100 blocks)

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

If anyone can mine with no ID and no disadvantage what prevents every miner (including the attacker) from using a unique ID in every single block, and thus being indistinguishable?

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.

Alternatively, if you pin blocks based on the decisions of some of these "optional" IDs to the detriment of IDless miners, what prevents the ID-ed miners from pinning a particular otherwise-non-consensus blockchain

1. You still have to follow protocol, it would be impossible to change rules.
2. There is ONLY detriment to ID less miners if they combined make 40% + of all blocks otherwise all are equal.
3. Again users choose which IDs their client should trust so who is ID-ed/trusted miners can change instantly during an attack.

[heartbit]

Anyone can mine even with no ID in my system - that includes sole mining.

So... if a miner had 51% of the network, couldn't a "bad" mining pool simply set the ID on half of their miners to be "no ID" - so then it would look like they only controlled 25% of the network... when in fact, they would control over 50%.

Which would be effectively the same as the current situation where GHash publicly controls 40% of hashrate - and I've read claims (not saying true or false, just that some people claim) they also control another 10-15% of "unknown" miners.

Sorry if I've misunderstood.

[Realpra]

Anyone can mine even with no ID in my system - that includes sole mining.

So... if a miner had 51% of the network, couldn't a "bad" mining pool simply set the ID on half of their miners to be "no ID" - so then it would look like they only controlled 25% of the network... when in fact, they would control over 50%.

Which would be effectively the same as the current situation where GHash publicly controls 40% of hashrate - and I've read claims (not saying true or false, just that some people claim) they also control another 10-15% of "unknown" miners.

Sorry if I've misunderstood.

No, because if they are removed from the trust lists then their blocks and all other untrusted / no ID blocks would be counted as one partition w. +50% and these new clients would start to not relay their blocks.

You can still do some double spend attacks in my solution, but there is an upper limit introduced and total control becomes impossible.

[kolinko]

What happens if some clients have a trust-list different than some other clients? There will be two separate and incompatible blockchains then, right?

E.g. some nodes/clients include a pool A, but not B. Some nodes/clients include B, but not A. But everyone includes C, and nobody includes D.

After a short while there's a situation like this:

ABCD (so, first block mined by A, second by B, third by C..)

Then "A" mines a block. Part of the network accepts it, part of the network doesn't trust A, and rejects it, because it was right after D which is also untrusted. So now we have:

ABCDA - some clients consider this the longest block
ABCD - some clients consider this the longest block

But then "B" delivers a new block to "ABCD" (because "B" doesn't trust "A" either, so it doesn't consider "ABCDA" the longest blockchain), so it's now:

ABCDA - some clients believe this is the only valid blockchain
ABCDB - some clients believe this is the only valid blockchain

aaaand we have a hard fork. Some clients use one blockchain, some clients use another blockchain.

In other words still - clients having different trust lists would lead to a hard fork of blockchain.

[Realpra]

What happens if some clients have a trust-list different than some other clients? There will be two separate and incompatible blockchains then, right?

Yes and no.

This concern is why my solution would have two different "punish modes":
1. At ~40% of blocks untrusted the client will just not relay another untrusted block for 1 hour.
So longest chain is in this case still accepted even if it is 90% untrusted. However propagation would be slower for the untrusted pools in this case.
2. Outright rejection that you mention. It would ONLY happen if something like ~99% of the last ~100 blocks are untrusted.

So the hardfork situation you describe could happen, but ONLY if the majority of nodes A Do not have ANY trust overlap and B 99% of blocks are untrusted by both partition 1 and 2 clients using your own example.

Mode 1 makes centralization harder and mode 2 prevents a total denial of service by a single player preventing all transactions.

[jl2012]

Anyone can mine even with no ID in my system - that includes sole mining.

So... if a miner had 51% of the network, couldn't a "bad" mining pool simply set the ID on half of their miners to be "no ID" - so then it would look like they only controlled 25% of the network... when in fact, they would control over 50%.

Which would be effectively the same as the current situation where GHash publicly controls 40% of hashrate - and I've read claims (not saying true or false, just that some people claim) they also control another 10-15% of "unknown" miners.

Sorry if I've misunderstood.

No, because if they are removed from the trust lists then their blocks and all other untrusted / no ID blocks would be counted as one partition w. +50% and these new clients would start to not relay their blocks.

You can still do some double spend attacks in my solution, but there is an upper limit introduced and total control becomes impossible.

You didn't answer the question. A miner holding 60% of hashing power could pretend to be 10 independent miners with 6% power each.

[Realpra]

You didn't answer the question. A miner holding 60% of hashing power could pretend to be 10 independent miners with 6% power each.

Yes he could.

However the assumption is that if he either
A. Started to do doublespends via chain rollbacks.
B. Started to only allow his own blocks.
It would become obvious that these 10 fake pools were in fact colluding and people would remove them from their trust lists and start to delay them/reject them.
(The clients today already have automatic alarms for 2+ blockchain forks I believe)

In other words one single honest entity could control 100% of the mining power in my system and no one would necessarily know about it.
However as long as no attacks are taking place we don't care.