1 2013-08-08 00:00:27 <jgarzik> sipa, tempting to embed libsecp256k1 into bitcoin, a la leveldb
2 2013-08-08 00:00:41 <jgarzik> sipa, to work around Fedora's openssl hobbling </self-interest>
3 2013-08-08 00:01:37 <gmaxwell> jgarzik: this hasn't escaped prior discussion!
4 2013-08-08 00:01:44 <gmaxwell> I'm all for it.
5 2013-08-08 00:27:38 <Vinnie_win> What do I include to get std::unique_ptr ?
6 2013-08-08 00:32:54 <jgarzik> Vinnie_win, <memory>
7 2013-08-08 00:33:06 <Vinnie_win> jgarzik: Thanks.
8 2013-08-08 00:33:15 <jgarzik> Vinnie_win, i.e. the first hit when googling std::unique_ptr ;p
9 2013-08-08 00:33:31 <Vinnie_win> I was on that page but I can't find the #include line
10 2013-08-08 00:33:51 <Vinnie_win> Argh...now I see it.
11 2013-08-08 00:34:01 <Vinnie_win> "Defined in header <memory>" could they possibly make the font smaller?
12 2013-08-08 00:39:42 <devrandom> any idea why this p2sh redemption is slow to confirm? https://blockchain.info/tx/d46a02af8f3847ab7f1bb2958634d61a452b9028063b305ca967193dca3fb98d
13 2013-08-08 01:06:19 <devrandom> (probably inputs too small / recent)
14 2013-08-08 01:07:47 <TheLordOfTime> ;;tslb
15 2013-08-08 01:07:49 <gribble> Time since last block: 5 minutes and 43 seconds
16 2013-08-08 01:07:53 <TheLordOfTime> devrandom: it'll be picked up eventually, i think
17 2013-08-08 01:08:52 <devrandom> right
18 2013-08-08 02:09:24 <gavinandresen> I need a short phrase that means "a transaction output that cannot be expressed as a bitcoin address"
19 2013-08-08 02:10:45 <gavinandresen> It will be shown to users in what should be a very rare edge case: A non-signed PaymentRequest that requests payment to (for example) an OP_CHECKMULTISIG output.
20 2013-08-08 02:12:00 <gmaxwell> "output script"? as in "Payment to output script: 0xhex_encoding_of_the_actual_script"
21 2013-08-08 02:12:52 <gavinandresen> oof??? not sure I want to show users the hex encoding
22 2013-08-08 02:13:25 <gavinandresen> it'll tend to scroll off the dialog box
23 2013-08-08 02:14:23 <gmaxwell> "custom script"
24 2013-08-08 02:14:31 <gmaxwell> "custom payment script"
25 2013-08-08 02:14:45 <gavinandresen> "custom payment script" I like
26 2013-08-08 02:15:10 <gavinandresen> I hope that translates well......
27 2013-08-08 02:21:10 <gmaxwell> "tailored remuneration story"
28 2013-08-08 02:21:25 <gmaxwell> (sounds like what you get when someone is late on paying back a debt)
29 2013-08-08 02:21:42 <gmaxwell> translations are fun.
30 2013-08-08 02:49:56 <Luke-Jr> gavinandresen: we do have a disassembly function in bitcoind :p
31 2013-08-08 02:50:15 <Luke-Jr> but it's probably sufficient to just show them the length
32 2013-08-08 02:50:22 <Luke-Jr> "Custom payment script (%d bytes)"
33 2013-08-08 11:16:58 <TD_> sipa: is -rescan intended to empty the wallet of unconfirmed transactions?
34 2013-08-08 11:17:13 <TD> https://bitcointalk.org/index.php?topic=270005.0
35 2013-08-08 11:41:01 <sipa> TD: no
36 2013-08-08 11:41:11 <TD> that would be the reason then. perhaps it should?
37 2013-08-08 11:42:01 <sipa> rescan really just finds missing wallet transactions
38 2013-08-08 11:42:25 <sipa> dealing properly with non-confirming transactions is a different issue in general
39 2013-08-08 11:42:33 <sipa> (it requires tracking conflicts, for example)
40 2013-08-08 11:43:03 <sipa> you generally don't want a rescan to drop unconfirmed transactions, they may still confirm
41 2013-08-08 11:45:55 <TD> if they do, you'll see them again when they appear in the chain
42 2013-08-08 11:46:29 <sipa> well sure, but you may be the only one who has them
43 2013-08-08 11:46:39 <sipa> you want to keep rebroadcasting until confirmed
44 2013-08-08 11:47:00 <sipa> the problem is not that you want to remove non-confirmed transactions; the problem is that you should detect that a transaction will never confirm
45 2013-08-08 11:47:22 <TD> well, yes, of course, but that's harder :)
46 2013-08-08 11:47:23 <sipa> or have some ability for the user to delete after some time
47 2013-08-08 11:47:37 <sipa> yes, it is harder
48 2013-08-08 11:48:25 <sipa> the solution to non-confirming transactions in the wallet is generally -salvagewallet
49 2013-08-08 11:48:32 <sipa> but that's sort of a very rough measure
50 2013-08-08 11:48:46 <sipa> (removes everything but keys, and rescans)
51 2013-08-08 11:55:06 <TD> sipa: yeah that's more like what bitcoinj wallet replay does
52 2013-08-08 11:56:05 <jgarzik> mornin'
53 2013-08-08 11:58:14 <TD> hey there
54 2013-08-08 11:59:20 <jgarzik> Payment protocol hits the news: http://www.pcworld.co.nz/article/523173/bitcoin_upgrade_aims_smoother_e-commerce/?utm_medium=rss&utm_source=taxonomyfeed
55 2013-08-08 11:59:22 <jgarzik> gavinandresen, ^
56 2013-08-08 12:18:02 <petertodd> jgarzik: Heh, I wonder how long it will take until people realize that the payment protocol, as people describe it, only solves security of sending funds, not receiving?
57 2013-08-08 12:18:36 <petertodd> jgarzik: I gave a talk last night that touched on that... too a lot of guiding before one particularly bright audience member figured out that problem. :(
58 2013-08-08 12:19:06 <petertodd> Sigh, just another example of how crypto is magic to people...
59 2013-08-08 12:21:43 <petertodd> Also interesting: I talked to someone involved in a company getting into the business of selling Bitcoins, and they did understand the issue, and were seriously considering giving customers private keys on paper that they would fund, specifically due to legal issues about liability for stolen coins - they liked my one-time-password idea for that purpose.
60 2013-08-08 12:37:59 <nsh> petertodd, magicness(crypt) =~ can_be_done() / can_be_groked()
61 2013-08-08 12:38:02 <nsh> *crypto
62 2013-08-08 12:39:10 <petertodd> heh
63 2013-08-08 12:39:51 <petertodd> nsh: Though I did love one comment about the oracles/one-time-passwords idea: "But, that's so simple, why didn't someone do that years ago?"
64 2013-08-08 12:40:24 <nsh> elegance often occupies the shadow of internalised complexity
65 2013-08-08 12:40:26 <nsh> or something like that
66 2013-08-08 12:40:32 <petertodd> That's after I did a whole 15 minute story about Alice and her tree fort and her fear of boys with cooties explaining the difference between passwords and signatures... :)
67 2013-08-08 12:40:51 <nsh> sounds like a fun story
68 2013-08-08 12:40:58 <nsh> online anywhere?
69 2013-08-08 12:41:01 <petertodd> heh, yeah, my answere was pretty much "I got lucky and had the right bit of inspiration"
70 2013-08-08 12:41:13 <petertodd> nah, too dark for videos, I should write it up though
71 2013-08-08 12:41:20 <nsh> i'd like to read if you do :)
72 2013-08-08 12:41:51 <petertodd> well.... we need to make an oracle tx where nsh the oracle releases funds iff Peter Todd writes up said story :P
73 2013-08-08 12:42:15 <nsh> +1
74 2013-08-08 12:42:31 <nsh> (first we need to make the great internet heist whereby nsh has any funds to release)
75 2013-08-08 12:42:41 <petertodd> um... ok, testnet funds
76 2013-08-08 12:42:51 <nsh> :)
77 2013-08-08 12:43:10 <nsh> i don't think i know your oracle/OTP idea either
78 2013-08-08 12:43:14 <nsh> can you synopsise?
79 2013-08-08 12:43:23 <nsh> (or link)
80 2013-08-08 12:44:29 <petertodd> nsh: OTP version: that's so simple, why didn't someone do that years ago?"
81 2013-08-08 12:44:34 <petertodd> er: that's so simple, why didn't someone do that years ago?"
82 2013-08-08 12:44:41 <nsh> aye
83 2013-08-08 12:44:43 <petertodd> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02601.html
84 2013-08-08 12:44:46 <petertodd> there!
85 2013-08-08 12:44:51 <nsh> thankye!
86 2013-08-08 12:44:54 <petertodd> (stupid windows)
87 2013-08-08 12:45:13 <petertodd> oracle version: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02601.html
88 2013-08-08 12:48:37 <nsh> i take it any simple key-extension of RFC6238 will not add the required entropy?
89 2013-08-08 12:48:55 <nsh> also not clear to me why birthday attack doesn't apply (sorry, ignorant)
90 2013-08-08 12:49:47 <petertodd> RFC6238 only spits out six digit numbers, so the key-extension would have to be so large as to be just totally impractical. :(
91 2013-08-08 12:50:00 <nsh> k
92 2013-08-08 12:50:44 <petertodd> Birthday attacks don't apply because an attacker has to find a nonce that matches a given digest; birthday attacks only apply if you want to find two nonces for the same digest, but don't care exactly what each nonce is.
93 2013-08-08 12:51:30 <petertodd> Having said that, there could be obscure cases with third parties where a third-party generates the nonces, and wants to generate a second that matches for some reason... but seems unlikely in real-world scenarios.
94 2013-08-08 12:51:32 <volante> is it true that bitcoin offers only 128 bit security?
95 2013-08-08 12:54:58 <nsh> petertodd, that's a neat idea but i'll admit it's on the threshold of my current capacity to understand. to call it simple perhaps speaks more to the abstruseness it's possible to get into in the scripting system
96 2013-08-08 12:55:53 <kjj> volante: yes, but I object to your use of the word "only"
97 2013-08-08 12:56:37 <petertodd> nsh: ha, yeah, I'll assume the "simple" was only due to my excellent story about tree forts, lol
98 2013-08-08 12:56:52 <nsh> :D
99 2013-08-08 12:57:14 <nsh> volante, not all bits are created equal :)
100 2013-08-08 12:57:25 <volante> kjj: ok i take back "only" :)
101 2013-08-08 12:57:39 <nsh> volante, one bit of <inside or outside of fort knox> is relatively high security
102 2013-08-08 12:57:56 <kjj> volante: http://www.nsa.gov/business/programs/elliptic_curve.shtml
103 2013-08-08 13:00:54 <michagogo> ACTION sighs
104 2013-08-08 13:00:54 <michagogo> It kinda irks me to see the media get things wrong like "A bitcoin is essentially a secret number that is transferred from one software client to another using a 32-character alpha-numeric address." (from that pcw nz article)
105 2013-08-08 13:02:09 <petertodd> lol
106 2013-08-08 13:02:19 <petertodd> man, if we could transfer secret numbers securely...
107 2013-08-08 13:02:34 <K1773R> michagogo: thinking/worrying about media is mostly a waste of time
108 2013-08-08 13:02:43 <michagogo> I know, I know.
109 2013-08-08 13:03:03 <petertodd> michagogo: join the bitcoin foundation, let them worry about it
110 2013-08-08 13:04:02 <michagogo> Hmm?
111 2013-08-08 13:04:51 <petertodd> michagogo: part of the job of the foundation is to have something called "The Foundation" that the media will talk to by default and get sane answers
112 2013-08-08 13:04:59 <nsh> (about public/press misapprehension)
113 2013-08-08 13:05:44 <petertodd> michagogo: The beauty of it, is the bitcoin foundation can say over and over they aren't the one true authority on bitcoin, but the media will (hopefully) still go to them anyway.
114 2013-08-08 13:05:45 <michagogo> Ah
115 2013-08-08 13:07:19 <michagogo> Also, I'm laughing so hard right now... The Israeli government uses smartcards for identification for businesses and government employees.
116 2013-08-08 13:07:43 <michagogo> They have a guide to installing the software for the readers.
117 2013-08-08 13:07:51 <michagogo> That guide is at http://www.gov.il/NR/rdonlyres/A19BC418-5D97-46C8-BA70-47B69AE4972A/0/20111122_guideInstallupdated.pdf
118 2013-08-08 13:08:19 <michagogo> On page 8 of the PDF, there are "A number of examples of incorrect usage" (translated)
119 2013-08-08 13:10:20 <michagogo> The first example is "<b><red>The card is not inserted into the reader.</b></red><br> Make sure <b><u>that the smartcard is inside the card reader.</b></u>"
120 2013-08-08 13:12:28 <michagogo> I realize the guide is designed for anyone to be able to follow, and the "make sure the card's not backwards" part makes sense for that, but I find it hard to believe that it's actually neccesary to not just textually, but visually demonstrate the state of "the card is on the desk next to the reader" as being invalid.
121 2013-08-08 13:12:58 <nsh> lol
122 2013-08-08 13:13:17 <nsh> i dunno, everything these days is contactless, even my love-life
123 2013-08-08 13:17:31 <michagogo> nsh: Yeah, but when there's a gold-colored contact chip *on the card*, and you're given a reader with a slot for the card, it seems beyond obvious that you're not supposed to place the card on the desk several inches away from the reader.
124 2013-08-08 13:17:48 <nsh> yeah, i'll give you that :)
125 2013-08-08 13:18:05 <michagogo> Also: related: In the next couple months I may be getting a cryptographic smartcard
126 2013-08-08 13:18:17 <petertodd> michagogo: from whome?
127 2013-08-08 13:18:54 <michagogo> Since moin/piba are finally refreshing the Israeli Teudat Zehut (ID card, literally "certificate of identity")
128 2013-08-08 13:19:17 <petertodd> Ah
129 2013-08-08 13:19:25 <michagogo> It's been the same for decades and decades, and it's not very secure
130 2013-08-08 13:19:43 <petertodd> I was gonna say, get yourself a PGP smartcard like the crypto-nerds, er I mean cool kids.
131 2013-08-08 13:20:11 <petertodd> also this: https://www.crypto-stick.com/
132 2013-08-08 13:20:30 <michagogo> Basically, when you go to the issuing office to get your TZ, they put the photo you give them in a device that trims it to a certain size, and they print out a piece of paper
133 2013-08-08 13:21:22 <petertodd> Heh, makes you want to give them a futuristic bit of magical electronic paper instead of a photo...
134 2013-08-08 13:21:41 <michagogo> They tear off one section of the paper (the main TZ), use a glue stick to affix your photo, put it in a lamination pouch printed with the state seal, and put it through a laminating machine.
135 2013-08-08 13:22:19 <michagogo> http://en.wikipedia.org/wiki/Teudat_zehut
136 2013-08-08 13:24:22 <michagogo> (the rest of the paper that prints out is used as the appendix, with your family details, previous names, address, etc.
137 2013-08-08 13:25:08 <petertodd> huh, now can you actually use this card to sign stuff?
138 2013-08-08 13:26:10 <michagogo> Yes.
139 2013-08-08 13:26:32 <petertodd> Interesting, what standard?
140 2013-08-08 13:27:06 <michagogo> I don't know if it's a standard, or some system developed for this specifically
141 2013-08-08 13:28:02 <petertodd> Hm, either way, add it to my mental list of places with signing-capable ID cards... they can be useful sometimes because it lets you do a "proof-of-human", forcing the government to issue fake certs to attack you.
142 2013-08-08 13:30:22 <michagogo> Hmm?
143 2013-08-08 13:30:45 <petertodd> sybil attacks
144 2013-08-08 13:33:11 <michagogo> Ah
145 2013-08-08 13:33:42 <michagogo> So letting you know that the person you're talking to is an actual person, rather than some entity creating multiple personalities
146 2013-08-08 13:33:52 <petertodd> Yup
147 2013-08-08 13:34:26 <petertodd> IE I'd rather my bitcoin node not connect to 8 peers all run by the same person, and I don't care whether or not the fact that I am running a bitcoin node is public.
148 2013-08-08 13:35:02 <Vinnie_win> hey what's up folks
149 2013-08-08 13:35:37 <shesek> so if the government revokes your ID card, you wouldn't be able to connect to bitcoin nodes?
150 2013-08-08 13:35:53 <petertodd> depends on how such a system is implemented
151 2013-08-08 13:36:17 <petertodd> probably not, because you'd assume that it's only to setup the link, but that's all implementation decisions
152 2013-08-08 13:36:21 <shesek> having to rely on a central authority to provide ID cards seems to be somewhat against the idea of Bitcoin
153 2013-08-08 13:36:47 <shesek> or at least, against the spirit of Bitcoin
154 2013-08-08 13:36:50 <petertodd> well sure, but then again we also rely on the central authority assigning IP addresses for anti-sybil - it'd be nice to at least be relying on more than one central authority
155 2013-08-08 13:37:04 <petertodd> tl;dr: options are good
156 2013-08-08 13:37:59 <michagogo> petertodd: I thought there *are* more than one central authority?
157 2013-08-08 13:38:07 <michagogo> Different regionals, no?
158 2013-08-08 13:38:53 <petertodd> michagogo: well, sorta, kinda... the way we do it you could wind up with one central authority screwing you over - that might be worth thinking about carefully
159 2013-08-08 13:39:02 <petertodd> it's very weak protection anyway
160 2013-08-08 13:40:17 <michagogo> (to make sure I'm not misunderstood: that comment was referring to the IP addresses)
161 2013-08-08 13:40:27 <michagogo> What one central authority is that?
162 2013-08-08 13:41:37 <petertodd> Someone co-ordinates the actions of the regionals, but more importantly the way we do anti-sybil means we could allow 8 ips that are all under the control of one regional - but it's all moot because getting ip addresses from lots of different prefixes is really easy anyway.
163 2013-08-08 13:42:06 <michagogo> Right.
164 2013-08-08 13:42:19 <jgarzik> I had a thought about getting bitcoind to check AS numbers and regions, not just IP addresses
165 2013-08-08 13:42:22 <jgarzik> RIRs
166 2013-08-08 13:42:37 <petertodd> jgarzik: same thing I'm thinking, but I dunno it's worth the trouble
167 2013-08-08 13:43:21 <petertodd> jgarzik: though if someone wrote a patch to do it, I'd ACK it
168 2013-08-08 13:43:41 <jgarzik> hmm :)
169 2013-08-08 13:44:06 <petertodd> heh
170 2013-08-08 13:44:14 <jgarzik> Already looked into it, a bit. The main annoyance is querying the databases, which are typically centralized and not suited for high volume queries
171 2013-08-08 13:44:18 <gmaxwell> an interesting to check is if the /16 check actually excludes more peer entropy than an ASN check would.
172 2013-08-08 13:44:29 <jgarzik> could include an AS database with the software
173 2013-08-08 13:44:39 <gmaxwell> jgarzik: I'd suggest just shipping with a snapshot.
174 2013-08-08 13:44:39 <michagogo> How big is said DB?
175 2013-08-08 13:44:47 <petertodd> jgarzik: probably the way to do - they don't like people querying the AS database...
176 2013-08-08 13:44:51 <jgarzik> not too big, I think
177 2013-08-08 13:44:54 <TD> petertodd: actually the BitSafe guy mentioned the getting-money-in problem at the may conference. so yeah it's something to think about.
178 2013-08-08 13:45:02 <jgarzik> didn't measure, but I would guess it is less than 10MB
179 2013-08-08 13:45:12 <petertodd> TD: oh good! it's a hard one
180 2013-08-08 13:45:19 <michagogo> Anyway, g2g catch a bus to meet my family for dinner
181 2013-08-08 13:45:20 <michagogo> Bbl
182 2013-08-08 13:45:26 <TD> my suggestion was to have the devices sold via exchanges.
183 2013-08-08 13:45:40 <TD> then use a reverse payment protocol with a trezor-specific pki
184 2013-08-08 13:45:46 <petertodd> TD: I gotta admit the paper solution to it has a lot of plusses for real users
185 2013-08-08 13:45:47 <jgarzik> heh
186 2013-08-08 13:45:58 <TD> trezor gets more distribution and advertising to new users. exchanges can send to trezor securely. users can send from trezor to merchants securely. etc.
187 2013-08-08 13:46:15 <TD> jgarzik: i'm getting the answer for you now.
188 2013-08-08 13:46:22 <TD> jgarzik: (we use ip->asn database as part of a product i used to work on)
189 2013-08-08 13:46:25 <DiabloD3> what the hell is a trezor
190 2013-08-08 13:46:29 <petertodd> TD: trezor-specific is reasonable... though you want to be careful that the attacker can't just MITM the trezor - so anonymous trezor's are probably out :(
191 2013-08-08 13:46:37 <jgarzik> TD, nice, thanks
192 2013-08-08 13:47:54 <gmaxwell> It can probably be compressed a fair bit further if you do some things like include currently unannounced space in the same asn as it's neighbors in order to permit larger prefixes.
193 2013-08-08 13:48:32 <jgarzik> it's a fun lookup-tree problem
194 2013-08-08 13:48:54 <jgarzik> reminds me of how BIND stores its data, for speedy lookups (or used to)
195 2013-08-08 13:50:53 <nsh> since CRIME/BEAST i'm wary of any efforts to add compression to a protocol where it's not absolutely necessary
196 2013-08-08 13:51:00 <nsh> is that foolish?
197 2013-08-08 13:51:33 <gmaxwell> ... nsh, what we're talking to is so completely unrelated I dunno where to start.
198 2013-08-08 13:51:38 <petertodd> speaking of, so I'm thinking everything we do to solve maxconnections/DoS in general by prioritizing peers by "relay work" they do will make it easier to sybil the network, and I'm not seeing a clever way around that, OTOH it forces a sybiler to be useful...
199 2013-08-08 13:51:41 <jgarzik> nsh, yes
200 2013-08-08 13:51:54 <nsh> ok, thanks
201 2013-08-08 13:52:31 <TD> text file with the mapping of subnets to asns is about 2.3mb
202 2013-08-08 13:52:32 <nsh> sometimes i just see words and thoughts occur to me, they're not always related or remotely sensible
203 2013-08-08 13:52:34 <TD> not very large
204 2013-08-08 13:52:36 <jgarzik> Make every P2P node mine a diff-1 share to a p2pool-like entity, to join the network
205 2013-08-08 13:52:44 <jgarzik> must be a valid share for current block
206 2013-08-08 13:52:58 <jgarzik> TD, great
207 2013-08-08 13:52:59 <gmaxwell> petertodd: hm? your protection against sybil is outbound, maxconnection dos is inbound. You can treat them seperately.
208 2013-08-08 13:53:04 <jgarzik> TD, even smaller than I thought
209 2013-08-08 13:53:27 <petertodd> gmaxwell: I'm also thinking sybil as in tracking where every transaction came from.
210 2013-08-08 13:53:56 <petertodd> gmaxwell: But we can make that a lot less effective by not broadcasting every tx to every peer every time.
211 2013-08-08 13:54:38 <gmaxwell> petertodd: go look at how the broadcasting loging works. :P
212 2013-08-08 13:55:12 <petertodd> jgarzik: Too much asymytry between most nodes and people with mining gear. I worked out a memory-hard version - proof of memory posession - and even if you said every peer would have to dedicate 1GB that still winds up just costing ~$100,000 per year to make a connection to every node on a 10k node network.
213 2013-08-08 13:55:34 <jgarzik> ACTION was just joking ;p
214 2013-08-08 13:55:42 <jgarzik> Not realistic at all for Android SPVs
215 2013-08-08 13:55:58 <jgarzik> to pick up just one example
216 2013-08-08 13:57:56 <gmaxwell> jgarzik: http://thyme.apnic.net/current/data-raw-table
217 2013-08-08 13:58:02 <petertodd> gmaxwell: oh good, I misread the trickle code as doing so for our own tx's, so that 1/4 is promising
218 2013-08-08 13:58:47 <petertodd> jgarzik: well... that's the funny thing, for sybil SPV gets a pass, because SPV nodes only see a subset of transactions, so their connection cost is thusly reduced :)
219 2013-08-08 14:03:19 <gmaxwell> I'd suggest squashing out any prefix smaller than /24 (just convert to a /24 if it is otherwise not covered by another prefix) then you can reduce the addresses to 4 bytes (cidr prefix and the mask length). Then just load the whole table into a dumb map and perform up to 24 tests of it to do the longest match match.
220 2013-08-08 14:05:14 <gmaxwell> that list can be reduced further by removing routes that are completely contained in a larger covering route with the same asn.
221 2013-08-08 14:05:26 <petertodd> TD: what's your guess on % of bits set in your average android users bloom filter?
222 2013-08-08 14:06:00 <TD> er, i forgot. it's been months since i looked at that. i could figure it out. the filters have a very close to zero fp rate though, so the % should be low
223 2013-08-08 14:06:21 <petertodd> TD: ballpark 1%? 5%?
224 2013-08-08 14:07:42 <TD> maybe 5? but i don't really know. it's easy to add a few log lines to find out given most users only have a handful of keys, tops, but i'm working on something else right now
225 2013-08-08 14:08:53 <petertodd> k, close enough
226 2013-08-08 14:12:40 <petertodd> gmaxwell: so here's the thing: suppose I have n peers who I send tx's too, and every tx I reliably send to m peers, the if the attacker wants to observe where a tx came from with p probability, they have to make n/m * p connections to me, so for anti-sybil we want more peers, not less, provided the number of peers we do send a tx to immediately is fixed
227 2013-08-08 14:13:54 <petertodd> gmaxwell: it also means with our peer connections, we should use bloom filtering so we can maintain a lot of peers, but without the traffic, and then send tx's to any of those peers, randomly chosen
228 2013-08-08 14:14:30 <petertodd> gmaxwell: heck, we could even pretend to be SPV nodes... though we would want to think hard about memory usage, IE balance it against memory usage for PoW
229 2013-08-08 14:15:56 <petertodd> gmaxwell: the other thing would be to have the concept of a "send-only" peer - a peer who doesn't want any block data at all, but will send us tx's sometimes
230 2013-08-08 14:16:44 <petertodd> point is, for the attacker, they care about listening reliably, not sending, and all this makes it more and more expensive for them to fill up a nodes peer slots that they would *send* txs too
231 2013-08-08 14:20:05 <k9quaint> I have decided to ignore all sentences that begin with "Suppose I have N..."
232 2013-08-08 14:20:21 <k9quaint> it leads to nothing but trouble
233 2013-08-08 14:20:25 <petertodd> k9quaint: I used lower-case n, it's totally different
234 2013-08-08 14:20:53 <k9quaint> I pipe all of my IRC though toupper()
235 2013-08-08 14:21:12 <k9quaint> it makes people seem more passionate about things
236 2013-08-08 14:21:15 <petertodd> k9quaint: better yet - "they have to make $\\frac{n}{m} p$
237 2013-08-08 14:22:06 <k9quaint> I once gave my wife a perl script that printed an ascii necklace
238 2013-08-08 14:22:29 <petertodd> k9quaint: heh, I once cut my gf a ring out of titanium on my lathe in front of her
239 2013-08-08 14:22:42 <k9quaint> did you tell her it was titanium?
240 2013-08-08 14:22:59 <petertodd> k9quaint: well she did ask what was the dreadful noise and smoke from
241 2013-08-08 14:23:16 <k9quaint> "this block of platinum that I am carving you a ring out of dear!"
242 2013-08-08 14:23:42 <petertodd> k9quaint: "uh-huh, I know how broke your artschool ass is"
243 2013-08-08 14:24:57 <k9quaint> "thats why I have been working so long in my meth lab honey"
244 2013-08-08 14:25:18 <k9quaint> then go all Walter White on her
245 2013-08-08 14:25:21 <petertodd> "pff, you're not that cool"
246 2013-08-08 14:25:30 <petertodd> "oh wait..."
247 2013-08-08 14:25:58 <k9quaint> why are you dating smart women?
248 2013-08-08 14:26:07 <k9quaint> houseplants are so much easier to care for
249 2013-08-08 14:26:51 <petertodd> heh... well... I did get dumped in 2nd year after my girlfriend pointed out I had no life and missed her birthday because I had been up for 48 hours working
250 2013-08-08 14:27:54 <nsh> what, you can't reschedule birthdays around hackathons now?
251 2013-08-08 14:28:01 <nsh> pfft
252 2013-08-08 14:28:39 <petertodd> I suspect if it was a hackathon she would have been less pissed... nah, I had a insane client - longest continuous amount of time I've ever billed someone for
253 2013-08-08 14:28:45 <k9quaint> petertodd: I always ran my own NTP server so I wouldn't have that problem
254 2013-08-08 14:28:52 <petertodd> k9quaint: lol
255 2013-08-08 14:29:56 <k9quaint> that and I have 2 reminders for our anniversary in my iphone
256 2013-08-08 14:30:03 <k9quaint> 15 minutes and 5 minutes before ;)
257 2013-08-08 14:30:32 <petertodd> anyway, more to the point, my clever idea doesn't work because your anti-sybil PoW has to be based essentially on probability of getting a tx, and it has to be specific to you and them, so your ability to send tx's out to a lot of peers is hampered and there's no asymetry in the attacker/defender relationship
258 2013-08-08 14:30:41 <petertodd> k9quaint: ha, I gotta do that...
259 2013-08-08 14:32:09 <petertodd> It's also interesting how, come to think of it, something like an identity card *also* doesn't work because nothing is stopping you from just using that one card with a tonne of peers - it really has to be a resource that is tied up per peer pair.
260 2013-08-08 14:34:26 <k9quaint> web of trust protocols always rub me the wrong way a little
261 2013-08-08 14:35:34 <petertodd> what, don't you want to feel connected to your fellow man?
262 2013-08-08 14:35:55 <k9quaint> only in human centipede form
263 2013-08-08 14:36:15 <petertodd> heh
264 2013-08-08 14:41:03 <licnep> can anyone give me a summary of the 0.9 changes or is there something i can read about it?
265 2013-08-08 14:53:40 <gmaxwell> licnep: there are no "the 0.9 changes", 0.9 doesn't exist yet.
266 2013-08-08 14:55:45 <licnep> gmaxwell: yea, but i heard about the introduction of payment requests, signing, description, refund address... i wanted to know more about that
267 2013-08-08 14:56:09 <gmaxwell> Then you're interested in the payment protocol stuff, not 0.9.
268 2013-08-08 14:56:33 <licnep> oh, they told me it was 0.9 stuff, anyway yea that's what i was interested in, the 'payment protocol'
269 2013-08-08 14:58:49 <licnep> oh i found this, https://gist.github.com/gavinandresen/4120476 i'll start therei guess
270 2013-08-08 15:08:01 <sipa> i'd also call it more a "0.9 addition" than a "0.9 change"
271 2013-08-08 15:08:42 <sipa> making it sound like it's a change confuses people :)
272 2013-08-08 15:09:09 <licnep> mhm
273 2013-08-08 15:11:03 <sipa> it's just a new layer on top, to negotiate bitcoin transactions before they hit the network
274 2013-08-08 15:11:41 <licnep> yea
275 2013-08-08 17:32:35 <gmaxwell> Why is someone expecting listransactions "account" to show them sendrawtransaction transactions?
276 2013-08-08 17:35:22 <helo> it should if the sendrawtransaction tx was to/from "account" though, right?
277 2013-08-08 17:50:09 <gmaxwell> helo: how could it be from, it's a sendrawtransaction. To??? yes, it could be to, if you were sending to yourself, but I don't think that isn't working.
278 2013-08-08 17:50:41 <helo> valid point
279 2013-08-08 18:20:00 <Happzz> so how would i go about generating a new address to receive btcs at, without having the actual wallet and private key on the server that generates them
280 2013-08-08 18:20:13 <Happzz> like some commerce system
281 2013-08-08 18:20:36 <Happzz> i can only think of generating a bunch of addresses and then giving the server a list of addresses without the private keys
282 2013-08-08 18:26:52 <helo> type-2 deterministic wallets can allow calculating subsequent addresses without the any private keys
283 2013-08-08 18:27:47 <helo> but that requires something other than bitcoind
284 2013-08-08 18:32:17 <helo> with the payment protocol, the requests will be signed with the private keys sitting on the web server, right?
285 2013-08-08 18:33:12 <helo> so if someone compromises the web server, they'd have access to the private keys, and would be able to forge payment requests to addresses they own?
286 2013-08-08 18:33:17 <MC1984> thats sounds bad
287 2013-08-08 18:33:52 <helo> i don't know much about web server setups, but all of the https setups i've done have the private keys sitting around on the server
288 2013-08-08 18:34:48 <gavinandresen> sure. If you're in the web server, you can simply serve up unsigned payment requests that send money to you, too
289 2013-08-08 18:34:48 <helo> i guess the key used for https wouldn't have to be the same as the key used to sign the payment requests
290 2013-08-08 18:37:59 <gavinandresen> best practice would be for the web server to have a hardware security doo-hickey, so the web server could sign requests but getting the private keys requires physical access to the server
291 2013-08-08 18:38:58 <gmaxwell> gavinandresen: sounds like a feature request tressor!
292 2013-08-08 19:25:10 <Happzz> http or https is irrelevant
293 2013-08-08 19:25:20 <Happzz> i need to generate a bitcoin address to receive payments at
294 2013-08-08 19:25:26 <Happzz> without having the private key around
295 2013-08-08 19:25:34 <Happzz> web servers get rooted too often
296 2013-08-08 19:25:51 <MC1984> TPM?
297 2013-08-08 19:26:35 <phantomcircuit> MC1984, they dont support ecdsa keys in general
298 2013-08-08 19:26:54 <MC1984> aw
299 2013-08-08 19:26:59 <phantomcircuit> yeah
300 2013-08-08 19:27:44 <Happzz> like, what do mtgox use to generate input addresses?
301 2013-08-08 19:27:51 <Happzz> i can't imagine it's all on their webserver
302 2013-08-08 19:28:14 <phantomcircuit> Happzz, they probably generate the addresses somewhere else and then transfer them to the database
303 2013-08-08 19:28:28 <phantomcircuit> that is by far the easiest secure way of going about it
304 2013-08-08 19:28:41 <phantomcircuit> importantly the security model is trivial to understand
305 2013-08-08 19:31:43 <harningt> Happzz: one method of generating independent payment addresses would be to use a deterministic wallet with support for public generation - ex: Electrum w/ its Master Public Key, or BIP 0032 with public derivation - that way, if the web server is hacked, all the attacker knows is the entire payment history... but no coin stolen
306 2013-08-08 19:32:24 <harningt> now, you'd definitely want to generate a new one once hacked, that way you have privacy 'fixed' from then on...
307 2013-08-08 19:33:57 <harningt> another enhancement, if worried about possible attacks on deterministic wallet addresses, would be to have a watcher on those addresses that forwards to another address as soon as a payment went through, that way you divorce your payment infrastructure more strongly from your server (such as funnelling to a single address, but you could also have bitcoind generate new addresses for each transaction forwarded)
308 2013-08-08 19:36:46 <Happzz> i do pay double the fees though that way
309 2013-08-08 19:37:35 <Happzz> other than that.. a watcher might be a clever idea
310 2013-08-08 19:37:55 <gmaxwell> harningt: that means keeping a signing key online, bad bad mojo.
311 2013-08-08 19:37:59 <Happzz> after a second thought, a watcher could be tampered with to forward the payments elsewhere
312 2013-08-08 19:38:05 <Happzz> and it'll take forever to notice
313 2013-08-08 19:38:10 <gmaxwell> For now, just pregenerate addresses **done**.
314 2013-08-08 19:38:13 <harningt> gmaxwell: no it doesn't you have a signing key on your own machine
315 2013-08-08 19:38:24 <harningt> and you run the watcher yourself
316 2013-08-08 19:38:36 <Happzz> so the best bet is to generate a bunch of addresses and just let the webserver pull an address from that list?
317 2013-08-08 19:38:54 <gmaxwell> harningt: it means the a key controling live funds is online and connected to the internet, this is not a best practice. Plus you double your transaction load, ::yawn::.
318 2013-08-08 19:39:01 <Happzz> is there a way to import a massive amount of addresses to bitcoin-qt or something?
319 2013-08-08 19:39:14 <harningt> Happzz: that also works well, have a setup locally that asks your webserver if it needs addresses, and then can get it generated
320 2013-08-08 19:39:41 <Happzz> i don't want my webserver to even know where the real money is placed
321 2013-08-08 19:39:46 <harningt> gmaxwell: that is true, so you could omit the watcher tool
322 2013-08-08 19:39:50 <Happzz> not to mention connectivity between the two
323 2013-08-08 19:39:52 <gmaxwell> Happzz: there is an import RPC. though in this case you wouldn't need it.
324 2013-08-08 19:40:11 <harningt> ah, webserver not knowing where the money is,.... now that's tricky
325 2013-08-08 19:40:23 <gmaxwell> No, thats not tricky.
326 2013-08-08 19:40:27 <harningt> I guess you could have it written such that once it saw a deposit made, it deletes the address
327 2013-08-08 19:40:47 <gmaxwell> Just @#$@# pregenerate a ton of keys and periodically refill it.
328 2013-08-08 19:40:58 <harningt> but that means the server knows where the money is
329 2013-08-08 19:41:18 <harningt> indirectly - someone compromising server sees the addresses where money was put in
330 2013-08-08 19:41:22 <Happzz> harningt it knows the addresses. i have no issue with that.
331 2013-08-08 19:41:27 <harningt> oh... ok
332 2013-08-08 19:41:31 <Happzz> i don't want the webserver to know where the keys are
333 2013-08-08 19:41:37 <harningt> thought from the webserver knowing where real money is place
334 2013-08-08 19:41:38 <Happzz> that's what i mean "where the money is"
335 2013-08-08 19:41:39 <harningt> got it
336 2013-08-08 20:05:50 <helo> how does one detect the case where an attacker has compromised a server and replaced your list of pregenerated addresses with his own?
337 2013-08-08 20:15:03 <helo> i guess periodic auditing bots that make purchases through the site and verify that the funds are recieved
338 2013-08-08 20:18:58 <nsh> hmm
339 2013-08-08 22:45:08 <sipa> wow, there's featherscoin.com, looking remarkably similar to feathercoin.com, but linking to a different download...
340 2013-08-08 22:46:02 <c0rw1n> lulz
341 2013-08-08 22:46:32 <c0rw1n> 'neone to wireshark that in a vm?
342 2013-08-08 22:47:03 <c0rw1n> am too drunk and sleepy
343 2013-08-08 22:47:15 <c0rw1n> was my mom's bday
344 2013-08-08 22:47:24 <c0rw1n> good good winez
345 2013-08-08 23:04:24 <gmaxwell> sipa: careful with the stuff sipa!