Pages:
Author

Topic: Last Time. In small words. Why 2MB impossible. Why Soft Fork. Why SegWit First.. - page 7. (Read 6499 times)

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
legendary
Activity: 4424
Merit: 4794
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
legendary
Activity: 924
Merit: 1000
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
legendary
Activity: 924
Merit: 1000
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.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
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.
legendary
Activity: 4424
Merit: 4794
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
Quote
/** 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
Quote
/** 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
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
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? Roll Eyes

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
legendary
Activity: 4424
Merit: 4794
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? Roll Eyes

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
legendary
Activity: 2674
Merit: 3000
Terminated.
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? Roll Eyes

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.
legendary
Activity: 4424
Merit: 4794
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
legendary
Activity: 2674
Merit: 3000
Terminated.
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?
legendary
Activity: 4424
Merit: 4794
plus gmax didnt dbunk anything. he just done what you usually do.. "wrong because word twist + insult"
He did debunk it by making such a statement as your claim is ludicruous.

wow "im ludicrous"
now thats real proof of concept there.
such merit in code and such merit in display of proving wrong by saying "im ludicrous", such detail in explaining it...

now then..
4k vs 16k sigop count, which do you think is worse
legendary
Activity: 2674
Merit: 3000
Terminated.
i was actually symplifying things without going into waffle for the benefit of the "one paragraph concentration spam" people of reddit/twitter
Regardless, you are wrong about the sigops.

plus gmax didnt dbunk anything. he just done what you usually do.. "wrong because word twist + insult"
He did debunk it by making such a statement as your claim is ludicruous. If I were to get the author of Segwit in here to tell you that you were wrong, you'd still write "he didn't debunk anything" nonsense.

If you're concerned about decentralization, SPV Fraud Proofs are better than ever:  https://bitcrust.org/blog-fraud-proofs
This is nonsense, as you'd expect it from a paid baboon. SPV Fraud Proofs are far from being practical and safe enough to alleviate the dangers of SPV wallets.

I had never heard of this fraud proof implementation. Interesting.
They are not ready yet. Hypocritically, the BTU supporters bash something that has been extensively tested for months but praise something that is new as safe just because it fits their agenda.  Roll Eyes
full member
Activity: 196
Merit: 101
If you're concerned about decentralization, SPV Fraud Proofs are better than ever:  https://bitcrust.org/blog-fraud-proofs

I had never heard of this fraud proof implementation. Interesting.

I just started reading it and one problem I see is that it requires a fork to Bitcoin that changes the merkle tree. This would break covert ASICBOOST (I'm not joking!) so I don't think Jihan will support it.

It seems like to do what they call 'fraud hints' would require a malleability fix too, so we'd still need segwit or another malleability fix, though I'm not entirely sure about this.

There are also some limitations to it:
Quote
The tricky frauds to proof, are not covered this way. An attacker can include a TXID of a non-existent transaction in the block. Such absence cannot be proofed as there is no invalid transaction to broadcast.

This article does not aim to structurally cover the full attack surface, nor does it provide detailed solutions; it should serve as an initial exploration of the possibilities of Fraud Proof SPV nodes using the spend tree.

legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political

CORE are NOT your enemy.
 

Yes they are.  Their actions speak for themselves.  They've stalled for years and damaged Bitcoin adoption, use-cases, and marketshare with high fees and slow confirmations.   Segwit as SF just allows them to continue to dole out whatever meager on chain capacity improvements they are willing to grant us.

I reject their economic approach entirely and believe blocksize should always be well beyond market demand.  Let off-chain solutions compete FAIRLY with on-chain, without any constraints.  

If you're concerned about decentralization, SPV Fraud Proofs are better than ever:  https://bitcrust.org/blog-fraud-proofs

legendary
Activity: 924
Merit: 1000
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.
legendary
Activity: 4424
Merit: 4794
CORE V 0.12 :  txsigops 4k blocksigops 20k = 5 tx of 4k each  (total block validation time if those 5tx were created = 50 seconds)

CORE V 0.14 :  txsigops 16k blocksigops 80k = 5 tx of 16k each (total block validation time if those 5tx were created = 40 minutes)
core v0.14.. is segwit.
Nonsense. The sigops in Core 0.14.0 are scaled for Segwit and have linear validation time. "40 minutes" is an outright lie.

yep more txsigop bloat is possible due to NEW limits of 0.14. which is segwit..
Do you even algorithm complexity?

This was debunked by me long ago, then later also commented on by Maxwell stating the absurdness of your claims.

i was actually symplifying things without going into waffle for the benefit of the "one paragraph concentration spam" people of reddit/twitter
so here goes, as condensed as i can make it:
Code:
MAX_STANDARD_TX_SIGOPS_COST
not
Code:
MAX_STANDARD_P2WSH_TX_SIGOPS_COST

plus gmax didnt dbunk anything. he just done what you usually do.. "wrong because word twist + insult"
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
legendary
Activity: 2674
Merit: 3000
Terminated.
CORE V 0.12 :  txsigops 4k blocksigops 20k = 5 tx of 4k each  (total block validation time if those 5tx were created = 50 seconds)

CORE V 0.14 :  txsigops 16k blocksigops 80k = 5 tx of 16k each (total block validation time if those 5tx were created = 40 minutes)
core v0.14.. is segwit.
Nonsense. The sigops in Core 0.14.0 are scaled for Segwit and have linear validation time. "40 minutes" is an outright lie.

yep more txsigop bloat is possible due to NEW limits of 0.14. which is segwit..
Do you even algorithm complexity?

This was debunked by me long ago, then later also commented on by Maxwell stating the absurdness of your claims.
Pages:
Jump to: