Gold collapsing. Bitcoin UP.

[Dusty]

So you're saying that if a node use the RN client it does not need to require new blocks, it will receive blocks as soon they appear because the RN is going to broadcast them?

Yes, this is the architecture of the relay network: some kind of broadcast tailored per-peer.

So as you can see from requesting the block to fully validating it it took less than a second, 0.48 + 0.07 = 0.55 sec to be precise.

Yes, thinblocks are great, but to understand how well it scales you have to know at least:
- how many peers the node was relaying blocks to? How the two times change based on the number of peers he is connected to?
- how those two times grow with the growth of the number of transactions in the block?

Absolute numbers for a very small block like we have now is not complete info to understand how well it scales.
Also, please note that I'm not criticizing the x-thin blocks (on the contrary), I'm just interested in knowing if it can borrow some techniques from the RL to become even better.

 

[cypherdoc]

good article @Aquent

 

[sickpig]

Yes, thinblocks are great, but to understand how well it scales you have to know at least:
- how many peers the node was relaying blocks to? How the two times changes based on the number of peers he is connected to?
- how those two times grow with the growth of the number of transactions in the block?

Absolute numbers for a very small block like we have now is not complete info to understand how well it scales.
Also, please note that I'm not criticizing the x-thin blocks (on the contrary), I'm just interested in knowing if it can borrow some techniques from the RL to become even better.

I got what's your angle and I share your goal, i.e. find ways to improve block time propagation and integrate those in the bitcoin client directly without the need to use external tools.

WRT of Xthin scaling: I think that there's a lot of room for improvements and the @theZerg and @Peter Tschipper are working hard on this issue (BUIP017, Xpedited etc etc).

That said the aforementioned techniques would be fully integrated in the avg p2p client, hence we don't need to worry too much about scaling, or at least not as much as in the case of RN because we won't get only 6 nodes to relay all txs and all blks, we would have hundreds of nodes among which distribute such task (and we already have an order of magnitude more nodes than the one belonging to the RN, https://bitnodes.21.co/nodes/?q=bitcoinunlimited)

 

[Dusty]

I really like the work being done in BU.

BTW: does anyone know which are the plans (if any) regarding the merge of features of core 0.12.1 into Classic and BU?

 

[Richy_T]

Since the RL uses a scheme where the peer knows in advance which tx a peer has,

This implies that the "peer" is connected only to the relay network and not other nodes. This betrays the idea of a "peer to peer" network and is a tremendous centralizing choke-point. Un-censorable? Imagine if someone like luke-jr managed to gain control of the codebase. Your transaction might make it across the p2p Bitcoin network but if he regarded it as spam, there's a good chance it would never see a miner.

The relay network is anathema to Bitcoin ideals. It should never have been enacted. If something like it was inevitable, it should only have existed until its equivalent was integrated into regular nodes. That Core is limp on their own implementation of thin blocks and actively denigrate x-thin blocks just goes to outline that they are agenda driven.

It wouldn't be surprising to me if the relay network was being used as leverage against miners. I wish we could get some insight into that world because I'm sure a lot is going on that isn't above board.

 

[Peter R]

@Dusty:

I think Xthin is pretty close to theoretically optimal, given the lack or requirements it places on peers. Specifically, (a) it is designed to work with the existing P2P "INV" method, (b) it places no constraints on a node's mempool policy, (c) it is memoryless (i.e., it doesn't require keeping track of which transactions your peers have), (d) it does not place constraints on the ordering or selection of transactions in a block (i.e., miners can build blocks however they please).

Regarding round trips, under most conditions it has the same number of round trips as standard block propagation (and standard TX propagation) using the INV method (refer to the diagram that @sickpig posted).

Regarding the information transmitted, AFAICT the theoretical minimum is ~(N log2 M) + (missing TXs) where N is the number of transactions in the block and M is the number of transactions in mempool. The transmitting node needs to communicate the transactions the receiving node doesn't have in full, plus instructions that specify an ordered subset from the node's mempool (and this requires N log2 M bits of information).

If we assume mempool contains M = 20,000 transactions (about 10 MB of data), then--assuming all possible blocks are equally likely--the thin block must contain at least N log2(20000) ~= 14 N, or about 14 bits of information per transaction, plus any missing transactions in full.

