Gold collapsing. Bitcoin UP.

[sgbett]

Segwit being sold as a scaling solution when in this regard everything that applies to a simple blocksize increase *also* applies to segwit. Same bandwidth, same storage (for apples to apples comparison of *full* nodes).

What segwit actually does is split witness data and prices that data differently. Its not clear whether this is desirable.

Soft forking a breaking change is the killer non-feature though.

One the one hand the message is that we need more full nodes because centralisation. OTOH we have its ok for segwit to silently break the "fully validating" aspect of full nodes. That makes no sense.

I also haven't quite got my head around this so if I am wrong please correct me, but it seems exactly the same thing applies to xthinblocks vs -blocksonly.

xthinblocks retains a nodes ability to be fully validating. -blocksonly appears to scrap the propogation/validation of transactions on the fly (i.e. it only validates once transactions are in blocks)

If its true then thats another way in which people are being pushed away from running fully validating nodes... curious.

 

[satoshis_sockpuppet]

I'm always looking for arguments against segwit. That thing smelled extremely fishy to me since the beginning. I just don't like it. It's such a weird cumbersome package. Doesn't solve the issue and adds complexity, huge workload and also risks... not even talking about the unkown unkowns. Maybe you can clarify some points you made...

• What exactly do you mean by "misuse of bitcoin language"?
• What do you mean by "it will mess your money up"? Was that just a summary of the preceding points?

"bitcoin language" should be bitcoin scripting language. Personally I don't think workarounds like using "anyonecanspend" to achieve something completely different (SegWit) are good design. Maybe I'm just a neurotic on this issue but I don't think it is a good idea to mark my funds as anyonecanspend b/c I know most nodes and the majority of miners will see it as something different. Especially if I can achieve the wanted behavior with a clean fork where either SegWit is just used for all transactions or I introduce a new term like "segwittransaction".
Imho the software should be as transparent as possible and it is good to use names for what they are. If I say "anyonecanspend" I want "anyonecanspend".
Every hack like this makes the documentation more voluminous and the code loses it self documenting style. I think J Stolfi said, the core devs aren't designing software, they are hacking.

"Mess your money up" is a bit polemic but 1. Yes, it is a summary of SW and 2. SW changes the way bitcoin operates atm fundamentally. This can be a good thing, but it is extremely dangerous to make it look like it's just an easy fix (like a 2MB fork would be). Something like this should be discussed in detail, not a can kick like 2 MB. If SegWit activates as a soft fork there is no going back, it is irreversible.

edit: P.S.: Sorry for the walls of text. What I said could be said in less words but as a non native speaker it is harder to be concise.
[doublepost=1458037649,1458036668][/doublepost]

accounting tricks aside it's a worthwhile piece of code. modula.

I mean, I know very little about the details but it sounds all good, and as a bonus it helps scaling
and it helps scaling in a big way, segwit isn't == 2MB , segwith == 2X Block_size_limit
with segwit 2MB blocks "feel" like 4MB!
4MB feels like 8MB
8MB feels like 16MB
...
512MB feels like 1024MB

