Topic: bitcoin "unlimited" seeks review - page 4. (Read 16106 times)

A very simple attack can be done on the network.

There are really 3 parameters that can be set at each node:

1) Maximum generation size (only used by miners)

2) Maximum relay size (used to propagate to peers)

3) Maximum acceptance size and # of blocks ahead to force an automatic change of parameters (This mechanism is one I am less sure of how it works).


I'll ignore the first parameter since it's set by miners.  Suppose I want big blocks in my unlimited node.  I set a max relay size of 32MB and max acceptance size of 32MB (the maximum allowed?).  I will accept anything I see that is the longest chain and pass everything along.

Now suppose I connect to a bunch of nodes, and they have much lower limits - the max relay they have is 2MB, and max acceptance is 2MB.  I will never see any blocks bigger than 2MB!  Even if the majority of nodes were accepting large blocks, and I just got connected to a few small block nodes, I'm screwed.  I'm out of sync with everyone else, and there's nothing I can do to sync up.

The attack is simple - launch a bunch of nodes, try to connect to as many nodes as possible, and stop relaying anything big.

In a large enough network, this doesn't even need to be accidental.  Some poor sap gets unlucky and connects to all small block users, and can't ever get an update.  The end result is many chains and chaos.

Of course this is solved in an interesting mechanism - a bunch of people get together and talk and coordinate limits and upgrade together... hmmm.... sounds familiar.

This ...1000x

Case in point - https://www.darkwallet.is/

Even with many warnings such as ---



People were still using real coins and losing them all the time on experimental software. Are any of the core devs open to us having a fundraiser to finish cleaning up the code and testing the dark wallet implementation or is this a matter of all the focus on bitcoin core at the moment?

 if so, aren't fraud proofs for SW an illusion?

The idea of enabling nodes & miners to set a market block-size is quite reasonable so there is no criticism of the idea.  Dont take review of the mechanism as a critique of the idea: for ideas to be deployed we need game-theory reviewed protocols and rigorously tested implementations.  Dynamic block-size is actually on the core roadmap and the best proposal I've seen for it is flexcap by GMaxwell & Maaku, with some ideas from Jeff.  You can watch a video about flexcap presented at scaling bitcoin HK.  Maaku has code for the core parts of it, I believe he was going to publish it, probably online by now.


The precursor idea was BIP "100" which Jeff retracted.  The BIP "100" proposal is similar but only miners vote.  In flexcap both users and miners vote.

I would suggest people interested in the idea of dynamic blocks, learn about BIP "100" and flex-cap and see if they can improve them.  There are design considerations that have been refined between 100 and the improvement on it flex-cap.

The bitcoin unlimited project has presented some ideas which do try to automate things.  Unfortunately all of the ones so far seem to be defective suffering sybil attack, constant centralisation pressure, dont take account of SPV mining, shared pools, relay network existing practice nor selfish-mining, attacks.

I have not really analysed the idea of validating two chains, but it seems likely to have problems based on intuition, particularly in the area of race-conditions, chain sharding and divergence risk, and in an adversarial environment.

Bear in mind that the consensus mechanism is extremely fragile, it only just works in that there are many design close things that completely fail.  Most variants I tried I self-broke fairly immediately.  But some of these things take a long time to realise, or require review from GMaxwell or others to disprove.  For example selfish mining was not noticed for years.  I did spend about 3 - 4 months cooking up analysing mining variants to improve bitcoin mining centralisation (eg I invented ghost, but rejected it as over complex for what it achieved, before the academic paper proposed it and a bunch of other variants), before getting into side-chains.

The idea for users to vote by delaying block relay wont work because most miners are already using the relay network or SPV mining.  Over 50% of the network was SPV mining during the 4th july fork.  A large portion of miners use the relay network.

Users voting by advertisement wont work because of sybil as others have explained.

You can read flex-cap to see how they combine miner and user voting in a secure, game-theory stable way that defends against all these attacks.

