Gold collapsing. Bitcoin UP.

[albin]

can you explain what you mean by qualifying sequence numbers?

nSequence being set < 0xFFFFFFFF to signal the opt-in to replace the tx.

Basically what I'm suggesting is that if a miner sees nSequence flagging replaceable, the tx sender has indicated to the miner that they might get more money just waiting and not mining the tx. Admittedly the analysis to figure out how this could translate into profit-maximizing behavior is probably very complex, because on the margin we're talking about forsaking those revs for a probabilistic chance to pick up the replacement tx later, which is going to be a function of how much of total hashpower the miner has, and some notion of on average how much users tend to bump their fees per iteration, but in principle this situation has the right information characteristics for a price discrimination strategy to be plausible..

By the standards of rigor we've come to expect from the handwaving priesthood, I would wager that it's even totally justified to say on this basis alone that opt-in RBF is a force for mining centralization!

 

[theZerg]

Please consider posting this on /r/btc. Seems newsworthy.
[doublepost=1455811891][/doublepost]

Ok I put something up on /r/Bitcoin that avoided mention of BU.

 

[sickpig]

All,

we should have a look at @Peter Tschipper last proposal posted on BU development board: Xpress Validation (XV)

So it turns out that in bitcoin core not only txs are sent twice but even validated twice. Xthinblock will tackle the first whereas XV will deal with the second.

I'm really impressed with the work done by Peter, really god stuff.

 

[albin]

I think that @AdrianX just explained it better then I did. But I do not entirely understand what you meant with price discriminating between groups, maybe you could expand on that more.

The classic examples are airlines charging different rates by day (whether the demand is more business or leisure travelers) and college financial aid (where in the United States you fill out detailed paperwork telling them exactly what you can afford to pay and then largely subsidized loan and grant programs fill in the rest). When it's possible to distinguish between groups of customers with different demand preferences, a price discrimination strategy allows you to maximize profit by treating each as different markets and optimizing against each individually instead of aggregating them. In the example of high value tx's, it might be a reasonable strategy for miners to have different fee/KB minimums for larger value tx's, figuring in the extreme case say someone is transferring millions of dollars worth of bitcoin, there might be little doubt that that particular sender would be willing to spend a lot more than a few cents.

 

[Richy_T]

@sickpig

yeah, good pt.

it's just that miner can't get past fees/byte at this early stage due to fears of orphaning and whatnot. it IS crazy that you can send $millions for $0.04. not complaining of course

I would suggest that that is just your programmed expectations. There is not much reason that changing a few bytes in a database, blockchain or otherwise, should cost much more than the marginal costs to do so.
[doublepost=1455833369][/doublepost]

In fact I would be very surprised if we didn't see some kind of price discrimination for example if opt-in RBF actually makes it, because tx's with qualifying sequence numbers are just advertising to miners that they're willing to pay more.

Excellent point.

 

[AdrianX]

@albin, its about paying a premium on the cost to write to the blockchain in a preferred manner not a bases of value.

You are talking big changes to Bitcoin, I don't think we should change bitcoin to work like that - on a percentage, or a value based fee structure, maybe build an alt to test that long term.

Bitcoin tx fees are based on data size and should be priced according to orphan risk. it's just data in the commodity of block space.

If I was running Bitcoin as a business I'd switch to a percentage based model as a business income based on marginal profit from a commodity doesn't allow much leverage when it comes to maximizing profit.

We want the most powerful force - the miners to process all TX's equally based on an objective criteria to avoid centralized control, miners need to be kept in check to keep the incentive system in bitcoin working.

 

[Richy_T]

@VeritasSapere

That's labor theory of value. If tx value meaningfully divides tx senders into categories with different preferences, then price discriminating between groups becomes profit maximizing.

True. But miners are not doing anything special so one would expect competition to drive costs down. If one miner wants to charge 1BTC for a 2000BTC transaction, another will still be willing to do it for 0.0002
[doublepost=1455833883][/doublepost]

Well didn't your science teacher tell you that playing with the variables mid experiment was fastest way to compromise the results?

I've come to believe that it's not a financial experiment but a social experiment.

 

[VeritasSapere]

@albin Thanks for explaining that more, I can see what you mean now, I still agree more with @AdrianX on this point though, both because of conservatism and the market principles previously explained.

 

