[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)

[AliceWonderMiscreations]

Do you understand that 'fungibility' is the property that no units of a thing have differing characteristics from other units?

So for you, being part of UTXO vs Segwit UTXO is an adequate characteristic to destroy fungibility?

Actually it is. That isn't disputed by most SegWit supporters.

[1713472993]

1713472993

[jbreher]

Do you understand that 'fungibility' is the property that no units of a thing have differing characteristics from other units?

So for you, being part of UTXO vs Segwit UTXO is an adequate characteristic to destroy fungibility? What happens when *all* (in theory) keys are Segwit UTXO? Fungibility suddenly returned?

I think you are on the verge of understanding that issue.

Way to make a technical rebuttal, Lauda. You're certainly on your game tonight.

I've come to realize that it is pointless to event attempt that since you only perceive what you want to. You are going to come to the same conclusion each time, regardless of whether you're wrong or not.

OK... sure. I'm quite certain you are unable to poke a hole in my scenario there. Why don't you try? Or even ... why don't you ping Harding with what I posted, and have him see if he can poke holes in it?

[Lauda]

That isn't disputed by most SegWit supporters.

Source?

I think you are on the verge of understanding that issue.

I don't see why it is an issue. I see it as a non-issue, just as you see quadratic validation as a non issue.

OK... sure. I'm quite certain you are unable to poke a hole in my scenario there. Why don't you try? Or even ... why don't you ping Harding with what I posted, and have him see if he can poke holes in it?

It was not worth bothering to be frank[1]; I just quickly went through it and saw your conclusion. I'm not going to be a messenger between you and someone with clearly superior understanding. Find a way to contact him yourself.
[1] - Looks like I'm turning into Franky.

[AngryDwarf]

-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.

I'd like to understand the reason spamming with native keys is useless after segwit activation.

However, it would seem that core is mitigating the problem by putting in restrictive policies right now:

Note: Code from 0.14 branch, not backtracked it to see when it was added - edit checked it is in the 0.13.x branch, so maybe not something new

policy.h

Code:

