1 2014-02-25 00:03:33 <melvster> ah this is what was throwing me ... N doesnt even appear in the outputs in block explorer ... http://blockexplorer.com/rawtx/8ba9c7bb6eb2ae87d3bef37e01dfb706cf95e220d78194c1d2a75485e9ebd55d
  2 2014-02-25 00:04:05 <melvster> i guess i just take the array index
  3 2014-02-25 00:07:14 <airbreather> todamoon: for the purposes of determining the "longest" chain, if I'm not mistaken, you count the number of blocks in the chain, but each block is weighted by difficulty.  Otherwise, if I'm not mistaken, someone could just trivially build a second chain of diff-1 blocks off of the genesis block with fudged timestamps so it looks like they were mined 10 minutes apart and then all of a sudden appear to have the longest chain.
  4 2014-02-25 00:08:45 <airbreather> does that make sense and/or am I mistaken?
  5 2014-02-25 00:09:00 <melvster> airbreather: yes ... you are correct ... it's not longest in length it's longest in difficulty
  6 2014-02-25 00:09:46 <todamoon> ok
  7 2014-02-25 00:09:52 <melvster> you could build a longer chain in length if you wanted still anyway
  8 2014-02-25 00:09:58 <melvster> but clients would not accept it
  9 2014-02-25 00:10:01 <todamoon> well in that case my question would be, what would happen if it was also weighted for size?
 10 2014-02-25 00:11:01 <todamoon> there is a bit of a disincentive for miners to mine large blocks at the moment due to the risk of getting orphaned since large blocks take longer to propagate
 11 2014-02-25 00:11:35 <melvster> i wondered about that too ... but dont you get more fees for bigger blocks?
 12 2014-02-25 00:11:37 <todamoon> I was wondering if weighting for size could help as well
 13 2014-02-25 00:11:45 <todamoon> but it would require a hard fork i guess
 14 2014-02-25 00:12:11 <todamoon> yes melvster but since the reward dwarfs the fees, miners dont want to take the risk of losing the reward for more fees
 15 2014-02-25 00:12:30 <todamoon> that's why many miners are configured for smaller blocks
 16 2014-02-25 00:20:48 <super3> while it might not be the most practical solution, at least could linearly reducing fees over time be at least theoretically be a good idea?
 17 2014-02-25 00:21:28 <super3> so you can see mempool problems or txout attacks increase as you lower the fee before they become a problem
 18 2014-02-25 00:22:33 <sipa> super3: i think very soon the relay fees will be irrelevant
 19 2014-02-25 00:22:47 <sipa> as all that matters is a fee that will get your transaction confirmed
 20 2014-02-25 00:23:29 <sipa> the 'floating fee' idea makes the relay fee depend on the mining fee, just to provide some dos protection against transaction that won't be mined anyway
 21 2014-02-25 00:28:29 <super3> well i was thinking of it more as a stopgap measure before floating fees gets implemented
 22 2014-02-25 00:29:00 <super3> been reading through this pull
 23 2014-02-25 00:29:00 <super3> https://github.com/bitcoin/bitcoin/pull/3305
 24 2014-02-25 00:30:56 <sipa> i don't see the point... if the floating-fee code currently imposes a higher fee already, it must mean that the current fee is for the majority of cases already too low
 25 2014-02-25 00:32:50 <super3> but if you can avoid that user psychology problems without much effort that would be the way to go
 26 2014-02-25 00:34:59 <sipa> i think lowering the fee may do more damange than good
 27 2014-02-25 00:35:05 <sipa> in terms of non-confirming transactions
 28 2014-02-25 00:36:11 <super3> according what i've seen of Luke-Jr's node stats its takes quite a while for people to upgrade
 29 2014-02-25 00:36:22 <sipa> yes
 30 2014-02-25 00:36:29 <Luke-Jr> super3: note at least some part of that is how often it polls nodes
 31 2014-02-25 00:36:45 <super3> Luke-Jr, how often?
 32 2014-02-25 00:37:06 <Luke-Jr> sipa would know better
 33 2014-02-25 00:37:25 <super3> could old nodes(with higher fees) force new nodes(with lower fees) back a few blocks resulting in significant longer initial confirm times
 34 2014-02-25 01:07:40 <HaltingState> sipa, can you add ability to encrypt point on curve with someone's public key and ability to decrypt it if you know private key; as functions in your library, for ECDH
 35 2014-02-25 03:53:36 <Diablo-D3> lol
 36 2014-02-25 03:53:46 <Diablo-D3> top 5 stories on hn, with a sixth further down are mtgox
 37 2014-02-25 04:05:11 <Diablo-D3> top 6 are mtgox, 7th rising
 38 2014-02-25 06:21:25 <michagogo> cloud|Diablo-D3: why so many gox stories?
 39 2014-02-25 06:24:32 <Urushiol> michagogo|cloud: http://www.reddit.com/r/Bitcoin/comments/1yvdcd/heres_a_summary_of_what_has_happened_over_the/
 40 2014-02-25 06:26:40 <michagogo> cloud|Holy crap.
 41 2014-02-25 06:29:16 <Urushiol> yeah
 42 2014-02-25 06:34:10 <michagogo> cloud|...wow.
 43 2014-02-25 06:39:22 <wumpus> whoa
 44 2014-02-25 06:41:22 <wumpus> 750 000 coins 'lost'? as in, destroyed?
 45 2014-02-25 06:41:41 <copumpkin> wumpus: presumably stolen
 46 2014-02-25 06:41:47 <copumpkin> all speculation at this point though
 47 2014-02-25 06:42:09 <wumpus> right
 48 2014-02-25 06:49:02 <Herodes> Do any of you devs actually think that 750k coins are stolen without MtGox noticing? Is Mark THAT incompetent?
 49 2014-02-25 06:52:02 <paniaguaxx> devs should do a hard fork and give those coins back to gox users
 50 2014-02-25 06:52:04 <paniaguaxx> :p
 51 2014-02-25 06:52:33 <tonokip> michagogo|cloud, .
 52 2014-02-25 06:59:27 <wumpus> Herodes: who can say ...
 53 2014-02-25 07:00:32 <Apocalyptic> Herodes, the fact they plainly don't discard it says enough
 54 2014-02-25 07:05:55 <edcba> hi !
 55 2014-02-25 07:06:12 <edcba> good news everyone : we just got rid of speculators :)
 56 2014-02-25 07:10:25 <rfish> Anyone can comment on this address
 57 2014-02-25 07:10:26 <rfish> https://blockchain.info/address/1Drt3c8pSdrkyjuBiwVcSSixZwQtMZ3Tew
 58 2014-02-25 07:10:27 <jgarzik> edcba, heh
 59 2014-02-25 07:15:56 <michagogo> cloud|tonokip: any luck with gitian?
 60 2014-02-25 07:16:02 <michagogo> cloud|(Have you tried?)
 61 2014-02-25 07:16:26 <tonokip> i got part way and stopped :)
 62 2014-02-25 07:17:04 <tonokip> i made the vm
 63 2014-02-25 07:19:44 <tonokip> oh i need my inputs i guess
 64 2014-02-25 07:22:25 <tonokip> doing that now :D
 65 2014-02-25 07:53:36 <rebroad> what is the situation with mtgox? have they suffered a loss of bitcoins?
 66 2014-02-25 07:54:31 <tonokip> seems the gitian stuff wants to build win64 binaries by default
 67 2014-02-25 07:59:20 <michagogo> cloud|tonokip: both.
 68 2014-02-25 07:59:34 <michagogo> cloud|But it should be easy to tweak
 69 2014-02-25 07:59:44 <dexX7> is there any pool that allows overwrite-by-fee (or what's it called..)?
 70 2014-02-25 08:00:03 <Luke-Jr> is there a good algorithm for building merkle branches in-place?
 71 2014-02-25 08:00:12 <michagogo> cloud|Iirc there's a "for bits in 32 64" line in there
 72 2014-02-25 08:00:59 <michagogo> cloud|If you just take out the for block and set bits equal to 32, you'll get 32-bit only
 73 2014-02-25 08:03:34 <tonokip> k
 74 2014-02-25 08:05:06 <michagogo> cloud|tonokip: oh, and also sanity-check the rest of it for things like the inputs that it calls for
 75 2014-02-25 08:06:10 <tonokip> already started the time consuming process of making the 64bit vm
 76 2014-02-25 08:06:54 <Luke-Jr> I think everything is built in 64-bit VMs now either way
 77 2014-02-25 08:07:21 <michagogo> cloud|Luke-Jr: not linux32, if I'm not mistaken
 78 2014-02-25 08:09:46 <wumpus> linux32 is built on a 32 bit VM
 79 2014-02-25 08:09:58 <michagogo> cloud|Why is that, btw?
 80 2014-02-25 08:10:05 <wumpus> because no one changed it?
 81 2014-02-25 08:10:11 <michagogo> cloud|Ah.
 82 2014-02-25 08:10:17 <wumpus> usually the answer to 'why?' is 'no one bothered to do it'
 83 2014-02-25 08:10:24 <michagogo> cloud|Yeah
 84 2014-02-25 08:10:31 <michagogo> cloud|But sometimes there's a reason
 85 2014-02-25 08:10:35 <wumpus> patches welcome and such
 86 2014-02-25 08:10:56 <wumpus> well it's the easiest way to do it which reliably works
 87 2014-02-25 08:10:59 <michagogo> cloud|How hard is it to compile 32 on 64, anyway?
 88 2014-02-25 08:11:02 <wumpus> seems a good reason to me
 89 2014-02-25 08:12:29 <wumpus> not hard to do (just pass -m32 and install the right :i386 packages), but will be a lot of testing work to make sure that the result still works on 32 bit systems, 64 bit systems, and edge cases
 90 2014-02-25 08:12:47 <uiop> more or less just "gcc -m32" (modulo having the 32bit libs/runtime/etc installed if you want to run it)
 91 2014-02-25 08:13:00 <uiop> wumpus beat me
 92 2014-02-25 08:13:26 <wumpus> myself I'm quite sick of gitian right now, just managed to get everything (including intermediate outputs) kind of deterministic, so everything that ruins that will make me pissed :)
 93 2014-02-25 08:15:05 <wumpus> still, patches welcome, for the 0.10/1.0 release it'd be nice to build everything on one VM
 94 2014-02-25 08:17:13 <uiop> how does the build (make -j<n>) scale parallel-ly ?
 95 2014-02-25 08:17:36 <wumpus> the bitcoin build itself scales pretty well
 96 2014-02-25 08:17:47 <wumpus> some of the inputs (like qt) scale very badly
 97 2014-02-25 08:17:56 <uiop> (err, i.e. are there any long stretches of serial build deps during build?)
 98 2014-02-25 08:18:00 <uiop> cool
 99 2014-02-25 08:18:33 <uiop> "make -j" is what multicore is made for! :)
