1 2014-04-26 00:20:33 <heffner> is the secp256k1 java to native wrapper still being developed?
2 2014-04-26 00:22:38 <heffner> @sipa that was your work right?
3 2014-04-26 00:23:19 <heffner> ah no.. it was BlueMatt
4 2014-04-26 00:27:05 <heffner> anybody else here familliar with NativeSecp256k1 ?
5 2014-04-26 00:34:30 <sipa> heffner: BlueMatt wrote the wrapper, i wrote the native implementation
6 2014-04-26 00:35:09 <heffner> the wrapper only has verify sofar.... any plans to expand it?
7 2014-04-26 00:35:24 <sipa> patches welcome
8 2014-04-26 00:52:34 <modyn> i cant use my rcpserver for bitcoind. why?
9 2014-04-26 00:55:29 <heffner> is there a build instruction for secp256k1 on ubuntu? first running autoconf and them ./configure results in: configure: error: cannot find install-sh, install.sh, or shtool in src/build-aux "."/src/build-aux
10 2014-04-26 01:05:46 <modyn> must the bitcoind be synced to blocks? before i could use rpcserver?
11 2014-04-26 01:23:02 <warren> anone happen to be aware of a txid of a double-spent transaction on testnet3?
12 2014-04-26 02:17:28 <warren> anyone have the 1st generation USB mining sticks?
13 2014-04-26 03:21:24 <saizai> Iâve got bitcoind running on my server, and its data files sshfsâd onto my laptop. Iâd like to run Armory so that it runs against the serverâs bitcoind (and so only the server has to run bitcoind/qt), but it seems to insist on having bitcoinqt running locally, and bitcoinqt local + bitcoind on the server donât seem happy running at the same time. Any suggestions?
14 2014-04-26 03:22:52 <saizai> (also fwiw, my laptop is osx, serverâs ubuntu)
15 2014-04-26 03:25:53 <phantomcircuit> saizai, #armory
16 2014-04-26 03:26:02 <saizai> phantomcircuit: thanks
17 2014-04-26 03:26:19 <saizai> ⦠though nobody there?
18 2014-04-26 03:26:35 <saizai> âcept TheSeven
19 2014-04-26 03:26:51 <phantomcircuit> that sounds about right
20 2014-04-26 03:26:55 <phantomcircuit> (hint: dont use armory)
21 2014-04-26 03:27:33 <saizai> (reason?
22 2014-04-26 03:27:54 <Luke-Jr> â¦
23 2014-04-26 03:28:05 <phantomcircuit> surely you're not serious
24 2014-04-26 03:28:37 <Luke-Jr> phantomcircuit: Armory is currently the best wallet software on the "market"â¦
25 2014-04-26 03:28:50 <Luke-Jr> other than being Python <.<
26 2014-04-26 03:30:02 <saizai> ideally Iâd like to have bitcoind on my server handling all the big files, and something on my laptop thatâs secure and can work against my serverâs (trusted) bitcoind for the big stuff so I donât have to have any of that locally
27 2014-04-26 03:30:17 <saizai> armory seemed to fit the bill, though I may be mistaken.
28 2014-04-26 03:30:20 <Luke-Jr> saizai: that's not Armory
29 2014-04-26 03:30:32 <saizai> Luke-Jr: what is?
30 2014-04-26 03:30:43 <phantomcircuit> an spv client
31 2014-04-26 03:30:53 <phantomcircuit> multibit maybe
32 2014-04-26 03:31:03 <phantomcircuit> but honestly multibit makes me a bit nervous
33 2014-04-26 03:31:06 <phantomcircuit> (har har)
34 2014-04-26 03:31:34 <Luke-Jr> Electrum sounds like a closer match, but I don't like to recommend Electrum since they promote "from address" bogus nonsense
35 2014-04-26 03:31:45 <saizai> howso?
36 2014-04-26 03:32:47 <saizai> (explaining that âfrom addressâ issue to the FEC was ⦠interesting. came up in a random issue w/ their reporting proposal too, wanting to tie sale of bitcoin to a particular receipt; had to explain thatâs not quite possible)
37 2014-04-26 03:33:27 <Luke-Jr> saizai: they added some stupid thing where you can right-click an address to "send from" it
38 2014-04-26 03:34:05 <saizai> i.e. have outputs to it be the only inputs to the new tx?
39 2014-04-26 04:21:55 <saizai> oy, armory fucks up when attempting to install on a gui-less server
40 2014-04-26 04:21:59 <saizai> soooo fuck that
41 2014-04-26 06:37:21 <ibwbtc_> Free bitcoin with each bet! I've been nothing but ahead!! https://satoshibet.com/?r=82d1ca24f92d63565e3a4ecba596c057
42 2014-04-26 06:38:59 <gmaxwell> you are nothing bit a scamspammer
43 2014-04-26 06:39:20 <phantomcircuit> gmaxwell, lold
44 2014-04-26 06:40:45 <phantomcircuit> gmaxwell, fun piece of trivia
45 2014-04-26 06:40:55 <phantomcircuit> im porting an ancient bitcoin exploit to dogecoin
46 2014-04-26 06:58:52 <sipa> saizai: sharing datadir between two bitcoin core instances is not supported (they need read write access), and it would very much surprise me if a datadir mounted over sshfs would work
47 2014-04-26 06:59:09 <saizai> sipa: pity :/
48 2014-04-26 06:59:38 <saizai> or that a bitcoind canât use another bitcoind as its data source
49 2014-04-26 06:59:43 <saizai> via rpc eg
50 2014-04-26 07:01:00 <sipa> once we separate the wallet from the full node there will be little reason for that
51 2014-04-26 07:05:59 <saizai> ACTION nods
52 2014-04-26 07:06:05 <saizai> that seems like a good separation to make
53 2014-04-26 07:06:32 <saizai> the daemon can just keep the chain and transmit whatever on command
54 2014-04-26 07:06:44 <sipa> indeed
55 2014-04-26 07:06:58 <saizai> and have the wallet totally separate, asking the daemon for info about what outputs own eg
56 2014-04-26 07:07:12 <sipa> eh no, the wallet tracks that
57 2014-04-26 07:07:22 <saizai> 3rd party outputs
58 2014-04-26 07:07:44 <sipa> hmm?
59 2014-04-26 07:07:51 <saizai> itâd need to know somehow about outputs to addresses it has pks for
60 2014-04-26 07:08:04 <sipa> yes, spv synchronyzation
61 2014-04-26 07:08:08 <saizai> ACTION nods
62 2014-04-26 07:08:27 <saizai> but then the normal wallet can be tiny
63 2014-04-26 07:08:37 <saizai> and btcd remote
64 2014-04-26 07:08:51 <saizai> and not tied to anything personal in particular
65 2014-04-26 07:09:06 <saizai> makes sense
66 2014-04-26 09:44:28 <TheSeven> phantomcircuit: hint: I've only grabbed that #armory channel just to keep the trolls from doing so, I've never seen any official armory people in there.
67 2014-04-26 09:52:19 <GAit> are people in general supportive of projects like btcd? mixed feelings?
68 2014-04-26 09:59:29 <TravelingTeen> I'm hopeing to making it so my app will allow people to schedual a withdrawl and then at certain times I would go and generate a unsigned coinJoin transaction of all those withdrawls combined, Firstly is it even possible to create a "CoinJoin" transaction (I think thats what you call combining the withdrawls) yet using the default bitcoind and json rpc and secondly how in the world would I do it, I've tried researc
69 2014-04-26 09:59:30 <TravelingTeen> hing
70 2014-04-26 09:59:37 <TravelingTeen> online but haven't found anything useful, If im missing something obvious feel free to call me a idiot lol
71 2014-04-26 09:59:45 <TravelingTeen> Coin join isnt really needed even, I just want to create the unsigned transactions so I can move it to a offline wallet and sign it, The advantage to coinJoin would be only having one transaction to save on fees and number of transactions I would need to sign, Rather then paying a fee and signing/sending for each withdrawl
72 2014-04-26 09:59:53 <TravelingTeen> (Yes I copied from #bitcoin)
73 2014-04-26 10:02:57 <jurov> hi all.
74 2014-04-26 10:03:02 <jurov> is it possible that transaction is visible in listtransactions, but get(raw)transaction fails
75 2014-04-26 10:03:26 <jurov> with Invalid or non-wallet transaction id or No information available about transaction?
76 2014-04-26 10:06:53 <wao> hello, I'm running bitcoind 0.9.1 with txindex=1 and when I do bitcoin gettransaction 1f4cc9174229486061e782e2d1f6b29946f1a533528b92fec6a1e72a24595551 I get response error: {"code":-5,"message":"Invalid or non-wallet transaction id"}, I also previously ran -reindex, any ideas?
77 2014-04-26 10:08:29 <TravelingTeen> wao, Are you sure its done downloading?
78 2014-04-26 10:09:07 <wao> "blocks" : 297787,
79 2014-04-26 10:09:10 <wao> from getinfo
80 2014-04-26 10:10:32 <Apocalyptic> wao, bc.i haven't seen your tx either
81 2014-04-26 10:14:18 <sipa> jurov: you have -txindex enabled?
82 2014-04-26 10:15:44 <TravelingTeen> wangbus, Apocalyptic is right: https://blockchain.info/search?search=1f4cc9174229486061e782e2d1f6b29946f1a533528b92fec6a1e72a24595551
83 2014-04-26 10:15:58 <Apocalyptic> sipa, should it matter since he's talking about a tx visible in listtransactions, thus obviously wallet-related
84 2014-04-26 10:15:59 <TravelingTeen> fuck, wao* sorry
85 2014-04-26 10:16:28 <sipa> Apocalyptic: yes, listtransaction queries the wallet and only the wallet
86 2014-04-26 10:16:55 <sipa> Apocalyptic: getrawtransaction only queries the validation database
87 2014-04-26 10:17:14 <Apocalyptic> I see
88 2014-04-26 10:17:41 <sipa> since 0.9 i think gettransaction also shows the raw form
89 2014-04-26 10:17:52 <sipa> and doesn't need txindex
90 2014-04-26 10:21:18 <jurov> sipa we have same case with wao, txindex is enabled
91 2014-04-26 10:22:41 <jurov> we determined that in case of mutated txs, if it is wallet tx, gettransaction works (with confirmations = -1 as it should) but getrawtransaction not
92 2014-04-26 10:23:02 <jurov> and if it's nonwallet tx, neither works
93 2014-04-26 10:23:06 <Apocalyptic> well it looks like 1f4cc9174229486061e782e2d1f6b29946f1a533528b92fec6a1e72a24595551 is not known to the network
94 2014-04-26 10:23:40 <TravelingTeen> I concure :p
95 2014-04-26 10:24:06 <Apocalyptic> <jurov> we determined that in case of mutated txs // define mutated tx
96 2014-04-26 10:24:38 <jurov> conflicts with already confirmed tx
97 2014-04-26 10:24:57 <jurov> the other tx shows in walletconflicts
98 2014-04-26 10:26:12 <sipa> jurov: getrawtransaction queries the validation database
99 2014-04-26 10:26:36 <sipa> jurov: if it's not in the mempool and not in the blockchain, it won't find it
100 2014-04-26 10:27:00 <jurov> anyway, that's not the point.. the point is we should deprecate getrawtransaction and instead use "hex" field from gettransaction if we want to learn more about it
101 2014-04-26 10:27:03 <TravelingTeen> is coin join with PHP using the JSONrpc possible yet?
102 2014-04-26 10:27:12 <sipa> jurov: yup
103 2014-04-26 10:28:09 <jurov> alternatively, iterate walletconflicts, find confirmed tx and use that instead
104 2014-04-26 10:30:13 <sipa> just looking at confirmed transactions shoukd suffice, no?
105 2014-04-26 10:30:30 <sipa> what do you need the conflicts for?
106 2014-04-26 10:30:52 <jurov> well, we have a dice game that accepts zeroconf
107 2014-04-26 10:31:12 <jurov> after update it croaked, so we're analyzing what does it do
108 2014-04-26 12:19:10 <Diablo-D3> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1308572
109 2014-04-26 12:22:00 <GAit> ouch
110 2014-04-26 12:22:39 <airbreather> jurov: "we hage a dice game that accepts zeroconf" -- sounds like a really good way to lose money.
111 2014-04-26 12:22:40 <GAit> that reminds me of ctrl+alt+canc -> task manager, kill screen saver (win 95 bug?)
112 2014-04-26 12:22:47 <airbreather> s/hage/have/
113 2014-04-26 12:29:30 <TravelingTeen> is coin join with PHP using the JSONrpc possible yet?
114 2014-04-26 12:37:26 <sipa> coinjoin is not implemented in the reference client
115 2014-04-26 13:23:29 <modyn> who have a bitcoind rpcserver i could try to use?
116 2014-04-26 13:24:08 <SomeoneWeird> uh, nobody in their right mind? :)
117 2014-04-26 13:48:17 <modyn> anybody who could help me install bitcoind for debian 7? i offer bitcoin as thanks /msg me
118 2014-04-26 13:49:29 <reipr> Im trying to weed out orphan blocks in my block notify script. Currently I am only checking if the block has 0 confirmations.
119 2014-04-26 13:49:43 <reipr> What are the other signs that I am processing an orphan?
120 2014-04-26 13:50:06 <sipa> you should never be notified of an orphan
121 2014-04-26 13:50:14 <reipr> Wouldnt I be safe not processing any blocks that had 0 confirms.
122 2014-04-26 13:50:15 <reipr> ok
123 2014-04-26 13:55:50 <Luke-Jr> reipr: if you mean stale blocks, you need to consider that they *become stale after the fact*
124 2014-04-26 13:56:50 <sipa> reipr: to clarify, what the source code calls "orphan blocks" are blocks whose parents haven't been downloaded yet; you will never ever see these, except in log files
125 2014-04-26 13:57:26 <sipa> reipr: stale blocks (which are often called orphan blocks too), are simply branches of the block tree there were once part of the best known chain, but aren't any longer
126 2014-04-26 13:58:04 <sipa> i believe you're referring to the second, and indeed as Luke-Jr says, you'd only see them when the are active
127 2014-04-26 14:00:49 <reipr> So there is no change that I will process a block as if it is good and then later reprocess the block to fix the original mistake?
128 2014-04-26 14:01:04 <reipr> chance*
129 2014-04-26 14:01:24 <sipa> notify is called whenever the tip of the active block chain changes
130 2014-04-26 14:01:50 <sipa> of course, it is possible that by the time your script to deal with it runs, that is no longer the actual tip
131 2014-04-26 14:03:42 <reipr> During block processing, I never check the tip, I only refer tot he block that was given to my blocknotify script by the blockhash
132 2014-04-26 14:04:11 <sipa> that's fine, but be aware that even if a block is once active, it can be reorganized away later
133 2014-04-26 14:04:19 <reipr> Im processing the block and storing the vouts that are destined to addressess that I care about.
134 2014-04-26 14:04:37 <sipa> you need to be able to roll back too
135 2014-04-26 14:06:05 <reipr> So, 1. Check if the block has confirmations, 2. Check the block has a parent, if not roll back to a previous block that has a parent?
136 2014-04-26 14:06:23 <sipa> every block has a parent
137 2014-04-26 14:06:32 <sipa> and no, that's not what i meant
138 2014-04-26 14:06:43 <sipa> assume the current block chain is a-b
139 2014-04-26 14:07:00 <sipa> a block c on top of b arrives and you get notified, so you process c
140 2014-04-26 14:07:23 <sipa> now a fork appears, and a block d and e replace c
141 2014-04-26 14:07:28 <sipa> so you get a-b-d-e
142 2014-04-26 14:07:33 <sipa> you'll get notified for e
143 2014-04-26 14:07:42 <reipr> ah
144 2014-04-26 14:07:57 <reipr> so I check if I have already processed the parent. If not I roll back
145 2014-04-26 14:08:01 <sipa> what you do is walk back to the point where you know (b), notice that c has disappeared, undo processing of c, and process d and e
146 2014-04-26 14:09:07 <reipr> ok so. Check that I processed blocks parent, if not walk up the chain until I hit a block Ive already processed. Check which children I processed for that block and undo it.
147 2014-04-26 14:09:22 <sipa> indeed
148 2014-04-26 14:09:25 <reipr> rinse repeat
149 2014-04-26 14:09:43 <reipr> sweet. glad I asked the question, there is alot of bad info out there
150 2014-04-26 14:11:23 <reipr> What is the likelyhood that this can happen. I mean is it feasable that I could have already marked a txout as "confrimed" (6 confirmations) and then have to go back?
151 2014-04-26 14:13:33 <reipr> nvm I see it.
152 2014-04-26 14:13:45 <reipr> Once proof of a longer chain exists...
153 2014-04-26 14:14:04 <reipr> Hence, wait 6 confirms.
154 2014-04-26 14:16:42 <reipr> I guess the edge case: 1. I've been processing blocks, when I process block c, one of my transactions has received 6 confirmations. So it is possible that I have marked a transaction as confirmed when in fact it is not
155 2014-04-26 14:17:42 <sipa> yes, confirmations are just a measure for how certain you are it won't be reverted
156 2014-04-26 14:18:25 <reipr> I guess even in that case, the chance of the transaction being confirmed in the next block (even if forked) is high considering the first 4 blocks were not stale
157 2014-04-26 14:18:52 <reipr> ok
158 2014-04-26 14:20:25 <reipr> Im going to store the blockchain including stale blocks, it will be interesting to see over time.
159 2014-04-26 14:23:52 <reipr> You hear the common "Wait 6 confirmations, since the amount of hashing power to create 6 blocks in a row is so high that it is not feasible" argument. But where is the actual math?
160 2014-04-26 14:24:16 <belcher> in the whitepaper
161 2014-04-26 14:24:42 <belcher> though the whitepaper assumes very good decentralisation of mining
162 2014-04-26 14:24:48 <belcher> i.e. not what we have today
163 2014-04-26 14:24:55 <belcher> theres that website where yuo can work out
164 2014-04-26 14:25:10 <belcher> 40% of hash power can reverse 6 confirms 50% of the time
165 2014-04-26 14:26:06 <belcher> i can never remember the link
166 2014-04-26 14:29:15 <reipr> https://bitcoil.co.il/Doublespend.pdf
167 2014-04-26 14:29:27 <reipr> I guess my google-fu just got better
168 2014-04-26 14:29:57 <belcher> no i tried googling, its not that
169 2014-04-26 14:30:01 <belcher> its a simple javascript website
170 2014-04-26 14:30:17 <reipr> There is a table there that lists your numbers you referenced
171 2014-04-26 14:30:19 <belcher> put in hash power proportion and number of confirms, tell you probability of reversing
172 2014-04-26 14:30:56 <reipr> theres a table in that pdf that lists it, along with the math involved
173 2014-04-26 14:38:36 <belcher> im trying to understand tx scripts of p2sh addresses to see if they were multisig or something else
174 2014-04-26 14:38:49 <shesek> you can't
175 2014-04-26 14:39:02 <shesek> p2sh addresses are an hash of the script
176 2014-04-26 14:39:04 <belcher> they are inputs, the p2sh have been spent from
177 2014-04-26 14:39:27 <shesek> ah - so yeah, in the spending transaction, the inputs contains the original script being spent
178 2014-04-26 14:39:42 <belcher> so like a914aa2ae7db0b5da26918896cc738e5b858944b1f3187, 0xa9 is OP_HASH160 according to wiki, but 0x14 isnt anything
179 2014-04-26 14:42:31 <belcher> it seems short though, thats meant to contain 2 pubkeys within it
180 2014-04-26 14:44:35 <shesek> what are you looking into, exactly? you need the scriptSig of the input
181 2014-04-26 14:44:42 <sipa> belcher: no, it does not contain two pubkeys
182 2014-04-26 14:44:52 <sipa> belcher: you reveal the actual pubkeys only when spending
183 2014-04-26 14:45:03 <sipa> including the actual script that contains them
184 2014-04-26 14:45:07 <belcher> this is the spending tx, the p2sh adderss is being spent from
185 2014-04-26 14:45:07 <shesek> belcher, look here: https://blockchain.info/tx/4102a51c8a29f901fd1d7489b48cf6cb5ab0bea00cc77d348f848c94d9ce4755
186 2014-04-26 14:45:32 <belcher> hmm
187 2014-04-26 14:45:42 <shesek> the last part of the input script is the p2sh script
188 2014-04-26 14:45:59 <sipa> it's often called the 'redeemscript'
189 2014-04-26 14:46:11 <sipa> as input/output script are ambiguous
190 2014-04-26 14:46:12 <belcher> ok
191 2014-04-26 14:46:35 <belcher> so what is the 0x30 straight after OP_FALSE, its not an opcode
192 2014-04-26 14:47:33 <belcher> a pubkey i guess
193 2014-04-26 14:48:44 <sipa> no, a signature
194 2014-04-26 14:49:17 <modyn> i have been upgraded libc and a bunch of other things, now everything that is not statically linked barely works. Could anybody help me fix this? I offer you payment by paypal or bitcoin /msg me
195 2014-04-26 14:49:47 <sipa> modyn: you were warned not to upgrade your c library
196 2014-04-26 14:50:03 <sipa> and this is not #debian
197 2014-04-26 14:51:05 <shesek> belcher, as sipa mentioned, its a signature, not a public key. the public keys are contained in the redeemScript, which is that last part being pushed
198 2014-04-26 14:51:34 <shesek> and there are also PUSHDATA ops in there that blockchain.info doesn't show
199 2014-04-26 14:52:07 <sipa> actually, just one pushdata
200 2014-04-26 14:52:23 <belcher> ok
201 2014-04-26 16:17:06 <jgarzik> For the nth time, I wish there was a "bitcoin cookbook"
202 2014-04-26 16:17:41 <jgarzik> A set of "recipes" which describe certain trust situations, and provide full scripts + TX examples on how to properly handle those situations.
203 2014-04-26 16:18:18 <jgarzik> You see plenty of these on the forums or mailing list, in English textual form ("1. tx1 does this. 2. tx1_refund looks like this. 3. alice does that.")
204 2014-04-26 16:18:55 <jgarzik> It would be better to have a computer-parseable set of examples. Then I could give out these links to other people.
205 2014-04-26 16:26:55 <petertodd> jgarzik: I've got a few of those in python-bitcoinlib now
206 2014-04-26 16:54:45 <jgarzik> Thought bubble
207 2014-04-26 16:54:55 <jgarzik> What would be the impact of requiring a simply PoW on each transaction?
208 2014-04-26 16:55:03 <jgarzik> *simple
209 2014-04-26 16:55:30 <jgarzik> to relay, before it is confirmed in a block.
210 2014-04-26 16:57:53 <sipa> jgarzik: PoW == money; requiring PoW for a transactions == fee
211 2014-04-26 16:58:25 <jgarzik> Or more broadly "economic friction"
212 2014-04-26 16:58:45 <sipa> it would essentially be hashcash on top of reusable-hashcash :p
213 2014-04-26 17:00:10 <jgarzik> ACTION is just thinking in the direction of relaying having a cost that's difficult to translate into real terms
214 2014-04-26 17:00:29 <jgarzik> a PoW might eliminate unknown DoS vectors, by not presuming that relaying is free
215 2014-04-26 17:01:46 <jgarzik> OTOH, if mempool superblock works as idealized, that becomes essentially a rolling forecast of transactions likely to be confirmed in the next N blocks
216 2014-04-26 17:02:08 <jgarzik> If we are good at guessing what is likely to be confirmed, then relaying should succeed or fail naturally via that avenue
217 2014-04-26 17:14:58 <gmaxwell> jgarzik: fee is just stored POW in a transaction; with the added benefit that there are more ways to get it that only via computation... which is particularly useful on mobile devices.
218 2014-04-26 18:26:04 <bawse> Is it easy to program api's
219 2014-04-26 18:33:29 <Genitrust> where does Bitcoin's "nonce" come from?
220 2014-04-26 18:34:03 <sipa> you mean the word?
221 2014-04-26 18:34:15 <sipa> or the value of block header nonces?
222 2014-04-26 18:34:24 <sipa> or the extranonce inside the coinbase?
223 2014-04-26 18:36:44 <Genitrust> sipa i'm looking to learn more about this "nonce" thing. it appears to be an entirely random number... but i wonder a lot of things
224 2014-04-26 18:36:52 <Genitrust> so let me re-phrase that question for ya :)
225 2014-04-26 18:37:22 <sipa> nonce just means "number used only once"
226 2014-04-26 18:37:47 <sipa> the one in block headers just there to have a variable in it, so its hash can vary
227 2014-04-26 18:39:02 <Genitrust> referring to this: https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers
228 2014-04-26 18:39:08 <Genitrust> who supplies that nonce?
229 2014-04-26 18:39:12 <Genitrust> where does it come from?
230 2014-04-26 18:39:15 <Genitrust> (the block header)
231 2014-04-26 18:40:32 <sipa> the miner chooses it
232 2014-04-26 18:40:42 <sipa> its value is irrelevant
233 2014-04-26 18:40:54 <Genitrust> ah ok, is this the miner who "solved" the block?
234 2014-04-26 18:40:55 <michagogo> cloud|Does anyone know of a network-protocol-level Bitcoin client?
235 2014-04-26 18:41:05 <sipa> Genitrust: yes
236 2014-04-26 18:41:15 <Genitrust> awesome, thanks sipa
237 2014-04-26 18:41:27 <Genitrust> and is that miner's address saved on that block header?
238 2014-04-26 18:41:36 <michagogo> cloud|(in other words, something that I can use to connect to a node and arbitrarily send network messages)
239 2014-04-26 18:41:43 <sipa> Genitrust: well, evidently... the miner choses the nonce; if he choses badly, the result just isn't valid, and he has to try a new nonce
240 2014-04-26 18:41:59 <sipa> Genitrust: no, the payout is done by the furst transaction in a block
241 2014-04-26 18:42:25 <Genitrust> ahh, so the payout (which goes to who solved the block) becomes the first transaction of that ?
242 2014-04-26 18:42:28 <Genitrust> of that block* ?
243 2014-04-26 18:42:39 <sipa> #bitcoin please
244 2014-04-26 18:43:44 <Genitrust> as in, i should ask #bitcoin that?
245 2014-04-26 18:44:31 <Genitrust> i think i'm gunna read these specifications...this is pretty cool :P)
246 2014-04-26 18:44:32 <Genitrust> :) *
247 2014-04-26 18:44:34 <Genitrust> have a good day!
248 2014-04-26 20:13:11 <michagogo> cloud|https://github.com/bitcoin/bitcoin/pull/4094/
249 2014-04-26 20:13:18 <michagogo> cloud|...yet another Qt build? :-/
250 2014-04-26 20:21:39 <rnicoll> hearn, sorry, being lazy, but this probably isn't worth a whole new email; fairly certain IANA would take a vendor registration from Bitcoin if people wanted to do that, but more asking to have asked than anything else, given it's been implemented as-is.
251 2014-04-26 20:22:07 <hearn> yeah. i mean, iâm not sure how much it really matters
252 2014-04-26 20:22:17 <hearn> mime types are pretty ad hoc in practice
253 2014-04-26 20:23:32 <phantomcircuit> jgarzik, i'd swear python-bitcoinlib used to have a filterload message type
254 2014-04-26 20:23:35 <phantomcircuit> amicrazy
255 2014-04-26 20:24:11 <Luke-Jr> rnicoll: what vendor?
256 2014-04-26 20:29:07 <rnicoll> Luke-Jr, "Bitcoin". IANA uses the term "vendor" fairly... well incorrectly. Mostly to mean "responsible organisation"
257 2014-04-26 20:29:43 <rnicoll> hearn, only real thing to think about is whether it's worth it for enabling lookup from MIME type back to standard
258 2014-04-26 20:30:23 <Luke-Jr> rnicoll: my point is that there is no Bitcoin organisation
259 2014-04-26 20:31:18 <hearn> i think theyâd probably just roll with it in our case
260 2014-04-26 20:32:02 <rnicoll> Luke-Jr, the Github organisation would probably be given the responsibility, I think
261 2014-04-26 20:33:23 <rnicoll> Luke-Jr, could put a recognised MIME types list in amongst the BIPS repo. I may have over thought this..
262 2014-04-26 20:49:01 <petertodd> phantomcircuit: which python-bitcoinlib?
263 2014-04-26 20:50:44 <petertodd> hmm, git log -p |grep -i filterload turns up nothing
264 2014-04-26 20:54:26 <phantomcircuit> petertodd, guess not
265 2014-04-26 21:45:42 <_alp_> Anyone around? Trying to figure out why I can't get RPC to work with regtest
266 2014-04-26 21:47:06 <sipa> what fails?
267 2014-04-26 21:47:39 <_alp_> connection failure. can use it with testnet or mainnet no problem
268 2014-04-26 21:47:55 <_alp_> socket hang up
269 2014-04-26 21:50:17 <_alp_> sipa: was trying python before, bitcore now.
270 2014-04-26 21:56:54 <jgarzik> phantomcircuit, I certainly coded that, once upon a time
271 2014-04-26 21:57:06 <jgarzik> phantomcircuit, don't see it now ;p
272 2014-04-26 21:59:20 <phantomcircuit> jgarzik, i can distinctly remember using it at somepoint
273 2014-04-26 22:04:33 <hearn> _alp_: does debug.log say much?
274 2014-04-26 22:12:13 <_alp_> hearn: let me check
275 2014-04-26 22:14:13 <_alp_> hearn: appears that nothing is in the log since it started up
276 2014-04-26 22:16:23 <hearn> odd
277 2014-04-26 22:16:33 <hearn> youâre doing ./bitcoind -regtest getinfo ?
278 2014-04-26 22:17:16 <_alp_> that works like a charm, its just RPC thats failing
279 2014-04-26 22:19:25 <sipa> well if getinfo works, then RPC works...
280 2014-04-26 22:21:03 <_alp_> sipa: sorry, I might be phrasing this wrong then. Just trying a simple python program it doesn't respond.
281 2014-04-26 22:21:23 <_alp_> httplib.BadStatusLine: ''
282 2014-04-26 22:22:44 <_alp_> ihavenoideawhatimdoingdog.jpg
283 2014-04-26 22:24:36 <richcollins> Will nodes hold/relay a transaction that references an output that they don't know about yet?
284 2014-04-26 22:24:41 <richcollins> I'm trying to minimize the amount of time that the user has to wait for 2 transactions (one dependent on the other) to be included in a block.
285 2014-04-26 22:24:47 <richcollins> I was hoping to broadcast them both at the same time.
286 2014-04-26 22:25:14 <richcollins> or do I have to wait until the first is confirmed before broadcasting the second
287 2014-04-26 22:26:29 <sipa> richcollins: the mempool holds unconfirmed transactions that have been verified, and when new transaactions arrive that spend their outputs, they can go in the memory pool too
288 2014-04-26 22:26:46 <sipa> there is also an orphan pool, for transactions whose inputs are unknown
289 2014-04-26 22:26:58 <richcollins> Right but is there a chance that they will receive tx B before A and reject it?
290 2014-04-26 22:27:00 <richcollins> ah ok
291 2014-04-26 22:27:18 <sipa> the orphan pool is smaller and has stricter rules to prevent abuse, and transactions are randomly removed from it
292 2014-04-26 22:27:19 <richcollins> So will the tx be moved from the orphan pool to the mempool when its depedency arrives?
293 2014-04-26 22:27:25 <sipa> yes
294 2014-04-26 22:27:55 <richcollins> OK so this strategy should work with the caveat that the parent tx might be mutated before being included in a block
295 2014-04-26 22:28:04 <richcollins> rendering the child invalid
296 2014-04-26 22:28:14 <richcollins> which would require me to recreate / broadcast it?
297 2014-04-26 22:32:22 <_alp_> sipa: any idea why command lind rpc would work but json rpc wouldnt?
298 2014-04-26 22:32:55 <sipa> no
299 2014-04-26 22:33:06 <sipa> the command line uses jsonrpc
300 2014-04-26 22:35:44 <_alp_> seems to be that the server just has no response. If I use wrong port, it cannot connect, but correct port of 18444 just gives empty response, so strange.
301 2014-04-26 22:35:56 <_alp_> and everything works great with testnet/mainent
302 2014-04-26 22:37:16 <Luke-Jr> lechuga_â¦â¦
303 2014-04-26 22:39:47 <sipa> Luke-Jr: ?
304 2014-04-26 22:40:38 <Luke-Jr> sipa: hard to get ahold of him :P
305 2014-04-26 22:41:46 <richcollins> Hrm how can you estimate fees for a multisig transaction when you donât know how many inputs / outputs the counterparty will add
306 2014-04-26 22:41:48 <richcollins> and visa versa
307 2014-04-26 22:42:05 <richcollins> and if you canât estimate fees then you donât know which inputs to select in the first place
308 2014-04-26 22:42:36 <sipa> that's no different for normal transactions
309 2014-04-26 22:43:13 <_alp_> sipa: its a bit different in that everything is under your control in a single sig.
310 2014-04-26 22:43:38 <Luke-Jr> richcollins: you don't know miner policies either
311 2014-04-26 22:44:04 <richcollins> right I mean given some chosen fee
312 2014-04-26 22:44:06 <Luke-Jr> just factor in enough that you're certain to have enough (and put whatever is left in change)
313 2014-04-26 22:44:17 <richcollins> you can choose a fee that youâre confident will lead to acceptance of the tx
314 2014-04-26 22:44:28 <richcollins> ah I see
315 2014-04-26 22:44:35 <richcollins> but arentâ fees a fn of the size of the tx
316 2014-04-26 22:44:44 <sipa> yes
317 2014-04-26 22:45:06 <_alp_> sipa: where is code for json-rpc call in bitcoind? trying to see what might be different in that version.
318 2014-04-26 22:45:13 <sipa> _alp_: rpcclient.cpp
319 2014-04-26 22:45:21 <_alp_> sipa: ty sir
320 2014-04-26 22:45:28 <richcollins> So the counterparty could send you inputs and outputs that cause the tx size to be more than the expected fee would cover
321 2014-04-26 22:45:51 <sipa> richcollins: i'd say they are responsible for adding enough fee for their part?
322 2014-04-26 22:46:01 <richcollins> ah good point
323 2014-04-26 22:46:25 <richcollins> then you could figure out final fees before broadcasting and add some back to output values if needed
324 2014-04-26 22:46:28 <_alp_> sipa: tough to decide whos part, there are "shared parts", but yeah, you can divide that in half if you wanted to be truly fair.
325 2014-04-26 22:46:30 <richcollins> that should work
326 2014-04-26 22:46:52 <richcollins> right it could be shared based on size of each contribution
327 2014-04-26 22:46:56 <richcollins> sounds good thanks for the idea
328 2014-04-26 22:46:58 <shesek> if one party has 100 outputs and the other has just one, then an equal split is not really fair
329 2014-04-26 22:49:35 <PRab> Each party should cover the fee for their own inputs and outputs. Overhead should be split equally.
330 2014-04-26 23:16:22 <modyn> hi i want to install bitcoind for debian 7. could anybody help me please? /msg me
331 2014-04-26 23:18:50 <shesek> can a child transaction be on the same block as its parent?
332 2014-04-26 23:19:56 <hearn> yes
333 2014-04-26 23:21:32 <shesek> thanks
334 2014-04-26 23:25:43 <Luke-Jr> shesek: it does need to be in the right order though
335 2014-04-26 23:27:28 <shesek> yeah, makes sense... when you're validating a block you're going over the transactions in order, so you'd want to see the funding transaction before the one spending it
336 2014-04-26 23:28:18 <ProfMac> I'm reading more source from the git. I'm tracing execution flow in the network starting with a submitblock RPC. I need some help to find where a peer receives the propagated block. I assume it's just an open connection that gets parsed, but C++ is a foreign language to me and a filename / linenumber would really be appreciated.