In summary:

1. The use case: dynamic market set block-sizes are interesting.

2. bitcoin unlimited proposals so far seems broken as discussed by multiple people for a whole range of reasons.  We didnt have a crisp definition and it seems that some things maybe undecided.  That's ok - just keep working on it and make a concrete proposal later and people can analyse it from that.

3. BIP "100" seemed plausible, but was only miner meta-incentive secure. Meaning we would be trusting miners to do the right thing, limited only by their commitment to not do anything too selfish for fear of hurting bitcoin's long term value.

4. flex-cap adds user voting (in transactions) and an economic quadratic feed-back mechanism to create an incentive to right-size blocks (to deter miner zero sum attacks against other miners and curtail the continuous centralisation pressure). Flex-cap also ensures miner fee profit in conditions where otherwise mining fees can be driven to zero by excess capacity in a non-dynamic block-size growth proposals like BIP-103.

[EDIT: I suppose the other thing is it might be better to run experiments on testnet rather than bitcoin or putting clear warnings for users if you have not.  People could lose bitcoin running partial implementations of incomplete ideas.  Encouraging users arent understanding it is a research project to run experimental code with real Bitcoin under it's control or even on the same machine, would be inadvisable.]

Adam

I just wanted to point out that the one comment I left in this thread has now been deleted. The idea that this place is "neutral" is silly.

All the good people are leaving.

This is an important point - and the one I've thought it safe to ignore here, but if you have people picking a larger sized block, without BU building in safeguards, it will be dangerous to the network if people are not aware of the consequences.  Even 2 MB blocks can have transactions that can take 5-10 minutes to verify.  

There is no mechanism to reach consensus about the blocksize limit, with BU all nodes just set there own limits.  This does not reduce the potential for debate, arguments or central planning.  The community would still need to reach consensus about the blocksize limit in the same way it is trying to now.  The core development team could still try to keep the 1MB limit and miners would still need to make a decision to change to accept larger blocks, the only difference would be the debate may be about values to set in the client, rather than which client to use, which is effectively no significant change from the current status quo.  If we want nodes to dynamically set a blocksize limit, in a way determined by the market, we should use a proposal like BIP100.  BIP100 actually allows miners to dynamically set a blocksize limit and agree with each other on a new limit, BU has no system to enable nodes to agree on the limit.

BU does not always follow the longest chain.  In general BU operates in the same way as in Core,  BU nodes follow the longest valid chain.  There is a slight difference with respect to the blocksize issue.  It is possible BU nodes will follow the longest chain, where the blocksizes are arbitrarily large, but only under certain limited unusual conditions.  There is an “N depth” idea in BU, where nodes switch from regarding one chain as valid to another chain, if the chain with larger blocks has a lead of N blocks.  The default value of N is 4 and N could be manually set to any number, including infinity, when BU nodes will never switch to the longest chain.  Only if N is manually changed to 1, does BU follow the longest chain with respect to any blocksize.  Therefore the claim that BU always follows the longest chain is false.

I just wanted to come back on the superlinear problem that iCEBREAKER mentioned here, because it deserves response since it's just as much a problem for other BIPs and SW.

So this is not a new problem introduced by BU, and there have been some proposals made in the context of BU to mitigate this (by moving verification into separate threads etc.)

Most of the discussion around this in BU has happened in the thread below as far as I have seen:

https://bitco.in/forum/threads/i-really-want-to-like-bitcoin-unlimited.684/page-2#post-8087

Aquent has posted his reply to Adam's thread-opening post:

https://bitco.in/forum/threads/re-bitcoin-unlimited-seeks-review.718/

His closing statement is worth re-iterating in this forum:

Here are two posts from the BU lead developer.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-226#post-8419
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-226#post-8444

Very nice to see what kind of 'Bitcoiners' with what kind of language on what kind of 'communication' channels are trying to back Mr. Back.
Very nice to see that such Monero-Trolls indeed believe they help to keep Bitcoin on core's track to cripple Bitcoin.

As long as you can't understand a swarm and autopoiesis, you will never understand. You will always believe in authority.

So it sounds like you are using non-relaying by end user nodes as a form of soft pressure to discourage miners from creating blocks larger than node limits.

How do you deal with the fact that miners will often want to have direct connections with other miners (due to the natural incentive to reduce "orphans"), making relay through end user nodes irrelevant?

Setting aside the previous, have you done simulations or mathematical models to characterize how relaying will behave in practice given some distribution of nodes putting a block "on probation" while other nodes process and relay it?

Can you characterize the cost of creating nodes that deliberately relay larger blocks than most of the end user nodes in an attempt to influence the orphan pressure on miners?

Without doing any simulations or models, it intuitively seems to me that even a small number of such permissive nodes (either malicious or otherwise) can quickly relay blocks to nearly the entire portion of the network willing to process them, though operators of such nodes will incur bandwidth costs.


Only if the block does not reach other miners.

I mean... for how long are you going to dodge the very simple fact that BU is NOT a market driven solution but one that leaves EVERYTHING up to the miners?

It's painfully obvious to anyone paying attention yet you (and others to which I've raised the point) continue to swerve around the issue.

