Bitcoin Forum
November 22, 2017, 01:36:26 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   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 ... 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 [966] 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2011353 times)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
January 01, 2015, 09:23:27 PM
 #19301

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.
1511357786
Hero Member
*
Offline Offline

Posts: 1511357786

View Profile Personal Message (Offline)

Ignore
1511357786
Reply with quote  #2

1511357786
Report to moderator
1511357786
Hero Member
*
Offline Offline

Posts: 1511357786

View Profile Personal Message (Offline)

Ignore
1511357786
Reply with quote  #2

1511357786
Report to moderator
1511357786
Hero Member
*
Offline Offline

Posts: 1511357786

View Profile Personal Message (Offline)

Ignore
1511357786
Reply with quote  #2

1511357786
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440


View Profile
January 01, 2015, 09:26:14 PM
 #19302

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

co-founder, Monetas
creator, Open-Transactions
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 09:29:51 PM
 #19303

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

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
January 01, 2015, 09:35:24 PM
 #19304


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


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

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

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

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

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

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 01, 2015, 09:37:20 PM
 #19305

Adam,

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

Activity: 1764



View Profile
January 01, 2015, 09:42:49 PM
 #19306

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

first off, usually they mean Bitcoin economic fundamentals.

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

Activity: 2324


View Profile
January 01, 2015, 09:48:35 PM
 #19307

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

  "Bitcoin mining will always approach non-profitability due to unlimited supply."
What is this, econ 101?

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

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

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

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

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


cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736

Let's talk governance, lipstick, and pigs.


View Profile
January 01, 2015, 10:12:46 PM
 #19308

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

  "Bitcoin mining will always approach non-profitability due to unlimited supply."
What is this, econ 101?

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

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

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

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

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


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

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 10:56:54 PM
 #19309

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

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

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

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

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

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
January 01, 2015, 11:06:26 PM
 #19310

One problem we face is it seems blockchains are inherently more expensive (bandwidth, latency, convergence time) at the limit that server clusters like Voting Pools for OpenTransactions and other related ideas.  That might encourage people to not take up full bitcoin features if those systems turn out not to be able to match the features quite due to less decentralisation.
Blockchains are inherently more expensive in terms of resource consumption than other solutions. On the other hand, they offer additional features which the less expensive options can't provide.

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

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

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

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

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

Activity: 1218


View Profile
January 01, 2015, 11:12:03 PM
 #19311

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

Rusty Russell? The creator of iptables/netfilter?

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

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
January 01, 2015, 11:12:52 PM
 #19312

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

first off, usually they mean Bitcoin economic fundamentals.

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

"Bitcoin is NOT broken" and nobody want to break it.

I don't understand why do you try to fight the wind. Everybody can spend his money for things he wish.

 - people burn bitcoins in Counterparty address
 - people bought Ethers -> they sent bitcoins (worth millions of $) to vitalik address
 - and people will send money to other sidechain addresses .. especially when they can control them and withdraw back.

It really is not your problem what SC will do and how many SCs will exist (it is same as nobody have to ask you for permissions to buy bitcoin). There is record in MC that some address hold some amount of bitcoins. (there is not difference between your address and SC address)  => It is as simple as possible and nothing has changed for you as an investor. ( you would send tip to Blockstream b/c they made bitcoin more useful)  ...

:-)
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 11:13:43 PM
 #19313

Blockstream and Monetas are essentially competitors, no?

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 welcome Blockstream's entry into this space and I think alt-coins are the ones most concerned about what they represent.

Yup what fellowtraveller said.  I personally am happy to donate time or code to OpenTransactions and may get time to do it sometime, its sort of on my todo list.  (They have some fun possibility to use things like Chaum ecash and Brands attribute certs and ecash and I have a library that does that).

Quote from: fellowtraveller
The reason Monetas contracted Justus to help us build the voting pools is because he is a Bitcoin purist. Justus keeps us honest. And I think that is the same role he is playing here in this thread. Bitcoin is his highest value.

Yeah I've talked to Justus in person a little if he recalls, and also watched his presentation at one of the conferences as well as a video of a OpenTransactions security model presentation he did etc.  I know he thinks in terms of bitcoin ethos so thats logic I grok.

Quote from: fellowtraveller
And I think what Justus is saying is, that a framework needs to be developed for any changes to Bitcoin. I think he's right that it's not good enough for changes merely to be "open source, open IP." There is a potential conflict of interest, and there is an easy way to put any concerns to rest.

