1 2014-05-12 00:00:00 <sipa> and much harder to forget things due to no RAII
  2 2014-05-12 00:00:02 <GAit> yeah and imho it's easier to find someone bad at C++ than python or java
  3 2014-05-12 00:01:23 <GAit> i've seen and worked at nightmareish C++ codebases (as well as with neat nicely designed projects but few of these and more of the nightmare ones)
  4 2014-05-12 00:01:50 <sipa> yeah, c++ has so many features that based on which ones you favor, you tend to get very different coding styles
  5 2014-05-12 00:01:58 <sipa> which is a bad thing, imho
  6 2014-05-12 00:02:25 <GAit> and refactoring takes more time imho than with other langs
  7 2014-05-12 00:02:40 <sipa> ever tried refactoring perl? :p
  8 2014-05-12 00:02:47 <GAit> gdb can be flacky too
  9 2014-05-12 00:02:48 <GAit> yes, and i failed
 10 2014-05-12 00:02:53 <sipa> haha!
 11 2014-05-12 00:03:55 <GAit> i was given a job to refactor some perloid or reimplement it in java because it was leaking like mad. I eneded up splitting and creating an new process regularly so it would clear the memory on exit. I just couldn't understand what it did. Lots of regexes and shifts and implicit perl stuff from a non programmer
 12 2014-05-12 00:04:17 <GAit> grown over 5 years at some company
 13 2014-05-12 00:04:24 <GAit> oh yeah it was a log parser
 14 2014-05-12 00:04:39 <sipa> 
ACTION -> zZzZ

 15 2014-05-12 00:04:41 <AndyOfiesh> I heard that there is a way to disable difficulty checks on an Testnet in a Box. What's the trick?
 16 2014-05-12 00:04:56 <sipa> you mean -regtest
 17 2014-05-12 00:06:09 <AndyOfiesh> perhaps, I'm just trying to generate enough blocks to write some tests against without wating a day
 18 2014-05-12 00:06:43 <GAit> AndyOfiesh: yeah you want to run regtest and setgenerate true
 19 2014-05-12 00:07:01 <AndyOfiesh> Thanks for the tip, I will try that
 20 2014-05-12 00:24:54 <Forex> hello
 21 2014-05-12 00:45:37 <fun> hi, where I can find formula to derive diff from hashrate ? :)
 22 2014-05-12 00:46:45 <fun> so far i found formula to calc nr of hashesh needed to solve 1 block at diff D  D *2**32 / 600
 23 2014-05-12 00:46:47 <fun> :)
 24 2014-05-12 00:55:03 <fun> ok got it
 25 2014-05-12 00:55:03 <fun> ty
 26 2014-05-12 00:55:04 <fun> :d
 27 2014-05-12 01:23:59 <saizai> do BF people hang out here?
 28 2014-05-12 01:25:09 <gwillen> saizai: I don't think they do regularly, but it's possible some are lurking
 29 2014-05-12 01:25:18 <saizai> gwillen: *nod*
 30 2014-05-12 01:25:40 <saizai> I sent gavin, jon, & peter an email, but it’d be nice to talk to them directly
 31 2014-05-12 01:26:46 <gwillen> saizai: gavin appears on IRC periodically though he doesn't appear to be here now
 32 2014-05-12 01:26:54 <saizai> 
ACTION nods

 33 2014-05-12 01:26:59 <saizai> I’ve talked with him before
 34 2014-05-12 01:27:01 <gwillen> saizai: the others probably not as much, as far as I know
 35 2014-05-12 01:27:02 <gwillen> 
