Last Time. In small words. Why 2MB impossible. Why Soft Fork. Why SegWit First..

[franky1]

wow "im ludicrous"

You are.

4k vs 16k sigop count, which do you think is worse

The left one is with the current block size limit & quadratic validation time,

the other one is with Segwit and linear validation time.

The foremost is worse. Maybe enroll in a CS college?

lol says the guy that doesnt even know and admits to not knowing c++

lol
so go on.. if you really think the 16k is only for segwit key users.. go on show me the limit for native key users
go on showw the code in 0.14 that says basically in laymans
this is line of code for segwit tx type sigop limit
this is line of code for native tx type sigop limit

i now await the usual 'i dont have to prove anything' or ' lets just insult you' or other empty whistling in the wind reply

[Lauda]

so go on.. if you really think the 16k is only for segwit key users.. go on show me the limit for native key users

Download and run Bitcoin Core 0.14.0. Create a transaction with 16k Sigops and provide us with proof here. Once you fail to create such transaction(s), you will come back here complaining about semantics. What happened to the per-block-limit that you kept mentioning until recently?

i now await the usual 'i dont have to prove anything' or ' lets just insult you' or other empty whistling in the wind reply

It is up to you to prove your initial claim, and snipping code out of context != proof.

[franky1]

so go on.. if you really think the 16k is only for segwit key users.. go on show me the limit for native key users

Download and run Bitcoin Core 0.14.0. Create a transaction with 16k Sigops and provide us with proof here. Once you fail to create such transaction(s), you will come back here complaining about semantics. What happened to the per-block-limit that you kept mentioning until recently?

i now await the usual 'i dont have to prove anything' or ' lets just insult you' or other empty whistling in the wind reply

It is up to you to prove your initial claim, and snipping code out of context != proof.

i snipped code because you were crying the other month that you cant read more than a paragraph
so here you go https://github.com/bitcoin/bitcoin/tree/master/src read the unsnipped version

[jonald_fyookball]

so go on.. if you really think the 16k is only for segwit key users.. go on show me the limit for native key users

Download and run Bitcoin Core 0.14.0. Create a transaction with 16k Sigops and provide us with proof here. Once you fail to create such transaction(s), you will come back here complaining about semantics. What happened to the per-block-limit that you kept mentioning until recently?

i now await the usual 'i dont have to prove anything' or ' lets just insult you' or other empty whistling in the wind reply

It is up to you to prove your initial claim, and snipping code out of context != proof.

i snipped code because you were crying the other month that you cant read more than a paragraph
so here you go https://github.com/bitcoin/bitcoin/tree/master/src read the unsnipped version

which file has the sigops limit?  i would like to see

[franky1]

which file has the sigops limit?  i would like to see

it requires basic elementary/primary school level maths and reading a couple locations wrote in c++ which i know lauda has a hard time dealing with. so i simplified it for him by just using laymans: maxtxsigop=16k

but for those able to read and do basic maths

https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h

/** The maximum number of sigops we're willing to relay/mine in a single tx */
static const unsigned int MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

and here is where the MAX_BLOCK_SIGOPS_COST exists
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h

/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;

rearranged into one line of text is:
 MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
becomes
MAX_STANDARD_TX_SIGOPS_COST = 80000/5 = 16,000
meaning
"The maximum number of sigops we're willing to relay/mine in a single tx = 16k"

also worth noting
in short you can use up a base blocks entire MAX_BLOCK_SIGOPS_COST with just 5 tx of 16k sigops
also worth noting
thats 3 different spam attack vectors

1. just fill a block of native data to 1mb
2. use up the block sigops limit with say 1000tx of just 80sigops each for example
3. use up the block sigops limit with say 5tx of just 16,000sigops each for example

[d5000]

I wondered why no one still mentioned the following counter-argument:

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

That is not an argument against "2 MB + Segwit".

Proposals like Lerner's  "Segwit2MB" would activate the 2 MB hard fork after the activation of the Segwit soft fork. Maybe Lerner's 6 months (if I remember right) as "grace period" is too short because maybe until then most people would still use legacy transactions, but 1 year would be surely enough. We would then activate Segwit in mid-to-late 2017 and 2MB in mid-to-late 2018. Jihan as far as I remember mentioned the Hong Kong Agreement several times, so he should be happy with this solution.

[The One]

I wondered why no one still mentioned the following counter-argument:

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

That is not an argument against "2 MB + Segwit".

Proposals like Lerner's  "Segwit2MB" would activate the 2 MB hard fork after the activation of the Segwit soft fork. Maybe Lerner's 6 months (if I remember right) as "grace period" is too short because maybe until then most people would still use legacy transactions, but 1 year would be surely enough. We would then activate Segwit in mid-to-late 2017 and 2MB in mid-to-late 2018. Jihan as far as I remember mentioned the Hong Kong Agreement several times, so he should be happy with this solution.

What wrong with do both as hard fork? Wouldn't segwit hard fork be better than soft fork?

I assume if hard fork for both then there is a need to allow legacy txs to be converted at a later date. ie. 10 years.

[-ck]

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

You ? meaning me or miner?

You said, "However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices,." = miner can choose = dictate?

The developers cannot dictate.

I was talking about pools when I used the word dictate.

We seem to not be communicating here. You asked "Is this not something developers should sort out" and I'm telling you they can't.

[The One]

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

You ? meaning me or miner?

You said, "However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices,." = miner can choose = dictate?

The developers cannot dictate.

I was talking about pools when I used the word dictate.

We seem to not be communicating here. You asked "Is this not something developers should sort out" and I'm telling you they can't.

lol

This is an element of centralisation when pools can dictate their own rules... Thus dictate was relevant to pools.

Explain why it would be "extremely unpopular move and suicide for a cryptocurrency"?, when a miner producing an empty block when there is outstanding txs is stupid enough itself.

[franky1]

Proposals like Lerner's  "Segwit2MB" would activate the 2 MB hard fork after the activation of the Segwit soft fork. Maybe Lerner's 6 months (if I remember right) as "grace period" is too short because maybe until then most people would still use legacy transactions, but 1 year would be surely enough. We would then activate Segwit in mid-to-late 2017 and 2MB in mid-to-late 2018. Jihan as far as I remember mentioned the Hong Kong Agreement several times, so he should be happy with this solution.

segwit as a hardfork requires everyone to upgrade node.
but here is the thing.. native key users dont have to move funds to segwit keys.

what happens in reality is that instead of 2 merkle (block inside a block)..
its just 1 base block where the witness and txdata sit together.

and simple ALL share the same room.

its not
base 1mb           || witness <3mb  ||
[IN] [SIG] [OUT] ||                      ||  - native
[IN] [OUT]         ||[SIG]               ||  - segwit

it is
base 2mb
[IN] [SIG] [OUT]                          || - native
[IN] [OUT][SIG]                           || - segwit

thus both tx types benefit and coexist in the same area with no stripping (filtering/bridging) data.. blocks are the same for all nodes of the network because they all upgraded to just the 2mb hardfork

[-ck]

This is an element of centralisation when pools can dictate their own rules... Thus dictate was relevant to pools.

Explain why it would be "extremely unpopular move and suicide for a cryptocurrency"?, when a miner producing an empty block when there is outstanding txs is stupid enough itself.

I don't disagree that pools producing empty blocks is stupid; heck I'm one of the BIGGEST campaigners against doing so in the mining world.

As for why developers cant mandate what goes into a block through network rules via a hard fork, bitcoin is an open transaction system and any attempt to strictly specify which transactions must go into a block in the reference core implementation would be futile. Not only does every node have a different mempool consisting of different transactions (it's impossible to sync all nodes to the same set of transactions in time and space), but enforcing certain transactions is actually creating a system with an unintentional censoring, prioritising and filtering of transactions in the world. The current system works off transaction fees as the incentive to choose transactions based on the reward making them more worth mining and indirectly creates a type of consensus without mandating order. Either way, the fact that no 2 mempools will be alike means it would be impossible to mandate anything anyway. Even empty blocks, as much as it pains me to say, must be allowed since theoretically there is a time and place where there are no transactions (though unlikely in bitcoin I agree) but additionally when a bitcoin node is restarted it has no transactions until they're gathered from the network or some are loaded from disk (in 0.14+). Even the ones loaded from disk may be all old and no longer mineable if enough blocks have passed since the node was restarted.

[Lauda]

i snipped code because you were crying the other month that you cant read more than a paragraph
so here you go https://github.com/bitcoin/bitcoin/tree/master/src read the unsnipped version

It does not mean what you think it means. Ask any developer that is actually working on the code.

That is not an argument against "2 MB + Segwit".

Proposals like Lerner's  "Segwit2MB" would activate the 2 MB hard fork after the activation of the Segwit soft fork. Maybe Lerner's 6 months (if I remember right) as "grace period" is too short because maybe until then most people would still use legacy transactions, but 1 year would be surely enough. We would then activate Segwit in mid-to-late 2017 and 2MB in mid-to-late 2018. Jihan as far as I remember mentioned the Hong Kong Agreement several times, so he should be happy with this solution.

I don't see how 2 MB + Segwit would avoid the quadratic problem on it's own. It needs to have some constraints on native transactions in order to work. Additionally, this creates a possibility of almost 8 MB blocks (if someone wanted to spam the network with this).

[The One]

This is an element of centralisation when pools can dictate their own rules... Thus dictate was relevant to pools.

Explain why it would be "extremely unpopular move and suicide for a cryptocurrency"?, when a miner producing an empty block when there is outstanding txs is stupid enough itself.

I don't disagree that pools producing empty blocks is stupid; heck I'm one of the BIGGEST campaigners against doing so in the mining world.

As for why developers cant mandate what goes into a block through network rules via a hard fork, bitcoin is an open transaction system and any attempt to strictly specify which transactions must go into a block in the reference core implementation would be futile. Not only does every node have a different mempool consisting of different transactions (it's impossible to sync all nodes to the same set of transactions in time and space), but enforcing certain transactions is actually creating a system with an unintentional censoring, prioritising and filtering of transactions in the world. The current system works off transaction fees as the incentive to choose transactions based on the reward making them more worth mining and indirectly creates a type of consensus without mandating order. Either way, the fact that no 2 mempools will be alike means it would be impossible to mandate anything anyway. Even empty blocks, as much as it pains me to say, must be allowed since theoretically there is a time and place where there are no transactions (though unlikely in bitcoin I agree) but additionally when a bitcoin node is restarted it has no transactions until they're gathered from the network or some are loaded from disk (in 0.14+). Even the ones loaded from disk may be all old and no longer mineable if enough blocks have passed since the node was restarted.

I didn't say 'which' but any validated txs. As long there are txs in the mempool, then the block should fill up until there is no txs in the mempool or block is over 95% full, for example. Empty blocks when there are no txs is fine but when there are thousands of txs waiting to be confirmed is madness.

Isn't that what the miners are already doing ?

[The One]

Proposals like Lerner's  "Segwit2MB" would activate the 2 MB hard fork after the activation of the Segwit soft fork. Maybe Lerner's 6 months (if I remember right) as "grace period" is too short because maybe until then most people would still use legacy transactions, but 1 year would be surely enough. We would then activate Segwit in mid-to-late 2017 and 2MB in mid-to-late 2018. Jihan as far as I remember mentioned the Hong Kong Agreement several times, so he should be happy with this solution.

segwit as a hardfork requires everyone to upgrade node.
but here is the thing.. native key users dont have to move funds to segwit keys.

what happens in reality is that instead of 2 merkle (block inside a block)..
its just 1 base block where the witness and txdata sit together.

and simple ALL share the same room.

its not
base 1mb           || witness <3mb  ||
[IN] [SIG] [OUT] ||                      ||  - native
[IN] [OUT]         ||[SIG]               ||  - segwit

it is
base 2mb
[IN] [SIG] [OUT]                          || - native
[IN] [OUT][SIG]                           || - segwit

thus both tx types benefit and coexist in the same area with no stripping (filtering/bridging) data.. blocks are the same for all nodes of the network because they all upgraded to just the 2mb hardfork

Surely 4mb would be better?

[franky1]

Surely 4mb would be better?

yep. 4mb single block would be better for everyone..
but the other thing is that the hype about a compromise of 2mb+segwit.. was released on the 1st of april...
so although 4mb block where native and segwit can co-mingle in one merkle block(no block within block) would be better
im taking a pinch of salt as to if 'core' would actually really agree to code such a version of even 2mb+segwit for people to download.

[Lauda]

https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h

/** The maximum number of sigops we're willing to relay/mine in a single tx */
static const unsigned int MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

and here is where the MAX_BLOCK_SIGOPS_COST exists
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h

/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;

rearranged into one line of text is:
 MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
becomes
MAX_STANDARD_TX_SIGOPS_COST = 80000/5 = 16,000
meaning
"The maximum number of sigops we're willing to relay/mine in a single tx = 16k"

Because of your nonsense, someone actually asked on IRC about this (it wasn't me):

<luke-jr> questioner2: sigops in legacy scripts count 4x toward the 80k limit
<luke-jr> this is in validation.cpp:GetTransactionSigOpCost
<questioner2> so a legacy tx can make 4 tx of 20k each
<questioner2> ok after trying to read what you say. the consensus/policy is 80k/5 for tx sigops = 16k. but legacy tx has 4x of the 16k = 4k
<questioner2> so just 20 tx of 4k legacy can use up all the blocks sigops
<sipa> questioner2: the easiest way to see it is that from the point of view of an old wallet, nothing changed
<sipa> 20k legacy sigops were allowed before, 20k legacy sigops are allowed after
<questioner2> is using up all 20k legacy treated as using up all 80k block sigops. or treated as legacy tx only use 25% of blocksigop limits allowing segwit transactions to still have 60x sigops spare to use in the base block
<questioner2> 60k*
<sipa> a legacy sigop counts as 4 segwit sigops
<sipa> so 20k legacy sigops would fill a block
<questioner2> so 5 legacy tx of 4k sigops would fill the block not allowing segwit txdata to sit in base block
<questioner2> 4k sigops each* (=20k legacy)
<sipa> just as 1M of non-segwit transactions would fill the whole block, not leaving space for segwit transactions
<sipa> *1M bytes

Tl;dr; + ELI5: You can't use more than 20k sigops per block using native keys after Segwit.
Bonus: I was right, and franky was wrong as usual.

[jonald_fyookball]

which file has the sigops limit?  i would like to see

it requires basic elementary/primary school level maths and reading a couple locations wrote in c++ which i know lauda has a hard time dealing with. so i simplified it for him by just using laymans: maxtxsigop=16k

but for those able to read and do basic maths

https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h

/** The maximum number of sigops we're willing to relay/mine in a single tx */
static const unsigned int MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

and here is where the MAX_BLOCK_SIGOPS_COST exists
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h

/** The maximum allowed number of signature check operations in a block (network rule) */
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;

rearranged into one line of text is:
 MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
becomes
MAX_STANDARD_TX_SIGOPS_COST = 80000/5 = 16,000
meaning
"The maximum number of sigops we're willing to relay/mine in a single tx = 16k"

also worth noting
in short you can use up a base blocks entire MAX_BLOCK_SIGOPS_COST with just 5 tx of 16k sigops
also worth noting
thats 3 different spam attack vectors

1. just fill a block of native data to 1mb
2. use up the block sigops limit with say 1000tx of just 80sigops each for example
3. use up the block sigops limit with say 5tx of just 16,000sigops each for example

So it appears that this limit is used in validation.cpp.  Why is Lauda saying its only for segwit?  What a troll.

[Lauda]

So it appears that this limit is used in validation.cpp.  Why is Lauda saying its only for segwit?  What a troll.

Which is not something that I've ever said. Learn to read.
I'd be very surprised if either one of you would admit to being wrong considering my previous post. Let's see whether we are really talking about "open-minded" individuals or "closed-minded" shills as suspected earlier.

[-ck]

This is an element of centralisation when pools can dictate their own rules... Thus dictate was relevant to pools.

Explain why it would be "extremely unpopular move and suicide for a cryptocurrency"?, when a miner producing an empty block when there is outstanding txs is stupid enough itself.

I don't disagree that pools producing empty blocks is stupid; heck I'm one of the BIGGEST campaigners against doing so in the mining world.

As for why developers cant mandate what goes into a block through network rules via a hard fork, bitcoin is an open transaction system and any attempt to strictly specify which transactions must go into a block in the reference core implementation would be futile. Not only does every node have a different mempool consisting of different transactions (it's impossible to sync all nodes to the same set of transactions in time and space), but enforcing certain transactions is actually creating a system with an unintentional censoring, prioritising and filtering of transactions in the world. The current system works off transaction fees as the incentive to choose transactions based on the reward making them more worth mining and indirectly creates a type of consensus without mandating order. Either way, the fact that no 2 mempools will be alike means it would be impossible to mandate anything anyway. Even empty blocks, as much as it pains me to say, must be allowed since theoretically there is a time and place where there are no transactions (though unlikely in bitcoin I agree) but additionally when a bitcoin node is restarted it has no transactions until they're gathered from the network or some are loaded from disk (in 0.14+). Even the ones loaded from disk may be all old and no longer mineable if enough blocks have passed since the node was restarted.

I didn't say 'which' but any validated txs. As long there are txs in the mempool, then the block should fill up until there is no txs in the mempool or block is over 95% full, for example. Empty blocks when there are no txs is fine but when there are thousands of txs waiting to be confirmed is madness.

Isn't that what the miners are already doing ?

I agree they SHOULD but as I said there is no way to reliably make it so they MUST.

Of course miners are choosing what goes into a block - that's precisely what mining is; mining transactions into the blockchain. You can't mine only "verified" transactions because the process of mining IS the verification.

[d5000]

What wrong with do both as hard fork? Wouldn't segwit hard fork be better than soft fork?

I assume if hard fork for both then there is a need to allow legacy txs to be converted at a later date. ie. 10 years.

A soft fork is always better if possible because of the "danger of two competing blockchains", and I don't see how a hard fork can solve the quadratic hashing problem here. (edited, see below) But legacy transactions cannot be permitted in an unrestricted way after the 2MB activation like today, as Lauda correctly points out:

I don't see how 2 MB + Segwit would avoid the quadratic problem on it's own. It needs to have some constraints on native transactions in order to work.

So the "grace period" between the Segwit activation and the 2MB activation must be as long as possible (~1 year) to correctly evaluate the danger of "full block spam" (in this case "4 MB block spam"). Edit: And the 2 MB hard fork should contain also a restriction for legacy transactions. Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses. But we don't have to do that already when the Segwit soft fork is activated (so we don't need a hard fork then), the 2 MB hard fork 1 year later would be early enough.

Regarding the possible 8 MB block spam, as I have already discussed in another thread, I would support going forward slower (first go to 1,5 MB/6 MB max. after a year and then to 2 MB after 1-2 years more if everything works right).