Gold collapsing. Bitcoin UP.

[cypherdoc]

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.

I really think that you do not need to keep trillions chinese transactions stored in your computer.  Use MC as SOV and do shopping and everyday spending on local SCs.

What about pruning? Also, there have been innovative proposals emphasizing UTXO sets.

Auto prune. Apparently running stable now if you want to try:

https://github.com/bitcoin/bitcoin/pull/4701

[1714181819]

1714181819

[1714181819]

1714181819

[justusranvier]

Why don't you, cypherdoc, and whoever else be a sport and answer my theorem for a change:

  "Bitcoin mining will always approach non-profitability due to unlimited supply."

What is this, econ 101?

Of course Bitcoin mining will always approach non-profitability - in a free market the production of all products and services always approaches non-profitability. That's what markets do.

Absent some kind of forceful outside intervention, the price of all services in an economy approaches the cost of production plus a profit margin that tends toward zero over time.

Why would you even bring this up like it's some kind of great revelation or a problem of any kind whatsoever?

[Peter R]

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.

I really think that you do not need to keep trillions chinese transactions stored in your computer.  Use MC as SOV and do shopping and everyday spending on local SCs.

My post neither argued against sidechains nor advocated for storing "trillions of Chinese transactions" on the Blockchain.  I do think the blocksize limit should be as high as possible without adding too much centralization risk.  The debate then is one of finding the right balance between 'enough transactional bandwidth' on the Blockchain and 'too much centralization risk.'

But you've demonstrated the type of thinking I'm afraid of by suggesting that we simply push TXs to sidechains without bothering to objectively address the blocksize limit question. 

[justusranvier]

The debate then is one of finding the right balance between 'enough transactional bandwidth' on the Blockchain and 'too much centralization risk.'

Do you happen to have a definition of "centralization risk" or a way to measure it?

[Odalv]

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.

I really think that you do not need to keep trillions chinese transactions stored in your computer.  Use MC as SOV and do shopping and everyday spending on local SCs.

What about pruning? Also, there have been innovative proposals emphasizing UTXO sets.

We will see a lot of innovations in Bitcoin. Bitcoin will not be same in next 100 (10) years.
 - cars now ( and 100 years ago )   https://www.daimler.com/Projects/c2c/channel/images/790751_1449829_800_530_benz_patent_motorwagen_1886.jpg
 - first airplane and we have rowers on mars now :-)
 - first radio  and HDTV
 - computers and software are evolving much fasters

[Peter R]

The debate then is one of finding the right balance between 'enough transactional bandwidth' on the Blockchain and 'too much centralization risk.'

Do you happen to have a definition of "centralization risk" or a way to measure it?

I think it was Gavin's argument that as long as the typical home internet connection in the developed world was sufficient for running a full node at the blocksize limit, then this was acceptable protection against centralization risk.  This seems reasonable to me.  I think it was this type of logic that he used to come up with the 20 MB limit + 50% / year growth proposal (which my gut tells me is somewhat too aggressive).  

What are your thoughts?

[adam3us]

One of the interesting motivations for wanting the extensibility that sidechains provides is to be able to make that zero trust a reality for more bitcoin transaction types.

That would be great, if it was possible. However any given sidechain will always require more trust than the main chain. I don't believe the white paper made the claim that sidechains will be zero trust, did it?

Just terminology I mean where you find a way to express the security critical parts of the business logic so that it runs in a smart-contract, and then the blockchain enforces it for you.  For example lets say daily spend limits, if bitcion scripts had access to value as well as block height (without getting into address reuse for now) you could write a script to protect yourself from being coerced to spend your savings when you're trying to spend < $1000/day or whatever as a basic precaution from that wallet.  Its more secure if the blockchain enforces that than if a server does via a multisig where the server is the policy decision point because the server could be compromised.

The worst case scenario for sidechains is that they are used as an excuse to keep Bitcoin's transaction rate capped forever.

