Bitcoin Forum
December 05, 2016, 04:50:06 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1804656 times)
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 02:45:00 AM
 #19301

ps the correct response
Is that you're still not off the hook.

You've acknowledged that Blockstream is trying to change the protocol.

You've acknowledged that other companies which are not trying to change the protocol aren't subject to the same levels of legitimate scrutiny as those which are.

Agreed.  But you're also not completely off the hook.  There are also economic implications from offchain and voting-pools version of offchain.  People also have a right to ask about that similarly.  There are actually economic implications.  If OpenTransactions sucks a bunch of transactions off-chain that deprives bitcoin of transaction fees, and so it lowers bitcoin security.  I am not saying this is a bad tradeoff, just point out that nothing is free of implications.

Quote from: justusranvier
You haven't given a better answer than "trust us to to the right thing" for why Bitcoin users shouldn't be concerned about your plans for the protocol.

You did see this reply?  https://bitcointalk.org/index.php?topic=68655.msg9997546#msg9997546

Quote
Which basically means we're at the same point today we were this morning, and at the months leading up to today, and where I expect things will remain for the foreseeable future.

Was that really called for?  I am trying to be responsive here...

I said its a very valid question.  I tried several times to answer.  Feel free to pick apart the answer but dont just say I didnt answer, or I cant really reply short of reiterating as I wont know what it is you found unclear or unconvincing about the argument.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
1480956606
Hero Member
*
Offline Offline

Posts: 1480956606

View Profile Personal Message (Offline)

Ignore
1480956606
Reply with quote  #2

1480956606
Report to moderator
1480956606
Hero Member
*
Offline Offline

Posts: 1480956606

View Profile Personal Message (Offline)

Ignore
1480956606
Reply with quote  #2

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

Posts: 1480956606

View Profile Personal Message (Offline)

Ignore
1480956606
Reply with quote  #2

1480956606
Report to moderator
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 01, 2015, 02:50:43 AM
 #19302

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.  

serious question.  what kind of revolutionary tech, ie spvp, relies on "convincing" an entire industry called "mining" to support and secure itself?  b/c in the absence of close to 100% MM'ing support, i see SC's failing miserably from attacks.  there is no way you'll get 100% of miners to MM one, let alone dozens of SC's.  that's a huge risk.

Well there is the federated peg that doesnt need miner support.  There is the one way peg that also doesnt (but is more limited than 2wp).  And also most of the miners we've talked to informally seemed pretty keen on the idea.

I mean for example namecoin gets a pretty high Merge Mine rate and thats not really actively used even.  Mining profits are quite thin right now with difficulty reaching equilibrium for the price range so another percent or two makes all the difference.  I got the idea they were also interested in future potential for more transactions and more types of transactions as they considered this a source of bitcoin price upside, and they are mining bitcoins and living off the margin.

Plus a price uptick is a big deal to current miners, its a kind of derivative on bitcoin price.  They get to cash in for 3months at a higher price with too low difficulty until the manufacturers can ramp new manufacturing pipelines and get lots of new equipment to market.

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.

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, 02:57:26 AM
 #19303

Agreed.  But you're also not completely off the hook.  There are also economic implications from offchain and voting-pools version of offchain.  People also have a right to ask about that similarly.  There are actually economic implications.  If OpenTransactions sucks a bunch of transactions off-chain that deprives bitcoin of transaction fees, and so it lowers bitcoin security.  I am not saying this is a bad tradeoff, just point out that nothing is free of implications.
Fair enough.

It is true that if Open-Transactions could be use to transact in Bitcoin substitutes, and that would suck fee revenue away from Bitcoin.

It is also true that outcome is 100% avoidable.

The only reason OT would suck transaction fee revenue away from Bitcoin is if the Bitcoin blockchain is forbidden for processing those transaction.

If Bitcoin won't process the transactions, they'll be processed somewhere else.

It's up to the core developers and Bitcoin community at large whether or not OT ends up sucking fee revenue away from Bitcoin mining.

I'm not a core developer, so I can't stop them from making changes to Bitcoin that would increase the blockchain's transaction processing capability.

In fact, it would be extremely out of character for me to even argue against such a change given that I've spent three years arguing for more transactions to happen on chain, to the point of saying that's the only way Bitcoin can economically survive in the long term.

It's also a perfectly viable future for OT to handle financial instrument contracts (BTC-denominated and otherwise) that aren't appropriate for the blockchain anyway while leaving all monetary transactions to the blockchain. It might even be the case that a high percentage of OT transactions end up causing a blockchain transaction anyway so that OT transaction volume helps drives Bitcoin transaction volume.

