1 2014-01-14 00:00:02 <sipa> maaku: think :)
2 2014-01-14 00:00:54 <phantomcircuit> sipa, it's all the IsCanonicalSignature stuff right
3 2014-01-14 00:00:55 <phantomcircuit> er
4 2014-01-14 00:00:59 <phantomcircuit> IsCanonicalPubKey
5 2014-01-14 00:01:20 <sipa> standardness has little to do with it, as the wallet will see everything in the blockchain in any case
6 2014-01-14 00:04:20 <wallet42> are there plans to implement deterministic signatures?
7 2014-01-14 00:04:45 <warren> Would you accept a patch that adds an optional parameter for -rescan to have it scan only after block X?
8 2014-01-14 00:05:06 <wallet42> so i can know the final txid to use it in a followup tx for example
9 2014-01-14 00:09:22 <sipa> wallet42: deterministic signatures are on the radar, but they cannot be enforced
10 2014-01-14 00:09:30 <sipa> wallet42: it's the client side choice whether to use them or not
11 2014-01-14 00:09:39 <wallet42> no i dont want them to be enforced
12 2014-01-14 00:09:52 <wallet42> i just want to be able to precompute a txid
13 2014-01-14 00:10:15 <sipa> i don't understand; why can't you do that now?
14 2014-01-14 00:10:24 <sipa> you just create the transaction
15 2014-01-14 00:10:30 <sipa> there's nothing "pre" to it
16 2014-01-14 00:11:15 <wallet42> create a chain of transactions
17 2014-01-14 00:11:24 <sipa> you can do that now...
18 2014-01-14 00:11:46 <wallet42> the publishing happens in reverse order
19 2014-01-14 00:11:53 <wallet42> so everyone is sure he cannot be screwed
20 2014-01-14 00:12:46 <gmaxwell> wallet42: you can do that now
21 2014-01-14 00:12:55 <wallet42> ah⦠no it wouldnt work⦠if 2 inputs need to be signed i cannot know the hash
22 2014-01-14 00:13:13 <wallet42> witout them being signed together
23 2014-01-14 00:13:35 <gmaxwell> Yes, it works fine. And to the extent it doesn't determinstic signatures cannot help you at all.
24 2014-01-14 00:13:35 <sipa> deterministic signatures doesn't mean you can know the signature before signing
25 2014-01-14 00:13:55 <sipa> and the transaction hash depends on the signature
26 2014-01-14 00:13:57 <wallet42> no.. forget it my idea is not going to work with deterministic signatures
27 2014-01-14 00:13:59 <wallet42> yes
28 2014-01-14 00:14:42 <gmaxwell> wallet42: whatever protocol you want can probably be done however.
29 2014-01-14 00:15:02 <gmaxwell> But you haven't described it in enough detail for me to tell you how to make it workable, because you described only mechenism not goals.
30 2014-01-14 00:15:17 <wallet42> it has to be trustless :) im still working on it
31 2014-01-14 00:16:10 <gmaxwell> wallet42: the way I've addressed this in protocols is just by having parties sign data they've never seen (e.g. give them the hash to sign). Which is perfectly safe to do if you do not reuse keys.
32 2014-01-14 00:17:23 <wallet42> i will publish it soon, you can tear it to pieces afterwards ;)
33 2014-01-14 00:17:48 <wallet42> gmaxwell: i dont think signing arbitrary hashes is sth i would trust....
34 2014-01-14 00:17:53 <wallet42> isnt
35 2014-01-14 00:17:58 <wallet42> is
36 2014-01-14 00:20:23 <gmaxwell> wallet42: uhh.
37 2014-01-14 00:20:34 <gmaxwell> Why not?
38 2014-01-14 00:24:29 <wallet42> oh i didnt see the "do not reuse keys"
39 2014-01-14 00:24:40 <wallet42> you're probably right then
40 2014-01-14 00:30:38 <lechuga__> ugh found it
41 2014-01-14 00:30:50 <lechuga__> this lib wasnt properly detecting key compression
42 2014-01-14 00:31:21 <realazthat> sipa: you mentioned yesterday about using the confirmations=0 to go back up the chain
43 2014-01-14 00:31:39 <realazthat> so can I assume that normally blocks always have >= 1 confirmation
44 2014-01-14 00:31:50 <realazthat> I mean, that makes sense
45 2014-01-14 00:31:55 <realazthat> just want to confirm
46 2014-01-14 00:31:59 <sipa> blocks in the main chain always have >= confirmation
47 2014-01-14 00:32:04 <sipa> 1
48 2014-01-14 00:32:09 <realazthat> ok very good
49 2014-01-14 00:32:32 <realazthat> sipa: thanks
50 2014-01-14 00:33:02 <realazthat> how am I supposed to test code that runs only when there is a fork
51 2014-01-14 00:33:21 <sipa> use regtest mode, and cause a fork :D
52 2014-01-14 00:35:24 <realazthat> mmm where is that documented
53 2014-01-14 00:37:27 <sipa> it's not in any release yet
54 2014-01-14 00:41:47 <warren> cfields: what's the status of the gitian macosx target?
55 2014-01-14 00:41:51 <maaku> isn't there also a reorg unit test?
56 2014-01-14 00:41:53 <maaku> you could use that
57 2014-01-14 00:42:11 <realazthat> sipa: ah
58 2014-01-14 00:42:13 <realazthat> :(
59 2014-01-14 00:42:24 <realazthat> sipa: how hard is it to fork testnet?
60 2014-01-14 00:42:58 <realazthat> or alternatively, are there any forks existing in testnet?
61 2014-01-14 00:43:18 <realazthat> erm, that doesn't matter, I wouldn't be able to get the bad part :(
62 2014-01-14 00:43:35 <warren> realazthat: very easy to fork it given difficulty drops to minimum after 20 minutes of no blocks
63 2014-01-14 00:43:43 <gmaxwell> realazthat: sure there are forks on testnet.
64 2014-01-14 00:43:56 <gmaxwell> I have a blockchain file for testnet here with a several thousand block long fork.
65 2014-01-14 00:44:05 <realazthat> gmaxwell: oh can I have that
66 2014-01-14 00:44:12 <gmaxwell> yea, lemme find
67 2014-01-14 00:44:14 <realazthat> I can feed that into my bitcoind, right
68 2014-01-14 00:44:31 <realazthat> gmaxwell: bonus, any double spends?
69 2014-01-14 00:44:42 <gmaxwell> No, no double spends, I think.
70 2014-01-14 00:44:48 <realazthat> ok
71 2014-01-14 00:45:30 <gmaxwell> crud. it's not on my laptop.
72 2014-01-14 00:45:56 <gmaxwell> midnightmagic: would you happen to have the old testnet3 blockchain which was reorged away handy
73 2014-01-14 00:46:05 <sipa> gmaxwell: you didn't vaporize it, did you?
74 2014-01-14 00:46:23 <gmaxwell> sipa: testnet3? yea I wiped out and replaced the chain at one point.
75 2014-01-14 00:46:38 <sipa> ah, so it's in the cloud!
76 2014-01-14 00:46:57 <gmaxwell> yea, the data exists... anyone who ran a testnet3 node from the start has it.
77 2014-01-14 00:47:32 <gmaxwell> well maybe its on this node, lemme reindex and see if I see a reorg.
78 2014-01-14 00:48:01 <realazthat> gmaxwell: btw, how can you see it
79 2014-01-14 00:48:04 <gmaxwell> oh wait, would a reindex preserve the orphans?
80 2014-01-14 00:48:21 <gmaxwell> realazthat: "REORGANIZE:" in the log.
81 2014-01-14 00:48:27 <realazthat> ah cool
82 2014-01-14 00:48:34 <sipa> gmaxwell: no, but it will retain side chains :p
83 2014-01-14 00:48:51 <gmaxwell> stupid language... :P
84 2014-01-14 00:49:43 <midnightmagic> gmaxwell: Hrm. Not sure. I have a long-running testnet3 node. No clue whether it contains the old reorg stuff.
85 2014-01-14 00:50:04 <gmaxwell> man, why is shutdown taking forever lately.
86 2014-01-14 00:50:20 <gmaxwell> esp on my testnet node.. stop.. and three minutes later I give up and kill -9
87 2014-01-14 00:50:52 <midnightmagic> virtually instantaneous for me.
88 2014-01-14 00:51:04 <gmaxwell> darn, the blockfiles on my laptop don't appear to have the sidechain.
89 2014-01-14 00:51:21 <midnightmagic> right now, how were you detecting whether the reorg existed? -loadblocks?
90 2014-01-14 00:52:51 <sidhujag> Hey guys im looking at the merged-mined blocks and seeing that the hash of the current block is not existing in the scriptsig of the coinbase TX in the merge-mine header... like it is here: https://en.bitcoin.it/wiki/Merged_mining_specification with the hash d8a7c3e01e1e95bcee015e6fcc7583a2ca60b79e5a3aa0a171eddd344ada903d coming after the merged-mine mask
91 2014-01-14 00:53:11 <sidhujag> is the spec out of date?
92 2014-01-14 00:53:46 <warren> wumpus: sipa: https://github.com/bitcoin/bitcoin/pull/3383 regarding the change of isMine from bool to isminetype, it remains type "bool" in some parts of the code, is this intended?
93 2014-01-14 00:54:24 <sipa> warren: depends which layer you're talking about
94 2014-01-14 00:55:04 <sipa> can you give an example?
95 2014-01-14 00:55:31 <warren> src/qt/addresstablemodel.cpp:static AddressTableEntry::Type translateTransactionType(const QString &strPurpose, bool isMine)
96 2014-01-14 00:55:31 <warren> src/qt/addresstablemodel.h: void updateEntry(const QString &address, const QString &label, bool isMine, const QString &purpose, int status);
97 2014-01-14 00:55:31 <warren> src/qt/walletmodel.h: void updateAddressBook(const QString &address, const QString &label, bool isMine, const QString &purpose, int status);
98 2014-01-14 00:55:33 <warren> and a few others
99 2014-01-14 00:55:50 <sipa> oh, i have no clue about the gui
100 2014-01-14 00:56:16 <warren> src/wallet.h: &address, const std::string &label, bool isMine,
101 2014-01-14 00:56:20 <warren> not gui
102 2014-01-14 00:58:43 <sipa> warren: the return value of IsMine(CTransaction) is supposed to be a bool - it should be called "IsRelevantToMe", as it could just as easily be a mix
103 2014-01-14 00:59:33 <warren> ShouldICare()
104 2014-01-14 00:59:52 <sipa> for NotifyAddressBookChanged it could be made into isminetype, if the GUI uses/needs that information
105 2014-01-14 01:00:01 <sipa> i'll comment
106 2014-01-14 01:00:30 <warren> I ran into a problem with NotifyAddressBookChanged where it changes isminetype from 0 to 1 if you update the label of a watchonly address.
107 2014-01-14 01:00:47 <warren> but that's in 0.8 where SetAddressBook is different
108 2014-01-14 01:00:55 <warren> it lacks a "purpose" parameter
109 2014-01-14 01:00:58 <warren> not sure if I need to add that
110 2014-01-14 01:24:06 <lechuga__> finally got testnet to accept my crazy txn
111 2014-01-14 01:24:13 <lechuga__> that literally took the better part of a day
112 2014-01-14 01:26:28 <lechuga__> hey wizkid057
113 2014-01-14 01:26:40 <lechuga__> will Eligius' pushtxn.php accept non-standard txns?
114 2014-01-14 01:26:55 <wizkid057> some
115 2014-01-14 01:27:24 <lechuga__> im trying to make an external state (oracle) contract/claim sequence happen
116 2014-01-14 01:27:32 <lechuga__> think i migth get lucky?
117 2014-01-14 01:27:44 <lechuga__> its just a multisig with a <hash> OP_DROP prepended
118 2014-01-14 01:27:48 <wizkid057> I'd much rather stick with bitcoin related transactions
119 2014-01-14 01:27:53 <wizkid057> and not non-bitcoin spam
120 2014-01-14 01:27:58 <lechuga__> it is for bitcoins
121 2014-01-14 01:28:22 <lechuga__> the contract/claim r for the promise/redemption of coins
122 2014-01-14 01:28:35 <wizkid057> interesting
123 2014-01-14 01:28:42 <wizkid057> feel free to give it a shot
124 2014-01-14 01:28:46 <lechuga__> k thx
125 2014-01-14 01:33:26 <lechuga__> wizkid057: one more thing
126 2014-01-14 01:33:47 <lechuga__> does that php script just call 'sednrawtransaction' on a modded bitcoind?
127 2014-01-14 01:33:54 <lechuga__> sendrawtransaction*
128 2014-01-14 01:34:48 <lechuga__> or is it hooked into eloipool or something
129 2014-01-14 01:34:48 <lianj> if only one pool accepts your txs, don't rely on it to keep doing that
130 2014-01-14 01:35:29 <lechuga__> lianj: yeah this just to see if i can actually do it
131 2014-01-14 01:35:41 <lechuga__> dont plan on spamming them with these or anything
132 2014-01-14 01:39:59 <wizkid057> lechuga__: it calls sendrawtransaction on a modded bitcoind that is directly peered to the internal pool servers
133 2014-01-14 01:41:45 <lechuga__> cool thx again
134 2014-01-14 01:55:04 <sidhujag> noone knows the answer to mine?
135 2014-01-14 02:00:26 <petertodd> lechuga__: you don't need OP_DROP for that, use OP_RETURN instead, or better yet, a pubkey
136 2014-01-14 02:31:07 <energymvr> Anyone know much about the notify message for stratum pool to send work to the connected miner?
137 2014-01-14 02:41:05 <lechuga__> petertodd: im following https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state fairly strictly
138 2014-01-14 04:23:17 <RommelVR> hey all, anyone here able to just clarify something in regards to vout for me? :p
139 2014-01-14 04:23:58 <RommelVR> (and is this the right channel to be asking questions?)
140 2014-01-14 04:24:50 <andytoshi> RommelVR: you're probably okay -- and just ask, being told to go to #bitcoin is no big deal
141 2014-01-14 04:26:10 <RommelVR> andytoshi: its OK, just in wording my question I've figured out where I was wrong in my thinking. Should probably put that rubber duck back on my desk.
142 2014-01-14 04:26:23 <RommelVR> andytoshi: cheers ;)
143 2014-01-14 04:26:29 <andytoshi> excellent, glad we could help :)
144 2014-01-14 07:28:46 <michagogo> cloud|6:26:08 <RommelVR> ... Should probably put that rubber duck back on my desk.
145 2014-01-14 07:28:57 <michagogo> cloud|What rubber duck?
146 2014-01-14 08:49:19 <jouke_> the -timeout setting, is that client side only? Or do I need to set it on the server as well? Because 'listtransactions "*" 999999' seems to time out.
147 2014-01-14 08:51:11 <twizt> anyone know if these are good
148 2014-01-14 08:51:12 <twizt> http://www.redbooks.ibm.com/abstracts/tips0850.html
149 2014-01-14 09:26:14 <wumpus> Jouke: timeout is for the P2P protocol, it does not affect RPC connections
150 2014-01-14 09:26:42 <Jouke> Ah ok.
151 2014-01-14 09:27:36 <wumpus> hmm looking at the master source it doesn't seem to be used *at all*... that's funny
152 2014-01-14 09:28:04 <wumpus> oh.. it is, just as a default argument, never mind
153 2014-01-14 09:29:55 <wumpus> in any case RPC connections should never time out
154 2014-01-14 09:31:03 <wumpus> if it does seem to time out during some commands that's a bug
155 2014-01-14 09:31:09 <Jouke> I get a "error: no response from server"
156 2014-01-14 09:31:38 <stonecoldpat> it takes a few minutes sometiems before an RPC will work
157 2014-01-14 09:31:42 <stonecoldpat> also make sure Bitcoind is running
158 2014-01-14 09:31:55 <stonecoldpat> if your making modifications - your code might break as you call your changes - and get a nerror like that
159 2014-01-14 09:32:17 <Jouke> bitcoind is running, I did not make changes.
160 2014-01-14 09:32:33 <Jouke> ./bitcoind listtransactions "*" 999999 > listtransactionserror: no response from server
161 2014-01-14 09:32:54 <Jouke> Too many transactions to list?
162 2014-01-14 09:32:59 <stonecoldpat> you may not be connected to any peers...?
163 2014-01-14 09:33:03 <stonecoldpat> could be .. try a smaller limit
164 2014-01-14 09:33:58 <stonecoldpat> check ur connected with people first, i think thats probably the issue, (its a remote command procedure, so even if its a local command, it still needs to be connected) as far as im aware
165 2014-01-14 09:34:01 <wumpus> does the server process die? could be it runs out of memory, or other resources
166 2014-01-14 09:34:09 <Jouke> wumpus: no it does not
167 2014-01-14 09:34:35 <Jouke> A smaller limmit does return transactiens
168 2014-01-14 09:35:05 <stonecoldpat> client probably runs out of memory trying to retrieve that many transactions? or it doesnt have that many (and so breaks down?)
169 2014-01-14 09:37:33 <Jouke> no and no
170 2014-01-14 09:57:12 <TD> good morning
171 2014-01-14 09:58:35 <stonecoldpat> morning x
172 2014-01-14 10:29:19 <petertodd> lechuga__: that page is out of date with respect to best practices - OP_DROP has very little support and may never be implemented as a standard transaction type, but you can get the exact same effect by encoding your contract hash or similar in either a OP_RETURN txout, or a fake pubkey in a CHECKMULTISIG txout. (better yet, a real pubkey with BIP32-style derivation of the contract hash based on the oracle's root pubkey)
173 2014-01-14 11:36:05 <Happzz> https://blockchain.info/pools?timespan=24hrs
174 2014-01-14 11:36:08 <Happzz> time to worry?
175 2014-01-14 11:38:52 <keyboard> p2pool disappeared?
176 2014-01-14 11:40:07 <matjeh> all the smaller pools i've mined at dissapeared
177 2014-01-14 11:40:15 <matjeh> the last one was HHTT
178 2014-01-14 11:40:51 <matjeh> the owner said it paid out more BTC than it mined (how does that happen?)
179 2014-01-14 11:45:45 <kinlo> Happzz / matjeh: that's a discussion for #bitcoin, not here plz
180 2014-01-14 11:48:50 <Happzz> kinlo i don't see why.
181 2014-01-14 11:50:16 <SomeoneWeird> matjeh, pps
182 2014-01-14 11:52:34 <kinlo> sigh...
183 2014-01-14 11:53:15 <matjeh> SomeoneWeird: i mean, someone who is obviously not a mathematician comes up with a scheme like PPS :p
184 2014-01-14 15:01:51 <helo> if a node sees a block at the same height as one it has already accepted, but the new block has a lower hash (more work), will it orphan the first block to get a chain with higher total work?
185 2014-01-14 15:02:46 <sipa> the amount of total work is not determined by the hash
186 2014-01-14 15:03:17 <sipa> it's determined by how difficult it was to create the block
187 2014-01-14 15:03:44 <sipa> (the formula is: work(block) = 2^256 / (block.target + 1))
188 2014-01-14 15:04:49 <helo> oh. i thought it used block.hash instead of block.target in your eqn
189 2014-01-14 15:05:00 <sipa> that would lead to huge variance
190 2014-01-14 15:05:27 <sipa> how hard it is to create a block is set in advance, by the target
191 2014-01-14 15:05:45 <helo> sure, that makes sense
192 2014-01-14 15:05:46 <sipa> there are a well-known number of valid hashes and a number of invalid hashes
193 2014-01-14 15:06:04 <sipa> however, if you create a new block which has a total amount of work that is higher, we will reorganize
194 2014-01-14 15:06:17 <sipa> (which requires a retarget to happen in between)
195 2014-01-14 15:06:19 <helo> hearing over and over "it's highest total work, not chain height" made me start thinking it was based on individual hashes
196 2014-01-14 15:06:43 <sipa> right, i guess that's a reasonable guess
197 2014-01-14 15:07:08 <sipa> but it's still true; the only way it makes a difference is if there is a retarget in the part of the chain being reorganized
198 2014-01-14 15:08:20 <helo> right. thanks
199 2014-01-14 16:14:45 <EasyAt> Is there a hard limit on the size of a transaction that the reference client will no longer forward?
200 2014-01-14 16:14:59 <jgarzik> various limits under various conditions
201 2014-01-14 16:15:06 <jgarzik> 5000 bytes is one barrier
202 2014-01-14 16:15:16 <EasyAt> So, I could theoretically take up an entire block
203 2014-01-14 16:15:24 <jgarzik> sure
204 2014-01-14 16:15:35 <brisque> more than 100k isn't standard though, right?
205 2014-01-14 16:16:32 <jgarzik> I think even 100k will relay, given proper fees?
206 2014-01-14 16:16:44 <jgarzik> 100k _orphan_ will not get relayed
207 2014-01-14 16:17:12 <brisque> MAX_STANDARD_TX_SIZE = 100000;
208 2014-01-14 16:17:16 <gmaxwell> main.h:static const unsigned int MAX_STANDARD_TX_SIZE = 100000;
209 2014-01-14 16:18:08 <gmaxwell> IIRC there is a stupid dos attack that we're avoiding with that.
210 2014-01-14 16:18:35 <brisque> "Limiting transactions to MAX_STANDARD_TX_SIZE mitigates CPU exhaustion attacks."
211 2014-01-14 16:18:37 <gmaxwell> (basically when a transaction is validate all its inputs are pulled into memory. So we can use memory related to the maximum size squared)
212 2014-01-14 16:19:02 <gmaxwell> hm or maybe I misremember
213 2014-01-14 16:19:22 <brisque> https://github.com/bitcoin/bitcoin/blob/266921e70ffcfa8d9c930284aaf02fd2d9b69109/src/main.cpp#L373
214 2014-01-14 16:19:41 <gmaxwell> in any case, there is a nearly 1 million byte transaction transaction in the testnet chain.
215 2014-01-14 16:20:33 <brisque> I'm sure at some point we will have a miner that decides to fill 1MB blocks just because they can.
216 2014-01-14 16:21:13 <brisque> off testnet, I mean.
217 2014-01-14 16:21:40 <phillipsjk> Saw this waring in the 0.8.6 Release notes: "There have been frequent reports of users running out of virtual memory on 32-bit systems" -- does this imply I need more than 4GB of RAM+swap for a full node?
218 2014-01-14 16:21:55 <TD> no
219 2014-01-14 16:21:56 <brisque> for syncing it initially
220 2014-01-14 16:22:02 <TD> a lot of the address space is used for leveldb mmapped files, or used to be
221 2014-01-14 16:22:21 <brisque> a running node uses < 200MB if you -disablewallet in the configuration.
222 2014-01-14 16:22:24 <wumpus> phillipsjk: not really, certainly not if you use the blockchain torrent
223 2014-01-14 16:22:38 <phillipsjk> TD: the mmapp thing was only replaced in OSx.
224 2014-01-14 16:23:06 <phillipsjk> wumpus: I was planning to use the .torrent, actually.
225 2014-01-14 16:23:12 <wumpus> initial sync takes a lot of memory due to orphans storage, and indeed virtual memory due to mmaps (but those are different things, the virtual memory problem doesn't exist on 64 bit whereas the orphans problem does)
226 2014-01-14 16:23:59 <wumpus> there's a pull you can help test that reduces orphans storage, let's see, https://github.com/bitcoin/bitcoin/pull/3514
227 2014-01-14 16:24:01 <phillipsjk> so the problem is that the virtual memory has sparse storage?
228 2014-01-14 16:24:50 <phillipsjk> I suppose upwards of 1GB is just not useable on 32bit systems.
229 2014-01-14 16:24:53 <wumpus> phillipsjk: 32-bit systems only have 2-3GB of virtual memory for a process, the database files are much bigger
230 2014-01-14 16:24:56 <EasyAt> Is there a rough estimate when the ops for xor, mult, cat etc... will be allowed?
231 2014-01-14 16:25:41 <wumpus> phillipsjk: hm no that's wrong, the database files aren't that big... still, leveldb likes to allocate a lot of it :)
232 2014-01-14 16:26:25 <brisque> EasyAt: can't imagine it's going to happen soon. even if it was planned it's not a one update change.
233 2014-01-14 16:26:38 <phillipsjk> I think I am running a PAE 32Bit kernel on this machine (though not using if for Bitcoind) would that help at all?
234 2014-01-14 16:27:00 <wumpus> no, that extends Physical Address space
235 2014-01-14 16:27:42 <wumpus> so you can address more RAM memory on the system as a whole. within one process, that doesn't help you
236 2014-01-14 16:28:13 <wumpus> in any case, if you use the blockchain torrent you should be ok
237 2014-01-14 16:28:27 <phillipsjk> Well, my planned Bitcoin node is running a 64bit kernel, so the concern is moot other than physical RAM.
238 2014-01-14 16:29:14 <phillipsjk> For some reason my machine sees an extra 124MB after pulling a 2MB video card :P
239 2014-01-14 16:29:54 <phillipsjk> Thanks for the help.
240 2014-01-14 16:31:12 <wumpus> it also reserves I/O mmap space and such for video cards, although 128Mb sounds like a lot indeed
241 2014-01-14 16:32:37 <wumpus> mmio*
242 2014-01-14 16:32:54 <phillipsjk> Pretty sure it was a slightly "odd" number like 124 :)
243 2014-01-14 16:33:32 <phillipsjk> Maybe 128-4MB
244 2014-01-14 16:34:42 <phillipsjk> RS-232 FTW.
245 2014-01-14 16:43:52 <EasyAt> If those/sc
246 2014-01-14 16:43:57 <EasyAt> whoops
247 2014-01-14 17:09:36 <Burrito> Is there any way of getting Bitcoin's "estimated total blocks" from the RPC API?
248 2014-01-14 17:11:54 <Burrito> Or, more directly, is there any way to judge whether it is downloading or syncing through the RPC API?
249 2014-01-14 17:12:11 <Burrito> (or indexing)
250 2014-01-14 17:26:13 <EasyAt> getblockcount
251 2014-01-14 17:26:30 <EasyAt> Run it a couple times apart and blockheight should increase while syncing
252 2014-01-14 17:28:39 <Burrito> hm, okay
253 2014-01-14 17:29:28 <EasyAt> There's probably a nicer way to do it
254 2014-01-14 17:30:02 <sipa> Burrito: the best heuristic is looking at the timestamp of the latest block
255 2014-01-14 17:30:09 <Burrito> So far I've written it so that it compares values from Blockchain.info, Blockr.io, and Block Explorer. I thought there was actually a nicer way.
256 2014-01-14 17:30:12 <Burrito> Ah
257 2014-01-14 17:30:15 <sipa> internally, bitcoin uses more heuristics than that, but they're all flaky
258 2014-01-14 17:30:30 <sipa> there is no real answer to that question... it is *always* syncing
259 2014-01-14 17:30:37 <sipa> from a technical point
260 2014-01-14 17:31:09 <Burrito> Okay, thanks
261 2014-01-14 17:33:09 <EasyAt> sipa: Is there a list of reasons somehwere detailing why some opcodes are disabled
262 2014-01-14 17:34:20 <sipa> the only reason is "satoshi disabled them at some point, because they were insufficiently tested for DoS potential and other bugs"
263 2014-01-14 17:34:41 <TD> also nobody really found compelling uses for most of them
264 2014-01-14 17:34:47 <TD> so there wasn't much incentive to reactivate them
265 2014-01-14 17:34:59 <sipa> true
266 2014-01-14 17:35:09 <sipa> though since reenabling requires a hardfork...
267 2014-01-14 17:35:26 <sipa> there would need to be some compelling reason at least
268 2014-01-14 17:35:44 <EasyAt> I thought it be fun to have bounty transactions. Where someone satisfies some problem to optain the outputs... I can't think of any good applications, though
269 2014-01-14 17:38:07 <brisque> there's one in the blockchain that if you can make a SHA1 collision you win a few BTC
270 2014-01-14 17:38:42 <EasyAt> brisque: exactly
271 2014-01-14 17:38:48 <EasyAt> Something a bit more useful would be nice, heh
272 2014-01-14 17:38:50 <brisque> sha1(a) == sha1(b) && a != b
273 2014-01-14 17:38:57 <maaku> EasyAt: really? if script was a bit more expressive there's tons of applications
274 2014-01-14 17:38:58 <sipa> yeah that's about the only useful thing you can do now
275 2014-01-14 17:39:08 <EasyAt> maaku: I mean with the currenct script
276 2014-01-14 17:39:16 <EasyAt> scirpt ops*
277 2014-01-14 17:41:34 <EasyAt> I finally really dug into the scripting side last night and just can't stop thinking about the applications
278 2014-01-14 17:43:06 <maaku> ACTION spent last night playing with replacing script with Joy
279 2014-01-14 17:43:48 <EasyAt> maaku: script with joy?
280 2014-01-14 17:44:04 <maaku> EasyAt: http://en.wikipedia.org/wiki/Joy_%28programming_language%29
281 2014-01-14 17:44:24 <maaku> it's a more theoretically grounded descendent of Forth
282 2014-01-14 17:54:43 <EasyAt> maaku: Interesting
283 2014-01-14 17:55:40 <sipa> dang, i made bitcoind do a full sync on #3514 on valgrind
284 2014-01-14 17:55:50 <sipa> ... laptop shut down because of overheating
285 2014-01-14 17:56:12 <maaku> yeah it's turing-complete, so what you'd have to do is prefix the scriptSig with the # of executed instructions for fee purposes, which is checked as part of validation
286 2014-01-14 17:56:24 <maaku> you'd probably want to Merklize it too
287 2014-01-14 17:56:31 <maaku> (this is more of a -wizards discussion)
288 2014-01-14 17:58:37 <EasyAt> maaku: If we had a turing complete scripting language wouldn't I be able to create a bunch of bogus TXs and have it eat a bunch of CPU before the receiving nodes throw the TX out?
289 2014-01-14 17:59:13 <maaku> EasyAt: computation stops once you exceed the specified instruction count
290 2014-01-14 18:00:00 <maaku> transactions without sufficient fee are ignored or brown listed
291 2014-01-14 18:00:34 <maaku> and if a txn with invalid instruction count is found, its inputs could be brown listed
292 2014-01-14 18:01:24 <EasyAt> maaku: They'd have to execute all those operations before they realized it was bogus, no?
293 2014-01-14 18:01:24 <sipa> maaku: you'd need a (reachable) per-block instruction count limit too
294 2014-01-14 18:01:41 <sipa> as otherwise miners have no reason to enforce that fee per operation
295 2014-01-14 18:03:22 <maaku> sipa: yes, definately
296 2014-01-14 18:03:52 <maaku> also for DoS reasons (like the sigop limit)
297 2014-01-14 18:13:05 <btcNeverSleeps> Hey everyone... I'm a software dev but haven't done any programming yet related to bitcoin. I've got a question regarding "user logging" on a site on which the user would have a bitcoin balance. Instead of implementing two-factor auth and using the usual password + google 2FA etc., would it make sense to ask the user to send 1 satoshi from its wallet so that he would login?
298 2014-01-14 18:14:28 <Luke-Jr> btcNeverSleeps: no
299 2014-01-14 18:14:31 <dmanderson> Not if it has to wait to make it into the block
300 2014-01-14 18:14:41 <btcNeverSleeps> Luke-Jr: can you develop a bit?
301 2014-01-14 18:14:41 <Luke-Jr> btcNeverSleeps: Bitcoin is a currency, not an authentication system
302 2014-01-14 18:14:42 <dmanderson> your user could be waiting a LONG time for 1 Satoshi to who up
303 2014-01-14 18:14:55 <Luke-Jr> btcNeverSleeps: you can use signed messages though
304 2014-01-14 18:15:10 <btcNeverSleeps> Luke-Jr: bitcoin ain't a decentralized trusted timestamp system, it's a currency... Yet people use it for decentralized timestamps right?
305 2014-01-14 18:15:22 <btcNeverSleeps> dmanderson: one block at most... No need for confirmation.
306 2014-01-14 18:15:33 <maaku> btcNeverSleeps: look up signed messages
307 2014-01-14 18:15:43 <btcNeverSleeps> maaku: ok, going to read on that
308 2014-01-14 18:15:46 <Luke-Jr> btcNeverSleeps: in theory, one could develop a timestamping system with bitcoin technology, but it hasn't really been done yet
309 2014-01-14 18:15:47 <dmanderson> the user could still be waiting a long time for 1 Satoshi to make it into the block
310 2014-01-14 18:16:00 <Luke-Jr> btcNeverSleeps: and timestamping isn't authentication
311 2014-01-14 18:16:19 <Luke-Jr> btcNeverSleeps: Bitcoin-OTC and Eligius use signed messages as a kind of authentication successfully
312 2014-01-14 18:16:28 <btcNeverSleeps> Luke-Jr: I know, I know... My point was that it's more than just a currency or a medium of exchange.
313 2014-01-14 18:16:35 <btcNeverSleeps> Luke-Jr: oh, that is very interesting
314 2014-01-14 18:16:56 <Luke-Jr> basically a signed message proves the person who receives funds sent to a given address agrees to some contract
315 2014-01-14 18:17:19 <Luke-Jr> btcNeverSleeps: Bitcoin itself *is* just a currency, even if the technology could be expanded outside of that.
316 2014-01-14 18:17:31 <Luke-Jr> btcNeverSleeps: such expansion wouldn't use the bitcoin blockchain, for example
317 2014-01-14 18:18:31 <phillipsjk> btcNeverSleeps, You can get your users to decrypt a challenge string with one of thier private keys, but you might as well just use OpenPGP for that.
318 2014-01-14 18:18:52 <dmanderson> Andreas Antonopoulos would challenge the 'just a currency' statement ;-)
319 2014-01-14 18:19:17 <btcNeverSleeps> Another very related question then: say I were to write an exchange (I'm definitely not, it's theoretical), would you recommend I implement the traditional "username+password+optional TFA" as most sites do or that I'd try to use signed messages as a kind of authentication system?
320 2014-01-14 18:20:33 <phillipsjk> the #bitcoin-otc bot uses the challenge string method.
321 2014-01-14 18:21:13 <phillipsjk> The info is also used to build a "web of trust"
322 2014-01-14 18:21:51 <btcNeverSleeps> Luke-Jr: reading your msg here: http://sourceforge.net/mailarchive/message.php?msg_id=31590964 (I take it it's yours ; )
323 2014-01-14 18:22:10 <phillipsjk> I think you average user would be bewildered by such a requirement though.
324 2014-01-14 18:27:44 <Luke-Jr> phillipsjk: ECDSA/Bitcoin don't support encryption :P
325 2014-01-14 18:28:31 <phillipsjk> I did not want to say have your user sign a challenge message :P
326 2014-01-14 18:29:46 <Luke-Jr> phillipsjk: why not?
327 2014-01-14 18:30:48 <phillipsjk> Usually blindly signing random messages is a bad idea.
328 2014-01-14 18:31:35 <Luke-Jr> phillipsjk: of course it is, that's why you don't make it random
329 2014-01-14 18:32:14 <shesek> isn't it what gribble does?
330 2014-01-14 18:32:23 <Luke-Jr> "2014-01-14: This message validates the authentication of login to the 'foobar' account from IP 2002:2042:2320::2."
331 2014-01-14 18:32:34 <phillipsjk> Just make it "log me in to site.com on this date:time"?
332 2014-01-14 18:32:36 <Luke-Jr> shesek: I didn't say gribble was a *good* implementation :/
333 2014-01-14 18:32:42 <Luke-Jr> right, site name is good too
334 2014-01-14 18:32:48 <shesek> Luke-Jr, I'd probably add the site name there too
335 2014-01-14 18:32:55 <shesek> oh, yes, what phillipsjk just said
336 2014-01-14 18:33:23 <jcorgan> the site could send a random challenge string, the user XORs that with his own randomly chosen string, then sends a signed version of the result and his string. The site can verify the signature, but has no incentive to send malicious hashes as the actual signature would be on random data
337 2014-01-14 18:34:01 <Luke-Jr> jcorgan: ⦠no
338 2014-01-14 18:34:39 <shesek> though, coming to think about, if users were to use separate signing addresses for each service, using random challenge strings wouldn't really be a problem
339 2014-01-14 18:34:40 <jcorgan> please correct me. i'm still working through my first cup of coffee this morning.
340 2014-01-14 18:35:52 <Luke-Jr> signing random data = bad :p
341 2014-01-14 18:36:14 <gmaxwell> I nagged nanotube to change gribble's behavior but doing so would break varrious people's autologin things.
342 2014-01-14 18:36:43 <jcorgan> it would be instructive for me to understand where the above protocol goes wrong
343 2014-01-14 18:36:56 <jcorgan> and perhaps embarrasing as well
344 2014-01-14 18:36:56 <Luke-Jr> jcorgan: it teaches a bad lesson
345 2014-01-14 18:37:29 <phillipsjk> jcorgan, one problem is that the user has to do something special before signing
346 2014-01-14 18:38:04 <shesek> jcorgan, if everyone were to use that xor-with-random-data thing, it doesn't really do any good
347 2014-01-14 18:38:10 <Luke-Jr> gmaxwell: nanotube: ;;bcauth2
348 2014-01-14 18:38:40 <shesek> user tried to login to service A, service A goes to service B where that user also has an account and gets the challenge string, the user sends his sig/random data to service A, then service A uses that to login to service B
349 2014-01-14 18:38:47 <shesek> * tries
350 2014-01-14 18:39:21 <shesek> if both A and B uses what you're suggesting, it wouldn't really help
351 2014-01-14 18:39:39 <gmaxwell> shesek: Yea, I demonstrated this attack in bitcoin-otc a while back with some crappy service that had copied gribble's auth.
352 2014-01-14 18:39:46 <jcorgan> got it, thanks.
353 2014-01-14 18:40:13 <Luke-Jr> gmaxwell: I tried to, but the target noticed I wasn't the real gribble XD
354 2014-01-14 18:40:42 <gmaxwell> (gpg auth) they gave the user an encrypted message with a not-obviously site specific challenge string in it and asked the user to decrypt. So I just went to authenticate as a user and then said "Hey, I'm testing something, can you decrypt this for me?"
355 2014-01-14 18:40:46 <gmaxwell> and they did.
356 2014-01-14 18:41:25 <shesek> gmaxwell, I'm not sure how it'll break auto-login scripts, mitigating this should be as simple as changing the challenge string to "I want to login to gribble, token: <random>"
357 2014-01-14 18:41:52 <shesek> scripts would handle it in pretty much the same way (though it will be wise to verify the message starts with that prefix)
358 2014-01-14 18:41:56 <Luke-Jr> shesek: needs the nickname too
359 2014-01-14 18:42:06 <phillipsjk> The whole point of this discussion is that random==bad, no?
360 2014-01-14 18:42:19 <Luke-Jr> phillipsjk: it's that random = social engineering permitted
361 2014-01-14 18:42:28 <shesek> phillipsjk, I think that using only random is bad
362 2014-01-14 18:42:46 <phillipsjk> ACTION sees distinction
363 2014-01-14 18:42:50 <shesek> in addition to a readable message that says what its doing, I think its fine
364 2014-01-14 18:42:51 <gmaxwell> there needs to be either a random part or a counter, in order to prevent replay.
365 2014-01-14 18:43:02 <Luke-Jr> also, signed messages shoudl ALWAYS have a date on the front IMO
366 2014-01-14 18:43:29 <Luke-Jr> maybe an hour for some uses
367 2014-01-14 18:43:35 <phillipsjk> That is why my example had date:time: a well understood counter :)
368 2014-01-14 18:44:01 <shesek> ideally, I think the best solution it to just use signing for the actual actions the user is doing, and not for authentication
369 2014-01-14 18:44:34 <Luke-Jr> ideally browsers would have PGP support builtin etc
370 2014-01-14 18:44:38 <shesek> like, sign something like "2014-01-14: I, shesek, want to rate gmaxwell with +1: fast trade"
371 2014-01-14 18:45:10 <shesek> that also prevents gribble's operator (or someone who hacks gribble) from adding false ratings
372 2014-01-14 18:45:19 <Luke-Jr> ACTION scams shesek and then replays the positive rating later that night :P
373 2014-01-14 18:45:29 <shesek> the current way it works relies on gribble's operator to be honest
374 2014-01-14 18:45:32 <Luke-Jr> shesek: only if the reader verifies it
375 2014-01-14 18:45:51 <Luke-Jr> and very few people even verify their bitcoin client!
376 2014-01-14 18:45:59 <shesek> Luke-Jr, re your /me - yeah, a random token is probably also needed there to prevent replay
377 2014-01-14 18:46:19 <Luke-Jr> shesek: random token requires a challenge
378 2014-01-14 18:47:19 <shesek> well, yes - I would tell gribble I want to rate someone, he would reply with a challenge that I need to include in the message format ([timestamp]:[challenge] I, [me], wants to rate [someone] with [rating]: [text])
379 2014-01-14 18:47:34 <Luke-Jr> too much effort, I will stop rating :P
380 2014-01-14 18:48:16 <shesek> yeah, something like this does require some client to handle that process automatically, it is probably too much hassle
381 2014-01-14 18:48:24 <shesek> that's why I said "ideally"
382 2014-01-14 18:49:24 <shesek> I'm planning to implement rating like that on Bitrated, where most users would do the signing client-side with javascript
383 2014-01-14 18:49:46 <shesek> but I think that users who won't trust bitrated to properly handle private keys are going to suffer from this process :-\
384 2014-01-14 18:50:55 <shesek> (its optional - either provide a private key [that's handled client side and never sent to the server] and have things done automatically, or provide a public key and do that locally)
385 2014-01-14 18:52:52 <shesek> I wonder if its worth the effort, though. I think its much better to have everything digitally signed (the service operator can't fake ratings on behalf of users), but I somewhat doubt anyone would care about this :-\
386 2014-01-14 19:24:33 <zone117x> when getblocktemplate is called, it contains an array of transactions. is it possible to call getblocktemplate again later and receive the SAME prevhash (so same block) yet updated array of transactions?
387 2014-01-14 19:24:53 <zone117x> in other words, can the transactions array grow over time for a given block template?
388 2014-01-14 19:24:56 <michagogo> cloud|zone117x: certainly.
389 2014-01-14 19:28:17 <Luke-Jr> regularly..
390 2014-01-14 19:29:21 <zone117x> hmmm so lets say I mine a block with a merkle root made from a transactions array that is missing the last 2 minutes of transactions. does the network accept it? what happens to the transactions from the last 2 minutes that I ignored?
391 2014-01-14 19:30:15 <jaakkos> zone117x: those transactions just hang around in the mempool waiting to get to next block
392 2014-01-14 19:30:27 <jaakkos> zone117x: and sure, the network will accept it
393 2014-01-14 19:30:30 <gmaxwell> zone117x: of course it does, the blocks are what defines what the network knows about. If the network was already consistent we wouldn't need blocks.
394 2014-01-14 19:30:54 <Luke-Jr> zone117x: miners are not in any sense required to accept transactions
395 2014-01-14 19:31:28 <Luke-Jr> zone117x: you should, since it gives value to bitcoin (makes the system work) and you get transaction fees
396 2014-01-14 19:31:49 <Luke-Jr> but in that sense, you should also not accept transactions that harm the network (eg, DDoS/flood attacks) if you can identify them
397 2014-01-14 19:31:59 <zone117x> okay thank you for the info. so just to clarify... if I do getblocktemplate as soon as one is available, and there are only a handful of transactions.. then I find the block 9 minutes later. all of the transactions I ignored for those 9 minutes will simply be put into the next block template?
398 2014-01-14 19:32:32 <Luke-Jr> they might or might not
399 2014-01-14 19:32:38 <Luke-Jr> depends on your client's policy
400 2014-01-14 19:32:43 <Luke-Jr> which you really SHOULD configure
401 2014-01-14 19:32:51 <Luke-Jr> (future versions will require some level of miner configuration)
402 2014-01-14 19:34:06 <zone117x> okay I see. say I decided to not accept any transactions and I mine 90% of the new blocks. the remaining 10% of blocks mined by other miners would probably be putting all the transactions into the blockchain?
403 2014-01-14 19:36:02 <michagogo> cloud|zone117x: just about, yes
404 2014-01-14 19:36:14 <michagogo> cloud|(though if you're mining 90% of all blocks, Bitcoin is in trouble...)
405 2014-01-14 19:37:51 <Luke-Jr> zone117x: just having 90% of the blocks makes you a threat to bitcoin and will probably kill its value
406 2014-01-14 19:37:53 <Luke-Jr> fyi
407 2014-01-14 19:38:08 <lechuga__> speaking of which
408 2014-01-14 19:38:15 <lechuga__> luke-jr: have u peeped that merge req?
409 2014-01-14 19:38:27 <Luke-Jr> lechuga__: yeah, left a few comments skimming over it
410 2014-01-14 19:38:31 <lechuga__> oh great
411 2014-01-14 19:38:57 <lechuga__> i was distracted by a personal project but ill get back to that and incorp feedback
412 2014-01-14 19:39:03 <Luke-Jr> k
413 2014-01-14 19:39:04 <Luke-Jr> no rush
414 2014-01-14 19:39:11 <lechuga__> k
415 2014-01-14 19:39:41 <lechuga__> i got my oracle experiment to work
416 2014-01-14 19:39:45 <lechuga__> all in javascript
417 2014-01-14 19:40:25 <lechuga__> but now i have to figure out the next evolution of that idea
418 2014-01-14 19:40:46 <lechuga__> re: the zero knowledge contingent payment stuff
419 2014-01-14 19:41:19 <lechuga__> need to do a lot more reading before i beg gmaxwell to break it down for me
420 2014-01-14 19:41:41 <lechuga__> but that seems extremely interesting
421 2014-01-14 19:47:30 <lechuga__> anyone know why multisig doesnt support pay to pubkeyhash?
422 2014-01-14 19:49:52 <sipa> you can certainly construct an output script that that requires M-out-of-N signatures, for N given pubkey hashes
423 2014-01-14 19:49:58 <sipa> but why would you want to do that?
424 2014-01-14 19:50:10 <Luke-Jr> lechuga__: that doesn't make sense
425 2014-01-14 19:50:24 <Luke-Jr> pay-to-pubkeyhash is a specific output form which is not multisig