Author

Topic: Gold collapsing. Bitcoin UP. - page 593. (Read 2032266 times)

legendary
Activity: 1414
Merit: 1000
January 01, 2015, 04:35:24 PM

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.

sr. member
Activity: 404
Merit: 362
in bitcoin we trust
January 01, 2015, 04:29:51 PM
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).

Quote
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.

Quote
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
sr. member
Activity: 440
Merit: 251
January 01, 2015, 04:26:14 PM
Just making sure this doesn't get lost in the mix:

Quote from: justusranvier
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... ?
legendary
Activity: 1400
Merit: 1013
January 01, 2015, 04:23:27 PM
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.
legendary
Activity: 1414
Merit: 1000
January 01, 2015, 04:21:10 PM

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
legendary
Activity: 1764
Merit: 1002
January 01, 2015, 04:18:52 PM

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.
sr. member
Activity: 404
Merit: 362
in bitcoin we trust
January 01, 2015, 04:15:33 PM
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.

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).

Quote
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
legendary
Activity: 1162
Merit: 1007
January 01, 2015, 04:10:47 PM
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?
legendary
Activity: 1414
Merit: 1000
January 01, 2015, 04:05:55 PM

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
legendary
Activity: 1400
Merit: 1013
January 01, 2015, 03:57:35 PM
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?
legendary
Activity: 1162
Merit: 1007
January 01, 2015, 03:52:38 PM

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. 
legendary
Activity: 1400
Merit: 1013
January 01, 2015, 03:32:04 PM
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?
legendary
Activity: 1764
Merit: 1002
January 01, 2015, 03:20:24 PM

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
legendary
Activity: 1764
Merit: 1002
January 01, 2015, 03:00:30 PM

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.
legendary
Activity: 4760
Merit: 1283
January 01, 2015, 03:00:09 PM
Wrong again Bob.  With sidechains, native Bitcoin is available to anyone who wants to pay what it's worth.
That is the opposite of true.

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

That makes no more logical sense than to say it's 'artificially fixed' to where everyone can use of for 'free'.  And nothing in this world is 'free'.

The fact is that it's always going to be relatively expensive to have every transaction transmitted nearly instantly and stored indefinitely on multiple
autonomous systems.  You can try to subsidize it, but in the end all you are going to have is consolidation as the fixed rates and cost of doing business increases lineally without bound.  I'm willing to pay for this since I understand the value and it is valuable to me.  Most people bought into the hype so now we have tension.

The real 'costs of doing business' have not even started yet because Bitcoin is still to small to be a noteworthy threat to anyone.  Some of those who it might threaten are almost certainly keeping an eye on things, and likely influencing things such that they can win the upcoming battles if they need occur, but these are largely on the horizon.

In the mean time I think that you guys swim in a pool you are not even aware of.  That is, you take it for granted as an artifact of the natural environment that there exists a relatively free global network that you will always be allowed to use as a playground.  Ever seen the pictures of the rusty ships in the desert in the former Soviet Union?  Whoever build those thought there would always be a big pool of water there for them to float in and probably didn't really anticipate the plug being pulled on the dams that created the artificial sea.

What you want is to model the ubiquitous welfare state structure that abound with plebs being subsidized by powerful institutions who leverage economies of scale to drop their own costs while milking the herd for different kinds of value streams.
Again, what you're saying is the opposite of true.

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.

There are problems with the P2P network lacking price discovery, and as a result use of the blockchain creates externalities.

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.

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."

It does not matter how fast the solution grows or how profitable it might be in certain periods.  It is beyond absurd to say "we just need to get to 1x10^{n} hashes and everything will be cool."  This has vast ramifications for almost everything about Bitcoin, and it's been studiously ignored.  I suspect that it simply blows any conventional conceptions and efforts built upon them out of the water.

The best hope is that Bitcoin valuation growth happens in a linear manner, but this puts it at best on terms with modern Keynesian monetary systems which rely on centrally planned inflation to keep the game alive.  It doesn't seem likely with Bitcoin absent central control, and that is something I personally don't wish to see.  At all!

More likely what will happen is that mining will be profitable only to those who both employ economies of scale and who tap other value streams.  The most competative will be a handful of very large player who got very large by playing nice with the powers that be and who only survive by the grace of said.  We've seen this game before and see it all around us at present.

Sidechains have some hope of mitigating the inevitable disaster by requiring that Bitcoin itself become subsidized by mutable pool of sidechains no group of which are critical to the value core.  The also provide an outlet for the (again, inevitable) oversupply of sha256 hashing power which will otherwise if little to do and little to lose by attacking the very solution they were supposed to support before being powered down forever.

You guys should read the Greek myth about Syphilis.  That is an outstanding proxy for sha256 hashing in support of Bitcoin.  A much better long term solution for proof of work would have been significantly more sophisticated, but getting there from here probably does not involve Satoshi's Bitcoin at this time.  It may or may not include data residing in the blockchain however.  Sidechains provides the best bet of not ever finding out whether or not that is the case.

legendary
Activity: 1414
Merit: 1000
January 01, 2015, 02:53:25 PM

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.
legendary
Activity: 1162
Merit: 1007
January 01, 2015, 02:24:03 PM
Adam, what are your thoughts on increasing Bitcoin's blocksize limit?  Does Blockstream have a position on this topic?

I am not sure its a blockstream position as there are multiple independent minded bitcoin-protocol aware people that compose blockstream who dont always agree on everything.

But my view is increasing blocksize increases centralisation so you'd want to be careful about that.

I guess the current tx throughput is about 3-4x away from the 1MB limit with current average tx sizes?

It may also not be as close to the limit as it looks because once there was actual block space scarcity, maybe the economics will push out some stuff that is currently basically spam.  But you dont want that to go too far or actual transactions will back up.

Maybe the interim solution is to increase it a little bit or be prepared to, as it takes time to be ready.

If sidechains were ready, for people who like the security tradeoff, it offers another degree of freedom, because you can have different blockchains with different blocksizes.  eg you could have a lower value transaction blockchain where people can better tolerate the small extra centralisation risk (centralisation being if the bandwidth is 10x or 100x fewer nodes have the bandwidth to validate all tx.)   You might even make the argument bitcoin main blocksize could be reduced to improve its decentralisation.  It decouples from the one-size fits all aspect of bitcoin, which I think is a good thing - we can have more decentralisation where it matters, and more and faster transactions where it doesnt as much.

ps As its not always obvious to people a sidechain could also have a shorter block interval for faster clearing of lower valued transactions.  I'm sure you know that, but not everyone does.

Adam


One of my primary concerns with sidechains is that this "other degree freedom" is used to work around the hard problems (such as the scalability hard fork) at the possible long-term detriment of the network.  Like you said, "if sidechains were ready...you can have different blockchains with different blocksizes"; I worry that simply having this option might fragment the community such that the hard-fork to increase the blocksize limit doesn't happen.  Without sufficient transactional bandwidth on the main chain, I worry that Bitcoin's SOV properties would be hurt as the "global ledger" becomes fragmented across multiple sidechains. 

