< jeremyrubin>
How do I use travis without pushing to my PR?
< jeremyrubin>
I'd like to confirm what I think is causing some build fails without having to push
< jeremyrubin>
testing locally is a bit mroe difficult
< jeremyrubin>
ah i guess I hadn't looked at the pull_tester before... should be resolved.
< sipa>
jeremyrubin: you can't run the tests locally?
< sonlin>
Thoughts on implementing the dev subsidy feature?
< sipa>
what feature?
< sonlin>
It takes for example 20% of block reward and fees and distributes it to devs.
< sonlin>
The exact % can be changed.
< sipa>
why would anyone accept that?
< sipa>
especially with the current developers not asking for such a thing
< sonlin>
It seems like a good way to distribute coins instead of just pow as it is currently.
< sipa>
it requires a centralized development team
< sipa>
whose identity is hardcoded in the protocol
< sonlin>
Right now there is no direct reward for developing.
< sipa>
it seems to work fine without
< sonlin>
Once there is then there will be competition between developers to do things better.
< gmaxwell>
the reward is that we get to argue with ignorant people on the internet.
< sipa>
sonlin: no, there would be an incentive for developers to start pumping the price and do marketing
< sonlin>
Dsd in my opinion could fix a lot of this politics bs in the dev space.
< sipa>
security and features don't drive the price... empty promises do
< gmaxwell>
sonlin: by having protocol hardcoded developers... you think that would fix a lot of politics?
< kanzure>
also see other weird problems with transaction fees from wallets and wallet developers
< sonlin>
Developers wouldn't necessarily be hard coded.
< sonlin>
And it's funny you brought that up.
< sipa>
sonlin: then who has the right to update the list of developers?
< sipa>
who get the subsidy?
< sonlin>
Because right now it's almost like devs are hardcoded in.
< sipa>
what?
< sonlin>
There is such a closed off community of devs.
< sonlin>
That pushes some other devs away.
< sipa>
how would your proposal fix that?
< sipa>
who gets to decide which developers get the money?
< sonlin>
Bitcoin holders and a combination of other methods.
< sipa>
how do bitcoin holders decide?
< sonlin>
Dsd is still being developed.
< sipa>
what is Dsd?
< sonlin>
Developer subsidy distribution
< kanzure>
how do you evaluate whether the community is closed off? have you tried to write code?
< sipa>
there have been altcoins that tried this model
< sonlin>
I currently have a team of developers writing the code.
< sipa>
it doesn't seem to work
< sipa>
in any case, off topic for this channel
< kanzure>
and what payments did you make to join this irc channel? it doesn't seem particularly closed to me..
< kanzure>
ok fine
< sonlin>
I just want bitcoin to progress.
< sonlin>
That's why I'm going to implement this.
< 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
< sipa>
you can do so without introducing a point of centralization
< sonlin>
It will be hard to get this implemented though.
< sonlin>
Because I'm fairly sure no miners will allow this.
< sipa>
i think it's a terrible idea... speaking as someone who would possibly be at the receiving end of your idea :)
< sipa>
and we all want bitcoin to progress, but i don't think you do that by radically changing its economics
< sonlin>
Ok 20% might be to high
< sonlin>
But let's say 5% gos towards dsd
< sipa>
even if it was 0.001%
< sonlin>
That's $50k a day at current price that gos towards development.
< sipa>
i think it's fundamentally a perversion of incentives
< 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.
< sipa>
feel free to discuss the idea once you have worked out the exact mechanism on the mailing list
< 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)
< sipa>
but i expect most developers to dislike it
< sipa>
before you even know how users get to decide the distribution there is not much to talk about
< sonlin>
I'm not the one actually developing it that's why.
< kanzure>
sipa: what about altcoins distributing payments to bitcoin developers as part of their protocol definitions?
< kanzure>
ok anyway off-topic i guess
< sipa>
kanzure: now you give bitcoin developers an incentive to go pump those altcoins :p
< sipa>
please, don't give them idea
< sonlin>
But i was told by the developers that are making dsd that basically all bitcoin devs would switch over at once.
< sonlin>
It's to good to pass up.
< sipa>
sonlin: i believe you're misinformed
< sipa>
also, bitcoin developers don't set the rules
< sonlin>
I know that's the thing.
< 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)
< sipa>
if bitcoin core were to introduce such a rule, i hope the community would refuse to run it
< luke-jr>
kanzure: sipa: Devcoin already did that.
< sipa>
right, devcoin
< sonlin>
It's human nature, developers will not refuse this subsidy.
< luke-jr>
sonlin: Devcoin seems pretty dead.
< kanzure>
sonlin: it seems pretty easy to me to refuse a subsidy.
< sipa>
sonlin: as a developer, i believe it would strongly undermine trust in bitcoin as an independent decentralized currency
< sipa>
sonlin: as such, i would oppose it
< sipa>
even if it would pay me
< sonlin>
That's because devcoin was an irelevent alt
< sonlin>
It would put an end to development stagnation
< sipa>
what?
< sipa>
development is going faster than ever
< sonlin>
There is to much time wasted with politics
< sipa>
and you think adding more money to the equation would reduce politics? :o
< sonlin>
Once there is financial incentive things will start to inovate and speed up.
< 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.
< sipa>
sonlin: i think you're totally wrong
< 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
< sipa>
anyway, this is getting far off topic
< sipa>
this channel is about development of bitcoin core
< sipa>
i doubt many people involved with bitcoin core development are interested in this
< GitHub160>
[bitcoin] paveljanik opened pull request #8472: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK (master...20160806_Wshadow_LOCK) https://github.com/bitcoin/bitcoin/pull/8472
< 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?
< 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.
< gmaxwell>
And it is fast so it can be frequently done, narrowing the window of compromise to pratically nothing.
< 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.
< 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.
< 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.
< jonasschnelli>
Maybe instead of hash(oldkey) we could just use hmac(oldkey, hash(ECDH-secret))
< jonasschnelli>
(Where the second parameter is the HMAC key)
< jonasschnelli>
The cost of a HMAC instead of a SHA should be minimal
< sipa>
if he can steal the symmetric key, why would he not be able to steal the ecdh secret?
< jonasschnelli>
If the symmetric cipher is broken and he can do a known plaintext attack or something...
< jonasschnelli>
Not sure... But I think the cost/benefits of HMAC over hash for a rekey is worth doing it.
< gmaxwell>
hmac doesn't change anything here.
< 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.
< jonasschnelli>
gmaxwell: wouldn't HMAC(oldkey, key=session_id or ecdh-secret) be considered more robust then just hash(oldkey)?
< jonasschnelli>
But right, we should use the session-Id instead of hash(ecdh) secret.
< jonasschnelli>
The session id was HKDF derived.
< gmaxwell>
you must not keep around ecdh-secret, or backtracking resistance (forward secrecy) is diminished.
< jonasschnelli>
Okay. So then HMAC with the session id as key?
< gmaxwell>
HMAC vs using a hash is irrelevant in this place. Having the session id in there is fine.
< jonasschnelli>
Okay. hash(oldkey | sessionid)?
< gmaxwell>
sessionid first would be more natural.
< jonasschnelli>
gmaxwell: is there no security advantage using HMAC(oldkey, sessionID) over hash(sessionID || oldkey)?
< sipa>
jonasschnelli: no, hmac only protects against length extension attacks
< sipa>
jonasschnelli: which don't apply if the input data to the hash is constant size