BU's "honest miner" security model

[HostFat]

I did and it's sitting with "Your comment is awaiting moderation.". I cannot "archive it" because it won't even be displayed in the first place without his permission.

Good to know, I'll trust you on this

I think this point is especially dishonest coming from a BU developer, given that their whole security model is based on a strong assumption that the aggregate behavior of miners is honest.

Oh well, this the basic on how the Bitcoin system works. I know and remember that the first time you saw Bitcoin you didn't agree on this, but still it didn't break in the past years, claiming the opposite is unproven.
This is again a good history case/proof of the opposite of what you are claiming: http://www.coindesk.com/bitcoin-miners-ditch-ghash-io-pool-51-attack

BU model is the Bitcoin model, no changes on its root.

Bitcoin.pdf

The incentive may help encourage nodes to stay honest. If a greedy attacker is able to
assemble more CPU power than all the honest nodes, he would have to choose between using it
to defraud people by stealing back his payments, or using it to generate new coins. He ought to
find it more profitable to play by the rules, such rules that favour him with more new coins than
everyone else combined, than to undermine the system and the validity of his own wealth.

With nodes here Satoshi was meaning miners, because they can mine with CPU power.

[gmaxwell]

BU model is the Bitcoin model, no changes on its root.

Repeating a lie won't make it true.

Even though you and BU insist on ignoring how _every version ever released_ works-- you don't even need to look to the operation of the system to disprove your belief that Bitcoin does whatever the majority of the hashpower wants-- The whitepaper itself specifically speaks to the potential for a dishonest hashrate majority:

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, [...]

The text you quote, "He ought to find it more profitable to play by the rules"-- is speaking to a world where network nodes validate and so miners ability to profitably break the rules is very limited. This incentive assumption is far weaker in the BU world where all users strongly trust miners.

Besides, you've dodged my point there:  You can that you want that miners should be strongly assumed to be honest and the system shouldn't be secure against them-- but don't turn around and complain about 'attacks' that only exist in a security model you've already rejected one where miners attacking is a problem.

[HostFat]

Repeating a lie won't make it true.

It doesn't make it true, by the pure meaning of the "true" word, but it can help to make everyone believe a lie for a longest time of being able to gain a profit.

Currently, no one is paying me to talk about BU or other Bitcoin implementation, no one paid me in the past, and I still nearly fully invested in the "Bitcoin token", on private keys that I fully own.
I haven't any full contract with any company and/or invested on them. So I feel myself in a better position than yours about denying this possibility of having an incentive of gaining profit by repeating lies.

Even though you and BU insist on ignoring how _every version ever released_ works-- you don't even need to look to the operation of the system to disprove your belief that Bitcoin does whatever the majority of the hashpower wants-- The whitepaper itself specifically speaks to the potential for a dishonest hashrate majority:

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, [...]

"simplified method"

The quote refers to the SPV clients, while instead we are talking about full nodes verification.

Full quote:

8. Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep
a copy of the block headers of the longest proof-of-work chain, which he can get by querying
network nodes until he's convinced he has the longest chain, and obtain the Merkle branch
linking the transaction to the block it's timestamped in. He can't check the transaction for
himself, but by linking it to a place in the chain, he can see that a network node has accepted it,
and blocks added after it further confirm the network has accepted it.

IMAGE

As such, the verification is reliable as long as honest nodes control the network, but is more
vulnerable if the network is overpowered by an attacker. While network nodes can verify
transactions for themselves, the simplified method can be fooled by an attacker's fabricated
transactions for as long as the attacker can continue to overpower the network. One strategy to
protect against this would be to accept alerts from network nodes when they detect an invalid
block, prompting the user's software to download the full block and alerted transactions to
confirm the inconsistency. Businesses that receive frequent payments will probably still want to
run their own nodes for more independent security and quicker verification.

(emphasis is mine)

The text you quote, "He ought to find it more profitable to play by the rules"-- is speaking to a world where network nodes validate and so miners ability to profitably break the rules is very limited. This incentive assumption is far weaker in the BU world where all users strongly trust miners.

I think that you are trying to mix the full node situation with the SPV situation.

It is suggested by always to wait more confirmations on an SPV clients.

This is now, and it will be the same on a possible BU world. Again, nothing will change.

There is also a big difference on "trusting the miners" and "trusting the legit miners". BU nodes trust the legit miners.
Where is the difference? Legit BU miners aren't going to blindly accept blocks bigger then their EB settings.
Because this damaging the users and belief in the Bitcoin system will damage their income.

So, the possible attacker (from the quote of the bitcoin.pdf you have reported) will just mine huge blocks that will go nowhere.

BU nodes instead (with the current default setting, that the user can freely change) aren't going to accept bigger block without 12 consecutive blocks after it. (AD setting)

So, at the end, to be more precise, in the "current BU world" (with default settings) there is the basic idea that there can't be an attacker that is going to be able to do and pay for an attack of 13 consecutive blocks (the first one bigger + 12 small blocks)

If someone thinks that a 13 block attack is still possible ... there is also this coming:
Parallel Validation: https://github.com/BitcoinUnlimited/BUIP/blob/master/033.mediawiki (being developed here)
The first block downloaded and validated wins.
So, the smaller and easier to be fully validated the better.


I think that if segwit hadn't the fake block size increase (but everything else), now it could be already activated by the larger majority of the miners.

[gmaxwell]

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, [...]

"simplified method"

The quote refers to the SPV clients, while instead we are talking about full nodes verification.

The text is also talking about full nodes. I've re-bolded to help you out.   As it nodes, an attacker might overpower the network with invalid blocks (this is not possible in the BU security model, because having more hashpower is the definition of "valid" there, and it states that this is prevented by network nodes because they validate, but in BU the network nodes trust miners instead of enforcing on their own.

There is also a big difference on "trusting the miners" and "trusting the legit miners". BU nodes trust the legit miners.
Where is the difference? Legit BU miners aren't going to blindly accept blocks bigger then their EB settings.
Because this damaging the users and belief in the Bitcoin system will damage their income.

So, the possible attacker (from the quote of the bitcoin.pdf you have reported) will just mine huge blocks that will go nowhere.

BU nodes instead (with the current default setting, that the user can freely change) aren't going to accept bigger block without 12 consecutive blocks after it. (AD setting)

If the attacker is overpowering the network, as noted, they can produce any number of blocks ahead on their chain. Not just 12.

If someone thinks that a 13 block attack is still possible ... there is also this coming:
Parallel Validation: https://github.com/BitcoinUnlimited/BUIP/blob/master/033.mediawiki (being developed here)
The first block downloaded and validated wins.

No: more work wins, all that change does is potentially influence the behavior on ties of equal work (and potentially enable new selfish mining strategies, while slowing down validation and making it more memory hungry). Meaning an overpowering attacker can do whatever they want. This is the BU model and it is unlike the model described in the Bitcoin whitepaper or implemented in any version of the software ever released.

[HostFat]

If the attacker is overpowering the network, as noted, they can produce any number of blocks ahead on their chain. Not just 12.

In the real world, an attack isn't a simple logic it can be done / not. There are costs.
Even now "it is possible" a 51% attack from an "attacker overpowering the network", and the only solution is a pow fork, as in the imaginary-but-not-economic-possible case in the BU world.

If the attacker is overpowering the network, as noted, they can produce any number of blocks ahead on their chain. Not just 12.

Again, it isn't free.
Anyway, the settings of the BU node can be changed easily with few clicks.
So they are the results of the perceived needed security of every user/service/business.
Maybe many users will leave 12, but maybe businesses/exchanges will set it to 50, 100 or more. (and so then will do the same the users)
Then the attacker will lose any incentive to it anyway.

The BU node can be also set to work as a Core node (ex: EB 1 AD 999999999).
The good thing is that the everyone will not need anymore any ""consensus"" from few devs to upgrade the network, it can move on it's own emergent consensus.