ACTION nods

 36 2014-05-12 01:27:32 <saizai> well, hopefully they read their email
 37 2014-05-12 01:41:11 <GAit> what do you guys think about http://article.gmane.org/gmane.comp.bitcoin.devel/5352 , amending bip0070 to add Access control allow origin ?
 38 2014-05-12 01:42:20 <GAit> guys or girls of course
 39 2014-05-12 02:15:15 <legerde> Im reading about the payment protocol.   I was pointed to look at this earlier today if I wanted to have refund addresses.  My question is the status of the payment protocol.  I see that bitcoin-qt supposedly supports/will support this.
 40 2014-05-12 02:15:39 <legerde> What kind of merchant support exists for the payment protocol?
 41 2014-05-12 02:16:30 <legerde> I guess I am hoping for a pre-existing python library to jump start this support for me.
 42 2014-05-12 02:16:47 <survic> bitpay supports it, as does bitcoin core
 43 2014-05-12 02:17:20 <legerde> By bitcoin core I assume you are talking about bitcoind daemon with json-rpc?
 44 2014-05-12 02:19:44 <survic> bitcoin core is the GUI (previously Bitcoin-QT)
 45 2014-05-12 02:20:34 <legerde> Thank you.   Ill go look into that.  I am hoping to figure out how to make a payment request from python.
 46 2014-05-12 02:26:01 <uiop> "bitcoin core" is the gui?! (?)
 47 2014-05-12 02:31:07 <survic> that was my understanding. QT was rebranded to Core, bitcoind stays bitcoind
 48 2014-05-12 02:31:22 <uiop> ah, gotcha.
 49 2014-05-12 02:57:14 <survic> has there ever been a push by the core developers to hide key importing and exporting tools from user view a bit more?
 50 2014-05-12 02:58:03 <gwillen> survic: I definitely recall it being discussed.
 51 2014-05-12 02:58:08 <survic> this is the second time today that I've had to help somebody out with disaster recovery due to the bitcoin core wallet and blockchain.info making the tools a little bit too user friendly.
 52 2014-05-12 02:58:19 <survic> total loss, around 26BTC.
 53 2014-05-12 02:58:38 <gwillen> This comes up periodically, and I think a number of people agree that it would be good to hide that behind an 'advanced' setting.
 54 2014-05-12 02:58:58 <survic> it's maddening because I can't help any of these people
 55 2014-05-12 02:59:12 <gwillen> :-(
 56 2014-05-12 02:59:12 <survic> yeah sorry, you just fucked up and lost $10,000
 57 2014-05-12 02:59:24 <gwillen> survic: are these "paper wallet" cases?
 58 2014-05-12 02:59:24 <survic> why was the tool there for me to use then?
 59 2014-05-12 02:59:30 <gwillen> survic: import, transfer, destroy?
 60 2014-05-12 03:00:05 <survic> gwillen: no, people wanting to micro manage funds. there's probably some guide or tutorial telling people that if they export the private key that it's safe forever.
 61 2014-05-12 03:00:39 <gwillen> huh, that one's new to me.... usually this comes up because people put all their funds in a paper wallet, import it, send something, and then assume the rest is still 'in' the original address (not understanding change addresses) and destroy the wallet that did the import
 62 2014-05-12 03:01:00 <survic> I know that one, I've done one of those too.
 63 2014-05-12 03:01:03 <gwillen> :-(
 64 2014-05-12 03:01:07 <buZz> ppl dont get the difference between accounts and addresses
 65 2014-05-12 03:01:20 <gwillen> I think removal of 'accounts' has also been discussed
 66 2014-05-12 03:01:25 <survic> 6BTC today was somebody misunderstanding which key is the private key and importing it as a watch only wallet into blockchain.info.
 67 2014-05-12 03:01:36 <gwillen> because they are purely an account tool, and do not correspond to addresses in any way, and this confuses the shit out of people
 68 2014-05-12 03:01:40 <gwillen> accounting tool*
 69 2014-05-12 03:01:51 <gmaxwell> survic: they're pretty hidden now, there is no GUI for them! :(
 70 2014-05-12 03:01:57 <survic> no sorry, you can see your funds there but you'll never be able to spend them again. that's $3000 and all of your money down the hole.
 71 2014-05-12 03:02:07 <buZz> gwillen: but i like them as accounting tool :(
 72 2014-05-12 03:02:14 <gwillen> survic: hm, per gmaxwell's comment, is it possible they were using an old version of the client?
 73 2014-05-12 03:02:30 <gwillen> buZz: but as you say, people don't understand them at all
 74 2014-05-12 03:02:44 <buZz> yeah ..
 75 2014-05-12 03:02:48 <gwillen> buZz: people assume that you put an address in an account, and when you spend from that account you spend from that address
 76 2014-05-12 03:03:07 <gmaxwell> we've never exposed import/export in the GUI, except by opening the debugging console, specifically because its such a footgun.
 77 2014-05-12 03:03:15 <survic> gmaxwell: no, there's the developer console and that's enough. people will follow instructions from bitcointalk and lose their funds through that. I know it's useful to have it there for the developers, but make a switch for it at compile time or something?
 78 2014-05-12 03:03:36 <buZz> its hard to explain to ppl how you dont have the same 'from' address everytime
 79 2014-05-12 03:03:36 <gmaxwell> maybe if it gave you more of a warning that it was dangerous?
 80 2014-05-12 03:03:52 <survic> please.
 81 2014-05-12 03:04:30 <gmaxwell> buZz: it's mostly hard because of things like blockexplorer presenting things as though there were from addresses at all. If they didn't it's pretty easy to accept "bitcoin transactions don't have a from field".
 82 2014-05-12 03:04:38 <gmaxwell> survic: Hm. Not quite sure how to do that. :-/
 83 2014-05-12 03:05:47 <survic> gmaxwell: big red letters in the console. USING THIS COMMAND WILL CAUSE YOU TO LOSE YOUR FUNDS IF OPERATED INCORRECTLY. type "yes I want to shoot myself in the ass" to enable this command.
 84 2014-05-12 03:05:56 <gwillen> survic: you know people will do it anyway
 85 2014-05-12 03:06:08 <gwillen> survic: although I agree with making them type out "I am aware that etc."
 86 2014-05-12 03:06:11 <survic> it'll stop people from thinking it's a normal action to be doing.
 87 2014-05-12 03:06:14 <gwillen> 
ACTION nods

 88 2014-05-12 03:06:35 <survic> people think this is some causal action. aw yeah just moving this key. they don't know how dangerous it is.
 89 2014-05-12 03:06:40 <gwillen> 
ACTION nods

 90 2014-05-12 03:06:56 <gmaxwell> They even follow instructions for this stuff, written by people who are also invinciple educatiors of spherical infinitely attentive genuises.
 91 2014-05-12 03:07:04 <gwillen> survic: where does the actual loss come in (other than for the watch-only guy, which I understand) -- export a key, then delete the rest of the wallet?
 92 2014-05-12 03:07:36 <gwillen> gmaxwell: it's like the git tutorials that throw around "reset --hard" as though it was a totally normal thing to be doing
 93 2014-05-12 03:07:39 <gwillen> gmaxwell: drives me insane
 94 2014-05-12 03:08:20 <survic> gwillen: yep. export the private keys, make a backup of one of them after being told that wallets only need one private key, then blast the wallet from the face of the earth
 95 2014-05-12 03:08:33 <buZz> maybe the gui could just show the amount of keys the wallet holds
 96 2014-05-12 03:09:09 <gwillen> survic: so perhaps it would _specifically_ help to have the developer console make you type out "I understand that it is always a bad idea to delete a wallet even if I think it has no funds in it, even if someone on the Internet told me to" :-P
 97 2014-05-12 03:09:24 <gwillen> survic: that seems to be the specific common failure mode in most or all of these
 98 2014-05-12 03:09:52 <survic> no, that's not enough. it needs to say that messing with private keys is dangerous no matter what the situation.
 99 2014-05-12 03:10:04 <gmaxwell> there really should be some wallet surrender service or something where you don't delete your wallet, you surrender it... and then you can get it back for N hours (and after that any other funds go to the service). :)
100 2014-05-12 03:10:05 <gwillen> well, the problem is, if your warning is too generic people will ignore it
101 2014-05-12 03:10:09 <buZz> if ppl just see in the status bar that it has 893742 keys, it would make them secondguess if they exported the right one
102 2014-05-12 03:10:22 <uiop> survic: wow, 26btc. that sucks. how did the user do it? thought he exported private key, erased data, realized had not in fact exported private key?
103 2014-05-12 03:10:23 <gwillen> your warning needs to be specific enough that people think it applies to them
104 2014-05-12 03:10:27 <survic> this is a $13,000 lesson. it had better be a fucking good message.
105 2014-05-12 03:10:34 <gwillen> if they think they know better they'll just click through
106 2014-05-12 03:10:50 <gwillen> but if the warning specifically mentions something they're about to do, and the reason they're about to do it, they might pause
107 2014-05-12 03:10:55 <survic> uiop: two different incidents. that, and messing up with watch only addresses.
108 2014-05-12 03:11:54 <gwillen> survic: I think one possible good message amounts to "you should not ever delete a wallet; if you think you want to delete a wallet, you are wrong; here is a wiki page about why you should never delete a wallet, even if you think it's empty"
109 2014-05-12 03:12:03 <gmaxwell> I've seen pepole make the watch only mistake before.  Though in that case they copy and pasted the address out of the address book into a bc.i wallet, saw the funds show up... and deleted their qt wallet. No privkey import/export involved.
110 2014-05-12 03:12:16 <gwillen> I mean, some people you just can't help
111 2014-05-12 03:12:24 <jcorgan> meh.  ultimately you can't save determined people from themselves.
112 2014-05-12 03:12:27 <gwillen> and if they never open the console it's hard to imagine how you could warn them
113 2014-05-12 03:12:47 <survic> eh. why have we got a culture where people ever see the private keys? it's ridiulous
114 2014-05-12 03:12:49 <gmaxwell> well it's not the indiviugal people, in general this stuff is more of a hazard than it could be; and importantly way more of a hazard than anything in traditional banking is.
115 2014-05-12 03:12:53 <gwillen> I do think that making someone type out a message is one of the few ways to ACTUALLY get them to think about your warning before they use the console
116 2014-05-12 03:13:02 <gwillen> any message you SHOW them will go in one ear and out the other
117 2014-05-12 03:13:11 <gwillen> but if you make them type it out, you have one chance to actually reach them
118 2014-05-12 03:13:15 <andytoshi> will the payment protocol require x509 keys and stuff, or will normal people be able to send money to each other with it?
119 2014-05-12 03:13:20 <gwillen> so I think that's probably a good gate to put on the dev console
120 2014-05-12 03:13:26 <andytoshi> i.e. can we move toward a situation where nobod ever sees addresses
121 2014-05-12 03:13:30 <gmaxwell> gwillen: I mean people try to do things I think are really inadvisable so agressively that they write software to do it... dunno that harder warning messages help.
122 2014-05-12 03:13:40 <survic> gwillen: agreed. it needs a situation where they have to type out the footgun line.
123 2014-05-12 03:13:58 <gmaxwell> andytoshi: they aren't required. But you can't really use it to recieve payments without a webserver and the skill to use it.
124 2014-05-12 03:14:03 <gwillen> gmaxwell: I mean, for reference, I have -- in scripts I wrote _for myself_ to use -- done the "make the user type a message" trick
125 2014-05-12 03:14:07 <andytoshi> every time i've had to type a footgun line, i've typo'd it and then i was extra careful :)
126 2014-05-12 03:14:09 <gwillen> it really does force you to stop and think about what your'e doing
127 2014-05-12 03:14:11 <survic> if you want me to have a shot at your other wallet with the forgotten password, we can do that but only under the following conditions.
128 2014-05-12 03:14:14 <survic> uh
129 2014-05-12 03:14:19 <gwillen> I like the phrase "footgun line" for this technique
130 2014-05-12 03:14:21 <gmaxwell> (well I suppose you can carry around payment requests as files, but none of the software sets it up to make that easy right now)
131 2014-05-12 03:14:22 <survic> wrong window.
132 2014-05-12 03:14:33 <midnightmagic> well. one more reason not to bother using the gui :)
133 2014-05-12 03:14:48 <andytoshi> gmaxwell: would PRs to the effect of making bitcoin core be such a server be considered?
134 2014-05-12 03:15:10 <gwillen> survic: anyway, I'd encourage you to write a patch adding a footgun prompt to the dev console; I'm not a bitcoin dev but I'd help you push for inclusion, and tune the wording of the message
135 2014-05-12 03:15:15 <gmaxwell> make it be a public facing webserver errrr... uh. fork() one, perhaps.
136 2014-05-12 03:16:03 <andytoshi> actually scrap that, i think this is one of those things where we want alternate wallets to do it first so we can learn the UI stuff
137 2014-05-12 03:16:17 <gmaxwell> gwillen: you can make them think but they think they understand. In any case, I'm fine with adding more warnings but there isn't an obvious clean way to do it here. I don't really want to put a nasty warning over the whole debug console, as its how you get to things like getinfo. And beyond that its just an RPC interface.
138 2014-05-12 03:16:28 <survic> gwillen: I'll out some thought into it.
139 2014-05-12 03:16:47 <gwillen> gmaxwell: *sigh*, yeah... hmm.
140 2014-05-12 03:16:59 <gwillen> Perhaps an extra prompt for import/export? Not sure. :-\
141 2014-05-12 03:17:00 <gmaxwell> andytoshi: you also have to consider the MITM vulnerability.
142 2014-05-12 03:17:08 <andytoshi> gmaxwell: yeah :/
143 2014-05-12 03:17:23 <uiop> 
ACTION is reminded of the classic "sudo rm -rf /<SPACE>etc/blah.txt"  #oh shit!

144 2014-05-12 03:17:28 <gwillen> gmaxwell: thinking they understand is not a binary thing... the more you can reach the better
145 2014-05-12 03:17:41 <gwillen> gmaxwell: but I understand about not making safe operations require you to jump through hoops
146 2014-05-12 03:17:57 <andytoshi> gwillen: maybe there should be a hidden field in the RPC interface to indicate that the debug window is being used, and this would enable more agressive help text and extra required footgun texts
147 2014-05-12 03:18:48 <gwillen> andytoshi: well, but now that the RPC interface has been mentioned, I realize that that is a whole _other_ footgun people can use, with no prompting
148 2014-05-12 03:18:57 <gwillen> andytoshi: it's not really any harder than using the console
149 2014-05-12 03:19:14 <andytoshi> i think it's harder
150 2014-05-12 03:19:27 <gwillen> so I guess we have one thing going for us here, which is that the tutorials are not adversairal
151 2014-05-12 03:19:29 <gmaxwell> the problem is that the risk with the private key handling is a bit abstract. It's not like a nice concrete risk like "showing this data on your screen will enable nsa brainwave monitors to see it"... it's more that "in our expirence, people, even expirenced, ones make boneheaded moves that start out with this step. Statistically, doom is likely in your future if you continue." To which the user thinks "okay, I won't make any boneheaded ...
152 2014-05-12 03:19:30 <andytoshi> you have to open a command shell for one, figure out where the bitcoind binary is for another
153 2014-05-12 03:19:36 <gmaxwell> ... moves."
154 2014-05-12 03:19:53 <gmaxwell> we have the console because using the rpc was basically impossibly hard for a lot of windows and mac users. :)
155 2014-05-12 03:19:55 <gwillen> gmaxwell: so this is why I was focusing on warning against the specific act of deleting a wallet, and asserting that it is never a correct operation
156 2014-05-12 03:20:01 <andytoshi> uiop: i remember coming home from school one day and my dad said, "i think i broke your computer... i accidentally deleted /usr/share/..."
157 2014-05-12 03:20:11 <andytoshi> and he said it as though he thought the computer might still work :)
158 2014-05-12 03:20:13 <gwillen> gmaxwell: because as far as I know it's not, AND it's a very concrete action, which people can _see_ why it would be dangerous
159 2014-05-12 03:20:22 <gwillen> gmaxwell: all in contrast to key import/export, which is harder to see the risk of
160 2014-05-12 03:20:29 <gmaxwell> yes, I agree with that. Though survic points out that the risk isn't limited to that.
161 2014-05-12 03:20:42 <gwillen> what was the other risk that didn't involve deleting a wallet?
162 2014-05-12 03:21:05 <gwillen> I think both of survic's cases were wallet deletions, it's just that the means by which the user convinced themselves it was ok was different in each case
163 2014-05-12 03:21:07 <gmaxwell> There are a bunch, A fun one from an expirenced user around here was that they _imported_ a private key from some random source. Then later picked an address from the address book to have someone else send funds to... and the funds vanished.
164 2014-05-12 03:21:16 <gwillen> .... D:
165 2014-05-12 03:21:20 <survic> gmaxwell: importing an address as watch-only is one.
166 2014-05-12 03:21:21 <gwillen> okay, _that_ is a footgun I had forgotten about
167 2014-05-12 03:21:27 <gmaxwell> (we've reduced that risk by making it harder to reuse addresses in the UI)
168 2014-05-12 03:21:58 <gwillen> you could treat showing the address of an imported key as a dangerous action that requires a warning
169 2014-05-12 03:22:02 <gwillen> but that one's really abstract :-\
170 2014-05-12 03:22:29 <survic> (anybody reading the logs and saw my /window mess up before, I decided not to help the user out with the password, I redirected them to walletrecoveryservices.com rather than take on any personal risk)
171 2014-05-12 03:22:33 <gmaxwell> really depends on where that came from, I think we've mostly done enough there... and mostly surrived the complaints for making the address reuse workflow harder.
172 2014-05-12 03:22:36 <uiop> andytoshi: at least it wasn't /home
173 2014-05-12 03:22:51 <andytoshi> uiop: yeah, that was exactly my thought
174 2014-05-12 03:23:28 <gmaxwell> gwillen: I've seen people get robbed by exporting private keys and pasting them in evil websites. ("turn your private key into a QR code! encrypted!")
175 2014-05-12 03:23:47 <ganjafarmer> is there a bootstrap.dat for testnet3?
176 2014-05-12 03:23:49 <survic> gmaxwell: now that's a footgun.
177 2014-05-12 03:23:54 <gwillen> uiop: I once accidentally did a recursive chown of /home on a multiuser system
178 2014-05-12 03:23:57 <gwillen> uiop: that was a bad day
179 2014-05-12 03:24:14 <gmaxwell> ganjafarmer: why would there be? the testnet data weighs in at about 2gb or so.
180 2014-05-12 03:24:14 <gwillen> that was the day I learned that you never operate on .*
181 2014-05-12 03:24:36 <gwillen> gmaxwell: sigh :-\
182 2014-05-12 03:24:48 <ganjafarmer> gmaxwell: im about 2 hours into syncing and have 50 more weeks to go. just hoping to speed it up.
183 2014-05-12 03:24:50 <andytoshi> here's an analogy that i like (though i'm very tired) "your wallet is a cup of rice. you have to keep every rice secret and you can't ever lose any. don't take the lid of the damn rice"
184 2014-05-12 03:24:50 <gmaxwell> hehe .foo .bar . .. .baz. :P
185 2014-05-12 03:24:53 <gwillen> gmaxwell: I feel like "never share your private keys with anybody is another _relatively_ concrete thing to warn about
186 2014-05-12 03:24:53 <survic> can you show me a screenshot / the text near where you are asked for this?
187 2014-05-12 03:24:56 <survic> ahhh
188 2014-05-12 03:24:57 <gwillen> gmaxwell: yep!
189 2014-05-12 03:25:01 <survic> I really need to fix my bindings.
190 2014-05-12 03:25:16 <gwillen> survic: heh!
191 2014-05-12 03:25:21 <gmaxwell> gwillen: "I totally didn't give it to a person, I put it in this QR generator app"
192 2014-05-12 03:25:27 <gwillen> gmaxwell: yeah, I know, I know
193 2014-05-12 03:25:37 <gwillen> gmaxwell: people are idiots, news at 10
194 2014-05-12 03:25:47 <uiop> gwillen: ouch. did you just "chmod 777 -R /home" and pretend it never happened? :)
195 2014-05-12 03:25:50 <survic> I keep hitting an old shortcut for window changes which does nothing and then I spurt irrelevant crap into the wrong channel
196 2014-05-12 03:26:05 <gmaxwell> not idiots; rationally ignorant, but with hurestics which are ill fit for bitcoin at its current state of maturity.
197 2014-05-12 03:26:05 <gwillen> uiop: haha, no, I was a student network admin... I was tasked with fixing them one by one
198 2014-05-12 03:26:14 <gwillen> uiop: there were only dozens of users in total and I stopped it pretty fast
199 2014-05-12 03:26:47 <gmaxwell> the real idiots have not yet, for the most part, found bitcoin. god help us.
200 2014-05-12 03:26:49 <gwillen> uiop: some of them may have ended up with wrong-owner files, but since you can't chown-away files on Solaris, I assumed that in general all the contents of someone's homedir should be owned by them, and chowned it all back
201 2014-05-12 03:27:05 <survic> gmaxwell: private keys should NEVER be shown to a user.
202 2014-05-12 03:27:31 <gwillen> survic: this is the import/export feature in the console, though -- unless you take it away entirely, people will find it
203 2014-05-12 03:27:34 <gmaxwell> survic: there are important recovery tasks where we need to get to them. They're not in the regular UI for a reason.
204 2014-05-12 03:27:41 <gwillen> and this is actually a case where the tutorial IS adversarial, right
205 2014-05-12 03:27:57 <gwillen> in the bitcointalk case where the tutorial writer is just stupid, making it hard enough will make it stop
206 2014-05-12 03:28:03 <gwillen> but when the tutorial writer is actually malicious...
207 2014-05-12 03:28:05 <gmaxwell> all handcapping it further will do is drive people to software will less socially responsible authors who won't care about this stuff at all.
208 2014-05-12 03:28:18 <gwillen> gmaxwell: now _that_ I don't htink is true
209 2014-05-12 03:28:23 <survic> gmaxwell: that's not what I mean. brainwallt.org/blockchain.org/bitaddress.org all show private keys and expect users to micro manage them. it's shown as a common thing to want to do.
210 2014-05-12 03:28:25 <uiop> gwillen: ah yeah, chown on /home wouldn't be that bad
211 2014-05-12 03:28:36 <gwillen> for better or for worse, people do not pick software based on whether obscure features are good or easy to use, they pick based on whether it's shiny
212 2014-05-12 03:28:44 <gwillen> taking away key import/export will not change the distribution of wallet software at all
213 2014-05-12 03:28:48 <gmaxwell> Right, but ... well, you know my opinions there.
214 2014-05-12 03:29:09 <gmaxwell> (to survic)
215 2014-05-12 03:29:12 <gwillen> 
ACTION ndo

