1 2014-01-07 00:00:12 <andytoshi> gmaxwell: do you have a good link offhand for learning about this?
2 2014-01-07 00:00:13 <shesek> right. well, it is a lot more work to do this p2p
3 2014-01-07 00:00:15 <sipa> gmaxwell: still, i have no clue about it - i'm pretty good at ignoring very interesting stuff around me when my brain bandwidth is saturated already
4 2014-01-07 00:00:31 <andytoshi> (i'm in exactly the same boat as sipa)
5 2014-01-07 00:00:48 <shesek> ACTION is too :)
6 2014-01-07 00:01:27 <blochchain> sipa: can you elaborate?
7 2014-01-07 00:01:39 <gmaxwell> andytoshi: the older pairing crypto papers are actually pretty hard to read. I'm trying to remember which one it was that I liked.
8 2014-01-07 00:01:59 <sipa> blochchain: "the blockchain" is a pretty abstract concept
9 2014-01-07 00:02:07 <gmaxwell> andytoshi: basically every single paper on any protocol using paring crypto explains the algebraic level understanding over again.
10 2014-01-07 00:02:22 <sipa> blochchain: you're talking about the blk*.dat files created by the reference client, not about the blockchain in general, right?
11 2014-01-07 00:02:40 <andytoshi> gmaxwell: thx, i'll skim the preprint archive then
12 2014-01-07 00:03:06 <gmaxwell> andytoshi: e.g. see the list at the top of page 9 in https://www.dropbox.com/s/nkh22cibel8stb4/horasyuanmouton.pdf you can see that same list in dozens of papers
13 2014-01-07 00:03:10 <blochchain> i know, sipa. i'm pretty well-versed in this stuff. i've just always used other people's blockchain parsers and now i'm writing my own
14 2014-01-07 00:03:10 <sipa> also, those files are an on-disk representation of the whole block tree, not just the block chain currently active
15 2014-01-07 00:03:12 <sipa> blochchain: but apart from that, yes
16 2014-01-07 00:05:40 <maaku> blochchain: fyi, blocks may be out of order in the blk*.dat files
17 2014-01-07 00:08:10 <gmaxwell> andytoshi: in any case you can go pretty far understanding nothing other than you have some special group G1 allowing a computable map 'pairing()' G1xG1->G2 such that pairing(g1_a^x,g1_b^y) == pairing(g1_a,g1_b)^xy (this is a symetric pairing there are G1xG2->G3 ones too, but they're more rarely needed). This criteria would be easy to achieve but then we also require the discrete log problem be hard in G1.
18 2014-01-07 00:08:47 <sipa> maaku: no
19 2014-01-07 00:08:52 <sipa> maaku: not yet
20 2014-01-07 00:09:09 <gmaxwell> Actually how the map is computed is pure mystery to me,... but all the useful algebra follows naturally from that definition.
21 2014-01-07 00:09:14 <blochchain> yeah that would strike me as odd
22 2014-01-07 00:09:20 <andytoshi> gmaxwell: thanks!
23 2014-01-07 00:09:20 <blochchain> (sipa and maaku)
24 2014-01-07 00:09:23 <maaku> sipa: I've encountered that in my own blk files. is that from an old version of bitcoind?
25 2014-01-07 00:09:33 <blochchain> considering that you need all previous blocks to verify a new block
26 2014-01-07 00:09:39 <sipa> maaku: have you used any headersfirst version?
27 2014-01-07 00:09:49 <sipa> because those break that assumption
28 2014-01-07 00:09:52 <maaku> ah yes
29 2014-01-07 00:10:03 <sipa> current -reindex relies on the blocks being in order
30 2014-01-07 00:10:32 <shesek> andytoshi, how active is your coinjoin service?
31 2014-01-07 00:10:39 <gribble> Coinjoin Status: There is no currently open session. Visit https://www.wpsoftware.net/coinjoin/ or http://xnpjsvp7crbzlj3w.onion/ to start one.
32 2014-01-07 00:10:39 <maaku> ;;cjs
33 2014-01-07 00:11:43 <andytoshi> shesek: if i go on #bitcoin and say "coinjoin in an hour", i have roughly a 50% chance of getting gmaxwell to join, 10% chance of anybody else
34 2014-01-07 00:12:00 <andytoshi> to the best of my knowledge nobody has used it without prompting <.<
35 2014-01-07 00:12:30 <shesek> how about perhaps setting some set time for everyone to come?
36 2014-01-07 00:12:51 <shesek> or possibly just making the session duration longer, and send some notifications when its ready for signing?
37 2014-01-07 00:13:10 <andytoshi> shesek: yeah, gmaxwell has suggested this to me repeatedly .. i will do it when i get around to it ;)
38 2014-01-07 00:13:22 <gmaxwell> I think it's still just too hard to use for people who don't regularly use raw transactions.
39 2014-01-07 00:13:28 <andytoshi> you are welcome to write an IRC bot which shows up a few times a day to say "coinjoin at 5PM pacific" or whatever
40 2014-01-07 00:13:49 <shesek> gmaxwell, I was thinking to write a web interface for that which'll do the transaction creation/signing with bitcoinjs-lib
41 2014-01-07 00:14:21 <andytoshi> shesek: your browser can't see your coins
42 2014-01-07 00:14:22 <andytoshi> i hope
43 2014-01-07 00:14:57 <shesek> but its somewhat hard to get the funds into an output the web interface can control - it'll require either asking the user for a private key (which might contain funds that the user doesn't want to join, and they'll probably won't like that idea much generally) or create a new address that's controlled by the web interface and ask it to send the funds there first
44 2014-01-07 00:15:10 <petertodd> shesek: I'd suggest writing an electrum plugin actually
45 2014-01-07 00:15:21 <shesek> but its an extra transaction, which'll also be mined shortly before the coinjoin transaction
46 2014-01-07 00:15:30 <shesek> which would make it easy to identify coinjoin txs
47 2014-01-07 00:15:36 <petertodd> shesek: someone already did so for blockchain.info's shared send service (not the CJ one) and it works fine
48 2014-01-07 00:16:01 <gmaxwell> electrum has plugins?
49 2014-01-07 00:16:05 <shesek> I didn't look much into it, how does it work?
50 2014-01-07 00:16:07 <petertodd> gmaxwell: yup
51 2014-01-07 00:16:10 <gmaxwell> cool
52 2014-01-07 00:16:22 <petertodd> shesek: dunno, some kind of file goes in a magic directory and there's some hooks or something
53 2014-01-07 00:17:01 <shesek> oh wait, didn't notice you wrote "not the cj one"
54 2014-01-07 00:17:24 <shesek> and I meant what you said about blockchain.info, not electrum plugins
55 2014-01-07 00:17:26 <petertodd> shesek: yeah, either way though, I'm sure the plugin system could let you write a CJ plugin
56 2014-01-07 00:17:48 <shesek> and yes, something like this does make sense more as a desktop client with access to the user's wallet rather than a web interface
57 2014-01-07 00:17:50 <petertodd> shesek: ah, yeah, there's no such thing as a bc.i plugin AFAIK, er, well other than what some hackers probably have :P
58 2014-01-07 00:19:43 <shesek> I was referring to "someone already did so for blockchain.info's shared send service", not to bc.i plugins
59 2014-01-07 00:20:07 <petertodd> shesek: right, well that *does* have an API is my understanding
60 2014-01-07 00:25:12 <maaku> petertodd: ugh my email was ambiguous
61 2014-01-07 00:26:33 <maaku> the authenticated prefix tree BIP provides a compact Merkle data structure for representing the dictionary of scriptPubKey -> (inputs, outputs) committed to each block
62 2014-01-07 00:26:48 <maaku> same general data structure, but these are not UTXO proofs
63 2014-01-07 00:27:07 <maaku> since you want access to all inputs or all outputs, regardless of spent-ness
64 2014-01-07 00:27:31 <maaku> and you have applications for both TXIN and TXOUT commitments?
65 2014-01-07 00:33:22 <michagogo> cloud|Hmm, anyone happen to know if `nc` et al can take input to send from a file?
66 2014-01-07 00:33:39 <michagogo> cloud|If so, 2:13:28 <andytoshi> you are welcome to write an IRC bot which shows up a few times a day to say "coinjoin at 5PM pacific" or whatever
67 2014-01-07 00:33:59 <michagogo> cloud|Could probably do that with cron and a script
68 2014-01-07 00:34:34 <sipa> michagogo|cloud: nc host port <file
69 2014-01-07 00:35:00 <michagogo> cloud|Figured.
70 2014-01-07 00:36:06 <michagogo> cloud|andytoshi, idea: allow the user, when submitting a tx to coinjoiner, to specify how long they're willing to wait to get into a round
71 2014-01-07 00:36:17 <michagogo> cloud|That would allow you to make bigger rounds
72 2014-01-07 00:37:49 <andytoshi> well, the concern is that people will forget about transactions and then jam the joiner without meaning to
73 2014-01-07 00:38:05 <andytoshi> (ofc if they jam it deliberately, there's not much i can do without killing usability)
74 2014-01-07 00:38:52 <michagogo> cloud|andytoshi: ooh, maybe find an SMS gateway to use?
75 2014-01-07 00:39:02 <michagogo> cloud|(Only half kidding there)
76 2014-01-07 00:39:14 <andytoshi> :P that'd be great
77 2014-01-07 00:39:15 <shesek> michagogo|cloud, why sms? with everyone having smartphones, email should suffice\
78 2014-01-07 00:39:21 <andytoshi> "the next 5 messages are my raw tx"
79 2014-01-07 00:39:33 <shesek> can't SIGHASH_SINGLE be used and ask the user's signature in advance?
80 2014-01-07 00:39:46 <andytoshi> shesek: that ties inputs to outputs
81 2014-01-07 00:39:55 <shesek> though it'll only allow one-to-one mapping between inputs and outputs
82 2014-01-07 00:39:57 <michagogo> cloud|andytoshi: I meant for notifying/reminding, not submitting :P
83 2014-01-07 00:40:00 <shesek> oh. right.
84 2014-01-07 00:40:11 <andytoshi> michagogo|cloud: ohh, then that's a pretty good idea
85 2014-01-07 00:40:15 <shesek> that was silly :)
86 2014-01-07 00:40:24 <michagogo> cloud|shesek: heh, that defeats the pur-yeah
87 2014-01-07 00:40:37 <petertodd> maaku: well txin *contents* yes, but I'm dubious about providing that given how niche the application is
88 2014-01-07 00:40:53 <andytoshi> shesek: it also forces you to use as many inputs as outputs, otherwise i'd say "better than nothing"
89 2014-01-07 00:41:20 <andytoshi> in that it'd be easier to use and would force analyzers to understand the protocol a little better
90 2014-01-07 00:41:45 <shesek> I'm not sure if a false sense of security is really better than nothing in this case
91 2014-01-07 00:42:01 <petertodd> maaku: txout contents, absolutely a index would be useful
92 2014-01-07 00:42:04 <gmaxwell> shesek: "it depends"
93 2014-01-07 00:42:12 <michagogo> cloud|shesek: wait, why are *you* still up? :-P
94 2014-01-07 00:42:37 <shesek> heh, I'm almost always up at these hours :)
95 2014-01-07 00:42:46 <gmaxwell> shesek: part of the purpose here is to prevent non-coinjoin users from being harmed by graph analysis... if we make graph analysis tools give useless results thats helpful.
96 2014-01-07 00:44:43 <shesek> how would that make graph analysis less useful?
97 2014-01-07 00:45:01 <shesek> it should be quite trivial to notice its SIGHASH_SINGLE and handle it properly
98 2014-01-07 00:46:01 <andytoshi> well, it's trivial if you know to do it..
99 2014-01-07 00:46:40 <andytoshi> also, if i saw a SIGHASH_SINGLE tx today i'd think "this is something weird" and not have any idea how many people were involved or the nature of the transaction
100 2014-01-07 00:46:53 <petertodd> andytoshi: actually SIGHASH_SINGLE ties a single input to a single output *and* the index of that output, unfortunately
101 2014-01-07 00:47:52 <petertodd> andytoshi: which in turn implies the index of the input too...
102 2014-01-07 00:48:14 <gmaxwell> yea, point.
103 2014-01-07 00:48:15 <andytoshi> petertodd: understood, but unless you can say for sure "this is a coinjoin" you don't know if the input and output are owned by the same person, nor do you know which inputs are owned by the same people
104 2014-01-07 00:48:20 <gmaxwell> ACTION shakes his fist at the sighash flags
105 2014-01-07 00:48:27 <andytoshi> shesek: agreed that we are providing no actual security here
106 2014-01-07 00:48:42 <andytoshi> i'm just suggesting that we'd be confusing bad guys more than if we weren't doing anything at all
107 2014-01-07 00:48:56 <shesek> well, I wouldn't want to be some freedom fighter somewhere who counted on coinjoin to hide him and then got caught by the authorities because of something like this
108 2014-01-07 00:49:01 <shesek> a false sense of security can be really harmful
109 2014-01-07 00:49:14 <petertodd> andytoshi: right, well it's more complex than that too, the input txins are committed to with SIGHASH_SINGLE unless used with ANYONECANPAY
110 2014-01-07 00:49:21 <shesek> it was just a really really silly suggestion, I blame the the hour for that (its almost 3am here)
111 2014-01-07 00:49:36 <andytoshi> petertodd: oh, i didn't realize that, that's irritating
112 2014-01-07 00:50:12 <andytoshi> gmaxwell: i've spent some time thinking about what sighash flags an alt might have to enable easy transaction pasting..
113 2014-01-07 00:50:27 <gmaxwell> shesek: right, it's important to be clear about whats going on.
114 2014-01-07 00:50:30 <petertodd> andytoshi: yup, now you can play weird games using both where you have the first input sign an output of greater value, and then the next one make up the difference, but that gets limiting quick and probably doesn't do much for privacy
115 2014-01-07 00:50:37 <andytoshi> ..and it seems like there is no way to have transactions (a) be tamper-proof, and (b) be stapleable together without clearly being identifiable
116 2014-01-07 00:50:47 <gmaxwell> andytoshi: well, that OWAS paper is what you want if you want private transaction pasting.
117 2014-01-07 00:51:17 <gmaxwell> andytoshi: thats exactly what that OWAS paper I linked to earlier does, at the expense of moon math. (using pairing signatures)
118 2014-01-07 00:52:27 <andytoshi> gmaxwell: oh, nice
119 2014-01-07 00:52:27 <andytoshi> i'll try to get to that one this week then
120 2014-01-07 00:52:27 <petertodd> gmaxwell: the number of times that we need to invoke moon math is suggesting to me that bitcoin needs to go to the moon
121 2014-01-07 00:52:38 <shesek> â(°0°)â
122 2014-01-07 00:52:43 <shesek> (sorry, couldn't resist)
123 2014-01-07 00:53:10 <shesek> :)
124 2014-01-07 00:54:44 <maaku> petertodd: well the txin contents are in the utxo delta + block contents
125 2014-01-07 00:55:29 <petertodd> maaku: right, but a standard and useful query to make is "has this txout been spent?"
126 2014-01-07 00:55:43 <maaku> txout index would be looking for your coins, yes? what's the niche use of the txin index?
127 2014-01-07 00:56:18 <petertodd> maaku: the niche application is to be able to get a sorted list of scriptSig, or even <pushdata in scriptsig> like bloom filters do - but I don't think we should go down that route
128 2014-01-07 00:57:17 <petertodd> maaku: the other interesting question is can whatever sorted trees we wind up with be generated co-operatively by multiple nodes without any one node having all the data (or bandwidth cost)
129 2014-01-07 00:58:01 <petertodd> maaku: bonus if you can somehow do that between untrusted nodes - but good luck there...
130 2014-01-07 01:00:23 <Azra-el> probably not the right channel to ask but i dunno where to ask it. is there a limit on how short a block time should be? i mean.. would ~40 seconds be too low?
131 2014-01-07 01:00:51 <petertodd> Azra-el: speed of light is a consideration if you want your coin to be decentralized
132 2014-01-07 01:01:29 <Azra-el> mkay.. meaning? how fast would a signal travel or ?? :)
133 2014-01-07 01:01:33 <petertodd> Azra-el: it's a tradeoff; there's no one right answer. keep in mind though that from a consumers point of view anything over a few seconds is much too long for a payment
134 2014-01-07 01:02:03 <Azra-el> i know that. but if i understood correctly ... too short of a block time can generate orphans?
135 2014-01-07 01:02:19 <petertodd> Azra-el: quite literally that. circumfrence of the earth * speed of light * big fudge-factor is a absolutely minimum time for the block to propagate
136 2014-01-07 01:02:38 <petertodd> Azra-el: exactly, and even worse, it means that large, more centralized, pools are making more money than the small ones
137 2014-01-07 01:02:47 <petertodd> (you never orphan yourself)
138 2014-01-07 01:03:06 <Azra-el> but is there an estimate of the lowest ?
139 2014-01-07 01:03:26 <maaku> Azra-el: geistgeld imploded with a time of something like 15s, iirc
140 2014-01-07 01:03:31 <andytoshi> Azra-el: feathercoin has had serious convergence issues as well
141 2014-01-07 01:03:36 <petertodd> Azra-el: that's like saying "how safe should a schoolbus be?"
142 2014-01-07 01:03:37 <maaku> that's definately way, way too low
143 2014-01-07 01:04:09 <petertodd> maaku: what blocksize did geistgeld have?
144 2014-01-07 01:04:19 <andytoshi> Azra-el: you also have to consider how big your blocks are, and how big they could be in the future, and how hard validation is...
145 2014-01-07 01:04:23 <maaku> petertodd: originally 7 seconds, then hard forked to 15s iirc
146 2014-01-07 01:04:33 <petertodd> maaku: size, not time :)
147 2014-01-07 01:04:51 <maaku> oh standard 1mb I think ... but i doubt they ever hit that
148 2014-01-07 01:05:00 <petertodd> maaku: lol!
149 2014-01-07 01:05:03 <maaku> that'd be interestint to find out
150 2014-01-07 01:05:14 <petertodd> maaku: I don't think I've ever seen an alt change that parameter...
151 2014-01-07 01:05:22 <petertodd> BlueMatt: ^
152 2014-01-07 01:05:35 <Azra-el> you lost me a bit on the blocksize. need to look that up :)
153 2014-01-07 01:05:45 <petertodd> Azra-el: yes, you do...
154 2014-01-07 01:05:49 <maaku> Azra-el: you will find that opinions differ. IMHO, *unless* you can get point-of-sale speeds of <1s (you can't), then you want the *largest* interblock time acceptable
155 2014-01-07 01:06:12 <andytoshi> my thoughts are exactly what maaku said
156 2014-01-07 01:06:38 <maaku> 2 minutes, 5 minutes, 10 minutes confirmation time doesn't make a difference in practice
157 2014-01-07 01:06:45 <sipa> did anyone ever make an altcoin with a block time >10 minutes?
158 2014-01-07 01:06:47 <maaku> but it has huge implications for SPV
159 2014-01-07 01:06:48 <Azra-el> maaku ... POS times of <1s are bullshit ...
160 2014-01-07 01:06:49 <petertodd> I set steamcoin to have a 1 month blocktime so that clipper ships could ferry blocks across the atlantic
161 2014-01-07 01:07:30 <petertodd> Azra-el: remember that actual inter-block interval is a random poisson distribution, if you set block interval to 1s, you still get 10s waits, etc.
162 2014-01-07 01:07:41 <maaku> ACTION adds "MarsCoin" with a 30 minute block time to his todo list
163 2014-01-07 01:07:55 <andytoshi> again, maaku types my thoughts...
164 2014-01-07 01:07:59 <petertodd> Azra-el: set it to a "fast" 10s and you get nearly two minute waits...
165 2014-01-07 01:08:32 <Azra-el> petertodd again... im just dipping my toes in the water .. a lot of missing knowledge.. but i'll get there
166 2014-01-07 01:09:14 <gmaxwell> shorter blocktimes also dramatically increase costs for lite nodes. 600x more data is not fun.
167 2014-01-07 01:09:27 <Azra-el> dogecoin has 60s afaik right?
168 2014-01-07 01:09:32 <petertodd> gmaxwell: a MMR could help that
169 2014-01-07 01:09:35 <sipa> who cares about dogecoin?
170 2014-01-07 01:09:37 <gmaxwell> and in doing so also increase costs for proof systems.
171 2014-01-07 01:09:58 <Azra-el> sipa ... it's a discussion .. not a validation of the coin .. :)
172 2014-01-07 01:10:01 <gmaxwell> petertodd: I've thought that before, but actually proof of sum difficulty is perhaps harder than it seems.
173 2014-01-07 01:10:21 <petertodd> gmaxwell: why doesn't interactive sampling work?
174 2014-01-07 01:10:41 <gmaxwell> petertodd: interactive can work, NI proofs end up being big though.
175 2014-01-07 01:11:00 <petertodd> gmaxwell: right, though for SPV I think interactive should be ok
176 2014-01-07 01:11:10 <gmaxwell> Interactive doesn't work in all contexts, consider the 2-way-binding stuff where a NI SPV proof gets embeded in the host chain.
177 2014-01-07 01:11:50 <gmaxwell> And a cut and choose needs a fairly large number of points to get acceptable security.
178 2014-01-07 01:12:16 <gmaxwell> (I mean a fiat-shamir ni cut and choose)
179 2014-01-07 01:12:16 <petertodd> gmaxwell: yeah, niche application though :) anyway, more likely is you'd be doing this for some kind of blockdag anyway
180 2014-01-07 01:13:21 <gmaxwell> petertodd: I don't think NI-SPV is that niche, it's applicable to all sorts of things, e.g. fidelity bonds/sin for example.. or data timestamping. any place where you want to verify data from bitcoin outside of bitcoin.
181 2014-01-07 01:14:14 <petertodd> gmaxwell: I mean if you actually had a 1s blockchain, it'd be some merging blockdag in which case I haven't thought through exactly how it'd work
182 2014-01-07 01:16:28 <gmaxwell> petertodd: yea, well high hashvalue highway.. where you are merged mining a bunch of octave levels.. e.g. diff 1x 2x 4x 8x 16x 32x... all link back to the last at the same multipler
183 2014-01-07 01:16:39 <gmaxwell> and then you can actually get compact proofs.
184 2014-01-07 01:21:04 <Azra-el> now i have a question about nTargetTimespan .. any rules on that?
185 2014-01-07 01:23:23 <maaku> Azra-el: grep the source for where it's used
186 2014-01-07 01:23:28 <maaku> it's only a handful of locations
187 2014-01-07 01:24:41 <Azra-el> well as far as i understand it... it's the amount of time it takes until the diff is recalculated am I correct?
188 2014-01-07 01:26:01 <maaku> yes
189 2014-01-07 01:28:42 <Azra-el> bitcoin is 2 weeks.. litecoin is 3.5 days ... so with 10 min per block ... retargeting on bitcoin is done @ 2016 blocks ... with 2.5 min per block retargeting on litecoin is done @ 2016 also
190 2014-01-07 01:29:58 <maaku> Azra-el: this isn't #design-your-altcoin-help
191 2014-01-07 01:30:19 <maaku> we'll entertain questions so long as they are technically interesting
192 2014-01-07 01:30:31 <maaku> but it is off topic
193 2014-01-07 01:30:43 <Azra-el> it is not. of course. for me personally right now it's an opportunity to learn. what's behind the reasoning. i'm sorry for the trouble i guess
194 2014-01-07 01:31:12 <maaku> ok in that mindset, remember that PoW is a random (Poisson) process
195 2014-01-07 01:31:28 <maaku> so at the same hashrate, the next block could be 2 minutes, 10 minutes, or 2 hours from now
196 2014-01-07 01:31:57 <maaku> you need a large window therefore to get a large number of samples to get an accurate read of what the current hash rate is, to know how much to adjust it
197 2014-01-07 01:32:37 <maaku> or you can do something more complicated than a simple average, but alas that is what Satoshi chose
198 2014-01-07 01:32:47 <Azra-el> i see.
199 2014-01-07 01:34:24 <maaku> IIRC, with 2016 samples you should expect about 0.5% variance
200 2014-01-07 01:35:46 <Azra-el> so bottom line it's called target because that's in "optimal" conditions, when one block comes at 10 minutes after the other ... it might come in 2 minutes .. or in 30 minutes.. is an approximation. and so is the targetTimespan .. an aproximation of how long it would take 2016 blocks.
201 2014-01-07 01:35:53 <Azra-el> am I in the vicinity?
202 2014-01-07 01:36:53 <maaku> yes.
203 2014-01-07 01:37:15 <Azra-el> phew
204 2014-01-07 01:37:42 <maaku> it's supposed to take 14 days. let's say it actually took 13. then the network is 14/13 = 107.7% it's previous speed, and so the difficulty increases by that amount
205 2014-01-07 01:38:34 <Azra-el> anyway thank you for your patience. i'm just a bit fascinated at the moment with the whole thing .. whats going on behind the scenes...
206 2014-01-07 01:39:18 <maaku> no worries, keep the questions focused on bitcoin and you'll get help here (if it's source code related, otherwise #bitcoin)
207 2014-01-07 01:39:46 <Azra-el> it increases with 7.7% right? and if it takes 20 days .... the network hashrate is lower hence the diff will decrease
208 2014-01-07 01:39:56 <maaku> yes
209 2014-01-07 01:40:14 <maaku> with a cap of no more than 4x in either direction
210 2014-01-07 01:41:07 <Azra-el> im trying to keep it related to the coin . ofc i'm making an alt to see what is what. for example this .. .the 2016 blocks i didn't know that it was chosen because of the variance due to the poisson distribution
211 2014-01-07 01:43:33 <Azra-el> but i'm mainly doing this because I want to understand the behind the scenes.. because i had an idea about a POS device... and I'm trying to see if its complete bullcrap or not :)
212 2014-01-07 01:45:56 <theorbtwo> Azra-el: I think it's more fair to say that 2016 comes from 10 minutes and two weeks then that 2016 comes from the poisson distribution. The poisson distribution is why it can't be 10 minutes and 10 minutes, but given that 10 minutes and a fortnight are nice even human numbers and 2016 isn't...
213 2014-01-07 01:47:00 <Azra-el> lol yeah that's what i meant ...
214 2014-01-07 02:26:08 <wyager> gmaxwell: What did you mean when you said there was research to make embedding data in the blockchain "impossible"?
215 2014-01-07 02:27:34 <gmaxwell> wyager: several people have been working on techniques that can be used to prevent using the network to store or relay unrelated data.
216 2014-01-07 02:28:02 <wyager> Interesting. Any suggested reading? Can't see how that's feasible in a general context
217 2014-01-07 02:28:58 <gmaxwell> wyager: Well the first idea in this space was my p2sh^2 idea: http://sourceforge.net/mailarchive/message.php?msg_id=30705609
218 2014-01-07 02:29:12 <gmaxwell> which I elaborated on at https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less
219 2014-01-07 02:29:42 <gmaxwell> though there are now some more powerful ideas that haven't been published yet which also keep the data off the relay network.
220 2014-01-07 02:32:10 <wyager> Ha
221 2014-01-07 02:32:18 <wyager> I like the p2sh^2 thing
222 2014-01-07 02:33:52 <gmaxwell> I dunno if we'll ever deploy something like that in Bitcoinâ perhaps not. But data storage is a potential threat to the system, so it's good to have tools up our sleeves.
223 2014-01-07 02:33:59 <wyager> So the goal is to prevent unprunable data storage, not data storage in general? That is a much more feasible goal :p
224 2014-01-07 02:34:09 <wallet42> what about OP_RETURN?
225 2014-01-07 02:34:18 <wyager> He mentioned that too
226 2014-01-07 02:34:22 <wyager> hash the data before it
227 2014-01-07 02:34:28 <wyager> you can prune the data and keep the hash
228 2014-01-07 02:34:48 <gmaxwell> wyager: earlier today in here I described a self-certifyable hash, a hash that proves its a hash.
229 2014-01-07 02:35:04 <wyager> Interesting...
230 2014-01-07 02:35:11 <wyager> How?
231 2014-01-07 02:35:18 <gmaxwell> wyager: I can prevent data storage in general too though p2sh^2 didn't discuss that.
232 2014-01-07 02:36:29 <gmaxwell> wyager: http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/01/06#l1389050948
233 2014-01-07 02:37:01 <wyager> With the same concept? Just make people hash everything so you can prune the storage? Or actually prevent it from going in the chain in the first place?
234 2014-01-07 02:38:12 <gmaxwell> wyager: actually prevent the data in the first place (basically only allow data which you can prove is hashed/encrypted/etc)
235 2014-01-07 02:38:21 <wyager> I see
236 2014-01-07 02:38:28 <wyager> I'm reading the self-certifying hash thing now
237 2014-01-07 02:40:38 <Luke-Jr> wyager: the goal is to prevent data storage completely
238 2014-01-07 02:41:27 <Luke-Jr> wallet42: OP_RETURN is "we can't stop you from raping us at the moment, so please be gentle!"
239 2014-01-07 02:42:40 <wyager> so you want to scrap it?
240 2014-01-07 02:42:50 <wyager> or just enforce certifiably hashed data?
241 2014-01-07 02:43:12 <Luke-Jr> wyager: none of the stop-data-storage proposals so far are practical to be deployed
242 2014-01-07 02:43:24 <Luke-Jr> (outside of an emergency situation, anyhow)
243 2014-01-07 02:44:23 <gmaxwell> There are two major areas of risk data storage creates for bitcoin: If data storage people outbid transactions for space, it will reduce the usefulness of bitcoin as a currency, perhaps creating a vicious cycle which ends in thats all bitcoin is useful for, and if people abuse bitcoin to store unlawful data it may create pressure to censor the system that causes centralization (e.g. you're not allowed to run your own node because ...
244 2014-01-07 02:44:29 <gmaxwell> ... syncing it up requires feteching the bad data), this would be multiplied by the data requiring huge amounts of storage meaning it was costly to run a node regardless.
245 2014-01-07 02:45:02 <gmaxwell> who knows if these problems will ever be pratical, â but it would be good to have the technology know to address those things. And the threat of deploying them may discourage some of the abusive uses.
246 2014-01-07 02:45:37 <gmaxwell> (There are other blockchains specifically for storing data... uh. I think it's a terrible idea, but hey, their systemâ I wish them luck)
247 2014-01-07 02:45:51 <gmaxwell> (e.g. "Datacoin")
248 2014-01-07 02:48:35 <wyager> I see. I must admit, from a political perspective I am very wary of an proposal to "censor" the blockchain. But I agree that it's good to have the tech ready to use, and obviously there are practical reasons that may outweigh political ones
249 2014-01-07 02:49:50 <gmaxwell> wyager: Bitcoin is not a censorship resistant system to begin with, miners may/can/do freely filter thingsâ and if they didn't someone with a simple while true loop would totally blow up the system.
250 2014-01-07 02:50:07 <Luke-Jr> wyager: the blockchain was never intended for data, and putting data in it is forcing people to store it against their consent. it's also entirely void of real use cases.
251 2014-01-07 02:50:12 <gmaxwell> basically by excluding data that would try to make bitcoin interesting to censor, bitcoin as a whole becomes more robust.
252 2014-01-07 02:50:59 <petertodd> gmaxwell: currently they can't effectively filter things if they don't know what they are, hence if the threat model is blacklists steganography works just fine
253 2014-01-07 02:51:09 <gmaxwell> yea, usually the arguments for storing data in the blockchain are pretty terrible, e.g. cost externalization ("I'll make these bitcoin people reliably store my data for me") or just misguided, e.g. "I want to timestamp my data"â which can be done.
254 2014-01-07 02:51:28 <gmaxwell> petertodd: yea, well thats why I mentioned before "prove the data was encrypted"
255 2014-01-07 02:51:47 <gmaxwell> er "I want to timestamp my data" â which can be done without putting the data into bitcoin
256 2014-01-07 02:51:59 <wyager> Luke-Jr: By that logic, couldn't you argue that everyone is "forced to store data against their consent"? What if I don't want to store P2SH transactions? Obviously this is a facetious example, but I would be very wary about making such arguments
257 2014-01-07 02:52:24 <gmaxwell> wyager: Just because an argument doesn't yield crisp boundaries doesn't mean it can't inform a discussion.
258 2014-01-07 02:52:30 <wyager> Of course
259 2014-01-07 02:52:35 <Luke-Jr> wyager: we all bought into bitcoin with the understanding that full nodes need to store the data for *bitcoin transactions*
260 2014-01-07 02:52:39 <petertodd> gmaxwell: I'm not talking about hypothetical future scenarios, I'm talking about the reality right now + blacklists
261 2014-01-07 02:53:05 <Luke-Jr> wyager: so, every single person using bitcoin has consented to storing that data
262 2014-01-07 02:53:07 <petertodd> gmaxwell: right now the blockchain *is* a pretty good jam-proof network if you can afford it
263 2014-01-07 02:53:12 <gmaxwell> wyager: you can't draw brightline rules from what luke's saying but in principle, bitcoin is a digital currencyâ there really isn't any ambiguity about that. People creating 1e-8 value outputs to store data ... is really an unrelated use.
264 2014-01-07 02:53:48 <gmaxwell> wyager: so even though there is perhaps a slippery slope that makes drawing a rule out of it hard, it's still an important point.
265 2014-01-07 02:54:32 <gmaxwell> Also, as I said, flip side, miners can't not censor in some manner or the first genius with while true {send to myself} takes the system out.
266 2014-01-07 02:55:54 <petertodd> gmaxwell: I'm not going to call a fixed blocksize censorship any more than I'd call "you can't afford to buy a front-page ad on the times" censorship
267 2014-01-07 02:56:01 <gmaxwell> petertodd: very low data rate at least. We can't totally close subliminal channels. I think we can come pretty close.
268 2014-01-07 02:56:32 <gmaxwell> petertodd: it is a kind of censorship, esp in the presence of hostile forces which would outbid you specifically with the intent of displacing you.
269 2014-01-07 02:56:43 <gmaxwell> (something which has been done in advertising, in fact!)
270 2014-01-07 02:57:27 <wyager> Agreed. But I am afraid of creating a precedent of being excessively focused on making sure only data that "belongs" in the blockchain goes there.
271 2014-01-07 02:57:40 <petertodd> gmaxwell: like I say, modulo invasive p2sh^2 v2 applied to scriptPubKey contents, there's very little you can do - you can easily stuff data in pubkeys that look no different from any other
272 2014-01-07 02:57:53 <wyager> Where what "belongs" is perhaps up for debate to an uncomfortable degree
273 2014-01-07 02:58:12 <petertodd> gmaxwell: basically, you need your p2sh^2 + MAST and proof of each untaked branch probably
274 2014-01-07 02:58:39 <gmaxwell> petertodd: well for the signature itself you can move the whole signature behind a SNARK.
275 2014-01-07 02:58:58 <Luke-Jr> wyager: there are ways to get the same effects without putting it in the blockchain, in this case
276 2014-01-07 02:59:09 <Luke-Jr> wyager: mere data can always be merged mined
277 2014-01-07 02:59:43 <Luke-Jr> wyager: then storing it is opt-in
278 2014-01-07 02:59:56 <petertodd> gmaxwell: yeah, and this is -dev, not -wizards :) I *do* accept you can make *a* system that has practically no data potential, but bitcoin is really far from that system.
279 2014-01-07 03:00:00 <wyager> Of course. Again, I agree with the practicality of these measures, but it is very easy to let practicality get in the way of other goals
280 2014-01-07 03:00:21 <gmaxwell> wyager: yea sure, but you can at least look at extremes, I don't think its ambigious that a non-currency use, where people put in data for the express purpose of other peopleâ who are not being compensatedâ being forced to store it as a price of participating with the currency, is not so hot. And orders of magnitude worse when possession of the data is a strict liability crime in a big chunk of the world...
281 2014-01-07 03:00:22 <petertodd> wyager: +1
282 2014-01-07 03:00:23 <BlueMatt> petertodd: meh, I sold coingen
283 2014-01-07 03:00:30 <petertodd> BlueMatt: pity
284 2014-01-07 03:00:32 <gmaxwell> BlueMatt: for too darn little!
285 2014-01-07 03:00:54 <BlueMatt> petertodd: I dont have time to dev it and the point was to get it to produce shittons of alts of the same quality we see today
286 2014-01-07 03:01:00 <BlueMatt> gmaxwell: the point /wasnt/ to make money
287 2014-01-07 03:01:06 <BlueMatt> the cost was really to limit server dos
288 2014-01-07 03:01:10 <Luke-Jr> lol
289 2014-01-07 03:01:26 <Luke-Jr> BlueMatt: you accidentally made a new business model :p
290 2014-01-07 03:01:26 <wyager> BlueMatt: I'm a big fan of Coingen. Great idea
291 2014-01-07 03:01:32 <gmaxwell> BlueMatt: you can never feel too bad about an honest trade that deflects funds away from dumb things to better ones.
292 2014-01-07 03:01:43 <Luke-Jr> BlueMatt: too bad you sold it with an exclusive term.. it'd have been useful for -wizards games
293 2014-01-07 03:04:33 <maaku> i could probably whip up another one in a few hours
294 2014-01-07 03:04:59 <maaku> kicking myself for not seeing the potential to redirect some near-term funds...
295 2014-01-07 03:05:41 <gmaxwell> hey, neat: http://www.reddit.com/r/Bitcoin/comments/1ulbj7/would_this_mitigate_the_doublespend_potential_of/
296 2014-01-07 03:06:06 <wyager> find . -regex .*\.[hcp]* -exec sed -i'' -e 's/Bitcoin/{$other}/g' {} \;
297 2014-01-07 03:06:08 <gmaxwell> (neat that someone else independantly proposed it finally)
298 2014-01-07 03:06:09 <wyager> :p
299 2014-01-07 03:10:21 <Luke-Jr> gmaxwell: didn't petertodd come up with it independently as well?
300 2014-01-07 03:11:34 <gmaxwell> Dunno? it's less surprising when people who talk to each other a lot think of the same things.
301 2014-01-07 03:11:40 <petertodd> Luke-Jr: I don't think so
302 2014-01-07 03:12:50 <gmaxwell> I'm still not quite sure how a pool should handle fees in such a scheme, if it doesn't know/hasn't accepted all the inputs. One way would be to not pool for the fees, but thats a bit ugly.
303 2014-01-07 03:13:53 <Luke-Jr> yeah, probably will end up needing some extensions in the end
304 2014-01-07 03:14:32 <Gabit> Hi guys, are there any good suggestions for maintaining blockchain size with bitcoin-qt? Where I could search for those?
305 2014-01-07 03:14:44 <petertodd> frankly given the important of latency to profitability, especially in the future, I just can't see the idea working without some significant changes to the way mining works
306 2014-01-07 03:16:11 <maaku> Gabit: what do you mean by maintaining blockchain size
307 2014-01-07 03:17:14 <Gabit> maaku: Well it is getting bit bloated, and I have an idea and I want to compare it to previous ideas...
308 2014-01-07 03:19:20 <maaku> i just don't know what you mean by "maintaining" - pruning?
309 2014-01-07 03:19:23 <wyager> Question about getblocktemplate: Would you need a full Bitcoin node running to source transactions from random nodes?
310 2014-01-07 03:19:34 <maaku> you don't maintain the block chain size, it's always growing
311 2014-01-07 03:19:36 <wyager> That would exclude e.g. Raspberry Pi-based mining machines
312 2014-01-07 03:19:57 <maaku> wyager: yes
313 2014-01-07 03:20:03 <wyager> OK
314 2014-01-07 03:20:11 <maaku> maybe in the future that won't be the case
315 2014-01-07 03:20:29 <maaku> with proper extensions you won't have to maintain the utxo set, so long as you can find peers willing to give you proofs
316 2014-01-07 03:20:46 <maaku> but with current technology, you'd run the risk of including an invalid transaction and receiving no credit
317 2014-01-07 03:20:55 <wyager> exactly
318 2014-01-07 03:21:00 <wyager> I see
319 2014-01-07 03:21:10 <BlueMatt> Luke-Jr: it took like 3 days of 4-hours/day to build it....
320 2014-01-07 03:21:13 <BlueMatt> Luke-Jr: go build it ;)
321 2014-01-07 03:22:34 <Gabit> We could use verified snapshots of all announced addresses and balances when diff changes. Not everyone needs a full chain.
322 2014-01-07 03:23:03 <wyager> Balances? Don't you need all verified touts?
323 2014-01-07 03:23:10 <wyager> *txouts
324 2014-01-07 03:23:13 <maaku> yes, you doo
325 2014-01-07 03:23:29 <maaku> Gabit: the block chain isn't a ledger
326 2014-01-07 03:23:51 <maaku> but you can create structures which summarize portions of the unspent transaction output set
327 2014-01-07 03:24:36 <maaku> but you can't fully trust these without witnessing the whole block chain anyway
328 2014-01-07 03:24:38 <Gabit> I do understand that... But I would like to try it how I could make it work.. that why I asked if there are any discussions available..
329 2014-01-07 03:25:07 <maaku> ok see for example https://bitcointalk.org/index.php?topic=88208.0
330 2014-01-07 03:25:27 <Gabit> thx
331 2014-01-07 03:46:29 <wyager> gmaxwell: I don't know the very theoretical math behind EC crypto. Only a topical understanding of how/why it works, so I don't really get what an EC pairing is. But would it be correct to say that your suggestion works because you can't easily construct a DH pubkey that contains arbitrary data?
332 2014-01-07 03:47:06 <wyager> *ECDH pubkey
333 2014-01-07 03:47:21 <gmaxwell> wyager: only with exponential work, or otherwise you could solve discrete logs fast.
334 2014-01-07 03:47:21 <lechuga__> heh
335 2014-01-07 03:47:45 <lechuga__> wyger: i posed the gbt question on reddit
336 2014-01-07 03:47:49 <lechuga__> <- andyd00d
337 2014-01-07 03:47:53 <lechuga__> i dont think u need a local node
338 2014-01-07 03:47:56 <gmaxwell> the signature proves you know the private key behind the public key.
339 2014-01-07 03:48:05 <lechuga__> wyager even
340 2014-01-07 03:48:44 <gmaxwell> lechuga__: a local node is very strongly preferrable, since then you know the data you're trying to mine is honest... e.g. you're an actual miner, not just someone else who's hashing to get paid.
341 2014-01-07 03:49:16 <gmaxwell> lechuga__: if people did exactly as you proposed there would be a big incentive to put up a lot of nodes that gave out bad GBTs in order to trip up other miners who don't run their own nodes.
342 2014-01-07 03:49:41 <lechuga__> gmaxwell: couldn't they be weeded out and blacklisted?
343 2014-01-07 03:49:47 <lechuga__> with simpel crossverify checks
344 2014-01-07 03:50:45 <lechuga__> also setting up a lot of nodes has a serious cost
345 2014-01-07 03:51:07 <lechuga__> doesnt seem worth it if they're easily identified anyway
346 2014-01-07 03:51:36 <wyager> That's a super sketchy way of doing it
347 2014-01-07 03:52:15 <lechuga__> i guess i dont see why its all that sketchy
348 2014-01-07 03:52:54 <wyager> Because there's like a million ways to pull off a basically unbeatable sybil attack that would spam the network with bat GBTs if people just implicitly trusted them
349 2014-01-07 03:53:18 <wyager> I don't think blacklisting is particularly practical
350 2014-01-07 03:54:34 <lechuga__> hmm i guess there isnt a real cost to one of these bad nodes if they just blast fake txns
351 2014-01-07 03:54:56 <lechuga__> but you would know pretty easily if they only sent you fake txns
352 2014-01-07 03:55:11 <lechuga__> since theyd be mutually exclusive with everything th eother nodes are telling u
353 2014-01-07 03:55:12 <wyager> But what if they just sent you one fake txn
354 2014-01-07 03:55:21 <wyager> That's all they need
355 2014-01-07 03:55:25 <lechuga__> ud check the othr nodes u spoke to
356 2014-01-07 03:55:28 <wyager> Then all your work is for nothing
357 2014-01-07 03:55:32 <lechuga__> if that txn wasnt in the other sets
358 2014-01-07 03:55:35 <lechuga__> u ignore it
359 2014-01-07 03:56:08 <wyager> What if someone set up a botnet? They could make tens of thousands of secret malicious nodes and all of a sudden put every single non-node pool miner out of commission
360 2014-01-07 03:56:09 <maaku> <lechuga__> also setting up a lot of nodes has a serious cost <-- it has approx zero cost for someone with appropriate resources / connections
361 2014-01-07 03:56:09 <wyager> boom
362 2014-01-07 03:56:16 <wyager> network hash rate drops to 10%
363 2014-01-07 03:56:30 <wyager> They just lie in wait until the moment is right
364 2014-01-07 03:57:05 <lechuga__> how many nodes are there right now
365 2014-01-07 03:57:19 <wyager> Not as many as there are botneted computers
366 2014-01-07 03:57:22 <lechuga__> heh
367 2014-01-07 03:57:31 <wallet42> http://getaddr.bitnodes.io/
368 2014-01-07 03:57:48 <wallet42> 140,000
369 2014-01-07 03:57:59 <lechuga__> thx
370 2014-01-07 03:58:10 <wyager> http://en.wikipedia.org/wiki/Srizbi_botnet
371 2014-01-07 03:58:14 <wyager> 450,000 machines
372 2014-01-07 03:59:39 <wyager> That would be way easier than a 51% attack. Now, it's more like 51%*(percent of network hashing power connected to a full node) attack
373 2014-01-07 03:59:59 <wyager> Which I'm guessing is alarmingly small
374 2014-01-07 04:00:13 <maaku> there's far, far less than 140,000 full nodes out there
375 2014-01-07 04:00:39 <lechuga__> hmm
376 2014-01-07 04:01:05 <lechuga__> couldnt u just verify your list with the transaction list returned to ur gbt call to the pool node?
377 2014-01-07 04:01:13 <lechuga__> actually nope
378 2014-01-07 04:01:59 <maaku> lechuga__: you cannot simply trust other people with this
379 2014-01-07 04:02:12 <lechuga__> but the botnet would all have to run a full node
380 2014-01-07 04:02:36 <lechuga__> or u could tell they were fake
381 2014-01-07 04:02:37 <maaku> lechuga__: no, they don't have to
382 2014-01-07 04:02:41 <maaku> how?
383 2014-01-07 04:03:20 <maaku> you pose queries to them? nevermind that the p2p network doesn't support that, but the botnet controller could always provide the response
384 2014-01-07 04:03:23 <lechuga__> hmmm yeah i guess they could use a handful of real nodes to answer any potential verification u could attempt
385 2014-01-07 04:03:38 <wyager> lechuga__: The pool can always exclude whatever transactions they like, for example the legitimate first spend
386 2014-01-07 04:04:28 <wyager> If you based your trust on what the majority of connected nodes tell you, you're vulnerable to a botnet attack
387 2014-01-07 04:04:49 <lechuga__> your mining efforts are yeah
388 2014-01-07 04:04:53 <wyager> If you base your trust on what the pool operator says, that's a little better, because you implicitly trusted the operator
389 2014-01-07 04:05:23 <wyager> The best would be if you don't trust anyone, but as far as I can tell that requires a full node in this case (I may be wrong though)
390 2014-01-07 04:06:28 <lechuga__> what if there were a verifytxns rpc call u coudl send back to the pool operator with the transactions u got from randoms
391 2014-01-07 04:06:38 <maaku> the best option is to support utxo proof commitment extensions that let you do this decentralized
392 2014-01-07 04:07:06 <maaku> lechuga__: and the pool says no, not valid? even if it is?
393 2014-01-07 04:07:12 <maaku> you can't outsource this
394 2014-01-07 04:07:17 <wyager> lechuga__: Then they can "block" valid txns
395 2014-01-07 04:07:18 <lechuga__> then they're just sabotaging themself
396 2014-01-07 04:07:24 <wyager> No, they're not
397 2014-01-07 04:07:35 <wyager> they're doing the same thing as if they pulled off a double-spend attack
398 2014-01-07 04:07:47 <lechuga__> but their hashing powr is reduced
399 2014-01-07 04:07:52 <lechuga__> since u wont be doing work now
400 2014-01-07 04:08:13 <wyager> You will be doing work. You will be mining a block without that transaction in it
401 2014-01-07 04:09:07 <lechuga__> but how can the operator (or whoever hacked the operator) double spend then
402 2014-01-07 04:09:22 <lechuga__> they can only deny txns into a block
403 2014-01-07 04:09:28 <lechuga__> they cant insert double-spending ones
404 2014-01-07 04:10:15 <wyager> Right. So they insert the double spending ones, tell the miners that those are valid, and then tell the miners that the original transactions are invalid
405 2014-01-07 04:10:33 <lechuga__> whoa
406 2014-01-07 04:10:35 <wyager> Now the miners will ignore the original, legitimate transaction
407 2014-01-07 04:10:43 <lechuga__> wait
408 2014-01-07 04:10:49 <lechuga__> im getting txns from random nodes
409 2014-01-07 04:11:00 <lechuga__> lets say some of them included "bad" txns
410 2014-01-07 04:11:03 <lechuga__> and
411 2014-01-07 04:11:03 <wyager> OK
412 2014-01-07 04:11:10 <lechuga__> im getting txns from the pool node im affiliated with
413 2014-01-07 04:11:19 <wyager> Yes
414 2014-01-07 04:11:20 <lechuga__> and lets say they contain "bad" txns too
415 2014-01-07 04:11:23 <lechuga__> everyone hates me basically
416 2014-01-07 04:11:27 <wyager> How would you know?
417 2014-01-07 04:11:33 <lechuga__> so
418 2014-01-07 04:11:39 <wyager> The only way to know for sure what is bad and what isn't is to run a full node
419 2014-01-07 04:11:43 <lechuga__> i send the random txns back to my pool operator
420 2014-01-07 04:11:46 <wyager> or do something clever that I haven't though tof
421 2014-01-07 04:11:48 <wyager> *of
422 2014-01-07 04:11:51 <lechuga__> anyones he doesnt like he tells me arent valid
423 2014-01-07 04:11:54 <wyager> Sure
424 2014-01-07 04:12:08 <lechuga__> ok
425 2014-01-07 04:12:26 <lechuga__> so now im left with a set of pool-approved nodes *but* it doesnt include their double-spend attempts either
426 2014-01-07 04:12:33 <lechuga__> er pool-approved txns
427 2014-01-07 04:12:58 <lechuga__> i guess if i happen to be speakign with all botnet nodes
428 2014-01-07 04:13:05 <lechuga__> i could try hashing nothign but the coinbase
429 2014-01-07 04:13:17 <lechuga__> but if that did happen i could reshuffle as it were
430 2014-01-07 04:13:19 <lechuga__> and find other nodes
431 2014-01-07 04:14:34 <wyager> OK, so in the end you're left with a few options: You can either trust the majority of your connected peers (bad idea) trust your pool operator (mediocre idea) not actually mine any transactions (bad idea, your pool might not allow this either) or just verify all txns yourself (good idea)
432 2014-01-07 04:15:33 <lechuga__> but the only way a double-spend happens with this model is if
433 2014-01-07 04:15:40 <lechuga__> a) the pool is compormised
434 2014-01-07 04:15:45 <lechuga__> b) and they have a botnet
435 2014-01-07 04:16:30 <wyager> I see. You mean ignore any "bad" transactions from *either* the pool *or* the rest of the network?
436 2014-01-07 04:16:35 <lechuga__> right
437 2014-01-07 04:16:45 <Luke-Jr> there's another option
438 2014-01-07 04:16:47 <gribble> (xor <password> <text>) -- Returns <text> XOR-encrypted with <password>. See http://www.yoe.org/developer/xor.html for information about XOR encryption.
439 2014-01-07 04:16:47 <lechuga__> !xor
440 2014-01-07 04:16:55 <lechuga__> whoa didnt know that was a command
441 2014-01-07 04:17:13 <Luke-Jr> use Foopool as your pool, and Barpolicy as your transaction policy provider
442 2014-01-07 04:17:36 <wyager> Yeah, I was going to suggest that
443 2014-01-07 04:17:45 <wyager> separate txn verification from block template provider
444 2014-01-07 04:18:12 <lechuga__> who would txn verify
445 2014-01-07 04:18:19 <wyager> Also opens the possibility of running your own txn verification server
446 2014-01-07 04:18:31 <lechuga__> where does Barpolicy come from
447 2014-01-07 04:18:39 <Luke-Jr> lechuga__: anyone who wants to
448 2014-01-07 04:18:39 <wyager> You have a hundred raspberry Pis running ASICs and one full PC running a verification gizmo
449 2014-01-07 04:19:10 <lechuga__> hmm
450 2014-01-07 04:19:25 <lechuga__> you could actually verify againt eligius' Barpolicy
451 2014-01-07 04:19:34 <lechuga__> when using ghash's Foopool
452 2014-01-07 04:19:41 <Luke-Jr> that way if they wanted to, miners could mine on BTCGuild, but use Eligius's policy
453 2014-01-07 04:19:47 <lechuga__> heh jinx
454 2014-01-07 04:19:48 <Luke-Jr> right
455 2014-01-07 04:19:53 <lechuga__> ya that sounds ideal
456 2014-01-07 04:20:05 <lechuga__> is there sufficient protocl to act as Barpolicy now
457 2014-01-07 04:20:06 <Luke-Jr> well, ideal has everyone with their own policy node
458 2014-01-07 04:20:09 <Luke-Jr> yes
459 2014-01-07 04:20:10 <lechuga__> true
460 2014-01-07 04:20:14 <Luke-Jr> GBT without coinbasetxn specified ;)
461 2014-01-07 04:20:20 <lechuga__> haha
462 2014-01-07 04:20:21 <lechuga__> right
463 2014-01-07 04:20:49 <lechuga__> thats smart
464 2014-01-07 04:20:49 <Luke-Jr> lechuga__: btw, are you just here to brainstorm, or help code this? :D
465 2014-01-07 04:21:00 <lechuga__> i may as well help
466 2014-01-07 04:21:13 <Luke-Jr> as gmaxwell hinted, I'm short on time to get everything done I'd like :/
467 2014-01-07 04:21:28 <lechuga__> k ill work on it
468 2014-01-07 04:21:47 <lechuga__> assuming i should work on bfgminer/liblkmaker first
469 2014-01-07 04:21:50 <Luke-Jr> libblkmaker was designed for this from the start, so should be easy to implement it in
470 2014-01-07 04:21:55 <lechuga__> k
471 2014-01-07 04:22:06 <Luke-Jr> the concept behind it is that you can merge templates together
472 2014-01-07 04:22:29 <lechuga__> ah it already supports that
473 2014-01-07 04:22:37 <Luke-Jr> not really
474 2014-01-07 04:22:39 <lechuga__> o
475 2014-01-07 04:22:44 <Luke-Jr> the interfaces are just designed to support it in the future
476 2014-01-07 04:23:04 <lechuga__> well ill tinker with it and post diffs
477 2014-01-07 04:23:04 <XX01XX> mean that if the fork block is >>1hour old the sidechain blocks will fail the "older than the median time of the previous 11 blocks" check and thus orphan the sidechain?
478 2014-01-07 04:23:04 <XX01XX> The block validation algorithm will reject blocks older than the median time of the previous 11 blocks (i.e more than ~1 hour in the past) or more than 2 hours in the future. Blocks which build on a sidechain will pass this validation and be saved, however if/when the sidechain grows longer than the mainchain, these timestamp checks are repeated. Am I correct in interpreting that to
479 2014-01-07 04:23:11 <lechuga__> whats the accepted way to post diffs
480 2014-01-07 04:23:22 <lechuga__> preferred even
481 2014-01-07 04:23:36 <Luke-Jr> lechuga__: Gitorious merge requests would be ideal (and maybe PM/email me the link, since Gitorious doesn't seem to consistently email me..)
482 2014-01-07 04:23:41 <lechuga__> k
483 2014-01-07 04:24:25 <Luke-Jr> thanks
484 2014-01-07 04:24:27 <lechuga__> np
485 2014-01-07 04:30:16 <XX01XX> Anyone?
486 2014-01-07 04:50:32 <XX01XX> Hmmm.
487 2014-01-07 04:55:02 <weex> XX01XX: doesn't sound correct to me
488 2014-01-07 04:55:33 <weex> i can't imagine that the time since the "fork block" would trigger anything special to happen since each block is evaluated based on the 11 before it in its chain
489 2014-01-07 04:56:54 <XX01XX> It's unclear if the "previous 11 blocks" refers to the chain or the previous 11 blocks that have been announced.
490 2014-01-07 04:57:43 <XX01XX> previous 11 blocks that have been announced would make more sense.
491 2014-01-07 04:58:02 <XX01XX> as they would both be the same if nothing nefarious is going on.
492 2014-01-07 04:58:44 <XX01XX> and if someone is trying a 51% attack, it makes it much more complicated to orchestrate
493 2014-01-07 04:58:59 <gmaxwell> XX01XX: these tests are purely within the context of a selected chain.
494 2014-01-07 04:59:19 <gmaxwell> You cannot have data from one chain effecting another, because the set of all chains seen by nodes is not consistent.
495 2014-01-07 04:59:48 <gmaxwell> So if you had such a think I could prepare two small forks, and concurrently announce one to half the network, one to another half of the network, and forever partition them.
496 2014-01-07 05:00:24 <gmaxwell> XX01XX: it's just the timestamps in the current chain, thats all.
497 2014-01-07 05:01:09 <XX01XX> how are you defining "current chain"?
498 2014-01-07 05:09:48 <XX01XX> If you interpret it to mean that a block cannot be timestamped older than ~1hr before the block before it in the chain, a 51% attack could fork off a sidechain at any arbitrary block, mine it privately until the sidechain was longer, and then begin releasing the blocks. If you interpret it to mean that the block cannot be ~1hr older than the newest block, then such an attack would fail
499 2014-01-07 05:09:48 <XX01XX> outright because the timestamps of the first blocks in the sidechain would fail validation.
500 2014-01-07 05:11:06 <XX01XX> Unless the attacker could accurately predict when the sidechain would surpass the mainchain and falsify their timestamps to fall into that ~3 hour validation window.
501 2014-01-07 05:11:08 <XX01XX> But even then you'd have to broadcast the entire attack/sidechain within that window or else the attack fails.
502 2014-01-07 05:11:56 <XX01XX> And if the chain is long enough to contain multiple difficulty adjustments, the falsified timestamps would be much shorter than the 1 minute target, resulting in large increases in the cost of the attack.
503 2014-01-07 05:12:38 <XX01XX> I may be wrong, of course, it just seems really stupid to do it the other way.
504 2014-01-07 06:31:47 <Doge_Funnie> hi
505 2014-01-07 06:32:01 <justanotheruser> hi Do
506 2014-01-07 06:32:04 <justanotheruser> Doge_Funnie:
507 2014-01-07 06:32:16 <Doge_Funnie> I need a dev for a few hours
508 2014-01-07 06:32:28 <justanotheruser> for what
509 2014-01-07 06:32:48 <Doge_Funnie> cloning coinyewest coin and releasing before them
510 2014-01-07 06:33:09 <Luke-Jr> gmaxwell:
511 2014-01-07 06:33:17 <Doge_Funnie> i have the best domain
512 2014-01-07 06:33:19 <justanotheruser> Doge_Funnie: just change the magic and logo of whatever they're cloning
513 2014-01-07 06:33:28 <Doge_Funnie> I'm not a dev
514 2014-01-07 06:33:30 <Doge_Funnie> I want to pay http://coingen.bluematt.me/#basic
515 2014-01-07 06:33:38 <Doge_Funnie> but I don't know where to get from there
516 2014-01-07 06:33:44 <Doge_Funnie> the genesis block, nodes, etc
517 2014-01-07 06:33:46 <gmaxwell> Doge_Funnie: wrong channel.
518 2014-01-07 06:33:53 <Doge_Funnie> :\
519 2014-01-07 06:34:37 <Doge_Funnie> pay to help I guess. coinye coin is being released in like 20hours i just found out. Not much time
520 2014-01-07 06:34:59 <wyager> What do you hope to accomplish?
521 2014-01-07 06:35:01 <Doge_Funnie> they're premining and have 666, 33, 11 illuminati shit all over the coin fuck that
522 2014-01-07 06:35:30 <Doge_Funnie> I need a working litecoin clone working asap
523 2014-01-07 06:35:44 <justanotheruser> Doge_Funnie: so you can pump and dump before them?
524 2014-01-07 06:35:55 <Doge_Funnie> nah
525 2014-01-07 06:37:22 <Luke-Jr> gmaxwell is a patient man. XD
526 2014-01-07 06:37:37 <gmaxwell> Doge_Funnie: really, not here.
527 2014-01-07 06:37:51 <Doge_Funnie> it says dev?
528 2014-01-07 06:37:58 <justanotheruser> Doge_Funnie: it also says bitcoin
529 2014-01-07 06:38:01 <gmaxwell> _Bitcoin_ development.
530 2014-01-07 06:38:16 <wyager> It's also not rent-a-dev, it's dev discussion
531 2014-01-07 06:38:24 <Doge_Funnie> kthanksbye
532 2014-01-07 07:46:20 <robonerd> dev to dev here: any *badass* web app devs interested in joining a team for a bitcoin start up? small scale, quick launch, already has some good support
533 2014-01-07 07:46:37 <robonerd> python/ruby/whatever
534 2014-01-07 07:46:39 <robonerd> ideally not php
535 2014-01-07 07:49:21 <robonerd> worry wrong chan
536 2014-01-07 09:18:41 <cr3pe> hi
537 2014-01-07 10:01:52 <abrkn> anyone have a bip32 implementation in js?
538 2014-01-07 10:02:47 <brisque> abrkn: there's one that brainwallet.org uses- though that's electrum which isn't a complete bip32 implementation (though I'm not sure in what way)
539 2014-01-07 10:03:22 <abrkn> ok, i'll have a look
540 2014-01-07 10:29:52 <hydromet> TD?
541 2014-01-07 10:44:22 <abrkn> anyone used this? https://github.com/justcoin/bitcoinjs-lib/blob/master/src/bip32.js#L68
542 2014-01-07 10:51:17 <BlueMatt> robonerd: you should be banned for that......
543 2014-01-07 11:03:30 <sipa> XX01XX: a block's timestamp must be after the median of its 11 direct ancestor blocks'
544 2014-01-07 11:03:46 <sipa> XX01XX: so its validity is only defined by the chain it is part of
545 2014-01-07 11:29:24 <Alina-malina> someone please list all possible bitcoin clients please?
546 2014-01-07 11:29:55 <brisque> all possible? for what purpose?
547 2014-01-07 11:30:21 <Alina-malina> brisque, i want to see how many are there already to choose which one to use
548 2014-01-07 11:31:05 <brisque> this is OT for #bitcoin-dev, but bitcoin.org has a nice set of comparisons.
549 2014-01-07 11:31:14 <brisque> http://bitcoin.org/en/choose-your-wallet
550 2014-01-07 11:31:44 <Alina-malina> hmmmm ok thanks, but i cant see the electrum there
551 2014-01-07 11:31:52 <brisque> bottom left.
552 2014-01-07 11:32:09 <Alina-malina> oh ok thanks alot!
553 2014-01-07 11:32:37 <Alina-malina> so 4 major clients for windows
554 2014-01-07 11:33:37 <brisque> we should probably continue this in #bitcoin. this is off topic.
555 2014-01-07 11:33:43 <Alina-malina> ok
556 2014-01-07 13:54:21 <Azra-el> nobody up? :)
557 2014-01-07 15:49:59 <saizai> maaku: ping re http://bitcoin.stackexchange.com/questions/20000/can-bitcoin-qt-be-configured-to-trim-the-blockchain
558 2014-01-07 15:51:53 <sipa> saizai: ?
559 2014-01-07 15:52:31 <sipa> saizai: yes, deleting old data when it is processed is possible in theory
560 2014-01-07 15:52:36 <sipa> no it is not implemented
561 2014-01-07 15:53:00 <saizai> sad
562 2014-01-07 15:53:14 <sipa> the problem is not implementing it, it's changing the protocol so that clients can still find the data they need
563 2014-01-07 15:53:28 <sipa> as you may connect to someone who has pruned old blocks that you need
564 2014-01-07 15:53:48 <sipa> so we need protocol extensions to announce which blocks you still have etc
565 2014-01-07 15:53:53 <saizai> ah
566 2014-01-07 15:53:56 <saizai> :-/
567 2014-01-07 15:54:09 <saizai> sounds like I can't run a secure client on my laptop now then
568 2014-01-07 15:55:04 <wallet42> saizai: multibit is SVP and quite secure
569 2014-01-07 15:55:08 <brisque> saizai: look into Bitcoin Armory
570 2014-01-07 15:55:25 <sipa> armory needs bitcoind in the background
571 2014-01-07 15:55:42 <wallet42> or you run a full bitcoind on a server and then use bitcoin-rcp to connect to it (with TSL enabled)
572 2014-01-07 15:55:52 <saizai> afaict
573 2014-01-07 15:55:52 <saizai> brisque: armory depends on bitcoin-qt
574 2014-01-07 15:55:52 <saizai> wallet42: SVP=?
575 2014-01-07 15:55:53 <sipa> bitcoin-rpc
576 2014-01-07 15:55:56 <sipa> with tls
577 2014-01-07 15:56:07 <wallet42> lol
578 2014-01-07 15:56:09 <sipa> are you intentionally mistyping all tla's? :p
579 2014-01-07 15:56:18 <brisque> Armory can be run in a split mode where an offline client doesn't need a copy of bitcoind.
580 2014-01-07 15:56:26 <sipa> multibit is spv
581 2014-01-07 15:56:39 <wallet42> simple payment verification