100 2014-02-25 08:18:39 <wumpus> the only annoyance with bitcoin is the leveldb build, sometimes I wish there was a 'make clean except leveldb'
101 2014-02-25 08:19:36 <uiop> are there any insidious weird deps that make such a thing fragile, or has nobody just spent the time to conjur the correct make incantations?
102 2014-02-25 08:19:46 <wumpus> (although the leveldb build is parallelized, building any of bitcoin's own objects waits for it)
103 2014-02-25 08:20:20 <wumpus> well the reason is that leveldb has its own build system
104 2014-02-25 08:20:35 <wumpus> that's also the reason that out-of-tree builds don't work at the moment, leveldb's build system doesn't support them
105 2014-02-25 08:20:48 <uiop> oh.. ouch
106 2014-02-25 08:21:14 <uiop> out-of-tree builds are the "man-or-boy test" for build systems
107 2014-02-25 08:21:23 <wumpus> well, patches welcome
108 2014-02-25 08:21:37 <uiop> i'll take a look
109 2014-02-25 08:21:39 <wumpus> I expect it to be really ugly
110 2014-02-25 08:22:31 <wumpus> cfields had a look at it and he's as close to an autotools/conf expert we have around here
111 2014-02-25 08:24:55 <uiop> 
ACTION has had occasion to printed out the gcc Makefiles and read them with highlighters

112 2014-02-25 08:26:09 <wumpus> masochist :)
113 2014-02-25 08:26:41 <uiop> oh yesh, the fun :)
114 2014-02-25 08:51:56 <melvster> is there any incentive for miners to add transactions with zero fees?
115 2014-02-25 08:52:19 <melvster> other than making btc awesome ...
116 2014-02-25 08:52:58 <Mqrius> melvster: if it's their own transactions :)
117 2014-02-25 08:53:16 <melvster> ahhh
118 2014-02-25 08:54:14 <jgarzik> melvster, sure.  to encourage use of bitcoin.  to reduce the UTXO set size.  to encourage holders of old coins to circulate them through the system.
119 2014-02-25 08:54:38 <jgarzik> melvster, some mining pools of yesteryear were very loud in their desire to include all transactions, fee or no
120 2014-02-25 09:07:50 <melvster> jgarzik: awesome
121 2014-02-25 09:31:55 <shaileshg> hi, if you are running online wallet service.. how do you keep x% in hot wallet and (100-x%) in cold storage?
122 2014-02-25 09:33:23 <shaileshg> means if you are giving API to your merchants to accept payments.. then those would contain one particular public address.. in that case, do you keep transferring bitcoins from your receiving address to one whose' private key is in cold storage?
123 2014-02-25 09:34:26 <Belxjander> shaileshg: that means you need to be generating and storing "cold wallet" data by printing it out as QRcodes or some other mechanism
124 2014-02-25 09:39:13 <Luke-Jr> shaileshg: you know addresses are only to be used once ever, correct?
125 2014-02-25 09:42:46 <phillipsjk> Apparently Bitcoin does not listen for RPC connections on external interfaces. P2Pool assumes the RPC and Bitcoin P2P interface both use the same address. This is not the case if you explicitly tell bitcoind to listen to a specific address.
126 2014-02-25 09:43:18 <wumpus> phillipsjk: you can make it listen on external interfaces by providing at least one -rpcallowip
127 2014-02-25 09:44:29 <phillipsjk> This is a bit of sysadmin fail too because the machine is hosting a jail, but the Bitcoin related stuff is not in a jail.
128 2014-02-25 09:49:31 <phillipsjk> it does not appear to be listening on the external interface when I set the rpcallowip=interface_address.
129 2014-02-25 09:49:43 <phillipsjk> root@casey:~ #
130 2014-02-25 09:49:43 <phillipsjk> root@casey:~ # netstat -a | grep 192.168.243.2:8332
131 2014-02-25 09:50:53 <wumpus> phillipsjk:  I have a pull open for allowing RPC binding on any interface(s) you want, please help testing https://github.com/bitcoin/bitcoin/pull/3695
132 2014-02-25 09:51:08 <phillipsjk> found it:
133 2014-02-25 09:51:13 <phillipsjk> root@casey:~ # netstat -a | grep 8332
134 2014-02-25 09:51:13 <phillipsjk> tcp46      0      0 *.8332                 *.*                    LISTEN
135 2014-02-25 09:51:34 <phillipsjk> 
ACTION tests

