1 2015-12-23 01:05:22 <btcdrak> Capacity increase FAQ https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
 2 2015-12-23 01:59:56 <brg444> to be clear, how much capacity increase does a node that does not upgrade to SW gets?
 3 2015-12-23 02:16:38 <instagibbs> brg444, their effective feerate will stay the same, all else held equal
 4 2015-12-23 02:16:49 <instagibbs> SW transactions get "discount"
 5 2015-12-23 02:18:35 <brg444> mmm I guess my question is how much regular transactions can fit in a block? FAQ says about 1.6 right?
 6 2015-12-23 02:18:43 <brg444> mb
 7 2015-12-23 02:21:16 <brg444> nvm
 8 2015-12-23 02:21:20 <brg444> got it
 9 2015-12-23 02:21:26 <brg444> thx
10 2015-12-23 02:22:14 <instagibbs> all "regular" would be 1mb still
11 2015-12-23 02:22:15 <instagibbs> yeah
12 2015-12-23 02:22:27 <instagibbs> stuffing the signatures elsewhere gives discount
13 2015-12-23 02:25:16 <brg444> right
14 2015-12-23 03:30:02 <maaku> instagibbs: actually from their perspective SW transactions pay a premium
15 2015-12-23 03:30:29 <maaku> (from the perspective of a non-upgraded node that doesn't see the witness)
16 2015-12-23 12:08:24 <Quent> hey
17 2015-12-23 12:09:15 <Quent> I'm wondering what you guys think of this approach: http://www.bitcoinunlimited.info/software - that is taking the blocksize limit out of the consensus layer to the messaging layer
18 2015-12-23 12:44:39 <Luke-Jr> Quent: it's insanity
19 2015-12-23 12:45:21 <Luke-Jr> Quent: in part because it is *necessarily* a consensus rule. failure to enforce it just leads to lack of consensus.
20 2015-12-23 12:45:45 <haakonn> as i heard someone say: "let them find out on their own"
21 2015-12-23 12:45:50 <Luke-Jr> if the limit is implemented in the "messaging layer", that just means the messaging layer is now part of the consensus rules
22 2015-12-23 12:52:13 <Quent> Luke-Jr, wouldn't a consensus naturally form by individual nodes choosing the blocksize themselves though?
23 2015-12-23 12:52:57 <Quent> anyway, I'll recommend they post about it to the mailing list so that it can properly be discussed I guess...
24 2015-12-23 12:53:40 <Luke-Jr> Quent: only if they all chose the same size..
25 2015-12-23 12:55:51 <Quent> the implementation is somewhat complex I think in allowing consensus to form through buffers as in + or -5mb is acceptable from 8mb or whatever, but maybe I asked prematurely as I am not sure if there is any full proper documentation yet so as I said I'll ask them to provide the details in the mailing list so that it can be properly discussed
26 2015-12-23 16:21:52 <jtimon> Quent: Luke-Jr a consensus on the block size isn't strictly necessary, it could be a local policy restriction only. But then it wouldn't have any effect on limiting mining centralization (or full node centralization)
27 2015-12-23 16:22:33 <jtimon> disclaimer: I haven't read the paper
28 2015-12-23 16:29:43 <Quent> I don't think the paper is out yet jtimon
29 2015-12-23 16:42:55 <jtimon> I mean, I didn't read the link, just the conversation here
30 2015-12-23 19:43:14 <Eliel_> Luke-Jr: there's no need for block size consensus for old blocks, only new blocks. Perhaps it'd be possible to make the block size limit soft in that it only applies to blocks that don't have X continuation blocks yet. That'd allow increasing the size without completely breaking old nodes.
31 2015-12-23 19:54:43 <Prattler> what's the ETA for jgarzik's "BIP-draft: BIP 102 variant w/ small steps" getting a BIP number?
32 2015-12-23 20:29:29 <Quent> Prattler, isn't that BIP as good as dead with the recent proclamation?
33 2015-12-23 20:29:48 <Prattler> Quent, what proclamation?
34 2015-12-23 20:30:05 <Quent> not sure why wumpus is even keeping it open to be honest, you can't sign "the road map" on one hand and keep that bip open on the other :)
35 2015-12-23 20:30:31 <Prattler> ah right right...
36 2015-12-23 20:31:14 <brg444> What's wrong with the BIP again?
37 2015-12-23 21:19:17 <warren> There's nothing wrong with assigning BIP numbers.  It's better than folks choosing their own numbers.