Well block size is an interesting debate.  Lots of people on both sides of that decentralisation vs scalability.  I made my comment on it earlier in the thread here in reply to Peter R comment about it.  https://bitcointalk.org/index.php?topic=68655.msg9997995#msg9997995 on this thread.  Peter Todd for example is pretty against increasing blocksize - but believes in full nodes only, and things like tree chains, Gavin mildly exploring it as a possibility and people who rely on bitcoin scalability due to a focus on user transactions and merchant integration getting nervous about being 3-4x from seeming limit (though we've yet to see spam get squeezed out).  Greg seems cautious due to centralisation risk like Peter.  I think go slowly and carefully as I said.

Based on the composition of the Blockstream team, I feel pretty safe assuming this is a goal which they will actively pursue.

You do realize that all the blockstream people are cofounders and founded the company and are philosophically inclined to defend bitcoin to the death and would quit if the rest of their co-founders went nuts and tried to coerce them or convince them to do something they considered bad for bitcoin.  We have like 8 Justuses (and I'm one of them:) not even kidding (and 3 people who would bow out for technical depth).

In that scenario we do, in fact, end up replicating the legacy banking system. There will be a real Bitcoin which only a privileged elite can access, and the rest of humanity will be relegated to transacting in money substitutes.

Yes actually that outcome also sucks and is the flip side of the debate where some people (eg Peter Todd with his keep bitcoin safe video on blocksize) small blocksizes are good for decentralisation but bad for access, if bitcoin becomes a settlement network.  As I was mentioning sidechains for those who like the security tradeoffs that can be constructed with them may provide a safety valve that doesnt involve switching to an alt, or going offchain.

If you're going to go offchain obviously its better to do it with split trust (voting trust, federated peg, multi-sig vaults etc) than pure governance IOUs.  But I think by being offchain you often miss out on user ethos focussed features like:

- unfreezability (exchange/vault refuses to give your coins back)
- unseizability (exchange/vault gives your coins to someone else)
- smart-contracts (if your ownership can be undone then so can a contract sort of, so it devolves from smart to dumb conventional electronic contract)

There's not a super nice answer thats in

Adam

[cypherdoc]

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.

I really think that you do not need to keep trillions chinese transactions stored in your computer.  Use MC as SOV and do shopping and everyday spending on local SCs.

What about pruning? Also, there have been innovative proposals emphasizing UTXO sets.

We will see a lot of innovations in Bitcoin. Bitcoin will not be same in next 100 (10) years.
 - cars now ( and 100 years ago )   https://www.daimler.com/Projects/c2c/channel/images/790751_1449829_800_530_benz_patent_motorwagen_1886.jpg
 - first airplane and we have rowers on mars now :-)
 - first radio  and HDTV
 - computers and software are evolving much fasters

I agree and very much encourage it. Just do it on MC so that we do not risk Bitcoins SOV function. The hard fork risk  is way overblown, imo, and just requires hard work and focus by the dev community along with funding from guys like me. The other buckets for investment, such as merchants and mining  will grow in time as well within their respective cycles.  By slowly allowing the altcoins to slowly die off like I argue  they are doing  with a  corresponding increase in Bitcoins price, more and more of those talented devs will focus back on Bitcoin.  SCs represent fragmentation and additional needless complexity.

[Odalv]

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.

I really think that you do not need to keep trillions chinese transactions stored in your computer.  Use MC as SOV and do shopping and everyday spending on local SCs.

My post neither argued against sidechains nor advocated for storing "trillions of Chinese transactions" on the Blockchain.  I do think the blocksize limit should be as high as possible without adding too much centralization risk.  The debate then is one of finding the right balance between 'enough transactional bandwidth' on the Blockchain and 'too much centralization risk.'

But you've demonstrated the type of thinking I'm afraid of by suggesting that we simply push TXs to sidechains without bothering to objectively address the blocksize limit question. 

