NOT Upgrading to SegWit who's with me?!

[hv_]

Mm , can't find

Step 0:  Fixing scalability ( by simplifying code e.g. drop the line that has the 1MB ) that would be most recommended and the nobrainer all could agree on.


 

[jbreher]

even Andreas Antonopoulos is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake

Got a link to AA actually saying that? Thanks.

https://twitter.com/aantonop/status/792436751901921280

Perhaps twitter gives different views to different people? There is nothing in there where Andreas "is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake".

Maybe you meant to post a different link?

[xyzzy099]

even Andreas Antonopoulos is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake

Got a link to AA actually saying that? Thanks.

https://twitter.com/aantonop/status/792436751901921280

Perhaps twitter gives different views to different people? There is nothing in there where Andreas "is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake".

Maybe you meant to post a different link?

Nope.  I thought you were looking for a quote that showed Andreas' support for segwit, but it appears that you are looking for a quote from him that contains the exact words from the original poster's obvious paraphrase of Andreas' position.

I think the original posters point was simply that Andreas' supports swgwit, which is clearly true - and trying to nit-pick his paraphrasing of Andreas' position seems to me to be pretty silly - but don't let me deter you from your chosen path

[Carlton Banks]

Mm , can't find

Step 0:  Fixing scalability ( by simplifying code e.g. drop the line that has the 1MB ) that would be most recommended and the nobrainer all could agree on.


 

Then why do all the brains in the heads of the development community disagree fundamentally with that approach? Because of the sighashing scaling problem, the solution to which is a part of the Segwit fork.

Bigger blocks using the present sighashing code can increase the time it takes to compute signature hashes by an unsustainable factor, even 1MB blocks with complex chains of transactions can take a worryingly long amount of time to validate. This presents an unacceptable network coherence risk without increasing the base blocksize.


And that's not even considering the threat to decentralisation of Bitcoin nodes. The current price spike has buoyed the node count, but it's not much of an improvement. The base size should be increased, but not before the trend in the node count is improving consistently. Confidence in the Bitcoin network depends in part on how widely distributed the nodes are. With the trends the way they are now, there is too much of a risk that the node count would slump, and that would harm confidence in the currency itself, i.e. the market price that everyone gets so excited about

[jackg]

Mm , can't find

Step 0:  Fixing scalability ( by simplifying code e.g. drop the line that has the 1MB ) that would be most recommended and the nobrainer all could agree on.


 

Nope. It should be to do nothing but improve the security of Bitcoin. If you set high enough tx fees (and contribute to the network) then you will have no problem with your transactions being slow.

even Andreas Antonopoulos is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake

Got a link to AA actually saying that? Thanks.

https://twitter.com/aantonop/status/792436751901921280

Perhaps twitter gives different views to different people? There is nothing in there where Andreas "is advising people to adopt segwit before raising the blocksize because doing otherwise is a mistake".

Maybe you meant to post a different link?

Nope.  I thought you were looking for a quote that showed Andreas' support for segwit, but it appears that you are looking for a quote from him that contains the exact words from the original poster's obvious paraphrase of Andreas' position.

I think the original posters point was simply that Andreas' supports swgwit, which is clearly true - and trying to nit-pick his paraphrasing of Andreas' position seems to me to be pretty silly - but don't let me deter you from your chosen path

That link just saays that he isn't trying to block segwit. Maybe hisdoes support it but he didn't really make that seem obvious in his post (other than the fact he updated to it).

[xyzzy099]

That link just saays that he isn't trying to block segwit. Maybe hisdoes support it but he didn't really make that seem obvious in his post (other than the fact he updated to it).

I think it's clear from the tweet that he supports SW, but even if you disagree, there is plenty of stuff from Andreas that you can find on google where he discusses SW in terms that make it clear that he thinks it's a great idea.  If you don't want to google it yourself, watch this video: https://www.youtube.com/watch?v=kSq-58ElBzk&feature=youtu.be

[jackg]

That link just saays that he isn't trying to block segwit. Maybe hisdoes support it but he didn't really make that seem obvious in his post (other than the fact he updated to it).

I think it's clear from the tweet that he supports SW, but even if you disagree, there is plenty of stuff from Andreas that you can find on google where he discusses SW in terms that make it clear that he thinks it's a great idea.  If you don't want to google it yourself, watch this video: https://www.youtube.com/watch?v=kSq-58ElBzk&feature=youtu.be

I just said that your link didn't seem to support it.
Something like this may have been better: https://decentralize.today/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.vd2s787t3

Segregated witness therefore has two main effects on the fees paid by bitcoin users. Firstly, segregated witness reduces the overall cost of transactions by discounting witness data and increasing the capacity of the bitcoin blockchain. Secondly, segregated witness’ discount on witness data corrects a misalignment of incentives that may have inadvertently created more bloat in the UTXO set.

That looks better

[jbreher]

I just said that your link didn't seem to support it.
Something like this may have been better: https://decentralize.today/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.vd2s787t3

Segregated witness therefore has two main effects on the fees paid by bitcoin users. Firstly, segregated witness reduces the overall cost of transactions by discounting witness data and increasing the capacity of the bitcoin blockchain. Secondly, segregated witness’ discount on witness data corrects a misalignment of incentives that may have inadvertently created more bloat in the UTXO set.

That looks better

Perhaps... but it still does not say that segwit should be adopted before a simple maxblocksize bump. Let alone that doing otherwise would be a mistake.

[jackg]

I just said that your link didn't seem to support it.
Something like this may have been better: https://decentralize.today/segregated-witness-and-aligning-economic-incentives-with-resource-costs-7d987b135c00#.vd2s787t3

Segregated witness therefore has two main effects on the fees paid by bitcoin users. Firstly, segregated witness reduces the overall cost of transactions by discounting witness data and increasing the capacity of the bitcoin blockchain. Secondly, segregated witness’ discount on witness data corrects a misalignment of incentives that may have inadvertently created more bloat in the UTXO set.

That looks better

Perhaps... but it still does not say that segwit should be adopted before a simple maxblocksize bump. Let alone that doing otherwise would be a mistake.

But the blocksize issue leaves a large problem though doesn't it? What does it increase to? when does it end?
If we double it to 2MB then we'll still have the same problem and people will continue to say "we need to double the block size limit because my transaction without any fees is taking a few hours to go through the network".

There is no saying that it should or shouldn't be added before increasing the block size and arguably increasing the block size would be a simpler task (I mean it requires less theory behind it). Segwit will though also decrease the blockchain size for full nodes that are currently running bitcoin core.

The hard disk drive technology is improving to increase the capacity of them but not as fast as the blockchain is growing. If we continue without finding ways to reduce the blockchain size, in a few years, full nodes will be on petabyte group-owned servers that will slow the network and lead to a less amount of centralisation (reducing the block size but uite a dramatic amount will be useful and can be done with segwit - read the article if in doubt).

[jbreher]

Segwit will though also decrease the blockchain size for full nodes that are currently running bitcoin core.

Not for fully-validating nodes (which to me seems synonymous with full nodes - perhaps you have a weird definition) it does not. SegWit actually increases the storage required for a full copy of the blockchain.

The hard disk drive technology is improving to increase the capacity of them but not as fast as the blockchain is growing.

Nonsense. Find me an HDD of recent manufacture that is not capacious enough to hold the blockchain.

[jackg]

Segwit will though also decrease the blockchain size for full nodes that are currently running bitcoin core.

Not for fully-validating nodes (which to me seems synonymous with full nodes - perhaps you have a weird definition) it does not. SegWit actually increases the storage required for a full copy of the blockchain.

The hard disk drive technology is improving to increase the capacity of them but not as fast as the blockchain is growing.

Nonsense. Find me an HDD of recent manufacture that is not capacious enough to hold the blockchain.

Not now in the future. If the blockchain has grown by 20GB this year and continues to increase yearly growth then larger hard drives are needed which may slow down the network due to more bandwidth required.
If segwit takes up more space then it shouldn't be used now. As that was what it was supposed to do, decrease transaction sizes!

[jbreher]

Segwit will though also decrease the blockchain size for full nodes that are currently running bitcoin core.

Not for fully-validating nodes (which to me seems synonymous with full nodes - perhaps you have a weird definition) it does not. SegWit actually increases the storage required for a full copy of the blockchain.

The hard disk drive technology is improving to increase the capacity of them but not as fast as the blockchain is growing.

Nonsense. Find me an HDD of recent manufacture that is not capacious enough to hold the blockchain.

Not now in the future. If the blockchain has grown by 20GB this year and continues to increase yearly growth then larger hard drives are needed which may slow down the network due to more bandwidth required.

Larger hard drives are not a problem. Today, the 'sweet spot' for HDDs, based on price, is 4TB drives costing about 0.125 BTC. 10TB HDDs are widely available. 12TB and 14TB drives will be coming online this year, and 20TB drives are in the planning stages.