Justus said it best:

Quote
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 really don't think that's much to ask. Do you, Adam?

sounds good to me, and you shouldnt interpret our intent to be anything otherwise, the thread is pretty long but I said eg

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9998261#msg9998261
I think the bigger picture though is its premature - we have not yet released code, nor BIP draft for community discussion and picking apart and redesigning etc before there is something to merge mine.  Its also useful (maybe you said it yourself also I think) for a federated peg to operate for a while in parallel with that open design discussion for people to see how it works.  You can view the federated peg as a protocol adaptor - there can still be mining occuring on the sidechain with the federated peg, just the return peg is translated into a multisig for bitcoin by the federation servers.

After that if the community can settle on a op-code for extensibility everyone is happy with people including us can try to stand up a few sidechains.  If no one likes them then they wont get mined.  So as you can see sidechains and the op_spv really depend on community and economic majority approval, and thats a good thing.

Quote from: fellowtraveller
[kind words] And I know Justus can be blunt; Adam has been very graceful in this thread.

Thanks for the kind words.  You're doing cool stuff also and thanks for the demo a while back I as pleased I managed to find you at the massive San Jose conference.

Dont worry about Justus we get along just fine - its all in good humor, like I said when someone flamed him on this thread:

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9998088#msg9998088
Nah Justus is the good guy.  He just flames a little, so what.

Quote from: fellowtraveller
Yet it is true that Monetas is not asking for any forks in the Bitcoin protocol. Blockstream is. That's why these questions are being raised.

Yeah actually I said to Justus I wasnt really asking about Monetas funding for that exact reason, just replaying his questions to him to illustrate for him so he could think go through the analogous mental exercise of answering his own questions from with a Monetas hat on.

Quote from: fellowtraveller
There is an easy way to put them to rest.

trust me the discussion hasnt even started... wait until there's a proof of concept code and draft BIP for people to suggest redesigns of.  This'll be an interesting and very open public discussion and community discussion.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 11:31:20 PM
 #19314

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. 

Doesnt bitcoin's SOV get helped by more demand for bitcoin arising from more types of transactions (eg share trades, zerocash transactions, snark contracts, micropayments, richer contract language etc)?  Most people seem pretty ecstatic about sidechains for that kind of reason, bringing innovation back to bitcoin rather than in altcoins or featurecoins or altshares.  Maybe one analogy would be say with gold if there was some law mandating you cant use it below some value, and you cant do more than so much trade, and you cant use it for property transactions only cash trades - that might have dented golds 6000 rule as a world currency no?

Btw random question, I was meaning to ask with aethereum?  Would a sidechain be a better way to make the point to ethereum that their value isnt in the feature that can be forked, but in cryptocurrencies network effect.  ps I thought aethereum was awesome Smiley except that if I recall it would float from bitcoin so not by quite bitcoin denominated.  Bitcoin users had a perpetual right to claim their share of the coins right?

Quote from: Peter R
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. 

Yeah I'm not disagreeing other than to suggest you maybe want to take it easy increasing it, eg do it a little and then do more later and monitor the situation.

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

Its probably fair to say you want to support both because a sidechain is also a different security formula.  However I think you acknowledge there are centralisation risks so that'd have to be balanced.  If both were done we could see where users were willing to put transactions.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
smooth
Legendary
*
Offline Offline

Activity: 1596



View Profile
January 01, 2015, 11:35:08 PM
 #19315

Btw random question, I was meaning to ask with aethereum?  Would a sidechain be a better way to make the point to ethereum that their value isnt in the feature that can be forked, but in cryptocurrencies network effect.  ps I thought aethereum was awesome Smiley except that if I recall it would float from bitcoin so not by quite bitcoin denominated.  Bitcoin users had a perpetual right to claim their share of the coins right?

There was some discussion about the practical compromises of a perpetual right vs a limited (but not short) term right.

It is an interesting distinction, though, to compare the one-time right to redeem (spinoff) vs a perpetual right to bidirectionally convert (side chain).

adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 11:40:37 PM
 #19316

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

Rusty Russell? The creator of iptables/netfilter?

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

Ayup the one and same.  He has a video up about pettycoin chain sharding https://www.youtube.com/watch?v=yzst_gChOr8.

