Bitcoin Forum
August 16, 2017, 03:29:48 PM *
News: ALL CLEAR: You can now use Bitcoin as you were previously. For more info, including how to claim your BCH (optional), see here.
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 [807] 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1950436 times)
Odalv
Legendary
*
Offline Offline

Activity: 1176



View Profile
November 07, 2014, 02:34:59 PM
 #16121



How would ppl trade scBTC with each other?

Example:


Simplified version of exchange.

1. I can create bid/ask Merger as SC.
 - it can be implemented as central authority server  b/c it cannot move coins (I'll remove feature send coins from this mergerSC)
 - merger can only pair  bids and asks (new featue I'll add) => Merger will create proof (Merger creates signature that he found signed bid by A that match signed ask by B) => in fact merger mines blockchain as list of trades.

2. now I can create 2-way-peg  (Federated Peg, Oracle or by Bitcoin protocol)
 - I can deposit asset into Merger
 - I can withdraw asset from Merger because I can create proof from merger-blockchain.
 - Merger can be easy audited

3. Merger feature cannot be implemented on MC b/c it requires to remove feature "send coins" and new blockchain concept.

Edit:
Trying to explain it more.
It will look same as gox (gox will have goxBTC not real bitcoins)
I'll use proof of trading  and  2wp  (Federated Peg, Oracle or by Bitcoin protocol) gives me real bitcoins.
1502897388
Hero Member
*
Offline Offline

Posts: 1502897388

View Profile Personal Message (Offline)

Ignore
1502897388
Reply with quote  #2

1502897388
Report to moderator
1502897388
Hero Member
*
Offline Offline

Posts: 1502897388

View Profile Personal Message (Offline)

Ignore
1502897388
Reply with quote  #2

1502897388
Report to moderator
1502897388
Hero Member
*
Offline Offline

Posts: 1502897388

View Profile Personal Message (Offline)

Ignore
1502897388
Reply with quote  #2

1502897388
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 02:43:55 PM
 #16122



How would ppl trade scBTC with each other?

Example:


Simplified version of exchange.

1. I can create bid/ask Merger as SC.
 - it can be implemented as central authority server  b/c it cannot move coins (I'll remove feature send coins from this mergerSC)
 - merger can only pair  bids and asks (new featue I'll add) => Merger will create proof (Merger creates signature that he found signed bid by A that match signed ask by B) => in fact merger mines blockchain as list of trades.

2. now I can create 2-way-peg  (Federated Peg, Oracle or by Bitcoin protocol)
 - I can deposit asset into Merger
 - I can withdraw asset from Merger because I can create proof from merger-blockchain.
 - Merger can be easy audited

3. Merger feature cannot be implemented on MC b/c it requires to remove feature "send coins" and new blockchain concept.

But that'ssa centralized system which we've already agreed is not ideal. I more interested in how this works on the SC via spv proof
Odalv
Legendary
*
Offline Offline

Activity: 1176



View Profile
November 07, 2014, 02:56:30 PM
 #16123



How would ppl trade scBTC with each other?

Example:


Simplified version of exchange.

1. I can create bid/ask Merger as SC.
 - it can be implemented as central authority server  b/c it cannot move coins (I'll remove feature send coins from this mergerSC)
 - merger can only pair  bids and asks (new featue I'll add) => Merger will create proof (Merger creates signature that he found signed bid by A that match signed ask by B) => in fact merger mines blockchain as list of trades.

2. now I can create 2-way-peg  (Federated Peg, Oracle or by Bitcoin protocol)
 - I can deposit asset into Merger
 - I can withdraw asset from Merger because I can create proof from merger-blockchain.
 - Merger can be easy audited

3. Merger feature cannot be implemented on MC b/c it requires to remove feature "send coins" and new blockchain concept.

But that'ssa centralized system which we've already agreed is not ideal. I more interested in how this works on the SC via spv proof

It is too complicated to explain. ( 20 pages of pdf ).

2wp can be replaced anytime (I mean switching from Federated Humans to SNARK scheme)

For the begging let's use  5 federated human judges who can use brain and can check trades. (ticker log)

You didn't answer me
"isn't  this same as move BTC from MC into exchange orderbook ?"
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 03:06:00 PM
 #16124



How would ppl trade scBTC with each other?

Example:


Simplified version of exchange.

1. I can create bid/ask Merger as SC.
 - it can be implemented as central authority server  b/c it cannot move coins (I'll remove feature send coins from this mergerSC)
 - merger can only pair  bids and asks (new featue I'll add) => Merger will create proof (Merger creates signature that he found signed bid by A that match signed ask by B) => in fact merger mines blockchain as list of trades.

2. now I can create 2-way-peg  (Federated Peg, Oracle or by Bitcoin protocol)
 - I can deposit asset into Merger
 - I can withdraw asset from Merger because I can create proof from merger-blockchain.
 - Merger can be easy audited

3. Merger feature cannot be implemented on MC b/c it requires to remove feature "send coins" and new blockchain concept.

But that'ssa centralized system which we've already agreed is not ideal. I more interested in how this works on the SC via spv proof

It is too complicated to explain. ( 20 pages of pdf ).

2wp can be replaced anytime (I mean switching from Federated Humans to SNARK scheme)

For the begging let's use  5 federated human judges who can use brain and can check trades. (ticker log)

You didn't answer me
"isn't  this same as move BTC from MC into exchange orderbook ?"


Maybe but you can't explain in less than 20 pages of pdf why we should prefer that system or if it's even safe or efficient. Are current wn wallets or exchanges getting safer? Maybe.
Odalv
Legendary
*
Offline Offline

Activity: 1176



View Profile
November 07, 2014, 03:12:42 PM
 #16125

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 03:17:57 PM
 #16126

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.

yes, but that's for getting BTC--->scBTC.  how does scBTC get exchanged while on SC other than simply by localtrading p2p w/o centralizing it?
Odalv
Legendary
*
Offline Offline

Activity: 1176



View Profile
November 07, 2014, 03:31:06 PM
 #16127

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.

yes, but that's for getting BTC--->scBTC.  how does scBTC get exchanged while on SC other than simply by localtrading p2p w/o centralizing it?

Not, ... oracle is on SC and oracle check SC.
It is same chain as Bitcoin
It know longest SC b/c it is same as every bitcoin client can verify

 and is unlocking bitcoins in MC by signing bitcoin transaction in MC.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 03:37:50 PM
 #16128

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.

yes, but that's for getting BTC--->scBTC.  how does scBTC get exchanged while on SC other than simply by localtrading p2p w/o centralizing it?

No oracle is on SC and oracle check SC.
It is same chain as Bitcoin
It know longest SC b/c it is same as every bitcoin client can verify

 and is unlocking bitcoins in MC by signing bitcoin transaction in MC.

?

maybe i can answer my own question.  once someone holds scBTC, they can transact just like they would with BTC except being able to take advantage of faster tx and anonymity be it online or p2p.  my question is that these same scBTC can be traded with other scBTC holders.  i suppose that could be p2p as well but if done on a centralized exchange that doesn't advance our anonymity desires.  which is what i was getting at to address your question about how a SC may or may not be analogous to mtgox.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 03:39:07 PM
 #16129

it's starting already.

Truthcoin, enabled by SC's!

http://www.truthcoin.info/
Odalv
Legendary
*
Offline Offline

Activity: 1176



View Profile
November 07, 2014, 03:45:50 PM
 #16130

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.

yes, but that's for getting BTC--->scBTC.  how does scBTC get exchanged while on SC other than simply by localtrading p2p w/o centralizing it?

No oracle is on SC and oracle check SC.
It is same chain as Bitcoin
It know longest SC b/c it is same as every bitcoin client can verify

 and is unlocking bitcoins in MC by signing bitcoin transaction in MC.

?

maybe i can answer my own question.  once someone holds scBTC, they can transact just like they would with BTC except being able to take advantage of faster tx and anonymity be it online or p2p.  my question is that these same scBTC can be traded with other scBTC holders.  i suppose that could be p2p as well but if done on a centralized exchange that doesn't advance our anonymity desires.  which is what i was getting at to address your question about how a SC may or may not be analogous to mtgox.

Now this new SC is same as original Bitcoin + has native support for new signatures (SPV, SNARK ...) -> new version of bitcoin.
Now inside this SC, it is possible to create new SCs (eg fastWallet, exchanges, ...)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 04:01:47 PM
 #16131

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.

yes, but that's for getting BTC--->scBTC.  how does scBTC get exchanged while on SC other than simply by localtrading p2p w/o centralizing it?

No oracle is on SC and oracle check SC.
It is same chain as Bitcoin
It know longest SC b/c it is same as every bitcoin client can verify

 and is unlocking bitcoins in MC by signing bitcoin transaction in MC.

?

maybe i can answer my own question.  once someone holds scBTC, they can transact just like they would with BTC except being able to take advantage of faster tx and anonymity be it online or p2p.  my question is that these same scBTC can be traded with other scBTC holders.  i suppose that could be p2p as well but if done on a centralized exchange that doesn't advance our anonymity desires.  which is what i was getting at to address your question about how a SC may or may not be analogous to mtgox.

Now this new SC is same as original Bitcoin + has native support for new signatures (SPV, SNARK ...) -> new version of bitcoin.
Now inside this SC, it is possible to create new SCs (eg fastWallet, exchanges, ...)

you don't mean another second SC for fastWallet and exchanges, do you?  b/c i would consider that a disadvantage as that would mean BTC would have to traverse 2 separate SPV proofs with contest/confirmation periods in order to get to 2nd SC which would increase risk of escaping SC's in general in an emergency due to time delays and technical failures. 

i would hope fastWallet exchanges  would be decentralized and anonymous and exist on the 1st SC away from Bitcoin. 
Odalv
Legendary
*
Offline Offline

Activity: 1176



View Profile
November 07, 2014, 04:10:25 PM
 #16132

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.

yes, but that's for getting BTC--->scBTC.  how does scBTC get exchanged while on SC other than simply by localtrading p2p w/o centralizing it?

No oracle is on SC and oracle check SC.
It is same chain as Bitcoin
It know longest SC b/c it is same as every bitcoin client can verify

 and is unlocking bitcoins in MC by signing bitcoin transaction in MC.

?

maybe i can answer my own question.  once someone holds scBTC, they can transact just like they would with BTC except being able to take advantage of faster tx and anonymity be it online or p2p.  my question is that these same scBTC can be traded with other scBTC holders.  i suppose that could be p2p as well but if done on a centralized exchange that doesn't advance our anonymity desires.  which is what i was getting at to address your question about how a SC may or may not be analogous to mtgox.

Now this new SC is same as original Bitcoin + has native support for new signatures (SPV, SNARK ...) -> new version of bitcoin.
Now inside this SC, it is possible to create new SCs (eg fastWallet, exchanges, ...)

you don't mean another second SC for fastWallet and exchanges, do you?  b/c i would consider that a disadvantage as that would mean BTC would have to traverse 2 separate SPV proofs with contest/confirmation periods in order to get to 2nd SC which would increase risk of escaping SC's in general in an emergency due to time delays and technical failures. 

i would hope fastWallet exchanges  would be decentralized and anonymous and exist on the 1st SC away from Bitcoin. 

I think I'll not need create more oracles inside SC b/c bitcoinSC may support it. I'm not sure. I have to go for now.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 04:13:40 PM
 #16133

spv proof

I can tell you only what is in whitepaper. (crystal clear)
Quote
"We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ),
which we consider to be of independent interest as a new type of group signature"

This new signature can be verified by Bitcoin ... or for begging  oracle can verify DMMS  and if is valid  then oracle will sign Bitcoin multi-signature transaction.

yes, but that's for getting BTC--->scBTC.  how does scBTC get exchanged while on SC other than simply by localtrading p2p w/o centralizing it?

No oracle is on SC and oracle check SC.
It is same chain as Bitcoin
It know longest SC b/c it is same as every bitcoin client can verify

 and is unlocking bitcoins in MC by signing bitcoin transaction in MC.

?

maybe i can answer my own question.  once someone holds scBTC, they can transact just like they would with BTC except being able to take advantage of faster tx and anonymity be it online or p2p.  my question is that these same scBTC can be traded with other scBTC holders.  i suppose that could be p2p as well but if done on a centralized exchange that doesn't advance our anonymity desires.  which is what i was getting at to address your question about how a SC may or may not be analogous to mtgox.

Now this new SC is same as original Bitcoin + has native support for new signatures (SPV, SNARK ...) -> new version of bitcoin.
Now inside this SC, it is possible to create new SCs (eg fastWallet, exchanges, ...)

you don't mean another second SC for fastWallet and exchanges, do you?  b/c i would consider that a disadvantage as that would mean BTC would have to traverse 2 separate SPV proofs with contest/confirmation periods in order to get to 2nd SC which would increase risk of escaping SC's in general in an emergency due to time delays and technical failures.  

i would hope fastWallet exchanges  would be decentralized and anonymous and exist on the 1st SC away from Bitcoin.  

I think I'll not need create more oracles inside SC b/c bitcoinSC may support it. I'm not sure. I have to go for now.

i sure love your imagination with these things.  it's so much more imaginative and mind expanding than some others around here.

i agree with you. there are going to be billions of these things!
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
November 07, 2014, 04:41:29 PM
 #16134

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

http://bitcoin.stackexchange.com/a/1288
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
November 07, 2014, 04:46:56 PM
 #16135

it's starting already.

Truthcoin, enabled by SC's!

http://www.truthcoin.info/

Fortunately Truthcoin is being proposed as a sort of spin-off if it can't be done as a sidechain. Paul Sztorc recognizes that an altcoin or alternative store of value is a terrible idea.

What if he launched it ala Counterparty, as an unmined sidechain that rides on Bitcoin and has no other tokens than the pegged ones?
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
November 07, 2014, 04:51:48 PM
 #16136

This is because successful sidechains would allow Bitcoin transactions to be disconnected from Bitcoin miners.

Interesting read but considering this is the premise of your scenario I have no choice but to disagree with your conclusions.

Txs fees are not escaping Bitcoin miners. As I've explained in another post, instead of miners sharing a % of the same pie, the txs fees are now split into different slices which are all available for miners to MM.

The point is that there'd be too little money paid for mining Bitcoin. Sure miners could continue to get paid, but not for mining Bitcoin. I don't think "oh yeah you can also merge-mine Bitcoin for a small extra profit" is a robust enough incentive.
NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
November 07, 2014, 05:10:14 PM
 #16137

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.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
November 07, 2014, 05:17:27 PM
 #16138

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.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
November 07, 2014, 05:32:53 PM
 #16139

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:

Quote from: Peter Todd (emphasis mine)
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 :

Quote from: Peter Todd
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
Legendary
*
Offline Offline

Activity: 1153


View Profile
November 07, 2014, 05:56:36 PM
 #16140

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.
Pages: « 1 ... 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 [807] 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 ... 1558 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!