Segregated witness - The solution to Scalability (short term)?

[Carlton Banks]

So, in layman's terms..

They have taken all the script sig data for all the P2SH signatures in a block, and put them in a merkle tree. Only the root hash of that tree is mined into the header.

Then, a week later, way after validation has occurred, you can safely through that merkle tree of data away, BUT still keep all the input/outputs in the blocks, to check that all the numbers add up.

Dunno about laymans terms, but that's pretty good way of summing it up in technical terms! The lay Bitcoiner maybe! Also, I think the P2PKH sigs will end up in the SegWit chain too.

[hdbuck]

new core nodes won't be sending witness data to old nodes.

That old data already does not get validated, so it's redundant to transfer it.

I dunno man, smells fishy.

Not that I understand code as well as devs, still I feel bitcoin protocol should not be 'fixed/improved' to fit external needs.

Besides, USGavin thinks segwit is 'cool'...

So to me it is just yet another attempt at highjacking bitcoin, weakening its protocol and introduce falsification risks.

Sigs are essential and part of the deal for bitcoin to stay strong (ie. valuable).

I am not playing the 'racist card' on the sigs, yet I understand noobs could not care less about it, and would rather have their friggin coffee cups on the blockchain.

salt..

This denigration of signatures represents nothing less than an attack on the primacy of cryptography in cryptocurrency. The blockchain represents a complete and verifiable historical record of every transaction and balance in Bitcoin. Attacking verifiability by lopping off signatures in a misguided effort to cram more transactions into a megabyte. This leaves a eunuch which is no longer the virile Bitcoin we love. As signatures fade into history, cryptographic certainty is replaced by faith and hope.

Ultimately, it is about increasing the number of places where Bitcoin can break and reducing the prominence of cryptography in cryptocurrency.

http://qntra.net/2015/12/after-xt-failure-gavin-andresen-supports-jim-crow-for-signatures-on-the-blockchain/


and pepper... http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/

Now everybody is alining behind this segwit soft fork because its is perceived as 'better than BIP101' basically..

But that is far from being enough, and they still want to twist the holy protocol.

Soft fork is even more pernicious than hard fork because it is more tricky to reject it.

Funny how not even coupla days after announcing this 'new plan' we got this satoshi hoax stealing the attention from it all.

[DooMAD]

and pepper... http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/

Now everybody is alining behind this segwit soft fork because its is perceived as 'better than BIP101' basically..

But that is far from being enough, and they still want to twist the holy protocol.

Soft fork is even more pernicious than hard fork because it is more tricky to reject it.

Funny how not even coupla days after announcing this 'new plan' we got this satoshi hoax stealing the attention from it all.

Can MP just spank his fortune on developing a time machine and piss off back to 2009 already?  If all he's ever going to do is spend the rest of forever bitching and whining every time someone proposes a change, it would be mutually beneficial for all.

[Lauda]

new core nodes won't be sending witness data to old nodes.

That old data already does not get validated, so it's redundant to transfer it.

I dunno man, smells fishy.
-snip-

Until security experts make such statements that is useless speculation. Average users can't really (correctly) tell if there are security risks involved. Let's wait for test net before drawing to conclusions.

[hdbuck]

and pepper... http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/

Now everybody is alining behind this segwit soft fork because its is perceived as 'better than BIP101' basically..

But that is far from being enough, and they still want to twist the holy protocol.

Soft fork is even more pernicious than hard fork because it is more tricky to reject it.

Funny how not even coupla days after announcing this 'new plan' we got this satoshi hoax stealing the attention from it all.

Can MP just spank his fortune on developing a time machine and piss off back to 2009 already?  If all he's ever going to do is spend the rest of forever bitching and whining every time someone proposes a change, it would be mutually beneficial for all.

Bitcoin *is* change.

WTF is this insatiable urge to change it?

Only TPTB really have a motivation for such governance coups, which are to essentially prove there is a central point (of failure) where change can be imposed to all.

Their hard fork failed, now they try at soft forking the cryptography part out of the blockchain.. for moar coffee cups!

[DooMAD]

and pepper... http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/

Now everybody is alining behind this segwit soft fork because its is perceived as 'better than BIP101' basically..

But that is far from being enough, and they still want to twist the holy protocol.

Soft fork is even more pernicious than hard fork because it is more tricky to reject it.

