Gold collapsing. Bitcoin UP.

[satoshis_sockpuppet]

By adding a version byte with semantics like, whenever you see a version byte that you don't know, consider it ANYONECANSPEND.

So, this is considered the conservative, careful approach? This is something that can be implemented in a few months and considered safe? Are we getting completely fucked by them?

Sounds pretty convincing to me: We made a tiny change to your money. From now on every account can be spent by anyone if you aren't updating your node and following our rules.

And these are the people that are "concerned" about fully validating nodes.

Argl.

 

[cypherdoc]

[doublepost=1458057936][/doublepost]by golly, you want change? we'll give you change! multiple, parallel soft forks in action, baby!:

Abstract
This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. Once the consensus change takes place, the bit is no longer necessary, and can be reused for later changes. In case a change is not adopted by majority vote before a pre-set timestamp, it is reverted and the used bit becomes available again as well.

https://gist.github.com/sipa/bf69659f43e763540550

 

[molecular]

anyways, it's about the actual changes themselves that we should be debating. forget SF vs HF.
[doublepost=1458056326][/doublepost]
read pwuille:

https://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

peter:

Obviously, an empty signature is not going to be able to spend an actual output that requires a signature. Instead, the outputs do not push these scripts that we required to be satisfied, they would be encapsulated, it would be pushed as a piece of data. This allows us to, this effectively to every node, and every node not using this system, it's an ANYONECANSPEND. It's just an output that pushes data on the stack, the output doesn't do anything else. It's ANYONECANSPEND. In a soft-fork, we can add a new rule that restricts what's valid.

What keeps an old client from actually spending those coins? What does ANYONECANSPEND even mean?

from bitcoin scripting wiki:

Anyone-Can-Spend Outputs
Conversely a transaction can be made spendable by anyone at all:

scriptPubKey: (empty)
scriptSig: OP_TRUE

With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for fidelity bonds to sacrifice funds in a provable way.

So a miner with an old client could actually assume he could take those coins and other miners with non-segwit clients running would accept blocks with such transactions? Doesn't this open the door to a nasty hardfork?

EDIT: at least this makes this softfork "just as bad" as a hardfork because every miner has to upgrade. Or am I missing something?

 

[cypherdoc]

@molecular

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-270#post-10067

 

[Justus Ranvier]

Sounds pretty convincing to me: We made a tiny change to your money. From now on every account can be spent by anyone if you aren't updating your node and following our rules.

And these are the people that are "concerned" about fully validating nodes.

Nobody wants to come out and say it because the illusion of good faith is still powerful (as is the fear of attack), but the only safe assumption you can make is that everything they say is a lie designed to further their agenda in the moment, even if some of their lies are coincidentally true.

They obviously don't believe their own arguments, because the second one of the arguments they've used in the past would contradict something they are pursuing in the present, they drop it like a hot potato and feign ignorance if you point it out.

 

[satoshis_sockpuppet]

EDIT: at least this makes this softfork "just as bad" as a hardfork because every miner has to upgrade. Or am I missing something?

The soft fork is more unclean than a hard fork.

The miners have to upgrade anyway. But old nodes are tricked into believing they're still part of the network although they are just doing bullshit.

Which I think is the main reason for a soft fork: Core is afraid, that a lot of old nodes wouldn't update to their version if they tried to do a hard fork. All the old 11.x (and older) nodes, that are still running would suddenly have to make a decision. What we see now is that a lot of these node operators are lazy and don't change anything, they might change to classic if they had to upgrade.

 

[cypherdoc]

Nobody wants to come out and say it because the illusion of good faith is still powerful (as is the fear of attack), but the only safe assumption you can make is that everything they say is a lie designed to further their agenda in the moment, even if some of their lies are coincidentally true.

They obviously don't believe their own arguments, because the second one of the arguments they've used in the past would contradict something they are pursuing in the present, they drop it like a hot potato and feign ignorance if you point it out.

or they just do the gool 'ol /u/nullc disappearing act like here:

poof! no answer! gone!
[doublepost=1458060104][/doublepost]ooh, this is juicy.

remember the brg444 revelation on SC's that i posted the other day here from the Core Slack channel? here's another one, just now. dead on arrival, baby:

