1 2014-01-16 00:08:46 <lechuga__> any1 up for a question about contracts?
2 2014-01-16 00:09:46 <lechuga__> quiet in here today
3 2014-01-16 00:37:02 <realazthat> sipa: I am designing a mock RPC api to simulate the fork and other test-cases
4 2014-01-16 00:37:11 <realazthat> seems most reliable to me
5 2014-01-16 00:37:35 <realazthat> just in case you wanted to know how I went about t hat
6 2014-01-16 00:39:22 <sipa> realazthat: hmm, i once implemented a blacklistblock RPC, which instants marks a block as invalid and reorganizes away from it
7 2014-01-16 00:41:12 <realazthat> sipa: heh interesting
8 2014-01-16 00:41:24 <realazthat> but still not really as useful for unit-testing another application I think
9 2014-01-16 00:41:45 <realazthat> this way I can simply make some mock blockchain, no need for it to even use valid hashes or anything
10 2014-01-16 00:42:04 <realazthat> just the amounts, addresses matter, essentially
11 2014-01-16 00:42:40 <sipa> ok
12 2014-01-16 00:42:52 <realazthat> sipa: is there anyone recording all known blocks, so that if there is a fork, the bad blocks are recorded
13 2014-01-16 00:43:03 <realazthat> just curious
14 2014-01-16 00:44:23 <sipa> every bitcoind records all blocks it sees
15 2014-01-16 00:44:54 <sipa> well, all blocks which at least validate syntactic correctness and PoW, and connect to the genesis block
16 2014-01-16 00:45:05 <realazthat> right, but if you restart it from scratch it won't get those, am I wrong?
17 2014-01-16 00:45:15 <sipa> no
18 2014-01-16 01:07:57 <jcorgan> sipa: are there bip0032 test vectors that exercise CKD' ?
19 2014-01-16 01:08:28 <sipa> if you want them to
20 2014-01-16 01:08:57 <sipa> for any non-prime derivation, you can either use CKD on the parent private key, or CKD' on the public key
21 2014-01-16 01:09:02 <sipa> and the result must be the same
22 2014-01-16 01:09:13 <jcorgan> got it, made sense after I though about it for a bit
23 2014-01-16 01:15:28 <jcorgan> is there intended to be a different meaning between 'm' and 'M' ?
24 2014-01-16 01:15:45 <sipa> m is private, M is public
25 2014-01-16 01:16:08 <jcorgan> as in return the extended public key vs. extended private key?
26 2014-01-16 01:16:24 <sipa> not "return"
27 2014-01-16 01:16:28 <sipa> they're variable name
28 2014-01-16 01:16:46 <sipa> but typically lower case is used for private ones, and upper case for public ones
29 2014-01-16 01:17:07 <jcorgan> sorry, i'm trying to wrap my bip32 code into a cli program, and pass the chain identifier as a cli argument
30 2014-01-16 01:18:10 <jcorgan> so i'm writing something that evaluates a given chain string for correctness, and then a parser to return some output regarding it
31 2014-01-16 01:18:34 <sipa> ok
32 2014-01-16 01:18:57 <sipa> so in these chain strings that start with m or M
33 2014-01-16 01:19:06 <sipa> those represent the xprv or xpub of the master
34 2014-01-16 01:19:22 <jcorgan> thought so
35 2014-01-16 01:29:51 <jcorgan> if I handed someone the xpubkey generated from m/0'/1, they could generate the pubkeys for m/0'/1/i, but they wouldn't really need to know that the chain was rooted at m/0'/1 to do it other than to get the depth and identifier right. So I'm trying to think of a good way for the user to supply that information to generate a subkey when all they have is a xprvkey or xpubkey somewhere down in the hierarchy
36 2014-01-16 01:31:03 <sipa> why do they need to know what lies above what you've given them?
37 2014-01-16 01:31:40 <jcorgan> i don't think they do, but there are fields in the serialization that ask for depth and parent identifier
38 2014-01-16 01:32:14 <sipa> yes, so they know
39 2014-01-16 01:32:26 <sipa> i'm not sure what you're trying to do
40 2014-01-16 01:33:58 <jcorgan> i want to be able to some something like: $ hdwgen -f xpubkey.bin 5 to generate /5 xpubkey under whatever node xpubkey.bin refers to
41 2014-01-16 01:34:58 <jcorgan> ah, just pull the depth and ident out of the xpubkey.bin
42 2014-01-16 01:36:47 <jcorgan> so if you are starting from the master key, you'd have m/..., but if you're just starting with an xprvkey or xpubkey from somewhere in the hierarchy, you could just specifiy the "relative" path continuing from there
43 2014-01-16 01:36:51 <jcorgan> right?
44 2014-01-16 01:37:31 <sipa> ye
45 2014-01-16 01:37:33 <jcorgan> i might be overthinking this
46 2014-01-16 01:37:33 <sipa> yes
47 2014-01-16 01:37:57 <sipa> i implemented that in https://github.com/bitcoin/bitcoin/pull/3520
48 2014-01-16 01:38:26 <sipa> you can pass xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ/2/3'/10000/0/1
49 2014-01-16 01:38:32 <jcorgan> ah, nice, ima gonna steal from that
50 2014-01-16 01:38:44 <sipa> well, no, you can't do prime derivations from an xpub
51 2014-01-16 01:38:53 <jcorgan> i get your point though
52 2014-01-16 01:39:09 <sipa> good!
53 2014-01-16 01:39:46 <sipa> phantomcircuit: can you have a look again at #2966?
54 2014-01-16 01:40:17 <jcorgan> so my program give the user the ability to supply the xpubkey or xprvkey from a file or stdin, or to supply entropy either from a file or stdin when creating a master
55 2014-01-16 01:41:01 <jcorgan> to duplicate what you said above, they'd supply the xpub... in one cli, then '2/3'/10000/0/1' as the chain spec
56 2014-01-16 01:41:42 <jcorgan> thanks for clarifying.
57 2014-01-16 01:41:46 <sipa> that hdderive command just takes [keyspec][/path[/path[...]]
58 2014-01-16 01:42:04 <sipa> where keyspec is either an xpub or xprv in base58, or a seed in hex
59 2014-01-16 01:43:20 <jcorgan> my Python utility is about the same, but a little more generalized
60 2014-01-16 01:43:31 <sipa> oki
61 2014-01-16 01:44:30 <jcorgan> like being able to generate the master xpub and xprv by supplying entropy
62 2014-01-16 01:45:16 <jcorgan> and outputting different things about a generated node (secret, pubkey, chain code, addr, etc.)
63 2014-01-16 01:45:48 <sipa> yup, that rpc command does all that too :)
64 2014-01-16 01:45:56 <jcorgan> i'm sure :)
65 2014-01-16 01:46:07 <sipa> anyway, not trying to discourage you at all
66 2014-01-16 01:46:15 <sipa> it's much more useful to have that as an external tool
67 2014-01-16 01:46:28 <jcorgan> this started as an exercise to understand the bip, it's grown into an effort to make playing with these things scriptable
68 2014-01-16 01:47:35 <jcorgan> i've even had the notion to wrap a FUSE filesystem around it, so you could recursivly descend into nodes and the various parameters would be files you could read, like /proc
69 2014-01-16 01:48:19 <sipa> haha
70 2014-01-16 01:48:44 <jcorgan> so you could "mount" an xpubkey, xprvkey, or entropy source, then do everything else with cat :)
71 2014-01-16 01:49:00 <jcorgan> and cd
72 2014-01-16 01:50:51 <jcorgan> that's a neat idea (and I'm a big fan of FUSE), but I have no idea if it is really useful
73 2014-01-16 01:51:05 <sipa> i've written fuse filesystems before too :)
74 2014-01-16 01:51:18 <sipa> here i think it's a little bit overkill though
75 2014-01-16 01:52:09 <gmaxwell> a fuse block explorer would be more amusing.
76 2014-01-16 01:52:48 <jcorgan> you are in a maze of twisty hex passages, all alike
77 2014-01-16 01:52:56 <gmaxwell> sipa: I forget, did addr index also index the spending transactions?
78 2014-01-16 01:53:23 <sipa> gmaxwell: i think so, yes
79 2014-01-16 03:29:13 <warren> sipa: for the leveldb patching, we commit to bitcoin/leveldb first then subtree merge squash to bitcoin?
80 2014-01-16 03:30:58 <warren> This is a bit issue is disruptive to master testing so I hope it can be merged soon.
81 2014-01-16 03:31:07 <warren> errr english
82 2014-01-16 05:04:21 <jgarzik> sipa, heh, cool. FUSE is a lot of fun. I wrote "dbfs": Local filesystem with POSIX semantics, implemented using Berkeley DB 4 over FUSE.
83 2014-01-16 05:04:53 <jgarzik> did the same for "fuse-ext2", which is a POSIX filesystem implemented using userspace e2fsprogs library
84 2014-01-16 05:06:27 <jgarzik> ACTION has written several kernel and userspace filesystems. Terribly interesting work, where genius data structure work is torn apart and smashed into pudding by hardware that lies to you
85 2014-01-16 05:07:18 <jgarzik> http://linux.yyz.us/projects.html
86 2014-01-16 06:35:44 <nightlingo> yo!
87 2014-01-16 07:05:54 <abrkn> is github user vbuterin ever on irc?
88 2014-01-16 07:06:17 <Luke-Jr> abrkn: rarely
89 2014-01-16 07:11:19 <sipa> jgarzik: for backuppc, a pretty nice deduplicating incremental backupservice written in perl, i wrote a filesystem in fuse-perl to mount it
90 2014-01-16 07:23:32 <abrkn> Luke-Jr: i see. he is not responding to pull requests
91 2014-01-16 07:27:57 <warren> sipa: shoot. using SSTFileName actually doesn't prevent the renaming
92 2014-01-16 07:28:07 <warren> sipa: patching s/ldb/sst/ did
93 2014-01-16 07:28:46 <sipa> really?
94 2014-01-16 07:28:57 <sipa> that's unexpected
95 2014-01-16 07:32:01 <warren> retesting
96 2014-01-16 07:32:56 <warren> sipa: http://0bin.net/paste/kpbM-Uh5EYAsGLwh#nuidR/3rIa9imn7upS8cGu/wYV8vulRARXvcRYDRXao= this is what you meant right?
97 2014-01-16 07:38:02 <abrkn> is it possible to have bitcoind always send change to a specific address?
98 2014-01-16 08:16:20 <sipa> warren: yes
99 2014-01-16 08:16:36 <warren> sipa: yeah, not working here.
100 2014-01-16 08:16:40 <sipa> abrkn: yes, if you change the code, but don't do that
101 2014-01-16 08:17:03 <sipa> warren: thanks, i'll have a look later today
102 2014-01-16 08:17:42 <abrkn> sipa: what would be a disadvantage?
103 2014-01-16 08:18:15 <abrkn> sipa: aside from loss of pseudonymity
104 2014-01-16 08:19:57 <wumpus> there are tons fo threads about why not to reuse addresses, please do your own research as well
105 2014-01-16 08:21:50 <warren> wumpus: hmm, renaming them back to .sst failed yesterday, but today it worked.
106 2014-01-16 08:22:40 <warren> cd ~/.bitcoin; for file in $(find -name '*.ldb'); do mv $file $(echo $file |sed 's/ldb$/sst/'); done
107 2014-01-16 08:22:41 <wumpus> let's hope that you did something wrong, and not even that is non-deterministic
108 2014-01-16 08:23:32 <abrkn> our wallet.dat's getting pretty big at justcoin and im trying to find a better system. was thinking generating addresses with bip32, but then we need to find inputs and construct tx' which is a pain and most people advice against
109 2014-01-16 08:24:13 <abrkn> alternatively can use bip32 to create disposable addresses and routinely sweep them up in a hot wallet chain
110 2014-01-16 08:25:24 <wumpus> slowing of wallet.dat's is mostly on number of transactions, number of keys shouldn't make much of a difference
111 2014-01-16 08:26:30 <warren> wumpus: hmm, should we switch the linux gitian intermediates to .zip for determinism?
112 2014-01-16 08:26:47 <wumpus> warren: yes
113 2014-01-16 08:28:27 <wumpus> and number of transactions doesn't change by using a different key generation scheme; the bitcoind wallet just doesn't scale that well, and a change like 'send the change to a fixed address' isn't going to resolve that
114 2014-01-16 08:30:13 <wumpus> I'm not sure what to recommend either
115 2014-01-16 08:32:07 <warren> i'm sleeping early tonight
116 2014-01-16 08:32:11 <warren> ttyl
117 2014-01-16 08:32:13 <abrkn> wumpus: alternative is to do our own input management, but things like having to re-broadcast tx'...
118 2014-01-16 08:32:23 <wumpus> if you skip the wallet and build and sign transactions using the raw transaction API instead you can build your own well-scaling system on top, but yes you need a way to keep track of inputs, I'm sure someone else did this before and can comment
119 2014-01-16 08:33:25 <abrkn> perhaps if sending using sendraw does the re-broadcasting for me, then i would benefit from bitcoind without bloating the wallet
120 2014-01-16 08:35:06 <wumpus> IIRC it only re-broadcasts sendrawtransaction'ed transactions if the wallet accepts them
121 2014-01-16 08:36:02 <wumpus> (yes, it's the wallet that does the re-broadcasting)
122 2014-01-16 08:36:09 <abrkn> ok
123 2014-01-16 11:15:39 <CodeShark> was a major LevelDB issue recently fixed with the master branch?
124 2014-01-16 11:17:56 <Eagle[TM]> 0.8.6 fixed/hardened things for Mac regarding LevelDB iirc, not sure about master
125 2014-01-16 11:19:16 <CodeShark> master from last week (I can get the exact commit id) was causing my system to hang on linux, with a process that simply could not be killed
126 2014-01-16 11:19:58 <Apocalyptic> CodeShark, every process can be killed
127 2014-01-16 11:20:06 <CodeShark> not this one :P
128 2014-01-16 11:20:08 <Apocalyptic> with -9 kill
129 2014-01-16 11:20:10 <CodeShark> nope
130 2014-01-16 11:20:21 <CodeShark> not if there's a problem with hardware
131 2014-01-16 11:20:24 <CodeShark> :p
132 2014-01-16 11:20:28 <Apocalyptic> wait, you sent SIGKILL and it didn't kill ?
133 2014-01-16 11:20:32 <Apocalyptic> hum yeah
134 2014-01-16 11:20:38 <Apocalyptic> but that shouldn't happen
135 2014-01-16 11:20:44 <CodeShark> famous last words
136 2014-01-16 11:20:49 <CodeShark> I assure you it WAS happening - I'
137 2014-01-16 11:21:06 <CodeShark> I was running it under VirtualBox, never had that problem before
138 2014-01-16 11:21:17 <Eagle[TM]> linux-vserver or similar?
139 2014-01-16 11:21:24 <Apocalyptic> you tried to reproduce it N
140 2014-01-16 11:21:58 <CodeShark> I was just trying to do a sync, would sync some and then would just hang
141 2014-01-16 11:22:09 <CodeShark> as in, kill -9 would not work
142 2014-01-16 11:22:39 <CodeShark> I thought perhaps I was running out of disk space, cleared out someâ¦but it still was happening
143 2014-01-16 11:22:59 <CodeShark> otherwise, this system is extremely stable and well-behaved
144 2014-01-16 11:23:17 <Eagle[TM]> strace might be helpful for some pointers
145 2014-01-16 11:24:19 <wumpus> indeed, if it hangs in the kernel on an uninterruptible operation, you cannot kill it in any way
146 2014-01-16 11:24:58 <CodeShark> I'm now running the latest master head, haven't seen the issue again yet
147 2014-01-16 11:25:36 <wumpus> this tended to happen with NFS volumes when the server is unreachable, before there was an option for that
148 2014-01-16 11:25:49 <CodeShark> the commit that seems to have been causing problems is 8da2b3316c6540684617a8ecb8edb458894c2009
149 2014-01-16 11:26:05 <wumpus> normally, it should be impossible to cause that with user-space problem
150 2014-01-16 11:26:28 <CodeShark> the volume still had at least a few gigs left
151 2014-01-16 11:26:47 <CodeShark> so I don't think that was the issue
152 2014-01-16 11:27:15 <wumpus> I doubt it's caused by disk space, usually it's a communication problem somewhere between the file system and the backing storage
153 2014-01-16 11:27:24 <wumpus> dmesg may show something
154 2014-01-16 11:27:45 <CodeShark> I've since restarted this machine
155 2014-01-16 11:27:46 <wumpus> for example a i/o problem or segfault in the kernel
156 2014-01-16 11:28:22 <CodeShark> perhaps I'll try running the problematic build again and run these tools
157 2014-01-16 11:28:58 <CodeShark> just want to see whether this newer build remains stable for a little while longer
158 2014-01-16 11:30:58 <CodeShark> seems some of the orphan block processing stuff changed
159 2014-01-16 11:33:43 <CodeShark> oh waitâ¦I pasted the wrong commit id
160 2014-01-16 11:33:45 <CodeShark> it's e8837b384dc045a0b970b19a64844d11e2da99b3
161 2014-01-16 12:42:01 <Diablo-D3> https://github.com/tarruda/vim/tree/event-loop
162 2014-01-16 16:42:07 <niston> If I have an address with BTC1000 in it, then do a payment to some other address of BTC0.01 and forget to include a change address for BTC999.99, then my transaction will have those BTC999.99 as fee. Correct?
163 2014-01-16 16:44:15 <michagogo> cloud|niston: If the 1000 BTC is one output and you're creating the transaction manually, yes
164 2014-01-16 16:44:45 <niston> okay :)
165 2014-01-16 16:45:28 <lianj> yea, its over then :)
166 2014-01-16 16:45:59 <lianj> although there were cases where a friendly miner gave those obvious mistaken fee back
167 2014-01-16 16:46:05 <lianj> but don't bet on it
168 2014-01-16 16:46:05 <niston> the reward would go to the miner (or pool) that mines the block with my transaction in it?
169 2014-01-16 16:46:13 <lianj> yes
170 2014-01-16 16:47:06 <niston> so to mine a block, I need to find the nonce that makes the hash of the whole block, whereas the individual TX hashes are stored as the merkle tree, satisfy the target requirement.
171 2014-01-16 16:47:52 <niston> thus it becomes hard to fake or alter the block, cause the changed merkle root would require a new nonce for the block to be valid.
172 2014-01-16 16:49:22 <niston> plus the original block will be long distributed to many many nodes, whereas any following block will be linked to the original block due to the previous hash embedded in each block.
173 2014-01-16 16:50:01 <niston> so it will be very difficult to insert the faked block, even if I eventually manage to compute a nonce that makes my fake block valid.
174 2014-01-16 16:50:58 <niston> I guess its possible for a given block to be uncomputable, means no nonce that satisfies target requirement can be found?
175 2014-01-16 16:51:23 <niston> should happen all the time, the solution (to mining the block) being to change something in the block that affects the merkle root?
176 2014-01-16 16:57:10 <helo> that's one
177 2014-01-16 17:19:43 <TD> sipa: ping
178 2014-01-16 17:21:33 <lechuga__> is passing around unsigned/partially signed multiparty input txns via QR code prior to broadcast a crazy idea?
179 2014-01-16 17:21:56 <lechuga__> like full hex encoded txns
180 2014-01-16 17:23:01 <TD> qrcodes are very limited in size
181 2014-01-16 17:23:13 <lechuga__> isnt it like 3k
182 2014-01-16 17:23:25 <TD> the more data you try and add the less scannable they become
183 2014-01-16 17:23:31 <lechuga__> ic
184 2014-01-16 17:25:00 <lechuga__> trying to figure out how contracts r going to work from a UX perspective
185 2014-01-16 17:34:40 <danwalton> what is the purpose of COINBASE_MATURITY?
186 2014-01-16 17:34:45 <danwalton> seems like a long time to wait
187 2014-01-16 17:44:51 <michagogo> cloud|danwalton: Essentially, to reduce the chances of a block ending up no longer on the best chain
188 2014-01-16 17:44:59 <michagogo> cloud|Which means that the generated coins are invalid
189 2014-01-16 17:45:23 <danwalton> so mine a block, then find out all your blocks are orphans
190 2014-01-16 17:45:24 <michagogo> cloud|Which could mean a very long chain of transactions suddenly gets wiped out non-maliciously
191 2014-01-16 17:45:36 <danwalton> how often does that happen?
192 2014-01-16 17:45:47 <michagogo> cloud|danwalton: Short forks happen regularly
193 2014-01-16 17:45:50 <michagogo> cloud|(usually just one block)
194 2014-01-16 17:45:56 <danwalton> right
195 2014-01-16 17:46:07 <danwalton> i guess in the case of a bug, you might have a very long fork
196 2014-01-16 17:46:17 <danwalton> this seems like its to allow for certain types of emergencies
197 2014-01-16 17:46:25 <danwalton> big forks
198 2014-01-16 17:46:29 <michagogo> cloud|The thing is, with most transactions, a reorg just means that a transaction is no longer confirmed
199 2014-01-16 17:46:38 <danwalton> right
200 2014-01-16 17:46:42 <michagogo> cloud|But the transaction is still valid and can get into future blocks
201 2014-01-16 17:46:53 <danwalton> because all the peers are honestly making sure that everyone isn't double spending
202 2014-01-16 17:46:57 <michagogo> cloud|That can't happen when a coinbase transaction is involved, because that transaction ceases to exist
203 2014-01-16 17:54:21 <dmanderson> You can still do a 33% attack
204 2014-01-16 17:54:28 <dmanderson> using a greedy pool
205 2014-01-16 17:54:49 <dmanderson> is this true?
206 2014-01-16 17:55:06 <dmanderson> *selfish pool
207 2014-01-16 18:00:32 <xyz> I'm trying to build LevelDB for Windows with MSVC following the instructions at https://github.com/bitcoin/leveldb/blob/bitcoin-fork/WINDOWS.md but it doesn't work because there are no project/solution files; what do?
208 2014-01-16 18:01:21 <michagogo> cloud|xyz: Good luck trying to build in MSVC...
209 2014-01-16 18:05:39 <bbdude> hey BlueMatt, what are the coingen.io coins a fork of?
210 2014-01-16 18:06:37 <blazon> the newest release for respective choice
211 2014-01-16 18:07:02 <xyz> michagogo|cloud: I know, right
212 2014-01-16 18:07:10 <xyz> I guess I'll go with official way of building it (with boost libs)
213 2014-01-16 18:07:36 <michagogo> cloud|bbdude: 0.8.6, I believe
214 2014-01-16 18:09:30 <bbdude> michagogo|cloud, ah even says it on the debug window, heh. Thanks!
215 2014-01-16 18:09:53 <michagogo> cloud|np
216 2014-01-16 18:18:11 <sipa> TD[gone]: pang
217 2014-01-16 18:20:28 <bbdude> anyone frequent the hackathons here?
218 2014-01-16 18:20:44 <bbdude> Anyone going to any upcoming ones? It'd be cool to see some coin hacks!
219 2014-01-16 18:23:27 <sevenqueue> dunno about the hackathons but the latest git pull of bitcoin on testnet has me 4 weeks behind and stuck on 153816 debug shows nothing but orphan blocks
220 2014-01-16 18:35:28 <helo> sevenqueue: attempting sync now
221 2014-01-16 18:38:35 <sevenqueue> should I wait a while? is there orphan block testing going on?
222 2014-01-16 18:45:14 <sevenqueue> github email says there was a testnet issue, wonder if that is what I'm hitting?
223 2014-01-16 19:04:00 <shesek> which mode is causing that "#bitcoin-dev :Cannot change nickname while banned on channel"? its super annoying :-\
224 2014-01-16 19:05:32 <gmaxwell> shesek: need to leave the channel to change nick or register with nickserv
225 2014-01-16 19:05:49 <dbasch> I just put together a standalone implementation of BIP38 in Java, if anyone is interested. It barely works, and it needs test cases: https://github.com/dbasch/BIP38
226 2014-01-16 19:05:50 <gmaxwell> you can register with nickserv without changing nick by giving it the username with the password.
227 2014-01-16 19:07:34 <shesek> I'm already registered to nickserv, and that is why I left the channel - to change my nickname and identify (I was execut3 a moment ago)
228 2014-01-16 19:12:57 <shesek> gmaxwell, oh, did you mean to identify when you said register? I think I misunderstood you
229 2014-01-16 19:17:01 <michagogo> cloud|Question: would an OC'd PC in a warmer-than-usual room be a possible cause for 2014-01-16 16:40:46 in this log? http://0bin.net/paste/xWid8aUuSN2hTmRN#gX2FrQ3IzvP9bmYjNKhl0VrLwS08Hq/E5W6nwCUlEhc=
230 2014-01-16 19:25:47 <lechuga__> looks like my galaxy note3 has no prob scanning a QR code which is a base58check encoded raw transaction
231 2014-01-16 19:28:31 <lianj> lechuga__: maybe youre lucky and have a small tx. meaning one input + 1 or 2 outputs
232 2014-01-16 19:29:32 <michagogo> cloud|lechuga__: Heh, a raw transaction in base58check?
233 2014-01-16 19:29:50 <michagogo> cloud|Never heard of that being done so far
234 2014-01-16 19:30:23 <sipa> for QR, uou're better off with base36
235 2014-01-16 19:32:59 <lechuga__> lianj: the type of txn im going to be working with is always 2 txins + 1 txout
236 2014-01-16 19:33:18 <lechuga__> sipa: ah true
237 2014-01-16 19:35:27 <lechuga__> michagogolcloud: im trying to design a quasi-sensible UX for multiparty contracts
238 2014-01-16 19:36:27 <lechuga__> well 2party in this case
239 2014-01-16 19:37:41 <lechuga__> not convinced this is correct but sketching it up to convince/unconvince myself
240 2014-01-16 19:49:33 <jaakkos> hmm. in the stealth address doc, it says: "we use BIP32-style derivation to create Q'=(Q+c)G" but since Q is EC point and c is integer, how is Q+c interpreted?
241 2014-01-16 19:50:37 <jaakkos> should that be just Q+cG or something?
242 2014-01-16 19:52:12 <jaakkos> also, what if we forget about DH and simply use Q' = Q*c and publish c?
243 2014-01-16 19:52:49 <sipa> that doesn't give you privacy
244 2014-01-16 19:53:01 <sipa> anyone can detect payments to you, in that case
245 2014-01-16 19:53:09 <jcorgan> jaakos: that's a typo, should be (d+c)G I think
246 2014-01-16 19:53:29 <jaakkos> sipa: but how would third parties figure out Q?
247 2014-01-16 19:53:58 <jaakkos> (Q*c)/c should be difficult, right?
248 2014-01-16 19:54:18 <sipa> it's trivial
249 2014-01-16 19:54:27 <sipa> you multiply by (1/c) mod n
250 2014-01-16 19:55:05 <jaakkos> meh indeed it is (Q*c)/Q that is difficult. my bad.
251 2014-01-16 19:56:49 <jaakkos> jcorgan: yeah that's what i thought
252 2014-01-16 19:57:22 <jcorgan> Q' = (d+c)G => dG + cG => Q + P
253 2014-01-16 19:58:12 <jaakkos> c was not used in any key yet
254 2014-01-16 19:58:37 <jaakkos> it was derived from the DH secret.
255 2014-01-16 19:58:42 <jaakkos> so cG != P
256 2014-01-16 19:59:01 <jaakkos> in the document eG = P
257 2014-01-16 19:59:09 <jcorgan> my bad
258 2014-01-16 20:11:17 <jspilman> this might help: https://gist.github.com/jspilman/8396495
259 2014-01-16 20:12:21 <jspilman> toy implementation in bitcoind coming soon
260 2014-01-16 20:48:56 <lechuga__> any1 know what channel mycelium devs hang out on?
261 2014-01-16 20:54:09 <ferroh> So I'm guessing this transaction will never confirm: https://blockchain.info/tx/79fbda85a003e24a8ceaae58dba988acedbd04778dfc68bbd1970b2af05f41ef
262 2014-01-16 20:54:21 <ferroh> It was sent by blockchain.info shared send. Can someone shed some light on why it will never confirm?
263 2014-01-16 20:54:34 <ferroh> I would like to be able to detect these types of transactions
264 2014-01-16 20:54:46 <ferroh> (and not accept them if I they aren't likely to confirm)
265 2014-01-16 21:02:52 <shesek> ferroh, the inputs were spent in other transactions that was confirmed
266 2014-01-16 21:03:36 <shesek> the transaction you linked to is now considered invalid
267 2014-01-16 21:06:31 <Denim-jdev> if you want to detect it, you would detect it the same way as a double-spend attack
268 2014-01-16 21:17:55 <ferroh> Denim-jdev, shesek: Does it look like this was done maliciously?
269 2014-01-16 21:18:16 <ferroh> Denim-jdev: What is an easy way to check for a double-spend attack?
270 2014-01-16 21:20:44 <newbie__> How to store some ascii data in the block chain?
271 2014-01-16 21:20:51 <sipa> don't
272 2014-01-16 21:21:04 <newbie__> what about transaction messages?
273 2014-01-16 21:21:10 <Ry4an> those aren't in the blockchain
274 2014-01-16 21:21:15 <Ry4an> they're only on that website you're looking at
275 2014-01-16 21:21:42 <newbie__> for a couple of years ago I saw some attack where Dan Kaminsky stored some ascii art in the block chain
276 2014-01-16 21:21:50 <sipa> yeah, he did
277 2014-01-16 21:24:08 <shesek> ferroh, re "Does it look like this was done maliciously?" - seems like it was sent eventually to the same addresses, so I assume not
278 2014-01-16 21:28:50 <ferroh> shesek: Is there a way that I can ask this user (who is using blockchain.info's wallet) to resend this? Or do I need to wait for the transaction to drop out of the memory pool
279 2014-01-16 21:29:25 <shesek> ferroh, there's no way to re-send this transaction, the inputs are already spent
280 2014-01-16 21:29:48 <ferroh> In other words, the user has already moved the coins that were "returned" to him
281 2014-01-16 21:29:54 <ferroh> ?
282 2014-01-16 21:31:36 <warren> sipa: did anyone look into the leveldb issue?
283 2014-01-16 21:32:15 <warren> sipa: I'm a bit concerned that issue will hamper the ability of more eyes to test master right now. If necessary I'll work on it today.
284 2014-01-16 21:32:49 <sipa> warren: sorry, too tired now
285 2014-01-16 21:33:15 <warren> sipa: how important is it that we retain .ldb support?
286 2014-01-16 21:33:38 <sevenqueue> what is the proper github clone for the master?
287 2014-01-16 21:33:51 <warren> sevenqueue: what is your goal?
288 2014-01-16 21:34:12 <sevenqueue> I'n on testnet now and lots of orphans
289 2014-01-16 21:34:42 <sipa> sevenqueue: could you try whether #3514 helps?
290 2014-01-16 21:34:58 <sevenqueue> I'll check
291 2014-01-16 21:39:01 <sipa> warren: i checked the source, if a db repair is attempted, everything is rewritten to .ldb
292 2014-01-16 21:45:13 <warren> sipa: do we really need to support .ldb in bitcoin?
293 2014-01-16 21:45:30 <warren> sipa: let's write only .sst and rename .ldb to .sst if db repair
294 2014-01-16 21:45:54 <sipa> more code
295 2014-01-16 21:46:01 <sipa> sec, i'm trying another patch
296 2014-01-16 21:47:35 <sipa> warren: pullreq bitcoin/leveldb#3 updated
297 2014-01-16 21:48:54 <warren> sipa: testing
298 2014-01-16 21:49:35 <sipa> thanks!
299 2014-01-16 21:49:54 <warren> sipa: yeah, that's what I tested originally
300 2014-01-16 21:50:34 <sipa> ah, nice
301 2014-01-16 21:53:08 <warren> testing again
302 2014-01-16 21:56:59 <killerstorm> hi. can somebody tell me when OP_RETURN will be usable on mainnet? I mean, when is it expected to be 'available'
303 2014-01-16 21:57:03 <killerstorm> in a month, two, never?
304 2014-01-16 21:58:39 <lechuga__> im not aware of any immediate plans for it to exist
305 2014-01-16 21:58:39 <sipa> whenever people choose to run a release that allows it
306 2014-01-16 21:58:52 <lechuga__> er be availablei shud say
307 2014-01-16 21:59:11 <sipa> and since there is no release of the 0.9 codebase yet, it could be still some months
308 2014-01-16 21:59:22 <lechuga__> is it standard in 0.9?
309 2014-01-16 22:00:11 <sipa> yes
310 2014-01-16 22:03:10 <killerstorm> when do you anticipate the release of 0.9?
311 2014-01-16 22:03:36 <sipa> first release candidate sometime next month
312 2014-01-16 22:03:45 <sipa> unless unexpected events
313 2014-01-16 22:04:51 <killerstorm> ok, thanks
314 2014-01-16 22:06:02 <michagogo> cloud|What was the rule for the various files in a datadir, when copying from one place to another? Was it, chainstate/ not newer than blocks/index/, and blocks/index/ not newer than blocks/*.dat?
315 2014-01-16 22:06:31 <sipa> michagogo|cloud: correct
316 2014-01-16 22:06:59 <michagogo> cloud|sipa: thanks
317 2014-01-16 22:07:46 <warren> sipa: crappppp
318 2014-01-16 22:08:00 <warren> sipa: renamed my .ldb files back to .sst, 0.8.6 thinks it's corrupted
319 2014-01-16 22:08:07 <warren> sipa: something else is incompatible
320 2014-01-16 22:08:42 <warren> sipa: 2 out of 3 tries renaming back to .sst, 0.8.6 thinks it's corrupted.
321 2014-01-16 22:08:44 <sipa> stop panicking
322 2014-01-16 22:08:57 <warren> This isn't panic.
323 2014-01-16 22:09:05 <sipa> ok
324 2014-01-16 22:09:59 <warren> I'm retaining a copy of this index and testing 0.8.6's index with the new patch again.
325 2014-01-16 22:14:22 <flound1129> how do I find the amount of tx fees in a block?
326 2014-01-16 22:15:49 <sipa> sum the values of all outputs of transactions, minus the sum of all inputs in transactions
327 2014-01-16 22:15:53 <sipa> (excluding the coinbase)
328 2014-01-16 22:19:40 <warren> https://github.com/bitcoin/leveldb/pull/3#issuecomment-32553309
329 2014-01-16 22:20:18 <sipa> thanks for testing
330 2014-01-16 22:24:35 <jakov> shesek you're interested in multisig tx, have you seen that deepweb marketplace that coded an electrum plugin for it?
331 2014-01-16 22:26:16 <shesek> jakov, yeah, I did
332 2014-01-16 22:27:00 <shesek> it looks quite complicated from the end-user's perspective though... they're required to setup a pair of keys elsewhere, copy/paste their public keys back to their interface
333 2014-01-16 22:27:06 <shesek> then copy around raw transactions
334 2014-01-16 22:28:21 <jakov> its not mentioned anywhere in bitcointalk.org, seems a shame since multisigs are useful for other stuff, its just a historical accident it came from a drugs marketplace
335 2014-01-16 22:31:58 <jakov> i wonder if they should encode public keys in base58check
336 2014-01-16 22:32:13 <jakov> since if theres an error in copying access to that money might be lost
337 2014-01-16 22:35:08 <shesek> its a good idea, but there's no standard version for that
338 2014-01-16 22:35:42 <shesek> I asked about it awhile ago - http://comments.gmane.org/gmane.comp.bitcoin.devel/2415
339 2014-01-16 22:37:20 <shesek> they could just make up a non-standard one, but that's probably a bad idea and will make it incompatible with other tools
340 2014-01-16 22:40:00 <jakov> what electrum version did you use TMP's plugin with?
341 2014-01-16 22:41:08 <jakov> shesek in https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes someone suggests 52 which would make it start with 4
342 2014-01-16 22:41:15 <jakov> but i never found any other reference to it
343 2014-01-16 22:41:53 <jakov> and noone replied to your mail
344 2014-01-16 22:42:58 <jakov> : (
345 2014-01-16 22:43:53 <jakov> the bitcoin developing machine seems to move slowly, understandable but sometimes i think its just better to do what casascius did and just do it without asking many people
346 2014-01-16 23:01:02 <sevenqueue> sipa with 3370 & 3514 it flys through the orphans but with testnet=1 in the conf it starts half in main and looks at the testnet data and tries to connect to mainnet nodes
347 2014-01-16 23:01:14 <sevenqueue> if I att -testnet to the command line it starts in full testnet mode
348 2014-01-16 23:01:27 <sipa> sevenqueue: are you sure you don't have your data dirs mixed up?
349 2014-01-16 23:01:42 <sevenqueue> ./src/qt/bitcoin-qt -conf=/home/myne/Miner/btc/data/testnet3/bitcoin.conf -datadir=/home/myne/Miner/btc/data/testnet3 &
350 2014-01-16 23:01:57 <sevenqueue> if I add -testnet to that it goes into testnet
351 2014-01-16 23:02:11 <sevenqueue> otherwise it tries to connect to mainnet but shows me my testnet wallet
352 2014-01-16 23:03:21 <warren> sipa: I guess go ahead and commit that leveldb patch?
353 2014-01-16 23:05:00 <sevenqueue> testnet=1 from the conf file
354 2014-01-16 23:05:30 <sevenqueue> I removed the leading space same result, needs -testnet on the command line to go full testnet mode
355 2014-01-16 23:05:45 <sipa> sevenqueue: file a bug, please
356 2014-01-16 23:05:52 <sevenqueue> will do
357 2014-01-16 23:05:57 <helo> sevenqueue: fwiw, i synched git head on testnet just now
358 2014-01-16 23:06:10 <sipa> maybe during the chainparams refactors, we lost the ability to specify -testnet in the config file
359 2014-01-16 23:06:25 <helo> using testnet=1 in ~/.bitcoin/bitcoin.conf
360 2014-01-16 23:06:34 <sipa> ah
361 2014-01-16 23:06:51 <sipa> sevenqueue: you don't happen to have both a .../btc/data/testnet3 and .../btc/data/testnet3/testnet3 ?
362 2014-01-16 23:07:22 <helo> i'm not specifying datadir on cli or config
363 2014-01-16 23:08:18 <sevenqueue> hmmm, yes
364 2014-01-16 23:08:36 <sipa> sevenqueue: my guess is that one is actually a mainnet datadir
365 2014-01-16 23:08:48 <sipa> and the other a real testnet one
366 2014-01-16 23:09:09 <sevenqueue> I'll remove them and start over and see what happens
367 2014-01-16 23:09:15 <sipa> and adding -testnet on the command line vs in the config file... one changes the datadir and the other does not
368 2014-01-16 23:09:33 <sevenqueue> is that command line correct?
369 2014-01-16 23:09:46 <helo> i'd suggest not bothering with datadir
370 2014-01-16 23:10:09 <helo> or rather make it .../btc/data/
371 2014-01-16 23:10:23 <sevenqueue> I moved the data onto a separate drive so when I refresh the vm I can just mount and continue
372 2014-01-16 23:10:38 <helo> it will add the testnet3/ part on its own
373 2014-01-16 23:10:48 <sevenqueue> ah, I'll try
374 2014-01-16 23:10:52 <sevenqueue> thanks
375 2014-01-16 23:11:52 <sipa> warren: found what caused your "other incompatibility" ?
376 2014-01-16 23:13:08 <warren> sipa: no =(
377 2014-01-16 23:13:31 <warren> sipa: can't reproduce it with your new patch either
378 2014-01-16 23:13:39 <sipa> ok
379 2014-01-16 23:24:01 <sevenqueue> if I start the gui with this './src/qt/bitcoin-qt -datadir=/home/myne/Miner/btc/data &' where does it expect to find the conf?
380 2014-01-16 23:26:09 <sipa> in that directory
381 2014-01-16 23:27:00 <sevenqueue> ok, and the conf file I have in that directory has testnet=1 but it starts in mainnet, perhaps I should just start fresh
382 2014-01-16 23:28:47 <sipa> well after the config file is read, the datadir doesn't change anymore i think
383 2014-01-16 23:29:57 <sevenqueue> going to try without -datadir
384 2014-01-16 23:51:42 <nickler> \whois warren
385 2014-01-16 23:51:50 <nickler> \whois warren
386 2014-01-16 23:52:10 <nickler> nevermind, still learning