No: more work wins, all that change does is potentially influence the behavior on ties of equal work (and potentially enable new selfish mining strategies, while slowing down validation and making it more memory hungry). Meaning an overpowering attacker can do whatever they want. This is the BU model and it is unlike the model described in the Bitcoin whitepaper or implemented in any version of the software ever released.

More work on small and easy to validate blocks? Seems good to me.
You are too vague here.

[gmaxwell]

If the attacker is overpowering the network, as noted, they can produce any number of blocks ahead on their chain. Not just 12.

In the real world, an attack isn't a simple logic it can be done / not. There are costs.
Even now "it is possible" a 51% attack from an "attacker overpowering the network", and the only solution is a pow fork,

Are you not even reading the pieces of the whitepaper we're quoting here? An overpowering attacker making invalid blocks is simply ignored by network nodes. There is no reason to change the POW.

More work on small and easy to validate blocks? Seems good to me.
You are too vague here.

No, just more work. It doesn't matter how big or slow it is, BU will follow more work even with those changes, because it has abandoned the consensus model of Bitcoin and replaced it with strong trust in miners. Instead of having a process that guarantees consensus it is a free for all that hopes cartel activity will cause an undocumented consensus to "emerge".

[jonald_fyookball]

Are you not even reading the pieces of the whitepaper we're quoting here? An overpowering attacker making invalid blocks is simply ignored by network nodes. There is no reason to change the POW.

Circular reasoning based on your idea/definition/assumption of what is 'valid'. 

There is no maximum blocksize in the whitepaper and We BU proponents do not believe blocksize should be part of the consensus rules.
 

[gmaxwell]

There is no maximum blocksize in the whitepaper and We BU proponents do not believe blocksize should be part of the consensus rules.

Then they should admit that what they want is a system which is different from the one Bitcoin's creator released. There is also no mention of 21 million coins -- why not 42 million-- there is no mention of Bitcoin Script, nor of 1001 other parts of the system.

[jonald_fyookball]

Well, the 21M coins or the "1001 other things" is not the issue of discussion here.
 
This idea that the BU security model is substantially different
from Bitcoin seems specious.  In BU, nodes can validate blocks
just as they can in Bitcoin, and simply ignore blocksize as one
less constraint for validity.  I don't see how this requires
more of a 'strong trust in miners.'

[IadixDev]

Well, the 21M coins or the "1001 other things" is not the issue of discussion here.
 
This idea that the BU security model is substantially different
from Bitcoin seems specious.  In BU, nodes can validate blocks
just as they can in Bitcoin, and simply ignore blocksize as one
less constraint for validity.  I don't see how this requires
more of a 'strong trust in miners.'

I guess it because it increase the resources needed to operate à node, bigger blocks = more bandwith, more disk space, more processing, which will tend to raise the cost of having full nodes,  and many things can increase very fast with the growing number of bigger tx,and lead toward centralisation to miners who are paid for it.

[jonald_fyookball]

Well, the 21M coins or the "1001 other things" is not the issue of discussion here.
 
This idea that the BU security model is substantially different
from Bitcoin seems specious.  In BU, nodes can validate blocks
just as they can in Bitcoin, and simply ignore blocksize as one
less constraint for validity.  I don't see how this requires
more of a 'strong trust in miners.'

I guess it because it increase the resources needed to operate à node, bigger blocks = more bandwith, more disk space, more processing, which will tend to raise the cost of having full nodes,  and many things can increase very fast with the growing number of bigger tx,and lead toward centralisation to miners who are paid for it.

Increased resources to operate a node is one of the well known trade offs that come with bigger blocks in general; that doesn't mean BU operates under a different security model.

[gmaxwell]

In BU, nodes can validate blocks
just as they can in Bitcoin, and simply ignore blocksize as one
less constraint for validity.

Ignoring the block size would be one thing-- just an ill-advised hardfork which would erode the decentralization of the system-- but BU replaces the validation based consensus model in Bitcoin with "emergent consensus", which is radically different and not an improvement.

[manselr]

