Gold collapsing. Bitcoin UP.

[NewLiberty]

I was under the impression that there was more paper gold in circulation than there is actual gold in vaults, is that not the case? is all paper gold a 1:1 ratio?

GLD is an exchange traded fund without any leverage.  Some allege they do not have full backing but outside of a conspiracy theory I think we can assume they do keep the gold they are supposed to.    

It isn't a conspiracy theory, it is in the S-1 filings.
Physical Gold leaves the ETF every day sold for costs, and to compensate the sponsors of the ETF, taxes on which are paid by the ETF holders.
Bitcoin ETP uses the same model.
The Merk ETF has one of the lightest touches of this type at 0.4% per year, but even so, it compounds over years.  The older the trust, the less percentage it holds in actual goods.

The ETFs are good for liquidity and trading, but not at all good for the sort of generational holding that gold (and bitcoin) may serve so well.
They are also good for "retirement account" type investment vehicles which are not really intended to survive the investor/spouse.

[Adrian-x]

this is an interesting primer on MM and the risks of MM an sidecoin:

http://bitcoin.stackexchange.com/a/1288

While I believe we had conscience on NL's rational reconciliation that SC' that enable MM pose a risk to the incentive structure in the Bitcoin protocol.

The that reference link above illustrates it well.

[rocks]

Somewhat related to the ongoing debate on the sidechains concept,
this is a good-to-read thread on the bitcoin development mailing list:

http://www.mail-archive.com/search?l=bitcoin-development@lists.sourceforge.net&q=subject:%22Re%3A+%5BBitcoin-development%5D+The+difficulty+of+writing+consensus+critical+code%3A+the+SIGHASH_SINGLE+bug%22

particularly enlightening is this piece from Peter Todd in response to Justus:

In the current model, the specification *is* the protocol, and the
Bitcoin Core team is scared to death of changing anything; they've got
very little real power. Soft-forks are the minimum-viable way of making
changes to the protocol, and it's very clear how they get adopted:
minerr consensus. They're also a fundemental way of changing the
protocol that is impossible to prevent, so you might as well use it.

You'll find another insight of what's the real complexity of bitcoin
development at the beginning of the aforementioned thread.

Peter is talking about how every node alt-implementation has to
replicate the exact same behaviour of Bitcoin Core in terms of consensus
policies (even bugs if any), otherwise it will be forked off the network.
It is what he calls "bug-for-bug" compatibility. I've found it fascinating.

Another really interesting quote from Peter :

You know, the smartest thing the Bitcoin Foundation could do if they
wanted to cement their place in the Bitcoin ecosystem as a power broker
would be to setup a program of periodic hard-forks, say every year or
two, and then manage the committees that decide what goes into those
hard-forks. That they haven't suggested that yet is a sign that they're
either not evil, or they don't understand Bitcoin very well.

p.s. sorry for being way too OT

This a great summary of the issue. The bitcoin protocol is currently a mess today and worse there is no path to fix it.

The March 2013 fork was not caused by a new bug in the 0.8 version. It was caused because the 0.8 version did not contain a previously unknown bug in the 0.7 version. This unknown bug was part of the specification, but no one knew it was part of the specification. This is horrifying and will damage bitcoin in the long run. I think people think Bitcoin is more stable than it really is. The basic concepts and structure are great and all, but the implementation is not great. Worse the development process is fundamentally broken today so there is no way to fix known problems, it's a patchwork of turning bugs into specifications.

If you understand Sidechains they essentially are an attempt to fix a broken development process and make it more open, that is all.

[rocks]

OK, that makes sense. But isn't that still the same as Bitcoin in 2009/10/11 where Satoshi and later Gavin had control over commit privileges? The protocol change for sidechains is one time, after that the 5 guys in Blockstream have limited influence.

What this does is to decentralize implementation of new features. Today you have to go through a small number of people to get a commit accepted. With sidechains anyone can implement a new feature and the community can choose which to adopt. This puts the power to extend features directly in the hands of the community and out of the hands of the few commiters of today. This is decentralized implementation of features, which has tremendous potential benefits.

It seems if you are worried about today's situation where only a few people have commit privileges and have too much influence over new features, then sidechains address that worry by removing power from these few people.

It seems another fear is SC's causing the main Bitcoin chain to become stagnate and thus unused over time, damaging the network. I guess I just see this as an upgrade path. If everyone switches to a SC, that SC because the main chain. The 21M ledger is still intact.

And it's actually a better upgrade path from today. Again today those 5 guys with commit privileges can push us all to upgrade. With SC's the upgrade is completely voluntary for individuals to move, everyone can decide on their own when they feel ready to move.