Bitcoin blockchain, here called as MC is linear.  MC + SCs is new tree structure, it holds same informations (what address owns how many bitcoins) but in more flexible form =>  less disk space, faster, better anonymity

[justusranvier]

I think it was Gavin's argument that as long as the typical home internet connection in the developed world was sufficient for running a full node at the blocksize limit, then this was sufficient protection against centralization risk.  I think it was this type of logic that he used to come up with the 20 MB limit + 50% / year growth proposal (which my gut tells me is too aggressive).  

What are your thoughts?

This is not a definition of "centralization risk"

It's important to note that merely inventing a new phrase doesn't automatically mean that whatever it refers to actually exists.

What is centralization risk? How do we know it exists? How to we measure it so that we can compared two proposed courses of action to predict how they will affect it? How will we know if our estimates were accurate or not after the fact?

If you can't answer those questions and still propose to make decisions based on a concept you can't define or measure, then you're just guessing. If you can't tie the concept to something measurable in the real world you might as well be estimating the top speed of a galloping unicorn. Who could say if you're wrong or not?

Gavin's "20 MB limit + 50% / year" guess about something that may or may not exist is as good as any other random number, and about as valuable.

The best course of action is to avoid the central planner's fallacy, and stop pretending that it's possible for anyone to know the correct answer.

Determining the allocation of economic output by having humans try to guess magic constants is known-flawed strategy. There is no way to achieve success using this method of problem solving.

The problem solving technique that has been shown to work for allocating economic output is price discovery in a competitive open market.

Instead of trying to guess unknowable magic numbers, identify the problems which prevent price discovery from functioning and fix those.

[fellowtraveler]

Just making sure this doesn't get lost in the mix:

I think this concern could be minimised if the soft fork needed to support sidechains was part of a larger clarification of the Bitcoin protocol development process.

If there was a clear process that explained what kinds of changes to the protocol are acceptable, and what kinds are not, combined with a development roadmap and a transparent sequence of steps for adding things to it, I think there would be less reason for Bitcoin users to worry about Blockstream and sidechains.

I don't think anyone can disagree with this.

Clearly it could only be for the benefit of Bitcoin.

And it would assuage any/all concerns.

So... ?

[adam3us]

The price of native Bitcoin transactions will be artificially fixed above their free market price because there is a production quota.

I think of it as a bad thing that blocksizes grow too fast if it leads to centralisation.  And also a bad thing if people are blocked from getting access to full bitcoin features (eg because of the effects you mention).  Being offchain generally degrades your features sometimes to no better than legacy "trust us" banking.

I think there's a middle ground which can grow the blocksize a bit for now if it has to.  And some technical hope that the problem can be solved so that we have decentralisation and more scale.  Sidechains have a security trade off but do give you full (and potentially more) bitcoin ethos functions - eg someone can do zerocash, or network enforced limits etc.  Other things also snarks can do magical things (full node validation and low bandwidth), sharding like Rusty Russel is exploring with pettycoin (its not an alt, its an approach to sharding bitcoin).  Federated pegs.  And Open Transactions offers some interesting protection via its trust but verify approach though maybe not quite full bitcoin features, it can offer many features and maybe some different ones also (eg blinding though that as I understand it hampers audit, and I didnt see a way to repair that either yet).

What I want is for transaction processing to be a competitive open market. That means let the market decide how many transactions to put on the blockchain instead of smugly asserting that most of humanity "doesn't need" that level of security and therefore will be forbidden from having it.

One problem we face is it seems blockchains are inherently more expensive (bandwidth, latency, convergence time) at the limit that server clusters like Voting Pools for OpenTransactions and other related ideas.  That might encourage people to not take up full bitcoin features if those systems turn out not to be able to match the features quite due to less decentralisation.

The correct response to that kind of problem, however, is not more central planning - it's more price discovery so that all costs are reflected in the price of using the network.

sounds good to me.  I think there is sort of assumed to be some price discovery via user preference and miner policy but as the blocks havent filled up so far we've never seen much supply shortage other than at 0 fees.