Presently, Xthin uses 64-bit hashes (rather than the theoretical minimum of 14 bits for M=20,000) and we are confident this could be reduced to 32-bits (or even 24-bits) with further optimization.

Thus, from an information theory perspective, we are already close to the theoretical optimal performance given the lack of requirements Xthin places on nodes.

I think that making further "big gains" would mean placing further requirements on nodes such as canonical ordering of transactions or stricter mempool policies--all of which seem centralizing to me (especially if implemented in a top-down fashion by developers).

Instead, I think Xthin together with a technique like subchains would allow us to scale to 100 MB blocks and beyond.

 

[Peter Tschipper]

@sickpig @Dusty I think what often gets lost in this argument is that Xthins is just one of many scaling solutions. It's not the end all be all, just like the RN is not a scaling solution for anything other than serving blocks to miners as fast as possible. Should be throw it away because it's only serving miners, no of course not. Another point that is very much forgotten or misunderstood is that Xthins is primarily geared towards P2P scaling and was not intended in it's present form to be for the miners, however, the Xpedited version of Xthins, which thezerg is working on can/will be used as a replacement for the RN.

On another note, Xthins is pretty blazing fast and I do wonder if we're already faster than the RN but it's hard to say given the lack of any useful performance data from the RN. Looking at Matt's page on response times it looks to me as if it's taking about 1 second on average but I'm really not sure if those numbers are correct or if I'm reading it right since there is little explanation as to how to interpret the charts. So hard to make a real comparison there until someone actually does a side by side benchmark with RN and Xthins.

The other point that is also rarely mentioned is that a block has to hop through several RN servers to get to it's final destination, it's not really as direct as is often claimed, whereas with Xthins or the Xpedited version the miners can direct connect to each other. So we have Xthins that does inv/getdata or RN which hops through several servers, which one is faster is not really clear based on theory alone. Again, someone needs to actually do a test IMO before making any claims...just saying that one has fewer round trips doesn't necessarily make it faster.

 

[Inca]

Pull request released for segwit by Peter Wuille. He is certainly prolific.

It does seem as though we are heading towards some form of increased transactional capacity potentially hitting the network around the time of the halving. I can envisage a strong technical sympathy rally from the market because something has been done to move the debate forward.

Bitcoin halfway to the previous ATH by the halving would be great.

 

[Dusty]

This implies that the "peer" is connected only to the relay network and not other nodes.

Of course not: the Bitcoin p2p protocol is "a gossip protocol" so each node can get an idea on what tx the other peers has by knowing which one it relays to them and which one they advertise.
But this is important when a peer is "new", for long lived connections all your peers tend to have the same mempool so it's not a really important thing.

This betrays the idea of a "peer to peer" network and is a tremendous centralizing choke-point. Un-censorable? Imagine if someone like luke-jr managed to gain control of the codebase. Your transaction might make it across the p2p Bitcoin network but if he regarded it as spam, there's a good chance it would never see a miner.

I think you are misinterpreting my words: I'm not advocating the RL, on the contrary I was trying to understand if some of its features could be inserted in the p2p protocol, so that we can get rid of it.

I found the per-peer map of the tx a the most interesting one, but after thinking more about it I'm now thinking that its effect should really be marginal.

Thanks also to the posts of the "two Peters" for the insights.

 

[Zangelbert Bingledack]

No change of signature scheme will save you: the fact is that if you have some bitcoins on the blockchain before the fork, you have the private keys to control them.
And if you have the private keys you can sign in whatever new scheme you come up in every chain. If you can't sign them then you do can't control your coins, and hence you was not owning them before the fork.

In case @freetrader's response didn't make it clear, that is the intended behavior. Having the private key to an address ensures you still hold the same percentage of the ledger, which of course means you must have access to bitcoins on both ledger-copies (Core and Classic). The reason we're talking about a change in sig scheme is to enable you to spend on only one of the chains without someone (say, the tx recipient - merchant, etc.) broadcasting your tx on the other chain against your will when you do that.

Meni used to have this view, but for anyone who don't have bitcoin, it is inflation like QE. Notice that bitcoin's value is supported mostly by purchasing from those who don't have bitcoin, not who have