the way i understand the github process is that while you may be able to put patches up there freely, nothing can be written to the source code w/o consensus from the core devs themselves.  b/c the vast majority of them now work in one company, there is a potential for them to possibly insert what they want and definitely to block what they don't want.

Your understanding of the process is the same as mine.

But again, isn't this the case today? What's different from today. At least with SC's you can implement new features outside of the centralized process we have currently (which I do not like).

JR has asked the question about technology that might obsolete the need for SC's and how that might get blocked.  he doesn't think his question got answered satisfactorily.  it is a potential problem that the community needs to address and talk about as it does have real world implications if abused.  they're basically saying "trust us".  it's up to you.

If there is strong demand, I don't think they can block SC alternatives. In Linux committers have a lot of control over their pieces, but it's not infinite by any means.

And again Blockstream does not have any control over sidechains where adoption of sidechains guarantees them money in any sort of way. We might find Blockstream has disappeared in a year and the 5 people mentioned above are now advocating for a SC alternative.

I think you bring up an important point which is "is this version of sidechains the best or are there potentially other solutions that are better". The reason this is important is once we have one version implemented, the preference will be to stick with the current version even if something better comes along later. So, we should make sure we implement the right technology first. That's a bigger sticking point for me.

no one is saying there "are" going to be problems, only that there is the potential for problems when it comes down to money.  blocking other innovations that might make SC's obsolete in the future could cost Blockstream lucrative contracts; after all, Austin has talked about designing SC's for gvts currencies.

a fundamental principle of Bitcoin as i've understood it is to design systems to be as resilient and trust free as possible.  why wouldn't this extend to those ppl who have influence over the source code?

I get that you are only talking about the potential for problems.

I am asking why you think problems related to only a few people having commit privileges is either: 1) new to sidechains or 2) worse with sidechains.

Again, the issue of having to trust a few centralized people with commit privileges is a problem Bitcoin has today and has always had. These maintainers have a variety of conflicting interests today. The potential problem you are ascribing to sidechains is not a problem for sidechains but a problem for Bitcoin. Yes the Bitcoin network is trustless in that you only have to trust the code and math, but Bitcoin still places a great deal of trust in a few people who maintain the code. Everytime you update your wallet version, you are trusting that someone else did not do something dishonest.

Sidechains have the potential to reduce this problem by enabling decentralized implementation of features and not relying on a few people, it actually improves the issue.

a fundamental principle of Bitcoin as i've understood it is to design systems to be as resilient and trust free as possible.  why wouldn't this extend to those ppl who have influence over the source code?

Bitcoin today requires significant trust in a few people maintaining the code. For example last month Luke Jr slipped an update to Ubuntu (or was it Debian) that blocked statoshidice and a few similar addresses, and it caused a huge uproar. Many people claimed he tried to force his religious preferences against gambling onto the network (personally I think it was just a non-malicious mistake where his own setting were accidentally moved to the release version), but it demonstrates that the potential for abuse is very real today.

This is an example of Bitcoin today not being trustless, but in fact trusting maintainers.

The issue you are ascribing to sidechains is not a sidechains issue, it is a Bitcoin issue. Unless you can show that the problem is made worse with sidechains, then it's not really a problem for sidechains.

Well see, you haven't really read the last 100 pages or so of this debate, or at least what I've repeatedly said  about conflict of interest.

The problem is your starting supposition : something is  wrong with Bitcoin and needs  to be fixed. That's not my starting point. I  don't think something is wrong  with Bitcoin and it should be left  alone.

This is the 2nd time you've done this and the 2nd time I'm going to call you out on it. Casually referencing some unstructured 100 pages as if they are a bible is not a response.

If you believe that sidechains have a conflict of interest issue, then you have to explain how the issue is either new or worse with sidechains. Simply stating the issue is there is not enough since the issue also exists today with Bitcoin. Otherwise you are presenting a problem Bitcoin has as if it is a problem for sidechains.

As described above I see sidechains as reducing the conflict of interest issue, not that the issue isn't there. You've stated nothing that counters that.

[rocks]

rocks, I also disagree with your characterization of Mc plus SC's as one seamless ledger in which 21M coins float with sov. If that were the case,  why all the fuss and need to firewall them off?

In theory they are buy no one knows for sure in reality.

And again you are simply stating an opinion as if it is fact but not responding to points made before.

The 2-way pegging process merge sidechains into the main chain as a single data structure. At any given time you could look at the bitcoin blockchain and billions of sidechains and see exactly where all 21M coins are in a completely open and transparent manner. That is the definition of a single seamless ledger that preserves the 21M cap and maintains the Sound Money aspect just as today.

It's fine to disagree, but so far you have not presented anything that counters that.

[Adrian-x]

Somewhat related to the ongoing debate on the sidechains concept,
this is a good-to-read thread on the bitcoin development mailing list:

