AliceWonderMiscreations
|
|
March 12, 2017, 09:24:44 AM |
|
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
|
|
|
jbreher
Legendary
Offline
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
|
|
March 12, 2017, 09:29:22 AM |
|
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?
|
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
Activity: 2674
Merit: 2965
Terminated.
|
|
March 12, 2017, 09:32:34 AM Last edit: March 12, 2017, 09:47:51 AM by 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.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
AngryDwarf
|
|
March 12, 2017, 12:27:45 PM Last edit: March 12, 2017, 12:48:49 PM by 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 newpolicy.h /** The maximum weight for transactions we're willing to relay/mine */ static const unsigned int MAX_STANDARD_TX_WEIGHT = 400000; policy.cpp // 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 // 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 // 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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
March 12, 2017, 12:55:19 PM |
|
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
|
|
March 12, 2017, 01:01:03 PM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
March 12, 2017, 01:03:07 PM |
|
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
|
|
March 12, 2017, 01:06:39 PM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
March 12, 2017, 01:10:13 PM |
|
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
|
|
March 12, 2017, 01:15:53 PM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
March 12, 2017, 01:18:19 PM |
|
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.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
AngryDwarf
|
|
March 12, 2017, 01:23:10 PM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
March 12, 2017, 01:25:34 PM |
|
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
|
|
March 12, 2017, 01:26:21 PM |
|
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
|
|
March 12, 2017, 01:30:00 PM |
|
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
Legendary
Offline
Activity: 4354
Merit: 4693
|
|
March 12, 2017, 01:55:41 PM |
|
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
|
|
March 12, 2017, 02:31:09 PM |
|
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
|
I hereby reserve the right to sometimes be wrong
|
|
|
spooderman
Legendary
Offline
Activity: 1652
Merit: 1029
|
|
March 12, 2017, 03:35:09 PM |
|
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 (OP)
Legendary
Offline
Activity: 4046
Merit: 7257
Decentralization Maximalist
|
|
March 12, 2017, 03:51:04 PM |
|
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
Activity: 4228
Merit: 1644
Ruu \o/
|
|
March 12, 2017, 04:12:09 PM |
|
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
|
|
|
|