[albin]

What's nice about Satoshi's plan here is that we have alot of time to study these dynamics before they become especially significant, due to the block reward. I feel like alot of the thought-experimenting and conjecture coming out of the Core camp about fees is just way too premature.

 

[rocks]

So ... IF technological progress can't keep up with Bitcoin-system eating the world's transactions, we will end up with a state, where private users are unable to connect directly with the network. If connecting to bitcoin means to first download and verify one day of 2GB-blogs and then being a node in an ocean of 2gb-blocks, than it will be too much for most home users. It's already not pleasure, but it's possible, and I highly prefer to do it and I think its ideologically essential to be able to do so.

We already passed the point where most users do not and cannot connect to the P2P network directly. The vast majority of users today (probably >99%) use light wallets and rely on others to provide a bridge to the P2P network.

Bitcoin's blockchain structure makes this work in a fully secure manner. You are describing a scenario as a negative what if scenario, but it is in fact both the current reality and what Bitcoin was designed for.

Full nodes should not be run at home, they should be run in the cloud on AWS like instances. If transactions grow to 10GB/block then yes moore's law will not keep up with the compute power needed to process all those transactions on a single Xeon thread. But that is why we have this mechanism called scale-out computing. Bitcoin processing is almost perfectly parallelizable, bitcoind nodes in the future will not run on a single compute node, but on multiple compute nodes. This is all easy.

 

[Peter R]

I am very excited about @Peter Tschipper's Xthin blocks (scheduled to be included in the next release of Bitcoin Unlimited).

Xthin technology allows blocks to be transmitted much more efficiently, because the transmitting node sends the information by hash for the transactions the receiving node knows about and in full otherwise [1]. This permits a greater than one order-of-magntitude reduction in the number bytes that need to be transmitted during block propagation. What this means is that if all nodes employed Xthin technology, that--considering only block propagation--blocks could be an order of magnitude larger tomorrow without affecting the percentage of nodes that could keep up.

Why is this important?

Because block propagation to nodes is arguably the most significant bottleneck with respect to on-chain scaling.

For example, a group of researchers from Cornell, Berkeley and elsewhere recently released a position paper on scaling decentralized blockchains:

They found that the bottleneck--and the reason for their 4MB max block size recommendation--was block propagation to nodes:

This is precisely the problem that Xthin addresses. By the authors' own logic, blocks significantly larger than 4MB could be built--without harming the authors' measure of "decentralization"--once Xthin is widely deployed.

[1] Ignoring the "false positive" problem that should affect less than 1% of transmissions.

 

[VeritasSapere]

Amazing work regarding Xthin blocks, I am only just starting to realize the significance of this.

I have been commentating on this thread but I do not feel comfortable there anymore. So much better discussing in a place where I do not need to fear censorship.

https://bitcointalk.org/index.php?topic=1349965.msg13932366#msg13932366

I did think I made some good points though before making a graceful exit I hope.

 

[Richy_T]

Great work by all involved. I feel this is one of the first optimizations that should have been done (I understand Hearn had something along the same lines? A comparison might be instructive)

 

[theZerg]

To move th8n blocks to the next level we need to solve the txn propagation problem. Please read my proposal in BU forum... if you want to contribute.
[doublepost=1455844822][/doublepost]@rocks I don't think you should make blanket and imprecise comments like "full nodes should not be run at home". Some people have FTTH for example. A home node that is used to serve SPV clients across a small town would keep these communications within the head end. Bandwidth kept within an ISP and esp within a head end is a LOT cheaper for the ISP then data going to the greater internet.

 

[rocks]

@theZerg Fair point. That comment was more meant to say that your average non-technical user shouldn't be expected to have to run a full node. Motivated people with FTTH of course can run home nodes for awhile. Although if we expect massive 100+ GB blocks someday then even with FTTH it might become difficult. At that point I'd expect cloud computing to be even more pervasive though and it's likely we'll run most processing in the cloud anyway without realizing it and most home devices will just be attach points.
[doublepost=1455845466][/doublepost]Good luck suing Bitcoin to turn over encryption keys or stop processing certain keys

WSJ reports that Senate Intelligence Committee Chairman Richard Burr (R., N.C.) is working on a proposal that would create criminal penalties for companies that don’t comply with court orders to decipher encrypted communications.