http://www.mail-archive.com/search?l=bitcoin-development@lists.sourceforge.net&q=subject:%22Re%3A+%5BBitcoin-development%5D+The+difficulty+of+writing+consensus+critical+code%3A+the+SIGHASH_SINGLE+bug%22

particularly enlightening is this piece from Peter Todd in response to Justus:

In the current model, the specification *is* the protocol, and the
Bitcoin Core team is scared to death of changing anything; they've got
very little real power. Soft-forks are the minimum-viable way of making
changes to the protocol, and it's very clear how they get adopted:
minerr consensus. They're also a fundemental way of changing the
protocol that is impossible to prevent, so you might as well use it.

You'll find another insight of what's the real complexity of bitcoin
development at the beginning of the aforementioned thread.

Peter is talking about how every node alt-implementation has to
replicate the exact same behaviour of Bitcoin Core in terms of consensus
policies (even bugs if any), otherwise it will be forked off the network.
It is what he calls "bug-for-bug" compatibility. I've found it fascinating.

Another really interesting quote from Peter :

You know, the smartest thing the Bitcoin Foundation could do if they
wanted to cement their place in the Bitcoin ecosystem as a power broker
would be to setup a program of periodic hard-forks, say every year or
two, and then manage the committees that decide what goes into those
hard-forks. That they haven't suggested that yet is a sign that they're
either not evil, or they don't understand Bitcoin very well.

p.s. sorry for being way too OT

This a great summary of the issue. The bitcoin protocol is currently a mess today and worse there is no path to fix it.

The March 2013 fork was not caused by a new bug in the 0.8 version. It was caused because the 0.8 version did not contain a previously unknown bug in the 0.7 version. This unknown bug was part of the specification, but no one knew it was part of the specification. This is horrifying and will damage bitcoin in the long run. I think people think Bitcoin is more stable than it really is. The basic concepts and structure are great and all, but the implementation is not great. Worse the development process is fundamentally broken today so there is no way to fix known problems, it's a patchwork of turning bugs into specifications.

If you understand Sidechains they essentially are an attempt to fix the development process, that is all.

I understand Sidechains at the level of how they would work if they did what they proposed to do, i haven't taken the time to understand the maths. I remain skeptical of the net benefit to Bitcoin in general. I'm happy to take Odalv at his word when he says summarizing a 20 page proof is not trivial. i can only imagine the introduction of the code to execute it is similar in complexity. my point being adding new code doesn't simplify the code we have, and i would rather see competition in code to execute the maths be tested in Alts before integrating the first proposal.

I happen to agree 99% with tvbcof  that the critical issues that can affect Bitcoin in the next 2 years are easy to adjust in the code mainly the block limit and the tx fees. (the 1% we disagree on is the 5 seconds, i think its more akin to a day or two once its been reviewed.) the complexity arising from the exsisting praposals comes from how to automate it.

I would feel far more comfortable if over the next 2 years we cleaned up the code we had, commenting it, and reconciling it with projects like btcd addressing the bug for bug issues that propagate over time. before introducing more financial complexity.  I empathize with the community as a whole to add features they think will increase their investment, however, i would rather see the code base fare more secure - and a stable foundation before adding new dependencies.

[rocks]

Long discussion by Greenspan on Gold.

http://www.cfr.org/financial-crises/conversation-alan-greenspan/p33699

He's now sounding like a gold bug, probably because he is trying to re-position his legacy since he knows that his fiat paper will fail, largely due to his own actions.

[cypherdoc]

OK, that makes sense. But isn't that still the same as Bitcoin in 2009/10/11 where Satoshi and later Gavin had control over commit privileges? The protocol change for sidechains is one time, after that the 5 guys in Blockstream have limited influence.

What this does is to decentralize implementation of new features. Today you have to go through a small number of people to get a commit accepted. With sidechains anyone can implement a new feature and the community can choose which to adopt. This puts the power to extend features directly in the hands of the community and out of the hands of the few commiters of today. This is decentralized implementation of features, which has tremendous potential benefits.

It seems if you are worried about today's situation where only a few people have commit privileges and have too much influence over new features, then sidechains address that worry by removing power from these few people.

It seems another fear is SC's causing the main Bitcoin chain to become stagnate and thus unused over time, damaging the network. I guess I just see this as an upgrade path. If everyone switches to a SC, that SC because the main chain. The 21M ledger is still intact.

And it's actually a better upgrade path from today. Again today those 5 guys with commit privileges can push us all to upgrade. With SC's the upgrade is completely voluntary for individuals to move, everyone can decide on their own when they feel ready to move.

