* [bitcoin-dev] Some real-world results about the current Segwit Discount @ 2017-05-08 22:42 Sergio Demian Lerner 2017-05-08 23:47 ` Alphonse Pace 2017-05-08 23:56 ` Gregory Maxwell 0 siblings, 2 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-08 22:42 UTC (permalink / raw) To: bitcoin-dev; +Cc: hello [-- Attachment #1: Type: text/plain, Size: 1214 bytes --] I have processed 1000 blocks starting from Block #461653. I computed several metrics, including the supposed size of witness data and non-witness data (onchain), assuming all P2SH inputs/outputs are converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. This takes into account that other types of transactions will not be modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't take into account that LN transactions may affect the current state, increasing the segwit/nosegwit ratio. Among a lot of information, I've got the following real world results... acMainChainSpace =352608924 acSegwitSpace =599400403 Ratio segwit/nosegwit=1.6999 This implies that the 75% that discount is not the best option to prevent witness spam in a block of 4 MB, as stated in https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e. 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. The Bitcoinj source code is available for anyone to review. I encourage anyone to re-compute this with another utility to cross-check. Maybe Antoine Le Calvez (p2sh.info) would like to double-check. [-- Attachment #2: Type: text/html, Size: 1655 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-08 22:42 [bitcoin-dev] Some real-world results about the current Segwit Discount Sergio Demian Lerner @ 2017-05-08 23:47 ` Alphonse Pace 2017-05-09 13:49 ` Sergio Demian Lerner 2017-05-08 23:56 ` Gregory Maxwell 1 sibling, 1 reply; 21+ messages in thread From: Alphonse Pace @ 2017-05-08 23:47 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1970 bytes --] Sergio, I'm not sure what the data you present has to do with the discount. A 75% discount prevents witness spam precisely because it is 75%, nothing more. The current usage simply gives a guideline on how much capacity is gained through a particular discount. With the data you show, it would imply that those blocks, with SegWit used where possible, would result in blocks of ~1.8MB. On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > I have processed 1000 blocks starting from Block #461653. > > I computed several metrics, including the supposed size of witness data > and non-witness data (onchain), assuming all P2SH inputs/outputs are > converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. > > This takes into account that other types of transactions will not be > modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't > take into account that LN transactions may affect the current state, > increasing the segwit/nosegwit ratio. > > Among a lot of information, I've got the following real world results... > > acMainChainSpace =352608924 > acSegwitSpace =599400403 > Ratio segwit/nosegwit=1.6999 > > This implies that the 75% that discount is not the best option to prevent > witness spam in a block of 4 MB, as stated in https://segwit.org/why-a- > discount-factor-of-4-why-not-2-or-8-bbcebe91721e. > > 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. > > The Bitcoinj source code is available for anyone to review. I encourage > anyone to re-compute this with another utility to cross-check. Maybe > Antoine Le Calvez (p2sh.info) would like to double-check. > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2969 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-08 23:47 ` Alphonse Pace @ 2017-05-09 13:49 ` Sergio Demian Lerner 2017-05-09 14:33 ` James Hilliard ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-09 13:49 UTC (permalink / raw) To: Alphonse Pace; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4104 bytes --] This [1] article says the current discount prevents witness spam. Witness spam is free space in the witness part of the block that can be filled by miners to create bigger blocks with almost no cost for the benefit a cluster of miners with low latency, increasing centralization. The 75% discount does not prevent it, but on the contrary leaves a lot of extra witness space for spam. If the maximum block weight is set to 2.7M, each byte of non-witness block costs 1.7, and each byte of witness costs 1, then a normal filled block would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4 Mbyte block. The worst case would be the average case, and the transaction rate would be the maximum possible. The current 75% discount can only achieve more transactions per second if the type of transactions change. Therefore the current 75% discount only makes the block size worst case worse (4 Mbytes when it should be 2.7 Mbytes). 80% of all inputs/outputs are P2PKH. The only way to make use of the extra witness space If most P2PKH transactions are replaced by multisigs (typically for LN). So it seems the 75% discount has been chosen with the idea that in the future the current transaction pattern will shift towards multisigs. This is not a bad idea, as it's the only direction Bitcoin can scale without a HF. But it's a bad idea if we end up doing, for example, a 2X blocksize increase HF in the future. In that case it's much better to use a 50% witness discount, and do not make scaling risky by making the worse case block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. I've uploaded the code here: https://github.com/SergioDemianLerner/SegwitStats [1] https://segwit.org/why-a-discount-factor-of-4-why-not- 2-or-8-bbcebe91721e. On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Sergio, > > I'm not sure what the data you present has to do with the discount. A 75% > discount prevents witness spam precisely because it is 75%, nothing more. > The current usage simply gives a guideline on how much capacity is gained > through a particular discount. With the data you show, it would imply that > those blocks, with SegWit used where possible, would result in blocks of > ~1.8MB. > > > > On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> I have processed 1000 blocks starting from Block #461653. >> >> I computed several metrics, including the supposed size of witness data >> and non-witness data (onchain), assuming all P2SH inputs/outputs are >> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. >> >> This takes into account that other types of transactions will not be >> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't >> take into account that LN transactions may affect the current state, >> increasing the segwit/nosegwit ratio. >> >> Among a lot of information, I've got the following real world results... >> >> acMainChainSpace =352608924 >> acSegwitSpace =599400403 >> Ratio segwit/nosegwit=1.6999 >> >> This implies that the 75% that discount is not the best option to prevent >> witness spam in a block of 4 MB, as stated in >> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e >> . >> >> 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. >> >> The Bitcoinj source code is available for anyone to review. I encourage >> anyone to re-compute this with another utility to cross-check. Maybe >> Antoine Le Calvez (p2sh.info) would like to double-check. >> >> >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6245 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 13:49 ` Sergio Demian Lerner @ 2017-05-09 14:33 ` James Hilliard 2017-05-09 15:45 ` Johnson Lau 2017-05-09 18:15 ` Matt Corallo 2 siblings, 0 replies; 21+ messages in thread From: James Hilliard @ 2017-05-09 14:33 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev The discount is designed to reduce UTXO bloat primarily, witness spam data would not make it into the UTXO set. The discount brings the fee of a transaction more in line with the actual costs to the network for the transaction. A miner spamming the network with 4MB witness blocks would have very little impact on the UTXO size compared with 1MB non-witness blocks. UTXO size is a bigger issue than blockchain size since full nodes can't prune the UTXO set. The discount of 75% for the SegWit softfork doesn't really have any effect on future hard forks as it can always be adjusted as needed later on as part of a HF. On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > This [1] article says the current discount prevents witness spam. Witness > spam is free space in the witness part of the block that can be filled by > miners to create bigger blocks with almost no cost for the benefit a cluster > of miners with low latency, increasing centralization. > > The 75% discount does not prevent it, but on the contrary leaves a lot of > extra witness space for spam. > > If the maximum block weight is set to 2.7M, each byte of non-witness block > costs 1.7, and each byte of witness costs 1, then a normal filled block > would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4 > Mbyte block. The worst case would be the average case, and the transaction > rate would be the maximum possible. > > The current 75% discount can only achieve more transactions per second if > the type of transactions change. Therefore the current 75% discount only > makes the block size worst case worse (4 Mbytes when it should be 2.7 > Mbytes). > > 80% of all inputs/outputs are P2PKH. The only way to make use of the extra > witness > space If most P2PKH transactions are replaced by multisigs (typically for > LN). > > So it seems the 75% discount has been chosen with the idea that in the > future the current transaction pattern will shift towards multisigs. This is > not a bad idea, as it's the only direction Bitcoin can scale without a HF. > But it's a bad idea if we end up doing, for example, a 2X blocksize increase > HF in the future. In that case it's much better to use a 50% witness > discount, and do not make scaling risky by making the worse case block size > 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. > > I've uploaded the code here: > https://github.com/SergioDemianLerner/SegwitStats > > [1] > https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e. > > > On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> Sergio, >> >> I'm not sure what the data you present has to do with the discount. A 75% >> discount prevents witness spam precisely because it is 75%, nothing more. >> The current usage simply gives a guideline on how much capacity is gained >> through a particular discount. With the data you show, it would imply that >> those blocks, with SegWit used where possible, would result in blocks of >> ~1.8MB. >> >> >> >> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >>> >>> I have processed 1000 blocks starting from Block #461653. >>> >>> I computed several metrics, including the supposed size of witness data >>> and non-witness data (onchain), assuming all P2SH inputs/outputs are >>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. >>> >>> This takes into account that other types of transactions will not be >>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't >>> take into account that LN transactions may affect the current state, >>> increasing the segwit/nosegwit ratio. >>> >>> Among a lot of information, I've got the following real world results... >>> >>> acMainChainSpace =352608924 >>> acSegwitSpace =599400403 >>> Ratio segwit/nosegwit=1.6999 >>> >>> This implies that the 75% that discount is not the best option to prevent >>> witness spam in a block of 4 MB, as stated in >>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e. >>> >>> 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. >>> >>> The Bitcoinj source code is available for anyone to review. I encourage >>> anyone to re-compute this with another utility to cross-check. Maybe Antoine >>> Le Calvez (p2sh.info) would like to double-check. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 13:49 ` Sergio Demian Lerner 2017-05-09 14:33 ` James Hilliard @ 2017-05-09 15:45 ` Johnson Lau 2017-05-09 16:19 ` Sergio Demian Lerner 2017-05-09 18:15 ` Matt Corallo 2 siblings, 1 reply; 21+ messages in thread From: Johnson Lau @ 2017-05-09 15:45 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > So it seems the 75% discount has been chosen with the idea that in the future the current transaction pattern will shift towards multisigs. This is not a bad idea, as it's the only direction Bitcoin can scale without a HF. > But it's a bad idea if we end up doing, for example, a 2X blocksize increase HF in the future. In that case it's much better to use a 50% witness discount, and do not make scaling risky by making the worse case block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. > As we could change any parameter in a hardfork, I don’t think this has any relation with the current BIP141 proposal. We could just use 75% in a softfork, and change that to a different value (or completely redefine the definition of weight) with a hardfork later. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 15:45 ` Johnson Lau @ 2017-05-09 16:19 ` Sergio Demian Lerner 2017-05-09 16:27 ` Johnson Lau 2017-05-09 16:27 ` James Hilliard 0 siblings, 2 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-09 16:19 UTC (permalink / raw) To: Johnson Lau; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1422 bytes --] Thanks Johnson and Hampus for the clarifications. However, I would rather do the opposite: soft-fork to 50% now, and soft-fork again to 75% discount later if needed, because it doesn't affect the max transactions/second. Segwit as it is today should be activated. However if it is not before November, then for the next Segwit attempt I would choose a more conservative 50% discount. On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012@xbt•hk> wrote: > > > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > > > So it seems the 75% discount has been chosen with the idea that in the > future the current transaction pattern will shift towards multisigs. This > is not a bad idea, as it's the only direction Bitcoin can scale without a > HF. > > But it's a bad idea if we end up doing, for example, a 2X blocksize > increase HF in the future. In that case it's much better to use a 50% > witness discount, and do not make scaling risky by making the worse case > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. > > > > As we could change any parameter in a hardfork, I don’t think this has any > relation with the current BIP141 proposal. We could just use 75% in a > softfork, and change that to a different value (or completely redefine the > definition of weight) with a hardfork later. > > > [-- Attachment #2: Type: text/html, Size: 1903 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 16:19 ` Sergio Demian Lerner @ 2017-05-09 16:27 ` Johnson Lau 2017-05-09 16:27 ` James Hilliard 1 sibling, 0 replies; 21+ messages in thread From: Johnson Lau @ 2017-05-09 16:27 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1862 bytes --] No, changing from 50% to 75% is a hardfork. (75 -> 50 is a softfork). Unless you make it pre-scheduled, or leave a special “backdoor” softfork to change the discount. And that would certainly reduce the max tx/s with 50% discount, also reduce the incentive to spend witness UTXO. > On 10 May 2017, at 00:19, Sergio Demian Lerner <sergio.d.lerner@gmail•com> wrote: > > Thanks Johnson and Hampus for the clarifications. > However, I would rather do the opposite: soft-fork to 50% now, and soft-fork again to 75% discount later if needed, because it doesn't affect the max transactions/second. > > Segwit as it is today should be activated. However if it is not before November, then for the next Segwit attempt I would choose a more conservative 50% discount. > > > > On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012@xbt•hk <mailto:jl2012@xbt•hk>> wrote: > > > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > > > > > So it seems the 75% discount has been chosen with the idea that in the future the current transaction pattern will shift towards multisigs. This is not a bad idea, as it's the only direction Bitcoin can scale without a HF. > > But it's a bad idea if we end up doing, for example, a 2X blocksize increase HF in the future. In that case it's much better to use a 50% witness discount, and do not make scaling risky by making the worse case block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. > > > > As we could change any parameter in a hardfork, I don’t think this has any relation with the current BIP141 proposal. We could just use 75% in a softfork, and change that to a different value (or completely redefine the definition of weight) with a hardfork later. > > > [-- Attachment #2: Type: text/html, Size: 3054 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 16:19 ` Sergio Demian Lerner 2017-05-09 16:27 ` Johnson Lau @ 2017-05-09 16:27 ` James Hilliard 1 sibling, 0 replies; 21+ messages in thread From: James Hilliard @ 2017-05-09 16:27 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev Doing a second soft-fork from 50% to 75% sounds more difficult since that's going from a more restrictive ruleset to less restrictive, you might be able to hack around it but it wouldn't be a fully backwards compatible change like going from 75% to 50% would be. 50% vs 75% does affect max transactions/second in practice, the exact amount depends on the real world usage of course though. On Tue, May 9, 2017 at 11:19 AM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Thanks Johnson and Hampus for the clarifications. > However, I would rather do the opposite: soft-fork to 50% now, and soft-fork > again to 75% discount later if needed, because it doesn't affect the max > transactions/second. > > Segwit as it is today should be activated. However if it is not before > November, then for the next Segwit attempt I would choose a more > conservative 50% discount. > > > > On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012@xbt•hk> wrote: >> >> >> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev >> > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> > >> > >> > So it seems the 75% discount has been chosen with the idea that in the >> > future the current transaction pattern will shift towards multisigs. This is >> > not a bad idea, as it's the only direction Bitcoin can scale without a HF. >> > But it's a bad idea if we end up doing, for example, a 2X blocksize >> > increase HF in the future. In that case it's much better to use a 50% >> > witness discount, and do not make scaling risky by making the worse case >> > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. >> > >> >> As we could change any parameter in a hardfork, I don’t think this has any >> relation with the current BIP141 proposal. We could just use 75% in a >> softfork, and change that to a different value (or completely redefine the >> definition of weight) with a hardfork later. >> >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 13:49 ` Sergio Demian Lerner 2017-05-09 14:33 ` James Hilliard 2017-05-09 15:45 ` Johnson Lau @ 2017-05-09 18:15 ` Matt Corallo 2017-05-09 18:58 ` Sergio Demian Lerner 2 siblings, 1 reply; 21+ messages in thread From: Matt Corallo @ 2017-05-09 18:15 UTC (permalink / raw) To: Sergio Demian Lerner, Alphonse Pace; +Cc: bitcoin-dev I'm not sure who wrote segwit.org, but I wouldn't take it as authoritative reasoning why we must do X over Y. You seem to be claiming that there is not cost for a miner to fill "extra witness space", but this is very untrue - in order to do so they must forgo fees on other transactions. Your analysis on worst-case vs normal-case blocks also seems flawed - there is a single limit, and not a separate, secondary, witness limit. You suggested "If the maximum block weight is set to 2.7M, each byte of non-witness block costs 1.7", but these numbers dont work out - setting the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft fork), not 2.7MB. If you set the max block weight to 2.7 with a 1.7x discount, you have a hard fork. If you set the discount to 2.7x with a 2.7 weight limit, you dont get 2.7MB average-sized blocks, but smaller, and still have the potential for padding blocks with pure-witness data to create larger blocks. Additionally, note that by padding blocks with larger witness data you lose some of the CPU cost to validate as you no longer have as many inputs (which have a maximal validation cost). Further, I'm not sure why you're arguing for a given witness discount on the basis of a future hardfork - it seems highly unlikely the community is in a position to pull something like that off, and even if it were, why set the witness discount with that assumption? If there were to be a hardfork, we should probably tweak a bunch of parameters (see, eg, my post from February of last year at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html). Maybe you could clarify your proposal a bit here, because the way I read it you seem to have misunderstood SegWit's discount system. On 05/09/17 13:49, Sergio Demian Lerner via bitcoin-dev wrote: > This [1] article says the current discount prevents witness spam. > Witness spam is free space in the witness part of the block that can be > filled by miners to create bigger blocks with almost no cost for the > benefit a cluster of miners with low latency, increasing centralization. > > The 75% discount does not prevent it, but on the contrary leaves a lot > of extra witness space for spam. > > If the maximum block weight is set to 2.7M, each byte of non-witness > block costs 1.7, and each byte of witness costs 1, then a normal filled > block would be 2.7M bytes (1.7+1), and there will be no need to create > ever a 4 Mbyte block. The worst case would be the average case, and the > transaction rate would be the maximum possible. > > The current 75% discount can only achieve more transactions per second > if the type of transactions change. Therefore the current 75% discount > only makes the block size worst case worse (4 Mbytes when it should be > 2.7 Mbytes). > > 80% of all inputs/outputs are P2PKH. The only way to make use of the > extra witness > space If most P2PKH transactions are replaced by multisigs (typically > for LN). > > So it seems the 75% discount has been chosen with the idea that in the > future the current transaction pattern will shift towards multisigs. > This is not a bad idea, as it's the only direction Bitcoin can scale > without a HF. > But it's a bad idea if we end up doing, for example, a 2X blocksize > increase HF in the future. In that case it's much better to use a 50% > witness discount, and do not make scaling risky by making the worse case > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes. > > I've uploaded the code here: > https://github.com/SergioDemianLerner/SegwitStats > > [1] https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e > <https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e>. > > > On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > Sergio, > > I'm not sure what the data you present has to do with the discount. > A 75% discount prevents witness spam precisely because it is 75%, > nothing more. The current usage simply gives a guideline on how > much capacity is gained through a particular discount. With the > data you show, it would imply that those blocks, with SegWit used > where possible, would result in blocks of ~1.8MB. > > > > On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > I have processed 1000 blocks starting from Block #461653. > > I computed several metrics, including the supposed size of > witness data and non-witness data (onchain), assuming all P2SH > inputs/outputs are converted to P2PWSH and all P2PKH > inputs/outputs are converted to P2WPKH. > > This takes into account that other types of transactions will > not be modified by Segwit (e.g. OP_RETURN outputs, or P2PK). > This analysis doesn't take into account that LN transactions may > affect the current state, increasing the segwit/nosegwit ratio. > > Among a lot of information, I've got the following real world > results... > > acMainChainSpace =352608924 > acSegwitSpace =599400403 > Ratio segwit/nosegwit=1.6999 > > This implies that the 75% that discount is not the best option > to prevent witness spam in a block of 4 MB, as stated in > https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e > <https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e>. > > 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. > > The Bitcoinj source code is available for anyone to review. I > encourage anyone to re-compute this with another utility to > cross-check. Maybe Antoine Le Calvez (p2sh.info > <http://p2sh.info>) would like to double-check. > > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 18:15 ` Matt Corallo @ 2017-05-09 18:58 ` Sergio Demian Lerner 2017-05-09 19:15 ` Sergio Demian Lerner 0 siblings, 1 reply; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-09 18:58 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 385 bytes --] > > > > You suggested "If the maximum block weight is set to 2.7M, each byte of > non-witness block costs 1.7", but these numbers dont work out - setting > the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft > fork), not 2.7MB. Yes. In a soft-fork is true. I was thinking about what a HF could do to optimize the balance, and I forgot I was in the context of a SF. [-- Attachment #2: Type: text/html, Size: 688 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 18:58 ` Sergio Demian Lerner @ 2017-05-09 19:15 ` Sergio Demian Lerner 2017-05-09 19:30 ` Gregory Maxwell 0 siblings, 1 reply; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-09 19:15 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1049 bytes --] Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7. Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4) n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000 Then n=4,000,000 / 5.7 = 701K Average block size = 701K*(1+1.7)=1.8 Mbytes Maximum block size = 4 MBytes Segwit with 50% discount + 2MB HF: (let WITNESS_SCALE_FACTOR=2) n*2+n*1.7 = 4,000,000 n = 4,000,000/ 3.7 = 1.08M Average block size = 1.08M*(1+1.7)=2.9 Mbytes Maximum block size = 4 MBytes The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum block size is the same. On Tue, May 9, 2017 at 3:58 PM, Sergio Demian Lerner < sergio.d.lerner@gmail•com> wrote: > >> >> You suggested "If the maximum block weight is set to 2.7M, each byte of >> non-witness block costs 1.7", but these numbers dont work out - setting >> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft >> fork), not 2.7MB. > > > Yes. In a soft-fork is true. > I was thinking about what a HF could do to optimize the balance, and I > forgot I was in the context of a SF. > > > [-- Attachment #2: Type: text/html, Size: 1882 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 19:15 ` Sergio Demian Lerner @ 2017-05-09 19:30 ` Gregory Maxwell 2017-05-09 19:42 ` Matt Corallo 0 siblings, 1 reply; 21+ messages in thread From: Gregory Maxwell @ 2017-05-09 19:30 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum > block size is the same. And the UTXO bloat potential is twice as large and the cost of that UTXO bloat is significantly reduced. So you're basically gutting the most of the gain from weight, making something incompatible, etc. I'm not sure what to explain-- even that page on segwit.org explains that the values are selected to balance worst case costs not to optimize one to the total exclusion of others. Raw size is not very relevant in the long run, but if your goal were to optimize for it (which it seems to be), then the limit should be pure size. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 19:30 ` Gregory Maxwell @ 2017-05-09 19:42 ` Matt Corallo 2017-05-09 20:13 ` Gregory Maxwell 0 siblings, 1 reply; 21+ messages in thread From: Matt Corallo @ 2017-05-09 19:42 UTC (permalink / raw) To: Gregory Maxwell, Sergio Demian Lerner; +Cc: bitcoin-dev There is something in between throwing the SegWit goals out the window (as Sergio seems to be advocating for) and having a higher discount ratio (which is required for the soft fork version to be useful). When I first started looking at the problem I very much wanted to reduce the worst-case block size (though have come around to caring a bit less about that thanks to all the work in FIBRE and other similar systems over the past year or two), but rapidly realized that just reducing the Segwit discount wasn't really the right solution here. You might as well take the real win and reduce the cost of the input prevout itself so that average inputs are less expensive than outputs (which SegWit doesn't quite achieve due to the large prevout size - 40 bytes). This way you can reduce the discount, still get the SegWit goal, and get a lower ratio between worst-case and average-case block size, though, frankly, I'm less interested in the last one these days, at least for reasonable parameters. If you're gonna look at hard forks, limiting yourself to just the parameters that we can tweak in a soft fork seems short-sighted, at beast. Matt On 05/09/17 19:30, Gregory Maxwell wrote: > On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum >> block size is the same. > > And the UTXO bloat potential is twice as large and the cost of that > UTXO bloat is significantly reduced. So you're basically gutting the > most of the gain from weight, making something incompatible, etc. > > I'm not sure what to explain-- even that page on segwit.org explains > that the values are selected to balance worst case costs not to > optimize one to the total exclusion of others. Raw size is not very > relevant in the long run, but if your goal were to optimize for it > (which it seems to be), then the limit should be pure size. > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 19:42 ` Matt Corallo @ 2017-05-09 20:13 ` Gregory Maxwell 2017-05-09 20:58 ` Sergio Demian Lerner 0 siblings, 1 reply; 21+ messages in thread From: Gregory Maxwell @ 2017-05-09 20:13 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-dev On Tue, May 9, 2017 at 7:42 PM, Matt Corallo <lf-lists@mattcorallo•com> wrote: > at beast. Rawr. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 20:13 ` Gregory Maxwell @ 2017-05-09 20:58 ` Sergio Demian Lerner 2017-05-10 5:37 ` Jorge Timón 2017-05-10 14:05 ` Matt Corallo 0 siblings, 2 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-09 20:58 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 452 bytes --] I agree with you Matt. I'm artificially limiting myself to changing the parameters of Segwit as it is.. This is motivated by the idea that a consensual HF in the current state would have greater chance of acceptance if it changes the minimum number of lines of code. On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg@xiph•org> wrote: > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo <lf-lists@mattcorallo•com> > wrote: > > at beast. > > Rawr. > [-- Attachment #2: Type: text/html, Size: 874 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 20:58 ` Sergio Demian Lerner @ 2017-05-10 5:37 ` Jorge Timón 2017-05-10 14:05 ` Matt Corallo 1 sibling, 0 replies; 21+ messages in thread From: Jorge Timón @ 2017-05-10 5:37 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 916 bytes --] If there's a better factor than 0.25 I would change it now before deploying segwit instead of leaving it to be changed later with a hf. On 9 May 2017 10:59 pm, "Sergio Demian Lerner via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > I agree with you Matt. > I'm artificially limiting myself to changing the parameters of Segwit as > it is.. > > This is motivated by the idea that a consensual HF in the current state > would have greater chance of acceptance if it changes the minimum number of > lines of code. > > > > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg@xiph•org> wrote: > >> On Tue, May 9, 2017 at 7:42 PM, Matt Corallo <lf-lists@mattcorallo•com> >> wrote: >> > at beast. >> >> Rawr. >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 1834 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-09 20:58 ` Sergio Demian Lerner 2017-05-10 5:37 ` Jorge Timón @ 2017-05-10 14:05 ` Matt Corallo 2017-05-10 15:25 ` Sergio Demian Lerner 1 sibling, 1 reply; 21+ messages in thread From: Matt Corallo @ 2017-05-10 14:05 UTC (permalink / raw) To: Sergio Demian Lerner, Gregory Maxwell; +Cc: bitcoin-dev I'm highly unconvinced of this point. Sure, you can change fewer lines of code, but if the result is, lets be honest, shit, how do you believe its going to have a higher chance of getting acceptance from the broader community? I think you're over-optimizing in the wrong direction. Matt On 05/09/17 20:58, Sergio Demian Lerner wrote: > I agree with you Matt. > I'm artificially limiting myself to changing the parameters of Segwit as > it is.. > > This is motivated by the idea that a consensual HF in the current state > would have greater chance of acceptance if it changes the minimum number > of lines of code. > > > > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg@xiph•org > <mailto:greg@xiph•org>> wrote: > > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo > <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote: > > at beast. > > Rawr. > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-10 14:05 ` Matt Corallo @ 2017-05-10 15:25 ` Sergio Demian Lerner 2017-05-10 16:39 ` Matt Corallo 0 siblings, 1 reply; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-10 15:25 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1377 bytes --] Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It has always been good enough. And at the beginning it was quite simple. Simple enough it allowed gradual improvements that anyone with some technical background could understand. Now we need a full website to explain an improvement. But this is becoming more and more out of topic. On Wed, May 10, 2017 at 11:05 AM, Matt Corallo <lf-lists@mattcorallo•com> wrote: > I'm highly unconvinced of this point. Sure, you can change fewer lines > of code, but if the result is, lets be honest, shit, how do you believe > its going to have a higher chance of getting acceptance from the broader > community? I think you're over-optimizing in the wrong direction. > > Matt > > On 05/09/17 20:58, Sergio Demian Lerner wrote: > > I agree with you Matt. > > I'm artificially limiting myself to changing the parameters of Segwit as > > it is.. > > > > This is motivated by the idea that a consensual HF in the current state > > would have greater chance of acceptance if it changes the minimum number > > of lines of code. > > > > > > > > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg@xiph•org > > <mailto:greg@xiph•org>> wrote: > > > > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo > > <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> wrote: > > > at beast. > > > > Rawr. > > > > > [-- Attachment #2: Type: text/html, Size: 2229 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-10 15:25 ` Sergio Demian Lerner @ 2017-05-10 16:39 ` Matt Corallo 2017-05-10 19:40 ` Sergio Demian Lerner 0 siblings, 1 reply; 21+ messages in thread From: Matt Corallo @ 2017-05-10 16:39 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev I highly disagree about the "not shit" part. You're advocating for throwing away one of the key features of Segwit, something that is very important for Bitcoin's long-term reliability! If you think doing so is going to somehow help get support in a divided community, I don't understand how - more likely you're only going to make things significantly worse. On May 10, 2017 11:25:27 AM EDT, Sergio Demian Lerner <sergio.d.lerner@gmail•com> wrote: >Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It >has >always been good enough. And at the beginning it was quite simple. >Simple >enough it allowed gradual improvements that anyone with some technical >background could understand. Now we need a full website to explain an >improvement. >But this is becoming more and more out of topic. > > >On Wed, May 10, 2017 at 11:05 AM, Matt Corallo ><lf-lists@mattcorallo•com> >wrote: > >> I'm highly unconvinced of this point. Sure, you can change fewer >lines >> of code, but if the result is, lets be honest, shit, how do you >believe >> its going to have a higher chance of getting acceptance from the >broader >> community? I think you're over-optimizing in the wrong direction. >> >> Matt >> >> On 05/09/17 20:58, Sergio Demian Lerner wrote: >> > I agree with you Matt. >> > I'm artificially limiting myself to changing the parameters of >Segwit as >> > it is.. >> > >> > This is motivated by the idea that a consensual HF in the current >state >> > would have greater chance of acceptance if it changes the minimum >number >> > of lines of code. >> > >> > >> > >> > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg@xiph•org >> > <mailto:greg@xiph•org>> wrote: >> > >> > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo >> > <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> >wrote: >> > > at beast. >> > >> > Rawr. >> > >> > >> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-10 16:39 ` Matt Corallo @ 2017-05-10 19:40 ` Sergio Demian Lerner 0 siblings, 0 replies; 21+ messages in thread From: Sergio Demian Lerner @ 2017-05-10 19:40 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2132 bytes --] I'm not advocating. I'm mediating. This is out of On Wed, May 10, 2017 at 1:39 PM, Matt Corallo <lf-lists@mattcorallo•com> wrote: > I highly disagree about the "not shit" part. You're advocating for > throwing away one of the key features of Segwit, something that is very > important for Bitcoin's long-term reliability! If you think doing so is > going to somehow help get support in a divided community, I don't > understand how - more likely you're only going to make things significantly > worse. > > On May 10, 2017 11:25:27 AM EDT, Sergio Demian Lerner < > sergio.d.lerner@gmail•com> wrote: > >Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It > >has > >always been good enough. And at the beginning it was quite simple. > >Simple > >enough it allowed gradual improvements that anyone with some technical > >background could understand. Now we need a full website to explain an > >improvement. > >But this is becoming more and more out of topic. > > > > > >On Wed, May 10, 2017 at 11:05 AM, Matt Corallo > ><lf-lists@mattcorallo•com> > >wrote: > > > >> I'm highly unconvinced of this point. Sure, you can change fewer > >lines > >> of code, but if the result is, lets be honest, shit, how do you > >believe > >> its going to have a higher chance of getting acceptance from the > >broader > >> community? I think you're over-optimizing in the wrong direction. > >> > >> Matt > >> > >> On 05/09/17 20:58, Sergio Demian Lerner wrote: > >> > I agree with you Matt. > >> > I'm artificially limiting myself to changing the parameters of > >Segwit as > >> > it is.. > >> > > >> > This is motivated by the idea that a consensual HF in the current > >state > >> > would have greater chance of acceptance if it changes the minimum > >number > >> > of lines of code. > >> > > >> > > >> > > >> > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell <greg@xiph•org > >> > <mailto:greg@xiph•org>> wrote: > >> > > >> > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo > >> > <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo•com>> > >wrote: > >> > > at beast. > >> > > >> > Rawr. > >> > > >> > > >> > [-- Attachment #2: Type: text/html, Size: 3332 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Some real-world results about the current Segwit Discount 2017-05-08 22:42 [bitcoin-dev] Some real-world results about the current Segwit Discount Sergio Demian Lerner 2017-05-08 23:47 ` Alphonse Pace @ 2017-05-08 23:56 ` Gregory Maxwell 1 sibling, 0 replies; 21+ messages in thread From: Gregory Maxwell @ 2017-05-08 23:56 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: bitcoin-dev, hello 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.) ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2017-05-10 19:40 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-08 22:42 [bitcoin-dev] Some real-world results about the current Segwit Discount Sergio Demian Lerner 2017-05-08 23:47 ` Alphonse Pace 2017-05-09 13:49 ` Sergio Demian Lerner 2017-05-09 14:33 ` James Hilliard 2017-05-09 15:45 ` Johnson Lau 2017-05-09 16:19 ` Sergio Demian Lerner 2017-05-09 16:27 ` Johnson Lau 2017-05-09 16:27 ` James Hilliard 2017-05-09 18:15 ` Matt Corallo 2017-05-09 18:58 ` Sergio Demian Lerner 2017-05-09 19:15 ` Sergio Demian Lerner 2017-05-09 19:30 ` Gregory Maxwell 2017-05-09 19:42 ` Matt Corallo 2017-05-09 20:13 ` Gregory Maxwell 2017-05-09 20:58 ` Sergio Demian Lerner 2017-05-10 5:37 ` Jorge Timón 2017-05-10 14:05 ` Matt Corallo 2017-05-10 15:25 ` Sergio Demian Lerner 2017-05-10 16:39 ` Matt Corallo 2017-05-10 19:40 ` Sergio Demian Lerner 2017-05-08 23:56 ` Gregory Maxwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox