On Mon, May 8, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > The non-witness data weight factor should not be 4 but 2.35. The closest > integer value is 2, which leads to a 50% witness discount.
Sergio, You've provided absolutely no information to qualify your "should be". It sounds like you are only measuring how much data is witness vs non-witness while completely ignoring the relative cost of UTXO bloat? It's perfectly acceptable to increase the worst case in one dimension while decreasing it in another-- and thats what segwit does. This sounds like a misunderstanding of what the factors should have accomplish. The non-witness factor should be as large as possible because the prunable witness data has little to no long term cost to the system, no cost to lite clients, etc-- as eventually the system's survival will require transitioning to starting from a state snapshot. But it cannot be too large because of the hyperbolic increase in worst case bandwidth. Also, when starting from a state snapshot security will require starting from an old one-- otherwise the whole system becomes much closer to SPV security, so the cost of witness data between there and the tip will still matter. If I had any leaning to adjust it, it would be towards five-- not towards even lower values. > The Bitcoinj source code is available for anyone to review. Where is it? (I have to say, I haven't found bitcoinj based things at all readable but it would be worth seeing.) _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
