Topic: Segregated witness - The solution to Scalability (short term)? - page 11. (Read 23195 times)

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

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.

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.

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

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


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)

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

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

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

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.

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!

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.

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.

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.



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.

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.

This planned patch is a step towards LN. Judging by its adoption, it seems that miners are favoring LN.

They (SW and LN) are different, yet their complexity is of comparable scale. In fact, what SW does is 'solve' malleability, and thus paves the way for full LN.

Incidentally, I spent more time understanding LN than SW.

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.

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.

?

If so.. I like it. Well coded!

I've been droning on about putting just the txn hash in the blocks, and using a similar disposable merkle tree of txn data, and squish everything, but I think this is a really nice solution. As you can still check that all the amounts add up.
 
And, who knows, maybe some day they will use this same trick, disposable merkle trees of data, once studied and better understood surviving in the wild, on the entire UTXO set.

 

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

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

They're not doing that. Splitting something up does not mean removing either piece of the original thing.