http://www.zerohedge.com/news/2016-02-18/crypto-wars-escalate-congress-plans-bill-force-companies-comply-decryption-orders

However if you use LN run by Blockstream it is of course much easier for the government to ensure compliance.

 

[dlareg]

Please excuse me if this is off topic, but I really wanted to say "thank you" to everyone participating in this thread and in this forum. I stumbled here by accident several weeks ago and have gone through and read each post starting at the beginning. I am certainly no early adopter, but have been involved with Bitcoin for several years. I am an IT professional and passionate about this most wonderful creation. I have been deeply disturbed by what Core has been doing, and the deceptive ongoing manipulation that appears to be none other than a coordinated attempt to neuter and destroy the basic premises that attracted me originally. Finding this forum and this intelligent, rational discussion, that sees through the veil has provided me with much hope in these critical and disturbing times. This place is a jewel in the rough. I am mostly a lurker and don't want to turn this into a long rant or disturb the flow here, but truly thank you all for what you are doing! Looking forward to helping and participating in the future.

 

[Peter R]

@theZerg, @Peter Tschipper, @sickpig:

Why do the Blockstreamers not understand that a typical Xthin exchange doesn't increase the number of round trips compared to the normal P2P protocol? This is Patrick Strateman:


I would explain this however I was banished from r/bitcoin after posting the forbidden GIF. So I made this figure to help (adapted from Fig. 2 of Decker and Wattenhofer 2012)

 

[sickpig]

@Peter R

I've quickly skimmed the reddit thread you quoted and the RLN website and I think that Patrick is not arguing in good faith. Maybe I'm wrong but I can't see a lot of rationality in his statements.

IMHO It's useless engaging in tech debate where the other part is pretending to be a technical counterpart where in reality he's only pursuing a political agenda.

about the RLN:

- you're not encouraged to run a server only clients, in fact binary are provided only for the latter

- RLN does not perform validation

- RLN website:

The relay nodes are NOT designed to ensure that you never miss data,
and may fail to relay some transactions/blocks. The relay nodes are NOT a replacement for having peers on the standard P2P network, nor should you rely on it as your only fast block relay method.

lastly: what's all this fury against xthin? if RLN is better it will win at the end and Patrick should not fear competition in any case.

it's like being angry to someone that cut your bandwidth consumption suddenly by a half just because there's another solution that "is" better (I doubt it) but to make it works you have to jump through a few hoops, namely: compiling it from source code (only win exe for the client are provided), install it and lastly operate it properly. Perfect logic, right?

 

[Peter R]

@sickpig

Agreed.

And he's not just comparing Xthin to the centralized relay network. He's also claiming that Xthin doubles the number of round trips compared to the the normal p2p network (which my diagram shows is false):

Which is to say best case [Xthin] can improve bandwidth costs for nodes on the p2p network, but at the cost of doubling the number of round trip requests that have to be made.

 

[Christoph Bergmann]

@theZerg, @Peter Tschipper, @sickpig:

Why do the Blockstreamers not understand that a typical Xthin exchange doesn't increase the number of round trips compared to the normal P2P protocol? This is Patrick Strateman:

I guess we just lack brainpower to understand him. I mean, he's a core dev. Otherwise his post can be translated into:
- a core/blockstream member has no clue how the network broadcasts blocks (he thinks a node just sends blocks for one time and doesn't understand the problems with peaks)
- a core/blockstream member tries to diss one of the greatest enhancements to bitcoin's scalability ever because it is not from core/blockstream, what can be translated into: a core/blockstream member is not intersted in making bitcoin better but into keeping core/blockstream in charge, even if it comes on the cost of making bitcoin worse.

Congratulation @zerg/peter_tschipper!

If I understand xthin correct, it helps the miners to cross he big firewall without the relay network and reduces the need upload capacity of a node to ~10-20% and the cpu for validation to 50%.

With libsec256k1 etc. cpu capacity would go down to 10%. So if everybody is ok with 2/4 mb blocks, regarding cpu / bandwith we should be able to go to 20/40Mb easily. Only problem left is the enormous amount of data to download.

But yeah, I'd say with xthin the most pressing issue of scalability today can be solved. If it works properly I don't see any reason for core to not implement it immediately, except they want to damage bitcoin or are to arrogant to implement anything not made by core.