Bitcoin Forum
December 01, 2021, 07:17:16 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)
AliceWonderMiscreations
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile WWW
March 12, 2017, 09:24:44 AM
 #161

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.

I hereby reserve the right to sometimes be wrong
1638386236
Hero Member
*
Offline Offline

Posts: 1638386236

View Profile Personal Message (Offline)

Ignore
1638386236
Reply with quote  #2

1638386236
Report to moderator
1638386236
Hero Member
*
Offline Offline

Posts: 1638386236

View Profile Personal Message (Offline)

Ignore
1638386236
Reply with quote  #2

1638386236
Report to moderator
1638386236
Hero Member
*
Offline Offline

Posts: 1638386236

View Profile Personal Message (Offline)

Ignore
1638386236
Reply with quote  #2

1638386236
Report to moderator
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1638386236
Hero Member
*
Offline Offline

Posts: 1638386236

View Profile Personal Message (Offline)

Ignore
1638386236
Reply with quote  #2

1638386236
Report to moderator
1638386236
Hero Member
*
Offline Offline

Posts: 1638386236

View Profile Personal Message (Offline)

Ignore
1638386236
Reply with quote  #2

1638386236
Report to moderator
jbreher
Legendary
*
Offline Offline

Activity: 2912
Merit: 1515


lose: unfind ... loose: untight


View Profile
March 12, 2017, 09:29:22 AM
 #162

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.

Quote
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?

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.
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 09:32:34 AM
Last edit: March 12, 2017, 09:47:51 AM by Lauda
 #163

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

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

"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 12, 2017, 12:27:45 PM
Last edit: March 12, 2017, 12:48:49 PM by AngryDwarf
 #164

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







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 12, 2017, 12:55:19 PM
 #165

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.

"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 12, 2017, 01:01:03 PM
 #166

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

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 12, 2017, 01:03:07 PM
 #167

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

"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 12, 2017, 01:06:39 PM
 #168

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.

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 12, 2017, 01:10:13 PM
 #169

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.

"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 12, 2017, 01:15:53 PM
 #170

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.

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

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 12, 2017, 01:18:19 PM
 #171

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

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

"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 12, 2017, 01:23:10 PM
 #172

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

Quote
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?

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 12, 2017, 01:25:34 PM
 #173

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.

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

Activity: 994
Merit: 543



View Profile
March 12, 2017, 01:26:21 PM
 #174

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

Quote
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
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 12, 2017, 01:30:00 PM
 #175

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?

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 12, 2017, 01:55:41 PM
 #176

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

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
AliceWonderMiscreations
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile WWW
March 12, 2017, 02:31:09 PM
 #177

That isn't disputed by most SegWit supporters.
Source?

Quote
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

I hereby reserve the right to sometimes be wrong
spooderman
Legendary
*
Offline Offline

Activity: 1624
Merit: 1008


View Profile WWW
March 12, 2017, 03:35:09 PM
 #178

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.

Society doesn't scale.
d5000
Legendary
*
Offline Offline

Activity: 3010
Merit: 2925


Decentralization Maximalist


View Profile
March 12, 2017, 03:51:04 PM
 #179

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
Legendary
*
Offline Offline

Activity: 3416
Merit: 1359


Ruu \o/


View Profile WWW
March 12, 2017, 04:12:09 PM
 #180

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

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
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!