How Bitcoin Unlimited works

Please review these examples of emergence first:
http://www.pbs.org/wgbh/nova/sciencenow/3410/03-ever-nf.html

Assume a BU majority network.
Consensus occurs on the max block size over the whole Bitcoin network from low-level rules used by thousands of individual nodes. There is no voting.

With Core and XT everyone needs the same maximum for block size. BU is different in that only the whole network possesses the attribute of a dynamic block limit, while each individual node has an approximation, or even a limit which is a lot smaller or larger. It doesn't matter, except that nodes with a too-small limit will frequently have the latest blocks "on probation" waiting for them to reach an acceptance depth. A node which sees a block which is excessive (over its limit) will not relay or process it until it is buried under enough confirmations. BU nodes always track the chain tip with the most PoW.

A miner producing a block larger than emergent network consensus gets its block orphaned. As individual node owners update their settings after upgrading or getting new hardware, bandwidth etc, then the network consensus slowly changes, usually upwards although the exact value at any one time is an irrational number and unknowable.

Individual node settings:

• Excessive block limit (default 16MB)
• Acceptance depth, i.e. confirmations (default 4)

Just wonder, if every week there are 100 new solutions, who has the time to review? Shouldn't the new solution based on current major user feedback instead of wishful thinking? Need a spam filter for new solutions  

Note to all since I've been answering a lot of questions: I'm not a spokesman for BU. I'm just someone with a keen interest in the project, and more than that, the overall concept and approach. My views are mine alone. For more details on what others involved in the project think, you'll probably have to go to other forums because many who are close to the project feel - with some justification but wrongly in this case I think - that they will be censored here.

I notice Adam posted on the other subreddit, so if you're not averse to asking questions there you may get some answers that I myself cannot provide. Really the developers should be answering a lot of the specific questions (on reddit: /u/thezerg1 /u/awemany and sickpig (not sure of sickpig's reddit name)). My responses here are mostly about the general idea of user-adjustable blocksize settings, which I see as the major idea of the project - note that many others probably do not agree.

The statements are not equivalent; the former (obviously) does not consider the exigency analyzed in the latter.

Sorry to have confused you, I should have been more clear for the sake of easily disoriented Trump-voters.  

I think the blocksize is the biggest controversial economic aspect they have touched (kind of easy to change something when it's not controversial), but - see my edit - I don't think it would be good to vest power even in someone who did have a good track record on that.

I do think we will be fine whatever happens with blocksize, and are fine now, but that adoption could be set back quite a ways if too much friction is introduced and circuitous paths are taken, so I think it's worth pointing out some existing burdens on weighing on the market discovery process.