btw that is a kind of (non-pegged) sidechain and you hear him talking about a gateway or federated gateway.  That is like a federated peg.  (Yeah he knows its related, he's hanging out on #bitcoin-wizards and discussing pettycoin design with GMaxwell and others).

(Pettycoin is a micropayment network bitcoin auxiliary chain aiming at scaling to 100k tx/sec.)

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 11:48:26 PM
 #19317

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

There we go, thats the cypherpdoc we know Smiley  But seriously I wrote several hundred lines on this topic, so it'd be helpful if you have something specific you can point about what i've said that you dont find convincing, it'll make it easier for me to comment.

I wrote a bit about why the op_spv is not proprietary or specific to blockstream and that idea existed before blockstream the company existed.  Feel free to pick it apart or disagree with something specific, here are some quotes and links from this thread:

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9988763#msg9988763
Its not our softfork - its a softfork to enable a generic extension mechanism.  We have no monopoly (and wouldnt want one) on use of the op code.  Our only defence is meritocracy - if we build better, more secure sidechains and people prefer to use them.  We wont be getting the fees off the sidechain either because those go to miners.  If we have the technical edge and people use our stuff that seems sort of fair enough to me.

(and the rest of that post follow the link).

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9991720#msg9991720
Sidechains are not a proprietary technology.  Everything is FOSS, open IP.  [...]

Its not our softfork - its a softfork to enable a generic extension mechanism.  We have no monopoly (and wouldnt want one) on use of the op code.  Our only defence is meritocracy - if we build better, more secure sidechains and people prefer to use them.  We wont be getting the fees off the sidechain either because those go to miners.  If we have the technical edge and people use our stuff that seems sort of fair enough to me.  [...]

Sidechains are just a mechanism to extend bitcoin.  The interesting thing is the extension not the chain.  If a better way to do it materialises great.  If some sidechain innovations are so cool and well validated from $1b resting on them for a year that it allows bitcoin core to merge them fantastic.  Actually Pieter Wuille views that as the best way to view the utility of sidechains, to enable longer and live validation of things that could then go into bitcoin where that'd be difficult to impossible to gain that confidence on directly.

There can also however be one-size fits-all limits.  Some extensions are mutually incompatible, or too risky though interesting (eg snark contracts, zerocash) unless a way to contain the risk in chain is found.  Also you can get some new scaling possibilities by having chains with different blocksizes.  Its more decentralised and safer to have a small bitcoin main block and a medium sized sidechain block, than introduce a large main bitcoin block as there is an escape route and choice.  You can within limits get your cake and eat it.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9994182#msg9994182
Sidechains may also be good for that - an escape valve - people who want to do crazy stuff, can go do it in a sidechain, that no one (who cares about bitcoin ethos features) would use.  Vs try to coerce legally or otherwise developers into subverting bitcoin itself at its core where there's no choice left, and bitcoin risks destruction.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9994308#msg9994308
For conflict freedom to occur (and I think its an interesting and useful objective) bitcoin perhaps needs to be simplified and frozen, maybe moved to a formally provable specification rather than code as definition.  Soft-forks could be prevented by consensus rule if we were convinced of perfect correctness. 

Hard-forks are harder to foist on people because they require a near absolute majority whereas soft-forks are a bit more miner influenceable.

If we had an extension mechanism that doesnt touch core once setup, the core becomes that bit closer to freezable & formal specifiable refactor becoming possible.  If we have the possibility for live-betas we are more likely to be able to get to formal specification as definition.  (Thats a hard-fork for sure).

Another aspect of conflict freedom (other than freezing and forcing change to be hard-fork) is to enable permissionless innovation - then there's no conflict, people who want to try things can go try them without lobbying for changes to bitcoin.  Also good.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9998261#msg9998261
I think the bigger picture though is its premature - we have not yet released code, nor BIP draft for community discussion and picking apart and redesigning etc before there is something to merge mine.  Its also useful (maybe you said it yourself also I think) for a federated peg to operate for a while in parallel with that open design discussion for people to see how it works.  You can view the federated peg as a protocol adaptor - there can still be mining occuring on the sidechain with the federated peg, just the return peg is translated into a multisig for bitcoin by the federation servers.

After that if the community can settle on a op-code for extensibility everyone is happy with people including us can try to stand up a few sidechains.  If no one likes them then they wont get mined.  So as you can see sidechains and the op_spv really depend on community and economic majority approval, and thats a good thing.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg10001181#msg10001181
I dont think one can characterise the op_spv is to the disadvantage of blockstream competitors.  Its an op code, anyone can use it to make sidechains or other things. 

Other things: you can also use the op_spv opcode to enhance security and efficiency for SPV clients like smartphone wallets completely separately from sidechains.  And to fast catchup headers also, the compact SPV proof is work-preserving.

If for example OpenTransactions sees a use for it, or ethereum wants to switch out ethers for bitcoin (i imagine the developers are attached to their premine for now) but perhaps Mastercoin or something thats market cap is falling, seeing less use and the ICO people probably mostly dumped by now (if thats a fair characterisation, dont follow it closely) maybe they might want to migrate to a sidechain, thats all expected and good.  Permisionless innovation is the point of sidechains.  You could even one-way peg the remaining mastercoins into a sidechain to allow their residual tradability.

If you mean it allows bitcoin to more easily incorporate features, well most alts dont really have features, or not meaningful or useful/non-broken ones, but there are some feature coins and bitcoin 2.0ish coins that do.  I dont see how extending bitcoin is unfair - they're all leeching off and copying bitcoin, which was the actual innovation - why cant bitcoin take little bits of innovation back too?

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg10001937#msg10001937
Another way to look at sidechains btw is that a federated peg is a multi-sig (with modest parameters eg 5 of 10 and some trustworthy security competent bitcoin interested businesses) and a SPV peg is a bigger federated peg with a 5000 of 10000 multisig with dynamic membership (ie whoever is mining the chain right now).  The spv peg op_code is an opcode to understand those dynamic membership multisigs.  The dynamic membership multi sigs (DMMS for short) are written about in the sidechain white paper http://www.blockstream.com/sidechains.pdf and are a different way to look at bitcoin mining, though its actually the same thing.

You can also combine DMMS sigs with regular multisigs, its just an op code so you can program with it.  eg IF ( 0.5*DMMS + 0.5*multisig(5,10) ) THEN spend coin.  Or IF ( hashrate > 75% AND DMMS ) OR ( hashrate <= 75% AND multisig(5,10) ) THEN spend coin can react to hashrate drops.  Different people could even use different peg rules on the same chain depending on their security tradoff preferences.

I dont see that as some how evil or dangerous relating to offchain transactions (we've seen them cause system shocks mtgox etc) or federated pegs or voting pools (then you are depending on the 5 of 10 of their security etc its better but its still non-zero risk) ... its just the next evolution in that direction - more decentralised, more things enforced by the network.  For example read Nick Szabo's recent blog post about fiduciary code http://unenumerated.blogspot.com/2014/12/the-dawn-of-trustworthy-computing.html what do you think he's talking about?

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 11:53:01 PM
 #19318

i mean, look, we have unencumbered BTC units traveling freely on an ultra secure blockchain whose value involves no counterparty and no other asset.

now, you're asking us to accept an unprecedented change to the protocol which will allow BTC units to intermingle with all sorts of assets limited only by our imaginations all while traveling on a less secure SC.  

We havent actually proposed anything concrete yet, but we expect to with code and a BIP for a op code to do something that is nearly or maybe actually possible already just less efficiently.

The alternative is offchain transactions which are impossible to stop, constitute probably 90% of bitcoin transactions, and remove fees from bitcoin network, and result in an ongoing economic impact when exchanges and other startups with custody of other peoples bitcoins get hacked, get "hacked" or steal them, get them frozen, deleted by accident etc.

That seems like a step forward to me.  Its an op_code.  We dont "own" the op code.  Anyone can use it to write any scripts they can cook up, to do with audit of sidechains or other users they may find.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 02, 2015, 12:01:46 AM
 #19319

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

There we go, thats the cypherpdoc we know Smiley 

actually, i'm quite serious.  let me rephrase the exact same concept.  we can let those guys insert an op_code of their choice which will be open source.  it will therefore be usable by anyone and not owned by them.  ppl will be free to ignore it by choice, therefore it can cause no harm.  just like your spvp.  why would you want to "prevent" them from doing that?
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
January 02, 2015, 12:05:27 AM
 #19320

... we can let those guys insert an op_code ...

Do you know how many op_codes bitcoin already supports and what they do ?

https://en.bitcoin.it/wiki/Script
Pages: « 1 ... 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 [966] 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 ... 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!