1 2015-05-22 00:30:15 <jtimon> cfields wumpus https://github.com/bitcoin/bitcoin/pull/6173
  2 2015-05-22 02:19:39 <dd_> hello
  3 2015-05-22 04:32:42 <mjerr> Hey everybody, working my way through BIP32 currently, as I want to use it in my application. I wanted to use it first by giving away one pubkey, such that the other side can know about the addresses, and then at a later part (for payment channels) reveal some of the private keys
  4 2015-05-22 04:32:58 <mjerr> I read now, that this is fundamentally not possible with BIP32
  5 2015-05-22 04:33:22 <mjerr> Just to reassure myself, as I would really like to go down that road, it is not possible, right?
  6 2015-05-22 04:35:14 <mjerr> As giving away any private key would apparently give away the whole tree, and using a hardened pub/priv pair would not allow derivation of addresses.. ?
  7 2015-05-22 04:36:02 <gmaxwell> giving away one private key gives away all it's public derrivation siblings to anyone who could derrive them.   BIP32 also has hardened derrivation which doesn't have this propert, but you cannot have other people generate addresses for you with it.
  8 2015-05-22 04:36:08 <gmaxwell> right.
  9 2015-05-22 04:36:24 <mjerr> Thanks. :)
 10 2015-05-22 04:37:09 <mjerr> you say 'to anyone who could derrive them', thats because no one has done it yet, but as it is mathematically possible, it can be done, right?
 11 2015-05-22 04:37:35 <gmaxwell> It's trivial to do.
 12 2015-05-22 04:37:45 <mjerr> I see
 13 2015-05-22 04:38:36 <gmaxwell> to derrive key a from key b you add value x * G to the pubkey.  To get private key b from key a you just subtract x from the private key.
 14 2015-05-22 04:38:53 <gmaxwell> the same property that makes public derrivation possible guarentees the compromise.
 15 2015-05-22 04:39:10 <gmaxwell> What you're asking for is not possible with ordinary cryptography (discrete log assumption) asymetric crypto; there are special cryptosystems that can do things like that (it's called identity based encryption) but their security is less trusted, less performant, and currently not available in bitcoin.
 16 2015-05-22 04:39:37 <gmaxwell> mjerr: otoh how are you sending the pubkey in the first place? can you just send a nice long list of pubkeys? in that case you're fine.
 17 2015-05-22 04:42:09 <mjerr> Yea that will be probably what I end up now, I don't want to store the private keys one by one though, and rather use the privkey of the chain, once all the childs can be exposed. The problem is though, how do I make sure the clients use the addresses in that chain, at best in the right order aswell
 18 2015-05-22 04:42:22 <mjerr> There is a nice explanation in the lightning paper
 19 2015-05-22 04:43:14 <mjerr> As I get a privkey, I could look up all the keys generated in some range, and delete those private keys from the db, as I have a way to derive them now
 20 2015-05-22 04:44:14 <mjerr> It's mostly about saving storage and traffic, as an attacker could use random keys in a ddos kind of style to bloat my database
 21 2015-05-22 04:45:38 <mjerr> And once there is a breach of contract, such that I must use an exposed private key, I have to go down the chain (where I previously checked that all necessary private keys are in), and brute force till I find that key
 22 2015-05-22 04:47:33 <mjerr> So I obviously dont want everybody using the 10000000. child, unless necessary, but now there isn't a way to enforce this behavior
 23 2015-05-22 04:55:33 <mjerr> Having a pubkey and any address of that chain (hardened), it is not possible to derive any attributes, such as childid, right?
 24 2015-05-22 05:39:10 <jtimon> cfields https://github.com/theuni/bitcoin/pull/27
 25 2015-05-22 05:56:09 <warren> anyone happen to have a tested branch of 0.10.2 plus the pruning patches?
 26 2015-05-22 06:28:41 <wumpus> there's only neglible changes between 0.10.1 and 0.10.2, forward porting a patch shouldn't give any difficulties
 27 2015-05-22 07:28:41 <stanford_drone> Does anyone know C/C++, Computer Vision/Image Processing, Machine Learning, AI, linux systems programming, or electronics? I'm looking for a programmer to join my Startup. We're going to China (manufacturing is there) from July to November. We're a team of 4. We're building a flying computer. A drone that you can play games with and install apps on.
 28 2015-05-22 07:29:54 <gmaxwell> stanford_drone: At stanford do they have classes on internet ethics?  You might want to check in there to learn about sending unsolicited advertisments to communities.
 29 2015-05-22 07:30:00 <wumpus> cool, but not really the place here
 30 2015-05-22 07:30:31 <gmaxwell> (and not really the place in the other channels that was pasted)
 31 2015-05-22 07:32:31 <phantomcircuit> gmaxwell, i wonder if he realizes that his public ip probably traces back to his actual person
 32 2015-05-22 07:32:50 <phantomcircuit> and doing that is probably a violation of the terms under which he uses their network
 33 2015-05-22 07:33:08 <gmaxwell> dunno, lets not compound the offtopicness futher.
 34 2015-05-22 08:44:56 <jonasschnelli> gmaxwell: have you some specification on hardened bip32? Or could you explain me your vision of rotating master keys?
 35 2015-05-22 08:48:38 <y1kes> i'm terrified.  i can no longer tell the difference between obvious trolling and what might actually be reality...
 36 2015-05-22 09:10:41 <wumpus> heh yes "vision of rotating master keys" sounds like something in a dream, or fit of hallucination
 37 2015-05-22 09:11:33 <wumpus> warren: strange, your 0.9.5 gitian build for linux and windows differs from the rest
 38 2015-05-22 09:11:45 <wumpus> warren: osx is ok
 39 2015-05-22 09:16:21 <jonasschnelli> wumpus: yes. "Vision" is probably a poor word coming out of my poor english vocabulary. :) But i really like to understand how key rotation and and Bip32 could work together.
 40 2015-05-22 09:18:46 <wumpus> jonasschnelli: I think it's the right word to use, wasn't meant as a comment, just sounded funny
 41 2015-05-22 12:43:41 <afk11> What would be the best way to compile libbitcoinconsensus as a standalone library? looking at https://github.com/jonasnick/bitcoinconsensus_testcases
 42 2015-05-22 13:39:21 <nickler> afk11: for this project I just ran make and copied libbitcoinconsensus from src/.libs/
 43 2015-05-22 14:09:57 <jonasschnelli> afk11: if you download one of the "official" and signed releases of bitcoin-core (https://bitcoin.org/bin/bitcoin-core-0.10.2/) you will find a libbitcoinconsensus within the tar.gz packages.
 44 2015-05-22 14:22:13 <afk11> jonasschnelli: that worked great, thanks
 45 2015-05-22 14:22:57 <jonasschnelli> afk11: or compile bitcoin-core by yourself directly or over gitian. --with-libs is by default on.
 46 2015-05-22 14:24:58 <afk11> I'll have a look at that also. quite keen on playing with this, cross implementation testing has been on my mind for a while
 47 2015-05-22 14:26:08 <afk11> @nickler: ah I see, thanks! I compile master each evening, will use those..
 48 2015-05-22 14:27:37 <jonasschnelli> afk11: if you want to compare nightly build hashes of your binaries: i also build every night at exact UTC 00:00: https://builds.jonasschnelli.ch/nightlybuilds/
 49 2015-05-22 14:29:14 <afk11> jonasschnelli: I'll keep that in mind. I do 5am, safer to assume I won't be awake then..
 50 2015-05-22 14:32:46 <afk11> nickler: I seem to get a ake
 51 2015-05-22 14:32:56 <afk11> segfault on valid_script
 52 2015-05-22 14:33:32 <jonasschnelli> Ouch! With custom build libbitcoinconsensu or "official"?
 53 2015-05-22 14:33:34 <afk11> ah, other problems cropping up, ignore that..
 54 2015-05-22 14:35:09 <afk11> copied entire contents of the signed bitcoin package /lib/ dir to /usr/lib, and ./include to /usr/include. ldconfig started complaining one of the files was not a symlink, so suspect I haven't done things correctly.
 55 2015-05-22 14:36:46 <nickler> afk11: yeah these programs are just hacks, you probably don't supply an argument to the command :/
 56 2015-05-22 14:44:09 <afk11> nickler: I think it's working now. what are arguments/output options?
 57 2015-05-22 14:47:02 <nickler> PM
 58 2015-05-22 15:00:19 <petertodd> BlueMatt: I just did a test payment to the P2SH redeemScript OP_NOP2, AKA OP_CHECKLOCKTIMEVERIFY, and noticed it was immediately spent. More to the point, bc.i shows one of your nodes as relaying the tx spending it, gw.vpn.bluematt.me (see https://blockchain.info/inv/0dcbbcc3f4791ba2fb4ae778bd42f4f30d598881553f40b181f8430b43028338)
 59 2015-05-22 15:00:58 <petertodd> BlueMatt: would you mind changing your relayer to block the upgradable NOP's? this could potentially pose issues in a soft-fork as a way of transmitting invalid txs
 60 2015-05-22 15:22:16 <StephenM347> Has regtest mode always used difficulty probablility of ~ 1/2 of blocks being valid? For some reason on 0.9.3, block ids all start with 0000.
 61 2015-05-22 15:22:32 <StephenM347> Except for the regtest genesis
 62 2015-05-22 15:26:47 <afk11> will bitcoinconsensus.h contain all the script flags soon? or do the P2SH and DERSIG flags cover the main others?
 63 2015-05-22 15:50:30 <nickler> Although bitcoinconsensus.h mentions only P2SH and DERSIG, actually all script flags are possible.
 64 2015-05-22 16:17:56 <harding> StephenM347: I believe the base difficulty for regtest was decreased from 0.9 to 0.10, but I think it's still the case the regtest retargets difficulty after 150 blocks.
 65 2015-05-22 16:19:00 <sdaftuar> harding: regtest difficulty retarget interval is the same as for mainnet; 150 is the subsidy halving time
 66 2015-05-22 16:19:23 <harding> sdaftuar: oh, right.  Thanks!
 67 2015-05-22 16:22:19 <StephenM347> harding: sdaftuar: http://pastebin.com/SzAQ5U13
 68 2015-05-22 16:22:54 <sdaftuar> StephenM347: that's with 0.9?
 69 2015-05-22 16:23:00 <StephenM347> 0.9.3
 70 2015-05-22 16:23:26 <sdaftuar> if i remember right, the 0.9 code used the cpu miner, which i noticed has some funny property that it only mines blocks with at least 4 leading 0's
 71 2015-05-22 16:23:37 <StephenM347> Not hurting anything, just thought it was strange.
 72 2015-05-22 16:23:44 <StephenM347> sdaftuar: Ah, that makes sense!
 73 2015-05-22 16:24:00 <StephenM347> The hash scanner wouldn't even return less frequently than that
 74 2015-05-22 16:24:01 <sdaftuar> at some point that was changed so that when you mine blocks on testnet, it doesn't hit the mining code, it just is mined in the rpc handler
 75 2015-05-22 16:24:09 <sdaftuar> er s/testnet/regtest
 76 2015-05-22 16:24:20 <sdaftuar> it might have been refactored again since then though, i can't remember
 77 2015-05-22 16:24:24 <StephenM347> mystery solved
 78 2015-05-22 16:28:39 <StephenM347> That means that solving many many blocks in regtest mode is not instant, but no biggy.
 79 2015-05-22 16:30:45 <harding> Ah.  That matches my experience too.  On 0.9.x, creating 101 blocks to get some spendable coins used to take about 45 seconds on my older laptop; now on 0.10/master it goes much faster.
 80 2015-05-22 16:34:58 <afk11> nickler: I guess if it's just wrapping VerifyScript it should be fine. I'm writing a PHP extension for bitcoinconsensus now, was going to use the flags exposed in bitcoinconsensus.h as constants, but I guess I can hardcode them.
 81 2015-05-22 16:36:17 <afk11> I guess that's the beauty of sortforking changes. old clients don't have to know about the new flag
 82 2015-05-22 17:00:39 <BlueMatt> petertodd: which of my nodes???
 83 2015-05-22 17:00:43 <BlueMatt> I dont think any of them should
 84 2015-05-22 17:02:02 <BlueMatt> petertodd: also, bc.i shows it as unconfirmed
 85 2015-05-22 17:03:45 <BlueMatt> petertodd: bc.i now says it was relayed by some eligius node
 86 2015-05-22 17:23:08 <Luke-Jr> um, why was 0.9.5 tagged? :x
 87 2015-05-22 17:24:36 <Luke-Jr> are we skipping the "sufficient testing" nowadays?
 88 2015-05-22 17:31:33 <petertodd> BlueMatt: well, bc.i says 162.243.132.6 relayed that tx, and host 162.243.132.6 -> gw.vpn.bluematt.me.
 89 2015-05-22 17:33:22 <petertodd> BlueMatt: I'm expecting it to be unconfirmed; we've never made a release that'd mine a NOP w/o a patch.
 90 2015-05-22 17:33:40 <BlueMatt> petertodd: ahh, thats not the relay network, thats just one of my nodes...should be running 0.10.2, did 0.10 get the discourage-nops-patch?
 91 2015-05-22 17:34:40 <petertodd> BlueMatt: yup, 0.10.2 has it, just checked
 92 2015-05-22 17:36:28 <BlueMatt> petertodd: well, I'm still waiting on grep to finish with the 321G debug.log
 93 2015-05-22 17:36:36 <BlueMatt> I'll tell you what it says
 94 2015-05-22 17:36:58 <Luke-Jr> wumpus: cfields: It looks like rc2 got *zero* real-world testing before it was tagged as final? There isn't a single listening node (at least that my crawler has seen) and the IRC logs sound like it had just barely attained the minimum builds for binary distributions.. wtf?
 95 2015-05-22 17:36:59 <petertodd> BlueMatt: oh, hang on... I think the discourage bit is off...
 96 2015-05-22 17:37:29 <petertodd> BlueMatt: oh, never mind, my grep foo is weak
 97 2015-05-22 17:37:37 <BlueMatt> ahh, ok
 98 2015-05-22 17:37:39 <cfields> Luke-Jr: rc2 was basically just a determinism test
 99 2015-05-22 17:38:05 <Luke-Jr> cfields: is there evidence rc1 received sufficient real-world testing even?
100 2015-05-22 17:39:43 <cfields> Luke-Jr: afaik the changes are minimal and it had sign-offs from a few people here, but wumpus could speak to that better than me
101 2015-05-22 17:39:46 <Luke-Jr> usually this would mean at least some time passing with >100 (IIRC) downloads
102 2015-05-22 17:40:56 <gmaxwell> Luke-Jr: I bet that'll basically never happen.
103 2015-05-22 17:41:10 <gmaxwell> I don't know why anyone would run that, I wouldn't recommend them to run it.
104 2015-05-22 17:41:13 <Luke-Jr> gmaxwell: which is why a number of past stable versions never left RC
105 2015-05-22 17:42:18 <gmaxwell> The old downloading logic is almost completely dysfunctional. ... I do still think we should have a backport, for whatever crazy person just _wouldn't_ run 0.10.x+ since it should be a strict improvement; but expecting a lot production testing may just be too much.
106 2015-05-22 17:42:34 <gmaxwell> And we do need to get a backport out because of the soft-fork.
107 2015-05-22 17:42:38 <petertodd> Luke-Jr: the only significant changes between v0.9.4 and v0.9.5 are the BIP66 stuff
108 2015-05-22 17:43:47 <Luke-Jr> backport is fine, but we shouldn't pass off things as tested when they're not.
109 2015-05-22 17:45:58 <gmaxwell> Luke-Jr: it's been tested just not with production testing by users because the users who would test more or less do not exist.
110 2015-05-22 17:46:16 <gmaxwell> (or rather not widespread production testing by users)
111 2015-05-22 17:47:00 <Luke-Jr> the latter has always been requried for finals (even when non-existent) and I'm not really sure we should change that
112 2015-05-22 17:47:04 <petertodd> gmaxwell: IOW the users who will test it are big mining pools, in production...
113 2015-05-22 17:48:02 <gmaxwell> Luke-Jr: also, I appricate your concern, but if I were wumpus I'd really hate to come back to find my screen full of "wtf". It would be a little more productive to express them a BIT less sharply. :) (esp because you may find that there is more testing than we know about)
114 2015-05-22 17:48:23 <gmaxwell> petertodd: right, and they won't test a test release. sooo...
115 2015-05-22 17:48:27 <Luke-Jr> gmaxwell: it's "wtf" because I explicitly pointed this out a few days ago.
116 2015-05-22 17:49:17 <Luke-Jr> and there was no discussion I saw in the meantime about if it ought to be changed
117 2015-05-22 17:49:57 <gmaxwell> none that I saw, though I was totally unaware of any download count metric.
118 2015-05-22 17:50:00 <gmaxwell> Luke-Jr: Well did you fix it a few days ago?  I mean-- what do you want? do you really think it's superior to _not_ cut one and have no 0.9.x which is not potentially divergent with the network consensus?
119 2015-05-22 17:51:19 <Luke-Jr> gmaxwell: I think it's superior to publish the rc2 as if it were a final.
120 2015-05-22 17:51:22 <Luke-Jr> (fix what?)
121 2015-05-22 17:51:38 <gmaxwell> Already our very very strong recommendation to everyone is to run 0.10.x. When someone shows up and because of some mess of patches cannot immediately run 0.10.x do we think it's better that they are on 0.9.4 or 0.9.5?   I think the latter is clearly better, because of the known problems in 0.9.4 (esp post BIP66 it will not enforce all the network rules)
122 2015-05-22 17:52:09 <gmaxwell> Luke-Jr: fix the fact that it hadn't had enough testing.
123 2015-05-22 17:52:09 <Luke-Jr> 0.9.5rc2
124 2015-05-22 17:52:26 <gmaxwell> 0.9.5 is 0.9.5rc2, no?
125 2015-05-22 17:52:26 <Luke-Jr> gmaxwell: not much I can do there, I'm just one person :p
126 2015-05-22 17:52:53 <gmaxwell> Luke-Jr: same for anyone else. The fact of the matter is that the only people who should in any way run this are people who will never test anything ever.
127 2015-05-22 17:52:58 <Luke-Jr> gmaxwell: yes, I'm saying we can and should recommend 0.9.5rc2 as better than 0.9.4, at least post-softfork
128 2015-05-22 17:53:40 <gmaxwell> then its just a naming convention, if we're _recommending_ it to people that is 99% of the substance of the naming.
129 2015-05-22 17:54:46 <gmaxwell> what good it it to say "this is bad, it's not adequately tested. but we strongly recommend you run it over 0.9.4". The result will just be random. The purpose of the version naming is to communicate to people what things are and what our recommendations are.
130 2015-05-22 17:55:04 <gmaxwell> We shouldn't be recommending a rcX to the general public, thats what releases are for.
131 2015-05-22 17:55:28 <LeMiner> The general recommendation should be to run the latest final released version.....
132 2015-05-22 17:55:52 <Luke-Jr> gmaxwell: but we're only recommending it over 0.9.4, not recommending it in general
133 2015-05-22 17:55:54 <petertodd> in any case, I did make a point of spinning up a new v0.9.5rc1 node, which is running fine and is in consensus after a few days syncing (mainnet and testnet)
134 2015-05-22 17:56:02 <gmaxwell> As an aside, I think the "someone ran it in production" is a pretty weak test; esp since 99.999% of the purpose of 0.9.5 is for people with masses of patches keeping them from quickly deploying 0.10.
135 2015-05-22 17:56:30 <gmaxwell> Luke-Jr: we're not recommending it in general no matter what we call it. It can barely get in initial sync with the network.
136 2015-05-22 17:56:38 <Luke-Jr> gmaxwell: production use tests diversity of environment, so things like that recent unicode bug
137 2015-05-22 17:57:32 <gmaxwell> Indeed, but stops being much of a useful test if users are applying a pile of patches on it.
138 2015-05-22 17:57:37 <Luke-Jr> gmaxwell: if we're going to change the definition of a final release, ok, but at the very least this should be mentioned in the release notes or something
139 2015-05-22 17:58:43 <gmaxwell> okay, yes, if we're unable to get a normal level of testing on a release we should release note that.
140 2015-05-22 17:58:49 <gmaxwell> I would agree there.
141 2015-05-22 17:59:18 <gmaxwell> I don't think it's a change; rather its just an exception, and releases can have exceptions.  For example, normally you can downgrade. Sometimes you can't and we note that.
142 2015-05-22 18:01:02 <petertodd> Luke-Jr: btw, keep in mind that I asked wumpus to do a v0.9.5 releast specifically because I've been talking (indirectly) to some pools about implementing BIP66, so that BIP65 can be implemented in a reasonable timeframe
143 2015-05-22 18:02:17 <petertodd> Luke-Jr: that recent spike at http://bitcoin.sipa.be/ver-2k.png is related to that
144 2015-05-22 18:12:21 <ajweiss> wumpus:  how about "<localized error message> <english e.what()>"?  that way the error is communicated clearly, but the detail isn't left out (and can be googled)
145 2015-05-22 18:28:39 <jonasschnelli> hmm.. i think there is a bug in CSubNet::Match()
146 2015-05-22 18:29:37 <jonasschnelli> Test: 192.168.0.10 does not match 192.168.0.1/24 (but it should)
147 2015-05-22 18:30:15 <jonasschnelli> Test: whereas 192.168.0.10 match 192.168.0.0/24
148 2015-05-22 18:30:37 <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/netbase.cpp#L1294
149 2015-05-22 18:30:48 <ajweiss> the first is a weird way of writing it, but yes i agree
150 2015-05-22 18:32:15 <gmaxwell> jonasschnelli: yea congrats on running into the same problem I did.
151 2015-05-22 18:32:33 <gmaxwell> (it's discussed in logs here some months ago)
152 2015-05-22 18:34:13 <gmaxwell> jonasschnelli: re earlier question. uhh. Hardened derrivation is described in BIP32.
153 2015-05-22 18:35:04 <jonasschnelli> gmaxwell: :) i try not to modify match so it's CIDR conform. Subnet banning is done (except from this bug)
154 2015-05-22 18:36:08 <jonasschnelli> gmaxwell: hardened derrivation is clear to me. I was thinking you are talking about some other things to harden bip32. But mainly i'm interested on how a keyrotation could be implemented.
155 2015-05-22 18:36:41 <jonasschnelli> i assume the bip32 masterkey stays static. Do you mean rotation of a bip32 master seed encryption key?
156 2015-05-22 18:37:01 <gmaxwell> no!
157 2015-05-22 18:37:07 <gmaxwell> encryption key?
158 2015-05-22 18:37:15 <gmaxwell> that doesn't make sense.
159 2015-05-22 18:37:36 <jonasschnelli> or how would you encrypt a bip32 wallet?
160 2015-05-22 18:37:48 <gmaxwell> jonasschnelli: as far as how I think master keys ought to be handled. The wallet should support having multiple master keys, a current one, and one or more past ones, as well as one or more future ones.  The user should be able to control switching to future ones, by policy or manually.   E.g. a reasonable policy is would be something like switch to the next master it has been three months since the
161 2015-05-22 18:37:54 <gmaxwell> first time it showed up in a backup, and has been backed up at least twice. (e.g. tracking the backup count),  or if the user hits a button that says their key has been compromised it immediately makes them do a backup and rotates.
162 2015-05-22 18:38:52 <gmaxwell> The objective is achieving industry standard cryptographic key management practices-- which hold that keys should be rotated on some regular basis to achieve forward security. E.g. someone copying off your keys in the past should not _forever_ compromise you.
163 2015-05-22 18:39:24 <gmaxwell> (esp since people lose control of old backups;  e.g. I've bought lots of tapes on ebay that had random companies backups on them)
164 2015-05-22 18:39:52 <gmaxwell> but obviously this can't be at the expense of risking integrity of storing the keys.
165 2015-05-22 18:41:13 <jonasschnelli> excuse my basic cryptographic understanding: but if have a bip32 master key, how can i rotate to another bip32 master key without losing the opportunity to spend my coins received over the first key?
166 2015-05-22 18:42:24 <gmaxwell> jonasschnelli: By continuing to remember the old keys.  Same way that generatenewaddress doesn't prevent you from spending past payments to you.
167 2015-05-22 18:43:35 <gmaxwell> (in the existing wallet)
168 2015-05-22 18:45:08 <gmaxwell> jonasschnelli: that making any sense to you?
169 2015-05-22 18:45:15 <jonasschnelli> gmaxwell: but if my master key before rotation is compromised, the attacker can steal at least all fund received over the compromise master-key/subkeys?
170 2015-05-22 18:45:56 <jonasschnelli> *funds
171 2015-05-22 18:46:02 <gmaxwell> Correct. No stopping that. Coin selection should prefer to spend ones on the prior keys after you've rotated. And the "I think I'm compromised" button I mentioned above should perform a sweeping transaction for amounts over some dust threshold.
172 2015-05-22 18:46:43 <jonasschnelli> why over some dust threshold and not all available coins?
173 2015-05-22 18:47:27 <kuzetsa> I think the intent / implication was that if the dust is too dusty there would be more spent in fees than reclaimed by sweeping the dust
174 2015-05-22 18:47:58 <jonasschnelli> kuzetsa: okay. This makes sense.
175 2015-05-22 18:48:05 <gmaxwell> perhaps all. So there are two costs to that sweep: one is the fees you'll pay, the other is the privacy you lose by linking your addresses.  if someone pays you a really tiny amount sweeping it is a let loss, might as well let it get stolen.
176 2015-05-22 18:48:16 <gmaxwell> s/let/net/
177 2015-05-22 18:49:56 <jonasschnelli> okay. I think this would be a good design. Time-triggered (or other rules) generation of new master keys which automatically gets used if you generate new receiving addresses.
178 2015-05-22 18:50:04 <ajweiss> a smaller, and potentially faster to confirm "oh no!" transaction is probably also desirable in this case
179 2015-05-22 18:50:27 <jonasschnelli> gmaxwell: Would it be to dangerous to automatically sweep transactions to your new key?
180 2015-05-22 18:51:11 <gmaxwell> jonasschnelli: I think we should have a "this is compromised"  flag in the wallet that can trigger automatic sweeping. (of amounts greater than some threshold again). Same flag could be used for imported keys normally.
181 2015-05-22 18:51:13 <jonasschnelli> nevermind, it should be a user confirmed or user triggered action
182 2015-05-22 18:52:10 <jonasschnelli> gmaxwell: master key rotation might get a bit complex if there is also multisig cosigning support built into the new wallet.
183 2015-05-22 18:53:59 <gmaxwell> jonasschnelli: I assume that multisig cosigning would be something you'd establish as a top level parameter when you create a wallet (wallet type).   I guess it's somewhat tricky: you could easily have a single rotating master key for a wallet which was "one master multiple cosigners" but the cosigners would need to be public derrivable.
184 2015-05-22 18:54:51 <gmaxwell> E.g. because a cosigner implementing some policy doesn't necessarily care at all what pubkey _you_ happen to be using. They'll just sign anything meeting whatever policy they should be enforcing, and don't need to be able to generate your keys.
185 2015-05-22 18:56:17 <jonasschnelli> gmaxwell: right. But if you implement keyrotation and auto-generation over bip32 pubkey wallets of 2of2 multisig addresses, your wallet needs to get the new pubkey after the cosign-wallet has rotated keys
186 2015-05-22 18:56:48 <jonasschnelli> (but maybe only rotate your main wallet keys)
187 2015-05-22 18:57:43 <jonasschnelli> s/keys/master key
188 2015-05-22 18:59:16 <gmaxwell> jonasschnelli: yea, thats what I was trying to express:  the case where only _one_ side rotates, and the other side never does- is fine.
189 2015-05-22 18:59:36 <gmaxwell> Thats actually _very_ reasonable for many applications.
190 2015-05-22 19:00:59 <jonasschnelli> gmaxwell: Thanks. Now i understand that better. Will try to implement a such behavior.
191 2015-05-22 19:02:10 <jonasschnelli> gmaxwell: another question (just answer if i don't steal your time): I was reading sipas bip32 wallet layout: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#the-default-wallet-layout ...
192 2015-05-22 19:02:34 <jonasschnelli> the external chain is like m/iH/0/k ... why is k no k' (hardened)?
193 2015-05-22 19:03:24 <jonasschnelli> is there any reason to not harden a key for change of receiving funds?
194 2015-05-22 19:04:25 <jonasschnelli> s/k no k'/k not k'
195 2015-05-22 19:04:41 <gmaxwell> The model pieter was thinking about there was that the wallet would be giving out addresses m/iH/0/k  with _i_ incrementing between each getnewaddress.   The idea was that you could give the reciever either an ordinary p2sh address or you could give them an extended pubkey, and they could generate more under that.
196 2015-05-22 19:04:52 <gmaxwell> So you'd only ever use a public derrivation with a single reciever.
197 2015-05-22 19:05:32 <gmaxwell> so, in the case that you weren't giving out extended pubkeys to people, all the addresses you actually used would be k=0.
198 2015-05-22 19:06:18 <gmaxwell> If payments came in with k>0 then you could automatically asscoiate them with the metadata you plugged in when you did that initial get-new-address
199 2015-05-22 19:07:12 <gmaxwell> E.g.  getnewaddress "my_mining_income"  and then you'd get payments marked my_mining_income:0 my_mining_income:1 my_mining_income:3 ...  if you gave the mining pool an extended pubkey.
200 2015-05-22 19:07:33 <jonasschnelli> so somone who send funds to you could decide to pay you without address reuse?
201 2015-05-22 19:07:40 <gmaxwell> Yes.
202 2015-05-22 19:08:37 <jonasschnelli> gmaxwell: would this still be compatible with bip43/44? i assume now, or you just append the iH/0/k?
203 2015-05-22 19:08:46 <gmaxwell> well in particular, you could load an extended public key on your webserver and get   my_webstore_invoice:0  my_webstore_invoice:1 my_webstore_invoice:2
204 2015-05-22 19:08:49 <jonasschnelli> s/now/no
205 2015-05-22 19:09:06 <gmaxwell> no clue. BIP44 was done by people who disagreed with BIP32's usage.
206 2015-05-22 19:09:37 <jonasschnelli> https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
207 2015-05-22 19:10:52 <jonasschnelli> I think whats usable from bip43/44 is the possibility to recover a wallet over master seed in a different wallet-app
208 2015-05-22 19:11:05 <gmaxwell> I think that can't be compatible because it forces you into a specific geometry that has public derrivation.
209 2015-05-22 19:12:02 <gmaxwell> I think recovery in a different wallet app, while a nice thought, is not really realistic (unless you tell the wallet about the specific geometry it needs to search). There is too much functionality gap.  Basically it can only work if you constrain all wallets to exactly the same key management behavior.
210 2015-05-22 19:12:19 <gmaxwell> And that was already out to window when some people insisted on using public derrivation for everything.
211 2015-05-22 19:13:23 <jonasschnelli> Totally agreed. I even think users should not be encouraged to do master-seed mnemonic re-creation/recovering of a wallet.
212 2015-05-22 19:14:43 <jonasschnelli> Because of the nature that you loos valuble metadata and if you had some hundreds addresses used, it can take long and there is a high chance that your (new)app will fail in finding all your key which where used for receiving funds
213 2015-05-22 19:15:05 <jonasschnelli> s/loos/lose
214 2015-05-22 19:16:20 <jonasschnelli> master seed recovering maybe should only be "the last option you have" when all your backups, etc. are gone.
215 2015-05-22 19:17:05 <gmaxwell> Yea, the whole master recovery no backups is really dangerous. I know personally losing my wallet data would potentially leave me exposed to thousands of dollars in tax liabilities.  It's good to support it but in no way does it replace backups.
216 2015-05-22 19:18:54 <akrmn> Hi I recently sketched out a proposal in the development mailing list for scaling Bitcoin with a softfork. Is anyone gonna reply to me or am I talking to myself?
217 2015-05-22 19:19:55 <jonasschnelli> But i think that what users using bip39 are thinking. They write down or remember their Mnemonic words and think they are save from losing any kind of wallet related data.
218 2015-05-22 19:20:52 <gmaxwell> akrmn: did you pay the response fee?
219 2015-05-22 19:21:29 <akrmn> gmaxwell: Is that sarcasm or do I miss some new procedure?
220 2015-05-22 19:23:26 <gmaxwell> akrmn: Your comment above sounded kinda rude, I thought I'd defuse with a joke.  What you posted about before has been described previously (I'd link but BCT is down).  Adam Back likes it, and ignoring software complexity one could argue that its strictly superior to just increasing the blocksize. But it is a functonal reduction to SPV security for anyone who isn't validating the rest, so it retains
221 2015-05-22 19:23:32 <gmaxwell> most of the fundimental centeralization vs scale tradeoff (same reason that sipa apparently told you previously that sidechains are not fundimentally a scalablity tool themselves)
222 2015-05-22 19:24:42 <gmaxwell> (by 'what you posted...has been described' I mean the main notion of an 'extension block', an addtional amount of tx space commited in the normal basic block.)
223 2015-05-22 19:25:15 <akrmn> gmaxwell: Then how do you solve the problem with storage space??
224 2015-05-22 19:25:27 <midnightmagic> buy moar hard drives
225 2015-05-22 19:25:39 <gmaxwell> akrmn: some of the other comments you made really don't make sense in the context about how a modern bitcoin implementation works; the blockchain is not used for validating new transactions in modern implementations.
226 2015-05-22 19:25:43 <akrmn> 10 MB block would make it hard for regular people to keep a long term history of their transactions
227 2015-05-22 19:25:45 <midnightmagic> there are slower-speed 8TB archival drives out now for fairly cheap
228 2015-05-22 19:26:05 <gmaxwell> sorting out a bunch of basic engineering understanding takes time and everyone is _very_ busy right now; (also pieter is on vacation)
229 2015-05-22 19:26:25 <akrmn> yes its ok no rush
230 2015-05-22 19:26:43 <akrmn> just asking here before I bug people more on the mailing list
231 2015-05-22 19:27:02 <akrmn> I never posted before on the list, but this block size increase is making me motivated
232 2015-05-22 19:27:07 <akrmn> (proposal)
233 2015-05-22 19:27:26 <Luke-Jr> is there a proposal yet?
234 2015-05-22 19:28:14 <akrmn> Well it seems like many people want it quite soon, and some say we need to wait, but I am saying we don't need it at all
235 2015-05-22 19:28:18 <phantomcircuit> gmaxwell, without public derivation why not just do something like; k_n = H(n | master_key)
236 2015-05-22 19:28:20 <akrmn> we can just extend with a softfork
237 2015-05-22 19:28:52 <gmaxwell> phantomcircuit: thats what hardened derrivation is, functionally.
238 2015-05-22 19:29:00 <phantomcircuit> oh
239 2015-05-22 19:29:02 <phantomcircuit> well then
240 2015-05-22 19:29:27 <gmaxwell> Luke-Jr: akrmn independantly suggested what was effectively extension blocks on the list.
241 2015-05-22 19:30:02 <gmaxwell> phantomcircuit: it's described with a bit more complexity in BIP32 so that you can implement both it and public with basically identical code.
242 2015-05-22 19:31:21 <HoloIRCUser1> Hi everyone
243 2015-05-22 19:31:22 <phantomcircuit> akrmn, i believe that such a change would break the social contract that is bitcoin
244 2015-05-22 19:31:47 <Luke-Jr> oh
245 2015-05-22 19:32:13 <Luke-Jr> phantomcircuit: ⁉
246 2015-05-22 19:32:23 <ajweiss> i'm starting to realize that the best way to communicate high level ideas in this space is with working code.  the chasm between the theoretical and the implementation with all details handled seems to be especially wide here.
247 2015-05-22 19:32:36 <akrmn> phantomcircuit: I think it's a softfork only that's required. So how is that breaking the contract while a hardfork is not?
248 2015-05-22 19:32:58 <phantomcircuit> Luke-Jr, people have fielded full nodes which they believe to be fully validating the blockchain, a soft fork which contains additional transactions potentially breaks that
249 2015-05-22 19:34:09 <phantomcircuit> akrmn, either way changing the blocksize limit does not provide scaling, increasing the blocksize limit is at best a linear increase in transaction count
250 2015-05-22 19:34:18 <Luke-Jr> phantomcircuit: any soft fork does?
251 2015-05-22 19:34:31 <akrmn> Well you can think of it like this. We are currenly validating the main (top) blockchain. But as an extension, we can validate the off chain transactions in a more elegant manner using this system I proposed.
252 2015-05-22 19:34:51 <phantomcircuit> akrmn, for reference a 20MB block takes about 60 seconds to validate with a cold signature cache on my i7-4700MQ
253 2015-05-22 19:34:55 <gmaxwell> akrmn: softforks can absolutely break the contract. There is a much larger possibility that they don't.
254 2015-05-22 19:35:00 <phantomcircuit> which is substantially faster than most
255 2015-05-22 19:35:09 <Luke-Jr> akrmn: this effectively requires the extension to be a semi-sidechain FYI
256 2015-05-22 19:35:16 <gmaxwell> akrmn: "All transactions must also be signed by the US DHS" would also be a softfork.
257 2015-05-22 19:35:38 <phantomcircuit> akrmn, a hard fork absolutely breaks the contract, but it does so in a way that is plainly obviously doing that
258 2015-05-22 19:35:44 <gmaxwell> Luke-Jr: akrmn: can you move to #bitcoin-wizards (also, luke if you haven't read his post you should)
259 2015-05-22 19:35:48 <phantomcircuit> a soft fork is potentially worse in that way
260 2015-05-22 19:36:22 <akrmn> Ya I am on that channel too. I'm not so good at arguing though, but I'll try :)
261 2015-05-22 19:54:36 <kuzetsa> gmaxwell: was there a particular reason for the comment: "All transactions must also be signed by the US DHS" <<< like is that hyperbole, or was someone really asking for such things O_O
262 2015-05-22 19:55:12 <kuzetsa> sadly, I can never tell when stuff like that might just seem like a tounge-in-cheek joke :(
263 2015-05-22 19:55:52 <gmaxwell> kuzetsa: it was hyperbole though someone who was president of some bitcoin assc in .. uh. someplace in europe told me that they were were telling their local officials that all bitcoin users could register their addresses with the state (and so any measure that discourages address reuse would be bad for their interests).  ...
264 2015-05-22 19:56:00 <Luke-Jr> kuzetsa: he didn't say anyone was asking for it; it's just an example of a clear softfork violating social contract
265 2015-05-22 20:01:35 <petertodd> gmaxwell, kuzetsa: I've had multiple discussions with regulatory types that were along the lines of "we're going after exchanges now, but it's obvious that in a few more years the regulations will extend to the blockchain itself" - e.g. registered addresses
266 2015-05-22 20:01:54 <kanzure> gmaxwell: they seriously thought that address reuse was the only way to track addresses?
267 2015-05-22 20:02:48 <kanzure> petertodd: i've been hearing some rumors about the treasury department wanting address registration, but nothing specific. if you know someone there maybe you should send them a proposal before they pick something that will break everything.
268 2015-05-22 20:02:58 <gmaxwell> kanzure: and were so clueless about bitcoin to not realize how throughly that would break .. .e.g tracking which invoices have actually been paid. Yes.
269 2015-05-22 20:03:10 <kanzure> hmph
270 2015-05-22 20:03:51 <petertodd> kanzure: one of these people was from the treasury department...
271 2015-05-22 20:04:17 <petertodd> gmaxwell: they know about HD now :/
272 2015-05-22 20:05:47 <gmaxwell> Considering what the courts have done with laws that attempt to require ID in the US, I am not too concerned in the US; other places... well.
273 2015-05-22 20:07:00 <Luke-Jr> petertodd: eh, I don't see a problem with governments asking their citizens to register watch-only HD seeds with them, provided they keep it private and don't inflict anything on miners or internationally
274 2015-05-22 20:07:13 <Luke-Jr> might make taxes easier if the IRS just starts sending me a bill :p
275 2015-05-22 20:07:37 <kanzure> Luke-Jr: er, are you interested in hearing about the problems that causes?
276 2015-05-22 20:07:46 <Luke-Jr> sure, but let's go to #bitcoin for this
277 2015-05-22 22:06:21 <Shibe_> Hello
278 2015-05-22 22:06:49 <Shibe_> Hello?
279 2015-05-22 22:07:53 <Shibe_> Hello
280 2015-05-22 22:08:49 <TheMatrixShibe> Hello
281 2015-05-22 22:28:50 <benhamel> French tooltip transtation of sync progress bar is not exactly right. We read : "Les transactions après cela ne seront pas encore visibles." Correct way to say "Transaction after that are not yet visible" is : "Les transactions après cela ne sont pas encore visibles."