kano (OP)
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 03:58:36 AM |
|
So ... I'm wondering why we should put up with an increase in the amount of disk space required for segwit for the same number of transactions?
Why do we NEED segwit?
Simply increasing the block size will have the same effect without making individual transactions bigger. segwit makes individual transactions bigger.
Now the only argument I've seen given for this is that if you ignore the segwit data you can run a smaller blockchain.
However, if instead you run a pruned blockchain it will be smaller, so I see the segwit excuse as FUD.
More so, saying you don't need the segwit data is the equivalent of saying SPV mining is OK.
As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?
Anyone got some answers that doesn't skip over and ignore these issues?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8647
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 06:14:15 AM Last edit: April 24, 2016, 06:24:16 AM by gmaxwell |
|
segwit makes individual transactions bigger.
It does not. (unless you want to count a byte or two from flagging in particular serialization which could simply be compressed out, if anyone cares). You should read the FAQ: https://bitcoincore.org/en/2016/01/26/segwit-benefits/Key advantages include solving malleability, facilitating safe script upgrades, lowering resource usage for lite clients, allowing additional capacity without significant additional UTXO bloat risk (in fact, it largely corrects the issue that creating additional UTXO is significantly cheaper than cleaning them up). In doing so it significantly reduces some of the risk points in increased capacity. saying you don't need the segwit data is the equivalent of saying SPV mining is OK The network consists of more than just miners, segwit doesn't change the data miners need. Allowing a continuum of options in using the network is important for avoiding some users being 'priced out' by the operating cost of it. As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit? Segwit is the only proper solution for malleability. The only other alternative is long lists of canonical encoding rules-- a mess of bandaids which, at best, only solve it for a subset of transaction types-- and even then maybe not (it's very hard to be sure that a set of canonical encoding rules is actually sufficient to guarantee non-malleability). That kind of patchy approach is a huge pile of technical debt that would make it much harder to implement and maintain the consensus code in Bitcoin implementations.
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 06:18:04 AM |
|
Why do we NEED segwit? We do not need either segwit or any other technology. We need profit. Nobody knows how to make profit from bitcoin, so they are listening "gurus". Segwit is the only proper solution for malleability. Why do we need solution for the thing what is not a problem? ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8647
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 06:19:32 AM |
|
We need profit.
Pump at all costs altcoins are ----> over there. Why do we need solution for the thing what is not a problem? ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) It's a problem for some things and not others. The fact that whatever you're doing might not be bothered by it isn't a reason that it shouldn't be fixed for others that care about it.
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 06:23:44 AM |
|
We need profit.
Pump at all costs altcoins are ----> over there. Do you mean something like Black Wednesday? Sooner or later there will be something similar here.
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1012
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 01:17:06 PM |
|
We don't NEED SegWit, we need something that can make us scale properly.
SegWit is being proposed and supported because it is a conservative approach.
SegWit is not a waste of disk space, as far as I could see, it is instead a way of rearranging the "house", organising furniture in order to have more space, speaking figuratively.
As for the rest, gmaxwell said pretty much everything.
|
|
|
|
Lauda
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 25, 2016, 04:48:33 PM |
|
We don't NEED SegWit, we need something that can make us scale properly.
Your statement is contradictory. LN will make the network scale 'properly'. LN requires Segwit, therefore we need Segwit.
OP it seems like you've read some false information somewhere. There are certain places that you should stay away from.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
TPTB_need_war
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 25, 2016, 05:07:34 PM |
|
Segwit is the only proper solution for malleability.
Technical reference please so I can verify?
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 25, 2016, 10:06:27 PM |
|
Segwit is the only proper solution for malleability
There is some confusion between the concept of not including the signature in the txid and the particular package of changes that is being done in Core that does this and more but is also commonly called sigwit.
|
|
|
|
Fatman3001
Legendary
Offline
Activity: 1526
Merit: 1013
Make Bitcoin glow with ENIAC
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 26, 2016, 02:14:30 PM |
|
We don't NEED SegWit, we need something that can make us scale properly.
Your statement is contradictory. LN will make the network scale 'properly'. LN requires Segwit, therefore we need Segwit.
OP it seems like you've read some false information somewhere. There are certain places that you should stay away from. I'd love to hear kanos view on LN. Maybe he could explain it in a way that doesn't result in a loose bowel.
|
"I predict the Internet will soon go spectacularly supernova and in 1996 catastrophically collapse." - Robert Metcalfe, 1995
|
|
|
mookid
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 27, 2016, 01:24:22 AM |
|
We don't NEED SegWit, we need something that can make us scale properly.
SegWit is being proposed and supported because it is a conservative approach.
SegWit is not a waste of disk space, as far as I could see, it is instead a way of rearranging the "house", organising furniture in order to have more space, speaking figuratively.
As for the rest, gmaxwell said pretty much everything.
I think you were severely misled. SegWit was necessary, I for one, despite the fact that the Bitcoin's scale problem was left unresolved for so long, I mean, IPv6 was underworks 20 years before IPv4 addresses ran out. Sure, creating a consensus is hard when you have a decentralized network, but let's be honest, miners will jump on everything you throw at them (if it's beneficial). I have confidence in the developers to go through this, and I hope the community is mature enough to support the good decisions and commits that the core developers surely are going to push.
|
|
|
|
beastmodeBiscuitGravy
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 27, 2016, 09:17:46 PM |
|
Lightning needs segwit, simple as that.
The time for complaining about it has passed. Waiting to observe the functionality, proliferation, and acceptance of the LN hub model is the only course of action now.
Astute miners realize that this topology is likely to result in on-chain fees increasing by 100x per tx. A small price to pay for uncensorable highly-decentralized settlement that you can’t get anywhere else.
|
|
|
|
Itoo
Jr. Member
Offline
Activity: 33
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 28, 2016, 08:08:12 PM |
|
Segwit is the only proper solution for malleability
There is some confusion between the concept of not including the signature in the txid and the particular package of changes that is being done in Core that does this and more but is also commonly called sigwit. Now I need a sigwit :-P sorry I couldn't resist
|
|
|
|
johnyj
Legendary
Offline
Activity: 1988
Merit: 1012
Beyond Imagination
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 01, 2016, 04:29:55 AM |
|
21 inc's LN has been out for months, it seems no one cares, so there is no market demand, if there is slightest market demand, 21inc's LN would be used at least to a degree, but no, I don't think average users would use prepaid model, and institutions would not trust a third party to handle their settlement
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 01, 2016, 05:55:28 AM |
|
21 inc's LN has been out for months, it seems no one cares, so there is no market demand, if there is slightest market demand, 21inc's LN would be used at least to a degree, but no, I don't think average users would use prepaid model, and institutions would not trust a third party to handle their settlement
Lightning doesn't have trusted third parties, so if "21Inc's LN" does, it isn't Lightning.
|
|
|
|
Jet Cash
Legendary
Offline
Activity: 2772
Merit: 2466
https://JetCash.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 01, 2016, 10:10:27 AM |
|
In my uneducated view SegWit is brilliant. Not only does it solve the blocksize problem in the short term, but it allows for a whole range of enhancements that will allow Bitcoin to become an intelligent programmable payment service that is independant of the fraudulent current banking system.
|
Offgrid campers allow you to enjoy life and preserve your health and wealth. Save old Cars - my project to save old cars from scrapage schemes, and to reduce the sale of new cars. My new Bitcoin transfer address is - bc1q9gtz8e40en6glgxwk4eujuau2fk5wxrprs6fys
|
|
|
Lauda
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 01, 2016, 03:24:17 PM |
|
In my uneducated view SegWit is brilliant. Not only does it solve the blocksize problem in the short term, but it allows for a whole range of enhancements that will allow Bitcoin to become an intelligent programmable payment service that is independant of the fraudulent current banking system.
Your 'uneducated' view is correct, which is quite unusual (as people tend to spread false information). Segwit does come with quite a few benefits, the added capacity increase is just a bonus. It should be (hopefully) merged soon. Lightning doesn't have trusted third parties, so if "21Inc's LN" does, it isn't Lightning.
He has been spreading that piece of miss information for quite some time now even though several people have pointed out (on several occasions) that it is false.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
simonbtc
Newbie
Offline
Activity: 16
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 01, 2016, 11:53:50 PM |
|
As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?
Fair question as the signature malleability issue is quite simple to fix. When hashing the transaction data to generate a txid, simply skip over the signature data. Everything else stays the same. Deployment and activation would be via a hard fork set at a certain block height.
|
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3486
Merit: 6824
Just writing some code
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 01, 2016, 11:56:05 PM |
|
As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?
Fair question as it's simple to implement. When hashing the transaction data to generate a txid, simply skip over the signature data. Everything else stays the same. Deployment and activation would be via a hard fork set at a certain block height. This has been discussed before albeit in another thread. So what happens with transactions that are unconfirmed when that happens? Sure the idea of it sounds simple, but deploying such a hard fork would be a major clusterfuck.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8647
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 02, 2016, 01:03:14 AM |
|
When hashing the transaction data to generate a txid, simply skip over the signature data. Everything else stays the same.
You still must have the block commit to the signature, or otherwise the signatures use in the network can be changed. (e.g. I could go add 200 GB to the size of the chain I give you by adding a megabyte of padding to the signatures in the first 200k blocks). You also need all transaction relay to be changed to be in terms of a new ID which is the hash of the whole transaction, not the txid. (Otherwise I can take a transaction, corrupt the signature, and relay it to everyone fast to block the real transaction from the network.) And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha). But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism). So what happens with transactions that are unconfirmed when that happens? Sure the idea of it sounds simple, but deploying such a hard fork would be a major clusterfuck.
Exactly, thats why we were unable to go forward with the original segwit design that we used in elements alpha: It's nearly impossible to deploy. The improved design is just simply better and a big part of that-- though far from all of it-- is that it's actually deployable.
|
|
|
|
|