"Increasing blocksize increases centralisation" is as true a statement as "decreasing blocksize decreases centralization."  At a tiny blocksize the centralization risk is small but the Blockchain is not very useful.  At a huge blocksize the Blockchain can support Visa-level TXs/sec but centralization risk (at least at today's internet BW norms) is much higher.   So the question is one of balancing transactional throughput with centralization risk…and I don't believe the arbitrary 1 MB limit put in place by Satoshi many years ago as a stop-gap measure is necessarily the right choice.  I know there are some people who disagree, but I think Gavin's proposal to increase the blocksize limit inline with the historical rate of growth of internet bandwidth is a reasonable way to allow the network to scale without significantly affecting centralization. 

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.
legendary
Activity: 1764
Merit: 1002
January 01, 2015, 12:58:42 PM
Adam,

1. in the WP, you mentioned that it is possible that if a SC became popular enough, then Bitcoiners might have to move all their BTC to the SC.  what about those who don't get the memo?  this question is similar to the big debate we had a couple years ago about harvesting apparent "un-used" addresses.  that was obviously shot down real quick in that there is no way to ever be sure exactly that the true owner was dead or had lost the privkey.

2. philosopically, do you see Bitcoin as Money or as an economic "system" for trading assets of all types?

3. what real difference is there in forcing more transparency (as we are now doing with Merkle root audits, regulation, better VC funded exchanges) on 3rd party merchants vs. using SC's where supposedly we will be able to view the source code to ensure no backdoors (only a select few can do that)?  i would argue that the former is no different than the real mechanisms we have today and therefore not experimental or as risky to the degree you're wanting to construct via an unprecedented and untested 2wp.  i say risky b/c i am still not convinced that separating the BTC unit from its native blockchain (MC) is a safe economic thing to do.  its not safe b/c it requires all sorts of new assumptions/requirements such as no bugs in the spvp itself, 100% MM of the SC to be simply "as safe", no bugs or backdoors in the SC code written by all the unscrupulous altcoin devs that you despise of which only a few in the Bitcoin community will be able to vet via inspection of their code.  i expect hundreds of SC's to pop up as a result of your proposal and you yourself said that there are really only a few in the community who could or would take the time to vet potentially malicious code.  given this proliferation, if i'm right, how can honest devs ever keep up with this?

4. given that most of the real world already views a fixed supply of any currency as a liability, what feedback effects do you think a continuous destruction of scBTC from failed SC's will have on Bitcoin itself?  please just don't say "it will only make our BTC go up!"  i think the answer needs to acknowledge that it might be that the market views that negatively as a hopeless downward spiraling deflationary currency that continuously damages the merchant economy by encouraging hoarding.  in this sense, i am drawing parallels to gold being a fairly fixed supply that for the most part nevers decreases.
legendary
Activity: 4760
Merit: 1283
January 01, 2015, 12:30:39 PM

Seems like a good time for me to chime in here. Maybe a year ago I used to hear this sort of thing about Ripple, that somehow Ripple and Monetas were competitors. But we are not, since our software does different things. This will become much more evident as our software rolls out.

The same is true of Blockstream. If you generalize enough, you can find some sort of overlap and then assume we must be competitors. But the reality is that no one else is building what Monetas is building, and no one else will be able to do the things that our software does.

That's nothing negative on Blockstream, it's just different -- that's all. Anyone who thinks there is competition between us lacks an understanding of what we're building and how we plan to monetize it.


I've mainly ignored the massive storm of flotsam and jetsam in the crypto-currency sphere for other interests but just spent a few minutes looking at Monetas due to entries in this thread.

I must say, it kinda seems like Monetas (or whatever) is kind of targeting the big Kahuna.  That is, to BE Bitcoin on the basis of having a better implementation in bctd (and I would not doubt that they do.)

If that ends up coming to pass then ya, the world would truly be your oyster and I one could certainly say "no one else will be able to do the things that our software does."

legendary
Activity: 1400
Merit: 1013
January 01, 2015, 12:07:06 PM
Wrong again Bob.  With sidechains, native Bitcoin is available to anyone who wants to pay what it's worth.
That is the opposite of true.

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

What you want is to model the ubiquitous welfare state structure that abound with plebs being subsidized by powerful institutions who leverage economies of scale to drop their own costs while milking the herd for different kinds of value streams.
Again, what you're saying is the opposite of true.

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.

There are problems with the P2P network lacking price discovery, and as a result use of the blockchain creates externalities.

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.
Jump to: