1 2014-04-16 00:00:02 <gmaxwell> melvster: so show me where x509 client certs are in chrome. :P
  2 2014-04-16 00:00:14 <vetch> GAit: wait. you said the 2FA requests show the user what they are agreeing to. how does that work with Google Authenticator?
  3 2014-04-16 00:00:30 <gmaxwell> melvster: and regardless, the browsers _own_ facilties are not the same thing as JS apps running on top of them.
  4 2014-04-16 00:00:42 <GAit> vetch: it doesn't with GA. but GA is the only one that can be offline and really anonymous
  5 2014-04-16 00:00:50 <sipa> GAit: appreciate it that you listened :)
  6 2014-04-16 00:01:07 <GAit> gmaxwell: you are right, we don't and we should.
  7 2014-04-16 00:01:31 <sipa> GAit: independently, i like the idea of usimg multisig for securimg tramsactions
  8 2014-04-16 00:01:36 <vetch> GAit: I think it's the one most users will choose, I don't imagine most people would give up their SMS address. in that model it's definitely easy for a compromise of the CRX to end up draining a users wallet, right?
  9 2014-04-16 00:01:52 <vetch> GAit: in line with sipa, I like that you're willing to discuss this.
 10 2014-04-16 00:02:01 <melvster> gmaxwell: somewhere in the security tab, you can import a cert of generate one with the <KEYGEN> tag, I use x.509 client certs *constantly* I've probably used them 100+ times in chrome today alone for auth ... sadly there's not ECDSA sepc256ka support yet tho
 11 2014-04-16 00:02:24 <melvster> k1
 12 2014-04-16 00:02:45 <GAit> vetch: i was thinking a while back to add a 2fa based on pgp
 13 2014-04-16 00:02:51 <GAit> with tx info signed by the server
 14 2014-04-16 00:03:13 <GAit> but boy is it a hard core / advanced  feature not for inexperienced users
 15 2014-04-16 00:03:19 <gmaxwell> melvster: ah it didn't used to, I actually had to remove client cert auth from a site because of chrome a couple years ago. I'm glad they've fixed that.
 16 2014-04-16 00:03:36 <vetch> GAit: is anything in Bitcoin easy to explain to users?
 17 2014-04-16 00:03:37 <melvster> yeah took a while!
 18 2014-04-16 00:03:42 <melvster> faster than mozilla at least
 19 2014-04-16 00:04:08 <GAit> vetch: no .. anyway i'm hoping with a hardware wallet most of these issues will disappear
 20 2014-04-16 00:04:29 <GAit> we're looking to integrate with two so far
 21 2014-04-16 00:04:41 <vetch> trezor and what else?
 22 2014-04-16 00:04:50 <vetch> if you can disclose that.
 23 2014-04-16 00:05:15 <GAit> no i can't, it may get announced before or at the conference
 24 2014-04-16 00:05:40 <vetch> understandable
 25 2014-04-16 00:05:43 <GAit> for all i know they may not get around the final stages or may be ready for mass production, no idea
 26 2014-04-16 00:06:20 <melvster> they'll do it ... i got 16 trezors on order ...
 27 2014-04-16 00:06:36 <melvster> i live in the same town as the trezor team
 28 2014-04-16 00:06:47 <GAit> trezor is cool. i had no idea it was this small
 29 2014-04-16 00:06:59 <GAit> oh really?
 30 2014-04-16 00:07:05 <Apocalyptic> melvster, did you see a prototype ?
 31 2014-04-16 00:07:21 <GAit> man i wish i could go around slush lab and have a beer with the boys :)
 32 2014-04-16 00:07:21 <vetch> GAit: I can pitch my idea for a hardware wallet to you if you want. it's basically like the trezor set in an enormous clear acrylic cube with a solid lead centre. so big and heavy that stealing it becomes completely ridiculous.
 33 2014-04-16 00:07:35 <melvster> yeah I saw mike's review ... looks great ... I used to be in the same co working space as them, before they got the office, used to chat a lot, trezor will be awesome, trust me
 34 2014-04-16 00:08:01 <melvster> and they run the hacker space too
 35 2014-04-16 00:08:10 <GAit> i used to love the one in london
 36 2014-04-16 00:08:22 <GAit> very cool atmosphere
 37 2014-04-16 00:08:38 <vetch> thankfully there's not much to the trezor's hardware. they should be cheap and plentiful.
 38 2014-04-16 00:08:39 <GAit> account registration without human contact, all bank account and then NFC tag to open the door
 39 2014-04-16 00:09:36 <GAit> vetch: what is the use of a such a hardware wallet? data center?
 40 2014-04-16 00:09:59 <WOODMAN> http://bitcoinmacroeconomics.com/2014/04/13/hard-lesson-i-want-to-share-with-others-wallet-qt-encryption/
 41 2014-04-16 00:10:05 <vetch> GAit: nah, it's something you keep in your house. nobody can steal what they can't get through the door.
 42 2014-04-16 00:10:07 <WOODMAN> help!
 43 2014-04-16 00:10:32 <shesek> I saw a trezor about a week ago
 44 2014-04-16 00:10:35 <GAit> can't i get it to sign away the funds
 45 2014-04-16 00:10:43 <shesek> they sent a few out to beta testers
 46 2014-04-16 00:10:57 <shesek> I didn't get to play much with it though :\
 47 2014-04-16 00:11:11 <GAit> from mikes review i saw that you can pick the mnemonic length
 48 2014-04-16 00:11:31 <GAit> i would love a definitive answer as to what we should default for users (and not even offer choice)
 49 2014-04-16 00:11:55 <melvster> just count up the entroyp
 50 2014-04-16 00:11:57 <vetch> GAit: nah, it'd have a passcode.. or something. I haven't put thought into that bit. I liked someone's idea for a separate project; making it radioactive so that nobody would want to hang around trying to crack it. might be a hard sell though.
 51 2014-04-16 00:12:45 <shesek> yeah, I don't think the entropy should be user configurable either
 52 2014-04-16 00:12:54 <GAit> melvster: that's the point, 12 words or 24 words. Mike always says 12 words in the videos, electrum is 12 words, trezor offers options, we went for 24 (but we should be able to move easily)
 53 2014-04-16 00:13:34 <GAit> 128 vs 256
 54 2014-04-16 00:14:33 <melvster> 128  bits seems plenty
 55 2014-04-16 00:14:41 <vetch> GAit: don't bitcoin keys have an effective security of 128bits anyway?
 56 2014-04-16 00:15:19 <GAit> so maybe the standard should be changed to not support 256 for mnemonics?
 57 2014-04-16 00:15:31 <sipa> my reason for recommending 256 in bip32 is because i don't understand well enough how the ecdlp's 1/2 bits security factor interacts with key entropy
 58 2014-04-16 00:15:58 <sipa> ie, i'm not comvinced thr resulting security is min(ec algorithm,key entropy)... it may be less
 59 2014-04-16 00:16:11 <GAit> i certainly can't claim I do
 60 2014-04-16 00:16:14 <vetch> sort of related related, a service called "carbon wallet" implemented bip32 as a web wallet. rather than use the randomly chosen words, people decided to use their own. because the words weren't in the bip32 dictionary the javascript returned false, so people used wallets like 0,0,0,0,0,0,0,0,0,0,0,0. whoops.
 61 2014-04-16 00:16:43 <GAit> oh, wallet sharing
 62 2014-04-16 00:17:22 <vetch> accidental wallet sharing, or just very weak seeds that were mostly null
 63 2014-04-16 00:17:47 <GAit> sipa we still have to document them but we have some alpha api exposed (the same used by the clients), fancy reviewing them?
 64 2014-04-16 00:18:37 <melvster> GAit: any views on warp wallet? http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/
 65 2014-04-16 00:18:40 <gmaxwell> vetch: damnit, give me a forehead impact warning before telling me about things like that; reeling from the concussion.
 66 2014-04-16 00:19:07 <GAit> gmaxwell: :)
 67 2014-04-16 00:20:19 <sipa> GAit: no time now
 68 2014-04-16 00:20:59 <vetch> melvster: when the price was around $1200 I considered that the last "challenge" was actually profitable. the scrypt implementation they use is portable to an FPGA, and the PBKDF2 is so weak that it's hardly even a factor.
 69 2014-04-16 00:22:09 <GAit> melvster: does it reuse addresses?
 70 2014-04-16 00:22:15 <gmaxwell> melvster: I am disappointed with that design, ignoring the whole space being very dangerous, its lame in a couple of silly ways, like it's not securely delegatable.
 71 2014-04-16 00:22:19 <vetch> GAit: yes, it's just more brain wallet stuff.
 72 2014-04-16 00:22:23 <gmaxwell> and doesnt encode a wallet, just a single key.
 73 2014-04-16 00:22:48 <melvster> ah interesting, i have been thru all the details yet
 74 2014-04-16 00:23:15 <vetch> if the price gets above $1500 it might actually be worthwhile cracking the last warp wallet challenge.
 75 2014-04-16 00:23:29 <gmaxwell> also the lack of delegatability and use in JS means they had to pick fairly weak strenghtening.
 76 2014-04-16 00:23:49 <vetch> gmaxwell: well, the PBKDF2 is pretty much instant on any CPU out there.
 77 2014-04-16 00:24:11 <gmaxwell> yea, its much less than even bitcoin-qt uses for it regular password kdf... much less a brainwallet.
 78 2014-04-16 00:24:51 <vetch> the scrypt they chose sadly isn't very FPGA sensible
 79 2014-04-16 00:25:42 <GAit> gmaxwell: are you self employed?
 80 2014-04-16 00:25:58 <vetch> I worked it out when they originally announced it, but fitting a quarter of a megabyte of memory on chip probably isn't easy
 81 2014-04-16 00:25:59 <coingenuity> GAit: that's kind of a random question
 82 2014-04-16 00:26:17 <stqism> coingenuity: Have you ever pet a sheep?
 83 2014-04-16 00:26:34 <coingenuity> stqism: probably
 84 2014-04-16 00:26:42 <GAit> coingenuity: true, is it a bad question?
 85 2014-04-16 00:26:43 <sipa> stqism: if the moon is green, do you prefer apples over sunlight?
 86 2014-04-16 00:26:59 <coingenuity> its just a bit out of the blue
 87 2014-04-16 00:27:05 <stqism> sipa: On weekends during spring, otherwise I'm more of a pear guy
 88 2014-04-16 00:27:15 <sipa> thx
 89 2014-04-16 00:28:55 <GAit> and the other thing i was wondering is whether should all businesses even outside the states register with the bitcoin-foundation
 90 2014-04-16 00:29:30 <stqism> GAit: No one should have any need to register with them
 91 2014-04-16 00:30:56 <sipa> if they want to, they can
 92 2014-04-16 00:31:04 <sipa> if they don't, they don't
 93 2014-04-16 00:32:09 <GAit> all i can say is that i can see many if not all of the btc services i know there registered and that we haven't done it yet and i'm evaluating it
 94 2014-04-16 00:32:13 <vetch> basically to crack that Warp Wallet challenge you'd need to do ~80k attempts a second for the next year and a half to have a 50% chance of cracking it.
 95 2014-04-16 00:32:59 <sipa> what does one attempt entail?
 96 2014-04-16 00:33:17 <vetch> scrypt(key=(passphrase||0x1), salt=(salt||0x1), N=218, r=8, p=1, dkLen=32)
 97 2014-04-16 00:33:20 <vetch> pbkdf2(key=(passphrase||0x2), salt=(salt||0x2), c=216, dkLen=32, prf=HMAC_SHA256)
 98 2014-04-16 00:33:27 <sipa> ok
 99 2014-04-16 00:33:36 <vetch> then XOR the results, ECDSA, compare with a given key
