Gold collapsing. Bitcoin UP.

[adamstgbit]

This is the basic problem with soft fork SW, it removes the
But soft fork SW changes that, coins are sent to an ANYONE can spend output. Now you have to also trust miners to continue to "honor" the rules of SW and to not spend those coins. Yes, in theory they will honor the rules, but it is an extra security weakness that does not need to be there.

Hard fork SW does not have this issue, but it is not being used.

It is almost as if the entire dev team want to break bitcoin so they can then tell everyone to use their more secure off chain solutions.

I will never send a coin to an ANYONE can spend output, it is insanity.

miners can not change the output of sent coins...

other miners have access to the witness data and will orphen any block that tries to change a TX to point to a different output. just like they do now.

what your talking about "ANYONE can spend output" TX's is what the segwit TX would look like to older versions of the software, all this to say segwit is backward compatible ( which its really not for other reasons )

 

[solex]

@adamstgbit
Surely the risk is that if the 75% is triggered. lots of people use the SW-type tx, then the SW hashing power goes back below 50%, that the SW outputs can be diverted as those blocks won't get orphaned as the SW miners are in a minority.

 

[rocks]

miners can not change the output of sent coins...

other miners have access to the witness data and will orphen any block that tries to change a TX to point to a different output. just like they do now.

what your talking about "ANYONE can spend output" TX's is what the segwit TX would look like to older versions of the software, all this to say segwit is backward compatible ( which its really not for other reasons )

You are still putting trust in miners to not do so. Under SFSW once 75% of miners say they will honor SW transactions (scouts honor), the system activates. BTW 25% still give no pledge.

At that point if just 1/3 of the miners who pinky swear that they will honor SW, decide to change their mind, well then the longest chain being built will spend those ANYONE CAN SPEND outputs, and the majority of non-updated nodes will go along.

I am not saying it will happen.

I am saying it is another layer of trust you have to have that did not exist before.
[doublepost=1458101279][/doublepost]

@adamstgbit
Surely the risk is that if the 75% is triggered. lots of people use the SW-type tx, then the SW hashing power goes back below 50%, that the SW outputs can be diverted as those blocks won't get orphaned as the SW miners are in a minority.

Exactly, it is another layer of trust.

In a system that is suppose to be trustless.

 

[Zangelbert Bingledack]

@AdrianX

That is doing it properly. The missile must be allowed to penetrate into the core of the Death Star before detonating. That means pre-empting as many objections as possible through said reddit-rinsing and whitepaper references.

 

[sickpig]

About SegWit (cross posting from Wall Observer thread):

- firstly it substitutes a scarse economic good, block space, with two new goods splitting the original in two parts. The first one is considered "noble", in fact it receives a completely arbitrary discount of 75% when computing tx fee. The second one is treated as "bad" and for some reasons won't get any discount. the former is tx signature, the latter it's transaction "body". This the worst part ever, it changes in a fundamental way bitcoin economic incentives.

- secondly it is falsely proposed as a scaling solution when it is not. Scaling it's a matter of bandwidth more than anything else, and guess what? with SegWit, as per current BIP, you could get 4 MB blocks. Those blocks has to be relaid and fetched by full nodes, only after validation phase a node could decide to drop the signature. So what's the difference between SegWit and just increasing max blk size to 4 MB in terms of bandwidth? there's no difference whatsoever.

- thirdly, SegWit will be introduced has a soft-fork. Listen, you're changing the very way we append data to the holy block chain and you are going to ask for permission only to the miners (sf)? Adding insult to injury you're going to deploy this feature in a minor release (0.12.x), are you kidding me?

I'm not even start considering all other things mentioned here (e.g. script versioning, ANYONECANSPEND madness,, block space clobbering due wtixd), the above 3 are enough for me to reject SegWit.

That said, in my opinion consensus rules have to be changed only via hard-fork, full stop.

 

[freetrader]

OK @Richy_T
I'd also like some input on opinions of what a viewer should come away with as the fundamental understanding once its been viewed.

I think SW is complex enough to merit a little presentation (e.g. 3 infographics), not trying to cram all its flaws on one.

One aspect - the facts about its soft-fork nature

Another : what it does to trustlessness, security and economics of the Bitcoin system
incl. opening the door to changing scripting language w/o meaningful consent (although this may be better on a completely separate slide since it is more an advanced and esoteric topic)

Third : perceived benefits vs actual benefits (and do we really need them now)

Something like that.

 

[Erdogan]

@Erdogan

yeah, i noticed.

how and why are you running nodes off ipv6?

All versions support ipv6 out of the box, and normally I get one or two connections. By setting the onlynet=ipv6 parameter, it announces the ipv6 address to other nodes, and uses ipv6 to connect to the 8 initial nodes. Anyway, ipv4 address is still open for connections.

I do it mostly because I can.

 

[Fatman3002]

I just checked nodecounter.com, looks like 1000 classic nodes went offline simultaneously.

 

[bluemoon]

@Fatman3002 looks like someone changed the count to exclude IPv6 nodes