If segwit takes up more space then it shouldn't be used now. As that was what it was supposed to do, decrease transaction sizes!

No, SegWit was not designed to decrease transaction sizes. Where did you get that idea?

[franky1]

im still laughing at people who "love" core/blockstream

saying how they are
ok with bloating a 2-in2-out tx upto a few kilobytes purely to make the transaction TEMPORARILY confidential. but PERMANENTLY bloated.
ok with having tx's locked into 3-5 day maturities (CLTV frozen funds)
ok with chargebacks (CSV revoke codes)
ok with permissioned 2 party authorised transactions (LN)
ok with third party management (LN outsourced management)
ok with fee penalties

and ill say it again ok with bloating each transaction that was ~400byte to become over 1kb.

but if anyone ever hints that core Devs should lose their grip of spoonfeeding the code... everyone goes insane

the funny thing is that the core sheeple think that segwit is a boost from ~2500tx to 4500tx.. yet thats if everyone, yes everyone uses segwit.
but by the time everyone made the switch. confidential payments would be bloating things up again causing the transaction count per block to decrease while the size per transaction increases.

[hv_]

Mm , can't find

Step 0:  Fixing scalability ( by simplifying code e.g. drop the line that has the 1MB ) that would be most recommended and the nobrainer all could agree on.


 

Then why do all the brains in the heads of the development community disagree fundamentally with that approach? Because of the sighashing scaling problem, the solution to which is a part of the Segwit fork.

Bigger blocks using the present sighashing code can increase the time it takes to compute signature hashes by an unsustainable factor, even 1MB blocks with complex chains of transactions can take a worryingly long amount of time to validate. This presents an unacceptable network coherence risk without increasing the base blocksize.


And that's not even considering the threat to decentralisation of Bitcoin nodes. The current price spike has buoyed the node count, but it's not much of an improvement. The base size should be increased, but not before the trend in the node count is improving consistently. Confidence in the Bitcoin network depends in part on how widely distributed the nodes are. With the trends the way they are now, there is too much of a risk that the node count would slump, and that would harm confidence in the currency itself, i.e. the market price that everyone gets so excited about

Can you put a number to your brains? And BS payed brains will condense down to 1 here!
Why do you think so much Keynsian and try to regulate things ?

Better and Bitcoiner is to think Austrian: Remove rules as much as possible, project the bitcoin protocol to its absolute minimum and let the market participants decide what they could provide. Now you ll get an infinite number of brains connected and the thing gets anti-fragile!

Stupid rules are for brainless ones.

[franky1]

lol solution to sighash scaling is simple.

limit how many sigops a tx can do. no single person needs to ever produce a tx with 80,000 sigops or 20,000 or even 1000..

afterall a LN tx is just a 2in 2out transaction, so thinking that the quadratic/linear doomsday impacts LN is false

also LN requires 2 signatures so one party would refuse to sign if they see another party is doing something funky to a tx. so a tx wont even be accepted with only one signature. so that keeps both parties in a 'mutually assured destruction/mutual agreement to benefit' paradigm to not have issues with malleability.

but core devs have forgot how to make code rules. and have put their banker hats on and decided 'market' rules are better.
such as
not making DDoS protection code for LN, but instead give penalty fee's to hub 'customers' if they dont do things a certain way.
not have the onchain tx fee reactive to actual demand of blockspace, but averaged biasedly in an ever increasing amount over x blocks.

[hv_]

lol solution to sighash scaling is simple.

limit how many sigops a tx can do. no single person needs to ever produce a tx with 80,000 sigops or 20,000 or even 1000..

afterall a LN tx is just a 2in 2out transaction, so thinking that the quadratic/linear doomsday impacts LN is false

also LN requires 2 signatures so one party would refuse to sign if they see another party is doing something funky to a tx. so a tx wont even be accepted with only one signature. so that keeps both parties in a 'mutually assured destruction/mutual agreement to benefit' paradigm to not have issues with malleability.

but core devs have forgot how to make code rules. and have put their banker hats on and decided 'market' rules are better.
such as
not making DDoS protection code for LN, but instead give penalty fee's to hub 'customers' if they dont do things a certain way.
not have the onchain tx fee reactive to actual demand of blockspace, but averaged biasedly in an ever increasing amount over x blocks.

And now think of the case LN or similar side chain channels might attract high volumes and people in some years, onchain tx fees are getting extreme high for individuals, so miners are given great attack vector DDoSing LN. Where should all these needed tx go through? Into the 1MB ?