Actually there is no inflation, whether you own BTC or not. The only thing that changes for new investors is that they have to make a decision whether to buy the default: equal amounts of Corecoins and Classiccoins, or to weight their portfolio in some other way. Given this only happens in the highly unusual scenario where both ledgers persist and retain value, this is exactly the choice we'd want new investors to face.

From the perspective of current holders, they own a stake in both ledgers equally by default, and upon forking they can re-weight if they wish. For new investors they can choose default or some other weighting. It's not complicated, since from new investors' perspective these are separate coins with separate functions (since the two ledgers will only both retain value if the market agrees that there was a good reason for the separation and the two have distinct value propositions).

 

[AdrianX]

Yes, the relay network is centralized but anyone can run their own, and most of all: the principle it uses to propagate the new blocks are very efficient.
My opinion is that the bitcoin p2p protocol should adopt those techniques natively, without having to rely on an external, centralized service.
In fact something like this is being done in BU (xtreme thin blocks etc), but the relay network has a more advanced tech that I hope it will be implemented in BU in the future: the client remembers the txs sent to every peer so to send personalized xtreme blocks for each one of them instead of the same one for every peer.
This comes with a cost in memory and cpu, of course, but it's a really nice improvement.

@Dusty if the benefit of the Fast Relay Network was in the software then it being OSS would have benefit.

The benefits are not in the software at all but in being part of an exclusive centrally controlled network of miner who confirm amongst the network members the order of block in almost real time regardless what the the rest of the P2P network of nodes.

The relay network only has value if everyone uses the same network its benefits are worthless if everyone ran there own OSS version. (like wise Bitcoin does not get its value from being OSS but being a large robust network of users who agree to the rules. - yes anyone can run there own bitcoin network but the value is in the connections in the network not the software.)

The reason the relay network is popular are not the reasons you suggest, it's only viable so long as it give a disproportionate benefit to some miners. If it was free of centralization (i.e. run by the bitcoin network of nodes) then all miners would befit equally. so long as all miners have to compete on an equal footing with regards to orphan rate it makes no difference to the Bitcoin network if the orphan rate is 5% 1,5% or 0.15%. the risk of orphaning a block has utility in that it discourages relative and proportional block size and reducing it to 0 is not beneficial.

It's a BS business model strategy chaining the largest group of miners and improving their orphan rate relative to the rest of the network in order to create dependency and trust.

The Miners just don't understand that bitcoin only works if the protocol serves everyone equally, if they did they would reject the asymmetrical benefits provides by the relay network. Competitive advantages are achieved with creativity in the free market, ie managing the costs of energy, bandwidth, hardware, warehousing, and infrastructure support in the most productive way.

 

[Dusty]

From the perspective of current holders, they own a stake in both ledgers equally by default, and upon forking they can re-weight if they wish.

I agree. But I think that after a few hours, if you can arbitrage the two coins, I think the fork would resolve itself because of the overwhelming economical pressure to maximize the value of one chain at the expense of the other.

That's why: it's very difficult that miners will be evenly divided and this thing alone will give an important indication to all stakeholders, let then suppose a user with a big stake on chain A bets on its future: he sells all his B-coins to buy more A-coins. This move can change even more the balance between the two coins and all the undecided people, for fear of losing value, will sell their B-coins to have more of A. This should create an avalanche effect that would quickly resolve the fork based on the bets of the major stakeholders.

 

[AdrianX]

@adamstgbit :


Yes, folks would need to seperate their coins on the two chains (by sending them to different addresses) to prevent this. This is in itself a problematic process since it requires access to miners which are guaranteed to mine transactions only on a particular chain.

Transactions which involve only pre-fork inputs that have not been spent can be replicated by bridge nodes.
It is hard if not impossible to prevent such bridge nodes - the only counter I can think of is to make the transactions untranslatable which would require the fork to run a different signature scheme.

this point @adamstgbit brought up is a bit of a slap in the face for me, as I'm not a technical user but I've had to rebroadcast a transaction before and its not all that difficult and I don't think many would hesitate to do it.

When first presented with this type of fork I was looking at it like a Spin-off and in that case double spending same addresses on the new network is largely irrelevant. A Spin-off may be motivation to avoid the complication.

 

[Dusty]

@Adrian: please read my previous posts: I was not advocating the use of RL, just trying to analyze its features.

but the value is in the connections in the network not the software