the way i understand the github process is that while you may be able to put patches up there freely, nothing can be written to the source code w/o consensus from the core devs themselves.  b/c the vast majority of them now work in one company, there is a potential for them to possibly insert what they want and definitely to block what they don't want.

Your understanding of the process is the same as mine.

But again, isn't this the case today? What's different from today. At least with SC's you can implement new features outside of the centralized process we have currently (which I do not like).

JR has asked the question about technology that might obsolete the need for SC's and how that might get blocked.  he doesn't think his question got answered satisfactorily.  it is a potential problem that the community needs to address and talk about as it does have real world implications if abused.  they're basically saying "trust us".  it's up to you.

If there is strong demand, I don't think they can block SC alternatives. In Linux committers have a lot of control over their pieces, but it's not infinite by any means.

And again Blockstream does not have any control over sidechains where adoption of sidechains guarantees them money in any sort of way. We might find Blockstream has disappeared in a year and the 5 people mentioned above are now advocating for a SC alternative.

I think you bring up an important point which is "is this version of sidechains the best or are there potentially other solutions that are better". The reason this is important is once we have one version implemented, the preference will be to stick with the current version even if something better comes along later. So, we should make sure we implement the right technology first. That's a bigger sticking point for me.

no one is saying there "are" going to be problems, only that there is the potential for problems when it comes down to money.  blocking other innovations that might make SC's obsolete in the future could cost Blockstream lucrative contracts; after all, Austin has talked about designing SC's for gvts currencies.

a fundamental principle of Bitcoin as i've understood it is to design systems to be as resilient and trust free as possible.  why wouldn't this extend to those ppl who have influence over the source code?

I get that you are only talking about the potential for problems.

I am asking why you think problems related to only a few people having commit privileges is either: 1) new to sidechains or 2) worse with sidechains.

Again, the issue of having to trust a few centralized people with commit privileges is a problem Bitcoin has today and has always had. These maintainers have a variety of conflicting interests today. The potential problem you are ascribing to sidechains is not a problem for sidechains but a problem for Bitcoin. Yes the Bitcoin network is trustless in that you only have to trust the code and math, but Bitcoin still places a great deal of trust in a few people who maintain the code. Everytime you update your wallet version, you are trusting that someone else did not do something dishonest.

Sidechains have the potential to reduce this problem by enabling decentralized implementation of features and not relying on a few people, it actually improves the issue.

a fundamental principle of Bitcoin as i've understood it is to design systems to be as resilient and trust free as possible.  why wouldn't this extend to those ppl who have influence over the source code?

Bitcoin today requires significant trust in a few people maintaining the code. For example last month Luke Jr slipped an update to Ubuntu (or was it Debian) that blocked statoshidice and a few similar addresses, and it caused a huge uproar. Many people claimed he tried to force his religious preferences against gambling onto the network (personally I think it was just a non-malicious mistake where his own setting were accidentally moved to the release version), but it demonstrates that the potential for abuse is very real today.

This is an example of Bitcoin today not being trustless, but in fact trusting maintainers.

The issue you are ascribing to sidechains is not a sidechains issue, it is a Bitcoin issue. Unless you can show that the problem is made worse with sidechains, then it's not really a problem for sidechains.

Well see, you haven't really read the last 100 pages or so of this debate, or at least what I've repeatedly said  about conflict of interest.

The problem is your starting supposition : something is  wrong with Bitcoin and needs  to be fixed. That's not my starting point. I  don't think something is wrong  with Bitcoin and it should be left  alone.

This is the 2nd time you've done this and the 2nd time I'm going to call you out on it. Casually referencing some unstructured 100 pages as if they are a bible is not a response.

If you believe that sidechains have a conflict of interest issue, then you have to explain how the issue is either new or worse with sidechains. Simply stating the issue is there is not enough since the issue also exists today with Bitcoin. Otherwise you are presenting a problem Bitcoin has as if it is a problem for sidechains.

As described above I see sidechains as reducing the conflict of interest issue, not that the issue isn't there. You've stated nothing that counters that.

It's worse because it establishes a precedent, which in some people's minds, like mine, is a conflict of interest. It shows that a group of insiders who do have some control of what's written to the rules of Bitcoin, can go out and establish a for profut company whose business model is dependent on a source code change that they have the influence to push through due to their significant %of the dev team. The establishment of SC's is not necessarily the problem itself.  It would have been much easier  to accept if Blockstream wasnt involved or if the team was broken up into several different companies.  

I generally don't like analogies but it would be like i 40% of the Federal Reserve board decided to establish a for profit company designed to take advantage of their son to be implemented negative interest rate policy. I  suggest you would scream bloody murder and demand they step down at the very least. Blockstream devs refuse to do that either because they are afraid of failure, they truly are conflicted, or they think it doesn't matter. I think it does matter as they could use their positions to possibly block competition