this is no "poison pill " ( as long as it actually works and doesn't break bitcoin... )
[doublepost=1458018194,1458017495][/doublepost]Maybe i'm overstating the scaling benefits because i dont understand it...
but there's a reason segwit is part of classics road map, and there's a damn good reason why its at the bottom of the road map, not the top.

First: The way SegWit is being implemented now is a no go (Softfork hack + discount). And as the current implementation it is a dangerous poison pill.

Apart from that, it isn't doing anything about scaling at all. Nothing. The data that has to be transferred isn't smaller, in fact it is a bit (although negligible*) larger.
"Feels like" is funnily the correct description. It feels smaller, but it isn't. And my router doesn't feel traffic, it transmits packets.

The fixes about malleability and quadratic signature hashing have been discussed before SW and this can be fixed without SW, although it is hardly a pressing issue at all. It's definitely not worth messing up current behavior imho.

I don't think SW is necessary at all, neither as a hard - nor a soft fork. (BTW I think there should be a new nomenclature for these forks, hard and soft is already manipulating wording imo) And I don't know if the work that has to be done for it is commensurate to the benefits (what are they?).


*In all fairness: If it came from non core devs and was against BS wishes, nullc etc. would be in an uproar about this "bloating"...

 

[Lee Adams]

but there's a reason segwit is part of classics road map, and there's a damn good reason why its at the bottom of the road map, not the top.

Do you have a source for this? I do not see SW on Classic's roadmap. Sure they are keeping up to date with core's new code (but disabling contentious features), but my gut feel is that if they include the SW code it would also be disabled.

 

[sgbett]

https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md

(at the bottom)
[doublepost=1458039450][/doublepost]ctrl-f "segregated" - its not referred to as segwit

 

[Lee Adams]

"bitcoin language" should be bitcoin scripting language. Personally I don't think workarounds like using "anyonecanspend" to achieve something completely different (SegWit) are good design.

This is my only objection to SW as planned. Maybe I trust Andreas Antonopoulos' enthusiasm for it too much, but I do feel that overall it has great benefits. However because this seems like a hack too far I'm firmly against it as a 'soft fork' (unelected fork?). I'd love to see it as a voted fork.

If SegWit activates as a soft fork there is no going back, it is irreversible.

Does this mean if just 1 miner produces a soft forked seg wit block, then we are stuck with it? Seems like a dangerous attack vector to me.

 

[sgbett]

If it activates as SF then yes there is no going back (barring consensus-reorg/checkpointing), but this is how bitcoin works. CPUs and voting power. If miners vote for it so be it.

What can be seen from this is that "Soft fork" doesn't sound so different to "Hard Fork" in terms of forcing people to upgrade.

The difference lies in the fact that the hard fork provides a visible mechanism of diverging nodes. A soft fork, nobody can tell what is going on for sure.

satoshis_sockpuppet was right on the money:

Imho the software should be as transparent as possible and it is good to use names for what they are. If I say "anyonecanspend" I want "anyonecanspend".
Every hack like this makes the documentation more voluminous and the code loses it self documenting style. I think J Stolfi said, the core devs aren't designing software, they are hacking.

 

[satoshis_sockpuppet]

This is my only objection to SW as planned. Maybe I trust Andreas Antonopoulos' enthusiasm for it too much, but I do feel that overall it has great benefits. However because this seems like a hack too far I'm firmly against it as a 'soft fork' (unelected fork?). I'd love to see it as a voted fork.

Honestly I would like to hear these great benefits. I can't understand how people can be enthusiastic for Segwit. It isn't a stroke of genius, it's just separating the two parts of a transaction. What are the huge benefits?
[doublepost=1458041181][/doublepost]

Does this mean if just 1 miner produces a soft forked seg wit block, then we are stuck with it? Seems like a dangerous attack vector to me.

That is how it is and like @sgbett already said, a softfork isn't soft at all.

Furthermore, if we changed the blocksize to 2 MB and for some reason two months later 1.9 MB seems better there is no problem with changing this. But if people used SegWit transactions they can't revert that change in the protocol.

And this is important: SegWit is changing how Bitcoin works today. It's effect is minimal imho, it does nothing for scaling (this is why it shouldn't be discussed on scaling workshops ..) but it changes a lot of code.
A 2 MB hardfork does nothing of the above. It is so fucked up and perverted, that Blockstream managed to make SW look like a nice little stroke of genius and a 2 MB hardfork like a dangerous HARD FORK!11!!11! It is completely twisted.

If Pieter Wuilles SW is on the way to activation I'm out.

 

[cypherdoc]

 

[theZerg]

Segwit being sold as a scaling solution when in this regard everything that applies to a simple blocksize increase *also* applies to segwit. Same bandwidth, same storage (for apples to apples comparison of *full* nodes).

What segwit actually does is split witness data and prices that data differently. Its not clear whether this is desirable.

Soft forking a breaking change is the killer non-feature though.

One the one hand the message is that we need more full nodes because centralisation. OTOH we have its ok for segwit to silently break the "fully validating" aspect of full nodes. That makes no sense.