brg444[9:13 AM]@proslogion: Last I heard there had been no progress on SPV sidechains since whitepaper was released

 

[sgbett]

http://gavinandresen.ninja/segregated-witness-is-cool

and, as pointed out by@sgbett, Seg Wit is on the Classic roadmap.

Please note I have already said that I think unelected fork seg wit is a bad idea.

segwit *is* cool imho, just wish there weren't so many niggling questions about the implementation.

discounting witness data as a motivation to reduce UTXO seems plausible.
locking the txid seems a good thing to do
BIP143, though complicated, on the face of it seems like a great idea. If it is so compelling, then why a soft fork? It looks to me like this is the real solution you put in place once the temporary limit to sign hash become a problem. Just like how you would put a temporary blocksize limit in that you would remove once you had a better solution!!
P2SH seems uncontroversially good
Script Versioning seems to be a big red flag. There seems to be a huge philosophical rift between proponents of Hard and Soft forks. If, in the face of controversy, the precedent is to maintain the status quo...

The choice as to whether to bother with signature data is good. Forcing old nodes not to have it by default is not choice. The discussion about 'scaling' benefits its totally dishonest, it attempts to cement the idea that there should be some limit somewhere, however fancifully dressed up it might be ("validation cost metric"). This is violently opposed to the idea that bitcoin exists without the interference of central planning. By definition if part of bitcoin is controlled then it has failed. Even nullc agrees...

[doublepost=1458061071][/doublepost]

I think I missed that bolded part. What is this "wide open scripting facility"?

Script versioning
Changes to Bitcoin’s script allow for both improved security and improved functionality. However, the design of script only allows backwards-compatible (soft-forking) changes to be implemented by replacing one of the ten extra OP_NOP opcodes with a new opcode that can conditionally fail the script, but which otherwise does nothing. This is sufficient for many changes – such as introducing a new signature method or a feature like OP_CLTV, but it is both slightly hacky (for example, OP_CLTV usually has to be accompanied by an OP_DROP) and cannot be used to enable even features as simple as joining two strings.

Segwit resolves this by including a version number for scripts, so that additional opcodes that would have required a hard-fork to be used in non-segwit transactions can instead be supported by simply increasing the script version.

from https://bitcoincore.org/en/2016/01/26/segwit-benefits/

 

[8up]

Nobody wants to come out and say it because the illusion of good faith is still powerful (as is the fear of attack), but the only safe assumption you can make is that everything they say is a lie designed to further their agenda in the moment, even if some of their lies are coincidentally true.

They obviously don't believe their own arguments, because the second one of the arguments they've used in the past would contradict something they are pursuing in the present, they drop it like a hot potato and feign ignorance if you point it out.

Nobody likes to look at the 9/11 facts/lies for the same reasons. It's just human mass psychology/herd mentality at play.

 

[sgbett]

by golly, you want change? we'll give you change! multiple, parallel soft forks in action, baby!:

Abstract
This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. Once the consensus change takes place, the bit is no longer necessary, and can be reused for later changes. In case a change is not adopted by majority vote before a pre-set timestamp, it is reverted and the used bit becomes available again as well.

https://gist.github.com/sipa/bf69659f43e763540550

software dev 101

https://en.wikipedia.org/wiki/Cyclomatic_complexity

 

[yrral86]

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.

Is there a transcript somewhere?


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.

You still know what address owned them. Segwit does not change that. If you get rid of signature data you can store more history in the same amount if space you have allocated.

 

[cypherdoc]

segwit *is* cool imho, just wish there weren't so many niggling questions about the implementation.

discounting witness data as a motivation to reduce UTXO seems plausible.
locking the txid seems a good thing to do
BIP143, though complicated, on the face of it seems like a great idea. If it is so compelling, then why a soft fork? It looks to me like this is the real solution you put in place once the temporary limit to sign hash become a problem. Just like how you would put a temporary blocksize limit in that you would remove once you had a better solution!!
P2SH seems uncontroversially good
Script Versioning seems to be a big red flag. There seems to be a huge philosophical rift between proponents of Hard and Soft forks. If, in the face of controversy, the precedent is to maintain the status quo...