Adam

[Odalv]

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.

I really think that you do not need to keep trillions chinese transactions stored in your computer.  Use MC as SOV and do shopping and everyday spending on local SCs.

What about pruning? Also, there have been innovative proposals emphasizing UTXO sets.

We will see a lot of innovations in Bitcoin. Bitcoin will not be same in next 100 (10) years.
 - cars now ( and 100 years ago )   https://www.daimler.com/Projects/c2c/channel/images/790751_1449829_800_530_benz_patent_motorwagen_1886.jpg
 - first airplane and we have rowers on mars now :-)
 - first radio  and HDTV
 - computers and software are evolving much fasters

I agree and very much encourage it. Just do it on MC so that we do not risk Bitcoins SOV function. The hard fork risk  is way overblown, imo, and just requires hard work and focus by the dev community along with funding from guys like me. The other buckets for investment, such as merchants and mining  will grow in time as well within their respective cycles.  By slowly allowing the altcoins to slowly die off like I argue  they are doing  with a  corresponding increase in Bitcoins price, more and more of those talented devs will focus back on Bitcoin.  SCs represent fragmentation and additional needless complexity.

It is not possible. Nobody wants to change bitcoin fundamentals. SCs will keep complexity out of bitcoin core. We want preserve bitcoin fundamental functionality in MC. It is not easy to understand basic bitcoin features for Average Joe.

[cypherdoc]

Adam,

i have a suggestion, out of fairness sake.  why don't we allow JR & ft, along with any other wanton altcoin/Bitcoin 2.0 dev, to insert their own highly specific op_code function into Bitcoin source code that benefits their own business model?  as long as it's open source, it should be fine, right?  and we shouldn't care if they are a for-profit, let alone nefarious, business; ppl can just ignore them.

[cypherdoc]

It is not possible. Nobody wants to change bitcoin fundamentals.

first off, usually they mean Bitcoin economic fundamentals.

second, they can get away with this position b/c Bitcoin is NOT broken, despite what some are trying to make us believe.

[tvbcof]

Why don't you, cypherdoc, and whoever else be a sport and answer my theorem for a change:

  "Bitcoin mining will always approach non-profitability due to unlimited supply."

What is this, econ 101?

Of course Bitcoin mining will always approach non-profitability - in a free market the production of all products and services always approaches non-profitability. That's what markets do.

Absent some kind of forceful outside intervention, the price of all services in an economy approaches the cost of production plus a profit margin that tends toward zero over time.

Why would you even bring this up like it's some kind of great revelation or a problem of any kind whatsoever?

So then you are aware that Bitcoin has effectively no long-term support potential as a foundation in it's presently advertised form and are not just another clueless dupe.  Good for you!  I can understand how it's one of those 'Houston, we have a problem' things that one would wish to defer dwelling on for whatever reason or set of reasons.  Chief among them until one has pocketed what one calculates to be the maximum potential profit.

For my part, I took some profits in case the shit hit the fan in an unpleasant way, but I also retained a bunch on the hopes that something would come along to rescue the system.  Sidechains seem to me to have that potential and do so in a way that preserves the aspects of Bitcoin that I like.  Centralization under a handful of large corp/gov players could also end up making me a dime, but I'd prefer the former route for philosophical reasons.

[cbeast]

Why don't you, cypherdoc, and whoever else be a sport and answer my theorem for a change:

  "Bitcoin mining will always approach non-profitability due to unlimited supply."

What is this, econ 101?

Of course Bitcoin mining will always approach non-profitability - in a free market the production of all products and services always approaches non-profitability. That's what markets do.

Absent some kind of forceful outside intervention, the price of all services in an economy approaches the cost of production plus a profit margin that tends toward zero over time.

Why would you even bring this up like it's some kind of great revelation or a problem of any kind whatsoever?