Edit : and it sends the wrong message

[tvbcof]

Long discussion by Greenspan on Gold.

http://www.cfr.org/financial-crises/conversation-alan-greenspan/p33699

He's now sounding like a gold bug, probably because he is trying to re-position his legacy since he knows that his fiat paper will fail, largely due to his own actions.

Greenspan has always been a gold bug and something a Randian Libertarian as far as I can tell.  Did you read his 1967 paper?  Fairly recently (after his tenure as fed chief) he said that he re-read not long before and he would not change a word.

Someone who understands all aspects of an issue is far better be prepared to be effective no matter which aspect they hire out to further.

[rocks]

I understand Sidechains at the level of how they would work if they did what they proposed to do, i haven't taken the time to understand the maths. I remain skeptical of the net benefit to Bitcoin in general. I'm happy to take Odalv at his word when he says summarizing a 20 page proof is not trivial. i can only imagine the introduction of the code to execute it is similar in complexity. my point being adding new code doesn't simplify the code we have, and i would rather see competition in code to execute the maths be tested in Alts before integrating the first proposal.

We completely agree on the need to be slow and careful and make sure the both the choice of which technology and what implementation be done with strong confidence that the choices made are better than any other alternatives. I've felt that in this thread there is a reaction to not make any changes or even explore options.

I happen to agree 99% with tvbcof  that the critical issues that can affect Bitcoin in the next 2 years are easy to adjust in the code mainly the block limit and the tx fees. (the 1% we disagree on is the 5 seconds, i think its more akin to a day or two once its been reviewed.) the complexity arising from the exsisting praposals comes from how to automate it.

We agree these are the main items to address in the near term. I just believe they are not the only changes needed.

I would feel far more comfortable if over the next 2 years we cleaned up the code we had, commenting it, and reconciling it with projects like btcd addressing the bug for bug issues that propagate over time. before introducing more financial complexity.  I empathize with the community as a whole to add features they think will increase there investment, however, i would rather see the code base fare more secure - and a stable foundation before adding new dependencies.

We disagree that the bug issues can ever be fixed adequately in the current development process. The whole problem it is they are part of the specification by default and because such an unbelievably massive effort to required to change anything, that the default is to leave them in.

I empathize with the community as a whole to add features they think will increase there investment, however, i would rather see the code base fare more secure - and a stable foundation before adding new dependencies.

I guess I see features as the main/only method to compete with fiat. As discussed earlier in this thread, fiat was a technological innovation over gold in terms of many ease of use aspects.

If we are to out compete with fiat, implementing more technological innovations is the best method. It is also replicates the method fiat used to take down gold.

[cypherdoc]

rocks, I also disagree with your characterization of Mc plus SC's as one seamless ledger in which 21M coins float with sov. If that were the case,  why all the fuss and need to firewall them off?

In theory they are buy no one knows for sure in reality.

And again you are simply stating an opinion as if it is fact but not responding to points made before.

The 2-way pegging process merge sidechains into the main chain as a single data structure. At any given time you could look at the bitcoin blockchain and billions of sidechains and see exactly where all 21M coins are in a completely open and transparent manner. That is the definition of a single seamless ledger that preserves the 21M cap and maintains the Sound Money aspect just as today.

It's fine to disagree, but so far you have not presented anything that counters that.

AndiI think your actually wrong here from a technical standpoint.

From what I understand from odalv and gmax is that these SC's can be private communities which would be using scBTC and we would never know it.  Certainly it seems like that way through the federated peg model. Remember these SC's are designed to fiction without having to have the Bitcoin network monitor them. The only thing that needs to be presented at the time of reentry into the Bitcoin network is a valid proof. In the meantime, maybe years, certainly the Bitcoin network has no idea what's going on with SC's and the scBTC involved so how would you?

[Adrian-x]

I guess I see features as the main/only method to compete with fiat. As discussed earlier in this thread, fiat was a technological innovation over gold in terms of many ease of use aspects.

If we are to out compete with fiat, implementing more technological innovations is the best method. It is also replicates the method fiat used to take down gold.

In my mind, the 1 order of magnitude year on year exponential growth, is competing effectively with fiat, and is so because it is seen as an inelastic asset. We may stall this year, but i dont think its because of lack of features, if anything it could be precisely because new investors are trying to mold it into something else before investing.  

[cypherdoc]

Somewhat related to the ongoing debate on the sidechains concept,
this is a good-to-read thread on the bitcoin development mailing list:

http://www.mail-archive.com/search?l=bitcoin-development@lists.sourceforge.net&q=subject:%22Re%3A+%5BBitcoin-development%5D+The+difficulty+of+writing+consensus+critical+code%3A+the+SIGHASH_SINGLE+bug%22

