Happy Anniversary, SEGWIT!

[squatter]

the only 'thing' that segwit is useful for is being a gateway format for alternative networks like LN and sidechains, but as we all know LN and sidechains are not bitcoin

Segwit's script versioning also allows the introduction of new signature schemes relatively easily via soft fork. It makes implementing Schnorr signatures much easier. Schnorr signature aggregation can provide significant space and fee savings.

[1715643723]

1715643723

[1715643723]

1715643723

[DooMAD]

the only 'thing' that segwit is useful for is being a gateway format for alternative networks like LN and sidechains, but as we all know LN and sidechains are not bitcoin

Segwit's script versioning also allows the introduction of new signature schemes relatively easily via soft fork. It makes implementing Schnorr signatures much easier. Schnorr signature aggregation can provide significant space and fee savings.

Which is brilliant.  But, let's be honest, based on his posting history, it's not like franky1 is going to be thrilled about the prospect of making implementing features via soft forks easier, now, is it?  

In b4 he posts "another Core plot to bypass consensus blah, blah, blah".  

[Wind_FURY]

Setting the precedent that the community can push back against the mining-cartel's politicizing in the network, the worst thing?

of course, the ideology is great but as i said the implementation of it was horrible. it had an almost guaranteed chance of splitting bitcoin and that is the worst thing that could ever happen to bitcoin. Lest we forget, the "community" or more precisely the nodes which were signalling for BIP148 were only 11% of the total nodes.

It wasn't ideal, I admit, but it was what's best in that circumstance in my opinion. It showed that the top miners, and the top merchants can't co-opt the network.

Yes, UASF was the minority, but many supported Segwit's activation.

true, we were supporting activation of SegWit but with >95% support of miners to prevent any kind of damage caused by splitting the network.... just like any other previous forks that we had with the same process. a process that works and has nearly no risk.

"Miners" of which was really Jihan Wu, and his friends, who politicized the signalling process to activate. He got his war, it didn't end well for them.

[Khaos77]

"Miners" of which was really Jihan Wu, and his friends, who politicized the signalling process to activate. He got his war, it didn't end well for them.

Oh I think Mr. Wu is doing better than most here.  

Source: https://en.wikipedia.org/wiki/Jihan_Wu

Jihan Wu (Chinese: 吳忌寒) is a co-founder of Bitmain (with Micree Zhan), and a prominent supporter of Bitcoin Cash.
In 2018 he was ranked number 3 in Fortune's The Ledger 40 under 40 for transforming business at the leading edge of finance and technology.
His net worth in 2018 was US$$2.39 billion.

@WindFury, and your non-mining node still earns $zero before and after segwit. 
Does not look like you personally won anything.

[DooMAD]

   devs want to introduce new opcodes to segwit that reintroduce malleability into segwit

I've heard this before, but couldn't any detailed info. Do you know any info or which opcodes which you  believe will reintroduce malleability?

He has been asked this question on numerous occasions and never answers it.  Also, his story has already changed since March, when he claimed they had already introduced it.  Now they apparently only want to introduce it:

recently due to new feature needs. core devs introduced a new sighash opcode that actually allows segwit tx's to malleate again..

So if they have introduced it, which one is it, Francis?  Which one allows malleation?  

I'm starting to think he doesn't actually know what the difference between a sighash flag and an opcode is.  But here he is on his little soapbox telling us that the developers don't know what they're doing.  

[pooya87]

    devs want to introduce new opcodes to segwit that reintroduce malleability into segwit

I've heard this before, but couldn't any detailed info. Do you know any info or which opcodes which you  believe will reintroduce malleability?

franky1 is known to be a drama queen about everything when SegWit is involved
he may be talking about BIP-118 which "proposes" addition of a new sighash called NoInput. i don't know what it has anything with malleability but i have seen some concerns raised about it specially for when you do address reuse. although like many of the BIPs it is just a proposal that is not accepted.

https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001242.html

[Msworld83]

The fork happen 2years back when there was a reason for split between the blocks size and claim for real btc , this has been a great journey so dar for the btc as the lightning as help reduce the scalability of the btc and make the transaction more fast than expected.

[adaseb]

This thread sure brings back memories and its crazy how 2 years ago feels more like a decade in Crypto years. I used to be all over Reddit, Twitter and Bitcointalk and hear all these people going back and forth whether to activate it or not. There was that UASF campaign and then that Antminer CEO who controlled so much hashrate that the SEGWIT activation was more or less in his hands. Times were crazy.

It was so crazy that its the reason why I never sold my BCH after Aug 1st, because if for some odd reason BCH became the dominant chain and basically had a flippening, then I wanted to be hedged completely so I just held both coins. Which was smart since BCH shortly after was in the 4 digits.