100 2014-04-16 00:46:29 <gmaxwell> s/ECDSA/multiple with the generator/
101 2014-04-16 05:13:23 <warren> wumpus: https://bitcointalk.org/index.php?topic=571414.0  anything you want changed before I post this to the dev list?
102 2014-04-16 06:22:45 <wumpus> warren: ok great
103 2014-04-16 06:23:13 <wumpus> so it's working, congratulations :)
104 2014-04-16 06:23:34 <warren> wumpus: if someone (not me) automates gitian on the same tags then they can be verified and you don't need to trust the nightly builds
105 2014-04-16 06:25:06 <wumpus> that's nice about deterministic builds
106 2014-04-16 06:51:49 <wumpus> is the script/system that you use to automate the gitian builds open source?
107 2014-04-16 06:52:55 <wumpus> (well, it's probably a crontab script that launches gbuild, gsign and does an upload, or is there more involved?)
108 2014-04-16 07:16:40 <wumpus> I could run a second build server that only validates the nightly builds
109 2014-04-16 07:28:13 <warren> wumpus: that would be great
110 2014-04-16 07:28:30 <warren> wumpus: it's a shell script run from cron
111 2014-04-16 07:30:52 <warren> wumpus: regarding https://github.com/bitcoin/bitcoin/pull/4049#issuecomment-40568703
112 2014-04-16 07:31:36 <warren> wumpus: can you reproduce the exact git repo where you saw that failure, then show me the output of git rev-list -1 $(git describe --abbrev=0)?
113 2014-04-16 07:33:38 <wumpus> what I did is `git fetch wtogami`, then `git checkout wtogami/prerelease`, then the usual autogen configure and make stuff
114 2014-04-16 07:35:01 <warren> wumpus: ok, I'd like to learn if your git output is different from me
115 2014-04-16 07:35:05 <wumpus> seems that there is some bash gotcha going on, shell scripting is so brittle
116 2014-04-16 07:35:43 <wumpus> that command gives me: d6e0e171ab2ca23be33b440d7c007d360de29c48
117 2014-04-16 07:36:05 <warren> git rev-parse HEAD ?
118 2014-04-16 07:36:19 <wumpus> db60debb4a637194cee1b7231921de808bbd8fb7
119 2014-04-16 07:37:51 <warren> I wonder if this is a difference between dash and bash
120 2014-04-16 07:38:12 <warren> i'm trying dash locally
121 2014-04-16 07:39:41 <warren> wumpus: yup, it's a dash behavior issue
122 2014-04-16 07:39:52 <wumpus> ok
123 2014-04-16 07:40:02 <warren> investigating
124 2014-04-16 07:41:19 <wumpus> the statement *looks* like valid bash scripting to me, then again, bash code is very brittle, almost as easy to introduce gotchas and unexpected behavior as PHP
125 2014-04-16 07:42:12 <wumpus> that's why I want to port all the tests in qa/rpc-tests to python instead
126 2014-04-16 07:42:29 <wumpus> but for the build I suppose relying on python wouldn't be nice
127 2014-04-16 07:44:06 <wumpus> ... it even keeps happening if I first assign left and right to A and B, then leave  if [ "$A" == "$B" ]; then
128 2014-04-16 07:44:26 <warren> I'm reading dash docs
129 2014-04-16 07:44:33 <warren> https://wiki.ubuntu.com/DashAsBinSh
130 2014-04-16 07:45:44 <wumpus> replacing the == by = fixes it ...
131 2014-04-16 07:46:01 <wumpus> well at least: it removes the error, haven't tested functionality
132 2014-04-16 07:46:25 <wumpus> but according to my bash guide both is valid
133 2014-04-16 07:46:49 <warren> ugly
134 2014-04-16 07:46:59 <warren> "The [ command (a.k.a. test) must be used carefully in portable scripts. A very common pitfall is to use the == operator, which is a bashism; use = instead."
135 2014-04-16 07:47:09 <wumpus> shell script is always ugly, let's make it the goal to make it work
136 2014-04-16 07:47:23 <warren> by changing it to #!/bin/bash
137 2014-04-16 07:47:49 <warren> ok, should I repush with = instead of ==?
138 2014-04-16 07:48:01 <wumpus>  either solution is fine with me
139 2014-04-16 07:48:30 <warren> I suppose = is more portable than bash
140 2014-04-16 07:54:30 <warren> fixing a bug then sending you the nightly builder script
141 2014-04-16 07:54:38 <warren> I'll open source it after it's matured a bit more
142 2014-04-16 07:55:01 <wumpus> okay
143 2014-04-16 08:07:53 <elichai2> ./bitcoin-qt: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ./bitcoin-qt)
144 2014-04-16 08:09:14 <wumpus> elichai2: try the builds in https://github.com/bitcoin/bitcoin/pull/4042
145 2014-04-16 08:10:06 <elichai2> any idea?
146 2014-04-16 08:10:16 <elichai2> debian wheezy, bitcoin-qt 0.9.1
147 2014-04-16 08:10:44 <wumpus> elichai2: try the builds in https://github.com/bitcoin/bitcoin/pull/4042
148 2014-04-16 08:12:02 <petertodd> Updated my old replace-by-fee patch w/ preferential peering. Works pretty well - even with less than a half-dozen nodes it would find replace-by-fee peers: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1
149 2014-04-16 08:12:38 <Luke-Jr> petertodd: does it do CPFP yet?
150 2014-04-16 08:13:00 <petertodd> Luke-Jr: not yet - wanted to keep it simple enough to be a quick decentralized response to bitundo
151 2014-04-16 08:14:22 <petertodd> CPFP will take some time to get implemented anyway, so it's not terribly useful immediately
152 2014-04-16 08:14:44 <Luke-Jr> CPFP is already implemented. So it's a regression to not support it :P
153 2014-04-16 08:15:24 <petertodd> Luke-Jr: lol, well, actually the patch should be compatible with your CPFP patch
154 2014-04-16 08:47:25 <elichai2> wumpus: i tried that, but it's version 0.9.99.0
155 2014-04-16 08:51:03 <warren> wumpus: see, the version is confusing =P
156 2014-04-16 09:14:38 <splitting> anyone here work with the python rpc api?
157 2014-04-16 09:15:13 <splitting> for some reason getbalance() returns nothing
158 2014-04-16 09:27:28 <wumpus> elichai2: yes, that's because it is version 0.9.99
159 2014-04-16 09:27:42 <wumpus> warren: no, it's not confusing, it signals exactly what it should
160 2014-04-16 09:28:02 <warren> elichai2: just test it, it contains the proposed fix for the issue you were complaining about
161 2014-04-16 09:28:02 <wumpus> elichai2: it would be possible to do a 0.9.1-with-that-patch build though
162 2014-04-16 09:28:05 <elichai2> wumpus: and it's equal to 0.9.1
163 2014-04-16 09:28:16 <elichai2> ok, it's still rescanning
164 2014-04-16 09:31:33 <wumpus> elichai2: it's ok for testing, I wouldn't recommend using 0.9.99 in production, if you plan on using it for production it would be better to do a 0.9.1 with just that patch
165 2014-04-16 09:32:13 <warren> wumpus: the users who need the binary aren't capable of building it
166 2014-04-16 09:32:14 <wumpus> if you can wait, we will do a 0.9.2 release some time next month that will include it
167 2014-04-16 09:32:27 <elichai2> A fatal error occured. Bitcoin can no longer continue safley and will quit. EXCEPTION: 13leveldb_error Database curropted bitcoin in Runaway exception
168 2014-04-16 09:32:40 <wumpus> warren: I know that
169 2014-04-16 09:32:48 <warren> uh..
170 2014-04-16 09:33:16 <warren> elichai2: what version were you running before?
171 2014-04-16 09:34:30 <wumpus> elichai2: can you pastebin the end of debug.log?
172 2014-04-16 09:35:14 <elichai2> 0.9.0
173 2014-04-16 09:35:18 <elichai2> (compiled by myself)
174 2014-04-16 09:35:37 <warren> wumpus: would it be helpful if I commited the gitian.sigs for these nightly builds?  it's a separate repo already: https://github.com/nightlybitcoin/gitian.sigs
175 2014-04-16 09:36:27 <wumpus> warren: could be useful; in principle it doesn't matter how you make them available, as long as people can check them, but a git repo is easy to stay in sync with
176 2014-04-16 09:37:18 <warren> ok adding that
177 2014-04-16 09:39:53 <elichai2> warren: http://pastebin.com/R2mJtqR3
178 2014-04-16 09:39:56 <elichai2> wumpus:
179 2014-04-16 09:41:06 <warren> elichai2: did you run out of disk space?
180 2014-04-16 09:41:27 <warren> elichai2: (write a big file in that directory to check)
181 2014-04-16 09:42:34 <wumpus> "2014-04-16 09:31:15 Corruption: truncated block read" ... sounds like one of the block files is corrupted
182 2014-04-16 09:42:36 <elichai2> no
183 2014-04-16 09:42:42 <warren> oh
184 2014-04-16 09:42:48 <elichai2> my blockchain are in a seperate partition
185 2014-04-16 09:42:56 <elichai2> tha has 18GB free
186 2014-04-16 09:43:33 <wumpus> did it happen at the same block both times?
187 2014-04-16 09:43:50 <elichai2> http://pastebin.com/4mrrYiEk
188 2014-04-16 09:43:55 <elichai2> idk
189 2014-04-16 09:45:02 <warren> wumpus: https://github.com/nightlybitcoin/gitian.sigs  auto-commit now working
190 2014-04-16 09:47:32 <wumpus> warren: when building #4049, the version appearing as: v0.9.99.0-cab7988-beta . Is this correct?
191 2014-04-16 09:47:56 <warren> wumpus: yes
192 2014-04-16 09:48:17 <elichai2> wumpus: so?
193 2014-04-16 09:48:20 <warren> wumpus: the count since the tag and g prefix are not useful anymore given it isn't a git identifier
194 2014-04-16 09:48:21 <sipa> can someone summarize the new rule for version names?
195 2014-04-16 09:48:54 <wumpus> warren: ah.. I understand why, I merged your pull as a pull request locally, instead of just checking out your branch, hence the different git id
196 2014-04-16 09:49:38 <warren> sipa: it gets version from configure.ac, adds git short hash and maybe dirty
197 2014-04-16 09:49:46 <wumpus> sipa: <version>-<gitid>[-dirty], unless the head commit has a tag, then that tag is added instead of the git id
198 2014-04-16 09:49:48 <warren> sipa: unless the latest commit is tagged, then it uses that instead
199 2014-04-16 09:50:03 <sipa> and something about branches?
200 2014-04-16 09:50:08 <warren> nothing about branches
201 2014-04-16 09:50:20 <elichai2> wumpus: :(
202 2014-04-16 09:50:33 <sipa> ok, i must have misread
203 2014-04-16 09:50:54 <wumpus> elichai2: I have a hard time believing that this is caused by the 0.9.99 upgrade
204 2014-04-16 09:51:07 <wumpus> elichai2: maybe your block files were already corrupted and the rescan made this visible
205 2014-04-16 09:51:24 <elichai2> :(
206 2014-04-16 09:51:29 <sipa> elichai2: didn't you previously have bad ram problems?
207 2014-04-16 09:51:30 <elichai2> so to reindex them?
208 2014-04-16 09:51:46 <elichai2> i did got that error before upgrading...
209 2014-04-16 09:53:50 <elichai2> so i must -reindex?
210 2014-04-16 09:54:07 <wumpus> yes
211 2014-04-16 09:54:15 <elichai2> it is possible that my RAM got correptued because of bitcoin
212 2014-04-16 09:54:30 <elichai2> i can reindex by bootstrap, right?
213 2014-04-16 09:56:20 <wumpus> well there are two options, either remove the block data and re-bootstrap, or just -reindex with the current block data (it will just use that part up to the corruption/missing blocks)
214 2014-04-16 09:56:59 <wumpus> ...the first option sounds slightly more predictable
215 2014-04-16 09:57:46 <elichai2> ohh -reindex just will reverify the blockchain from hard disk?
216 2014-04-16 09:57:51 <wumpus> yes
217 2014-04-16 09:57:52 <sipa> yes
218 2014-04-16 09:58:01 <elichai2> so, it's better, right?
219 2014-04-16 09:58:12 <sipa> how do you mean?
220 2014-04-16 09:58:18 <wumpus> ... better in what way?
221 2014-04-16 09:58:23 <elichai2> better than bootstrap
222 2014-04-16 09:58:27 <wumpus> why?
223 2014-04-16 09:58:31 <wumpus> bootstrap = 100% sure
224 2014-04-16 09:58:43 <sipa> it's exactly the same as bootstrap
225 2014-04-16 09:58:46 <elichai2> yeah but bootstrap is more slow
226 2014-04-16 09:58:55 <sipa> no, it's exactly thr same
227 2014-04-16 09:58:57 <elichai2> becuase it's compressed...
228 2014-04-16 09:59:04 <sipa> it is not compressed in any way
229 2014-04-16 09:59:19 <elichai2> really?
230 2014-04-16 09:59:22 <sipa> yes
231 2014-04-16 09:59:33 <sipa> block data is pretty hard to compress
232 2014-04-16 09:59:43 <warren> might be slower because it has to copy and write
233 2014-04-16 09:59:45 <wumpus> sipa: that depends on where the corruption is, if blocks are missing early it will start fetching from the network from there, right?
234 2014-04-16 09:59:53 <warren> OTOH the blockchain synced from the network might be full of orphans
235 2014-04-16 10:00:04 <sipa> wumpus: right, but his bootstrap.dat may be corrupted too
236 2014-04-16 10:00:08 <wumpus> sipa: right
237 2014-04-16 10:00:29 <elichai2> so -reindex then?
238 2014-04-16 10:00:43 <sipa> if you still have bootstrap, use that first
239 2014-04-16 10:00:46 <elichai2> (i don't think it's corrupted because i reviryfied it through toorent)
240 2014-04-16 10:00:49 <warren> wumpus: i'm going ahead with announcement of nightly builds, ok?
241 2014-04-16 10:00:55 <wumpus> warren: sure!
242 2014-04-16 10:01:00 <elichai2> warren: +1
243 2014-04-16 10:01:07 <elichai2> thats awessome!
244 2014-04-16 10:01:09 <warren> wumpus: then tomorrow will edit and post the dev roadmap that refers to it
245 2014-04-16 10:01:19 <elichai2> for the bitcoin-dev?
246 2014-04-16 10:02:05 <elichai2> *bitcoin-qt
247 2014-04-16 10:02:08 <elichai2> right?
248 2014-04-16 10:02:41 <sipa> bitcoin core it is called now
249 2014-04-16 10:09:09 <elichai2> that cool, but what would you add to the core?
250 2014-04-16 10:09:19 <elichai2> and it won't make some kind of a fork?
251 2014-04-16 10:11:57 <sipa> wth are you talking about?
252 2014-04-16 10:12:08 <sipa> the project was just renamed
253 2014-04-16 10:12:31 <elichai2> i'm talking about the nightly brunch
254 2014-04-16 10:12:51 <sipa> you're not supposed to use it for anything but testing of course
255 2014-04-16 10:14:05 <elichai2> btw, you ever thought about translating bitcoin core to other languages?
256 2014-04-16 10:14:14 <sipa> no
257 2014-04-16 10:14:38 <sipa> we can hardly managed to avoid forking bugs when changing small parts of the consensus-critical code
258 2014-04-16 10:14:54 <sipa> translating it to another language is totally crazy imho
259 2014-04-16 10:16:59 <elichai2> it showed that i've disconnected?
260 2014-04-16 10:17:17 <sipa> ?
261 2014-04-16 10:18:05 <elichai2> you saw that i disconnected and then reconnected a minute ago?
262 2014-04-16 10:18:14 <elichai2> (i have new bnc and want to know that it's working)
263 2014-04-16 10:20:07 <elichai2> when are you announcing about the nightly builds?
264 2014-04-16 10:22:42 <sipa> ask warren
265 2014-04-16 10:22:54 <sipa> i did not see a disconnect/reconnect
266 2014-04-16 10:23:05 <elichai2> sipa: can you please have a look here: https://bitcointalk.org/index.php?topic=19296.0
267 2014-04-16 10:23:07 <elichai2> sipa: thx
268 2014-04-16 10:24:13 <sipa> that's ancient
269 2014-04-16 10:24:20 <sipa> look at the date
270 2014-04-16 10:24:54 <elichai2> ohhh :(
271 2014-04-16 10:25:04 <elichai2> and all the links there dead...
272 2014-04-16 10:29:19 <sipa> it was also a really bad idea
273 2014-04-16 10:29:56 <warren> I have a self GPG signed index to use with bootstrap.dat ... but I don't distribute it.
274 2014-04-16 10:39:06 <sipa> bootstrap.dat is safe
275 2014-04-16 10:39:11 <sipa> even unsigned
276 2014-04-16 10:40:10 <wumpus> I think he means to say he signs the index, not bootstrap.dat
277 2014-04-16 10:41:42 <sipa> oh, right!
278 2014-04-16 10:41:45 <sipa> i misread
279 2014-04-16 11:03:52 <elichai2> warren: when the announcement will be?
280 2014-04-16 11:13:52 <warren> elichai2: why does it matter?
281 2014-04-16 11:14:14 <elichai2> just want to know :)
282 2014-04-16 11:14:21 <elichai2> maybe the price will go up then lol
283 2014-04-16 11:14:59 <wumpus> just hoping they won't use nightlies in production...
284 2014-04-16 11:15:49 <wumpus> luckily the builds will have the big 'do not use for mining and merchant applications' warning
285 2014-04-16 11:17:03 <elichai2> yeah
286 2014-04-16 11:17:17 <elichai2> wumpus: so you saying not to use the beta for normal wallet client?
287 2014-04-16 11:17:22 <elichai2> (i'm not minning...)
288 2014-04-16 11:17:29 <sipa> elichai2: every bitcoin release has been beta
289 2014-04-16 11:17:31 <wumpus> all bitcoin releases are "beta"
290 2014-04-16 11:17:48 <sipa> elichai2: but no, don't use release candidates or nightlies or anything but a full release for production
291 2014-04-16 11:18:05 <elichai2> sipa: no lol i talked about the nightlies and 0.9.99.0
292 2014-04-16 11:18:10 <wumpus> I'm saying that you shouldn't use a nightly for normal wallet client *unless you take proper precautions, and are willing to take the risks*
293 2014-04-16 11:18:32 <elichai2> sipa: and there is diffrence between self compiled client and official binaries?
294 2014-04-16 11:18:33 <sipa> ^ that
295 2014-04-16 11:18:53 <sipa> elichai2: you shouldn't use self compiled code that is not an actual release tag either...
296 2014-04-16 11:19:45 <elichai2> no, i'll compile the main brunch
297 2014-04-16 11:19:55 <elichai2> or the 0.9.1 brunch?
298 2014-04-16 11:19:59 <sipa> the master branch is where all development happens
299 2014-04-16 11:20:07 <sipa> if you want to build a release, checkout the tag and build that
300 2014-04-16 11:20:12 <sipa> git checkout v0.9.1
301 2014-04-16 11:20:15 <sipa> for example
302 2014-04-16 11:20:16 <elichai2> ok,
303 2014-04-16 11:20:46 <elichai2> because 0.9.1 official not working in debian wheezy, and i have now 0.9.99
304 2014-04-16 11:21:15 <wumpus> well, if you compile 0.9.1 yourself it will work fine on debian wheezy
305 2014-04-16 11:22:25 <wumpus> so check out and build the tag: git checkout v0.9.1 && ./autogen.sh && ./configure ... && make
306 2014-04-16 11:22:45 <Luke-Jr> may need ./configure --with-incompatible-bdb
307 2014-04-16 11:23:05 <warren> Personally I'd trust the gitian build more than self-compiled
308 2014-04-16 11:23:09 <warren> you have no idea what they're building against
309 2014-04-16 11:23:49 <wumpus> in generally that also doesn't matter
310 2014-04-16 11:24:12 <wumpus> it's not like the dependencies used by gitian are somehow holy and bug-free
311 2014-04-16 11:24:26 <warren> they are not? =)
312 2014-04-16 11:24:32 <elichai2> wumpus: yeah, i compiled 0.9.0 already(before 0.9.1)
313 2014-04-16 11:24:34 <wumpus> alas
314 2014-04-16 11:24:35 <warren> they're at least predictable
315 2014-04-16 11:24:52 <elichai2> just want to know if there's diffrence between compiling myself and official binary
316 2014-04-16 11:25:08 <sipa> yes
317 2014-04-16 11:25:22 <sipa> if you compile yourself, you'll use whatever dependencies exist on your system
318 2014-04-16 11:25:40 <sipa> instead of somewhat more controlled specific versions that are used for the release binaries
319 2014-04-16 11:26:14 <elichai2> yeah, but someone told me that leveldb error is more rare in official binary than from source
320 2014-04-16 11:26:41 <wumpus> elichai2: that'd be strange; we embed leveldb in the repository, we never use the system leveldb
321 2014-04-16 11:29:05 <elichai2> wumpus: that means?
322 2014-04-16 11:29:05 <sipa> some distros patch the bitcoin source to use system leveldb, i think :(
323 2014-04-16 11:33:23 <warren> If Bitcoin officially forked leveldb you could bypass that policy in distros ...
324 2014-04-16 11:33:48 <sipa> you know my opinion on that
325 2014-04-16 11:33:49 <warren> Chromium has similar reasons for embedding their own libraries, and Fedora refuses to accept it for that reason.
326 2014-04-16 11:35:01 <warren> sipa: isn't distro leveldb incompatible now?  the .sst issue
327 2014-04-16 11:35:27 <sipa> we read from both .ldb and .sst, but use .sst for writing
328 2014-04-16 11:35:33 <Luke-Jr> warren: Chromium has zero legitimate reason to embed libraries
329 2014-04-16 11:35:37 <sipa> so no, we are compatible
330 2014-04-16 11:35:58 <Luke-Jr> sipa: we should have just wrote .ldb since it's incompatible with 0.8.x anyway <.<
331 2014-04-16 11:36:18 <sipa> yeah, for 0.9 we could have reverted to the default
332 2014-04-16 11:36:35 <warren> the incompatible part was committed later
333 2014-04-16 11:37:00 <sipa> if 0.10 has headers-first stuff, the database will be backward incompatibly changed anyway, so we'll have a new chance to revert there
334 2014-04-16 11:37:12 <warren> good point
335 2014-04-16 11:37:34 <warren> 
ACTION sleep

336 2014-04-16 11:38:54 <Luke-Jr> why is headers-first changing the index format?
337 2014-04-16 11:39:46 <elichai2> sipa: so how can i make sure that it won't use leveldb?
338 2014-04-16 11:40:37 <sipa> Luke-Jr: because the index can now have headers which don't have associated block data
339 2014-04-16 11:41:01 <sipa> elichai2: if you compile code checkout out from bitcoin's repository, you always use our leveldb
340 2014-04-16 11:41:29 <sipa> Luke-Jr: it's not technically changing any encoding, but the old implementation code can't deal with that case
341 2014-04-16 11:46:14 <elichai2> sipa: ok, so when the 0.9.99 will finish reindexing the blocks i'll compile 0.9.1
342 2014-04-16 11:48:27 <GAit> petertodd: your reddit post wasn't very popular
343 2014-04-16 11:48:49 <GAit> isn't it just Gresham's Law?
344 2014-04-16 11:56:06 <vetch> GAit: it's too long. needs to be put into a meme for Reddit users to upvote it.
345 2014-04-16 11:57:39 <GAit> imho assuming miners are greedy it's a good argument. They are, they hop on different pools and coins and they have huge investments in mining equipment. If big corporations and mostly $$ oriented why would you expect large miner operations to be any different?
346 2014-04-16 11:58:02 <GAit> s/big corporations and/big corporations are/
347 2014-04-16 11:59:39 <sipa> GAit: here "miners" usually refers to those actually building blocks
348 2014-04-16 11:59:48 <sipa> GAit: not hashers who just sell their hashrate to a pool
349 2014-04-16 11:59:56 <Luke-Jr> sipa: I still don't like the idea of "importaddress" not being for addresses. Surely there's a better name (or maybe accept either hex or address format in importscriptpubkey)?
350 2014-04-16 12:00:09 <GAit> sipa: sure, now is all about pools
351 2014-04-16 12:00:25 <Luke-Jr> (maybe in the future, we will want "importaddress" to actually have a similar behaviour for the actual address..)
352 2014-04-16 12:00:35 <sipa> Luke-Jr: it is for addresses
353 2014-04-16 12:00:44 <sipa> Luke-Jr: an address is a shorthand for a specific scriptpubkey
354 2014-04-16 12:01:11 <Luke-Jr> sipa: an address is opaque, and only shorthand for a scriptpubkey when receiving (not controlling)
355 2014-04-16 12:01:18 <GAit> but the argument that pools wouldn't do it because it would lower overall value doesn't really hold off I think, people choose every day high rewards credit card which make overall value less for everyone, but better for them.
356 2014-04-16 12:02:33 <Luke-Jr> sipa: There is a real use case for watching *actual* addresses (and observing receipt, but not the unrelated sends)
357 2014-04-16 12:02:49 <Luke-Jr> (independent of your use case, not instead-of)
358 2014-04-16 12:02:59 <sipa> Luke-Jr: which is perfectly covered by this implementation
359 2014-04-16 12:03:18 <Luke-Jr> is it? how do I watch the address without getting the unrelated send transactions in the wallet?
360 2014-04-16 12:03:26 <sipa> by ignoring those
361 2014-04-16 12:03:39 <sipa> by using getreceivedbyaddress, which is already for that use case
362 2014-04-16 12:03:55 <Luke-Jr> ignoring those is not something listtransactions/GUI support
363 2014-04-16 12:04:21 <sipa> well, the RPC is called "importaddress"
364 2014-04-16 12:04:24 <sipa> not "watchaddress"
365 2014-04-16 12:04:33 <sipa> it adds that address to what the wallet considers its own
366 2014-04-16 12:05:48 <Luke-Jr> it adds the scriptpubkey, not just the address.
367 2014-04-16 12:06:01 <sipa> an address is a shorthand for a scriptpubkey
368 2014-04-16 12:06:42 <Luke-Jr> it's supposed to be an opaque identifier, not a shorthand.
369 2014-04-16 12:06:55 <sipa> i'm tired of this discussion, sorry
370 2014-04-16 12:07:04 <melvster> sorry net disconnected ...
371 2014-04-16 12:09:00 <melvster> *not sure if this came thru* ... it's not in the log, apologies if it's a repost
372 2014-04-16 12:09:02 <melvster> in the coinbase of the genesis block it's kind of big endian, yet everything else in the genesis block is little endian, right?
373 2014-04-16 12:09:56 <sipa> afaik there is nothing big-endian ever, except some cryptography-related things
374 2014-04-16 12:09:57 <melvster> *the message about the chancellor I mean* in the coinbase
375 2014-04-16 12:10:09 <sipa> which bitcoin treats as byte arrays, not as numbers
376 2014-04-16 12:10:16 <sipa> ... text is not a number
377 2014-04-16 12:10:23 <melvster> sipa: ah ok thanks, so it's just backward in english
378 2014-04-16 12:10:31 <sipa> big/litte endian is how you encode numbers
379 2014-04-16 12:10:37 <melvster> oic
380 2014-04-16 12:10:43 <sipa> yes, english uses "big endian decimal" to write numbers
381 2014-04-16 12:11:08 <melvster> interesting thanks
382 2014-04-16 12:11:30 <hearn> hello
383 2014-04-16 12:12:56 <hearn> GAit: lots of people don’t have/can’t get credit cards, actually.
384 2014-04-16 12:13:04 <hearn> so “people” is a large generalisation :)
385 2014-04-16 12:14:28 <GAit> hearn: my reasoning on it is better explained in this blog that talks about credit card and back in the day altered coins, Gresham's law, I think it applies to pools too
386 2014-04-16 12:14:38 <GAit>  http://jpkoning.blogspot.it/2014/04/greshams-law-and-credit-cards.html
387 2014-04-16 12:17:11 <hearn> GAit: the card contracts have been struck down in some parts of the world for that reason
388 2014-04-16 12:17:47 <GAit> so regulation is the solution? on bitcoin pools?
389 2014-04-16 12:18:20 <hearn> what was the question, sorry?
390 2014-04-16 12:18:24 <hearn> i didn’t see all the prior discussion
391 2014-04-16 12:19:46 <GAit> the question is whether we can prevent in any distributed way, i.e. without regulation, things like bitundo
392 2014-04-16 12:20:04 <sipa> no,i don't think so
393 2014-04-16 12:20:15 <sipa> (and i think it's inevitable)
394 2014-04-16 12:20:31 <vetch> I doubt bitundo will ever gain anything approaching a usably large pool
395 2014-04-16 12:20:54 <hearn> “we” cannot prevent anything, seeing as we developers have little to no power, however “we” can point out to people that it’s an ultimately self defeating strategy that would be unwise to adopt
396 2014-04-16 12:20:57 <vetch> an API for wallets and merchants to request retractions and block them? come on.
397 2014-04-16 12:21:21 <hearn> ultimately if the bitcoin community wants to self destruct, nobody can stop it from doing so
398 2014-04-16 12:21:28 <hearn> it would of course be very sad if that were to happen
399 2014-04-16 12:21:56 <GAit> hearn: i don't it would self destruct
400 2014-04-16 12:22:05 <sipa> as fees become more important income sources for miners, i believe that at some point miners will want more competion on that market
401 2014-04-16 12:22:39 <GAit> just like you need third parties for escrow you may need third parties for speed, or otherwise you just wait your confirmations. This has no impact on most ecommerce, is just a in shop or person to person friction point
402 2014-04-16 12:23:00 <hearn> bitundo could of course also charge for undoing txns that already appeared in blocks
403 2014-04-16 12:23:12 <hearn> there’s nothing special about pending txns in that regard. it’s just a matter of price.
404 2014-04-16 12:23:20 <GAit> that is a much harder thing to do
405 2014-04-16 12:23:29 <vetch> if the price is right
406 2014-04-16 12:23:32 <sipa> there they have at least the subsidy to compete against
407 2014-04-16 12:23:42 <hearn> and obviously if you end up needing third parties for common classes of transactions, bitcoin loses its raison d’etre, doesn’t it?
408 2014-04-16 12:23:45 <vetch> if there's more than 25BTC of incentive to reverse a block, then it will happen
409 2014-04-16 12:23:46 <GAit> and would self destroy bitcoin, so the price has to be huge and you would already make tons of money in fees/blocks
410 2014-04-16 12:23:50 <hearn> the entire point of bitcoin is to allow direct payments between people with no third parties
411 2014-04-16 12:24:05 <GAit> hearn: can you do an escrow without third parties?
412 2014-04-16 12:24:22 <GAit> it allows it, but instead of being seconds is hours or use a third party
413 2014-04-16 12:24:40 <GAit> or 10 minutes on avg if one block is deemed ok
414 2014-04-16 12:25:02 <hearn> you mean a dispute mediated transaction? by definition, no, but for many transactions you don’t need mediation and when you do, that’s not because of any issue with bitcoin. heck we manage an entire economy with none whatsoever today, although that’s hardly a great place to be
415 2014-04-16 12:26:05 <hearn> if you end up needing third parties because of some inherent issue with bitcoin, and not the seller in question, then that’s rather different and much worse
416 2014-04-16 12:26:06 <GAit> hearn: ok so not escrow as per definition but some sort of safety net in case the counterparty doesn't deliver, some sort of funds locking mechanism/auto destruction thing. As far as I know that still requires a third party
417 2014-04-16 12:26:21 <vetch> you need a mediator.
418 2014-04-16 12:26:32 <vetch> the blockchain can't make decisions for itself.
419 2014-04-16 12:26:56 <hearn> sort of
420 2014-04-16 12:27:05 <hearn> the people making the block chain obviously can set any rules they want
421 2014-04-16 12:27:27 <hearn> for instance, you could have a transaction type that requires a PDF digitally signed by FedEx to be attached to it. this would be a bizarre and wrong-headed design, but it could be done.
422 2014-04-16 12:27:57 <vetch> I've read about people's ideas for making a distributed mediation, but it always completely falls apart when you get to the decision making. they usually involve a lot of participants, but there's no way of preventing sybil attacks.
423 2014-04-16 12:28:02 <hearn> then you wouldn’t need any third party mediator to decide if a package had been delivered, just the proof from the delivery company. in practice it’s probably better to use a third party in that case. but it’s always worth looking for ways to optimise them out
424 2014-04-16 12:28:25 <vetch> hearn: that doesn't cover all of the use cases of the mediator. what if the seller sent a box of bricks?
425 2014-04-16 12:29:13 <GAit> if we use regulation for this, what stops regualtor from adding white listing?
426 2014-04-16 12:29:16 <hearn> sure. but most existing dispute mediation systems (in paypal etc) don’t handle that case well either. i’m not saying we don’t need third party mediators, we clearly do, just pointing out that for some of the things they would be used for, it could be integrated into bitcoin
427 2014-04-16 12:29:47 <hearn> GAit: “regulation” just means rules, doesn’t it. it’s quite possible for private sector systems to “regulate” themselves though that’s not normally what people think of when they hear the word
428 2014-04-16 12:29:56 <hearn> in a sense miners regulate the system and each other today
429 2014-04-16 12:30:05 <GAit> i can see the private corporations regulating them selves just great
430 2014-04-16 12:30:05 <hearn> bitundo is attempting to bribe the regulators, in effect
431 2014-04-16 12:30:52 <GAit> they get beaten up by their boards and investors if they don't take advantage of every possible legal and para legal thing
432 2014-04-16 12:30:56 <vetch> hearn: you'd also need some way of getting the PDF proof to everybody who needs to verify the block. else you've got a trusted oracle doing the verification.
433 2014-04-16 12:31:18 <hearn> vetch: yes. that’s why i said “attach”. it’d go into the block chain. obviously not a scheme that’s really affordable with current technology.
434 2014-04-16 12:31:34 <hearn> vetch: one can imagine a far more tightly defined specialised format that could be affordable though
435 2014-04-16 12:31:53 <vetch> hearn: right, sorry, I interpreted "attach" as "post a hash"
436 2014-04-16 12:32:22 <hearn> ah nope. i meant literally attach :) satoshi designed the p2p protocol to allow for this kind of thing actually. you could add extra data to the end of a tx message and it’d be relayed. it got taken out though
437 2014-04-16 12:33:04 <hearn> GAit: there are plenty of examples of it working. the CA system is one such example.
438 2014-04-16 12:33:11 <hearn> in that world the “regulators” are the browser and OS makers
439 2014-04-16 12:33:20 <hearn> though we don’t tend to think of them as such
440 2014-04-16 12:33:42 <GAit> hearn: the CA system is not a good example, as they will lose all business immediately if found out, with the pool miners know what they are doing
441 2014-04-16 12:34:24 <hearn> it was an example of private sector regulation rather than a direct analogy to our situation. for it to apply to bitcoin, node/wallet developers would have to contain lists of trusted miners
442 2014-04-16 12:34:28 <hearn> or something like that
443 2014-04-16 12:34:53 <hearn> obviously the super-lightweight / anonymous mining design is highly convenient and useful in many ways, it’s something we definitely want to keep
444 2014-04-16 12:34:55 <GAit> yeah then it would be comparable
445 2014-04-16 12:35:18 <hearn> but if miners stop running the system in the way other stakeholders want, then we might end up losing it
446 2014-04-16 12:35:23 <hearn> hopefully it never comes to that
447 2014-04-16 12:35:50 <GAit> but then is also not decentralized in the same way
448 2014-04-16 12:35:55 <GAit> it can be corrupted
449 2014-04-16 12:37:19 <hearn> decentralisation is a spectrum. yes it’d be less decentralised, of course. i was only pointing out that if the system is already corrupted, there isn’t much alternative but to either change it or abandon it
450 2014-04-16 12:45:24 <GAit> hearn: i don't think double spend was ever considered impossible and current miners can easily do this as a low marginal cost (although they may lose on reputation) even for small tx value. I don't know for sure how it will play out but i  have always thought that as long as there is sufficiently large incentive to do it people will do it,
451 2014-04-16 12:45:58 <GAit> i don't think there is enough incentive to do block rewrite consistently but double spend like bitundo, yeah, easy
452 2014-04-16 12:47:10 <hearn> miners don’t have reputation - they are anonymous
453 2014-04-16 12:47:19 <GAit> pools are not
454 2014-04-16 12:47:24 <vetch> pools can be
455 2014-04-16 12:47:35 <hearn> pools are just collections of miners
456 2014-04-16 12:47:38 <GAit> yeah they can be anonymous but also have a reputation
457 2014-04-16 12:47:44 <hearn> plus, you can’t reliably identify who mined a block
458 2014-04-16 12:48:49 <vetch> you can false attribute them too
459 2014-04-16 12:49:22 <hearn> in practice bitundo type double spending is not likely to become a serious issue for most sellers
460 2014-04-16 12:49:57 <GAit> what do you base this on? the fact that they wait for confirmations or the fact that no wallet has integrated bitundo yet?
461 2014-04-16 12:50:00 <hearn> because you need to be informed when the pool has found a block, and then “auto buy” from the seller. every seconds delay between solving a block and resolving the purchase is a second in which some other miner can find a block at the same height and broadcast it, losing you your work
462 2014-04-16 12:50:34 <hearn> this “auto buying” is in practice something that requires a program to do, and it requires a seller that automatically sells something of value quickly and irreversibly
463 2014-04-16 12:50:48 <hearn> most sellers do not wait for any confirmations, in fact i’d say the vast majority do not
464 2014-04-16 12:50:57 <GAit> if it works even once out of 10 is still good and i don't see why people won't exploit it, they expoit CC issues don't they?
465 2014-04-16 12:50:57 <hearn> which is why it’s important to try and keep unconfirmed transactions useful
466 2014-04-16 12:51:14 <hearn> GAit: only if you are OK with actually purchasing 9 of the things
467 2014-04-16 12:51:39 <GAit> if it's stuff easy to resell on a small loss then it can easily make up for it
468 2014-04-16 12:52:04 <hearn> if you’re constantly buying things over and over again AND the merchant does not require you to ID yourself AND the merchant is on auto pilot and sells within seconds AND you have a software setup that’s all integrated with this THEN it can earn you some money, sometimes, assuming you don’t get dragged to court for fraud
469 2014-04-16 12:52:50 <hearn> in practice merchants that get whacked by this kind of thing will just end up requiring ID verification of buyers
470 2014-04-16 12:53:22 <hearn> which is annoying and painful, but it will push wallet authors to make automatic IDV easier for people. of course we lose some of the nice privacy aspects then, so it’s not ideal and is better if miners don’t do it
471 2014-04-16 12:53:28 <hearn> basically bitundo just means bitcoin gets worse in various aspects
472 2014-04-16 12:53:40 <GAit> agreed it can't be used in all circumstances however people tend to find a way and will take advantage of it. Just like we reccomend to never reuse key pairs we should reccomend to not trust 0 confirmation, IMHO
473 2014-04-16 12:53:47 <hearn> if it gets sufficiently worse, of course, then it won’t be competitive with banking any more and people will lose interest. this is what i meant by “self destruct"
474 2014-04-16 12:53:51 <vetch> hearn: and the bitundo guy makes bank doing it.
475 2014-04-16 12:54:05 <hearn> well there are lots of ways to make money by trashing bitcoin
476 2014-04-16 12:54:23 <hearn> e.g. find a way to do a large short sell (anyone who allows short selling of bitcoin has no clue what they’re doing, imo) and then DoS the network
477 2014-04-16 12:54:33 <hearn> it’s a very vulnerable thing that can easily be damaged for profit
478 2014-04-16 12:55:38 <GAit> hearn: but that improves as the network becomes stronger and bigger and more people adopt bitcoin
479 2014-04-16 12:56:29 <hearn> er, no
480 2014-04-16 12:56:52 <hearn> it disrupts bitcoin for days, weeks or months then everyone sells when they realise that what they thought was a honey badger is more like a glass vase
481 2014-04-16 12:57:14 <hearn> it’s not like someone shorting bitcoin and attacking it magically makes skilled C++ developers who can work full time show up and start producing quality code
482 2014-04-16 12:57:24 <hearn> at least, nowhere near fast enough to react
483 2014-04-16 12:58:59 <GAit> maybe i was clear, i can see this being a problem now but i have hope that in time this will be less of an issue
484 2014-04-16 12:59:04 <GAit> wasn't*
485 2014-04-16 13:00:24 <hearn> yes in theory, but i am skeptical we can ever make bitcoin invincible
486 2014-04-16 13:00:31 <hearn> there will always be ways to attack the infrastructure
487 2014-04-16 13:00:46 <hearn> especially because nobody owns it and it’s not clear that anyone could really be prosecuted for attacking it, as such
488 2014-04-16 13:00:50 <vetch> Bitcoin has a massive bus factor.
489 2014-04-16 13:01:07 <vetch> yeah sure, other people can pick up the slack, but there's a lot of learning involved before you can
490 2014-04-16 13:02:29 <hno> what are we talking about exactly?
491 2014-04-16 13:02:31 <hearn> good day gavinandresen
492 2014-04-16 13:02:45 <gavinandresen> howdy hearn
493 2014-04-16 13:02:57 <hearn> hno: bitundo
494 2014-04-16 13:03:52 <hno> sorry, missing the piece on what bitundo is.
495 2014-04-16 13:04:03 <GAit> double spend service, or undo tx service
496 2014-04-16 13:04:04 <vetch> tl;dr: a pool and service designed to mine conflicting transactions for a fee.
497 2014-04-16 13:04:24 <hearn> yeah. finney attack for a 10% fee, essentially. not sure how much hash power they have. the creator only just announced it
498 2014-04-16 13:04:49 <vetch> negligible hash power. they're wanting pools and wallet software to cooperate.
499 2014-04-16 13:04:55 <GAit> double fee if you don't want your attempt to be seen on the network (if it doesn't work that is, because when it does it will be seen)
500 2014-04-16 13:05:45 <vetch> they're using Eoipool and not showing their stats, so who knows how big they are really.
501 2014-04-16 13:06:57 <vetch> Do you only support stratum?
502 2014-04-16 13:07:06 <vetch> Yes. Getwork is too inefficient, and GBT leaks information about attempted undos, that users have asked us not to share.
503 2014-04-16 13:08:05 <hearn> hah
504 2014-04-16 13:08:14 <hearn> the “undo service” thing is so paper thin
505 2014-04-16 13:08:32 <vetch> it's basically a hacking tool. there's no other reason for "hiding" the undos.
506 2014-04-16 13:08:57 <GAit> as true at that may be once it moves to tor (if it does) there is no way of stopping it, is there?
507 2014-04-16 13:09:07 <GAit> there is an incetive for people to ALWAYS attempt it when leaving a shop that accepts 0 confirmation, especially if the shop is not likely to remember you and it can be trivially implemented as a button in the wallet unconfirmed tx page.
508 2014-04-16 13:09:45 <hearn> the incentive is not getting arrested
509 2014-04-16 13:09:47 <vetch> no wallet is going to implement that centralised API
510 2014-04-16 13:09:56 <vetch> it's suicidal.
511 2014-04-16 13:10:04 <hearn> i think a good lawyer could convince a judge that doing that is analogous to paying with forged notes
512 2014-04-16 13:10:18 <epscy> just to be clear bitundo only works for unconfirmed txes?
513 2014-04-16 13:10:23 <GAit> if it can be proven that nobody else had access to the keys
514 2014-04-16 13:10:25 <hearn> vetch: bitundo could easily provide a forked version of a popular wallet that has the button
515 2014-04-16 13:10:27 <epscy> s/works/may work/
516 2014-04-16 13:10:27 <vetch> epscy: indeed.
517 2014-04-16 13:10:41 <epscy> i just can't get worked up about it then
518 2014-04-16 13:10:43 <GAit> hearn: exactly, bitundo could patch all wallets and provide them as foss packages
519 2014-04-16 13:10:44 <vetch> hearn: they are providing a fork of Bitcoin Core for mining with.
520 2014-04-16 13:11:05 <vetch> who would trust a binary from someone running a hacking service?
521 2014-04-16 13:11:14 <hearn> right. they’re basically promoting a forked version of bitcoin, which uses a different rule set, but the same block chain
522 2014-04-16 13:11:18 <GAit> you are talking about this as if credit card fraud doesn't exist, it exist and it is a huge issue
523 2014-04-16 13:11:34 <GAit> even if illegal
524 2014-04-16 13:11:45 <hearn> GAit: no, EMV basically wiped that out for in person transactions. don’t believe the “EMV is broken” hype, the stats speak for themselves
525 2014-04-16 13:11:58 <hearn> you can’t walk out of a shop (at least not in most parts of the world now) and simply take back your money.
526 2014-04-16 13:12:06 <epscy> EMV?
527 2014-04-16 13:12:11 <vetch> chip and pin.
528 2014-04-16 13:12:14 <epscy> oh right
529 2014-04-16 13:12:18 <hearn> even with weak-ass magstripe CCs you couldn’t do that anyway, banks don’t let you reverse arbitrary transactions for a fee
530 2014-04-16 13:12:26 <GAit> chip and pin has hacks as far as i know
531 2014-04-16 13:12:30 <hearn> merchants win about 40% of chargeback claims, iirc
532 2014-04-16 13:12:42 <vetch> speaking from experience there's a ridiculous amount of paperwork needed to chargeback
533 2014-04-16 13:12:56 <GAit> basically the hack is to use the card as if it was on a flight, disconnected and use signature
534 2014-04-16 13:13:14 <vetch> it took me a month and four trips to my bank to reverse a clearly bad transaction. I had screenshots of the merchant admitting they never shipped a product.
535 2014-04-16 13:13:17 <GAit> but tell the server it was PIN, or something like that. It was published by a university researcher i think
536 2014-04-16 13:13:26 <epscy> i just don't think we should be encouraging acceptance of zero conf txes in the first place, problem solved
537 2014-04-16 13:13:38 <GAit> epscy: yep agreed
538 2014-04-16 13:13:47 <vetch> GAit: different difficulty to a hacked up tape recorder to swipe the data from a credit card strip.
539 2014-04-16 13:13:59 <hearn> GAit: there have been a bunch of clever protocol attacks, but they all have patches available (or were impractical to begin with)
540 2014-04-16 13:14:14 <GAit> yes. but as long as some country issues signature cards you can still fraud people
541 2014-04-16 13:14:26 <hearn> epscy: do you actually use bitcoin, though? you’re saying you want to discourage a huge number of actual transactions today
542 2014-04-16 13:14:40 <epscy> hearn: yeah i do
543 2014-04-16 13:14:55 <GAit> I use bitcoin and generally unless i trust the person I wait at least one confirm before leaving.
544 2014-04-16 13:15:03 <hearn> most of the transactions i make, clear instantly because there is no waiting for a transaction
545 2014-04-16 13:15:34 <epscy> hearn: i think bitcoin is most suitable for transacting over the internet and it's rare that you can't wait for a confirm
546 2014-04-16 13:15:39 <hearn> GAit: some merchants reject magstripe-only cards, actually. this is a common problem for americans travelling abroad
547 2014-04-16 13:15:48 <epscy> for physical in person txes, cash and credit cards work well
548 2014-04-16 13:16:19 <GAit> ok i'm just suggesting that as long as CC have holes they will be used and i have no reason to doubt the same about bitcoin
549 2014-04-16 13:16:27 <hearn> epscy: hardly. i routinely order pizza online with bitcoin. i’d simply not do that if variance meant i might have to wait an hour or two before the pizza place even dispatched the courier.
550 2014-04-16 13:16:50 <GAit> hearn: by the time the ship the pizza usually there's a confirmation
551 2014-04-16 13:16:55 <GAit> so is this a good example?
552 2014-04-16 13:17:08 <epscy> hearn: also they know your address
553 2014-04-16 13:17:16 <kinlo> it makes some dangerous pizza from time to time
554 2014-04-16 13:17:28 <epscy> they can come and knock on your door if the tx doesn't get confirmed
555 2014-04-16 13:17:33 <GAit> they may still deliver the pizza and put poison in it!
556 2014-04-16 13:17:35 <hearn> “usually” isn’t good enough. i want to eat ASAP, damnit, and not risk that natural chance means there’s no block for 90 minutes or that one appears after 60 and my tx wasn’t included for some reason
557 2014-04-16 13:17:58 <GAit> hearn: if you double spend on them as epscy said they can come to your door with some money recovery guy :)
558 2014-04-16 13:18:02 <vetch> hearn: sounds like it's time for sub-block chains then.
559 2014-04-16 13:18:07 <hearn> look at it this way. if i can pay with cash or CC and be assured my pizza will be delivered ASAP, no screwing around, or bitcoin and encounter arbitrary delays, i’ll go with CCs
560 2014-04-16 13:18:11 <vetch> or a man with a mallet.
561 2014-04-16 13:18:16 <epscy> but i still think a service on top of bitcoin would be a better solution, but there is basically no difference between such service and a credit card company QED
562 2014-04-16 13:18:19 <hearn> yesterday i spent bitcoins at a cafe
563 2014-04-16 13:18:26 <kinlo> but in pizzaland you have to think differently, those are small amounts, if you miss out on one, it's perfectly manageable...
564 2014-04-16 13:18:32 <hearn> i quite enjoyed doing that. i would like to keep doing it. that requires instant payment.
565 2014-04-16 13:18:37 <sipa> i think such use cases will eventually require a payment processor anyway
566 2014-04-16 13:18:55 <sipa> bitcoin cannot give the necessary guarantees, so someone will need to take the risk
567 2014-04-16 13:19:09 <sipa> bitcoin is just a technology/currency
568 2014-04-16 13:19:14 <sipa> credit cards are payment systems
569 2014-04-16 13:19:18 <GAit> hearn:  just because people have been uncareful with btc doesn't mean we should going forward. There are mechanism for instant tx anyway. Initially credit cards were using carbon copy weren't they?
570 2014-04-16 13:19:40 <kinlo> I still think bitcoin should be seen as a method for storing your own coins, and some overlay network should do day-to-day transactions
571 2014-04-16 13:19:45 <hearn> they’re hardly uncareful. the system works, today. the bitundo guys want to stop it working.
572 2014-04-16 13:19:46 <vetch> GAit: yep. the checksum is designed for mechanical computation.
573 2014-04-16 13:20:03 <GAit> hearn: is not those guys the problem, is the incentive
574 2014-04-16 13:20:07 <epscy> hearn: the protocol never guaranteed zero confs would work
575 2014-04-16 13:20:22 <kinlo> ie, a shop owner would get 1 bitcoin transaction per month from the "credit card company" with their revenue, and each customer would charge their "credit card company" once ever x time in advance
576 2014-04-16 13:20:23 <hearn> a protocol can’t guarantee anything, obviously, if people don’t follow it
577 2014-04-16 13:20:35 <vetch> bitcoin takes that out as an issue.
578 2014-04-16 13:20:37 <kinlo> so even if you sell 100 beers, only 1 bitcoin transaction should be seen on the bitcoin network
579 2014-04-16 13:20:38 <epscy> hearn: if we are to rely upon people acting nicely, why do we need the blockchain at all?
580 2014-04-16 13:20:47 <GAit> hearn: bitcoin works on incetives
581 2014-04-16 13:20:49 <sipa> the system, as designed, has some best-effort 0-conf security
582 2014-04-16 13:21:01 <sipa> once people start competing for fees, that cannot remain
583 2014-04-16 13:21:02 <hearn> and sure, you can just shrug and say, actually kind of sucks as a payment system and in future it’ll hardly be used for that.
584 2014-04-16 13:21:09 <hearn> but then why would anyone care about a payment system that sucks?
585 2014-04-16 13:21:12 <sipa> bitcoin simply is not a payment system
586 2014-04-16 13:21:34 <epscy> hearn: bitcoin is a great payment system, it's just not a great instant payment system
587 2014-04-16 13:21:35 <GAit> you can built a payment system on top easily, without any extra primitives
588 2014-04-16 13:21:37 <hearn> epscy: bitcoin _does_ rely on people acting nicely and the block chain is not a solution to that.
589 2014-04-16 13:21:47 <sipa> bitcoin is a value transfer system
590 2014-04-16 13:21:49 <epscy> bitcoin is like cash with a slight delay basically
591 2014-04-16 13:21:49 <hearn> epscy: re-read the white paper. it talks about the majority being honest in several places
592 2014-04-16 13:21:54 <gavinandresen> anybody calculated the increased orphan costs of finney attacks recently?  Did the bitundo people?  If they did not, then miners would be idiots to join their pool.
593 2014-04-16 13:22:09 <GAit> hearn:  but Finnely is not about majority is it?
594 2014-04-16 13:22:28 <GAit> gavinandresen: why orphans?
595 2014-04-16 13:22:37 <GAit> they don't do rewrite as far as I know
596 2014-04-16 13:22:51 <epscy> hearn: yeah mining centralization concerns me too
597 2014-04-16 13:22:54 <gavinandresen> …. hmm…. do the bitundo people have a minimum undo amount?  DoS'ing them with tons of small-value transactions to make their orphan rate higher might work....
598 2014-04-16 13:22:56 <hearn> the bitundo people have a proposition - that bitcoin should work differently than it does. that is, unconfirmed txns should not mean anything. there is nothing in their model that suggests they wish to always be a minority - they want as much mining as possible
599 2014-04-16 13:22:57 <sipa> finney attacks don't require large blocks, as far as i know?
600 2014-04-16 13:23:17 <epscy> hearn: difference is waiting for 1 conf almost completely solves the zero conf issue
601 2014-04-16 13:23:22 <vetch> hearn: I don't think they're saying anything. they're in it to make a profit, not a statement.
602 2014-04-16 13:23:24 <gavinandresen> sipa:  equivalent-sized block will take longer to verify if the transactions haven't been broadcast
603 2014-04-16 13:23:29 <GAit> hearn: and gavinandresen this attack is already possibly every day today for marginal cost by any pool operator.
604 2014-04-16 13:23:33 <epscy> hearn: miner centralization is something i feel i have little control over
605 2014-04-16 13:23:38 <hearn> no it doesn’t. if there is a significant amount of mining power that wishes to double spend, they can replace your block with some probability (check the maths at the end of the paper)
606 2014-04-16 13:23:39 <sipa> gavinandresen: it only requires 1 non-broadcast transactions
607 2014-04-16 13:23:47 <sipa> gavinandresen: i don't think that effect is below noise level
608 2014-04-16 13:23:51 <sipa> *above
609 2014-04-16 13:23:57 <sipa> (but i have no numbers)
610 2014-04-16 13:24:09 <hearn> vetch: actually the guy is posting on reddit/hacker news that his site makes bitcoin better/that it makes double spending “legitimate” and other nonsense
611 2014-04-16 13:24:13 <hearn> vetch: so they are saying that
612 2014-04-16 13:24:20 <epscy> hearn: if that starts happening then that would damage bitcoin significantly
613 2014-04-16 13:24:26 <GAit> hearn: isn't that the same argument of Peter Todd ?
614 2014-04-16 13:24:39 <gavinandresen> sipa:  … right, but one transaction with thousands of (tiny-value) inputs will still be thousands of time longer to verify than a block with normal, already-broadcast-and-signatures-checked transactions
615 2014-04-16 13:25:02 <GAit> gavinandresen: couldn't they ignore some tx?
616 2014-04-16 13:25:02 <vetch> hearn: he acted like that on IRC too, but it still comes across as defending something intended to be used maliciously.
617 2014-04-16 13:25:10 <hearn> epscy: double spending damages bitcoin. doesn’t matter much if it’s unconfirmed, one confirm, two confirms, etc. there’s nothing special about that.
618 2014-04-16 13:25:13 <vetch> hearn: wink wink not for criminals.
619 2014-04-16 13:25:18 <sipa> i'd say it will just change bitcoin, and i'm in favor of keeping the old way as long as possible (as it has better usability in the short term), but i think it's inevitable that at some point competition for fees will drive this away
620 2014-04-16 13:25:20 <epscy> hearn: i'm not saying it can't happen, but a lot of the theory behind bitcoin is predicated on people behaving rationally, and intentionally and repeatedly overwriting blocks to undo transactions would lower the value of bitcoin overall
621 2014-04-16 13:25:21 <gavinandresen> … which is why I'm pondering the effect of flooding the bitundo people with a bunch of tiny spends-to-self.
622 2014-04-16 13:25:39 <hearn> epscy: so does leaving behind the first-seen rule! they don’t care about lowering the value of bitcoin, clearly
623 2014-04-16 13:25:40 <GAit> is publishing wireshark maliscious? is publishing a memory scanner for private keys maliscious? is it the tool or how it is used?
624 2014-04-16 13:26:05 <vetch> GAit: there's a difference been a tool that can be used for malice and one who designed for it.
625 2014-04-16 13:26:15 <hearn> the former is not malicious because packet dumpers have lots of legitimate uses (i’ve used wireshark for debugging loads of times). writing malware that steals private keys clearly is.
626 2014-04-16 13:26:39 <epscy> hearn: the first seen rule can't be enforced by consensus, confirmation of a tx can though
627 2014-04-16 13:26:41 <hearn> gavinandresen: i think we should just wait and see if real merchants start complaining about being finney attacked. the bitpay guys will notice if this is happening
628 2014-04-16 13:26:42 <GAit> if it doesn't steal them is it ok? just shows how vulnerable you are. But then someone else can take it and make it a virus
629 2014-04-16 13:26:45 <sipa> double spending also has legitimate use cases (sending with more fee, for example)
630 2014-04-16 13:27:00 <GAit> sipa: or in case i've been robbed
631 2014-04-16 13:27:03 <vetch> sipa: that's taken care of by child pays for parent.
632 2014-04-16 13:27:20 <sipa> it would, yes
633 2014-04-16 13:27:33 <hearn> epscy: no. gah. this is the mental block we seem to have
634 2014-04-16 13:27:42 <hearn> the block chain quantises the consensus
635 2014-04-16 13:27:56 <hearn> if there are miners who are trying to interfere with that consensus by running different rules, they can interfere with the block chain too
636 2014-04-16 13:28:00 <hno> ok. I don't see bitundo as a real threat. Only awareness riser. Accepting 0-confurmation transactions for any serious amount without knowing the customer is asking for being fooled. And very unlikely they will succeed in forking the chain to undo even 1 confirmation transactions at a rate that makes it useful.
637 2014-04-16 13:28:22 <vetch> hno: they aren't trying to fork at all. they're only touching unconfirmed transactions.
638 2014-04-16 13:28:32 <hearn> remember that you can still fork the chain even with much less than 50% of the hash power. it’s probabilistic.
639 2014-04-16 13:28:35 <hearn> just like finney attacks are
640 2014-04-16 13:28:43 <hno> vetch, I understand, but reading back the log here there is talk about forking..
641 2014-04-16 13:29:28 <hno> unconfirmed transactions are what they are called. A notification about intent, not really a transfe.r
642 2014-04-16 13:29:36 <vetch> hno: oh yeah, if the service is paid more than the block reward it becomes profitable to attempt a fork
643 2014-04-16 13:29:38 <epscy> hearn: ultimately i believe to do that would be self defeating and counter productive, but i guess we aren't going to agree
644 2014-04-16 13:30:50 <hearn> the area where we disagree is that you see unconfirmed and confirmed txns as somehow very different, and i don’t. we both agree that miners double spending is self defeating and counterproductive :)
645 2014-04-16 13:31:45 <epscy> i get what you are saying about honest miners required to make consensus work
646 2014-04-16 13:31:46 <hno> vetch, you need quite significant hashing power to do that today as you need to successfully mine n+1 blocks ahead of the rest of the network. Anyone having that amount of hashing power at their hands are very unlikely to want to touch this business as it risks the viability of bitoin.
647 2014-04-16 13:32:24 <epscy> however i think it is unrealistic to assume anything other than miners will mine txes with the highest fees
648 2014-04-16 13:32:46 <vetch> hno: while true, as the block reward drops it becomes more likely
649 2014-04-16 13:32:51 <GAit> this can be a huge pain in the ass not only for bitpay but potentially for satoshidice too
650 2014-04-16 13:33:06 <vetch> satoshidice require confirmations now
651 2014-04-16 13:33:16 <epscy> if we did enter a situation where were regularly seeing 1 or 2 block chain reorgs, that would just make people wait for more confirms
652 2014-04-16 13:33:18 <GAit> oh, sorry, i wasn't up to date on that
653 2014-04-16 13:33:33 <vetch> yeah, because people kept attacking them :P
654 2014-04-16 13:33:56 <epscy> but would lower the value of bitcoin in the interim
655 2014-04-16 13:34:06 <vetch> hno: the interesting thing is that it was against ghash.io's best interest to attack betting sites, but they did anyway.
656 2014-04-16 13:34:17 <GAit> vetch: i thought they could have used the same as bitpay, just listen on the network for long enough and accept specific standard tx with fee and good prevout
657 2014-04-16 13:34:30 <GAit> oh i see
658 2014-04-16 13:34:34 <GAit> so it was a pool that attacked them
659 2014-04-16 13:35:05 <hearn> lol. satoshidice has a eula these days too!
660 2014-04-16 13:35:08 <vetch> GAit: that's trivial to get around. push TX1 to pools, push TX2 to the majority simultaneously. you might lose a portion of the time, but attempts are free.
661 2014-04-16 13:35:27 <vetch> it's just a classic race.
662 2014-04-16 13:35:30 <hearn> vetch: yeah but the seller can detect that
663 2014-04-16 13:35:44 <GAit> yeah if it listens on enough parts of the network it can
664 2014-04-16 13:35:56 <vetch> not if the attacker times it right