Segregated Witness Sotf fork (Segwit) Pros and Cons

[Lee Adams]

Another great resource for considering the pros and cons:

https://bitcoin.consider.it/segregated-witness-as-a-soft-fork

 

[adamstgbit]

I don't think so. I'm not sure about this, though and should probably shut up. But I'm guessing: Segwit outputs go to ANYONECANSPEND? So the wallet wouldn't even recognize the output(s) as belonging to any of its keys.

another view: if you're sendig to the wallet you have to output to the hash of one of its pubkeys. Once you do that, though: the wallet can spend those funds by definition.
[doublepost=1458147746][/doublepost]Why are we even talking about the possible cons of segwit?

Who needs this and what are the pros?

Why would we want it?

The whole things seems like a huge resource hog (I mean community / dev / ...)

i think you're wrong

older node will only THINK it's an anyone can spend Tx.
the rest of the network will see it as an invalid segwit TX because the sig is wrong, older node wont be able to make that determination as far as they know it's an anyone can spend TX addressed to my pub key?

someone with a better handle on the finer points of temporal mechanics might be able to help us out.

 

[sickpig]

It looks a bit one sided for now. Some of these Pros are devil's advocate, but still need to be included and discussed.

Pros:
It fixes third-party transaction malleability.
It allows the ability to more easily upgrade Bitcoin’s Script language.
Possible 66% additional improvement in bi-directional channel efficiency by consolidating channel open and close operations.
It includes fraud proofs.
The above points will also enables sidechain type contracts.
It is supported by developers who (according to GitHub) generated more than 90% of all commits to Bitcoin Core in 2015.

Cons:
Allowing more complex script language could open up attack vectors.
[doublepost=1458122827,1458121864][/doublepost]2 more from the core FAQ. Again pretty weak and contradictory ones IMHO, but should be discussed.

Pros:
A modest reduction in fees.
Allows miners to put more transactions in their blocks, which may allow them to increase their per-block revenue.

corrections on listed pros:

- it does not currently include fraud proof validations and it won't include it even in the first deployment.
- the fact the has been developed by active devs it's not pro related to the technology

cons addendum:

- introduced by a soft-fork, by a bad trick IMHO, just one word ANYCANSPEND
- it's falsely proposed as a scaling solution. Once again: SegWit is not a scaling solution.
- the worst for last: it changes the bitcoin economic incentives that are regulating the access to one fundamental good: block size space.

the latter is so pernicious that it literally makes me freak out.

The last I've heard from Adam 'individual' Back is that SegWit will fix a long standing incentive bug in bug, see for yourself:

 

[jl777]

using segwit for scaling is like using a microwave oven to get better internet bandwidth.

It arguable works to some extent, but does require some egregious behavior
[doublepost=1458150393][/doublepost]

i think you're wrong

older node will only THINK it's an anyone can spend Tx.
the rest of the network will see it as an invalid segwit TX because the sig is wrong, older node wont be able to make that determination as far as they know it's an anyone can spend TX addressed to my pub key?

someone with a better handle on the finer points of temporal mechanics might be able to help us out.

what happens to the segwit anyone can spend tx when it is sent to another node that is not segwit enabled?

dont we end up with a bunch of transactions that have to be trusted to be valid?

Is it my imagination, or doesnt this make bitcoin like ripple?
[doublepost=1458150487][/doublepost]ripple has 5 validating nodes, last i checked. Sometime when things are felt to be safe enough, external nodes will be allowed to validate. that was as of last year, maybe they allow it now?

ripple allows any ledger to be modified, any account to be frozen
but you can trust that it will only ever be done to protect the women and children, so if you are against this you must be a terrorist

 

[adamstgbit]

@sickpig

it changes the bitcoin economic incentives that are regulating the access to one fundamental good: block size space.

the economic incentives change you are referring to you is " tx size will be smaller so the fees on each tx will be smaller " ?
[doublepost=1458151666,1458150521][/doublepost]

dont we end up with a bunch of transactions that have to be trusted to be valid?

I should be able to make a invalid segwit TX that spends someone else's 10,000BTC, and fool the older nodes into thinking i just sent them 10,000BTC, i'll have to send it directly to the node, and it will never confirm, but still the old node will not be able to validate so it will and see a 0 conf. 10,000BTC payment sent to it.

for older nodes this is true( i think. ), but the new nodes will know where to get the signature(aka witness) and don't rely on trusted nodes to validate.

edit: this is probably doable right now... just make a TX with NULL as the sig, node appect this as a anyone can spend TX,

"anyone can spend TX" is badly worded it should be call a "someone will sign this later TX"

i think...
[doublepost=1458151948][/doublepost]here somthing else to think about