But if real monetary transactions aren't allowed to happen on the Bitcoin blockchain, then Bitcoin substitutes will trade in OT.



As far as the voting pool concept itself goes, I've always thought (and said many times) that people shouldn't leave their Bitcoins in the custody of a third party such as an exchange.

However, since they're going to do it anyway no matter how many times I say that you don't own Bitcoins if you don't control the private key, and since I'm tired of seeing people lose money to incompetent and/or corrupt exchanges, I guess I have to fix the exchanges.
davec
Jr. Member
*
Offline Offline

Activity: 39


View Profile
January 01, 2015, 03:34:48 AM
 #19304

Oh boy, thats another can of worms.  You dont happen to work for conformal do you btw?

So (it a long story) but a) no one knows who's funding them; b) most of them seem to have ex-defence contractor profiles; c) no one knows why they are coding it; d) if there is one off by even a single bit interpretation bug in it it breaks consensus and forks bitcoin, which can likely be systematically abused, to create a massive accounting/double-spend mess that will be too expensive to repair as last time - that could create a mega fork worse than the leveldb bug, and kill bitcoin or force some really harsh choices to best effort cleanup where there are innocent losers; e) it apparently took a lot of effort by the core devs to persuade them that this was a problem; f) it still has that problem.

I think that about covers it.

Adam

Thanks for your response.  Yes, I'm the lead dev on btcd.

a and b) First, both of these are completely irrelevant.  No one knows who Satoshi was/is, yet that isn't a problem for Bitcoin Core.  So, even if every single contributor were unknown (they're not as you can find the names of every contributor on github), why would it be a problem for btcd when it isn't for Bitcoin Core?  Second, the defense bit is not true, but even if it were though, I'd venture to say with the number of contributors on Bitcoin Core, at least one or more have affiliations in one way or another with some organization that you, or somebody else, doesn't like.  The code is completely open for all to see, so it would be obvious to see if something nefarious were going on as you are implying.

c) It has been publicly stated many, many times that it is being coded because the ecosystem severely needs multiple diverse implementations if Bitcoin is ever going to truly flourish to the level we all want it to.  Thinking that a single implementation controlled by a handful of people is a good scheme for a system that is supposed to take over the World's monetary supply is just not very forward thinking.  This has been covered ad naseum.

d) This is a complete red herring and exists just as much with Bitcoin Core as it does with anything else.  The exact same thing can easily happen (and already has as you've noted) with Bitcoin Core.  This is a real problem with the technology that needs to be solved independent of the number of implementations on the network.  In fact, working toward solutions which address this fundamental issue is necessary for Bitcoin Core too since it means mistakes there don't lead to undesirable consequences either.  The current approach is "well let's just hope it doesn't happen!" and frankly, that just isn't good enough.

e) You've been misinformed.  Here is a blog post I made on the very first package we released back in May of 2013 which was only the wire protocol that clearly states "Here at Conformal, we are keenly aware of how important it is that any full-node implementations agree on the exact same set of rules for what blocks get included into the block chain as minor differences can lead to chain forks and double-spends." (https://blog.conformal.com/btcwire-the-bitcoin-wire-protocol-package-from-btcd/).  The Bitcoin Core devs weren't even aware we were working on the project at that point in time.  There was no "convincing" needed or involved.

f) This is referring to d and e, see those.
JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 868



View Profile
January 01, 2015, 03:44:05 AM
 #19305

Yeah that is kind of logical, there are some caveats.  The miner has a lot of capital invested maybe > $300m to do that now.  (You can be sure most pool miners would abandon a pool that did that.)
I am not so sure... If the change to the protocol means not having their revenue cut 50%, I bet that most miners, even those who are not in the cartel, would eagerly support it.

Merchants who "accept bitcoin" would not care and would not take sides, since they receive dollars and, at worst, may lose some customers if bitcoin collapses.  Payment processors, exchanges, and the like would have to choose a side, but since siding against the cartel could mean losing their income for months, they will probably upgrade before the deadline; and that will force their clients to upgrade, either before the deadline or before accessing their services again.  Note that, up to the deadline, users and miners who choose to upgrade will continue to interoperate with those who don't.

I seems that when people discuss a 51% attack they assume some entity that wants to either destroy bitcoin, or pull some quick scam (like double-spending) and run away.  But cartels usually employ their power to maximize net revenue over the long run, and are careful not to kill their cash cow.

