1 2016-05-18 00:47:26	0|petertodd|luke-jr: but that's unrelated to the opt-in rbf detection; I agree that in general we want to display doublespends
 2 2016-05-18 00:48:00	0|luke-jr|petertodd: well, I mean if we're displaying "replacable" as an indication
 3 2016-05-18 00:50:46	0|petertodd|luke-jr: right, but I'm only talking about incoming txs
 4 2016-05-18 01:30:33	0|GitHub150|[13bitcoin] 15theuni opened pull request #8067: travis: use slim generic image, and some fixups (06master...06travis-generic-image) 02https://github.com/bitcoin/bitcoin/pull/8067
 5 2016-05-18 01:49:21	0|GitHub3|[13bitcoin] 15TheBlueMatt opened pull request #8068: Compact Blocks (06master...06udp) 02https://github.com/bitcoin/bitcoin/pull/8068
 6 2016-05-18 04:17:40	0|BlueMatt|sipa/gmaxwell
 7 2016-05-18 04:17:55	0|BlueMatt|so I was just going back and checking, and the new varint stuff doesnt help anywhere that matters
 8 2016-05-18 04:19:50	0|BlueMatt|its an extra few kb in getblocktxn, but thats not really critical-path since that is still one-per-block-per-node
 9 2016-05-18 04:20:37	0|BlueMatt|its only like 10 or 20 bytes in cmpctblock, which is the all-important potentially-multiple-times-per-block