Funny how not even coupla days after announcing this 'new plan' we got this satoshi hoax stealing the attention from it all.

Can MP just spank his fortune on developing a time machine and piss off back to 2009 already?  If all he's ever going to do is spend the rest of forever bitching and whining every time someone proposes a change, it would be mutually beneficial for all.

Bitcoin *is* change.

WTF is this insatiable urge to change it?

Only TPTB really have a motivation for such governance coups, which are to essentially prove there is a central point (of failure) where change can be imposed to all.

Their hard fork failed, now they try at soft forking the cryptography part out of the blockchain.. for moar coffee cups!

If that were true, we'd all still be running 0.1.5 alpha, which he's more than welcome to run if he doesn't like recent developments.  Or better yet, as I keep suggesting, a closed-source coin would suit his motives far better.  He'll never have to worry about change again and we won't have to hear more petulant hissy fits.

[hdbuck]

new core nodes won't be sending witness data to old nodes.

That old data already does not get validated, so it's redundant to transfer it.

I dunno man, smells fishy.
-snip-

Until security experts make such statements that is useless speculation. Average users can't really (correctly) tell if there are security risks involved. Let's wait for test net before drawing to conclusions.

I concur, you seems like an open person, just dont jump off to cheerleading this simply for the sake of an 'improvement'.

Besides, testnets are irrelevant, and experts have already drawn conclusions: http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/#selection-105.0-291.48

"Okay. So I am Pieter Wuille. I'll be talking about segregated witness for Bitcoin. Before I can explain this, I want to give some context. We all know how bitcoin transactions work. Every bitcoin transaction gets inputs, which refer to previous outputs being spent. Every input has the txid and the signature to prove that it is allowed, plus an amount and script in every output. What this presentation will mostly be about is the question of whether all of this data is equally important.

In particular, we are going to be talking about signatures. It's important to realize here that signatures are really only needed for fully-validating nodes. As a light-weight client, you are not validating signatures, even though they are part of the transactions you still have to download them. If you are using a full-node that is syncing historical data, you don't actually validate all of the signatures in there. Currently there is a mechanism in there using checkpoints, which we want to deprecate soon, but the result will still be that we're not validating all signatures from years ago in deep history."

The point here is that non-validating nodes are not nodes. If you decide to buy some Trilema creditsii, the relevant, Bitcoin-related interaction happens at two points : when whatever validating node that holds your Bitcoiniii signs and announces the transaction, and when whatever full node I use sees the announcement and verifies the signature. At no other point and in no other manner is Bitcoin to any degree involved. Not when you use the "SPV Bitcoin Node" that is "your" online wallet ; not when you use the "SPV Bitcoin Node" that is the browser which displays Trilema to you, Mozilla, Chrome, whatever it may be. Not when the "SPV Bitcoin Node" that is your NAT Router or Comcast-owned modem passes the bits back and forth. Bitcoin is something that happens, on the social level, between holders ; and on the technical level between nodives.