The choice as to whether to bother with signature data is good. Forcing old nodes not to have it by default is not choice. The discussion about 'scaling' benefits its totally dishonest, it attempts to cement the idea that there should be some limit somewhere, however fancifully dressed up it might be ("validation cost metric"). This is violently opposed to the idea that bitcoin exists without the interference of central planning. By definition if part of bitcoin is controlled then it has failed. Even nullc agrees...

[doublepost=1458061071][/doublepost]

Script versioning
Changes to Bitcoin’s script allow for both improved security and improved functionality. However, the design of script only allows backwards-compatible (soft-forking) changes to be implemented by replacing one of the ten extra OP_NOP opcodes with a new opcode that can conditionally fail the script, but which otherwise does nothing. This is sufficient for many changes – such as introducing a new signature method or a feature like OP_CLTV, but it is both slightly hacky (for example, OP_CLTV usually has to be accompanied by an OP_DROP) and cannot be used to enable even features as simple as joining two strings.

Segwit resolves this by including a version number for scripts, so that additional opcodes that would have required a hard-fork to be used in non-segwit transactions can instead be supported by simply increasing the script version.

from https://bitcoincore.org/en/2016/01/26/segwit-benefits/

the result being, anytime core dev wants to introduce a new op_code via a script change, the restriction has now been undone since they can release the change as a soft fork, which usually means a sleeping unattentive community won't bother to object and their full nodes will be dragged along into accepting such change (witness CLTV, CSV) while at the same time interpreting the new version bit & tx as an ANYONECANSPEND piece of data and accept and relay tx's based on this w/o verification. said node has now been deprecated to a SPV partially validating node thank you very much and fuck you.

 

[freetrader]

It's a scammy way of upgrading a distributed system that's supposed to maintain consensus via a majority of honestly validating nodes.

(to be clear, I'm talking about the planned soft-fork rollout of SegWit, with all its gotchas)

 

[Richy_T]

So a miner with an old client could actually assume he could take those coins and other miners with non-segwit clients running would accept blocks with such transactions? Doesn't this open the door to a nasty hardfork?

By my understanding, there could be a fork but the activation requirements would mean that that fork would get orphaned pretty quickly. Of course, that makes even 1 conf tricky. So 30 or 40 minutes for that coffee you're not supposed to be buying.

 

[adamstgbit]

It's a scammy way of upgrading a distributed system that's supposed to maintain consensus via a majority of honestly validating nodes.

its a rushed way

the devs feel confident this is the way forward and they dont like having to explain themselves, so they are taking advantage segwit's scaling effect to sell the idea and avoid a lot of endless/pointless debating. change scares poeple, so they don't like to talk about how segwit is a game changer, they would rather we talk about how segwit is a life saver.

there method's are questionable, but effective.

the more i hear about segwit the more i like it, and the more i want it to be rolled out slowly and well reviewed, and cleaned to the point of perfection

In my view they should do the 2MB first simply to buy more time to really get segwit to perfection.

 

[cypherdoc]

i'm not sure how he thinks this helps him:

 

[sgbett]

the result being, anytime core dev wants to introduce a new op_code via a script change, the restriction has now been undone since they can release the change as a soft fork, which usually means a sleeping unattentive community won't bother to object and their full nodes will be dragged along into accepting such change (witness CLTV, CSV) while at the same time interpreting the new version bit & tx as an ANYONECANSPEND piece of data and accept and relay tx's based on this w/o verification. said node has now been deprecated to a SPV partially validating node thank you very much and fuck you.

Precisely and as previously asked:

 

[cypherdoc]

@sgbett

similarly what's more hostile?

1. a 10 LOC change of constant from 1 to 2 or,
2. a >2000 LOC change of multiple consensus mechanism functionalities and security mechanisms of the core protocol that change Bitcoin's economic incentives?

 

[adamstgbit]

@cypherdoc

2MB will hurt decentralization. ( not by very much at all.... hardly worth mentioning )
segwit will destroy/forever change bitcoin as we know it.

segwit is infinitely more "hostile" to the status quo

i'm love'n it!

 

[theZerg]

guys BU 0.12.0 with xthin blocks is basically released. Please head to www.bitcoinunlimited.info/download and update a node or two. Especially windows and Mac nodes since I have not had a chance to test this release on those platforms.

But let's keep this on this forum until Solex issues the official announcement, to let some of you guys test this bits on those architectures.