https://www.reddit.com/r/btc/comments/4an8gc/so_i_refreshed_bitnodes21co_and_the_node_count/

 

[Dusty]

discounting witness data as a motivation to reduce UTXO seems plausible.

That's not needed: we could prune the signatures from current txs, if we want, it's just an implementation detail (of how to save tx on disk).

Also, to give a discount to who uses segwit is dishonest: this gives an advantage to those users while using the same resources on the net.
This is done to push the use of LN by discounting its transactions.
[doublepost=1458136335][/doublepost]

If the 2MB fork came first, SW as proposed would require a network that could handle the equivalent of 8MB blocks, we know from many independant tests, the most conservative of which say that the network can only handle 4MB blocks today, so a 2MB Hard Fork would leave SegWit dead in the water.

That's not correct: if you implement segwit with a hard fork (as it should be), you don't need the trick of using a anyone-can-pay tx and you can measure the block size correctly, so you have blocks of max allowed size as usual.

 

[Inca]

About SegWit (cross posting from Wall Observer thread):

- firstly it substitutes a scarse economic good, block space, with two new goods splitting the original in two parts. The first one is considered "noble", in fact it receives a completely arbitrary discount of 75% when computing tx fee. The second one is treated as "bad" and for some reasons won't get any discount. the former is tx signature, the latter it's transaction "body". This the worst part ever, it changes in a fundamental way bitcoin economic incentives.

- secondly it is falsely proposed as a scaling solution when it is not. Scaling it's a matter of bandwidth more than anything else, and guess what? with SegWit, as per current BIP, you could get 4 MB blocks. Those blocks has to be relaid and fetched by full nodes, only after validation phase a node could decide to drop the signature. So what's the difference between SegWit and just increasing max blk size to 4 MB in terms of bandwidth? there's no difference whatsoever.

- thirdly, SegWit will be introduced has a soft-fork. Listen, you're changing the very way we append data to the holy block chain and you are going to ask for permission only to the miners (sf)? Adding insult to injury you're going to deploy this feature in a minor release (0.12.x), are you kidding me?

I'm not even start considering all other things mentioned here (e.g. script versioning, ANYONECANSPEND madness,, block space clobbering due wtixd), the above 3 are enough for me to reject SegWit.

That said, in my opinion consensus rules have to be changed only via hard-fork, full stop.

At this stage it should be clear this is looking like an attack on bitcoin. Core appears to have lost the plot.

Can someone who is au fait on the fine technical details please post a summary and get it out on /r/btc and /r/bitcoin?

 

[adamstgbit]

[core will] deploy this feature in a minor release (0.12.x), are you kidding me?

LOL!
These core devs are true assholes that think everyone is stupid!
i can't believe they are being so disingenuous, where did you find this info? link?

 

[cypherdoc]

it's great to finally see so much more attention being focused on the negatives of SW outside this forum. keep it up!
[doublepost=1458141579][/doublepost]

That's not needed: we could prune the signatures from current txs, if we want, it's just an implementation detail (of how to save tx on disk).

Also, to give a discount to who uses segwit is dishonest: this gives an advantage to those users while using the same resources on the net.
This is done to push the use of LN by discounting its transactions.
[doublepost=1458136335][/doublepost]
That's not correct: if you implement segwit with a hard fork (as it should be), you don't need the trick of using a anyone-can-pay tx and you can measure the block size correctly, so you have blocks of max allowed size as usual.

you can see from the above poll, that even the SWHF version of this is rejected by readers of this thread; which arguably is a significant and influential segment of the community; certainly an early adopter segment.

anyways, Dusty, have you changed your mind on SC's, being a strong proponent? did you notice the brg444 comment i posted yesterday or the day before where it appears nothing significant has been done with them recently? more importantly, his comments last week that i posted here indicating he thinks he jumped the gun with regards to the 2wp/spvp merits?
[doublepost=1458141662][/doublepost]

@Fatman3002 looks like someone changed the count to exclude IPv6 nodes

https://www.reddit.com/r/btc/comments/4an8gc/so_i_refreshed_bitnodes21co_and_the_node_count/

what is AS20473?
[doublepost=1458141750][/doublepost]ah, nvm, AS20473 is Choopa.

 

[albin]

I'm glad this thread exists, @jl777 is applying a wrecking ball to this thing!:

https://bitcointalk.org/index.php?topic=1398994.0;all

 

[cypherdoc]

see what i told you? intentionally obscuring what the real purpose of SWSF; that is to facilitate and preferentially favor LN multisigs by using the diversion of consolidating the UTXO set:

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

 

[Dusty]

it's great to finally see so much more attention being focused on the negatives of SW outside this forum. keep it up!
[doublepost=1458141579][/doublepost]
you can see from the above poll, that even the SWHF version of this is rejected by readers of this thread; which arguably is a significant and influential segment of the community; certainly an early adopter segment.

