Bitcoin Forum
December 01, 2021, 07:48:31 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: Would you approve the compromise "Segwit + 2MB"?
Yes - 78 (62.4%)
No - 35 (28%)
Don't know - 12 (9.6%)
Total Voters: 125

Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 »  All
  Print  
Author Topic: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)  (Read 14254 times)
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 08:13:11 PM
 #121

You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.
then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"
You are engaging in a discussion between another user and myself; we are free to discuss whatever we want and however we want. If you can't comprehend our discussion properly, then don't comment on it.

8mb upper limit and 2mb lower (dynamic) limit.
Where is the academic research backing up that 8 MB is safe as upper limit? For which time frame? How does the 2 MB grow to 8 MB? At what periods?

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
1638388111
Hero Member
*
Offline Offline

Posts: 1638388111

View Profile Personal Message (Offline)

Ignore
1638388111
Reply with quote  #2

1638388111
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1638388111
Hero Member
*
Offline Offline

Posts: 1638388111

View Profile Personal Message (Offline)

Ignore
1638388111
Reply with quote  #2

1638388111
Report to moderator
1638388111
Hero Member
*
Offline Offline

Posts: 1638388111

View Profile Personal Message (Offline)

Ignore
1638388111
Reply with quote  #2

1638388111
Report to moderator
franky1
Legendary
*
Offline Offline

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 08:17:12 PM
 #122

You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.
then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"
You are engaging in a discussion between another user and myself; we are free to discuss whatever we want and however we want. If you can't comprehend our discussion properly, then don't comment on it.

if you want a private conversation between 2 people then go to Private message with them

8mb upper limit and 2mb lower (dynamic) limit.
Where is the academic research backing up that 8 MB is safe as upper limit? For which time frame? How does the 2 MB grow to 8 MB? At what periods?

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
as for how...

are you forgetting the example of dynamics . i even drew you a picture to keep your concentration span open.

what you need to understand by having the limits is that the NODES flag what they are happy with and POOLS work below that.
meaning it wont get out of control of what general nodes can cope with. because the nodes are flagging it.

oh and i remember rusty russel (blockstream) had some stats of 8mb being fine. so try not to proclaim that 8mb is evil as its your gangs own agreement that 8mb is fine as a upper limit, but a preference for less as a lower limit

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 08:20:26 PM
 #123

if you want a private conversation between 2 people then go to Private message with them
You need to visit some courses in order to improve your faulty comprehension skills. We can discuss whenever we want and wherever we want.

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

are you forgetting the example of dynamics . i even drew you a picture to keep your concentration span open
No. I'm asking you for the specifics of your proposal, but there are none apparently.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 08:22:20 PM
 #124

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

So what is the technical reason for this to be the case?

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 08:23:52 PM
 #125

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.
So what is the technical reason for this to be the case?
For one (ignoring everything else): Linear sigops validation vs. quadratic validation.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
franky1
Legendary
*
Offline Offline

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 08:29:23 PM
Last edit: March 11, 2017, 08:47:27 PM by franky1
 #126

For one (ignoring everything else): Linear sigops validation vs. quadratic validation.

lol segwit doesnt solve it!!

even after segwit activates native key users are not disarmed.
segwit only offers to disable people who voluntarily use segwit keys to perform quadratics by not having the quadratics problem in a segwit key tx signing.

it does not take the quadratics opportunity away from native key users.

reducing or keeping tx sigops limit at or below 16,000 sigops per block no matter what the blocksize is. ensures quadratic spammers cannot spam large sigop quadratic tx's
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;

segwit actually allowed increasing tx sigops limit since v0.12 from 4000 to 16000 . while thinking that people will all be using segwit keys will be enough defense.. they have not thought about native users taking advantage.

oh and please dont instantly reply, untill you read the code.
read the code dont just reply "wrong because blockstream are kings"


edit: after reading lauda's instant reply below.. i actually pasted in and done the maths for him from cores own code...
lauda: read the code.

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 08:35:44 PM
 #127

lol segwit doesnt solve it!!

even after segwit activates native key users are not disarmed.
segwit only offers to disable people who voluntarily use segwit keys to perform quadratics by not having the quadratics problem in a segwit key tx signing.
You still don't understand how Segwit works?
1 MB quadratic hashing = no DoS risk AFAIK.
2 MB quadratic hashing -> DoS risk.
Segwit activated 2 MB block (Segwit TXs) = no DoS risk (linear hashing)
Segwit activated 1 MB block (old TXs) = no DoS risk at 1 MB (quadratic hashing).