Quote
This is going to be disruptive to bitcoin confidence and price and that affects the value of bitcoins they are mining, or the equipment itself which is worthless if bitcoin fails or crashes badly as a result.  Dangerous game to play with a $300m good behaviour bond.
At the current BTC price, the change I described would mean 600 k$/day for 2 years for the whole network, which is ~440 M$.  If the cartel has >50% of the power, that means >220 M$ of extra revenue just for the cartel.

Depending of their costs, that could mean the difference between making 100 M$ profit (say) if they try and succeed, or having to turn off their equipment and lose all their capital, as a reward for their "good behavior", if they do nothing.   At worst, if they try and fail, they will lose only a few weeks of revenue; and from then on they would get the same "reward" they would get if they did nothing.

Moreover, I don't believe that many people would want to leave bitcoin just because of that change.  Not even the long-term holders should change their minds about bitcoin's future because of a change to a parameter that was clearly chosen quite arbitrarily.  (People in countries with high inflation or bank deposit haircuts do not stop accepting their currency; they just try to spend it as fast as they can, or convert it to investments that are resistant to inflation.) The price may even go up, if the change is properly marketed as preserving the network's unique strength etc.

Quote
Secondly while they are DoSing bitcoin, they are not mining coins nor on their proposed alternative chain at any kind of usable speed as they have almost no hashpower left (if they have 55% and they're using 53% to DoS bitcoin that gives them 500min blocks if the new chain has the same difficulty.  If the new chain has reset difficulty the honest miners might DoS it in retaliation (block transactions there).  Now if the attacker had maybe 70% they could dominate both chains reliably.
The cartel would have to change the difficulty level and the difficulty adjustment algorithm to keep the new chain flowing at an acceptable rate during the transition period.   The cartel can move its power back and forth between the two chains, according to what the non-cartel miners are doing, in order to always have 51% of cooperating hashpower on both chains.  As noted above, most of the non-cartel miners would have strong incentive to cooperate with the cartel, and upgrade to the cartel's protocol, before  the deadline; they would then put any rebel miners at an even bigger disadvantage.

Quote
This is beyond mining a new hard-fork protocol version (which honest users and full nodes would ignore) and more DoS warfare to kill the main chain to give users a choice of no transactions or to fold and use the new chain.  I would imagine users would be annoyed enough about that so as to be a scenario where the bit red button might get pushed - destroying the $300m capital of the attacker (and the $245m of the rest of the miners who probably are going to sue the attacker, and its not easy to hide the delivery and location of $300m worth of mining equipment drawing perhaps a GW of power.)

I still do not understand what sort of "big red button" could do that.  Changing the protocol to make the ASICS useless would force any remaining rebel miners to give in to the cartel, and would require that the rebel users upgrade to a different protocol (which is supposed to be a catastrophe) leaving them on a junk coin with a minuscule network, no service infrastructure, and a minority of the former users.  But they would still have the option to upgrade to the cartel protocol and find all their coins waiting for them in the cartel chain, apart from any transactions that they made in the junk chain after the deadline.

Quote
Quote
Why wouldn't Bitstamp be already a sidechain, for example?
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?


Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
fellowtraveler
Sr. Member
****
Offline Offline

Activity: 440


View Profile
January 01, 2015, 06:53:41 AM
 #19306

Blockstream and Monetas are essentially competitors, no?

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

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

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

I welcome Blockstream's entry into this space and I think alt-coins are the ones most concerned about what they represent.

------------------------------------------

re: Justus, Adam Back

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.

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?

I think Adam is a good guy with good intentions. Certainly he deserves respect -- he has earned it. All around. He's a brilliant guy and he's been working for good for a long time. We all owe him our thanks at the very least for his invention of hashcash, his work at Zero Knowledge, etc. And I know Justus can be blunt; Adam has been very graceful in this thread.

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. There is an easy way to put them to rest.

co-founder, Monetas
creator, Open-Transactions
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
January 01, 2015, 07:20:08 AM
 #19307

Agreed.  But you're also not completely off the hook.  There are also economic implications from offchain and voting-pools version of offchain.  People also have a right to ask about that similarly.  There are actually economic implications.  If OpenTransactions sucks a bunch of transactions off-chain that deprives bitcoin of transaction fees, and so it lowers bitcoin security.  I am not saying this is a bad tradeoff, just point out that nothing is free of implications.

I dunno, it seems part of the bitcoin social contract is to be deliberately (and ideally enforceably) agnostic about what people do with their bitcoins. It that means sending them to some crazy off-chain system with voting pools or whatever other silly idea, so be it. How is that anyone's business any more than spending them on wikileaks donations?

If bitcoin can't handle people doing crazy things off chain like voting pools or MtGox, then it has some pretty big problems. It seems fairly proven that it can survive MtGox at least.

This includes the so-called federated model of sidechains.

I still see a gargantuan difference between that and changing the protocol.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 01, 2015, 09:00:13 AM
 #19308

Agreed.  But you're also not completely off the hook.  There are also economic implications from offchain and voting-pools version of offchain.  People also have a right to ask about that similarly.  There are actually economic implications.  If OpenTransactions sucks a bunch of transactions off-chain that deprives bitcoin of transaction fees, and so it lowers bitcoin security.  I am not saying this is a bad tradeoff, just point out that nothing is free of implications.

I dunno, it seems part of the bitcoin social contract is to be deliberately (and ideally enforceably) agnostic about what people do with their bitcoins. It that means sending them to some crazy off-chain system with voting pools or whatever other silly idea, so be it. How is that anyone's business any more than spending them on wikileaks donations?

If bitcoin can't handle people doing crazy things off chain like voting pools or MtGox, then it has some pretty big problems. It seems fairly proven that it can survive MtGox at least.

This includes the so-called federated model of sidechains.

I still see a gargantuan difference between that and changing the protocol.



i agree completely.  there's too much FUD being slung around about problems with offchain services.  if anything, it's getting better as in the case of exchanges and wallets.  not perfect, but better esp for the bigger ones.

and who is anyone to restrict where ppl send their BTC?
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
January 01, 2015, 09:29:48 AM
 #19309

re: Justus, Adam Back

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.

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?

I think Adam is a good guy with good intentions. Certainly he deserves respect -- he has earned it. All around. He's a brilliant guy and he's been working for good for a long time. We all owe him our thanks at the very least for his invention of hashcash, his work at Zero Knowledge, etc. And I know Justus can be blunt; Adam has been very graceful in this thread.

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. There is an easy way to put them to rest.
With respect to Bitcoin's development road map versus the world's vast array of financial relationships, in order to receive universal acceptance it usually best to keep language and protocol as simple as possible with enough functionality to serve the majority. Overly complex or superfluous language makes some people suspicious. Projects that offer Turing-complete complexity are empowering, but not always welcome. Having said that, there is nothing stopping meta applications from improving Bitcoin's footprint. In defense of Justus' pit bull defensiveness, sometimes strength of conviction is enough to clear the smoke from a conversation mired in nuance. While I often disagree with him on many things, I admire his brevity and focus.

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, 01:09:20 PM
 #19310

Let me save you some time

"We're not asking to change the sourcecode to the "disadvantage" of competitors ; We don't have core developers on board"

btw (I know you were predicting JustusRanvier) but 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?

Also alt-coins or feature coins can have sidechains off them also for beta versions, or secondary functionality if they were actively developed.

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, 02:56:19 PM
 #19311

Agreed.  But you're also not completely off the hook.  There are also economic implications from offchain and voting-pools version of offchain.  People also have a right to ask about that similarly.  There are actually economic implications.  If OpenTransactions sucks a bunch of transactions off-chain that deprives bitcoin of transaction fees, and so it lowers bitcoin security.  I am not saying this is a bad tradeoff, just point out that nothing is free of implications.

I dunno, it seems part of the bitcoin social contract is to be deliberately (and ideally enforceably) agnostic about what people do with their bitcoins. It that means sending them to some crazy off-chain system with voting pools or whatever other silly idea, so be it. How is that anyone's business any more than spending them on wikileaks donations?

If bitcoin can't handle people doing crazy things off chain like voting pools or MtGox, then it has some pretty big problems. It seems fairly proven that it can survive MtGox at least.

This includes the so-called federated model of sidechains.

I still see a gargantuan difference between that and changing the protocol.

i agree completely.  there's too much FUD being slung around about problems with offchain services.  if anything, it's getting better as in the case of exchanges and wallets.  not perfect, but better esp for the bigger ones.

and who is anyone to restrict where ppl send their BTC?

well seemingly you, for articulated reasons that we're exploring, would like to restrict people from sending their coins to a sidechain.

I agree people should be able to do what they want with their bitcoin and send them where they want.

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?

You complain about incentive, but I talked about the details of that and there are multiple secure and workable parameter choices with usable tradeoffs , and off-chain transactions and voting pools have incentive too - the holder just steals them for free with no effort!!  Thats pure human trust.

Incentive discussion was here
Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9988763#msg9988763
Note also the 51% takes all coins risk depends on the peg script.  Its possible to limit that problem and place the risk on the people doing the arbitrage or transfers by forcing the person returning coins to put up a bounty in main-chain bitcoins equal to the exchange which they forfeit if their transfer is proven fraudulent by a chosen % of the sidechain.  There can also be caps and time-adaptive delays (longer for more bitcoin).  Its a programming language, the op_spv is just an opcode to simplify the coding of one part of it, validating the compact-proofs.

Also for the non-voting pool version the statistics are horrible it used to be that 50% of exchanges that ever existed went down with loss of user funds.  Yes its improving but lets ask you a question: do you store investment amounts of bitcoins on an exchange?  Or a web wallet?  Or an offline/paper wallet with backups?  I imagine you do the latter.

Its also (I said this before on this thread) basically embarrassing that bitcoin is repeating the banking governance failures of the last century and of 2008 etc when the entire point of smart-contracts and programable trust is that users can have direct control of their funds and not have to trust third parties.

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

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, 04:20:06 PM
 #19312

One of the interesting motivations for wanting the extensibility that sidechains provides is to be able to make that zero trust a reality for more bitcoin transaction types.
That would be great, if it was possible. However any given sidechain will always require more trust than the main chain. I don't believe the white paper made the claim that sidechains will be zero trust, did it?

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

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

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

Activity: 1974


View Profile
January 01, 2015, 04:54:43 PM
 #19313

One of the interesting motivations for wanting the extensibility that sidechains provides is to be able to make that zero trust a reality for more bitcoin transaction types.
That would be great, if it was possible. However any given sidechain will always require more trust than the main chain. I don't believe the white paper made the claim that sidechains will be zero trust, did it?

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

That would be a best-case scenario to me (with the caveat that I would accept a modest and simple increase based upon quality forward looking analysis.)

Relatedly, and even more importantly, it would allow Bitcoin core to basically freeze as a codebase.

As an engineer, I appreciate well constructed, well documented, and elegant code.  Also as an engineer, I've lived with utterly shit code (often enough of my own creation) because of priorty and risk profiles, and because it worked for it's intended purpose and was reasonable well understood.

I was a fan of alternate implementations in earlier phases of Bitcoin's existence.  I even provided modest funding to the guy who was dicking around with an erlang implementation/joke.  Times have changed, and a realistic expectation of sidechains are THE main change.  This relegates the need for experimentation and elegance to the dustbin.


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

Likewise, and I think that is a great thing.  This because they are, as best I can tell, experiance professionals many of whom have fought in the trenches on the right side of the historic battles.  Fairly demonstrably so.  To a large degree their instincts and mine seem to align on a lot of fronts and this one in particular.


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

Wrong again Bob.  With sidechains, native Bitcoin is available to anyone who wants to pay what it's worth.  Anyone!  What you want is to model the ubiquitous welfare state structure that abound with plebs being subsidized by powerful institutions who leverage economies of scale to drop their own costs while milking the herd for different kinds of value streams.

What I see sidechains doing is giving everyone the opportunity to enjoy the kinds of freedom that current Bitcoin allows, but in an honest and robust manner rather than in the sneaky subsidized manner that logically must be the end-game when trying to make native Bitcoin be the one-size-fits-all solution under anything remotely resembling the current system of support.


justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
January 01, 2015, 05:07:06 PM
 #19314

Wrong again Bob.  With sidechains, native Bitcoin is available to anyone who wants to pay what it's worth.
That is the opposite of true.

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

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

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

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

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

Activity: 1974


View Profile
January 01, 2015, 05:30:39 PM
 #19315


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

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

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


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

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

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


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 01, 2015, 05:58:42 PM
 #19316

Adam,

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

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

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

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

Activity: 938



View Profile
January 01, 2015, 07:24:03 PM
 #19317

Adam, what are your thoughts on increasing Bitcoin's blocksize limit?  Does Blockstream have a position on this topic?

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

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

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

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

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

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

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

Adam


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

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

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

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
January 01, 2015, 07:53:25 PM
 #19318


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.
tvbcof
Legendary
*
Online Online

Activity: 1974


View Profile
January 01, 2015, 08:00:09 PM
 #19319

Wrong again Bob.  With sidechains, native Bitcoin is available to anyone who wants to pay what it's worth.
That is the opposite of true.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 01, 2015, 08:00:30 PM
 #19320


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.
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 ... 1560 »
  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!