ok, listen up you guys.
i need all of you to get up to speed on the math behind SW, and now, given the $55M Blockstream announcement we just got. if you've ever wondered why we haven't gotten any explanations from core dev as to exactly how their calculations and assumptions have been derived is b/c there aren't any. they are intentionally keeping us in the dark about the economic consequences. based on my analysis, as i've alluded to above, SW will be damaging to miners immediate health by shifting fees away from the mainchain and into LN thru these complex multi-sig tx's that preferentially receive not only a discount (in cost/monetary terms) but also by forcing all of us (miners and full nodes) to carry/transmit even greater amounts of data.
to that end, i am sharing 2 pm exchanges i've had with AJTowns where he explains the higher level math and assumptions behind SW. note esp the part where gmax and pwuille had to make an "estimation" that the network can in fact carry 4MB of BW transmission safely (note the hypocrisy with what they've told us over the last year that 1MB only is safe). this has been explained as the edge case maximum block attack using a sigops single tx with essentially no data (no real economic tx) and 4MB of witness. remember, that this would be a 4MB *block* that still has to be transmitted but gets trimmed down to 1MB by discarding the witness data by 75% to allow it to be soft fork compatible with old nodes. my argument to this is that blocks like this up to 4MB can ALSO be created by inserting a preponderance of LN multi sig tx's into a block which will get a mandated/centrally planned "discount", not only in cost ($) but in space (bytes), giving them an advantage over regular tx's inserted into the same blocks. this isn't fair. this forces miners to get paid less and forces us all to transmit, BW-wise, all this extra data btwn 1-4MB in size depending on how many of these LN tx's get inserted into blocks. given that core dev is choking the mainchain blocks at 1MB and creating a fee mkt, this migration is inevitable as ppl are forced to use LN instead. and that's IF LN even makes economic sense.
pls read AJ's correspondence and give me your interpretations:
ajtowns sent 7 days ago
i'm confused by the use of this term by SW. afaik, it means both a discount in terms of how fees/B are calculated AND a discount in terms of how space is allocated to blocksize. is that true?
can you explain the discounts at a high level ? fyi, i'm very familiar with all other aspects and advantages of SW and have watched pwuille's video 3-4x. it's just this cost/space advantage calcs that are confusing.
thx,
cypher
ajtowns sent 7 days ago
i'm confused by the use of this term by SW. afaik, it means both a discount in terms of how fees/B are calculated AND a discount in terms of how space is allocated to blocksize. is that true?
One implies the other -- miners have a limit they can use up, so they'll fill up this limit in order of who pays the most fees. If they can get two transactions that pay 2c each that use the same amount of the limit as one transaction that pays 3c, they'll take the two transactions and the 4c.
can you explain the discounts at a high level ? fyi, i'm very familiar with all other aspects and advantages of SW and have watched pwuille's video 3-4x. it's just this cost/space advantage calcs that are confusing.
It's kind-of a standard multidimensional optimisation problem. Which probably isn't helpful if you don't think multidimensional optimisation problems are a normal thing to think about? 
So first, "discount" is an accurate way of describing what you get by segregating signature bytes into the witness, but it's not really that great a way of understanding it in the long-term. Probably a better way is to just think of two different sorts of bytes making up a transaction: ones that increase UTXO and have to be delivered across the network; versus ones that just have to be delivered across the network. Obviously the former will always be more expensive than the latter, but whether that should be 4x more expensive or something else is ambiguous; it's like asking how much more expensive a MFLOP of CPU and a GB of hard disk should be compared to just a GB of hard disk. You can pick a number, but similar numbers would also be reasonable, and it might change over time.
If you've got hard limits for both though, it's easy to get a figure. For segwit as a soft-fork, UTXO can't be more than 1MB, and per jtoomim's numbers 4MB in total is fine for bandwidth (which pwuille and gmaxwell and co also seem to have come up with independently, though I'm not sure if that's numbers or just gut feel). In that case if you're buying "a" lots of UTXO and bandwidth, and "b" lots of additional (witness) bandwidth, then you want a < 1MB and a+b < 4MB. If you write that as a+xb < y, then y<=1 from the first inequality, so 4a+4xb<=4. But the only way to then guarantee a+b<4MB is if x>1/4, so the final constraint is a+b/4<=1, so bytes of b are "discounted by 75%". But "really" what's happening is you're just getting a way of comparing fundamentally different costs, and saying that a byte that hits UTXO (and bandwidth) is 4x the cost of a byte than just hits bandwidth and coming up with a single equation to constrain them both.
The single constraint is stronger than the two we had initially, because you can't have a=0.5MB and b=3.5MB -- that would be 0.5+3.5/4 = 1.375 > 1. "stronger" means "worse" here, in some sense.
The benefit that makes that worthwhile is that it means you only have to worry about a single price when sending a transaction -- okay so the price of a kilobyte of UTXO is 13000 satoshi today, that means a kilobyte of witness is 3250 satoshi and my fee is just 13000*(a+b/4). That makes everything easy to work out.
If you had two different prices and their relationship varied, "UTXO is 13000 today, but witness is 5000 satoshi" then it might turn out that to minimise fees you'd want to vary how you structured your transactions -- "okay witness data's cheap, I can use multisig today", "ooops witness data got expensive, I'd better just use p2pkh", which would then make wallet software really complicated. And, of course, prices would actually be varying every block, rather than just every day.
(So, in summary, the answer is no, I probably can't explain it at a high level...)
- permalink
- block user
- ajtowns sent 6 days ago
But the only way to then guarantee a+b<4MB is if **x>1/4**, so the final constraint is a+b/4<=1
i'm almost there! got everything except for how you arrived at the x>1/4. can you re-jigger your explanation a bit or give me the basic math at how you arrived at that?
btw, great high level explanation of the knapsack problem!
ajtowns sent 6 days ago
So you were happy with "a + xb < 1MB", because that will guarantee "a < 1MB" (if we don't maintain that, it's not a soft-fork). But we also wanted to guaranteed "a + b < 4MB", and we've only got "x" left to play with.
We can rewrite "a + xb" as "a + b - (1-x)b", so we have "a + b - (1-x)b < 1MB", and rearranging gives "a + b < 1MB + (1-x)b". So we just need to guaranteed "1MB + (1-x)b < 4MB", or "(1-x)b < 3MB". But x is a constant, so this has to be true for any value of b, and the highest value of "b" we can have that satisfies "a+xb < 1MB" is "b=1/x" (when a=0), so we want "(1-x)(1/x) < 3MB", or "1/x-1 < 3" or "1/x < 4" or "x > 1/4".
(The knapsack problem as far as CS is concerned is really a different problem, that can just be ignored in bitcoin since most transactions are so much smaller than a block; what we've got here is the multi-dimensional knapsack problem, where we don't just concern ourselves with size, but also UTXO bloat or sigops or sighash operations. But using a weighted sum turns it back into the one-dimensional knapsack problem)