So then you are aware that Bitcoin has effectively no long-term support potential as a foundation in it's presently advertised form and are not just another clueless dupe.  Good for you!  I can understand how it's one of those 'Houston, we have a problem' things that one would wish to defer dwelling on for whatever reason or set of reasons.  Chief among them until one has pocketed what one calculates to be the maximum potential profit.

For my part, I took some profits in case the shit hit the fan in an unpleasant way, but I also retained a bunch on the hopes that something would come along to rescue the system.  Sidechains seem to me to have that potential and do so in a way that preserves the aspects of Bitcoin that I like.  Centralization under a handful of large corp/gov players could also end up making me a dime, but I'd prefer the former route for philosophical reasons.

No. He said that EVERYTHING approaches zero profitability in a free market. Your hypothesis then is it's not worth doing anything in life because everything is worthless.

[adam3us]

Well bitstamp isnt trying to algorithmically peg - they're saying trust our host security, cold wallet physical security, audit, governance / separation of duty etc.  Ie you are trusting humans to manage an IOU.  (Not saying bitstamp is a bad exchange).

I must be missing some essential detail.  I understood that each sidechain would be just a black box from the viewpoint of the bitcoin protocol, and its designers/developers would be free to choose whether and how to peg its operations to the bitcoin chain -- without the bitcoin network having to know about it.   Is there more to the 'sidechain' concept than that?

Could a sidechain be a BTC/USD exchange providing sub-second trades with cryptographic certificates? It would not be possible to peg every such trade to the blockchain, right?

Well the term sidechain is sort of fuzzy pre-existing term that means something like a related chain that watches or interacts with a parent or sibling chain.

I suppose I should say pegged sidechain because then that implies (compact) spv-proofs etc and then a chain is doing whatever it wants but its peg return requests must be signed by the DMMS signature composed of the majority of its miners view of the correct status of that from the sidechains point of view.

Adam

[justusranvier]

One problem we face is it seems blockchains are inherently more expensive (bandwidth, latency, convergence time) at the limit that server clusters like Voting Pools for OpenTransactions and other related ideas.  That might encourage people to not take up full bitcoin features if those systems turn out not to be able to match the features quite due to less decentralisation.

Blockchains are inherently more expensive in terms of resource consumption than other solutions. On the other hand, they offer additional features which the less expensive options can't provide.

We can't know what the optimal allocation between blockchain vs off-chain transactions - the only way to discover the optimal allocation is to allow blockchain transactions to find their true market price and compete fairly with off-chain transactions.

That price can not be discovered as long as there's a production quota tilting the scale.

sounds good to me.  I think there is sort of assumed to be some price discovery via user preference and miner policy but as the blocks havent filled up so far we've never seen much supply shortage other than at 0 fees.

The most important area where price discovery is lacking is bandwidth in the P2P network.

Right now it's designed like every other P2P network along the principle of, "Let's give everything away for free, then craft a set of rules of ever-increasing complexity that force consumption patterns into the shape we desire".

It would be a great sign of progress if we could all agree that's never been a viable long term solution to network design and that maybe it's time to consider "everybody pays for what they use" instead.

[sickpig]

I think there's a middle ground which can grow the blocksize a bit for now if it has to.  And some technical hope that the problem can be solved so that we have decentralisation and more scale.  Sidechains have a security trade off but do give you full (and potentially more) bitcoin ethos functions - eg someone can do zerocash, or network enforced limits etc.  Other things also snarks can do magical things (full node validation and low bandwidth), sharding like Rusty Russel is exploring with pettycoin (its not an alt, its an approach to sharding bitcoin).  Federated pegs.  And Open Transactions offers some interesting protection via its trust but verify approach though maybe not quite full bitcoin features, it can offer many features and maybe some different ones also (eg blinding though that as I understand it hampers audit, and I didnt see a way to repair that either yet).

Rusty Russell? The creator of iptables/netfilter?

Edit: a brief search confirmed we have another main linux kernel developer on board