10 2016-05-18 04:22:30	0|BlueMatt|gmaxwell: since you're the one with no b/w at home, how much would you care if there is an extra few kb (if even that) in getblocktxn?
11 2016-05-18 04:22:40	0|BlueMatt|somehow I had thought it was a savings in cmpctblock
12 2016-05-18 04:24:04	0|sipa|i'm fine with sticking to the existing varint scheme
13 2016-05-18 04:24:12	0|luke-jr|"one" <.<
14 2016-05-18 04:24:33	0|luke-jr|BlueMatt: How is blocktxn not part of the critical path?
15 2016-05-18 06:00:03	0|BlueMatt|luke-jr: I said getblocktxn
16 2016-05-18 06:00:18	0|BlueMatt|luke-jr: meh, do you care about an extra few kb once per block?
17 2016-05-18 06:00:26	0|luke-jr|right, but that's before blocktxn
18 2016-05-18 06:00:33	0|BlueMatt|indeed?
19 2016-05-18 06:00:41	0|luke-jr|I don't know if it matters; it may not.
20 2016-05-18 06:02:01	0|BlueMatt|it'll be an extra packet or two
21 2016-05-18 06:02:17	0|BlueMatt|and it doesnt effect udp stuff
22 2016-05-18 06:43:26	0|jonasschnelli|luke-jr, petertodd: would you silently ignore (list as normal) incoming RBF txes?
23 2016-05-18 06:43:59	0|luke-jr|jonasschnelli: sure. they are no different in any practical sense than any other incoming txs
24 2016-05-18 06:44:18	0|jonasschnelli|except that they can be replaced.. :)
25 2016-05-18 06:44:29	0|luke-jr|all unconfirmed txs can be replaced.
26 2016-05-18 06:44:40	0|jonasschnelli|Sure. But they don't signal it explicit.
27 2016-05-18 06:44:45	0|luke-jr|irrelevant.
28 2016-05-18 06:45:09	0|jonasschnelli|So why do we have RBF then?
29 2016-05-18 06:45:13	0|luke-jr|because politics
30 2016-05-18 06:45:20	0|luke-jr|if you mean BIP 125
31 2016-05-18 06:45:28	0|luke-jr|RBF in general is just common sense really
32 2016-05-18 06:46:21	0|luke-jr|double spending was always easy for the criminal uses. RBF makes it practical for legitimate users too.
33 2016-05-18 06:46:40	0|luke-jr|BIP 125 is necessary to get around anti-RBF trolls.
34 2016-05-18 06:48:21	0|jonasschnelli|I don't care about politics and trolls. All I care is about a mempool rule that was written down in a Bip (125) and if a tx matches that bip rule (nSequence), it should be visible somewhere (can also be in the tx details once you doubleclick a tx).
35 2016-05-18 06:49:58	0|luke-jr|I don't care if you have the unenforcable nSequence stuff in the tx debug info window you get by double clicking it. I just don't think it should be presented to end users and relevant.
36 2016-05-18 06:50:16	0|luke-jr|mempool policy is not a rule, and is a per-node decision
37 2016-05-18 06:50:38	0|jonasschnelli|I kinda agree. 0-conf should be listed a 0-conf... maybe a slightly different icon (but same color attributes)?
38 2016-05-18 06:51:10	0|luke-jr|there are plenty of nodes and even some miners who do RBF ignoring BIP 125 signalling, and that's not a problem.
39 2016-05-18 06:51:27	0|luke-jr|there's no such thing as 0-conf, it's unconfirmed ;)
40 2016-05-18 06:51:50	0|luke-jr|unconfirmed should of course be presented differently from confirmed, but AFAIK we already do that
41 2016-05-18 06:52:07	0|jonasschnelli|luke-jr: requesting BIP number assignment for Peer-to-Peer Communication Encryption (https://github.com/bitcoin/bips/pull/362/files) (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012599.html)
42 2016-05-18 06:52:24	0|luke-jr|jonasschnelli: just encryption? or auth too?
43 2016-05-18 06:52:26	0|jonasschnelli|Number assignment for "Authentication" is not required at this point.
44 2016-05-18 06:52:34	0|jonasschnelli|(needs further discussion)
45 2016-05-18 06:53:03	0|luke-jr|k, 151 for encryption
46 2016-05-18 06:53:13	0|jonasschnelli|Super. Thanks!
47 2016-05-18 06:53:26	0|luke-jr|I guess split the PR up so 151 can be merged alone..?
48 2016-05-18 06:54:44	0|jonasschnelli|Yes. I'll remove the auth BIP from the PR and update the enc bip
49 2016-05-18 07:38:30	0|gmaxwell|BlueMatt: I'm sad to continue propagating the old varints in the protocol into more places. They're gratitiously inefficient for no reason... but I don't think the difference between the two really makes a meaningful bandwidth difference in this case.
50 2016-05-18 07:39:03	0|gmaxwell|(the differential encoding otoh makes a huge difference)
51 2016-05-18 07:40:19	0|sipa|gmaxwell: git btw uses little-endian varints, we use big endian ones
52 2016-05-18 07:44:36	0|gmaxwell|BlueMatt: I believe use of the bitcoin one will never cause a increase in packet count, even in the worst case with a 2MB sw block.
53 2016-05-18 07:45:17	0|BlueMatt|gmaxwell: it could with cmpctblock :p
54 2016-05-18 07:46:00	0|gmaxwell|yes, there it could. but not in getblocktxn
55 2016-05-18 07:46:34	0|gmaxwell|consider to get the 3 byte CompactSize, you'd need to have deltas of 254 or more. Well if you have 4000 btc, you can only have 15 such deltas.
56 2016-05-18 07:46:54	0|gmaxwell|s/btc/txn/
57 2016-05-18 07:48:05	0|BlueMatt|those extra few bytes...you never know :p
58 2016-05-18 07:48:30	0|gmaxwell|Well in any case if we cared the fact that small ranges take a whole byte is the real problem. :)
59 2016-05-18 07:48:42	0|gmaxwell|but I wasn't going to suggest you include a range coder.
60 2016-05-18 07:50:04	0|gmaxwell|Though someday when we do a compactblk v2 that uses set reconcil. we'd need a range coder to efficiently encode the transaction ordering...
61 2016-05-18 07:53:05	0|gmaxwell|BlueMatt: in any case, make whatever change you need to make so that I never again hear someone arguing that it should use "UTF-8".
62 2016-05-18 07:53:53	0|BlueMatt|..........
63 2016-05-18 07:53:54	0|BlueMatt|"I wasn't going to suggest"....you keep saying this...........
64 2016-05-18 07:54:33	0|BlueMatt|i mean i dont really give a shit about people making statements that are highly disconnected from reality...just that after having implemented it, I'm not sure its worth the protocol-complexity
65 2016-05-18 07:56:39	0|gmaxwell|BlueMatt: yea, yank it out. I agree.
66 2016-05-18 08:02:29	0|gmaxwell|https://people.xiph.org/~greg/temp/perm.tar.gz   permutation encoder that I started writing using the range coder from the daala video codec (which is a fast and efficient multiply free range coder with a nice API), which gets within about 0.5% of information thoretic efficiency. (e.g. it takes 1074 bytes to encode a permutation for 1000 elements).
67 2016-05-18 08:08:31	0|gmaxwell|BlueMatt: the spec should say what happens if you send non-canonical CompactSize encodings.
68 2016-05-18 08:16:50	0|BlueMatt|gmaxwell: i will point out that undefined behavior may eat cats, including non-canonical CompactSize :)