i mine a segwit-block with 1000 transaction the network has not yet seen ( i the miner created these TX myself )
I have the witness data readily available.
when other miners try to validate this block they will go through every single one of these TX and say

"i dont have the witness data for this TX_ID, i have to call TCP::GetWitnessData( TX_ID ) aw yes this is valid"

miners have to do this 1000X to figure out the block is valid???


EDIT: i'm not sure wtf i'm talking about. does this make any sense? who's to say.... Lol.

 

[jl777]

it requires a lot more work for each tx and more space
but it is a lot of work to implement
and it degrades the security level, even to the point of requiring trusted tx (chain of segwit spends to non-segwit nodes)
full nodes get SPV level security

then again pruning nodes that are at 2GB space now can get even smaller, so this is a big giant win for the pruning nodes.

luke-jr admits that segwit doesnt save HDD space. hasnt answered about how much extra space it takes. If needed I will pester them with nasty questions about the overall workload needed

and they want to softfork this in 6 weeks?????

 

[Lee Adams]

i mine a segwit-block with 1000 transaction the network has not yet seen ( i the miner created these TX myself )
I have the witness data readily available.
when other miners try to validate this block they will go through every single one of these TX and say

"i dont have the witness data for this TX_ID, i have to call TCP::GetWitnessData( TX_ID ) aw yes this is valid"

I've added this to https://bitcoin.consider.it/segregated-witness-as-a-soft-fork?selected=/point/10352 for visibility.

I assume this is not an issue pre-seg wit as the block contains all the transactions and proofs and no extra network resources are required once the block is published.

 

[adamstgbit]

I feel as tho i cannot trust the devs to try and break segwit, and figure out the security holes it might create.
there busy trying to make it all work, i fear they will attempt to push it out with the first impl that passes a few test, and will not stop to think about how to break it. scary though....

because of this i feel the need to try and break it myself, or at least come to an understanding of the trade-offs involved, hell i'll settle for a basic but correct understanding of all this segwit shit.

@jl777
segwit doesn't save HDD space??? how can this be the signatures won't be stored in the blockchain

 

[jl777]

calling the witness data not the blockchain assumes you are talking about non-validating nodes. for a validating node, all the sigs are needed, plus at least 3 bytes per tx, but I dont understand how it is encoded that small

maybe it is more cost per tx, the latest is 2 bytes per tx + 1 byte per vin

 

[adamstgbit]

all the sigs are needed, until the block is confirmed then validating full node can drop the witness data forever.

where will the witness data be stored if not in the blocks???

if you tell me the witness data is stored in the block but not counted toward blocksize my brain will explode.
[doublepost=1458158182][/doublepost]if the witness data is not stored in the blockchain, we have to trust full nodes to keep this data around forever?

after the block is all confirmed and such, and i want to get the witness data for a TX_ID how will i confrim the integrity of the witness data relayed by a node?
I can't! i must store the witness data myself forever, or forever rely on trusted nodes to give me this data again when i need it!
this literally saves no blockspace whatsoever!
and because they want to sotf fork it, it will actually cost MORE space.

 

[molecular]

My opinion on segwit is not fully formed, but right now it is:

It should not be rushed. We need at least 3 years of testing it in a meaningful altcoin, then I would say we discuss for another 3 years and then, when 95% of wallets have implemented, we wait 2 more years grace period and can start the rollout.

 

[jl777]

if the proportionate time taken on the 2MB hardfork is used, considering that segwit is more changes than all prior BIP's combined, I think the timeframe needed would be on the order of centuries.

I mean, on the one hand we have:
#define MAXBLOCKSIZE 1000000 -> 2000000

versus:
something that after a full day, I am still not sure what all is needed

 

[adamstgbit]

witness data gets moves from the part of the block which is mandatory to save to disk to the extra data part each block.

the witness data would be optional to store and transmit when saving or relaying a block.

meaning "full-nodes" will save only the mandatory TX_DATA without any witnesses!
meaning "full-nodes" will now save what they BELIEVE to be the correct set of TX for a given block with no way of checking the data.

WTF WTF WTF

everyone will continue to save the witness data, they are nothing more than SPV's if they dont, and not a shit thing has changed.

oh ya tx_id is calculated differently

BUT THAT CAN BE SOFTFORKED SEPARATELY ANYWAY

i can't believe this.
[doublepost=1458161290,1458160336][/doublepost]segwit is a fraud!

next thing you know they will propose saving the blockchain to a pen drive as a way a reducing the total size of the blockchain
[doublepost=1458161614][/doublepost]if they wanted to do this properly only TX_ID would be counted toward blocksize everything witness data and tx data would be moved out.

