Topic: Very very simple yet powerful 51% solution - page 2. (Read 3859 times)

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.

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

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)

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.

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

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.

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.

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.

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.

See above.

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

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

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.

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.

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

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.


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.

Wow, interesting

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

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

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.

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

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.

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

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.

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

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.

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.

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.

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)