136 2014-02-25 09:52:43 <phillipsjk> nope, still does't work.
137 2014-02-25 09:53:27 <uiop> wumpus: what modifications does the in-tree leveldb have to its ancestor in the leveldb mainline ?
138 2014-02-25 09:53:56 <wumpus> phillipsjk: so to be clear with that patch you need to provide both an rpcallowip and rpcbind
139 2014-02-25 09:54:54 <wumpus> if one or more -rpcallowip and no -rpcbind is specified, bind to all interfaces
140 2014-02-25 09:54:54 <wumpus> if one or more -rpcallowip and one or more -rpcbind is specified, bind to those specific addresses
141 2014-02-25 09:54:54 <wumpus> the logic is: unless -rpcallowip is specified, it binds to localhost
142 2014-02-25 09:54:57 <phillipsjk> I have not been able to compile bitcoind yet. Resorted to using a binary.
143 2014-02-25 09:56:18 <wumpus> uiop: I think only the db file extension change for compatibility with 0.8, not entirely sure tho
144 2014-02-25 09:56:45 <wumpus> but this: tcp46      0      0 *.8332                 *.*                    LISTEN   means it listens to all interfaces correct?
145 2014-02-25 09:57:06 <wumpus> so looks like it works as intended
146 2014-02-25 09:58:49 <phillipsjk> not sure why P2Pool can't connect.
147 2014-02-25 10:01:38 <phillipsjk> I have the RPC password correct because it worked before I tried to specify the LAN interface. (but it could not connect to the P2P port on local host)
148 2014-02-25 10:02:42 <wumpus> do you specify the right rpcallowip?
149 2014-02-25 10:03:23 <wumpus> you'll get a HTTP 403 error if not
150 2014-02-25 10:04:17 <phillipsjk> it was timing out.
151 2014-02-25 10:04:51 <wumpus> that should not even be possible for something that runs locally, unless you have a firewall issue
152 2014-02-25 10:05:32 <phillipsjk> well, I need sleep.
153 2014-02-25 10:05:41 <phillipsjk> Thanks for your help.
154 2014-02-25 10:11:56 <uiop> phillipsjk: are you on linux? if so you can do "sudo iptable-save" and look at your firewall rules
155 2014-02-25 10:12:31 <phillipsjk> no, FreeBSD
156 2014-02-25 10:12:49 <uiop> ah, i'm of no use then
157 2014-02-25 10:13:19 <uiop> phillipsjk: well, actually do you have netcat(1) (nc(1) ?) or socat(1) ?
158 2014-02-25 10:13:22 <phillipsjk> I know I have a choice of two differing firewall schemes...
159 2014-02-25 10:13:40 <uiop> (socat is the absolute best tool, it's worth getting)
160 2014-02-25 10:14:20 <uiop> socat TCP-L:4242 STDIO
161 2014-02-25 10:14:43 <uiop> will listen on port 4242 and dump incoming to terminal, and write its stdin to the network
162 2014-02-25 10:14:45 <phillipsjk> yup have nc
163 2014-02-25 10:14:49 <uiop> nice
164 2014-02-25 10:15:06 <uiop> that's my tool of choice for seeing if anything is blocking stuff
165 2014-02-25 10:15:19 <uiop> (although i don't know cli syntax on nc offhand)
166 2014-02-25 10:15:25 <uiop> s/on/of/
167 2014-02-25 10:16:33 <phillipsjk> I tried using ping, that worked.
168 2014-02-25 10:18:18 <uiop> i can't help myself but socat is the best: forward unix socket over ssh:
169 2014-02-25 10:18:23 <uiop> socat "TCP-LISTEN:6900,reuseaddr,fork" "EXEC:ssh me@example.com socat STDIO UNIX-CONNECT\:/tmp/.s.PGSQL.5432"
170 2014-02-25 10:18:52 <uiop> phillipsjk: try in one terminal "nc <listen on port blah> <dump to terminal>"
171 2014-02-25 10:18:55 <uiop> and in another terminal
172 2014-02-25 10:19:13 <uiop> "telnet <addr> <port>"
173 2014-02-25 10:19:37 <uiop> (ping doesn't do what you want)
174 2014-02-25 10:20:11 <uiop> phillipsjk: well, that ping works *does* tell you something..
175 2014-02-25 10:20:28 <uiop> (but not much)
176 2014-02-25 10:21:11 <phillipsjk> I only have the one terminal.
177 2014-02-25 10:21:21 <uiop> nc .. &
178 2014-02-25 10:21:28 <uiop> just background netcat
179 2014-02-25 10:21:40 <_syslog> phillipsjk:  you can use nohub for background.
180 2014-02-25 10:21:46 <uiop> or screen(1)
181 2014-02-25 10:21:57 <uiop> but that's a whole nother rabbit hole
182 2014-02-25 10:22:16 <uiop> _syslog: nohup you mean?
183 2014-02-25 10:22:33 <_syslog> http://en.wikipedia.org/wiki/Nohup
184 2014-02-25 10:22:52 <_syslog> if he was only 1 term, i doubt he has access to screen command.
185 2014-02-25 10:23:10 <_syslog> so there is only option ( imo )  nohub
186 2014-02-25 10:23:13 <uiop> phillipsjk: all we're going for is to determine if a given addr:port is blocked by the firewall, without looking at the firewall rules themselves, right?
187 2014-02-25 10:23:16 <phillipsjk> There is a BSD equivalent that I have not set up
188 2014-02-25 10:23:33 <phillipsjk> But I still need sleep.
189 2014-02-25 10:24:55 <uiop> _syslog: although in this case, all we care about is if we can connect, so he might as well redirect netcat to a file, connect with telnet, type "asdfghjkl<CR>^D", kill netcat, check if file is nonempty
190 2014-02-25 10:25:19 <uiop> phillipsjk: yeah, it sounds like it :)
191 2014-02-25 10:27:51 <phillipsjk> The reason I have only the one terminal is I am actually using a serial terminal. Saved a lot of trouble-shooting when the Network interface locked up during actual use. (I was able to see watchdog timer messages)
192 2014-02-25 10:55:13 <gribble> The operation succeeded.
193 2014-02-25 10:55:13 <sipa> ;;later tell HaltingState encryption using EC is usually done by encrypting with a separate algorithm (aes) using an ecdh-negotiated key; ecdh is already possible with my library
194 2014-02-25 10:56:39 <gmaxwell> sipa: would you object to an addition of that blind ECDSA to your library?  and an addition of schnorr signing with our curve? (perhaps both as ifdef optional compiles?)
195 2014-02-25 10:59:49 <TD> what's the advantage of schnorr signatures over regular ecdsa again?
196 2014-02-25 11:00:11 <sipa> faster, more flexible, not malleable
197 2014-02-25 11:00:20 <setra> hello, need some help compiling latest wallet...
198 2014-02-25 11:01:00 <gmaxwell> TD: efficient threshold signatures, solid security proofs, potentially faster (haven't benchmarked).
199 2014-02-25 11:01:08 <setra> what flags do I need to pass to set my compiled berkeleydb4.8 as used db
200 2014-02-25 11:01:40 <sipa> gmaxwell: it's a bit ugly, as sign/validate use an inline call to a hash function
201 2014-02-25 11:01:43 <TD> efficient threshold signatures in particular sounds very good
202 2014-02-25 11:01:43 <TD> no need for CHECKMULTISIG anymore
203 2014-02-25 11:01:43 <TD> sounds good
204 2014-02-25 11:01:50 <gmaxwell> TD: e.g. you can do non-interactive N of N with some key and signature arithemetic, and N of M with a simple interactive protocol to establish the keys.
205 2014-02-25 11:02:09 <gmaxwell> because N of M needs interaction there still might be applicablity for CHECKMULTISIG, but certantly less.
206 2014-02-25 11:02:14 <sipa> gmaxwell: and i prefer not to depend on particular hash imolementations
207 2014-02-25 11:02:32 <gmaxwell> sipa: behold the power of function pointers?
208 2014-02-25 11:02:43 <sipa> gmaxwell: bleh :)
209 2014-02-25 11:03:09 <gmaxwell> yea normally in security sensitive code I like to avoid function pointers, because they're a vector for instruction pointer control.
210 2014-02-25 11:03:16 <gmaxwell> But ::meh:: pick your poisons.
211 2014-02-25 11:03:46 <TD> i've been pondering today how to do provable audits of an exchange, ideally with good privacy. it's one of those problems that feels like it _should_ be tractable if enough crypto is thrown at it. but it's hard to see how.
212 2014-02-25 11:03:46 <TD> you'd need to be able to prove the amount of coin in a wallet, without revealing the keys, and then find a way to tie that to the exchanges databases
213 2014-02-25 11:04:36 <gmaxwell> TD: oh it's not hard with enjoy grypto. You just use the protocol I described for this but do the values under a general ZKP system. Complexity should be similar to the zerocash stuff.
214 2014-02-25 11:04:40 <gmaxwell> er crypto.
215 2014-02-25 11:05:33 <TD> yes i was hoping to avoid general ZKP given that no such framework is currently available publicly :) also it seems like interaction with the external databases would be tricky
216 2014-02-25 11:05:44 <TD> where did you describe your protocol?
217 2014-02-25 11:05:49 <gmaxwell> you don't interact with external databases. :)
218 2014-02-25 11:06:44 <gmaxwell> it recently got linked here: https://news.ycombinator.com/item?id=7277865
219 2014-02-25 11:07:41 <gmaxwell> the non-private version basically works like certificate transparency. First show your coins. Then show a hash root for a tree over your balances (including the sum of the child values in each of the interior nodes).  When someone logs in you prove to them their balance is included in the published root.
220 2014-02-25 11:08:14 <gmaxwell> Down side is that it reveals the services total holdings, and leaks a little bit about the account value distribution.  Making the balance tree a huffman tree minimizes the leakage.
221 2014-02-25 11:08:33 <gmaxwell> But you could do better by basically running this same protocol but encrypt the values and use a ZKP to prove the encrypted values add up.
222 2014-02-25 11:09:11 <gmaxwell> (and do the proof of ownership of the coins under the ZKP so you're not identifying your coins anymore)
223 2014-02-25 11:11:46 <gmaxwell> in any case, there apparently a number of services currently in the process of implementing the protocol I described, and some other ones who have said they will not because they do not want to reveal their total holdings.
224 2014-02-25 11:12:48 <gmaxwell> I assume that if some do release such a thing market pressure will make someone go solve the problem. I bet the folks working on the ZKP stuff in zerocash would love a research grant for something with such nice crisply defined boundaries that uses tools they already have.
225 2014-02-25 11:17:47 <TD> yeah. it seems right up their alley
226 2014-02-25 11:18:03 <TD> there's also cryptodb
227 2014-02-25 11:18:19 <TD> the problem is that to prove solvency, you have to not only prove you own the coins, but also that the coins you own match your outstanding liabilities
228 2014-02-25 11:18:44 <TD> which is usually going to be tracked in a sql db of some kind. cryptodb allows you to do queries over an encrypted database, modulo some very reasonable constraints, with good performance
229 2014-02-25 11:19:19 <TD> so i was thinking it might be possible to publish a cryptodb tracking users->balances, allow anyone to do a SELECT SUM() over the public db, whilst still restricting individual queries for individual users
230 2014-02-25 11:19:21 <Persopolis> can this not be tackled from a different angle - e.g. the exchanges write their own solvency code (sums total holdings vs account records) - have an approved auditor, audit the code - nothing is revealed in terms of total holdings - just that the ratio is 1:1 or over? - the audited code can be hashed and signed
231 2014-02-25 11:19:23 <TD> (but in a provable manner)
232 2014-02-25 11:19:38 <TD> yes of course, one off audits by a trusted third party are the current status quo
233 2014-02-25 11:19:52 <TD> the question is can we do better? publishing the audit code is fine but how do you know it was run properly?
234 2014-02-25 11:19:57 <TD> ideally you'd have fully decentralised auditing
235 2014-02-25 11:20:34 <TD> you could also do trusted computing in some way, run the entire DB in a remotely attestable domain, but TC has never worked well
236 2014-02-25 11:20:39 <Persopolis> TD: the key is signing with auditor key - the display of results can do check of authenticity
237 2014-02-25 11:20:39 <TD> i don't anticipate it will until intel release SGX
238 2014-02-25 11:22:56 <Persopolis> A nice solvency graph (only showing values as %s) and a code snippet at the bottom that refers to auditor site and which verifies the code as being the same one audited and approved
239 2014-02-25 11:23:15 <ThomasV> gmaxwell: which services plan to implement your proposal?
240 2014-02-25 11:26:24 <Persopolis> TD: is what I'm suggesting complete bull or is that something workable?
241 2014-02-25 11:27:45 <TD> i didn't really understand your proposal, i'm afraid. when you say "verifies the code as being the same one audited and approved" what does that mean? you don't know what code the exchange was running
242 2014-02-25 11:28:07 <swulf--> TD: don't you just move the problem to proving that the cryptodb is actually equal to the db used on your servers?
243 2014-02-25 11:28:26 <TD> i guess a simple, easy first step would be to have a trusted third party auditor be given read access to the sql db and list of keys. then it can connect through a VPN to the exchange and run queries once a month or so, to check things add up, and then the auditor can just publish a text message saying "We checked on this date and alles in ordnung"
244 2014-02-25 11:28:46 <swulf--> Was it peter todd? that suggested the hash tree/merkle-like tree of balances?
245 2014-02-25 11:29:03 <TD> swulf--: i think the exchange could selectively reveal keys to each individual user letting them check that their own database entry is correct
246 2014-02-25 11:29:13 <TD> of course the vast majority wouldn't. but the ones that would are effectively unknowable by the exchange
247 2014-02-25 11:29:17 <TD> so it'd be a statistical check
248 2014-02-25 11:29:26 <swulf--> again, you'd have to trust they weren't lying -- ideally the user would request their key
249 2014-02-25 11:29:36 <gmaxwell> swulf--: it was actually me that suggested it but apparently peter included it in a talk. :)
250 2014-02-25 11:29:43 <swulf--> gmaxwell: my apologies ;)
251 2014-02-25 11:30:16 <gmaxwell> TD: you can correct the majority by automating it .. I also in the original discussion that sparked this, suggested a wanky patch for that unfortunate property.
252 2014-02-25 11:30:48 <gmaxwell> You simply make it the Official Rules that the bank can confiscate your coins if you don't check your balance in X time.  (and of course checking your balance gives you a signature so you can prove that you were checking or not)
253 2014-02-25 11:30:52 <gmaxwell> :P
254 2014-02-25 11:31:00 <swulf--> TD: while you're here, I wanted to get your thoughts about the micropayments channel in bitcoinj
255 2014-02-25 11:32:01 <TD> sure
256 2014-02-25 11:32:35 <swulf--> Perhaps I don't have a deep understanding of all the nuances, but it seems to me like malleability opens a DoS vector with micropayments... could lead to lost funds
257 2014-02-25 11:33:19 <TD> yes, it does
258 2014-02-25 11:33:29 <swulf--> okay:)
259 2014-02-25 11:33:31 <TD> this is a known issue with all contract protocols that include a refund
260 2014-02-25 11:33:36 <swulf--> right
261 2014-02-25 11:34:25 <Persopolis> TD: Exchange writes code to do automatic audit, auditor checks the code and verifies it is doing the correct calculations etc the code is hashed and signed by the auditor, the results coming out of the code include signatures for the code and results which can be verified by the auditor's site as genuine  -- a bit more complicated than this - but this is the simplified version
262 2014-02-25 11:36:21 <TD> for some apps the server often won't have any way to communicate the fact that it wants to extort the user, back to that user.
263 2014-02-25 11:36:21 <TD> of course in a situation where someone is mutating every transaction they can, just to be a dick, that logic doesn't help you :)
264 2014-02-25 11:36:21 <TD> once the work is done on the bitcoin core side, opting in to v3 transactions should be very easy
265 2014-02-25 11:36:21 <TD> so for now it's best seen as a "preview of coming attractions", perhaps. also the refund-extortion attack is probably rather complicated to pull off in practice
266 2014-02-25 11:36:21 <TD> the current micropayment channel implementation has a couple of security issues: one is the malleability, another is that it reuses keys. once i finish HDW i'll go in and fix the latter. the former will require the v3 tx proposal to be implemented
267 2014-02-25 11:37:12 <TD> "signatures for the code"
268 2014-02-25 11:37:18 <TD> again what do you mean? are you assuming trusted computing?
269 2014-02-25 11:37:19 <swulf--> ahh, v3 transactions -- is this from the "dealing with malleability" thread on the ml?
270 2014-02-25 11:37:22 <TD> yeah
271 2014-02-25 11:39:27 <Persopolis> TD: hash the code so that if it is tempered with / changed after audit it become apparent - many ways to achieve this
272 2014-02-25 11:41:02 <TD> no, again, you aren't understanding me
273 2014-02-25 11:41:11 <TD> what proof do you have that the published code was the code actually run?
274 2014-02-25 11:41:25 <TD> you say many ways to achieve this, but i think i know all the ways, and none of them are entirely practical right now
275 2014-02-25 11:43:41 <Persopolis> TD: the signed code can be held on auditor site, the code to execute can pull from auditor site, which inserts random key
276 2014-02-25 11:44:17 <TD> so i write a 5-line shell script that extracts the key from the pulled code, runs by bogus "hide our insolvency" audit logic, and then signs the result with the extracted key
277 2014-02-25 11:47:05 <Persopolis> yes that's possible - you can work around that somewhat by obfuscating the source
278 2014-02-25 11:48:05 <Persopolis> makes it far harder for automated scripting to pull the key
279 2014-02-25 11:48:22 <TD> i have a lot of experience with code obfuscation. it can work better than people tend to imagine for some use cases. however, when large sums of money are involved, this would not be one of those use case
280 2014-02-25 11:49:47 <Persopolis> TD: if there is a time to live for the pulled code, it would offer another layer of protection
281 2014-02-25 11:56:23 <Persopolis> Looking at this from the exchange's perspective, what ever solution is to be used, it needs to: a) not expose the exchange to another attack vector b) not expose confidential data c) not expose commercially sensitive data   - to me these sum up to the audit having to be run on their premises mostly
282 2014-02-25 11:57:29 <TD> right. i think ideal solutions are possible. they are just hard
283 2014-02-25 11:57:31 <Persopolis> I don't think my idea would meet these either
284 2014-02-25 11:57:40 <TD> we'll probably get there over time in stages
285 2014-02-25 11:57:55 <upb> lol @ hashing source code
286 2014-02-25 11:58:27 <upb> you could apply multiparty computation to do that kind of an audit without revealing exact data to the auditor
287 2014-02-25 12:00:20 <Persopolis> not that unusual upb to sign code - i used to work as a mainframe OS developer and we had a secure version for MoD use - used that kind of technique
288 2014-02-25 12:01:37 <upb> sure its not unusual to sign code but it wouldnt work in the context youre proposing to use it
289 2014-02-25 12:03:07 <Persopolis> perhaps because I didn't type an end to end solution while thinking on my feet... all depends on how the code is loaded and executed
290 2014-02-25 12:04:15 <Persopolis> quite easy to shoot most ideas down - but discussion is what gets you to the answer - even if you start with a stupid idea ;D
291 2014-02-25 12:10:33 <Persopolis> what I do know is that if I was running my own exchange, I would in no way agree to have my db be quieried from outside
292 2014-02-25 12:11:07 <TD> Persopolis: sure, no problem
293 2014-02-25 12:13:59 <Persopolis> nvm...
294 2014-02-25 12:34:55 <edcba> why not just give the address of your cold wallet ?
295 2014-02-25 12:35:52 <KuDeTa> how would they prove ownership without signing?
296 2014-02-25 12:36:24 <KuDeTa> tux apparently claimed that was too complicated as all the parts of the key were split up in separate places.
297 2014-02-25 12:37:17 <michagogo> cloud|setra: still around?
298 2014-02-25 12:37:35 <michagogo> cloud|setra: run ./configure --help
299 2014-02-25 12:37:39 <edcba> it should be as "hard" as spending them
300 2014-02-25 12:37:46 <michagogo> cloud|Look for --with-something
301 2014-02-25 12:38:28 <michagogo> cloud|You can look at contrib/gitian-descriptors/gitian-win.yml for an example
302 2014-02-25 12:38:31 <edcba> anyway mtgox didn't inspire me confiance as soon as they did allow black pool stuff or dunno how it is called
303 2014-02-25 12:42:30 <michagogo> cloud|Interesting side effect of the mtgox problem...
304 2014-02-25 12:42:50 <michagogo> cloud|Wiki accounts can no longer pay for edit rights
305 2014-02-25 12:43:00 <setra> michagogo|cloud, yes still here. yes tried to run ./configure --help but it doesn't help me
306 2014-02-25 12:43:05 <Ymgve> Is there a way to check the blockchain for transactions that have been modified thru tx malleability?
307 2014-02-25 12:43:16 <chichov> how is the merkle tree computed if the number of nodes is odd, eg 5?
308 2014-02-25 12:43:23 <michagogo> cloud|setra: did you find the relevant option?
309 2014-02-25 12:43:47 <michagogo> cloud|chichov: each node that is missing a pair is hashed together
310 2014-02-25 12:44:02 <michagogo> cloud|With itself
311 2014-02-25 12:44:11 <michagogo> cloud|So if you have items 1,2,3,4,5
312 2014-02-25 12:44:40 <michagogo> cloud|a=H(12), b=H(34), c=H(55)
313 2014-02-25 12:44:53 <setra> michagogo|cloud, I don't know what to look for, I know I need to tell it to use the location /usr/local/BerkeleyDB4.8 for the includes and the library, but ... failed untill now
314 2014-02-25 12:45:02 <michagogo> cloud|A=H(ab), B=H(cc)
315 2014-02-25 12:45:32 <chichov> michagogo|cloud: thanks
316 2014-02-25 12:45:37 <michagogo> cloud|setra: in the output of configure --help, look for options starting with "--with"
317 2014-02-25 12:45:49 <chichov> wasn't absolutely clear in the wiki, as an example with 3 nodes was given
318 2014-02-25 12:46:03 <chichov> so that it is trivial to fill it up to 2^n
319 2014-02-25 12:46:30 <_syslog> _syslog
320 2014-02-25 12:46:41 <setra> michagogo|cloud, yes I found that but I would not prefer to not use any other DB than 4.8. so I rather need an option which defines the location for library and header of DB4.8
321 2014-02-25 12:47:19 <michagogo> cloud|setra: yes, one of the --with* options is that
322 2014-02-25 12:47:25 <michagogo> cloud|Give me a sec, I'll find it
323 2014-02-25 12:47:34 <chichov> is this more or less standard procedure for all Merkle trees or is this specific for bitcoin?
324 2014-02-25 12:47:45 <michagogo> cloud|chichov: the former, I believe
325 2014-02-25 12:47:57 <setra> michagogo|cloud, sorry I thought you mean --with-incompatible-db
326 2014-02-25 12:48:05 <michagogo> cloud|setra:
327 2014-02-25 12:48:09 <michagogo> cloud|nope
328 2014-02-25 12:48:24 <chichov> michagogo|cloud: thank you for your help
329 2014-02-25 12:49:11 <michagogo> cloud|Np
330 2014-02-25 12:50:53 <michagogo> cloud|setra: hm, looks like what I was thinking of is only for qt and boost
331 2014-02-25 12:52:23 <setra> michagogo|cloud, jup... how do you define a custom location of a library and headers in terms of a configure option
332 2014-02-25 12:52:45 <michagogo> cloud|setra: see if you can figure it out from contrib/gitian-descriptors/gitian-win.yml
333 2014-02-25 12:53:01 <michagogo> cloud|It might be the CPPFLAGS
334 2014-02-25 12:53:45 <michagogo> cloud|Or perhaps the LDFLAGS
335 2014-02-25 12:53:57 <setra> yes but how does the syntax look like..../configure CPPFLAGS='/usr/local/BerkeleyDB4.8/libs' ?
336 2014-02-25 12:54:22 <michagogo> cloud|I don't actually know what those options are, I'm not familiar with how the build system works
337 2014-02-25 12:55:09 <michagogo> cloud|I'd recommend looking at the configure line in contrib/gitian-descriptors/gitian-win.yml
338 2014-02-25 12:55:46 <setra> michagogo|cloud, Sorry to bother you with that build thingi... ok I will take a look after lunch... thx maybe you stillaround?
339 2014-02-25 12:57:11 <michagogo> cloud|One sec, I'll take a look in a minute when I get to my computer
340 2014-02-25 12:58:24 <michagogo> cloud|indir=$STAGING/plugins  --with-qt-incdir=$STAGING/include --with-qt-bindir=$STAG
341 2014-02-25 12:58:24 <michagogo> cloud|ING/host/bin --with-boost=$STAGING --disable-maintainer-mode --with-protoc-bindi
342 2014-02-25 12:58:24 <michagogo> cloud|Okay, looks like the full line is ./configure --bindir=$OUTDIR --prefix=$STAGING --host=$HOST --with-qt-plug
343 2014-02-25 12:58:24 <michagogo> cloud|{OPTFLAGS}" LDFLAGS="-L$STAGING/lib ${OPTFLAGS}" CXXFLAGS="-frandom-seed=bitcoin ${OPTFLAGS}"
344 2014-02-25 12:58:24 <michagogo> cloud|r=$STAGING/host/bin --disable-dependency-tracking CPPFLAGS="-I$STAGING/include $
345 2014-02-25 12:58:26 <michagogo> cloud|Gah
346 2014-02-25 12:58:30 <michagogo> cloud|That was supposed to be one line
347 2014-02-25 12:59:48 <michagogo> cloud|I think the relevant parts might be CPPFLAGS="-I$STAGING/include"
348 2014-02-25 12:59:56 <michagogo> cloud|and LDFLAGS="-L$STAGING/lib"
349 2014-02-25 12:59:57 <_syslog> michagogo|cloud:  in a fair world you should get kicked .
350 2014-02-25 13:00:02 <_syslog> *sorry
351 2014-02-25 13:00:19 <lnovy> http://youtu.be/29EgnYOYqpk :DD
352 2014-02-25 13:01:47 <michagogo> cloud|Erm, what is that?
353 2014-02-25 13:02:08 <lnovy> just another rant :)
354 2014-02-25 13:02:15 <michagogo> cloud|Some clip from a movie with redubbed subtitles or something?
355 2014-02-25 13:02:28 <lnovy> michagogo|cloud: you don't know the concept?
356 2014-02-25 13:02:34 <michagogo> cloud|No...
357 2014-02-25 13:02:40 <lnovy> michagogo|cloud: there's like millon of those similiar
358 2014-02-25 13:03:34 <lnovy> michagogo|cloud: meta: http://knowyourmeme.com/memes/downfall-hitler-reacts
359 2014-02-25 13:08:06 <t7> even my dad knows the downfall meme
360 2014-02-25 13:08:58 <abrkn> watching it now...
361 2014-02-25 13:11:23 <sipa> downfall?
362 2014-02-25 13:11:30 <sipa> is that the name of the movie in english?
363 2014-02-25 13:11:46 <abrkn> sipa: the downfall
364 2014-02-25 13:12:19 <abrkn> it's really good
365 2014-02-25 13:12:28 <sipa> i know the movie
366 2014-02-25 13:12:35 <sipa> just under the name "der untergang"
367 2014-02-25 13:12:40 <abrkn> yep
368 2014-02-25 13:55:52 <phillipsjk> uiop: the timeout was caused by 192.169.243.2 being the wrong address, not a fire-wall.
369 2014-02-25 13:56:08 <aynstein> Luke-Jr: is there a way to identify a miners device by the share it submits (I mean does it submit any hardware unique info), if so, does it persist through the bfg proxy ?
370 2014-02-25 14:00:40 <orweinberger> I'm sure you've seen this: https://eprint.iacr.org/2013/881.pdf - Did any core dev respond to it? Is this something viable for future versions?
371 2014-02-25 14:05:10 <setra> michagogo|cloud, sorry... cant figure it out from this gitan-win.yml file, don't even know what to look for
372 2014-02-25 14:06:17 <uiop> phillipsjk: heh
373 2014-02-25 14:15:20 <michagogo> cloud|setra: 14:59:48 <michagogo|cloud> I think the relevant parts might be CPPFLAGS="-I$STAGING/include" and LDFLAGS="-L$STAGING/lib"
374 2014-02-25 14:23:31 <michagogo> cloud|Heh, has anyone seen mtgox's homepage?
375 2014-02-25 14:23:58 <michagogo> cloud|<html>
376 2014-02-25 14:24:21 <Persopolis> oh dear - I got blank page and didn't look at the source
377 2014-02-25 14:25:05 <xeroc> michagogo|cloud: http://www.reddit.com/r/Bitcoin/comments/1yvndw/mtgoxcom_page_source_says_put_announce_for_mtgox/
378 2014-02-25 14:25:57 <Persopolis> so it's prety cert that they are goners
379 2014-02-25 14:37:42 <michagogo> cloud|uh
380 2014-02-25 14:37:51 <michagogo> cloud|I just refreshed and a bunch of js showed up...
381 2014-02-25 14:38:13 <michagogo> cloud|https://www.irccloud.com/pastebin/WD0QiY1b
382 2014-02-25 14:48:55 <Persopolis> do you use chrome?  you can see the JS in the header now
383 2014-02-25 14:52:12 <Persopolis> http://en.wikipedia.org/wiki/Akamai_Technologies
384 2014-02-25 15:15:44 <Phoebus> Hey guys, anyone know any DL or torrent for the testnet blockchain? Cheers.
385 2014-02-25 15:17:19 <_syslog> Phoebus: testnet blockchain is not huge like mainnet
386 2014-02-25 15:17:59 <_syslog> if you connected testnet it will be download entire blockchain in 1 hour ( my net download speed  was 100 kbps )
387 2014-02-25 15:18:22 <Phoebus> _syslog, cheers :)
388 2014-02-25 15:18:43 <_syslog> ;)
389 2014-02-25 15:18:50 <Phoebus> Time to work on something else meanwhile.
390 2014-02-25 15:18:55 <michagogo> cloud|Phoebus: yeah, it's much smaller
391 2014-02-25 15:19:02 <michagogo> cloud|Not much of a need
392 2014-02-25 15:19:37 <michagogo> cloud|And if it's being really slow, just restart the software for a different syncnode
393 2014-02-25 15:20:14 <_syslog> 85.153.13.35 it has full testnet blockchain.
394 2014-02-25 15:20:24 <Phoebus> cheers michagogo|cloud, it was blocked essentially so wasn't downloading.
395 2014-02-25 15:20:54 <michagogo> cloud|Phoebus: what was blocked?
396 2014-02-25 15:21:14 <Phoebus> nvm it's ok.
397 2014-02-25 15:21:29 <Phoebus> _syslog, that's not public, as in requires user/pass
398 2014-02-25 15:26:33 <_syslog> what are you doin ?