Those sure were the days.

[pooya87]

BCH became the dominant chain

how exactly do you define "dominant chain"?
- having a minuscule hashrate, difficulty and proof of work compared to bitcoin?
- having a manipulated difficulty adjustment so they could mine 1000+ blocks per day compared to the normal ~144 blocks per day?
- being centralized?
- not being immutable due to the fact that they rolled back a bunch of blocks they didn't like using their centralized power?
- maybe by price, being worth 0.028BTC?
- or maybe by block size having blocks that are on average have always been much smaller than bitcoin? (200 kb BCH versus 1.3 MB bitcoin)

[Carlton Banks]

BIP-118 "proposes" addition of a new sighash called NoInput. i don't know what it has anything with malleability but i have seen some concerns raised about it specially for when you do address reuse. although like many of the BIPs it is just a proposal that is not accepted.

https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001242.html

the proposals (BIP118 is just one such proposal) for no-input opcodes don't malleate the transaction hash, that's not possible anymore.

They do alter (or malleate if you prefer) which input is used after the transaction has been written (but obviously not once it's confirmed)

This makes payment channel protocols much better. Using them for on-chain transactions has no benefit, and comes with the risk you mention; if you reuse an address, and you sent a no-input transaction from that address once before, someone could replay the old transaction to spend the newer input, as the old transaction didn't specify a particular input (hence "no-input"). But no wallet developer is going to give you the option to use no-input onchain, that'd be dumb

still, the devs have been talking about exactly how to design the no-input feature for maybe 1 year now. they're being very careful, because it's definitely possible for the user to shoot themselves in the foot if they get too inquisitive and start trying to use no-input in transactions without understanding how it could backfire on them. It's not possible to do anything like that in Bitcoin transactions now, all the footguns were taken out of the scripting language years ago

[Wind_FURY]

"Miners" of which was really Jihan Wu, and his friends, who politicized the signalling process to activate. He got his war, it didn't end well for them.

Oh I think Mr. Wu is doing better than most here.  

Source: https://en.wikipedia.org/wiki/Jihan_Wu

Jihan Wu (Chinese: 吳忌寒) is a co-founder of Bitmain (with Micree Zhan), and a prominent supporter of Bitcoin Cash.
In 2018 he was ranked number 3 in Fortune's The Ledger 40 under 40 for transforming business at the leading edge of finance and technology.
His net worth in 2018 was US$$2.39 billion.

@WindFury, and your non-mining node still earns $zero before and after segwit. 
Does not look like you personally won anything.

But yet because of fear of losing, he and his friends activated Segwit, crushed by non-earning nodes.

Simply, Segwit was starting to gain ground in the community, and in some of the Core developers. UASF were nodes "saying" that they only want a type of block, if miners can't give that type of block, their blocks will be rejected.

The miners believe in economic reality. They had no choice. The first miners to follow the community, and the developers will be the winners, and the miners left will be the losers. Why do you believe Segwit won?

[franky1]

but concentrating just on segwit.. lets list what segwit promised and if it has/hasnt achieved it
1. better transaction capacity: no
    bytes per transaction has got worse since segwit.
    segwit is actually more bloaty.
    even with a 1.3x byte growth compared to ~2015 stats the tx count has not risen by 1.3x

But the reality says otherwise due to max. block size change from 1MB to 4.000.000 weight unit and SegWit have lower transaction weight size.

dang you really are believing the propaganda.
segwit does not have lower transaction BYTE hard drive storage size. it has UNCOUNTED size which they refer to as Virtual byte. these virtual bytes are used to make all the weight of a block appear as 1mb to not break the now outdated1mb rule

but when it comes to WEIGHT which does account for actual bytes. segwit tx actually uses more bytes compared to a legacy tx of same input/output count

maybe best to learn about segwit and how it mis-counts bytes

2. fee efficiency: no
    fee's in 2015 where pennies with a top price of 25cents before users complained. fees now are more by averaging 25c

And without SegWit and SegWit adaption, it'd be worse since less transaction would fit info a block which would increase avg transaction fees.

Besides, using cents rather than satoshi makes your comparison useless because because Bitcoin price in 2019 is higher than 2015

same could be said about the other way, using satoshi's instead of cents. less people are transacting as often because the cost is so high

the grand debate of bitcoins purpose WAS about a open currency without borders. yet the tx fee of bitcoin has ruled out utility to many countries of unbanked people

i am british but i travel alot. and while i see americans literally wanting to orgasm at the desire of a $20 tx fee to co-erse people over to LN so the west can make income as fee grabbing hubs, watchtowers, factories and routers. but the 3rd world countries are literally ignoring bitcoin because its been outpriced and made only fit for what they call the 'wall street crowd'

    devs want to introduce new opcodes to segwit that reintroduce malleability into segwit

I've heard this before, but couldn't any detailed info. Do you know any info or which opcodes which you  believe will reintroduce malleability?

i have been subtle to tell some that i will offer them no input into their research of discovering which opcode will introduce malleability into segwit

if you cant figure it out, maybe you need to do more research

[franky1]

the proposals (BIP118 is just one such proposal) for no-input opcodes don't malleate the transaction hash, that's not possible anymore.

They do alter (or malleate if you prefer) which input is used after the transaction has been written (but obviously not once it's confirmed)

no input does malleate the tx hash
the tx hash is created by hashing a complete tx. and as you yourself said no input can alter a input after its been written

the point being if i was using no-input, i made a tx and then copied the tx hash to then monitor the blockchain for broadcasts. whomever gets the tx next  could then add more inputs, take away inputs. which would alter the tx hash.

what no-input does is allow alterations of inputs without needing to change the signature script. its the signature that dos not alter. but the tx hash does.. which is what malleability is all about. altering the tx hash to broadcast a tx using an altered hash so someone monitoring a specific hash wont see it.

[Wind_FURY]

   devs want to introduce new opcodes to segwit that reintroduce malleability into segwit

I've heard this before, but couldn't any detailed info. Do you know any info or which opcodes which you  believe will reintroduce malleability?

i have been subtle to tell some that i will offer them no input into their research of discovering which opcode will introduce malleability into segwit

if you cant figure it out, maybe you need to do more research

Welcome back! But,



More misinformation from franky1, what's new. You can't show anything/offer no input because there's nothing. Happy 2nd Segwit Anniversary!

[franky1]

the only 'thing' that segwit is useful for is being a gateway format for alternative networks like LN and sidechains, but as we all know LN and sidechains are not bitcoin

Segwit's script versioning also allows the introduction of new signature schemes relatively easily via soft fork. It makes implementing Schnorr signatures much easier. Schnorr signature aggregation can provide significant space and fee savings.

Which is brilliant.  But, let's be honest, based on his posting history, it's not like franky1 is going to be thrilled about the prospect of making implementing features via soft forks easier, now, is it?  

In b4 he posts "another Core plot to bypass consensus blah, blah, blah".  

which is a trojan horse. imagine the blockstream/barrysilbert team (many exchanges, merchants and devs that made up the majority of the NYA agreement) decided to add a new script that allowed any input to be added even if the signature didnt link to the input (eg i put doomads utxo's into a tx to me, without the signature needing to prove im doomad's utxo owner).

there are many many other dangerous implementations that can be added and by having its as 'soft fork' (no consensus required) means that there is no way to prevent it.

[franky1]

   devs want to introduce new opcodes to segwit that reintroduce malleability into segwit

I've heard this before, but couldn't any detailed info. Do you know any info or which opcodes which you  believe will reintroduce malleability?

i have been subtle to tell some that i will offer them no input into their research of discovering which opcode will introduce malleability into segwit

if you cant figure it out, maybe you need to do more research

Welcome back! But,



More misinformation from franky1, what's new. You can't show anything/offer no input because there's nothing. Happy 2nd Segwit Anniversary!

i think the subtly game is up due to pooya revealing NO input.. if you didnt get the hint when i was being subtle about offering no input.. maybe you just didnt get the hint

i literally in several topics told people including yourself i was both being subtle.. and i was offering them NO_INPUT

and one in particular doesnt like it when im being subtle but give him no input

just because you didnt get it, doesnt mean i didnt "show anything/offer" and doesnt mean "there's nothing"

but now its been presented to you clearly. i hope you actually do some research on the matter. and i mean read code and documentation. not just get propaganda fluffy cloud speaches from friends that cover up the true risks.

EG doomad saying he loves schnorr and soft forks. which shows he has not looked into the risks and is just fluffy clouding

[franky1]

He has been asked this question on numerous occasions and never answers it.  Also, his story has already changed since March, when he claimed they had already introduced it.  Now they apparently only want to introduce it:

recently due to new feature needs. core devs introduced a new sighash opcode that actually allows segwit tx's to malleate again..

I'm starting to think he doesn't actually know what the difference between a sighash flag and an opcode is.  But here he is on his little soapbox telling us that the developers don't know what they're doing.  

1. july 2018 (14 months ago) devs introduced the new feature which they said would be included in the next segwit script update
2. devs were actually playing around with it meaning those with applications that had it in could use it.
3. the words i used were not 'publicly activated feature'
4. the words i used were "introduced".. which is the case
5. as shown by many quotes i could offer you, including one example i put into previous post to windfury. i have actually been telling people about no input since last year. shame you couldnt pick up on the subtly too
6. no input is both a sighash and opcode. if you dont think its a sighash then maybe you should review the bip which literally calls it SIGHASH_NOINPUT
7. you can do all you want trying to insult a forum username by attacking the personality. but if you do your research you will end up agreeing with the stuff i mention. (once you wipe away your 'fluffy cloud only mention positives' mindset)

people on this forum dont want to know only the fluffy positive propaganda which they will get from adverts and people promoting bitcoin. people want the real information which includes the negative.. remember to be on this forum they must have already heard of bitcoin. so there is no need to be trying to positively sell people on the fluffy cloud features. because they have already been introduced.. instead they want proper and real information

instead of trying to hide the negatives.. you should also be highlighting them.
a great currency is one that recognises its flaws and fixes them. not works around/hides them
if you actually cared for bitcoin then you would have the old mindset of the original devs that actually wanted people to try to find the flaws and try to break bitcoin so that bugs can be fixed.

P.S segwit is not a bugfix. its a gateway tool for another network

[Wind_FURY]

just because you didnt get it, doesnt mean i didnt "show anything/offer" and doesnt mean "there's nothing"

You "get it", OK. Or you claim you get it. But it doesn't mean there's "something", especially from your history, your anti-Core bias, and your pro-increase-block-size-or-die-propaganda.

[DooMAD]

people on this forum dont want to know only the fluffy positive propaganda which they will get from adverts and people promoting bitcoin. people want the real information which includes the negative.. remember to be on this forum they must have already heard of bitcoin. so there is no need to be trying to positively sell people on the fluffy cloud features. because they have already been introduced.. instead they want proper and real information

instead of trying to hide the negatives.. you should also be highlighting them.
a great currency is one that recognises its flaws and fixes them. not works around/hides them
if you actually cared for bitcoin then you would have the old mindset of the original devs that actually wanted people to try to find the flaws and try to break bitcoin so that bugs can be fixed.

How about you actually wait to see how it's implemented before you completely jump the gun with your alarmist 'sky-is-falling' nonsense, where you insinuate we're locked into a course where SegWit transactions will be malleable?

You could have phrased it that if the feature was implemented incorrectly, it had the potential to allow malleability.  But you chose to phrase it in the way that you did, making it sound as though malleability was the only conceivable outcome. 

You just can't help yourself.  Stop pointing the finger at other people when they call you out on the undeniable fact that you bring it all on yourself.  People would stop calling your integrity into question if you stopped giving them every reason to.

If it looked likely that the proposed feature would reintroduce malleability and devs still wanted to push ahead with it, then I would absolutely question that decision, just as I suspect everyone else here would.  Which is precisely why such an outcome is unlikely to ever occur.  But not once in the course of your last few years of your mindless FUD have you ever come close to making a reasonable statement like that.  As such, you deserve all the attacks people make on your character.  I can't even begin to comprehend how you look in a mirror and like what you see.  You are scum.

[ABCbits]

but concentrating just on segwit.. lets list what segwit promised and if it has/hasnt achieved it
1. better transaction capacity: no
    bytes per transaction has got worse since segwit.
    segwit is actually more bloaty.
    even with a 1.3x byte growth compared to ~2015 stats the tx count has not risen by 1.3x

But the reality says otherwise due to max. block size change from 1MB to 4.000.000 weight unit and SegWit have lower transaction weight size.

dang you really are believing the propaganda.
segwit does not have lower transaction BYTE hard drive storage size. it has UNCOUNTED size which they refer to as Virtual byte. these virtual bytes are used to make all the weight of a block appear as 1mb to not break the now outdated1mb rule

but when it comes to WEIGHT which does account for actual bytes. segwit tx actually uses more bytes compared to a legacy tx of same input/output count

maybe best to learn about segwit and how it mis-counts bytes

I didn't say SegWit transaction have smaller size in byte and i know the fact SegWit transaction have bigger size in byte, what i said are :
1. SegWit transaction have far lower weight size
2. SegWit indirectly allow higher TPS because max. block size changed from 1MB to 4 million weight unit

2. fee efficiency: no
    fee's in 2015 where pennies with a top price of 25cents before users complained. fees now are more by averaging 25c

And without SegWit and SegWit adaption, it'd be worse since less transaction would fit info a block which would increase avg transaction fees.

Besides, using cents rather than satoshi makes your comparison useless because because Bitcoin price in 2019 is higher than 2015

same could be said about the other way, using satoshi's instead of cents. less people are transacting as often because the cost is so high

Fair point, but the fact average transaction fees would be higher without SegWit remains true

the grand debate of bitcoins purpose WAS about a open currency without borders. yet the tx fee of bitcoin has ruled out utility to many countries of unbanked people

I agree with your opinion, but few people also argue that's the cost of decentralization.