Yes, but I don't care what the majority (or minority) thinks: I like to think with my brain and I like judging things on a technical level, not around politics.
I think that fixing tx malleability to allow LN (and probably many other ideas) and introducing some new capabilities like Schnorr signatures are a good improvement.
I don't agree on the way the core team is trying to push that though: their intent is clearly malicious and dangerous for the ecosystem.

anyways, Dusty, have you changed your mind on SC's, being a strong proponent?

You have a good memory! :-D
Like I said above I like to think with my head, and I still think that having two-way pegged sidechains is a nice improvement that can help in fostering innovation without disrupting the actual bitcoin network.
If sidechains does not happen innovation goes to altcoins (like ethereum) and Bitcoin lose market value.
If sidechains were possible we could have rootstock instead of ethereum and a billion more of market value...

did you notice the brg444 comment i posted yesterday or the day before where it appears nothing significant has been done with them recently?

That's understandable, if to efficiently implement two-way peg you need segregated witness first (I'm unsure though).

more importantly, his comments last week that i posted here indicating he thinks he jumped the gun with regards to the 2wp/spvp merits?

I'm sorry I'm not a native english speaker and I think I don't understand fully: what do you mean exactly?

 

[cypherdoc]

@Dusty

you know what they see about the Internet never forgetting? well, i never forget

here's brg444's revelations (finally):

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

I think that fixing tx malleability to allow LN (and probably many other ideas) and introducing some new capabilities like Schnorr signatures are a good improvement.

i agree with this. but not the way core dev is trying to do it with SW.

That's understandable, if to efficiently implement two-way peg you need segregated witness first (I'm unsure though).

actually, what everybody needs to realize is happening is that i think the 2wp/spvp with merge mining has now been deemed unworkable to Blockstream ala the maaku7 post here and what happened to OneName:


SO, as the alternative way to slip the SC's Elements projects into the code, they will be using this wide open script versioning of SW to insert CT at the beginning (they've said this) and the other Elements later on. and from there, who knows what else; Ethereum (they've said this too), Dogecoin, inflation, etc. This, combined with the SF workarounds elucidated in detail by Vitalik and jstolfi will cause all sorts of moral hazard changes to be inserted into the code in the future.

 

[Justus Ranvier]

So the truth is that sidechains/segwit is actually worse for scaling since for the same amount of security you need even more bandwidth to account for the additional overhead introduced by not having everything on one chain.

Which is exactly what we said all along (2013-08-22):

http://nakamotoinstitute.org/mempool/the-problem-with-altcoins/

Multiple block chains would reduce load on the network

In the Bitcoin network as it works today, all nodes receive all transactions. If Bitcoin grew to be a very large network, that could be a lot of transactions that all need to be communicated to everyone.

Altcoin promoters seem to imagine a world in which their own favorite altcoin has a status very roughly equal to that of Bitcoin, where each currency will be used for different kinds of things. This is impossible because the network effect always favors imbalance.

However, even in the very unstable situation of two roughly equal block chains, it is not necessarily true that there will be reduced network traffic as a result. If people had to work with both networks, they would still have to receive every transaction from both networks. And if people had to exchange their funds often enough from one currency to another to fulfill different purposes, this could easily result in a greater number of total transactions.

The only general benefit left is the supposed ability to shard validation, which is extremely dubious anyway since it's likely most of the sidechain users are going to end up being light clients too, just like on the main chain.

Also, a general-purpose fraud proof system (one that proves invalid transactions, non-existant inputs, and already-spent inputs) for the main chain is an even better type of sharding since any device with a non-zero fraction of the blockchain stored can check for double-spending and produce the appropriate proofs.

The worst part is that CT would be a great improvement to Bitcoin, but it won't matter how great it is if the process of adding it destroys Bitcoin.

 

[cypherdoc]

Go Gavin!

 

[Mengerian]

I think it is useful to think of segregated witness as consisting of at least three parts that can be considered separately:

1) Separation of signatures. SegWit is fundamentally just a reorganization of how transaction data is stored in blocks. It stores transactions in two parts, separated into two merkle trees. This makes pruning of signatures easier. It also helps with maleability, since the non-signature part of the transaction is not malleable (I guess you could still malleate the signature portion, which would only affect the witness merkle tree).

2) Scaling/witness discount/accounting tricks. This characteristic arises because of the block size limit combined with how they chose to implement Segwit as a soft fork. Since the witness portion of the merkle tree is not seen by old nodes, it is not constrained by the block size limit. They could have left the witness portion unbounded, made it fit within the 1MB limit, or added a static limit (eg. 4MB). Instead they chose to apply a formula with a 1/4 discount counting witness data towards the 1MB block size limit.

3) Changes to “witness” portion of transactions. This is where they include things like script versioning, non-quadradic scaling of sighashes, input signing, and various other changes. Again, none of these changes are intrinsic to SegWit, but the way it is introduced as a soft fork gives them an opportunity to include this set of changes they want. Some of these changes are nice, but they could just as easily be introduced separately in bite-sized portions, rather than shoved down everyone’s throats in one large clump.