I also haven't quite got my head around this so if I am wrong please correct me, but it seems exactly the same thing applies to xthinblocks vs -blocksonly.

xthinblocks retains a nodes ability to be fully validating. -blocksonly appears to scrap the propogation/validation of transactions on the fly (i.e. it only validates once transactions are in blocks)

If its true then thats another way in which people are being pushed away from running fully validating nodes... curious.

Yes if everyone ran blocksonly no txns would propagate. The network would stop functioning. You can't count a blocksonly node as a full node.

However it may have value in small merchant payment acceptance solutions - if the merchant does not need to see the txn or can get it another way. One issue with bitcoin today is that a VPS serving a personal storefront (cheapest VPS u can buy) can't also be a full node.

 

[cypherdoc]

Blocks only sounds retarded.

Is that a gmax solution? Figures. That's worse than breaking 0 confs. What are customers supposed to do, go stand in the corner of Starbucks waiting for a block confirmation? Am I supposed to sit 10 min for my online purchase to go through? merchants have already worked out this risk profile over the years. Who is core dev to step in and break this economic dynamic upon which all of Bitcoin's success has been built upon? They need to go. And that is what Classic offers.

 

[Lee Adams]

What are the huge benefits?

https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-277-separating-signatures-with-segregated-witness

 

[cypherdoc]

 

[Erdogan]

Well, shit. Ok, so SFSW seems to be basically a poison pill with a candy coating. In that case, I'm a little alarmed by how readily Bitcoiners on reddit seemed to be to swallow it. The sentiment among most "big-blockers," including people whose opinions I respect, seemed to be that "oh yeah, everyone likes SegWit, but we should do a simple HF to raise the block size limit first."

I absolutely don't want segregated witness. When it is beaten down and finished, and everyone can see that it never will be included, bitcoin price will double in an instant.

I want private, world, free market, sound money, exactly what bitcoin is. I want it for everybody. On chain can go a million fold, then we have payment providers and hand-to-hand, fiat-paper-rectangle-like-but better, fancy colored paper wallets.

I want nothing that can obscure the simple technology that we have.

 

[Lee Adams]

That is how it is

Hmmmm.... A miner with sufficient hash power could take the existing beta code and mine a block with seg wit. They could do this today and (if they had the code) they could have done it last year. Does this now mean that every node will eventually have to run seg wit code?

 

[yrral86]

Pros:
To play Devils Advocate, the purpose of segregating the witness (i.e. signature) data is so that it can be pruned. We need transaction history, but once the transactions are verified and in blocks, we can drop the witness data without really losing anything.

Also, a single segwit block isn't an attack vector. If the majority supports it, then we have forked and any attempt to spend it via anyonecanspend will be invalid. If the majority does not support it, someone will sweep up the bitcoin and the sender of that transaction will learn a lesson.

Cons:
SWSF can work, but it is a nasty hack and I personally wouldn't risk using a SW transaction until 95% of the miners support it. At that point, we should probably just do a proper hard fork. Also, if bandwidth is the bottleneck, not long term storage which is cheap and getting cheaper, than XThinBlocks will help way more is is a much safer, non forking (hard or soft) change. Even without XThin, blocks could easily be 2MB without stressing a decent connection in the least.

 

[theZerg]

Reddit troll mmeijeri proves he knows nothing about what he's talking about:


Anyone think its worth a separate knock down posting? (if so, please make one) But don't do his work for him and TELL him the data. He'll just grab it and move on. Force him to actually look at xthin blocks...

 

[cypherdoc]

https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-277-separating-signatures-with-segregated-witness

Listen to Lombrozzo's podcasts to hear the urgency in Core devs desire to ram this through. . Many core devs have said how great it will be to take advantage of the unfettered script versioning to do "all sorts of things" to the protocol via soft forks. Which basically is a mechanism to make changes without interference from current node implementations. IOW, old nodes are forced to come along by accepting the new changes or just plain leaving Bitcoin as the alternative. You are not allowed to voice disagreement with said change by not upgrading. Instead, you get deprecated to partially validating SPV status which is not only terrible for your own security but humiliating as you've effectively given core dev a blank check to speak forever on your behalf as a node.