The other important point is that the signatures are the only important parts of the transaction. The reference Bitcoin implementation, as released by the Bitcoin Foundation (the real one, not the n-th reboot of Vessennes' original MtGox-promoting, BFL-promoting fraudster den) already ignores most of that crud, and will be removing more of it in the future. This can not be emphasized enough : you can not be building any type of business on any sort of Gavinism, because they will not survive on the middle term. It's not just the Bitcoins, that you would have lost had I not murdered "XT". Everything - every hour you spend "developing" atop the crud USG agents try to stick in Bitcoin is a wasted hour, because the stuff you build upon has the consistency of smoke and the life expectancy of... well, I was going to say ephemerides, but I guess we could just as well say Pieter Wuille.

All the captatio in the world, all the carefully-engineered, plainly USG-Democrat style narrative, all the attentive positioningv is not going to change the simple fact : Bitcoin wants Wuille's head. Follow down the path that got him killed at your own peril.


"These signatures are only needed at time of validation. They don't go into the UTXO set, the database of all unspent coins."

And your dad doesn't go with you to the club. Notwithstanding that the clothes that you're wearing, he bought, and the car you drive or else the ticket for the bus that gets you there - he paid for. The notion that signatures "don't go into the UTXO set" is like the notion that hard work and living within one's means "don't go into WMAGvi". You can see how well that worked for your parents just by looking around : if they didn't buy that nonsense, at the cost of their labour and their lives, you wouldn't have some random gypsy from Eastern Europe decide if you live or die. How's that for captatio ?


"These unspent transaction outputs don't enter into the UTXO set. This is a significant cost on the resources of both keeping a node running but also the speed of propagation and access to the UTXO set needs to be fast. Of all the data in a transaction, signatures don't go into the UTXO set, even though they account for 60% of the blockchain data. Segregated witness is about ignoring this whenever possible."

They of shorter memory than their noses will no doubt have already forgotten the previous attempt at a "soft fork" organized by these same people, affectionately dubbed the Power Rangers. I guess we're supposed to not recall last year, nor any details about how non-validating Chinese miners managed to drag a soft fork in and then not enforce it, causing a netsplit that took a day to heal, the worst since Mike Hearn's deliberate sabotage a coupla years ago.


"The reason for this name is because signatures are not part of the transaction."

Yes, they are. Not only are they part of the transaction, not only are they an integral part of the transaction : they are the only actually needed part. What makes a transaction a transaction is the signature, nothing else. Everything else is like marketing : contributes to costs, not to revenue.


"They don't describe what the transaction is doing."

The attempt to import meaning and state into Bitcoin is the true attack vector here, and particularly pernicious. Review the sad history of XML and HTML standards if you're too young to remember how Erik Naggum died.


"The only thing htey are doing is proving that the transaction is authorized by the previous owners of the coins."

I know, right ?


"There are usually multiple possible valid signature for the same transaction."

This is a major problem, principally driven by the deliberately broken state of the FOSS (and guess who broke it, or are you too new to have read the NSA agent notes from various crypto conferences ?) resulted in braindamage being imported into Bitcoin via openssl. This is to be healed, mostly through removal. What the enemy would desire, of course, is for it to become the baseline, a new normal of sorts upon which further rot to be imported ad infinitum, slowly but surely chipping away at Bitcoin's disruptive capacity. This will not fly.

"We don't really care what the signature is, all we care about is that at least one signature for that existed. Such an example of where something exists is known as a witness."

This is not even wrong.


"We don't care that what it is, well we do for auditing purposes, like in multi-sign setup where you have 1-of-3 people that are able to spend a particular output, perhaps you would really like to know which person signed, which we will solve later. Inside a transaction, you still don't care.
"
This attempt at confounding the problem is the proof that not only is he not even wrong, he knows he's not even wrong, and actively, deliberately trying to cover it up. No, "1-of-3" bullshit has nothing to do with Bitcoin, and is uninteresting in this discussion.


"Wouldn't it be nice to just drop the signatures?"

No.

That's it, and that's all. Please take my money.

[Lauda]

I concur, you seems like an open person, just dont jump off to cheerleading this simply for the sake of an 'improvement'.

Besides, testnets are irrelevant, and experts have already drawn conclusions: http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/#selection-105.0-291.48

You should know better than to call Mircea Popescu a expert. My 4 year old cousin is probably more of an expert than that guy. This is not a security analysis but rather a expression of his opinion with an attack on Pieter included. After so much time, you should have learned not to listen to this guy. He's also very biased regardless of expertise.
I'll wait for a 3rd party to explain why this is bad (if it actually is).

[Cconvert2G36]

salt..

This denigration of signatures represents nothing less than an attack on the primacy of cryptography in cryptocurrency. The blockchain represents a complete and verifiable historical record of every transaction and balance in Bitcoin. Attacking verifiability by lopping off signatures in a misguided effort to cram more transactions into a megabyte. This leaves a eunuch which is no longer the virile Bitcoin we love. As signatures fade into history, cryptographic certainty is replaced by faith and hope.

Ultimately, it is about increasing the number of places where Bitcoin can break and reducing the prominence of cryptography in cryptocurrency.

http://qntra.net/2015/12/after-xt-failure-gavin-andresen-supports-jim-crow-for-signatures-on-the-blockchain/


and pepper... http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/

Is anyone else finding hdbuck's crisis of derived authority rather delicious? 

[Carlton Banks]

new core nodes won't be sending witness data to old nodes.

That old data already does not get validated, so it's redundant to transfer it.

I dunno man, smells fishy.

No, really, that's what happens now. The sigs get kept, but "checkpointed" periodically (which presumably constitutes a hash of some set of the tx data such that it proves bulk sig validity up to the checkpoint), only some few thousands of the most recent sigs actually get individually verified by Bitcoin Core, it's been like that for a while. I can't remember how far apart the checkpoints are spaced, but there's some margin of safety involved. It's just impractical to verify the whole thing for a brand new chain download, at least with OpenSSL doing the verifying (not so in upcoming 0.12, which uses another long term project, the in-house libsecp256k library, which might turn out to be an important crypto library for other software)

Until security experts make such statements that is useless speculation. Average users can't really (correctly) tell if there are security risks involved. Let's wait for test net before drawing to conclusions.

I concur, you seems like an open person, just dont jump off to cheerleading this simply for the sake of an 'improvement'.

You'd probably be surprised at the changes you've not accounted for, although I know you're fairly knowledgeable about how Bitcoin works. You should know that we're not even running 2013 Bitcoin right now, let alone 2010 Bitcoin. And it's better like this, 0.11 is a significant improvement over 2 years ago.

But you're right to have conservative instincts about something that's already valuable as it is; Gavin and Mike have already demonstrated that well-meaning people can be misled to bcak a bonkers "improvement" scheme; I remember your palpable anger when people first started arguing for it publicly, I felt the same.

But I propose that Bitcoin does, can and should be changed over time to make best use of the technological resources available to it, made as available as is economically viable (chain security and decentralisation bound up in that property amongst other parts), and that the 1MB blocks design fulfills that right now (but is becoming seriously stretched also). And so at the risk of sounding slightly too much like VeritAss, I think the will of the overall community will end up alighting on the conservative approach that reflects, because we've demonstrated we're treating changes to Bitcoin very carefully, and so looking carefully at any significant proposals also.

And from what I've seen so far, people like Pieter Wuille are who you want for that conservative engineering task; if you want to abandon the verification checkpoints and scan your blockchain whole, wait till version 0.12, it'll be many, many times quicker (as well as half-way practical). Send your thanks to Pieter. (and gmaxwell)

[johnyj]

Aside from added complexity, there are no downsides (yet).

For me raised level of complexity is the biggest downsides of any change. Typically in an enterprise environment such change will cause huge problem in the test lab where many test case failed due to some strange behavior they have never been designed for

In this case I have asked several questions and it seems no one has been able to give any concrete answer, which is already a dangerous sign, means centralization of knowledge

[johnyj]

What you argue here (as I understand it) is that miners won't be able to 'understand' the SW patch, so they won't run it. I highly doubt both an assertion and a conclusion. I am sure it will be rolled over quite fast. But I have no real proof so we have to wait.

To migrate to a large change in infrastructure, you need to not only understand the solution, but also fully aware of the impact to the existing system and all the other systems that are dependent on them, potential security risk, evaluate its risk/reward ratio, and finally and most important, you should always be able to roll back to the old version if something went wrong

A soft fork qualify the last criteria, but still, from risk/reward point of view, I don't feel it worth the effort given the risk it involves. You change to a new untested architecture, what if after 1 years when majority of the nodes were upgraded to SW and found out that there is a deadly security hole that can not be covered, thus hackers can spend anyone's coin?

Bitcoin's value relies purely on its security model. Existing architecture worth a lot because it is robust and time tested for almost 7 years. It worth a little in the beginning, since there are too many possible security risk to break it apart, thus it must survive the test of time to gain its value. Now if you change to another untested architecture, it will basically reset its value to zero, and take equal long time to establish people's trust

[Lauda]

For me raised level of complexity is the biggest downsides of any change. Typically in an enterprise environment such change will cause huge problem in the test lab where many test case failed due to some strange behavior they have never been designed for

In this case I have asked several questions and it seems no one has been able to give any concrete answer, which is already a dangerous sign, means centralization of knowledge

No, it does not mean that. Obviously when something is so young, the inventors of it are the ones who are going to have all of the knowledge. For everyone else it will take quite some time to fully understand everything. I'm actually not bothered by this complexity and people are way too scared of it. When I program myself, I usually end up solving the problem the complex way without realizing it (it just depends on individuals). Also, just remember that everything about Bitcoin was "complex" to someone at a certain point in their life.

[QuestionAuthority]

What you argue here (as I understand it) is that miners won't be able to 'understand' the SW patch, so they won't run it. I highly doubt both an assertion and a conclusion. I am sure it will be rolled over quite fast. But I have no real proof so we have to wait.

To migrate to a large change in infrastructure, you need to not only understand the solution, but also fully aware of the impact to the existing system and all the other systems that are dependent on them, potential security risk, evaluate its risk/reward ratio, and finally and most important, you should always be able to roll back to the old version if something went wrong

A soft fork qualify the last criteria, but still, from risk/reward point of view, I don't feel it worth the effort given the risk it involves. You change to a new untested architecture, what if after 1 years when majority of the nodes were upgraded to SW and found out that there is a deadly security hole that can not be covered, thus hackers can spend anyone's coin?

Bitcoin's value relies purely on its security model. Existing architecture worth a lot because it is robust and time tested for almost 7 years. It worth a little in the beginning, since there are too many possible security risk to break it apart, thus it must survive the test of time to gain its value. Now if you change to another untested architecture, it will basically reset its value to zero, and take equal long time to establish people's trust

This is growing tiresome. Do you fully understand the complexities of the ACH/EFT system? I bet, just like me, you have a general understanding of how it works but have never seen the code behind it. I would also bet you have or have had at least one debit card and credit card in your life because almost everyone in western society has. There were 22 billion ACH transactions in 2013 with a total value of $38.7 trillion and almost no one really understands how it works. The way the ACH/EFT system continues to operate is by government and private oversight. People make a career out of working in finance and programming who oversee the system and there are laws that govern the form of that oversight.

The users of Bitcoin believe that system is flawed. They see potential in Bitcoin and are willing to use it. That requires faith in the original architect and the developers that continue to improve it because there is no governing body to regulate its continued operation or bailout its failures as there is with ACH/EFT. That leaves two possibilities for our acceptance and use of Bitcoin. Either build up a world class understanding of at least C++, Python, Java and elliptic curve cryptography or trust the people that are doing the job for you. I've learned to trust some of the scientists that work on this project based on their actions. Others I don't trust at all. Unless a mistake becomes blatantly obvious or someone I trust decides to speak out against this change I'm going to trust it because my understanding is limited. I suggest you do the same.

[franky1]

everyone says that segwit wants less data.. risking security just so lite clients can have less bloat.. well here goes.. i have a solution that doesnt involve messing with bitcoin protocol of splitting the chain..
firstly as described by gavin an old and common 2014 fullnode tx looks like:
[txdata+sig]=170bytes

segwit proposed 2016 softfork fullnode tx with fraudproof opcode will look like:
[[txdata][sig]opcode]=182
yes more fullnode bloat

and the same softfork in 2016 but for segwit liteclient (not full nodes) will look like:
[[txdata]opcode]=102

thats only 68bytes saving.. compared to 2014(no new opcode version)
i can think of easier ways of saving 68bytes (well80 if you include this new malle fix opcode)
just rename the namespaces of the variables:
hex=hx(1)
txid=id(2)(3 saved)
version=vr(5)(8 saved)
locktime=LT(6(14 saved)
Vin=Vi(1)(15 saved)
txid=id(1)(16 saved)
Vout=Vo(2)(18 saved)
scriptsig=ss(7)(25 saved)
hex=hx(1)(26 saved)
sequence=sq(6)(32 saved)
Vout=Vo(2)(34 saved)
Value=Va(3)(37 saved)
scriptPubKey=SPK(10)(47 saved)
OP_HASH160=oph160(4)(51 saved)
OP_EQUALVERIFY=OPEV(10)(61 saved)
OP_CHECKSIG=OPCS(6)(67 saved)
hex=hx(1)(68 saved)
reqsigs=rs(5)(73 saved)
addresses=adr(6)(79 saved)

thats 79bytes per tx saved without risking security at all and allowing more transactions per block(if full nodes also truncated namespaces(not advised)) without having to cut the block into two.
so my idea gives liteclients  79 less bytes on hard drive along with still getting signatures and still having the opcode for this magical malle fix

so now instead of
2014fullnode [txdata+sig]=170  or  2016fullnode [[txdata+sig+malleopcode]=182
its
2016segwit[[txdata+sig+malleopcode]=103 which is similar to
2016 segwit [[txdata]opcode]=102

but my idea still includes signatures. allowing full relay/seeding privileges for people syncing their chains, rather than being a limited function non secure copy of the blockchain that people cant trust when syncing

so while full nodes still use full length namespaces of the variable, lite wallets can truncate the namespaces with a simple translator bit of code
EG (laymans)
full nodes can continue doing this(no change just used as comparison to the SWlite clients difference)
  receive data to json_class Fjson{{hex:12345}{sequence:54321}{scriptsig:a1b2c3d4e5}}
    Fjson.hex
    Fjson.sequence
    Fjson.scriptsig
  save Fjson to file {{hex:12345}{sequence:54321}{scriptsig:a1b2c3d4e5}}

where as SWliteclients
  receive data to class Fjson {{hex:12345}{sequence:54321}{scriptsig:a1b2c3d4e5}}
  create class SWjson
    SWjson.hx=Fjson.hex
    SWJson.sq=Fjson.sequence
    SWJson.ss=Fjson.scriptsig
  save SWjson to file{{hx:12345}{sq:54321}{ss:a1b2c3d4e5}}

and the lite clients saves 79bytes per tx without losing the signatures. and this little change to save 79bytes per tx is not done in the main bitcoin protocol which we all admit will still store signatures no matter how you paint it..
but will be done by the lite clients themselves thus not affecting bitcoin protocol at all

the lite clients can relay and seed data simply by translating back when sending to full nodes
where SWliteclients:

  open file data to class SWjson {{hx:12345}{sq:54321}{ss:a1b2c3d4e5}}
  create class Fjson
    Fjson.hex=SWjson.hx
    Fjson.sequence=SWJson.sq
    Fjson.scriptsig=SWJson.ss
  relay Fjson to network {{hex:12345}{sequence:54321}{scriptsig:a1b2c3d4e5}}

its just that simple for lite clients to save 79bytes while still remaining part of the main network securing and relaying data..

the other good thing about letting lite clients do the pruning without it being a bitcoin protocol implementation is that liteclients can if they choose to, still prune off the signatures..
where SWliteclients
  receive data to class Fjson {{hex:12345}{sequence:54321}{scriptsig:a1b2c3d4e5}}
  create class SWjson
    SWjson.hx=Fjson.hex
    SWJson.sq=Fjson.sequence
    SWJson.ss= - ignore -
  save SWjson to file{{hx:12345}{sq:54321}}

allowing lite wallets to save even more data, without changing bitcoin-core

[bambou]

What you argue here (as I understand it) is that miners won't be able to 'understand' the SW patch, so they won't run it. I highly doubt both an assertion and a conclusion. I am sure it will be rolled over quite fast. But I have no real proof so we have to wait.

To migrate to a large change in infrastructure, you need to not only understand the solution, but also fully aware of the impact to the existing system and all the other systems that are dependent on them, potential security risk, evaluate its risk/reward ratio, and finally and most important, you should always be able to roll back to the old version if something went wrong

A soft fork qualify the last criteria, but still, from risk/reward point of view, I don't feel it worth the effort given the risk it involves. You change to a new untested architecture, what if after 1 years when majority of the nodes were upgraded to SW and found out that there is a deadly security hole that can not be covered, thus hackers can spend anyone's coin?

Bitcoin's value relies purely on its security model. Existing architecture worth a lot because it is robust and time tested for almost 7 years. It worth a little in the beginning, since there are too many possible security risk to break it apart, thus it must survive the test of time to gain its value. Now if you change to another untested architecture, it will basically reset its value to zero, and take equal long time to establish people's trust

This is growing tiresome. Do you fully understand the complexities of the ACH/EFT system? I bet, just like me, you have a general understanding of how it works but have never seen the code behind it. I would also bet you have or have had at least one debit card and credit card in your life because almost everyone in western society has. There were 22 billion ACH transactions in 2013 with a total value of $38.7 trillion and almost no one really understands how it works. The way the ACH/EFT system continues to operate is by government and private oversight. People make a career out of working in finance and programming who oversee the system and there are laws that govern the form of that oversight.

The users of Bitcoin believe that system is flawed. They see potential in Bitcoin and are willing to use it. That requires faith in the original architect and the developers that continue to improve it because there is no governing body to regulate its continued operation or bailout its failures as there is with ACH/EFT. That leaves two possibilities for our acceptance and use of Bitcoin. Either build up a world class understanding of at least C++, Python, Java and elliptic curve cryptography or trust the people that are doing the job for you. I've learned to trust some of the scientists that work on this project based on their actions. Others I don't trust at all. Unless a mistake becomes blatantly obvious or someone I trust decides to speak out against this change I'm going to trust it because my understanding is limited. I suggest you do the same.

So, bitcoin is about believing and trusting people?

[QuestionAuthority]

What you argue here (as I understand it) is that miners won't be able to 'understand' the SW patch, so they won't run it. I highly doubt both an assertion and a conclusion. I am sure it will be rolled over quite fast. But I have no real proof so we have to wait.

To migrate to a large change in infrastructure, you need to not only understand the solution, but also fully aware of the impact to the existing system and all the other systems that are dependent on them, potential security risk, evaluate its risk/reward ratio, and finally and most important, you should always be able to roll back to the old version if something went wrong

A soft fork qualify the last criteria, but still, from risk/reward point of view, I don't feel it worth the effort given the risk it involves. You change to a new untested architecture, what if after 1 years when majority of the nodes were upgraded to SW and found out that there is a deadly security hole that can not be covered, thus hackers can spend anyone's coin?

Bitcoin's value relies purely on its security model. Existing architecture worth a lot because it is robust and time tested for almost 7 years. It worth a little in the beginning, since there are too many possible security risk to break it apart, thus it must survive the test of time to gain its value. Now if you change to another untested architecture, it will basically reset its value to zero, and take equal long time to establish people's trust

This is growing tiresome. Do you fully understand the complexities of the ACH/EFT system? I bet, just like me, you have a general understanding of how it works but have never seen the code behind it. I would also bet you have or have had at least one debit card and credit card in your life because almost everyone in western society has. There were 22 billion ACH transactions in 2013 with a total value of $38.7 trillion and almost no one really understands how it works. The way the ACH/EFT system continues to operate is by government and private oversight. People make a career out of working in finance and programming who oversee the system and there are laws that govern the form of that oversight.

The users of Bitcoin believe that system is flawed. They see potential in Bitcoin and are willing to use it. That requires faith in the original architect and the developers that continue to improve it because there is no governing body to regulate its continued operation or bailout its failures as there is with ACH/EFT. That leaves two possibilities for our acceptance and use of Bitcoin. Either build up a world class understanding of at least C++, Python, Java and elliptic curve cryptography or trust the people that are doing the job for you. I've learned to trust some of the scientists that work on this project based on their actions. Others I don't trust at all. Unless a mistake becomes blatantly obvious or someone I trust decides to speak out against this change I'm going to trust it because my understanding is limited. I suggest you do the same.

So, bitcoin is about believing and trusting people?

No, not if you're a scientific genius, it's not. For the rest of us, yeah, it is.

[johnyj]

So, bitcoin is about believing and trusting people?

Exactly, instead of trusting a group of bankers you trust a group of developers, then this is not a trust-less system

The problem here is that an open source project does not take any financial responsibility

At enterprise level, if a company push in a software change which resulted in customer loss, the company will have to pay the fine/compensation to customer based on the service level agreement or similar contract. So there are usually strict change and release management procedure in place to avoid such kind of loss as much as possible

However here in bitcoin world, there is no such kind of financial responsibility. If devs push in a change which resulted in customer loss, the devs are not responsible for the damage, or to say, they don't have enough money to compensate the loss from millions of users. The users are all on their own

Imagine that in future if pension fund and social security fund are all invested in bitcoin, and devs pushes out a change and let their bitcoin stolen, who is going to compensate for the losses caused for millions of people that relies on these funds for their retirement?

Of course no one can insure against everything, there is always risk, but it is a general practice to not take drastic change in financial projects unless in a crisis, and we are far from that yet

[johnyj]

No, not if you're a scientific genius, it's not. For the rest of us, yeah, it is.

Being a scientific genius is far from enough, there are so many professors financially broke because they lack of financial knowledge. In fact human all make wrong decisions, and different people have different interest, the point of bitcoin is to remove this kind of trust

[franky1]

However here in bitcoin world, there is no such kind of financial responsibility. If devs push in a change which resulted in customer loss, the devs are not responsible for the damage, or to say, they don't have enough money to compensate the loss from millions of users. The users are all on their own

if they mess up bitcoin, the dev's own income and savings is also lost..
thats why they dont want to mess up. and each new release is tested. and in the result of a bug in a new release. people downgrade to previous version and the bug is gone until its sorted out for an amended new release.

bitcoin is actually more secure then you think, you are not relying on 1 coders say so. there are usually 1000+ coders all using new releases before the general users even get the option to upgrade. so if there was any issue, the coders would be the first to get affected.