3 ms·

> Core != Blockstream The overlap is very large. In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap. > It's an effective bloc

> Core != Blockstream The overlap is very large. In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap. > It's an effective blocksize increase to 2MB If all users start using segwit addresses and segwit transactions, and if all wallets software will know how to send and receive it. And that will mean users will need to send their money to their segwit-enabled addresses first, which might, you know, clog the network. (In reality, nobody knows what will happen. Almost nobody uses segwit on litecoin right now, but litecoin is a toy currency...) hardfork would solve that issue immediately - no need to upgrade wallets, no need to figure out how do segwit-inside-P2SH addresses work (they are different from normal addresses!). > enables lightning network which should hopefully reduce congestion on the Bitcoin network Again nobody knows. Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. > SegWit transactions are cheaper than traditional transactions Well, that's a matter of "policy", and I am not sure if segwit2x nodes will implement the segwit discount or not. There were some issues about that, but I think they didn't have time to remove the segwit discount yet. But they plan to. (Again I am not advocating big blocks, increasing blocks that way is not something that can be done forever. Segwit is fine, it solves some issues like maleability, but it's overhyped IMO. There is no scaling solution for bitcoin yet. And maybe there will not be?)

kanzure 9y ago
> In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap there's more overlap with core developers and chaincode labs. > Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. it does exist, https://github.com/lightningnetwork/lnd https://github.com/lightningnetwork/lnd and http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/ http://lightning.community/release/software/lnd/lightning/20... and other implementations of lightning also exist.
- shp0ngle 9y ago
  Interesting. I will try the docker example later BUT you have to admit it is still in research and not widely used/accepted/tested by users
- pmorici 9y ago
  Chaincode shares at least one affiliate with Blockstream.
fpgaminer 9y ago
> If all users start using segwit addresses and segwit transactions SegWit blocks can vary from 1MB in non-ideal conditions to near 4MB in ideal conditions. 2MB is just the average. You're right, yes, ideally we'd want everyone using SegWit transactions. But we don't need all users to start using them to start seeing congestion relief. I would expect 90% of transactions are generated by 10% of Bitcoin's users. Maybe even more skewed than that. (That 10% is likely businesses, power users, etc). Getting those 10% to switch to SegWit transactions will be relatively easy; they'll feel the value of reduced fees more readily. It's likely Bitcoin Core would start using SegWit addresses by default some time after SegWit is activated. Since the majority of users use Bitcoin Core, the shift wouldn't take too long. > hardfork would solve that issue immediately - no need to upgrade wallets, no need to figure out how do segwit-inside-P2SH addresses work (they are different from normal addresses!). Hardfork _does_ require upgrading wallets. In fact, it requires upgrading _all_ wallets. Anyone who hasn't upgraded cannot participate in Bitcoin any longer if a hardfork is used. Contrast that with SegWit. SegWit doesn't require that everyone upgrade. And yet everyone will benefit from the increased block capacity, even those not using SegWit addresses, because the fees overall will go down. > Again nobody knows. Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. The plan was for SegWit to activate, providing a more immediate ~2MB increase in block size, and then mid-term we'd see things like the lightning network come online and provide further relief. Long term developers would continue improving network efficiency which means the existing blocks can carry more transactions, and also eventually a hardfork to add some mechanism for increasing blocksize (that doesn't require further hardforks). > Well, that's a matter of "policy" I didn't mean that SegWit transactions were inherently cheaper in terms of fees. Sure, fees are always policy. But, AFAIK, SegWit transactions are actually cheaper in terms of network load. The discount on SegWit transactions is not just to expand the blocksize; they're also discounted because they put less strain on the network compared to old-style transactions. EDIT: And to be clear, the SegWit discount we're talking about is a discount on the weight of a SegWit transaction's size in calculating the total blocksize. AFAIK, there is no fee discount on SegWit transactions; they pay the same per byte fee. SegWit2X has no way to remove that discount without changing consensus rules. So that specifically is not a matter of policy; it's matter of consensus. It would thus required another hardfork to change those rules.

kanzure 9y ago

> In the same way, segwit2x != Chinere miners, but come on, there is an clear overlap there's more overlap with core developers and chaincode labs. > Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. it does exist, https://github.com/lightningnetwork/lnd https://github.com/lightningnetwork/lnd and http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/ http://lightning.community/release/software/lnd/lightning/20... and other implementations of lightning also exist.

shp0ngle 9y ago
Interesting. I will try the docker example later BUT you have to admit it is still in research and not widely used/accepted/tested by users
pmorici 9y ago
Chaincode shares at least one affiliate with Blockstream.

fpgaminer 9y ago

> If all users start using segwit addresses and segwit transactions SegWit blocks can vary from 1MB in non-ideal conditions to near 4MB in ideal conditions. 2MB is just the average. You're right, yes, ideally we'd want everyone using SegWit transactions. But we don't need all users to start using them to start seeing congestion relief. I would expect 90% of transactions are generated by 10% of Bitcoin's users. Maybe even more skewed than that. (That 10% is likely businesses, power users, etc). Getting those 10% to switch to SegWit transactions will be relatively easy; they'll feel the value of reduced fees more readily. It's likely Bitcoin Core would start using SegWit addresses by default some time after SegWit is activated. Since the majority of users use Bitcoin Core, the shift wouldn't take too long. > hardfork would solve that issue immediately - no need to upgrade wallets, no need to figure out how do segwit-inside-P2SH addresses work (they are different from normal addresses!). Hardfork _does_ require upgrading wallets. In fact, it requires upgrading _all_ wallets. Anyone who hasn't upgraded cannot participate in Bitcoin any longer if a hardfork is used. Contrast that with SegWit. SegWit doesn't require that everyone upgrade. And yet everyone will benefit from the increased block capacity, even those not using SegWit addresses, because the fees overall will go down. > Again nobody knows. Lightning network might be a vaporware. Literally nobody is using it, since it does not exist. The plan was for SegWit to activate, providing a more immediate ~2MB increase in block size, and then mid-term we'd see things like the lightning network come online and provide further relief. Long term developers would continue improving network efficiency which means the existing blocks can carry more transactions, and also eventually a hardfork to add some mechanism for increasing blocksize (that doesn't require further hardforks). > Well, that's a matter of "policy" I didn't mean that SegWit transactions were inherently cheaper in terms of fees. Sure, fees are always policy. But, AFAIK, SegWit transactions are actually cheaper in terms of network load. The discount on SegWit transactions is not just to expand the blocksize; they're also discounted because they put less strain on the network compared to old-style transactions. EDIT: And to be clear, the SegWit discount we're talking about is a discount on the weight of a SegWit transaction's size in calculating the total blocksize. AFAIK, there is no fee discount on SegWit transactions; they pay the same per byte fee. SegWit2X has no way to remove that discount without changing consensus rules. So that specifically is not a matter of policy; it's matter of consensus. It would thus required another hardfork to change those rules.