216 2014-05-12 03:29:22 <gwillen> uiop: yeah, it was not nearly as bad as it could have been
217 2014-05-12 03:29:26 <survic> gmaxwell: I do.
218 2014-05-12 03:29:35 <gwillen> uiop: I have only unix-footgunned badly about three times in my life, which honestly I'm pleased with how low that is
219 2014-05-12 03:29:58 <survic> gwillen: bet one was with 'dd'
220 2014-05-12 03:30:12 <gwillen> ha, no, I have never footgunned with dd, because I would never run a dd without checking it thrice
221 2014-05-12 03:31:02 <gwillen> the other two were an 'rm' that I mistyped at a stupid hour ("let's see, I want to remove the class files from my java project before I hand it in... rm *.java") and a truncated mv ("mv file1 file2 <ENTER>"... oops I forgot the destination dir.)
222 2014-05-12 03:31:57 <survic> I did sudo rm -rf --no-preseve-root / on a production server because I got the wrong shell. that's probably my worst, but no where near $13k in damages. just red faces all around and a quick restore from backup.
223 2014-05-12 03:32:19 <gmaxwell> oh I've done the "destination directory omitted" thing before. Also the cat input | long pipeline | > input  ... why is the result zero bytes?
224 2014-05-12 03:32:47 <uiop> gmaxwell: i hate that one.
225 2014-05-12 03:33:01 <uiop> (dest dir omitted)
226 2014-05-12 03:33:14 <andytoshi> my favorite is doing the up-up-enter dance to switch between vi and make, then i cp template.c real-work.c
227 2014-05-12 03:33:29 <gmaxwell> in my dos days I'd found some probably malicious com file and set it aside for disassembly.. and then a week later forgot what it was and ran it... disk light went on and after a second I hit the power button.. it apparently had started zeroizing my disk... :-/ got it pretty early though.
228 2014-05-12 03:33:30 <andytoshi> edit real-work.c, then hit up-up-enter to compile, and overwrite all my work
229 2014-05-12 03:34:28 <gmaxwell> andytoshi: I have the switch set so that prefacing commands with space keeps them out of my history and I use them a lot to reduce that mistake. though it leads to a fancy version when I up enter and get the command before last and am unhappy with the result.
230 2014-05-12 03:34:35 <uiop> omg, <up>..<up><enter> is good too
231 2014-05-12 03:35:01 <uiop> 
ACTION 's going to make a list of these, "how to shoot youself in the foot on unix/in sh"