particularly enlightening is this piece from Peter Todd in response to Justus:

In the current model, the specification *is* the protocol, and the
Bitcoin Core team is scared to death of changing anything; they've got
very little real power. Soft-forks are the minimum-viable way of making
changes to the protocol, and it's very clear how they get adopted:
minerr consensus. They're also a fundemental way of changing the
protocol that is impossible to prevent, so you might as well use it.

You'll find another insight of what's the real complexity of bitcoin
development at the beginning of the aforementioned thread.

Peter is talking about how every node alt-implementation has to
replicate the exact same behaviour of Bitcoin Core in terms of consensus
policies (even bugs if any), otherwise it will be forked off the network.
It is what he calls "bug-for-bug" compatibility. I've found it fascinating.

Another really interesting quote from Peter :

You know, the smartest thing the Bitcoin Foundation could do if they
wanted to cement their place in the Bitcoin ecosystem as a power broker
would be to setup a program of periodic hard-forks, say every year or
two, and then manage the committees that decide what goes into those
hard-forks. That they haven't suggested that yet is a sign that they're
either not evil, or they don't understand Bitcoin very well.

p.s. sorry for being way too OT

This a great summary of the issue. The bitcoin protocol is currently a mess today and worse there is no path to fix it.

The March 2013 fork was not caused by a new bug in the 0.8 version. It was caused because the 0.8 version did not contain a previously unknown bug in the 0.7 version. This unknown bug was part of the specification, but no one knew it was part of the specification. This is horrifying and will damage bitcoin in the long run. I think people think Bitcoin is more stable than it really is. The basic concepts and structure are great and all, but the implementation is not great. Worse the development process is fundamentally broken today so there is no way to fix known problems, it's a patchwork of turning bugs into specifications.

If you understand Sidechains they essentially are an attempt to fix the development process, that is all.

I understand Sidechains at the level of how they would work if they did what they proposed to do, i haven't taken the time to understand the maths. I remain skeptical of the net benefit to Bitcoin in general. I'm happy to take Odalv at his word when he says summarizing a 20 page proof is not trivial. i can only imagine the introduction of the code to execute it is similar in complexity. my point being adding new code doesn't simplify the code we have, and i would rather see competition in code to execute the maths be tested in Alts before integrating the first proposal.

I happen to agree 99% with tvbcof  that the critical issues that can affect Bitcoin in the next 2 years are easy to adjust in the code mainly the block limit and the tx fees. (the 1% we disagree on is the 5 seconds, i think its more akin to a day or two once its been reviewed.) the complexity arising from the exsisting praposals comes from how to automate it.

I would feel far more comfortable if over the next 2 years we cleaned up the code we had, commenting it, and reconciling it with projects like btcd addressing the bug for bug issues that propagate over time. before introducing more financial complexity.  I empathize with the community as a whole to add features they think will increase their investment, however, i would rather see the code base fare more secure - and a stable foundation before adding new dependencies.

Yes, simplicity is actually important for Bitcoin in terms of coding. Just like cash is simpl,  Bitcoin should be simple technically. Complexity otoh introduces risks to bitcoin and all our savings. Technicall,  Blockstream devs are among the best bitcoin devs. But how good are they at Economics?

[cypherdoc]

I guess I see features as the main/only method to compete with fiat. As discussed earlier in this thread, fiat was a technological innovation over gold in terms of many ease of use aspects.

If we are to out compete with fiat, implementing more technological innovations is the best method. It is also replicates the method fiat used to take down gold.

In my mind, the 1 order of magnitude year on year exponential growth, is competing effectively with fiat, and is so because it is seen as an inelastic asset. We may stall this year, but i dont think its because of lack of features, if anything it could be precisely because new investors are trying to mold it into something else.   

[/b]

+1

[Adrian-x]

I guess I see features as the main/only method to compete with fiat. As discussed earlier in this thread, fiat was a technological innovation over gold in terms of many ease of use aspects.

If we are to out compete with fiat, implementing more technological innovations is the best method. It is also replicates the method fiat used to take down gold.

In my mind, the 1 order of magnitude year on year exponential growth, is competing effectively with fiat, and is so because it is seen as an inelastic asset. We may stall this year, but i dont think its because of lack of features, if anything it could be precisely because new investors are trying to mold it into something else.