/** The maximum weight for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_WEIGHT = 400000;

policy.cpp

Code:

   // Extremely large transactions with lots of inputs can cost the network
    // almost as much to process as they cost the sender in fees, because
    // computing signature hashes is O(ninputs*txsize). Limiting transactions
    // to MAX_STANDARD_TX_WEIGHT mitigates CPU exhaustion attacks.
    unsigned int sz = GetTransactionWeight(tx);
    if (sz >= MAX_STANDARD_TX_WEIGHT) {
        reason = "tx-size";
        return false;
    }

net_processing.cpp

Code:

   // Ignore big transactions, to avoid a
    // send-big-orphans memory exhaustion attack. If a peer has a legitimate
    // large transaction with a missing parent then we assume
    // it will rebroadcast it later, after the parent transaction(s)
    // have been mined or received.
    // 100 orphans, each of which is at most 99,999 bytes big is
    // at most 10 megabytes of orphans and somewhat more byprev index (in the worst case):
    unsigned int sz = GetTransactionWeight(*tx);
    if (sz >= MAX_STANDARD_TX_WEIGHT)
    {
        LogPrint("mempool", "ignoring large orphan tx (size: %u, hash: %s)\n", sz, hash.ToString());
        return false;
    }

wallet.cpp

Code:

       // Limit size
        if (GetTransactionWeight(wtxNew) >= MAX_STANDARD_TX_WEIGHT)
        {
            strFailReason = _("Transaction too large");
            return false;
        }

In other words, segwit activation is not needed for the change. It is effective right now. So what does segwit activation bring?

[Lauda]

I'd like to understand the reason spamming with native keys is useless after segwit activation.

This is quite simple. Take a look:
1) 1 MB (current) -> No DoS risk (quadratic hashing).
2) 2 MB (bare block size increase) -> DoS risk (quadratic hashing).
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).
4) 1 MB post Segwit (implies 100% native keys) -> No DoS risk (quadratic hashing); the same as the first line.
I'll check the remainder of your post later today.

[AngryDwarf]

I'd like to understand the reason spamming with native keys is useless after segwit activation.

This is quite simple. Take a look:
1) 1 MB (current) -> No DoS risk (quadratic hashing).
2) 2 MB (bare block size increase) -> DoS risk (quadratic hashing).
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).
4) 1 MB post Segwit (implies 100% native keys) -> No DoS risk (quadratic hashing); the same as the first line.

1) 1 MB (current) -> lower DoS risk (quadratic hashing).
2) 2 MB (bare block size increase) -> higher DoS risk (quadratic hashing).
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).
4) 1 MB post Segwit (implies 100% native keys) -> lower DoS risk (quadratic hashing); the same as the first line.

Is that a fair FTFY?

Also

5) 2 MB post Segwit (implies 100% native keys) -> higher DoS risk (quadratic hashing) - unless there are plans to limit native key space in blocks

[Lauda]

1) 1 MB (current) -> lower DoS risk (quadratic hashing).
2) 2 MB (bare block size increase) -> higher DoS risk (quadratic hashing).
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).
4) 1 MB post Segwit (implies 100% native keys) -> No lower risk (quadratic hashing); the same as the first line.

Is that a fair FTFY?

Yes and no. Writing it like that seems rather vague considering that we don't have exact data on it. It would be nice if someone actually did some in-depth research into this and tried to construct the worst kind of TX possible (validation time wise).

[AngryDwarf]

Yes and no. Writing it like that seems rather vague considering that we don't have exact data on it. It would be nice if someone actually did some in-depth research into this and tried to construct the worst kind of TX possible (validation time wise).

As core not done any research on this then? - also check edits above.

[Lauda]

5) 2 MB post Segwit (implies 100% native keys) -> higher DoS risk (quadratic hashing) - unless there are plans to limit native key space in blocks

No. You still don't understand Segwit. You can not create a 2 MB block using 100% native keys when Segwit is activated. You can only create a 1 MB block if you're using 100% native keys.

As core not done any research on this then?

I'm saying that you and I don't have adequate data, and no exact data in this thread. There was some article about a block that takes longer than 10 minutes to validate at 2 MB somewhere.

[AngryDwarf]

5) 2 MB post Segwit (implies 100% native keys) -> higher DoS risk (quadratic hashing) - unless there are plans to limit native key space in blocks

No. You still don't understand Segwit. You can not create a 2 MB block using 100% native keys when Segwit is activated. You can only create a 1 MB block if you're using 100% native keys.

I think I misunderstood the below and thought you was talking about a post segwit block size increase.

3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

So that would be

3) 2 MB estimated effective capacity (1MB transaction block limit) post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

[Lauda]

I think I misunderstood the below and thought you was talking about a post segwit block size increase.

3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

So that would be

3) 2 MB estimated effective capacity (1MB transaction block limit) post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

No, that is not the case. Basically the first two points are about a 'base block size increase', and the second one are just pure Segwit as it currently is. You can formulate the points in a better fashion, as long as they stay correct.

[AngryDwarf]

I think I misunderstood the below and thought you was talking about a post segwit block size increase.

3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

So that would be

3) 2 MB estimated effective capacity (1MB transaction block limit) post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

No, that is not the case. Basically the first two points are about a 'base block size increase', and the second one are just pure Segwit as it currently is. You can formulate the points in a better fashion, as long as they stay correct.

So how would you reword point 3? The original version may be open to interpretation which could lead to misunderstanding. Why do you think my wording is not correct?

[Lauda]

So how would you reword point 3? The original version may be open to interpretation which could lead to misunderstanding. Why do you think my wording is not correct?

I did not say it was incorrect. If you want to be even further specific, stop referring to it as 'block size' if you're talking about a scenario in which Segwit is activated. The block size is split into two parameters:
1) 1 MB base.
2) 4 MB weight.

[Xester]

I think I misunderstood the below and thought you was talking about a post segwit block size increase.

3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

So that would be

3) 2 MB estimated effective capacity (1MB transaction block limit) post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

No, that is not the case. Basically the first two points are about a 'base block size increase', and the second one are just pure Segwit as it currently is. You can formulate the points in a better fashion, as long as they stay correct.

Using simple logic these arguments are nothing to be debated. We cannot deny that segwit came out to the open because it can solve the issue on blocksize. If it cannot help solve the current problems on bitcoin network then they will not propose it. For now instead of debating why not just wait for the consensus to occur so we can enjoy bitcoins without flaw.

[AngryDwarf]

if you're talking about a scenario in which Segwit is activated. The block size is split into two parameters:
1) 1 MB base.
2) 4 MB weight.

So what is the definition of weight, and how does this relate to data storage requirements?

[franky1]

lauda.

take no offense by this..(think of this as a genuine question, requiring your critical thinking cap to be worn)
but are you thinking that a quadratic sigop attack is just about limiting sigops to not cause validation delays when a solved block is relayed.
..
because thats how im reading your thought process on your definition of DoS attack


have you thought about this as a DoS attack:
those limits which you think are defending validation time attack of solved blocks. can actually be used as an attack by filling a block

EG if a block in v.12 only allowed 20ksigops for the block and 4k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.
EG if a block in v.14 only allowed 80ksigops for the block and 16k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.

thus a native key user can with just 5 tx stop other tx's getting in. and thus all segwit promises cant be met.
no boost to blocksize as no segwit tx's adding to the block.

rmember im not talking about delay in validation times of propagation after block is solved. im just talking about filling blocks (mempool attack leaving everyone waiting)


so knowing that the segwit 'activation' does nothing to disarm native keys.
meaning
blocks can stay at 1mb. (either with as little as 5 native(sigopsbloatfill) or thousands of natives(databloatfill))
malleation and sigops are not disarmed.
so effectively.. what does segwit actually offer that is a real feature that has real 100% guarantee promise

[AliceWonderMiscreations]

That isn't disputed by most SegWit supporters.

Source?

The existence of two UTXO types with different security and economic properties also deteriorates Bitcoin’s fungibility. Miners and fully validating nodes may decide not to relay, or include in blocks, transactions that spend to one type or the other. While on one hand this is a positive step towards enforceability (i.e. soft enforceability), it is detrimental to unsophisticated Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability. Fundamentally this means that the face-value of Bitcoin will not be economically treated the same way depending on the type of output it comes from.

https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179#.mt4mf9jjh

[spooderman]

2MB is an action that would "compromise" decentralization and therefore security. and it would be occurring as a result of political pressure rather than technical necessity.

that is not a compromise i am willing to make.

[d5000]

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)

all that coded into a single BIP/pull request, to make it attractive for "big blocker" miners to accept it.

(I hope the terminology is OK)

[-ck]

As core not done any research on this then?

I'm saying that you and I don't have adequate data, and no exact data in this thread. There was some article about a block that takes longer than 10 minutes to validate at 2 MB somewhere.

https://rusty.ozlabs.org/?p=522