It was in both: the RL used xthin blocks well before BU implemented them, and this together with a fast centralized network gave the miners the advantage to receive new blocks in 1/10 of the time.

It's a BS business model strategy chaining the largest group of miners and improving their orphan rate relative to the rest of the network in order to create dependency and trust.

That can be, but they are now deprecating its usage, and I think that's because they have to push the propaganda that big blocks can't be relayed fast enough on the network.

 

[AdrianX]

@Dusty you are correct that the forks would resolve themselves because of the overwhelming economical pressure. however @rocks is proposing an new fork that changes the mining algorithm so it dosent resolve to worthless but becomes an "alt", and it's that user case that made me concerned that a transaction could be rebroadcast on the other fork
[doublepost=1461091005][/doublepost]@Dusty i was just responding to the quoted post, I better understand your position but hadn't read it at the time thanks.

 

[freetrader]

this point @adamstgbit brought up is a bit of a slap in the face for me, as I'm not a technical user but I've had to rebroadcast a transaction before and its not all that difficult and I don't think many would hesitate to do it.

When first presented with this type of fork I was looking at it like a Spin-off and in that case double spending same addresses on the new network is largely irrelevant. A Spin-off may be motivation to avoid the complication.

Yes, I think both @adamstgbit and myself were talking about this in the context of proposed spin-offs. Indeed, that's where it applies since to re-spend a tx on another fork requires that fork to share the ledger history as regards unspent inputs for that tx.

It may be possible to prevent involuntary re-broadcasting of transactions by merchants or other actors.
I have received a useful suggestion today that would involve adding an optional new field to transactions, which would make their signatures untranslatable by bridges. In the absence of the field, the transaction would appear entirely regular and could be forwarded by bridges to other forks which understand it.

Such an optional field would effectively allow a user to control whether re-broadcasting of a particular transaction should be permitted.

This is at a conceptual stage which has not been verified to be technically feasible. I'm putting this suggestion out here in the hope that those of you who are much more technically knowledgeable might be able to point out flaws and potential new attack vectors.

 

[Dusty]

@AdrianX: np.
Regarding the two forks with different mining algorithms: apart from the initial advantage given on the miner distribution I suppose that the outcome should be very similar, why would that be different?
In fact it's the very feature of using different signature scheme to avoid third parties to broadcast tx from one chain to another makes the arbitraging possible, and profitable.

 

[AdrianX]

That can be, but they are now deprecating its usage, and I think that's because they have to push the propaganda that big blocks can't be relayed fast enough on the network.

We've gone full circle, what started this dictation is that @cypherdoc was also under the imprecation that it's being deprecated.

And I was saying that doesn't look like the case. As Core is looking to pay to outsource its maintenance and optimize it for a V2.0 https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-491#post-17993
[doublepost=1461092169,1461091392][/doublepost]@Dusty the reason a full fork would not totally resolve is if it had features or some other benefit that the dominate competing fork lacked.

It's only viable competition that will make result in the best money. It pains me to say this but Bitcoin is showing a hint of becoming the Myspace of cryipto.

Here is the fork project I was thinking of bitcoin and this fork would be negatively impacted with out a solution to the issue: https://bitco.in/forum/threads/announcement-bitcoin-project-to-full-fork-to-flexible-blocksizes.933/ I think it has more potential than Litecoin for many of the reasons discussed.

 

[Dusty]

As Core is looking to pay to outsource its maintenance and optimize it for a V2.0 https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-491#post-17993

Yes I knew of the core sponsorships, but if you check all of them you also find "improved block relay" as a first example, and if this is the case, why they don't import BU features in Core?
That list can be a charade, or a way to exhibit good will without actually doing anything, but just to buy time.
Like the talk about block size raise for ages.

 

[solex]

@Dusty
BS-Core are a running a balancing act. They don't want improved block relay in Core until the OP codes for LN and SegWit changes are fully deployed and activated in the Bitcoin network.
Improved relay (efficient block propagation such as BU thinblocks) makes the argument for keeping the 1MB much weaker, ergo the pressure for a HF block limit increase stronger.

The Corallo Relay Network is limited to 1MB and should have been increased to 8MB when XT was launched if it was being impartially operated. The dependence miners have on the RN is a major factor in the failure of XT and the stalling of Classic's hash-rate.