1 2016-08-06 01:48:34 0|GitHub6|[13bitcoin] 15Christewart opened pull request #8469: [POC] Introducing property based testing to Core (06master...06rapidcheck) 02https://github.com/bitcoin/bitcoin/pull/8469
2 2016-08-06 03:08:49 0|jeremyrubin|How do I use travis without pushing to my PR?
3 2016-08-06 03:09:19 0|jeremyrubin|I'd like to confirm what I think is causing some build fails without having to push
4 2016-08-06 03:09:36 0|jeremyrubin|testing locally is a bit mroe difficult
5 2016-08-06 03:36:34 0|jeremyrubin|ah i guess I hadn't looked at the pull_tester before... should be resolved.
6 2016-08-06 03:42:44 0|sipa|jeremyrubin: you can't run the tests locally?
7 2016-08-06 04:07:27 0|sonlin|Thoughts on implementing the dev subsidy feature?
8 2016-08-06 04:07:51 0|sipa|what feature?
9 2016-08-06 04:08:30 0|sonlin|It takes for example 20% of block reward and fees and distributes it to devs.
10 2016-08-06 04:09:13 0|sonlin|The exact % can be changed.
11 2016-08-06 04:09:23 0|sipa|why would anyone accept that?
12 2016-08-06 04:10:03 0|sipa|especially with the current developers not asking for such a thing
13 2016-08-06 04:10:06 0|sonlin|It seems like a good way to distribute coins instead of just pow as it is currently.
14 2016-08-06 04:10:29 0|sipa|it requires a centralized development team
15 2016-08-06 04:10:38 0|sipa|whose identity is hardcoded in the protocol
16 2016-08-06 04:10:54 0|sonlin|Right now there is no direct reward for developing.
17 2016-08-06 04:11:08 0|sipa|it seems to work fine without
18 2016-08-06 04:11:12 0|sonlin|Once there is then there will be competition between developers to do things better.
19 2016-08-06 04:11:15 0|gmaxwell|the reward is that we get to argue with ignorant people on the internet.
20 2016-08-06 04:11:47 0|sipa|sonlin: no, there would be an incentive for developers to start pumping the price and do marketing
21 2016-08-06 04:11:54 0|sonlin|Dsd in my opinion could fix a lot of this politics bs in the dev space.
22 2016-08-06 04:12:14 0|sipa|security and features don't drive the price... empty promises do
23 2016-08-06 04:12:31 0|gmaxwell|sonlin: by having protocol hardcoded developers... you think that would fix a lot of politics?
24 2016-08-06 04:13:05 0|kanzure|also see other weird problems with transaction fees from wallets and wallet developers
25 2016-08-06 04:13:06 0|sonlin|Developers wouldn't necessarily be hard coded.
26 2016-08-06 04:13:16 0|sonlin|And it's funny you brought that up.
27 2016-08-06 04:13:19 0|sipa|sonlin: then who has the right to update the list of developers?
28 2016-08-06 04:13:34 0|sipa|who get the subsidy?
29 2016-08-06 04:13:34 0|sonlin|Because right now it's almost like devs are hardcoded in.
30 2016-08-06 04:13:52 0|sipa|what?
31 2016-08-06 04:13:55 0|sonlin|There is such a closed off community of devs.
32 2016-08-06 04:14:00 0|sonlin|That pushes some other devs away.
33 2016-08-06 04:14:20 0|sipa|how would your proposal fix that?
34 2016-08-06 04:14:29 0|sipa|who gets to decide which developers get the money?
35 2016-08-06 04:15:00 0|sonlin|Bitcoin holders and a combination of other methods.
36 2016-08-06 04:15:12 0|sipa|how do bitcoin holders decide?
37 2016-08-06 04:15:14 0|sonlin|Dsd is still being developed.
38 2016-08-06 04:15:21 0|sipa|what is Dsd?
39 2016-08-06 04:15:37 0|sonlin|Developer subsidy distribution
40 2016-08-06 04:15:45 0|kanzure|how do you evaluate whether the community is closed off? have you tried to write code?
41 2016-08-06 04:16:10 0|sipa|there have been altcoins that tried this model
42 2016-08-06 04:16:15 0|sonlin|I currently have a team of developers writing the code.
43 2016-08-06 04:16:21 0|sipa|it doesn't seem to work
44 2016-08-06 04:16:36 0|sipa|in any case, off topic for this channel
45 2016-08-06 04:16:38 0|kanzure|and what payments did you make to join this irc channel? it doesn't seem particularly closed to me..
46 2016-08-06 04:16:41 0|kanzure|ok fine
47 2016-08-06 04:16:43 0|sonlin|I just want bitcoin to progress.
48 2016-08-06 04:17:14 0|sonlin|That's why I'm going to implement this.
49 2016-08-06 04:17:15 0|kanzure|i think that a developer subsidy might be possible, but it will need a better idea, because existing implementations of your idea have shown the model to be fairly broken
50 2016-08-06 04:17:19 0|sipa|you can do so without introducing a point of centralization
51 2016-08-06 04:17:19 0|sonlin|It will be hard to get this implemented though.
52 2016-08-06 04:17:26 0|sonlin|Because I'm fairly sure no miners will allow this.
53 2016-08-06 04:17:52 0|sipa|i think it's a terrible idea... speaking as someone who would possibly be at the receiving end of your idea :)
54 2016-08-06 04:18:42 0|sipa|and we all want bitcoin to progress, but i don't think you do that by radically changing its economics
55 2016-08-06 04:19:12 0|sonlin|Ok 20% might be to high
56 2016-08-06 04:19:17 0|sonlin|But let's say 5% gos towards dsd
57 2016-08-06 04:19:25 0|sipa|even if it was 0.001%
58 2016-08-06 04:19:35 0|sonlin|That's $50k a day at current price that gos towards development.
59 2016-08-06 04:19:37 0|sipa|i think it's fundamentally a perversion of incentives
60 2016-08-06 04:19:46 0|kanzure|the funny thing is that altcoins should probably hard-code their developer subsidies to pay bitcoin developers, so that the bitcoin developers continue to work, since altcoins benefit mainly from that development activity, and that subsidy doesn't interfere with the bitcoin protocol definition. however, iirc, developers in the past have said they would not touch any of those subsidy payments anyway.
61 2016-08-06 04:21:00 0|sipa|feel free to discuss the idea once you have worked out the exact mechanism on the mailing list
62 2016-08-06 04:21:04 0|kanzure|(e.g. they wouldn't touch any of it on principle and because perversion of incentive reasons and because having someone decide where the payments go is itself contentious and difficult to solve)
63 2016-08-06 04:21:09 0|sipa|but i expect most developers to dislike it
64 2016-08-06 04:21:33 0|sipa|before you even know how users get to decide the distribution there is not much to talk about
65 2016-08-06 04:22:21 0|sonlin|I'm not the one actually developing it that's why.
66 2016-08-06 04:22:23 0|kanzure|sipa: what about altcoins distributing payments to bitcoin developers as part of their protocol definitions?
67 2016-08-06 04:22:40 0|kanzure|ok anyway off-topic i guess
68 2016-08-06 04:23:00 0|sipa|kanzure: now you give bitcoin developers an incentive to go pump those altcoins :p
69 2016-08-06 04:23:04 0|sipa|please, don't give them idea
70 2016-08-06 04:23:04 0|sonlin|But i was told by the developers that are making dsd that basically all bitcoin devs would switch over at once.
71 2016-08-06 04:23:16 0|sonlin|It's to good to pass up.
72 2016-08-06 04:23:22 0|sipa|sonlin: i believe you're misinformed
73 2016-08-06 04:23:44 0|sipa|also, bitcoin developers don't set the rules
74 2016-08-06 04:24:02 0|kanzure|"all developers would switch over at once" would only make sense if developers were doing development for payment (and most of them are unpaid, which seems to indicate otherwise)
75 2016-08-06 04:24:02 0|sonlin|I know that's the thing.
76 2016-08-06 04:24:04 0|sipa|if bitcoin core were to introduce such a rule, i hope the community would refuse to run it
77 2016-08-06 04:24:21 0|luke-jr|kanzure: sipa: Devcoin already did that.
78 2016-08-06 04:24:44 0|sipa|right, devcoin
79 2016-08-06 04:25:13 0|sonlin|It's human nature, developers will not refuse this subsidy.
80 2016-08-06 04:25:22 0|luke-jr|sonlin: Devcoin seems pretty dead.
81 2016-08-06 04:25:36 0|kanzure|sonlin: it seems pretty easy to me to refuse a subsidy.
82 2016-08-06 04:25:54 0|sipa|sonlin: as a developer, i believe it would strongly undermine trust in bitcoin as an independent decentralized currency
83 2016-08-06 04:26:01 0|sipa|sonlin: as such, i would oppose it
84 2016-08-06 04:26:05 0|sipa|even if it would pay me
85 2016-08-06 04:26:07 0|sonlin|That's because devcoin was an irelevent alt
86 2016-08-06 04:26:42 0|sonlin|It would put an end to development stagnation
87 2016-08-06 04:26:52 0|sipa|what?
88 2016-08-06 04:26:59 0|sipa|development is going faster than ever
89 2016-08-06 04:27:28 0|sonlin|There is to much time wasted with politics
90 2016-08-06 04:27:53 0|sipa|and you think adding more money to the equation would reduce politics? :o
91 2016-08-06 04:27:53 0|sonlin|Once there is financial incentive things will start to inovate and speed up.
92 2016-08-06 04:27:57 0|kanzure|they seem to be writing code instead of doing politics. this is increasingly off-topic. i think you should move to another channel to discuss this.
93 2016-08-06 04:28:07 0|sipa|sonlin: i think you're totally wrong
94 2016-08-06 04:28:38 0|sipa|sonlin: people were trying to innovate long before bitcoin had any value. increased value brought economic interest in influencing development with all associated politics
95 2016-08-06 04:30:06 0|sipa|anyway, this is getting far off topic
96 2016-08-06 04:30:14 0|sipa|this channel is about development of bitcoin core
97 2016-08-06 04:30:29 0|sipa|i doubt many people involved with bitcoin core development are interested in this
98 2016-08-06 04:31:47 0|sonlin|We shall see
99 2016-08-06 04:39:53 0|midnightmagic|\o/
100 2016-08-06 06:27:57 0|GitHub43|[13bitcoin] 15luke-jr opened pull request #8471: Key origin metadata, with HD wallet support (06master...06keyorigin_hd) 02https://github.com/bitcoin/bitcoin/pull/8471
101 2016-08-06 09:02:31 0|GitHub160|[13bitcoin] 15paveljanik opened pull request #8472: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK (06master...0620160806_Wshadow_LOCK) 02https://github.com/bitcoin/bitcoin/pull/8472
102 2016-08-06 15:03:55 0|jonasschnelli|gmaxwell: sipa: I guess the current bip151 rekeying has no forward secrecy. It's hash(old-sym-key). What about hkdf(ecdh_secret, old_syn_key) instead?
103 2016-08-06 15:05:15 0|jonasschnelli|S/old_syn_key/old_sym_key
104 2016-08-06 18:14:15 0|GitHub87|[13bitcoin] 15clickkarog opened pull request #8473: 0 9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/8473
105 2016-08-06 18:16:15 0|GitHub185|[13bitcoin] 15jonasschnelli closed pull request #8473: 0 9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/8473
106 2016-08-06 18:24:13 0|GitHub83|[13bitcoin] 15clickkarog opened pull request #8474: 0 9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/8474
107 2016-08-06 18:30:23 0|GitHub74|[13bitcoin] 15clickkarog opened pull request #8475: 0 10 (06master...060.10) 02https://github.com/bitcoin/bitcoin/pull/8475
108 2016-08-06 18:33:37 0|GitHub107|[13bitcoin] 15sipa closed pull request #8475: 0 10 (06master...060.10) 02https://github.com/bitcoin/bitcoin/pull/8475
109 2016-08-06 18:34:12 0|GitHub58|[13bitcoin] 15sipa closed pull request #8474: 0 9 (06master...060.9) 02https://github.com/bitcoin/bitcoin/pull/8474
110 2016-08-06 18:34:35 0|gmaxwell|jonasschnelli: it is forward secure. Forward secure means an attacker which later gets access to the hosts and has a transcript of the communication cannot decode the transcript. The hashing is distructive, it cannot be reversed.
111 2016-08-06 18:35:01 0|gmaxwell|And it is fast so it can be frequently done, narrowing the window of compromise to pratically nothing.
112 2016-08-06 18:40:20 0|gmaxwell|jonasschnelli: what you're suggesting would provide what SP800-90A calls prediction resistance. Which means that if an attacker gets a full read-only snapshot of your memory at some point, his ability to continue decoding the transcript at some point will stop.
113 2016-08-06 18:43:57 0|gmaxwell|Which isn't worthless-- but at what cost? with the added aggregate computational cost of that, I'd rather have initial key agreement which is secure against ECC breaks (E.g. quantum computers). simply because the attack model where an attacker can extract your session keys but for some reason can't just extract them again after you rekey, doesn't seem very interesting.
114 2016-08-06 18:48:43 0|GitHub79|[13bitcoin] 15MarcoFalke closed pull request #8253: [TEST] [Travis] Remove hostname workaround (06master...06remove-travis-workaround) 02https://github.com/bitcoin/bitcoin/pull/8253
115 2016-08-06 18:50:50 0|jonasschnelli|gmaxwell: IMO the problem with the current BIP rekey design is, if an attacker could manage to steal one symmetric key, he can also decrypt/tamper after a rekey.
116 2016-08-06 18:51:31 0|jonasschnelli|Maybe instead of hash(oldkey) we could just use hmac(oldkey, hash(ECDH-secret))
117 2016-08-06 18:51:59 0|jonasschnelli|(Where the second parameter is the HMAC key)
118 2016-08-06 18:52:42 0|jonasschnelli|The cost of a HMAC instead of a SHA should be minimal
119 2016-08-06 18:53:00 0|sipa|if he can steal the symmetric key, why would he not be able to steal the ecdh secret?
120 2016-08-06 18:53:38 0|jonasschnelli|If the symmetric cipher is broken and he can do a known plaintext attack or something...
121 2016-08-06 18:54:02 0|jonasschnelli|Not sure... But I think the cost/benefits of HMAC over hash for a rekey is worth doing it.
122 2016-08-06 18:55:36 0|gmaxwell|hmac doesn't change anything here.
123 2016-08-06 18:56:10 0|gmaxwell|jonasschnelli: if he can do then the the cipher is totally busted, esp as the keying state is larger than is used in any given block, but sure the rekey could include the session ID.
124 2016-08-06 18:59:29 0|jonasschnelli|gmaxwell: wouldn't HMAC(oldkey, key=session_id or ecdh-secret) be considered more robust then just hash(oldkey)?
125 2016-08-06 19:00:00 0|jonasschnelli|But right, we should use the session-Id instead of hash(ecdh) secret.
126 2016-08-06 19:00:14 0|jonasschnelli|The session id was HKDF derived.
127 2016-08-06 19:00:27 0|gmaxwell|you must not keep around ecdh-secret, or backtracking resistance (forward secrecy) is diminished.
128 2016-08-06 19:01:18 0|jonasschnelli|Okay. So then HMAC with the session id as key?
129 2016-08-06 19:01:38 0|gmaxwell|HMAC vs using a hash is irrelevant in this place. Having the session id in there is fine.
130 2016-08-06 19:02:49 0|jonasschnelli|Okay. hash(oldkey | sessionid)?
131 2016-08-06 19:03:49 0|gmaxwell|sessionid first would be more natural.
132 2016-08-06 19:09:36 0|jonasschnelli|gmaxwell: is there no security advantage using HMAC(oldkey, sessionID) over hash(sessionID || oldkey)?
133 2016-08-06 19:11:24 0|sipa|jonasschnelli: no, hmac only protects against length extension attacks
134 2016-08-06 19:11:36 0|sipa|jonasschnelli: which don't apply if the input data to the hash is constant size
135 2016-08-06 19:11:49 0|jonasschnelli|Ok
136 2016-08-06 20:52:44 0|GitHub1|[13bitcoin] 15MarcoFalke opened pull request #8477: [qa] Temporarily disable ipv6 in rpcbind test (06master...06Mf1608-qaIpv6) 02https://github.com/bitcoin/bitcoin/pull/8477