232 2014-05-12 03:35:27 <survic> anyway, back to the original discussion I might raise an issue on Github if nobody else has already.
233 2014-05-12 03:36:19 <gwillen> gmaxwell: hahaha, yeah, I've done the > one but never on live valuable data
234 2014-05-12 03:36:24 <gwillen> gmaxwell: I learned that one early
235 2014-05-12 03:36:30 <uiop> an easy way to verify privkey exports might go a long way
236 2014-05-12 03:37:13 <gmaxwell> survic: please do, though I'm not sure exactly what we can do. maybe just special case some the commands in the console to spit out an extra warning.
237 2014-05-12 03:37:29 <gwillen> I have up-entered the wrong command before, but never yet a dangerous one... it's only a matter of time probably though
238 2014-05-12 03:37:32 <gmaxwell> uiop: I don't think I've personally encountered a case where that would help.
239 2014-05-12 03:37:48 <gwillen> survic: gmaxwell: whatever the solution I would encourage an actual prompt and not just a warning, so that people actually read whatever it is you come up with
240 2014-05-12 03:37:56 <gmaxwell> gwillen: I've upentered to a git reset hard and spent a while fixing that. :P
241 2014-05-12 03:38:01 <gwillen> :-(
242 2014-05-12 03:38:20 <gwillen> at least there you have the reflog
243 2014-05-12 03:38:25 <gwillen> so you mostly don't actually loe
244 2014-05-12 03:38:26 <gmaxwell> yep
245 2014-05-12 03:38:27 <gwillen> lose*
246 2014-05-12 03:38:45 <gwillen> it amazes me how cavalier people are about the reflog, though; I kind of try not to rely on it
247 2014-05-12 03:39:06 <uiop> gmaxwell: one of survic's two recent losses resulted from "thought i exported it but didn't, then deleted orig data" i thought. it'd help there at least
248 2014-05-12 03:41:21 <survic> what's the export private keys RPC command?
249 2014-05-12 03:41:22 <uiop> 
ACTION is as usual suggesting features he's not offering to code :)

250 2014-05-12 03:41:58 <survic> dumpprivkey
251 2014-05-12 03:42:44 <gmaxwell> survic: did they even run dumpprivkey in that recent case?
252 2014-05-12 03:43:01 <gmaxwell> or did they just copy the address from the address book (which is something I've seen people do)
253 2014-05-12 03:43:26 <survic> gmaxwell: second one did the "watch wallet" thing with the address book
254 2014-05-12 03:43:34 <survic> I think. it's not clear.
255 2014-05-12 03:44:27 <andytoshi> from an education perspective, should we talk about addresses and key material as though they are not really related?
256 2014-05-12 03:44:34 <andytoshi> i.e. addresses are just payment identifiers
257 2014-05-12 03:44:50 <gmaxwell> So thats an exposing users to _addresses_ issue, not privkey issue.
258 2014-05-12 03:45:50 <survic> gmaxwell: first one was a privkey issue.
259 2014-05-12 03:47:42 <survic> oh
260 2014-05-12 03:48:47 <gmaxwell> Too bad addresses don't begin with 'Invoice' instead of '1' or '3'. :P
261 2014-05-12 03:49:06 <gwillen> heh!
262 2014-05-12 03:52:07 <phantomcircuit> gmaxwell, lol
263 2014-05-12 03:52:13 <phantomcircuit> just change the client to accept that!
264 2014-05-12 03:52:17 <phantomcircuit> magic
265 2014-05-12 03:52:31 <[\\\]> We should just do away with private keys, then people can't lose them.
266 2014-05-12 03:52:42 <survic> gmaxwell: issue raised.
267 2014-05-12 03:53:44 <sidneyz> I am thinking about distributed identity with a proof of burn
268 2014-05-12 03:53:47 <sidneyz> wanted to get your thoughts
269 2014-05-12 03:53:54 <sidneyz> https://keybase.io/ looks good
270 2014-05-12 03:53:54 <uiop> [\\\]: https://lkml.org/lkml/2012/3/31/131
271 2014-05-12 03:54:03 <sidneyz> but if we add a proof of burn on the blockchain
272 2014-05-12 03:54:13 <uiop> [\\\]: "In short, for the ultimate in computer-system simplicity, the optimal choice is NR_CPUS=0."
273 2014-05-12 03:54:19 <uiop> classic
274 2014-05-12 03:54:31 <sidneyz> plus make the publickey storage embedded in the blockchain via an OP_RETURN
275 2014-05-12 03:54:38 <sidneyz> in the same transaction as the proof of burn
276 2014-05-12 03:54:47 <sidneyz> do you think we can have a better system than keybase.io
277 2014-05-12 03:54:49 <sidneyz> thoughts?
278 2014-05-12 04:05:31 <gwillen> sidneyz: what's the need for proof of burn? Why not just sign something with a bitcoin key?
279 2014-05-12 04:06:00 <gwillen> sidneyz: by 'burn' do you mean an actual destruction of coins, or just a visible self-transfer, which would be sufficient to establish ownership of an address?
280 2014-05-12 04:30:03 <sidneyz> hey gwillen
281 2014-05-12 04:30:14 <sidneyz> I was thinking about proof of burn because (actual destruction of coins)
282 2014-05-12 04:30:25 <sidneyz> because it prevents farming of identity
283 2014-05-12 04:30:41 <sidneyz> and with a reliable identity system as a base then I can foresee a far more reliable reputation system being built on top of it
284 2014-05-12 04:31:10 <sidneyz> some ideas that I have been tossing with it, sending coins to an unspendable address and then OP_RETURN chains usename or something like that
285 2014-05-12 04:32:53 <petertodd> sidneyz: OP_RETURN *is* your unspendable address
286 2014-05-12 04:33:04 <sidneyz> but that didn’t burn any coins
287 2014-05-12 04:33:11 <sidneyz> oh well
288 2014-05-12 04:33:13 <sidneyz> I can attach value to it
289 2014-05-12 04:33:17 <gwillen> survic: can you explain what you mean by farming, and what coin-burning does for you?
290 2014-05-12 04:33:25 <petertodd> sidneyz: your OP_RETURN txout can itself have a value
291 2014-05-12 04:33:29 <sidneyz> right!
292 2014-05-12 04:33:37 <sidneyz> that’s good.
293 2014-05-12 04:33:47 <sidneyz> well I was thinking about twitter / ebay etc
294 2014-05-12 04:34:01 <sidneyz> identity can be farmed pretty cheaply by outsourcing to mechanical turks
295 2014-05-12 04:34:05 <sidneyz> just sign up lots of accounts
296 2014-05-12 04:34:14 <sidneyz> when you burn coins, it makes each account pretty expensive
297 2014-05-12 04:34:25 <petertodd> sidneyz: yeah, that's called a fidelity bond
298 2014-05-12 04:34:40 <sidneyz> I was looking at keybase.io
299 2014-05-12 04:34:45 <sidneyz> I was thinking a fidelity bond with that
300 2014-05-12 04:34:49 <sidneyz> would be perfect
301 2014-05-12 04:34:52 <gwillen> sidneyz: so let me suggest instead of burning, spending in transaction fees
302 2014-05-12 04:34:58 <sidneyz> oh right
303 2014-05-12 04:34:59 <sidneyz> yeah
304 2014-05-12 04:35:01 <sidneyz> that’s good
305 2014-05-12 04:35:12 <petertodd> gwillen: no, that's very, very bad
306 2014-05-12 04:35:15 <gwillen> sidneyz: but otherwise I do see what you mean about making identities expensive, and it's a good idea, although you may want to scale the amount dynamically somehow? But then again maybe not.
307 2014-05-12 04:35:17 <sidneyz> transaction fee is not better?
308 2014-05-12 04:35:19 <gwillen> petertodd: oh, why?
309 2014-05-12 04:36:06 <petertodd> gwillen: see my announce/commit fidelity bond scheme for the closest you can do to "burn to fees", but frankly even that isn't a good idea because it encourages mining pools to get bigger
310 2014-05-12 04:36:48 <gwillen> petertodd: can you link your scheme here? It sounds like something sidneyz and I would both be interested in reading
311 2014-05-12 04:36:57 <sidneyz> yes please
312 2014-05-12 04:37:00 <sidneyz> I would like to read that too
313 2014-05-12 04:37:07 <petertodd> gwillen: it's on the wiki under fidelity bonds, but really, it's a bad idea, just burn coins
314 2014-05-12 04:38:00 <sidneyz> attaching OP_RETURN is better because at least it prunable
315 2014-05-12 04:38:09 <sidneyz> whereasa address is there foreever
316 2014-05-12 04:42:19 <sidneyz> I want to know maybe it is better to do something else for identity instead of embedding it into the blockchain?
317 2014-05-12 04:42:28 <sidneyz> I feel fidelity bond is a good idea
318 2014-05-12 04:42:51 <gwillen> well, you don't actually have to embed it; you can do the fidelity bond with an address, then use that address to sign a proof or something, and put the proof in a sidechain
319 2014-05-12 04:42:51 <sidneyz> any examples where this is actually implemented?
320 2014-05-12 04:43:08 <petertodd> well you have to burn coins, so yeah, just do OP_RETURN <Hash(identity)>
321 2014-05-12 04:43:09 <gwillen> so you don't actually have to put anything into the bitcoin blockchain itself other than the burn
322 2014-05-12 04:43:40 <sidneyz> do you know any examples where it is implemented? I woud like to study it a bit more
323 2014-05-12 04:43:42 <gwillen> I mean, what do you put in for 'identity'? If it's a GPG key, why not just use the bitcoin privkey itself as the identity instead?
324 2014-05-12 04:43:52 <petertodd> sidneyz: it's not implemented anywhere
325 2014-05-12 04:44:21 <gwillen> If it's a Wallet Name (TM), not a good idea to tie that directly to the bond, since you may want to change it later and it would be annoying and costly to have to rebond
326 2014-05-12 04:44:27 <petertodd> gwillen: no, please don't, just commit to the GPG fingerprint so standard privkey securing techniques work
327 2014-05-12 04:44:47 <gwillen> what do you mean by 'standard privkey securing techniques'
328 2014-05-12 04:45:06 <petertodd> gwillen: e.g. I have a PGP smartcard - using a bitcoin privkey is a severe reduction in security for me
329 2014-05-12 04:45:26 <gwillen> that's a good approach if you do it, I agree
330 2014-05-12 04:45:55 <gwillen> and I suppose signing a chained pubkey with the bitcoin key enables you to use a corresponding privkey that was securely generated, in the general case
331 2014-05-12 04:46:00 <Belxjander> petertodd: could you setup a wallet where that pgp smartcard IS the private key ?
332 2014-05-12 04:46:00 <gwillen> whereas the bitcoin key almost surely was not
333 2014-05-12 04:46:26 <petertodd> Belxjander: sure - they're talking about a new PGP smartcard standard w/ bitcoin compatible ecdsa support
334 2014-05-12 04:46:40 <petertodd> gwillen: there's just no need to involve a bitcoin key at all
335 2014-05-12 04:46:42 <Belxjander> petertodd: yay
336 2014-05-12 04:47:07 <gwillen> petertodd: well, if you're bonding by destroying coins, there IS a bitcoin key involved, being the one that held the coins
337 2014-05-12 04:47:16 <survic> of the other wallet is it just that you don't know the case?
338 2014-05-12 04:47:18 <survic> arrgh
339 2014-05-12 04:47:22 <gwillen> petertodd: but I suppose merely putting the pgp pubkey fingerprint in the transaction is sufficient; you don't need any other operations with the bitcoin key
340 2014-05-12 04:47:26 <survic> !roulette
341 2014-05-12 04:47:27 <gribble> 
ACTION reloads and spins the chambers.

342 2014-05-12 04:47:40 <petertodd> gwillen: whose to say you were the one who actually paid for it directly?
343 2014-05-12 04:47:55 <petertodd> gwillen: besides, think about how you actually prove compactly that the fidelity bond exists...
344 2014-05-12 04:49:11 <gwillen> petertodd: I'm not a cryptographer nor a bitcoin dev, so proving things compactly is usually above my ability level...
345 2014-05-12 04:49:20 <SomeoneWeird> stahp
346 2014-05-12 04:49:34 <petertodd> gwillen: I'm a fine arts student, don't underestimate yourself :)
347 2014-05-12 04:49:37 <gwillen> hahahahah
348 2014-05-12 04:50:30 <gwillen> well, can you sketch for me what you mean? To someone who has a copy of the blockchain on hand, it would seem they don't need a proof because they should already have everything they need to know the key is bonded
349 2014-05-12 04:51:13 <petertodd> gwillen: basically the key thing you need to know is that a transaction itself only contains what scriptPubKeys it pays - it does *not* contain the scriptPubKeys it *spent*
350 2014-05-12 04:51:50 <petertodd> gwillen: secondly, you can use the merkle tree to show that a transaction existed in a block via the merkle tree (a merkle path)
351 2014-05-12 05:02:21 <phantomcircuit> <SomeoneWeird> stahp
352 2014-05-12 05:02:22 <phantomcircuit> wat
353 2014-05-12 05:12:03 <sidneyz> petertood I am trying to wrap my head around what you said about embedding pgp pubkey footprint
354 2014-05-12 05:12:14 <sidneyz> does that footprint go into the op_return?
355 2014-05-12 05:12:22 <petertodd> sidneyz: op_return <pgp fingerprint>
356 2014-05-12 05:12:48 <sidneyz> right
357 2014-05-12 05:12:48 <sidneyz> yeah
358 2014-05-12 05:13:42 <sidneyz> last question
359 2014-05-12 05:13:50 <sidneyz> isn’t it good to have miners to get the fees
360 2014-05-12 05:13:55 <sidneyz> as oppose to just burning it?
361 2014-05-12 05:14:33 <petertodd> sidneyz: no, because if you have 25% of the hashing power, it's 25% cheaper for you to sell fidelity bonds to someone else, incentivizing your mining pool to get bigger
362 2014-05-12 05:14:52 <sidneyz> I see
363 2014-05-12 05:14:57 <sidneyz> there is a higher incentive to centralize mining
364 2014-05-12 05:15:29 <petertodd> exactly
365 2014-05-12 05:15:43 <sidneyz> but why would someone be selling fidelity bond?
366 2014-05-12 05:15:54 <petertodd> because they can do it for 75% cheaper than you can
367 2014-05-12 05:15:55 <sidneyz> for example, I will just be attaching to a transaction fee?
368 2014-05-12 05:16:12 <petertodd> read my announce/commit sacrifices for the closest thing you can get to make that work
369 2014-05-12 05:16:15 <sidneyz> but if let’s say I am participant in the pool
370 2014-05-12 05:16:26 <sidneyz> I see
371 2014-05-12 05:16:29 <sidneyz> announce/commit sacrifices
372 2014-05-12 05:16:47 <petertodd> the point is the pool itself creates the bonds, knowing that it'll get the fees back by virtu of the fact that they get 25% of all fees
373 2014-05-12 05:20:11 <warren> phantomcircuit: clearly he is displeased with everything that we do
374 2014-05-12 05:22:44 <Eliel_> I think I'm starting to get why some designs divide fees over many blocks (reward averaging)
375 2014-05-12 05:23:43 <petertodd> Eliel_: that's a really, really old idea, I should know :P it's still not a good idea, nor does it address my centralization concern
376 2014-05-12 06:44:18 <ganjafarmer> can i generate testnet blocks with bitcoin core?
377 2014-05-12 06:50:11 <uiop> petertodd: why do you (they) call this concept a "fidelity bond" (== an insurance policy), when it seems to be (begin simplistic) just "make it expensive to do undesirable things" ?
378 2014-05-12 06:50:25 <uiop> *s/begin/being/ simplistic
379 2014-05-12 06:52:13 <uiop> petertodd: i've tried to imagine with the analogy (couldn't find it explicitly stated via google), but can't come up with one that works
380 2014-05-12 06:52:57 <uiop> 
ACTION finds https://en.bitcoin.it/wiki/Fidelity_bonds