when miners mine a new block they broadcast a list of TX_ID thats all, every peer on the network either has the TX itself on hand or can ask for it.

 

[Lee Adams]

The witness data is only needed before transactions are confirmed in a non-reorganisationable block. We say 6 blocks are good for this, because there has never (seldom?) been a 'valid' orphaned chain longer than this. In reality the depth is probably more like 1000 before witness data is dropped.

Why can we trust this when we no longer have the witness data? Because in order to confirm a transaction in a block, the witness data MUST be valid. Therefore if a transaction is in a block in the chain, then the witness data must have been valid.

 

[adamstgbit]

i understand that.

but once a TX is 1000 confirms and the witness data is lost.
a new user cannot verify that TX himself. he must trust the nodes he is dwling his blockchain from are being honest.

why does the client bother validating when its syncing?

with segwit the client will not only not bother validating when its syncing, it won't be able to at all.

is that a problem?
idk.

 

[Lee Adams]

a new user cannot verify that TX himself.

That's the point. It's in a block and that block has POW on top of it. ergo it must be valid and thus the new user has verified it. e.g. that it has come from one address and been sent to another. The ledger is therefore in tact. Am I missing something?
[doublepost=1458171034][/doublepost]i.e. He doesn't have to trust any one node, just the POW on the block and subsequent blocks.

 

[AdrianX]

theoretically, couldn't i fool a non-segwit full node to believe I sent it BTC??

i simply send it a segwit TX with invalid signature, it can't validate the fact that the signature is invalid, because it sees the TX as a anyone can spend TX.

you have to wait until the financial collapse, and then ask PwC to instruct BS/Core to fix it. that feature is unlikely to be made available to you and I.

 

[AdrianX]

whats becoming increasingly apparent is the need to keep bitcoin relatively simple, it's a hard concept to grasp when one is first introduced to it but its fundamentally elegant and easy to understand

a con. adoption could be slower if fewer people trust and understand it.

is my understanding correct that SW introduces a lot of complexity in understanding how all transactions are guaranteed valid. it becomes particularly concerning when one has typical transactions v0.11.2 and then one has SW transactions. Theses two sets of transactions effectively reside in 2 different networks, if a v0.11.2 node gets a SW transaction it can not spend it because it can't validate the utxo dataset. and the valid utxo dataset resides only on an implementation that is not secured by mandatory PoW and the longest chain, but Software version of Bitcoin that is run by miners as optional upgraded version.

 

[adamstgbit]

I like that con i think its a noteworthy point that technical mind will miss, its included in the OP.

Bitcoin is fairly simply to explain, poeple can trust it because they understand it, segwit makes understanding bitcoin an order of mangure more complex, which could lead to poeple not trusting bitcoin.

i sorta understand segwit, but to me forgetting about witness data after Xnumber of blocks sounds like it could cause some kind of security hole down the line, or make some new feather impossible to code or somthing. at the very least you can say it reduces redundant security, and when it comes to security redundancy is not a bad practice....

when you get down to it, segwit will not reduce network load, it will increase it by the same amount as if we had simply had 2MB blocks if not more because they want to keep it as a sotffork, now every block needs 2 mercal trees, and wastes space to accommodate "backward compatibility".

if we are going to go the segwit route, why not have the block chain only keep TX_ID thats it thats all. all the block really need to agree on is the order of TXs; the details of the TX is not citrial info its just nice to remember, as long as everyone keeps track of the order of TX thats all that really matters.

enter, Segregated Transition Details!

after 6Block have pasted, nodes could be made to completely forget everything about a TX expect its ID
nodes simple keep track of "all spendable input" and this blockchain list of TX_IDs.
as new TXs come in the node checks them, and temporally remembers all the details.
Once a new block(which only includes the TXIDs) is received by a node the node updates its spendable input table and saves the block(which only includes the TXIDs) and forgets about all the details of the TX and any double spends.
we keep track of the order of TX_ID in blocks only as a way to agree what TX is a double spend.
once the TX_ID is recorded in the block and your spendable input table updated, the details of that TX are irrlenvelt you know your spendable inputtable will always match everyone else's because you know you processed the TX in the same order as everyone else. hell you could only save the last 6 blocks worth of TD_IXs and you'd still be fine.
no one can double spend because everyone's spendable inputs table always matches.
the storage requirement are boiled down to a list of all spendable inputs + 6blocks worth of TX details +6blocks of TX_IDs.

I've solved it! i've solved bitcoins scaling problem!
what could go wrong... it makes perfect sense in my head!

TL;DR;
don't bother its craziness...

 

[adamstgbit]

i think the pros and cons in OP are fairly complete now.