reducing or keeping tx sigops limit at or below 16,000 sigops per block no matter what the blocksize is. ensures quadratic spammers cannot spam large sigop quadratic tx's
That.. doesn't actually solve it IIRC. Have you actually proposed this somewhere/done calculations or did you pull 16k out of thin air?

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 08:38:28 PM
 #128

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 08:39:46 PM
 #129

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?
That's the way that it is currently implemented; a known inefficiency (O(n^2) time). This is one of the reasons for which Segwit is quite beneficial. They packed up a lot of improvements at once.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 08:43:43 PM
 #130

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?
That's the way that it is currently implemented; a known inefficiency (O(n^2) time). This is one of the reasons for which Segwit is quite beneficial. They packed up a lot of improvements at once.

But is there any reason that this could not be implemented on the old tx's?

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 08:47:51 PM
 #131

But is there any reason that this could not be implemented on the old tx's?
Segwit introduces a new transaction type which can't be malleated as old TX's and which have linear scaling. I don't know what exactly is needed in order to make old TXs scale linearly as well. I'm going to assume that it may require a hard fork of some type.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
franky1
Legendary
*
Offline Offline

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 08:52:22 PM
 #132

But is there any reason that this could not be implemented on the old tx's?
Segwit introduces a new transaction type which can't be malleated as old TX's and which have linear scaling. I don't know what exactly is needed in order to make old TXs scale linearly as well. I'm going to assume that it may require a hard fork of some type.

sigop attack
v0.12 had a 4000 sigop per tx limit (read the code)
v0.14 had a 16000 sigop per tx limit (read the code)

so now check the code.
https://github.com/bitcoin/bitcoin/tree/0.14/src
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

https://github.com/bitcoin/bitcoin/tree/0.12/src
core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;
nothing stops a native tx from sigops spamming, you can only control how much spam is allowed

blockstream just thinks that people using segwit keys is enough defense they have not realised native users will stick to native keys

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 08:53:55 PM
 #133

But is there any reason that this could not be implemented on the old tx's?
Segwit introduces a new transaction type which can't be malleated as old TX's and which have linear scaling. I don't know what exactly is needed in order to make old TXs scale linearly as well. I'm going to assume that it may require a hard fork of some type.

That is what I am wondering. If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good. Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee and put unnecessary pressure on network capacity)?

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
franky1
Legendary
*
Offline Offline

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 08:56:01 PM
 #134

That is what I am wondering. If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good. Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee).

nope.

only real defense is keep limit per tx down........................ or blindly think malicious people will move to segwit keys to disarm themselves so everyone is using segwit keys

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 08:58:22 PM
 #135

-snip-
nothing stops a native tx from sigops spamming
You still don't understand it. Spamming with native keys after Segwit has been activated is useless. You can't DoS the network with them.

If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good.
No. The difference between SFSF and SFHF is negligible (aside from hard forks being dangerous without consensus). In order for something like that happen, it would probably require a whole different BIP and approach.

Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee and put unnecessary pressure on network capacity)?
I doubt it. Even the other attempt at fixing malleability with a hard fork called Flextrans (from the Classic dev, i.e. a BTU supporter) doesn't do that.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
franky1
Legendary
*
Offline Offline

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 09:00:26 PM
 #136

-snip-
nothing stops a native tx from sigops spamming
You still don't understand it. Spamming with native keys after Segwit has been activated is useless. You can't DoS the network with them.

you can by filling the baseblock.

EG
a block based on v:0.12 fills the 1mb block with sigop tx's totallying 4000 sigops per tx
a block based on v:0.14 fills the 1mb block with sigop tx's totallying 16000 sigops per tx

edit: here is the clincher justdoing 5 tx's uses up the blocks max tx count.. no one else can be added

READ THE CODE. not the sales pitch by blockstreamers on reddit

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 09:12:44 PM
 #137

-snip-
nothing stops a native tx from sigops spamming
You still don't understand it. Spamming with native keys after Segwit has been activated is useless. You can't DoS the network with them.

Is this because it will eventually only be possible to send to a segwit key, or is there some function in the two tier network that the SWSF creates?

If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good.
No. The difference between SFSF and SFHF is negligible (aside from hard forks being dangerous without consensus). In order for something like that happen, it would probably require a whole different BIP and approach.

So does this mean a soft fork bypasses consensus?

Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee and put unnecessary pressure on network capacity)?
I doubt it. Even the other attempt at fixing malleability with a hard fork called Flextrans (from the Classic dev, i.e. a BTU supporter) doesn't do that.

Does flextrans require a new address key type as well?

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
d5000
Legendary
*
Offline Offline

Activity: 3010
Merit: 2925


Decentralization Maximalist


View Profile
March 11, 2017, 09:14:39 PM
 #138

If you don't believe that Bitcoin is digital gold, or you don't understand where the current value stems from, then you have to re-examine everything.
Maybe we've different opinions here. I believe Bitcoin's value comes mainly from its usability as a value transfer (and later, also value storage) platform for many use cases among many users ("network effect") and its advantage ahead of similar cryptocurrencies ("altcoins"). But that could lead to a long discussion, so here in this thread, let's focus on the block size issue. Wink

In the case of IBD I think that in that in that "drastic future" most users will end downloading blockchain snapshots. That has some centralization risks but I think they are manageable. [...]
You shouldn't throw in centralizing aspects like they are trivial changes. The impact of something like that, and potential security concerns are probably not properly researched.
Then I would encourage research on that topic - I think it's inevitable at some point to provide "lighter" IBD procedures. Maybe Electrum and other light wallets could serve as objects in such a study.

Quote
We're obviously talking about end users with consumer-level equipment. Professional users that use servers in well-connected datacenters should have no problems with 20 MB blocks, I think.
I don't understand why you want me, as a user, to spend a lot of money to run my node in datacenters? I use Bitcoin Core for everything, node, wallet, cold storage.

No! Obviously the goal must be to allow end users running their node on PCs or notebooks. That was only a comment about professional equipment today - because the power of pro-equipment should be reached by consumer-level hardware at most a decade later. (Connectivity/bandwidth is another point, here you're right that mainly the upload bandwidth growth is a major bottleneck).
Edit: What upper limit would you consider realistic?
In what time frame? Next 5, 10 years?
Let's say 5 years, 10 years maybe is too far away.

(The 20 MB blocks were only an example to show the approximate relation between block size and possible user base, for now, I won't insist on this number)

Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 09:31:54 PM
 #139

you can by filling the baseblock.

EG
a block based on v:0.12 fills the 1mb block with sigop tx's totallying 4000 sigops per tx
a block based on v:0.14 fills the 1mb block with sigop tx's totallying 16000 sigops per tx
Are you trying to say that Bitcoin can be DOS'ed at 1 MB now? Roll Eyes

Is this because it will eventually only be possible to send to a segwit key, or is there some function in the two tier network that the SWSF creates?
No. You can refuse to use Segwit if you do not want to.

So does this mean a soft fork bypasses consensus?
No. Soft forks are backwards compatible, therefore mitigating the risk of a network split.

Does flextrans require a new address key type as well?
Yes.
I believe Bitcoin's value comes mainly from its usability ....
 But that could lead to a long discussion, so here in this thread, let's focus on the block size issue. Wink
It sounded like I was talking to Roger Ver for a second, but okay.

Then I would encourage research on that topic - I think it's inevitable at some point to provide "lighter" IBD procedures. Maybe Electrum and other light wallets could serve as objects in such a study.
Then encourage it, but don't spread it around like it is trivial until we know for 'sure'.

No! Obviously the goal must be to allow end users running their node on PCs or notebooks. That was only a comment about professional equipment today - because the power of pro-equipment should be reached by consumer-level hardware at most a decade later. (Connectivity/bandwidth is another point, here you're right that mainly the upload bandwidth growth is a major bottleneck).
Noted. My bad.

Let's say 5 years, 10 years maybe is too far away.

(The 20 MB blocks were only an example to show the approximate relation between block size and possible user base, for now, I won't insist on this number)
We also need to determine whether we are talking about a block size in the traditional sense or a post-Segwit 'base + weight' size (as the "new" block size). Which is it?

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
jbreher
Legendary
*
Offline Offline

Activity: 2912
Merit: 1515


lose: unfind ... loose: untight


View Profile
March 11, 2017, 09:38:51 PM
 #140

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?
That's the way that it is currently implemented; a known inefficiency (O(n^2) time). This is one of the reasons for which Segwit is quite beneficial. They packed up a lot of improvements at once.

But is there any reason that this could not be implemented on the old tx's?

The 'DoS' doesn't even require a protocol change to nullify. Indeed, there is a natural incentive already in the protocol that ensures it will never become a systemic problem. If large-time-to-verify-blocks ever became A Thing, miners will employ parallel validation. This will ensure that such large-time-to-verify-blocks will be orphaned by faster-to-verify-blocks.

Miners who gravitate to parallel validation will earn more income, and miners who do not employ parallel validation will become bankrupted over time. As will miners who create such DoS blocks.

This is already part of the protocol. No change is needed.

Anyone with a campaign ad in their signature -- for an organization with which they are not otherwise affiliated -- is automatically deducted credibility points.

I've been convicted of heresy. Convicted by a mere known extortionist. Read my Trust for details.
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!