As for the monetary part of this, I don't know about you, but I don't want a bunch immature kid geeks backed by $76M of fiat oriented investors constantly tinkering around with my money on an ongoing basis. Bitcoin was supposed to be a SOV with stable and predictable properties and behavior. Digital gold if you will. Core dev has already admitted that they could insert Ethereum and CT into the protocol via these unfettered script versions. Why not inflation too through something like Dogecoin? SW appears to be the very definition of complicated and opens the door to possible corruption. The Forth like scripting language Satoshi put in place is supposed to be restrictive to prevent this type of manipulation.

No, I'd rather stick with what's worked so far with devs I trust with Classic. Namely Gavin and Jeff.
[doublepost=1458046790,1458045731][/doublepost]

Pros:
To play Devils Advocate, the purpose of segregating the witness (i.e. signature) data is so that it can be pruned. We need transaction history, but once the transactions are verified and in blocks, we can drop the witness data without really losing anything.

Also, a single segwit block isn't an attack vector. If the majority supports it, then we have forked and any attempt to spend it via anyonecanspend will be invalid. If the majority does not support it, someone will sweep up the bitcoin and the sender of that transaction will learn a lesson.

Cons:
SWSF can work, but it is a nasty hack and I personally wouldn't risk using a SW transaction until 95% of the miners support it. At that point, we should probably just do a proper hard fork. Also, if bandwidth is the bottleneck, not long term storage which is cheap and getting cheaper, than XThinBlocks will help way more is is a much safer, non forking (hard or soft) change. Even without XThin, blocks could easily be 2MB without stressing a decent connection in the least.

We just got pruning enabled with 0.12; block pruning that is. Which is even better than SW because it preserves the current structure of things. And, it's never been about storage space anyways. SW worsens the BW requirements of the network and miners. For the love of me, I can't see how miners would go for this.

Also, it seems true that there would be no going back given that you'd have all these blockchain data sets pruned of their signatures stored on full pruned nodes without a means to reassociate them.

No one's ever addressed my Sybil attack scenario against ANYONECANSPEND nodes.

 

[Christoph Bergmann]

That's a bomb. A bitcoin business leader openly accusses core devs / blockstream of a massive conflict of interest. Just ... wow!

Edit: it was already submitted on r/bitcoin, but, as always, censored. Since when is critic on blockstream something against moderation policies?

 

[satoshis_sockpuppet]

Oh I thought there is a named field "anyonecanspend" (or something similar) today which apparently doesn't exist, so I have to take that part back. They any one can spend your coins script is not named as such.

https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-277-separating-signatures-with-segregated-witness

Is there a transcript somewhere?

To play Devils Advocate, the purpose of segregating the witness (i.e. signature) data is so that it can be pruned. We need transaction history, but once the transactions are verified and in blocks, we can drop the witness data without really losing anything.

This is wrong. You lose a lot. I would argue you lose the most important part of the blockchain in some sense, as you lose the evidence that someone owned certain coins at a time.
I'm not a blockchain fetishist who thinks everybody should store the complete blockchain, imho the last X weeks/months will be fine. But if you think everybody should store the complete blockchain I would argue, that the signatures are definitely part of the complete history.

And if you just store some GB's of the blockchain I don't see where SW makes a great difference in terms of storage cost.

 

[Richy_T]

Maybe i'm overstating the scaling benefits because i dont understand it...

This is the big issue. It's not your fault, it's a complicated chunk of stuff (a big red flag in and of itself). Heck, I didn't understand it and I thought I did. Much of the good stuff it does is not a side effect of what it does but could be implemented separately and should not be counted for it. It also subverts the PAY_ANY code and makes many nodes useless without consulting those running them.
[doublepost=1458047486][/doublepost]

if you prefer, go thru my tweet history of the last month. it's not long.

Maybe someone could do something Like Adam's 2MB vs 1MB thread. Adam?

Edit: Oh, it was Adam. Changed his avatar