+1

  that makes me feel good about dumping, I hope some "new investors" feel smug in there new position, and incentivised to maintain the Status quo.  ( and i mean Status quo in the lightest sense I'm in no way proposing to hobble Bitcoin so it cant run away.)

[cypherdoc]

Somewhat related to the ongoing debate on the sidechains concept,
this is a good-to-read thread on the bitcoin development mailing list:

http://www.mail-archive.com/search?l=bitcoin-development@lists.sourceforge.net&q=subject:%22Re%3A+%5BBitcoin-development%5D+The+difficulty+of+writing+consensus+critical+code%3A+the+SIGHASH_SINGLE+bug%22

particularly enlightening is this piece from Peter Todd in response to Justus:

In the current model, the specification *is* the protocol, and the
Bitcoin Core team is scared to death of changing anything; they've got
very little real power. Soft-forks are the minimum-viable way of making
changes to the protocol, and it's very clear how they get adopted:
minerr consensus. They're also a fundemental way of changing the
protocol that is impossible to prevent, so you might as well use it.

You'll find another insight of what's the real complexity of bitcoin
development at the beginning of the aforementioned thread.

Peter is talking about how every node alt-implementation has to
replicate the exact same behaviour of Bitcoin Core in terms of consensus
policies (even bugs if any), otherwise it will be forked off the network.
It is what he calls "bug-for-bug" compatibility. I've found it fascinating.

Another really interesting quote from Peter :

You know, the smartest thing the Bitcoin Foundation could do if they
wanted to cement their place in the Bitcoin ecosystem as a power broker
would be to setup a program of periodic hard-forks, say every year or
two, and then manage the committees that decide what goes into those
hard-forks. That they haven't suggested that yet is a sign that they're
either not evil, or they don't understand Bitcoin very well.

p.s. sorry for being way too OT

This a great summary of the issue. The bitcoin protocol is currently a mess today and worse there is no path to fix it.

The March 2013 fork was not caused by a new bug in the 0.8 version. It was caused because the 0.8 version did not contain a previously unknown bug in the 0.7 version. This unknown bug was part of the specification, but no one knew it was part of the specification. This is horrifying and will damage bitcoin in the long run. I think people think Bitcoin is more stable than it really is. The basic concepts and structure are great and all, but the implementation is not great. Worse the development process is fundamentally broken today so there is no way to fix known problems, it's a patchwork of turning bugs into specifications.

If you understand Sidechains they essentially are an attempt to fix a broken development process and make it more open, that is all.

That's a decent description of what happened with 0.8 but that's not all of it. I wrote extensively about this at the time but some is a little fuzzy. The shift from BDB to LevelDB left behind a bug in how the database works.  That is" bad" and I belief be there are other examples of this. But a different  way to look at this is "so what? "  maybe these bugs were exactly why some ppl scoffed at bitcoin in 2009 only to be proven wrong over the last 6year.  It's working! What's the tech analogy? Html5?

0.8 was also a failure of a adequate advertising  to top players like gox. They never bothered to update.  We rolled it back and went on our way. NP

[rocks]

It's worse because it establishes a precedent, which in some people's minds, like mine, is a conflict of interest. It shows that a group of insiders who do have some control of what's written to the rules of Bitcoin, can go out and establish a for profut company whose business model is dependent on a source code change that they have the influence to push through due to their significant %of the dev team. The establishment of SC's is not necessarily the problem itself.  It would have been much easier  to accept if Blockstream wasnt involved or if the team was broken up into several different companies.  

I generally don't like analogies but it would be like i 40% of the Federal Reserve board decided to establish a for profit company designed to take advantage of their son to be implemented negative interest rate policy. I  suggest you would scream bloody murder and demand they step down at the very least. Blockstream devs refuse to do that either because they are afraid of failure, they truly are conflicted, or they think it doesn't matter. I think it does matter as they could use their positions to possibly block competition.

That makes complete sense, I get the concern.

I guess I think the risk exists with or without Blockstream going first. There will always be moneyed entities lobbying to change things to their benefit. Whether or not sidechains happen will not change that. Just look at DC.

I also think sidechains decrease the level of influence external interests have by providing another outlet to make changes. Take paypal for example, today if paypal wanted to do something they'd have to lobby the core developers and community. With sidechains the community would rightfully respond that no changes are needed because paypal could now just implement a sidechain.

So I see sidechains as reducing the need for moneyed interest to change bitcoin by providing an easier alternative to implement, sidechains become the path of least resistance. And for the community participation is optional (which is a good)

[rocks]

rocks, I also disagree with your characterization of Mc plus SC's as one seamless ledger in which 21M coins float with sov. If that were the case,  why all the fuss and need to firewall them off?

In theory they are buy no one knows for sure in reality.

And again you are simply stating an opinion as if it is fact but not responding to points made before.

The 2-way pegging process merge sidechains into the main chain as a single data structure. At any given time you could look at the bitcoin blockchain and billions of sidechains and see exactly where all 21M coins are in a completely open and transparent manner. That is the definition of a single seamless ledger that preserves the 21M cap and maintains the Sound Money aspect just as today.

It's fine to disagree, but so far you have not presented anything that counters that.

I think your actually wrong here from a technical standpoint.

From what I understand from odalv and gmax is that these SC's can be private communities which would be using scBTC and we would never know it.  Certainly it seems like that way through the federated peg model. Remember these SC's are designed to fiction without having to have the Bitcoin network monitor them. The only thing that needs to be presented at the time of reentry into the Bitcoin network is a valid proof. In the meantime, maybe years, certainly the Bitcoin network has no idea what's going on with SC's and the scBTC involved so how would you?

Yes you may not be able to see what is happening off the main chain. (In the case of a zerocoin sidechain that would be the whole point BTW)

But my understanding is you would be able to see that the coins were moved to a sidechain and that is all you need for a global view. i.e. Bitcoin's main chain has 18M coins located at these UXTO, 1M coins on sidechain A, 1M coins on sidechain B, 1M coins on sidechain C. All 21M are accounted for.

The reason I'm saying that is a complete view is all 21M coins are accounted for visibly. The fact that you may not know what some of them are doing on sidechain B or who has them is not an issue, their existence and location on which chain is still known.

This might just be semantics....

[cypherdoc]

It's worse because it establishes a precedent, which in some people's minds, like mine, is a conflict of interest. It shows that a group of insiders who do have some control of what's written to the rules of Bitcoin, can go out and establish a for profut company whose business model is dependent on a source code change that they have the influence to push through due to their significant %of the dev team. The establishment of SC's is not necessarily the problem itself.  It would have been much easier  to accept if Blockstream wasnt involved or if the team was broken up into several different companies.  

I generally don't like analogies but it would be like i 40% of the Federal Reserve board decided to establish a for profit company designed to take advantage of their son to be implemented negative interest rate policy. I  suggest you would scream bloody murder and demand they step down at the very least. Blockstream devs refuse to do that either because they are afraid of failure, they truly are conflicted, or they think it doesn't matter. I think it does matter as they could use their positions to possibly block competition.

That makes complete sense, I get the concern.

I guess I think the risk is there with or without Blockstream going first. There will always be moneyed entities lobbying to change things to their benefit. Whether or not sidechains happen will not change that. Just look at DC.

I also think sidechains decrease the level of influence external interests have by providing another outlet to make changes. Take paypal for example, today if paypal wanted to do something they'd have to lobby the core developers and community. With sidechains the community would rightfully respond that no changes are needed because paypal could now just implement a sidechain.

So I see sidechains as reducing the need for moneyed interest to change bitcoin by providing an easier alternative to implement, sidechains become the path of least resistance. And for the community participation is optional (which is a good)

And I completely understand your point that it could stimulate free and open development. I've come off my harder line of objection and can see the light but it HAS to evolve as hypothesized by brg444  here or else were doomed.  There's alot of economic assumptions involved.

What if the market punishes  bitcoin though for allowing the conflict of interest?

[cypherdoc]

rocks, I also disagree with your characterization of Mc plus SC's as one seamless ledger in which 21M coins float with sov. If that were the case,  why all the fuss and need to firewall them off?

In theory they are buy no one knows for sure in reality.

And again you are simply stating an opinion as if it is fact but not responding to points made before.

The 2-way pegging process merge sidechains into the main chain as a single data structure. At any given time you could look at the bitcoin blockchain and billions of sidechains and see exactly where all 21M coins are in a completely open and transparent manner. That is the definition of a single seamless ledger that preserves the 21M cap and maintains the Sound Money aspect just as today.

It's fine to disagree, but so far you have not presented anything that counters that.

I think your actually wrong here from a technical standpoint.

From what I understand from odalv and gmax is that these SC's can be private communities which would be using scBTC and we would never know it.  Certainly it seems like that way through the federated peg model. Remember these SC's are designed to fiction without having to have the Bitcoin network monitor them. The only thing that needs to be presented at the time of reentry into the Bitcoin network is a valid proof. In the meantime, maybe years, certainly the Bitcoin network has no idea what's going on with SC's and the scBTC involved so how would you?

Yes you may not be able to see what is happening off the main chain. (In the case of a zerocoin sidechain that would be the whole point BTW)

But my understanding is you would be able to see that the coins were moved to a sidechain and that is all you need for a global view. i.e. Bitcoin's main chain has 18M coins located at these UXTO, 1M coins on sidechain A, 1M coins on sidechain B, 1M coins on sidechain C. All 21M are accounted for.

The reason I'm saying that is a complete view is all 21M coins are accounted for visibly. The fact that you may not know what some of them are doing on sidechain B or who has them is not an issue, their existence and location on which chain is still known.

This might just be semantics....

That's a good point.

 You seem to understand Economics. What's your opinion of we lose 50% of all BTC to a SC failure?