Never ever concentrate such scalings into to big too fail solutions!

[franky1]

Never ever concentrate such scalings into to big too fail solutions!

LN has a niche market for gamblers, day traders, adsense and faucets.
but if you look at the stats. most NORMAL people only transact using fiat 42 times a month.
so if normal people swapped using fiat to use bitcoin. they would use bitcoin far less than 42 times a month due to bitcoin not being available for all retail, public services.

LN should be a side solution for the high use people. but NOT forcing everyone to use LN permissioned transactions

the funny thing is core KNOW that 4mb is no issue for the network.
the problem is they want to bloat that 4mb allowance with features like confidential transactions, rather than allowing 2mb-4mb of lean transactions.

plus this fake gesture core want to offer, is a one time boost that depreciates faster than it will boost.
causing effectively no long term benefit. and still requiring us to be spoonfed.

however a dynamic block allows the community to decide when to grow. obviously if nodes cant cope with certain growth, they wont change the setting to flag desire for growth. and consensus wont allow growth unless majority can cope.

we dont need devs to decide what is possible or not. especially when they are biased saying 2mb is too much one day, but suddenly 4mb is ok the next day they suddenly need it for their features.

let me guess though blockstream sheeple will jump in to reply "one billion terrabyte blocks tomorrow" without explaining the rational concept of CONSENSUS and slow NATURAL and PROGRESSIVE growth of time

but core are not devs, they are economists now.
their mindset is less about using code to expand bitcoin, but instead
limit supply of space, increase the price of space and force people into commercial services(charging fe's/penalties to repay blockstream investors)

if anyone thinks the network cant cope with 2mb thus 1mb should remain then why the F**k are core now ok with 4mb to allow extra space to fit their bloated features.

bitcoin should remain as the lean transaction network. let the bloated features go offchain.

[Carlton Banks]

Can you put a number to your brains? And BS payed brains will condense down to 1 here!
Why do you think so much Keynsian and try to regulate things ?

If you don't want rules and regulations, you've been using the wrong system. Bitcoin cannot operate without rules, enforcing scarcity or the property rights of the holders would be impossible without rules.

And while Bitcoin is peer 2 peer when sending transactions, it is the underlying rules that make that possible. Having multiple sets of rules would not create any kind of a stable system, and hence a currency with multiple sets of rules cannot have a stable market price.

And you clearly don't understand Austrian Economics either. You have a lot of reading to do.

[franky1]

just to clarify some trolls points

bitcoin blocksize has 3 rules

core for instance has:
protocol size 32mb(bet most dont know that)
node preference 1mb base 4mb weight
pool preference 0.7mb base (but the pools have upped this themselves to 0.999mb after release)

while pools are at 0.7-0.999mb,  nodes can actually move their goal posts to anything they please. while still receiving any blocksize below their preference without issue.
we ALREADY have a few hundred nodes with block base sizes above 1mb with the main ones set at 2mb. and they are ALL happily accepting blocks

taking the control away from devs and letting the users control their own settings to show real community desire WONT break bitcoin.
pools wont up their preferential settings unless they see majority acceptance from the community, otherwise their blocks would get orphaned.
the community wont up their preferential settings unless they can handle it.

it does not require dev's to control when and how.. it should be a community consensus that does it.

anyone saying otherwise is just trolling for the banker backed dev's who want to limit bitcoin purely to commercialise it.

[hv_]

Can you put a number to your brains? And BS payed brains will condense down to 1 here!
Why do you think so much Keynsian and try to regulate things ?

If you don't want rules and regulations, you've been using the wrong system. Bitcoin cannot operate without rules, enforcing scarcity or the property rights of the holders would be impossible without rules.

And while Bitcoin is peer 2 peer when sending transactions, it is the underlying rules that make that possible. Having multiple sets of rules would not create any kind of a stable system, and hence a currency with multiple sets of rules cannot have a stable market price.

And you clearly don't understand Austrian Economics either. You have a lot of reading to do.

Good stuff - reading, yes it is. And thank you you are doing it and even writing back. Not from all we can say this!  I m sure we can agree on the minimal rule set needed.

Next level is implementing and understanding and recursive learnig and fixing things. Since this is mostly complex and nobody really can get all things right, we must have to agree on simplicity first -> minimal rule set.

1MB limit drops out here.... Try it out (maybe recursively ) and we will ALL learn and shake hands later.