Well, the 21M coins or the "1001 other things" is not the issue of discussion here.
 
This idea that the BU security model is substantially different
from Bitcoin seems specious.  In BU, nodes can validate blocks
just as they can in Bitcoin, and simply ignore blocksize as one
less constraint for validity.  I don't see how this requires
more of a 'strong trust in miners.'

I guess it because it increase the resources needed to operate à node, bigger blocks = more bandwith, more disk space, more processing, which will tend to raise the cost of having full nodes,  and many things can increase very fast with the growing number of bigger tx,and lead toward centralisation to miners who are paid for it.

Increased resources to operate a node is one of the well known trade offs that come with bigger blocks in general; that doesn't mean BU operates under a different security model.

The direct result of increased resources in order to operate a full node is a tradeoff that we can't afford, since it attacks directly into the decentralization of the network. How in hell is that a good idea?

Im all for a 1MB increase along with segwit, but segwit should go first, then we can start adding more MB VERY conservatively and after studying what the impact would be.

[jonald_fyookball]

The direct result of increased resources in order to operate a full node is a tradeoff that we can't afford, since it attacks directly into the decentralization of the network. How in hell is that a good idea?

Centralization of nodes is less dangerous than centralization of transactional control which is what you get with small blocks.  In other words,
with small blocks, you force ordinary users off the main chain, and then only the institutions that can afford to compete for main chain transactions
become the gate keepers and controllers of what and how transactions flow through the network.  This is much more dangerous in my opinion.
 

In BU, nodes can validate blocks
just as they can in Bitcoin, and simply ignore blocksize as one
less constraint for validity.

Ignoring the block size would be one thing-- just an ill-advised hardfork which would erode the decentralization of the system-- but BU replaces the validation based consensus model in Bitcoin with "emergent consensus", which is radically different and not an improvement.

It is not as different as you would like to make it sound, since the essence
of security and consensus is still based on mining nodes voting on the best chain with
the most work.

Granted, it is true that removing the blocksize limit from the protocol layer is different
from the way things have been done for several years, so whether or not it is 'radical'
is a matter of perspective and opinion... as is whether or not it is an improvement.

[RocketSingh]

There is no maximum blocksize in the whitepaper and We BU proponents do not believe blocksize should be part of the consensus rules.

Then they should admit that what they want is a system which is different from the one Bitcoin's creator released. There is also no mention of 21 million coins -- why not 42 million-- there is no mention of Bitcoin Script, nor of 1001 other parts of the system.

^^This does not seem like a valid argument against BU. Because, Bitcoin Core is also increasing max block size in SegWit soft fork to 4mb. Hence, should we assume Bitcoin Core may attempt to raise the coin supply to 42 million as well?

Given the kind of argument we get from Bitcoin Core & BU proponents from time to time, sometimes I feel anxious about the future of bitcoin. Thankfully, majority of hashpower still does not support either SegWit or BU.

I would also request to consider leaving https://github.com/bitcoin/ as is with 1mb limit with no SegWit. Both Bitcoin Unlimited & Bitcoin Core team may make Bitcoin great again with https://github.com/BitcoinUnlimited/ & https://github.com/Bitcoin-Core/ respectively.

[HostFat]

@Nicolas Tesla
You as many other are currently missing one important thing.

What happen if the network lose a large number of nodes? The decentralisation feature of the network starts to missing.
What happen to the market if the decentralisation feature of the network starts to missing? The confidence in the Bitcoin gets lower, and so the price.
What happen to the miners if the price gets lower? They get less money.

So, even with an unlimited block size, maybe there can be problems from a possible attack from malicious entity, and so some dynamic barriers are needed, but there is no way that miners will start to make huge blocks, because this goes directly against their interest on money.

Again, not because they have a good heart, but even just because of their greed, as the Nakamoto's consensus works. (6. Incentive)

And they have millions invested that need to cover on all the next months/years.

Good past example of this economic behavior:
http://www.coindesk.com/bitcoin-miners-ditch-ghash-io-pool-51-attack/

No issue here.