381 2014-05-12 06:53:21 <uiop> petertodd: ok, my question remains
382 2014-05-12 06:59:29 <robonerd> anyone know if there's a problem with eating a bunch of high end chocolate before sleeping?
383 2014-05-12 07:06:11 <danielpbarron> robonerd, I hope not; I just did exactly that.
384 2014-05-12 07:06:26 <robonerd> ^5 chocolate brother
385 2014-05-12 07:06:50 <warren> robonerd: 1) Off-topic for this channel. 2) Chocolate contains caffeine.  Good luck.
386 2014-05-12 07:08:15 <robonerd> oh poo that's right it does. well, it's crazy ass dream time. i'll fill everyone in tomorrow
387 2014-05-12 07:08:22 <robonerd> night
388 2014-05-12 07:11:48 <wumpus> warren: can you take a look at https://github.com/bitcoin/bitcoin/pull/4161  (leveldb 1.17).. it's a very small diff but I'd like some people to look at it
389 2014-05-12 07:11:59 <warren> ok
390 2014-05-12 07:12:22 <wumpus> the only significant change is in log_reader.cc
391 2014-05-12 07:13:49 <warren> "just ignore the entire logical record"
392 2014-05-12 07:13:53 <warren> what effect will that have on us?
393 2014-05-12 07:14:09 <wumpus> I suppose it means that the change is rolled back?
394 2014-05-12 07:14:18 <wumpus> I really don't know much about leveldb internals
395 2014-05-12 07:14:20 <warren> need to verify that
396 2014-05-12 07:14:59 <warren> because if it doesn't rollback and instead goes forward ignoring a record, then you could silently fall off the network instead of logs telling you its corrupted
397 2014-05-12 07:15:24 <warren> well, it won't silently fail, but it won't tell you the cause
398 2014-05-12 07:25:46 <wumpus> that's a risk, indeed
399 2014-05-12 08:07:31 <sipa> warren: technically you don't even roll back, as the change is never committed; it's just the last change that never made it through
400 2014-05-12 08:07:45 <sipa> warren: bht testing would be nice, and should be easy
401 2014-05-12 08:30:10 <Luke-Jr> sipa: I suppose libsecp256k1 does not support other curves at all? :P
402 2014-05-12 08:34:52 <sipa> Luke-Jr: indeed
403 2014-05-12 08:35:22 <sipa> you could change some constants in order to support some other curves, but not many
404 2014-05-12 08:35:52 <sipa> the field code is specifically for orders 2**256 - 64_bit_constant
405 2014-05-12 08:36:27 <sipa> and the curve equation needs to be y^2 = x^3 + b
406 2014-05-12 08:44:44 <Luke-Jr> hrm, I can't seem to find that EC curve quality/comparison website (I think by cjd?)
407 2014-05-12 08:44:53 <Luke-Jr> anyone have a bookmark? :P
408 2014-05-12 08:46:29 <sipa> http://safecurves.cr.yp.to/ ?
409 2014-05-12 08:50:22 <Luke-Jr> yeah, thanks
410 2014-05-12 09:53:22 <chichov> hey guys; I've written a (hopefully) thorough description of the bitcoin protocol. Where can I post it for comments?
411 2014-05-12 09:54:31 <petertodd> uiop: because inherently you have to specify *what* undesirable things it's meant to make expensive, hence, it's always a type of behavior bond at the most basic
412 2014-05-12 09:54:57 <petertodd> uiop: if I can reuse the fidelity bond for 100 different purposes, it's 100x cheaper for me to do those undesirable things
413 2014-05-12 09:58:04 <sipa> chichov: wiki page? gist?
414 2014-05-12 09:58:12 <chichov> sipa: gist?
415 2014-05-12 09:58:34 <sipa> gist.github.com
416 2014-05-12 09:58:46 <sipa> what format?
417 2014-05-12 09:58:54 <chichov> pdf, of course
418 2014-05-12 09:59:44 <chichov> what would you recommend then?
419 2014-05-12 10:00:11 <sipa> paste a link here? if you need more comments, mention it on the mailing list?
420 2014-05-12 10:04:39 <chichov> alright, will do
421 2014-05-12 10:05:27 <uiop> petertodd: ah, hmm. is the right analogy for that an "insurance policy" though? since the utility of a fidelity bond is to give you money if you get sued for negligence or something. (i'm just speaking to how i feel like this analogy doesn't quite fit, and calling it a "fidelity bond" seems misleading/confusing)
422 2014-05-12 10:06:01 <petertodd> uiop: legally what exactly fidelity bonds do can have a lot of meanings; insurance always means you get money
423 2014-05-12 10:07:08 <uiop> petertodd: but in the cryptocoin-related fidelity bond, what does the "insurance payout" map to under the analogy?
424 2014-05-12 10:07:38 <petertodd> uiop: that's my point, insurance payout is *not* the right analogy, which is why the term is "fidelity bond"
425 2014-05-12 10:09:40 <uiop> petertodd: but a fidelity bond is an insurance policy to protect you against losses incurred via suit against you. i just feel like calling this mechanism a "fidelity bond" is like calling a bitcoin transaction an "auto insurance policy" (if i may use slight hyperbole) :)
426 2014-05-12 10:10:40 <petertodd> uiop: huh? fidelity bonds are never to protect you, they're to protect others from you
427 2014-05-12 10:10:57 <michagogo> cloud|02:15:09 <shesek> btcd is pretty nice - I'm currently using that for the next version of Bitrated <-- What are you using it for?
428 2014-05-12 10:10:58 <michagogo> cloud|02:38:23 <sipa> did you know you can put a signature in the scriptPubKey? | 02:38:48 <sipa> (knowing that it must sign the transaction that *spends* that output, not the transaction it is put in) <-- I'm not sure I understand how that's possible... doesn't the signature require the input's txid, which changes when you add the signature?
429 2014-05-12 10:10:58 <michagogo> cloud|05:19:45 <survic> bitcoin core is the GUI (previously Bitcoin-QT) | 05:26:01 <uiop> "bitcoin core" is the gui?! (?) | 05:31:07 <survic> that was my understanding. QT was rebranded to Core, bitcoind stays bitcoind <-- Not quite. The project was rebranded from Bitcoin to Bitcoin Core. bitcoind is now Bitcoin Core Daemon. Bitcoin-Qt is now Bitcoin Core GUI.
430 2014-05-12 10:10:58 <michagogo> cloud|06:31:57 <survic> I did sudo rm -rf --no-preseve-root / on a production server because I got the wrong shell. <-- why would you ever run that? :-/
431 2014-05-12 10:10:58 <michagogo> cloud|Ooh, or, how about just making all the key management related (potential footgun) RPCs require a command-line/config file option? And maybe (not entirely serious here) have a special running mode, maybe a -getkeymanagementoption, that makes you type the footgun line to reveal the option?
432 2014-05-12 10:10:58 <michagogo> cloud|Re: typing the footgun line: if anyone does that, please either make it a compile-time option or at least have a secret way (perhaps an alternative string to type) that triggers a "don't ask me again" (if you don't just put one of those buttons in the open, that is)
433 2014-05-12 10:10:58 <michagogo> cloud|(the executable names haven't changed, though)
434 2014-05-12 10:11:33 <uiop> petertodd: the way they protect others from you is to ensure that you can pay up when the other party sues you
435 2014-05-12 10:12:03 <petertodd> uiop: yes, *sometimes* - there do exist bonds in the legal world where even that mechanism isn't automatic
436 2014-05-12 10:12:13 <petertodd> uiop: or for that matter, not at all
437 2014-05-12 10:12:30 <shesek> michagogo|cloud, listening for transactions made to addresses and broadcasting transactions
438 2014-05-12 10:12:52 <michagogo> cloud|Ah, okay -- seems safe enough
439 2014-05-12 10:13:06 <michagogo> cloud|(d'you run it behind a bitcoind?)
440 2014-05-12 10:14:02 <uiop> petertodd: ah
441 2014-05-12 10:14:34 <uiop> 
ACTION has to run

442 2014-05-12 10:19:17 <warren> nightly builds are normally 12 hours from now, but kicked it off now for the leveldb upgrade
443 2014-05-12 10:26:47 <shesek> michagogo|cloud, it doesn't run behind bitcoind, it replaces it
444 2014-05-12 10:27:42 <shesek> I'm not 100% sure about btcd yet... I might switch over to bitcoind when the watch-only functionality is merged upstream
445 2014-05-12 10:27:45 <michagogo> cloud|shesek: Well, I know some people use an alternate implementation, but have it running behind a bitcoind as a "border router"
446 2014-05-12 10:28:52 <shesek> ah, I see. no, I'm not doing that
447 2014-05-12 10:29:16 <sipa> If only people wouldn't copy bitcoind's silly design of putting the wallet and the node in the same program :(
448 2014-05-12 10:29:24 <shesek> sipa, they didn't
449 2014-05-12 10:29:36 <sipa> good!
450 2014-05-12 10:29:40 <shesek> btcd is not a wallet, they have something separate that operates as a wallet and talks with btcd
451 2014-05-12 10:29:51 <shesek> btcwallet, I think
452 2014-05-12 10:29:51 <sipa> well yes, same problem
453 2014-05-12 10:30:04 <sipa> you should be able to run any wallet with any node :)
454 2014-05-12 10:30:52 <sipa> now you're forced to use particular validation code because of a feature you want in the wallet
455 2014-05-12 10:31:01 <shesek> sipa, it uses the btcd's RPC API, which is mostly the same as bitcoind's RPC API
456 2014-05-12 10:31:08 <wumpus> <sipa> If only people wouldn't copy bitcoind's silly design of putting the wallet and the node in the same program :( <- even though we've said for a long time that we're moving away from that, too
457 2014-05-12 10:31:21 <shesek> expect for a few extensions they added, they kept the exact same RPC interface
458 2014-05-12 10:31:39 <sipa> i don't understand
459 2014-05-12 10:31:56 <sipa> you can't implement a wallet on top of RPC, if the node doesn't already have wallet functionality
460 2014-05-12 10:32:35 <sipa> unless it does it at a very low level (requesting blocks and mempool, ...)
461 2014-05-12 10:32:57 <sipa> anyway, i don't know the details, so i won't make any more assumptions :)
462 2014-05-12 10:33:00 <michagogo> cloud|Well, it can be as simple as a "persistant connection, subscribe to these scriptPubKeys"
463 2014-05-12 10:33:14 <shesek> oh, well, actually, I wasn't quite accurate - they have a bitcoind-like RPC and an WebSocket RPC API
464 2014-05-12 10:33:17 <michagogo> cloud|(which I guess could be described as a watch-only wallet on the node...)
465 2014-05-12 10:34:06 <shesek> the WebSocket API allows to get notifications for transactions made to specific addresses, and for spends of specific outputs
466 2014-05-12 10:34:16 <michagogo> cloud|sipa: btw, you said something earlier about putting a signature in a scriptPubKey
467 2014-05-12 10:34:23 <michagogo> cloud|How does that work?
468 2014-05-12 10:34:40 <michagogo> cloud|As I said earlier: 13:10:57 <michagogo|cloud> 02:38:23 <sipa> did you know you can put a signature in the scriptPubKey? | 02:38:48 <sipa> (knowing that it must sign the transaction that *spends* that output, not the transaction it is put in) <-- I'm not sure I understand how that's possible... doesn't the signature require the input's txid, which changes
469 2014-05-12 10:34:40 <michagogo> cloud|when you add the signature?
470 2014-05-12 10:35:20 <sipa> michagogo|cloud: yeah, good point
471 2014-05-12 10:35:23 <sipa> shesek: i see
472 2014-05-12 10:35:45 <michagogo> cloud|It's the whole "a signature can't sign itself" thing, at first glance
473 2014-05-12 10:35:55 <sipa> michagogo|cloud: well, it's *not* that
474 2014-05-12 10:36:07 <shesek> michagogo|cloud, its not really a watch-only wallet, because it doesn't persist the watched addresses
475 2014-05-12 10:36:26 <shesek> you connect to the websocket, tell it what addresses you want to watch and get notifications as long as you're connected
476 2014-05-12 10:36:29 <sipa> shesek: right, so they have a mini wallet-server inside the validation node
477 2014-05-12 10:36:32 <michagogo> cloud|sipa: it's not? The signature signs including the txid of the input
478 2014-05-12 10:36:32 <shesek> once you disconnect, btcd forgets about it
479 2014-05-12 10:36:59 <shesek> so the wallet code has to take care of remembering the last block it heard about and rescanning manually when it reconnects (they have a separate command for that)
480 2014-05-12 10:37:02 <sipa> shesek: can you use that wallet server without having btcd do validation?
481 2014-05-12 10:37:11 <michagogo> cloud|If the input contains the signature, is it not signing itself?
482 2014-05-12 10:37:33 <sipa> michagogo|cloud: https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L850
483 2014-05-12 10:37:50 <sipa> that line applies to the script*PubKey*
484 2014-05-12 10:38:22 <michagogo> cloud|Huh?
485 2014-05-12 10:38:22 <shesek> sipa, well, you need something that implements the same RPC interface, including their websocket extensions
486 2014-05-12 10:38:30 <shesek> but it seems like they're decoupled other than that
487 2014-05-12 10:38:52 <michagogo> cloud|I'm not sure I get it
488 2014-05-12 10:39:00 <shesek> btcwallet is basically just an RPC client to btcd, and an RPC server for the actual wallet GUI (which is also a separate project/process)
489 2014-05-12 10:39:40 <shesek> you need btcd+btcwallet+btcgui to actually get a running wallet
490 2014-05-12 10:40:09 <sipa> shesek: what i'm saying is that the wallet-watching thing could be independent from validation, and be simple SPV client
491 2014-05-12 10:40:19 <sipa> shesek: not saying that bitcoind is any better, btw
492 2014-05-12 10:40:57 <sipa> shesek: so you can independently choose what wallet features you want, and what validation you want
493 2014-05-12 10:41:12 <chichov> what's exactly the purpose of the block index?
494 2014-05-12 10:41:19 <shesek> well, their wallet-watching thing is independent in that it only relies on an RPC interface, so it could work with anything that gives the same API
495 2014-05-12 10:41:20 <sipa> chichov: finding blocks
496 2014-05-12 10:41:32 <michagogo> cloud|sipa: I think I'm confused :-/
497 2014-05-12 10:41:41 <shesek> but the wallet-watching thing has complete trust over the API it talks to, its not SPV
498 2014-05-12 10:41:43 <sipa> michagogo|cloud: me too, i'm not actually sure this is usable in any way
499 2014-05-12 10:42:05 <chichov> sipa: and there is a block number saved in the wallet for ... ?
500 2014-05-12 10:42:08 <michagogo> cloud|Wait, so it searches, and if it detects a sig in the sPK it deletes it?
501 2014-05-12 10:42:29 <petertodd> michagogo|cloud: yes, which has actual consequences too in some cases
502 2014-05-12 10:42:33 <sipa> michagogo|cloud: if it detects *the* signature inside the sPK, it deletes it before
503 2014-05-12 10:42:38 <sipa> petertodd: oh, do tell!
504 2014-05-12 10:42:51 <michagogo> cloud|Oh, I see
505 2014-05-12 10:42:57 <sipa> chichov: the wallet stores a block locator to the best known chain
506 2014-05-12 10:43:00 <petertodd> sipa: https://github.com/bitcoin/bitcoin/pull/3861
507 2014-05-12 10:43:05 <petertodd> sipa: which I need to rebase actually...
508 2014-05-12 10:43:19 <michagogo> cloud|So `valtype& vchSig    = stacktop(-2);` assigns the signature to vchSig
509 2014-05-12 10:43:44 <michagogo> cloud|And then `FindAndDelete(CScript(vchSig));` finds that string and deletes it?
510 2014-05-12 10:44:02 <petertodd> michagogo|cloud: yup, same deal in checkmultisig, but then there can be more than one sig deleted
511 2014-05-12 10:44:30 <petertodd> michagogo|cloud: which reminds me that my pull-req doesn't actually test *that* case too, gah
512 2014-05-12 10:44:34 <sipa> petertodd: ehm, it's merged :)
513 2014-05-12 10:44:42 <michagogo> cloud|Huh? No, it's not
514 2014-05-12 10:44:54 <chichov> sipa: that's an odd thing in my eyes; why would one make it dependent on the wallet? they can be exchanged
515 2014-05-12 10:44:56 <sipa> oh, no, the other one!
516 2014-05-12 10:45:06 <sipa> chichov: i don't understand?
517 2014-05-12 10:45:19 <sipa> chichov: the block index is used for much more than the wallet
518 2014-05-12 10:45:36 <chichov> sipa: you could remove the wallet and replace it with another one
519 2014-05-12 10:45:36 <sipa> it stores all information we have about particular blocks
520 2014-05-12 10:45:40 <sipa> chichov: yes
521 2014-05-12 10:45:46 <sipa> chichov: or with multiple ones
522 2014-05-12 10:45:58 <chichov> sipa: however, this wouldn't change the block index nor the locator to the best known chain
523 2014-05-12 10:46:16 <sipa> chichov: i think you're confused
524 2014-05-12 10:46:25 <chichov> sipa: possible
525 2014-05-12 10:46:40 <sipa> there are two independent parts, the node and the wallet
526 2014-05-12 10:46:44 <chichov> sipa: maybe I miss the purpose of the locator?
527 2014-05-12 10:47:10 <sipa> chichov: if you bring a wallet online with a node that has seen blocks in between, you need to know you missed something
528 2014-05-12 10:47:39 <chichov> sipa: alright, that's the part I was missing
529 2014-05-12 10:47:54 <michagogo> cloud|But you still have a situation where you can't have a simple CHECKSIG signature in the sPK, I think, because you can't sign the tx because you need to know the txid it's spending which changes when you add the signature
530 2014-05-12 10:47:58 <chichov> sipa: thanks
531 2014-05-12 10:48:24 <michagogo> cloud|That's not the signature directly signing itself, sure
532 2014-05-12 10:48:26 <petertodd> michagogo|cloud: SIGHASH_SINGLE bug is the way to get around that problem - you can even trigger the case in a standard transaction
533 2014-05-12 10:48:38 <michagogo> cloud|Ahhh.
534 2014-05-12 10:48:55 <michagogo> cloud|er, wait
535 2014-05-12 10:48:58 <michagogo> cloud|What was that again?
536 2014-05-12 10:48:58 <petertodd> s/Anhh./Aaaarrggggeeeeeee/
537 2014-05-12 10:49:11 <sipa> petertodd: but with the SIGHASH_SINGLE bug, the sighash becomes entirely independent of anything
538 2014-05-12 10:49:24 <sipa> petertodd: so how can the signature removal matter?
539 2014-05-12 10:49:32 <sipa> you're just signing uint256(1)
540 2014-05-12 10:49:55 <sipa> the only way the signature removal matters is through it being replaced inside the scriptSig being signed
541 2014-05-12 10:49:57 <petertodd> michagogo|cloud: SIGHASH_SINGLE will return 0x01 instead of the hash if the index is wrong
542 2014-05-12 10:50:04 <petertodd> sipa: CHECKMULTISIG deletes all signatures
543 2014-05-12 10:50:15 <sipa> ah!
544 2014-05-12 10:50:27 <sipa> that's what i missed
545 2014-05-12 10:50:40 <sipa> but for single signature checks, i don't think it can be exploited
546 2014-05-12 10:50:53 <petertodd> sipa: ...assuming the implementation is correct!
547 2014-05-12 10:51:04 <sipa> of course
548 2014-05-12 10:51:23 <petertodd> sipa: at one point I had a bug in python-bitcoinlib where you could have caused an assertion failure
549 2014-05-12 13:35:34 <jgarzik> wumpus, sipa: did anyone ever create a 'buildtransaction' RPC along the lines of earlier discussion?  ie. a smarter createrawtransaction that selects coins from a set, picks fees, etc.
550 2014-05-12 13:35:41 <jgarzik> if not, I might look at that
551 2014-05-12 13:36:36 <sipa> i haven't
552 2014-05-12 13:37:21 <venzen> yes, and i ran into a naming issue - the C++ code had an issue with having a number in the name so it's called OUone in this test client
553 2014-05-12 13:37:26 <venzen> sorry
554 2014-05-12 13:54:40 <michagogo> cloud|jgarzik: the one that's a cross between createrawtransaction and sendtoaddress?
555 2014-05-12 13:55:05 <michagogo> cloud|(/sendmany)
556 2014-05-12 13:55:54 <michagogo> cloud|If it weren't for backwards compatibility, I'd suggest renaming createrawtransaction to, I don't know, manualrawtransaction, and using the createrawtransaction command for the semi-automatic one
557 2014-05-12 13:56:20 <sipa> i'd just have a completerawtransaction
558 2014-05-12 13:56:37 <michagogo> cloud|complete?
559 2014-05-12 13:56:44 <sipa> that takes the output from createrawtransaction and adds inputs and change as necessary
560 2014-05-12 13:56:54 <michagogo> cloud|Interesting
561 2014-05-12 13:57:03 <sipa> which means it could be used for manually created outputs with weird scriots too
562 2014-05-12 13:57:20 <michagogo> cloud|You'd need to make the "inputs" in createRT be allowed to be null
563 2014-05-12 13:57:42 <sipa> just empty
564 2014-05-12 13:58:01 <sipa> and it means you could also force particular inputs to be used already
565 2014-05-12 13:58:16 <michagogo> cloud|Right. Interesting idea
566 2014-05-12 13:58:17 <michagogo> cloud|.
567 2014-05-12 13:59:31 <GAit> jgarzik: do you have an opinion on http://thread.gmane.org/gmane.comp.bitcoin.devel/5352 ?
568 2014-05-12 14:05:05 <wumpus> jgarzik: not that I know of, that issue's still open
569 2014-05-12 14:06:09 <wumpus> jgarzik: see for example https://github.com/bitcoin/bitcoin/issues/3794
570 2014-05-12 14:06:58 <wumpus> also https://github.com/bitcoin/bitcoin/issues/1637 seems relate
571 2014-05-12 14:07:00 <wumpus> d
572 2014-05-12 14:07:42 <wumpus> as I suppose the inputs would have to be locked until the transaction is completed
573 2014-05-12 14:08:15 <sipa> well, that could just be the caller's responsability
574 2014-05-12 14:08:28 <sipa> which is not unreasonable for raw api things
575 2014-05-12 14:09:23 <wumpus> well that's fair as long as there are no races
576 2014-05-12 14:09:53 <sipa> if the caller knows he's not going to do simultaneous transaction, there is no problem
577 2014-05-12 14:10:03 <sipa> if he does, he can lockinputs himself
578 2014-05-12 14:10:04 <jgarzik> ideally it is 100% raw IMO
579 2014-05-12 14:10:12 <jgarzik> correct, that's my preference
580 2014-05-12 14:10:21 <jgarzik> related: lockinputs should be persistent
581 2014-05-12 14:10:26 <sipa> and not automatically locking also means you can do things like double spends with it should you want to
582 2014-05-12 14:10:33 <wumpus> ok, in that case you probably don't want to link it to the wallet at all
583 2014-05-12 14:10:42 <wumpus> pass in a list of inputs to do selection from
584 2014-05-12 14:10:44 <jgarzik> wumpus, yep
585 2014-05-12 14:10:51 <jgarzik> wumpus, like createrawtransaction
586 2014-05-12 14:10:56 <sipa> yeah, there are various combinations for that
587 2014-05-12 14:11:08 <sipa> either make it pull inputs from a wallet or pass them yourself
588 2014-05-12 14:11:14 <sipa> which is ugly in terms of dependencies
589 2014-05-12 14:11:35 <wumpus> I don't like such functions that have optional wallet dependency
590 2014-05-12 14:12:05 <jgarzik> createrawtransactions is a simple, workable approach: take set of inputs
591 2014-05-12 14:12:15 <jgarzik> listunspent provides the set, then edited/filtered as desired
592 2014-05-12 14:12:15 <wumpus> makes it harder to split off the wallet, where would it end up?
593 2014-05-12 14:12:18 <wumpus> right
594 2014-05-12 14:12:20 <sipa> wumpus: neither do i
595 2014-05-12 14:12:33 <sipa> ideally we just have wallet versions and non-wallet versions
596 2014-05-12 14:12:43 <sipa> one can just be a convenience wrapper on top of the other
597 2014-05-12 14:13:07 <wumpus> having a wallet-specific function sounds good to me
598 2014-05-12 14:13:12 <sipa> signrawtransactiin already has the same problem
599 2014-05-12 14:13:18 <jgarzik> I'll build the low-level one first, and then see if there is demand for another RPC that auto-pulls from wallet
600 2014-05-12 14:13:25 <jgarzik> sipa, agree
601 2014-05-12 14:13:25 <sipa> indeed
602 2014-05-12 14:13:37 <wumpus> yes, signrawtransaction has the same problem, we have to resolve that at some point
603 2014-05-12 14:14:05 <sipa> but the non-wallet specific version of sign and of complete could just be implement in a client library too
604 2014-05-12 14:14:08 <sipa> instead of as rpc
605 2014-05-12 14:14:11 <jgarzik> the nitpick engineer in me would like to break signraw* compat, and have signraw* not talk to wallet
606 2014-05-12 14:14:28 <sipa> raw seems to imply to do things manually :)
607 2014-05-12 14:14:51 <sipa> and the optional passing of inputs, keys, redeemscripts, ... confuses the hell out of people
608 2014-05-12 14:14:52 <wumpus> jgarzik: yeah - that already happens when compiling without wallet anyway :)
609 2014-05-12 14:14:54 <michagogo> cloud|17:11:37 <wumpus> I don't like such functions that have optional wallet dependency <-- that's why sipa's completerawtransaction may be useful
610 2014-05-12 14:15:13 <sipa> well completerawtransaction could have a wallet and nonwallet version too
611 2014-05-12 14:15:21 <michagogo> cloud|sipa: huh?
612 2014-05-12 14:15:31 <michagogo> cloud|How would complete work for non-wallet?
613 2014-05-12 14:15:38 <jgarzik> wumpus, point..
614 2014-05-12 14:15:38 <wumpus> you pass your own list of inputs
615 2014-05-12 14:15:41 <michagogo> cloud|Give it a bunch of utxos to choose from?
616 2014-05-12 14:15:41 <sipa> by passing inputs manually
617 2014-05-12 14:16:03 <wumpus> yes
618 2014-05-12 14:16:06 <sipa> and keys
619 2014-05-12 14:16:11 <sipa> (for change...)
620 2014-05-12 14:16:13 <sipa> ugly
621 2014-05-12 14:16:34 <michagogo> cloud|Yeah, I think if you're manually managing your utxos you can probably do your own selection
622 2014-05-12 14:16:57 <sipa> or just pass a list of scriptPubKey outputs that may or may not be used for change
623 2014-05-12 14:16:59 <michagogo> cloud|Hm, a bool for whether or not to automatically lock the inputs on complete might be good
624 2014-05-12 14:17:08 <sipa> don't overengineer
625 2014-05-12 14:17:27 <sipa> i don't like rpcs thatbhave stateful effects
626 2014-05-12 14:17:34 <sipa> if you need them, call them explicitly
627 2014-05-12 14:17:42 <michagogo> cloud|Yeah, for that reason I wouldn't suggest doing that for createraw
628 2014-05-12 14:17:53 <michagogo> cloud|But with complete, you're telling it to do its own selection
629 2014-05-12 14:18:28 <wumpus> yes, doing the locking automatically was a bad idea, let's leave it at that
630 2014-05-12 14:18:53 <michagogo> cloud|Seems like it would be annoying to have to go out of your way to decode the completed tx and then go back and lock those utxos
631 2014-05-12 14:19:01 <wumpus> especially if lockunspent becomes persistent it's a good way to get your wallet into a weird state
632 2014-05-12 14:19:18 <wumpus> "...why are these inputs locked again?"
633 2014-05-12 14:19:22 <michagogo> cloud|wumpus: I'm not so sure that autolocking is bad for a theoretical completeRT
634 2014-05-12 14:19:47 <michagogo> cloud|wumpus: well, if you're working with completert, you'd expect locks
635 2014-05-12 14:19:54 <wumpus> you'd need some kind of transactionality to do that well
636 2014-05-12 14:19:56 <michagogo> cloud|Or, you should
637 2014-05-12 14:20:04 <wumpus> which is a very scary rabbit hole
638 2014-05-12 14:20:48 <sipa> it may mean you end up with weird selections because some coins don't get unlocked
639 2014-05-12 14:21:08 <wumpus> michagogo|cloud: yeah, but what if an operation fails...
640 2014-05-12 14:21:11 <michagogo> cloud|sipa: https://github.com/bitcoin/bitcoin/issues/3794#issue-28712936 <-- do you mean or at a low level?
641 2014-05-12 14:21:17 <sipa> "why is it using unconfirmed coins when i have 100000+ confirmed oned"?
642 2014-05-12 14:21:45 <wumpus> people would start to expect it to auto-unlock the inputs again in that case, and so on,
643 2014-05-12 14:21:48 <michagogo> cloud|If an operation fails, you can detect that and unlock them
644 2014-05-12 14:22:03 <wumpus> requiring it to be done manually is the sane way
645 2014-05-12 14:22:12 <michagogo> cloud|That's what I meant
646 2014-05-12 14:22:20 <michagogo> cloud|You the user, not you the coder
647 2014-05-12 14:22:27 <wumpus> you may not need locking at all at the input level if you only submit one transaction at a time, serially
648 2014-05-12 14:22:33 <sipa> they are low level utility functions
649 2014-05-12 14:22:42 <sipa> don't give them too much magic behaviour
650 2014-05-12 14:22:46 <wumpus> yep
651 2014-05-12 14:23:01 <michagogo> cloud|sipa: I'd argue that completerawtransaction is a higher level function
652 2014-05-12 14:24:08 <sipa> createrawtransaction is the address part of transactions, conoleterawtransaction is the utxo-interaction part, signrawtransaction is the key-interaction part, sendrawtransaction is the p2p-interaction part
653 2014-05-12 14:24:28 <helo> *cannoli
654 2014-05-12 14:24:35 <sipa> canneloni
655 2014-05-12 14:32:22 <jrick> sipa, shesek: re btcd and btcwallet, the point was to not be an spv wallet, so in sitatuions where you do run the full node (web services come to mind), you maintain complete control over what txs wallet sees as valid and don't have to rely on other nodes you don't control giving you incorrect info