Unlimited really should be Unlimited...

[TrevinHofmann]

@sgbett Non-mining nodes give their owners a complete view of the block chain without trusting other parties.

They provide a few benefits for the rest of the network. With more nodes online, it becomes more difficult for adversaries to attack the entire network with denial-of-service attacks. Non-mining nodes also help operators bring new nodes online by relaying the entire block chain to them upon request, similar to how seed seeds help leeches on the BitTorrent network. They also make Sybil attacks more difficult by decreasing the likelihood that all peers could be under the control of the attacker.

 

[Peter Tschipper]

@sgbett lets not forget SPV wallets that depend on nodes.

 

[sgbett]

Thanks for clarification. I suppose I was trying to understand if they did anything unique that mining-nodes did not do.

So I guess in that respect their key benefit is providing additional security and resilience, and reducing pressure on miners.

Guess I'll leave 'em switched on then

 

[solex]

Non-mining nodes give investor/saver/holders a degree of influence on miners by acting as intermediaries on their blocks as they propagate through the network (which is why the RN breaks basic principles of Bitcoin by centralizing the communication channel for miners). This is important for thin-blocks/IBLT which leverages mempool synchronization enforcing a higher degree of consensus on unconfirmed tx, which is desirable as the whole purpose of a blockchain is consensus on confirmed tx. Otherwise garbage-in garbage-out.

 

[TrevinHofmann]

Non-mining nodes give investor/saver/holders a degree of influence on miners by acting as intermediaries on their blocks as they propagate through the network (which is why the RN breaks basic principles of Bitcoin by centralizing the communication channel for miners).

I don't agree with this. If nodes block the traffic of blocks they don't like, it's expected that the nodes that do like those blocks and want to propagate or receive them will simply route around the uncooperative nodes. I don't see the relay network or submitting transactions directly to miners as antithetical to Bitcoin.

After a brief discussion with Matt Corallo, it seems that a variety of communication networks would be beneficial. Some may be geared towards miners to quickly relay blocks, some might be best suited for nodes supporting wallets, etc. The more decentralized these networks are, the better. Also, having a greater variety of these networks would help to decentralize Bitcoin in general.

 

[solex]

@TrevinHofmann There are separate areas which intersect here:

The scaling goal is sending transactions once through the network (ideal but not quite achievable). Just considering real-time tx dispersed through each 10-minute window, the network capacity is today more like 100 TPS than the 3 TPS being experienced. So the requirement to re-broadcast via blocks is an initial design compromise which is constraining capacity in a big way. Nodes reconstructing blocks from instruction messages (i.e. like IBLT) is best. So the opportunity for miners to accept direct tx for blocks is an artifact of the original design compromise. This capability will always exist to some degree but is not automatically a good thing because every node has to store the blockchain, so why shouldn't every node have the opportunity to contribute to consensus on the acceptance or rejection of every unconf tx which goes into it beforehand?

It is also not a case of nodes blocking the traffic of blocks they don't like. It is nodes simply not being able to reconstruct a block with the information they have already, plus the instructions given. I suppose my post above is more applicable to future state than current state.

Can anything be more decentralized than the original amorphous gossip-network design? Special channels for distinct services might have advantages, but 80% of the hashing power routing through a 6-node backbone is radical departure. I know why it was done, good intentions for helping miners behind the Great Firewall, etc.

 

[cypherdoc]

Is there really a tragedy of the commons scenario in the block space? Every single actor wants more, but the commons is better off with using less?

i don't think there is a TOC scenario here.
[doublepost=1454446117][/doublepost]

Glad to see you're looking forward to make Bitcoin big!

Arbitrary growth limits are a sign of irrational fear.

I hereby support the vision of Bitcoin Unlimited. That's how you design for success. How you make Bitcoin a trillion dollar project.

as @molecular is fond of saying; limits are for pussies!

 

[Roger_Murdock]

Here's what I said over on the reddit thread:

I guess I thought the philosophy of Bitcoin Unlimited was "getting out of the way" of the market by removing the "inconvenience barrier" to nodes and miners doing exactly what they think is best. So I'd be very hesitant about removing existing functionality (mining code, limit configurability). If you want to "encourage" certain settings, I think the better way is by making them defaults. Also, I think it's a little early to give up on Bitcoin Unlimited as a mining solution and say it's only for non-mining nodes. It really does seem like the better theoretical approach. It might just be ahead of its time and for now, the market might prefer the crystal clear simplicity of Classic as a Schelling point for breaking the current logjam.

 

[TrevinHofmann]

The scaling goal is sending transactions once through the network (ideal but not quite achievable). Just considering real-time tx dispersed through each 10-minute window, the network capacity is today more like 100 TPS than the 3 TPS being experienced. So the requirement to re-broadcast via blocks is an initial design compromise which is constraining capacity in a big way. Nodes reconstructing blocks from instruction messages (i.e. like IBLT) is best. So the opportunity for miners to accept direct tx for blocks is an artifact of the original design compromise. This capability will always exist to some degree but is not automatically a good thing because every node has to store the blockchain, so why shouldn't every node have the opportunity to contribute to consensus on the acceptance or rejection of every unconf tx which goes into it beforehand?

This seems to conflate the topics of multiple networks with IBLT. The two are not mutually exclusive.

It is also not a case of nodes blocking the traffic of blocks they don't like. It is nodes simply not being able to reconstruct a block with the information they have already, plus the instructions given. I suppose my post above is more applicable to future state than current state.

What did this statement mean, if not nodes choosing whether or not to allow blocks to propagate through the network?

Non-mining nodes give investor/saver/holders a degree of influence on miners by acting as intermediaries on their blocks as they propagate through the network

 

[solex]

> What did this statement mean, if not nodes choosing whether or not to allow blocks to propagate through the network?

I had two things in mind when I wrote that.
The first is the excessive-block-size in BU where nodes do not propagate blocks which are over their size limit. This is weakened when the miners communicate via their own channels. Secondly, with reconstruction, I was thinking of the upcoming thin-blocks (and IBLT in the future) when node mempools need consistency, so a block with a load of hitherto unseen tx will need to propagate as a standard block, which will increase its orphaning risk.

I will say that I am not against the RN functionality on principle, just that whatever it does should be part of standard implementation software, like Peter's extreme thinblocks, so that all nodes remain equal on the network (leaving aside the well-connected aspect).

 

[TrevinHofmann]

BU nodes have power because they will not follow a fork with an excessive block size, not because they will slow excessive blocks from propagating. There is no way that they can stop or slow miners from propagating their blocks to other miners and nodes that want those blocks. Unless there is a way of doing this that I'm not aware of, this idea seems dead on arrival.

 

[solex]

OK fine, I hadn't got that DoA notice

Are you still looking to get more involved with the RN?

 

[TrevinHofmann]

Yes. I haven't been able to do much yet, but I have a CI build working

https://github.com/BitcoinRelayNetwork/RelayNode

 

[solex]

Wow! I promise to stop dissing it until I see where you take it next.

 

[TrevinHofmann]

Criticism is good! It can help guide development. I would also rather be convinced that it would be a waste of time before I work on it rather than after.

 

[Roy Badami]

I'm broadly in favour of Gavin's suggestion. I don't really care if the mining code is actually ripped out, but I support promoting BU as a non-mining node, at least for now. That is the reality, after all.

I'm a little bit unsure about this bit of Gavin's proposal:

Yes, theoretically a 'rogue miner' could produce a block that takes a long time to broadcast or validate. So what? Worst case is your node spends half an hour validating it, and then re-orgs onto the longer chain with less expensive-to-validate blocks.

Unless I'm missing something, without any blocksize limit or sighash limit, that rogue miner could chuck out a 32MB block that would take all BU nodes offline effectively indefinitely until they were restarted.

My short term suggestion would be this: apply a 1.3GB sighash limit to all blocks that are larger than 1MB. We can safely do this now, without waiting for the fork. If and when the Classic fork activates we can put out a new release that makes the 1.3GB limit unconditional on block size. Similarly, if it looks likely that any other (non-Classic) big block solution that does not impose the 1.3GB limit is gaining traction with miners, we can revisit this and put out a new release that aligns with what miners are doing.

Thoughts?

 

[solex]

> rogue miner could chuck out a 32MB block that would take all BU nodes offline effectively indefinitely until they were restarted.

Not quite. It can only take out its peering nodes, which would be a very small percentage of BU nodes even in a majority BU network. This would still be annoying hence some sort of sigops limiting is preferable.

 

[yrral86]

That would be a lot of wasted hashing to take down a few nodes. I really doubt we would see such an attack attempted.

 

[Peter Tschipper]

Any miner trying such an attack would just be orphaning their blocks. But still there is a door open for possible attack for someone motivated enough.

 

[Roy Badami]

> rogue miner could chuck out a 32MB block that would take all BU nodes offline effectively indefinitely until they were restarted.

Not quite. It can only take out its peering nodes, which would be a very small percentage of BU nodes even in a majority BU network. This would still be annoying hence some sort of sigops limiting is preferable.

The attacker can fairly trivially establish connections to all BU nodes and broadcast the block to them. The attack would cost them one lost block reward, or approximately $10,000