1 2014-03-18 00:00:08 <justanotheruser> Or at least part of the f59kuE is the checksum
2 2014-03-18 00:00:24 <kadoban> dnathe4th: it's how base58 encoding works, unless i'm ridiculously confused
3 2014-03-18 00:03:13 <dnathe4th> kadoban: how can you just arbitrarily truncate characters off the right end and expect the base58 decoding to result in the same bytes (albeit also truncated), unless I am confused
4 2014-03-18 00:04:26 <gmaxwell> petertodd: http://0bin.net/paste/avMPb2XvTDNid2zr#vK6LPkvNauP7RGCrCmsd6Ek04W4hpNn3R16kxjuoRbE= okay, so 25 lines, untested (not even complied) and without the safe deployment code.
5 2014-03-18 00:04:50 <Luke-Jr> what is this in EvalScript for? CAutoBN_CTX pctx;
6 2014-03-18 00:05:26 <gmaxwell> Luke-Jr: I assume its the memory for a bignum. (the bignum implementation needs a context, I presume. I don't recall that)
7 2014-03-18 00:06:09 <sipa> Luke-Jr: openssl provides some optimized memory allocation
8 2014-03-18 00:06:22 <Luke-Jr> but pctx is unused..
9 2014-03-18 00:06:30 <sipa> wut?
10 2014-03-18 00:06:51 <kadoban> dnathe4th: there's probably some funniness about the last character, that'd be the only issue
11 2014-03-18 00:06:51 <Luke-Jr> commenting it out seems to compile at least
12 2014-03-18 00:07:02 <Luke-Jr> and I see no references to pctx
13 2014-03-18 00:07:21 <sipa> Luke-Jr: my guess is that only OP_MUL, OP_DIV and OP_MOD used it
14 2014-03-18 00:07:32 <sipa> which have been deleted
15 2014-03-18 00:07:36 <sipa> so let's get rid of it
16 2014-03-18 00:08:02 <sipa> now if only we
17 2014-03-18 00:08:20 <sipa> 'd replace the b58 implementation to not use bignum, we could remove that class entirely
18 2014-03-18 00:08:41 <gmaxwell> Luke-Jr: don't use have a b58 implementation that isn't goofy?
19 2014-03-18 00:08:59 <midnightmagic> in his libblkmaker, yeah
20 2014-03-18 00:09:21 <sipa> there was a really simple neat one that avoid all temporary bignums entirely
21 2014-03-18 00:09:41 <gmaxwell> yea, no need to use bignums for this.
22 2014-03-18 00:15:25 <petertodd> gmaxwell: one issue there is you have to figure out how you'll deal with nLockTime as time vs. nLockTime as block height
23 2014-03-18 00:16:01 <petertodd> gmaxwell: e.g. right now I could want a time-based nLockTime, and then you'd trivially satisfy it with block-height-based
24 2014-03-18 00:16:14 <gmaxwell> petertodd: ::nods:: demo code. :P
25 2014-03-18 00:17:07 <gmaxwell> the obvious thing to do is to just use the LOCKTIME_THRESHOLD to classify both numbers.
26 2014-03-18 00:17:16 <petertodd> gmaxwell: yup
27 2014-03-18 00:17:16 <sipa> gmaxwell: you use the name nlocktime, but you don't really use it as a lock time - more like a maturity time, right?
28 2014-03-18 00:17:22 <sipa> just with the same semantics as nLocktime
29 2014-03-18 00:17:34 <petertodd> gmaxwell: also, I wonder if CastToBigNum().getuint() exists/is used anywhere else?
30 2014-03-18 00:18:02 <gmaxwell> sipa: Yes, you could look at it that way. It's implemented as a constraint on the consuming tx's nlocktime.
31 2014-03-18 00:18:11 <sipa> gmaxwell: ok, that was my confusion
32 2014-03-18 00:18:17 <petertodd> gmaxwell: ...and looks like the answere to that is it exists, not used anywhere else
33 2014-03-18 00:18:32 <sipa> gmaxwell: then we were probably talking about the same thing (i haven't looked at your proposal in dtail)
34 2014-03-18 00:18:38 <lorenzoasr> hi, do you know a library in php that help me to create non-standard transaction with custom scriptpubkey ?
35 2014-03-18 00:19:08 <gmaxwell> sipa: well now I posted code, so we can avoid an impedance mismatch. It's not totally complete as petertodd notes wrt block vs time nlocktime.
36 2014-03-18 00:21:17 <petertodd> gmaxwell: oh, and re: deployement, perfect example of another type of SCRIPT_VERIFY flag, like my checkmultisig mutability pull-req suggested
37 2014-03-18 00:21:19 <rasmuzen> sipa: hey, I've been thinking about the rewind data you'd need to handle a fork
38 2014-03-18 00:21:44 <gmaxwell> petertodd: yea, thought of that too. just wrap that entire opcode with that flag check. :)
39 2014-03-18 00:22:25 <petertodd> gmaxwell: yup
40 2014-03-18 00:25:07 <sipa> rasmuzen: ok?
41 2014-03-18 00:25:22 <rasmuzen> sipa: I have a few questions :D
42 2014-03-18 00:25:28 <sipa> shoot
43 2014-03-18 00:25:53 <heipa> ok now I read more and see that I realise it now so good
44 2014-03-18 00:25:56 <rasmuzen> sipa: so basically you'll be requesting blocks and doing the hash calculations to make sure everything lines up
45 2014-03-18 00:26:17 <heipa> petertodd: is it ok to ask here about extra btc anon possibilities code wise?
46 2014-03-18 00:26:27 <rasmuzen> sipa: then at some point it won't add up and that's because a block in your local chain isn't actual in the longest chain?
47 2014-03-18 00:26:28 <petertodd> heipa: sure
48 2014-03-18 00:26:45 <rasmuzen> sipa: and that's how you'd detect a fork? assuming the chain you're requesting is longer than the chain you have locally?
49 2014-03-18 00:27:21 <sipa> rasmuzen: you have to understand the distinction between the block tree and the block chain
50 2014-03-18 00:27:34 <sipa> rasmuzen: internally, from all blocks downloaded, internally a block tree is built
51 2014-03-18 00:27:44 <heipa> petertodd: well I read a bit paper by I think zerocoin claiming their solution can add level of anonimity to btc, I wonder who tried it?
52 2014-03-18 00:27:44 <sipa> rasmuzen: by knowing the parent of each block
53 2014-03-18 00:27:56 <heipa> or at least maybe there was some forum topic about it?
54 2014-03-18 00:28:24 <petertodd> heipa: they released code for their old version, which was really slow, and haven't (AFAIK) released code for their new version
55 2014-03-18 00:28:29 <rasmuzen> sipa: block tree == merkle tree?
56 2014-03-18 00:28:41 <sipa> rasmuzen: no
57 2014-03-18 00:28:58 <heipa> petertodd: from your understanding of their paper is this something worth studying?
58 2014-03-18 00:29:03 <heipa> or not? :)
59 2014-03-18 00:29:27 <petertodd> heipa: I talked to Ian at the fincrypto conf the other week a lot about zerocoin - it's legit research and a very good idea
60 2014-03-18 00:29:30 <sipa> rasmuzen: the merkle tree is for organizing transactions within a block
61 2014-03-18 00:29:39 <rasmuzen> sipa: i see, i was imagining a linked list of blocks, where you can tell block B is block A's next based on some hashes, is this wrong?
62 2014-03-18 00:29:49 <petertodd> heipa: also, it's easy to implement on top of bitcoin as something akin to a colored coin
63 2014-03-18 00:29:52 <sipa> rasmuzen: you're missing some very basic stuff
64 2014-03-18 00:30:02 <sipa> rasmuzen: look up the data structure of blocks first place
65 2014-03-18 00:30:11 <heipa> petertodd: Oooooo nice!
66 2014-03-18 00:30:34 <heipa> so that means implementation can be done with 0 hard fork?
67 2014-03-18 00:30:36 <petertodd> heipa: nice thing about that is you can easily build a decentralized exchange of zerocoin<->btc to convert to and from
68 2014-03-18 00:30:47 <petertodd> heipa: correct, and for that matter, without any miner support at all.
69 2014-03-18 00:31:00 <heipa> wow and no one done it yet? :)
70 2014-03-18 00:31:05 <petertodd> heipa: indeed, it's actually non-trival to *stop* someone from doing that...
71 2014-03-18 00:31:15 <petertodd> heipa: well, they haven't released code yet
72 2014-03-18 00:31:32 <heipa> petertodd: so its like ripple but open source and somehow way more anon?
73 2014-03-18 00:31:50 <petertodd> heipa: no, entirely unlike ripple. More like mastercoin actually, in terms of technical architecture
74 2014-03-18 00:31:52 <Luke-Jr> gmaxwell: define goofy
75 2014-03-18 00:32:21 <Luke-Jr> gmaxwell: also, it only parses b58, doesn't create it
76 2014-03-18 00:32:23 <heipa> petertodd: oki and what do u mean by decentralised exchange how would that work in theory?
77 2014-03-18 00:32:30 <heipa> or maybe some howto online
78 2014-03-18 00:32:35 <gmaxwell> Luke-Jr: doesn't need a multiprecision integer implementation.
79 2014-03-18 00:32:46 <gmaxwell> e.g. does the carry handling with a counter.
80 2014-03-18 00:32:53 <Luke-Jr> heipa: note zerocoin requires a trusted third party
81 2014-03-18 00:33:08 <petertodd> heipa: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03892.html
82 2014-03-18 00:33:22 <heipa> Luke-Jr: thats what i was thinking if it could be 100% decentralised that would be something
83 2014-03-18 00:33:42 <petertodd> heipa, Luke-Jr: which is one of the reasons I suggested doing it as an embedded consensus system - makes it easy to have multiple zerocoin accumulators each initialized by separate groups
84 2014-03-18 00:34:05 <Luke-Jr> https://gitorious.org/bitcoin/libblkmaker/source/eb33f9c8e441ffef457a79d76ceed1ea20ab3059:base58.c
85 2014-03-18 00:34:07 <petertodd> heipa: zerocoin requires a trusted third party at setup, but only the one time - after the setup phase it is trustless
86 2014-03-18 00:34:07 <rasmuzen> sipa: will do, thanks
87 2014-03-18 00:34:23 <gmaxwell> petertodd: the efficiency becomes garbage but you could also do the dual-snark solution to strengthen that kind of thing.
88 2014-03-18 00:34:33 <Luke-Jr> petertodd: that trust is ongoing, though
89 2014-03-18 00:34:45 <gmaxwell> (https://bitcointalk.org/index.php?topic=516531.0)
90 2014-03-18 00:34:49 <Luke-Jr> even after setup, that third party can still fabricate more coins
91 2014-03-18 00:35:28 <heipa> what if 1 color coin is token of ownership
92 2014-03-18 00:35:31 <petertodd> Luke-Jr: I mean, the trust is that they do the setup honestly and delete the secret keys, if they do that, then there is no further trust issues
93 2014-03-18 00:35:39 <heipa> but how to verify it decentralising way
94 2014-03-18 00:36:07 <petertodd> heipa: you've got a lot to learn... explanations at that level are OT here
95 2014-03-18 00:36:21 <heipa> np I have some friends to ask :)
96 2014-03-18 00:39:18 <heipa> petertodd: apart me asking friends any idea which online courses that can help to understand this more? some cryptography courses?
97 2014-03-18 00:39:20 <gmaxwell> petertodd: another possibility on the nlocktime thing is do the test as an equals test, and have the scriptsig provide the nlocktime redundantly and then the script can test it with arithmetic operations and then do the equals test. But I think that results in larger signatures for no real gain.
98 2014-03-18 00:41:25 <petertodd> gmaxwell: hmm, that's an interesting concept actually - you could make all this stuff soft-forking by having it provided in the scriptSig, then testing with a *VERIFY that the provided value was correct
99 2014-03-18 00:42:23 <gmaxwell> yes. it's an idea which basically follows from the idea the script is not execution but is just verifying a witness of execution.
100 2014-03-18 00:42:31 <petertodd> absolutely
101 2014-03-18 00:44:17 <petertodd> basically at the beginning of the script you can have a section that does something like OP_CHECKNLOCKTIMEVERIFY OP_TOALTSTACK OP_CHECKPREVBLOCKHASHVERIFY OP_TOALTSTACK (or not altstack if your script is structured in the right way)
102 2014-03-18 00:44:33 <petertodd> easy to create stuff that's not trivial to be safe in reorgs though obviously
103 2014-03-18 00:45:22 <petertodd> oh, and a fun one: OP_CHECK_IS_A_BLOCK_HASH, which only has access to blockhashes older than x blocks
104 2014-03-18 00:45:32 <petertodd> s/$/verify/
105 2014-03-18 00:46:26 <sipa> OP_RANDOM
106 2014-03-18 00:47:04 <petertodd> what's interesting there, is the fact that it's a set test, means you can satisfy any scriptPubKey by chosing the right hash to provide, and modulo really big reorgs, in the future the set of all block hashes will always contain the magic one needed to satisfy the scriptPubKey
107 2014-03-18 00:47:27 <petertodd> hence, it's actually arguably as reorg safe as any coinbase transaction!
108 2014-03-18 00:48:05 <petertodd> gmaxwell: especially fun how your CHECKLOCKTIMEVERIFY automatically has that structure and usage possibilities
109 2014-03-18 00:49:09 <petertodd> e.g. the somewhat contrived scriptPubKey: CHECKLOCKTIMEVERIFY HASH <hash> EQUALVERIFY
110 2014-03-18 00:49:48 <petertodd> "It's locked, but I can't trivially find out for how long!"
111 2014-03-18 00:51:09 <gmaxwell> without a substr you can just test all values, alas.
112 2014-03-18 00:51:12 <sipa> ACTION still favors using the name "maturity" over "locktime", as it's exactly the same semantics as implicitly present in coinbases (though relative instead of absolute)
113 2014-03-18 00:51:24 <petertodd> gmaxwell: yes, that was a very weak version of trivially :)
114 2014-03-18 00:51:52 <petertodd> sipa: note that gmaxwell's version does compare to locktime though, so we should still call it that
115 2014-03-18 00:52:02 <gmaxwell> sipa: I will attempt to convince you otherwise at dinner.
116 2014-03-18 00:52:33 <gmaxwell> (or attempt to be convinced otherwise, alternatively)
117 2014-03-18 00:52:56 <petertodd> it's a pity satoshi screwed up CODESEPARATOR - we could have added a whole slew of soft-fork *VERIFY things to check any aspect of a transaction within a scriptSig
118 2014-03-18 00:53:06 <gmaxwell> annoyingly I can see an argument for both ways, there are uscases where one or the other is helpful.
119 2014-03-18 00:58:40 <sipa> gmaxwell: maybe i should read proposals before commenting on them
120 2014-03-18 01:01:53 <petertodd> ok, so here's a soft-forked OP_ADD re-enablement: n1 n2 expected_result OP_NEW_ADD OP_SWAP OP_DROP OP_SWAP OP_DROP
121 2014-03-18 01:02:30 <petertodd> oh, actually, OP_NEW_ADD OP_NIP OP_NIP
122 2014-03-18 01:03:14 <petertodd> then add a new CHECKSIG using the same thing with a crazy SignatureHash() that drops all the expected_results...
123 2014-03-18 01:04:39 <petertodd> probably better to stick to OP_MAST_EVAL, but kinda crazy that that works
124 2014-03-18 01:05:15 <gmaxwell> I don't think it's crazy at all. It's exactly how tinyram execution is simplified via the non-determinstic inputs.
125 2014-03-18 01:05:43 <petertodd> sure, obvious parallels there -
126 2014-03-18 01:06:27 <melik> is the coinbase value always unique?
127 2014-03-18 01:06:27 <petertodd> incidentally, an interesting question re: OP_MAST_EVAL is if you'd want the stack state to be hashed and then signed - might help catch consensus issues faster
128 2014-03-18 01:06:32 <petertodd> melik: yes
129 2014-03-18 01:06:40 <melik> petertodd, what is the significance of it?
130 2014-03-18 01:06:50 <petertodd> melik: means txids are always unique
131 2014-03-18 01:07:57 <melik> petertodd, "coinbase" : "04ffff001d02fd04",
132 2014-03-18 01:08:06 <melik> you're referring to this correct ^
133 2014-03-18 01:08:27 <petertodd> melik: read this: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
134 2014-03-18 01:08:30 <petertodd> bbl
135 2014-03-18 01:08:35 <melik> thank you petertodd
136 2014-03-18 01:44:33 <jtimon> ok, gmaxwell so instead of checking the current height, op_maturity (I'll stick to that name for now, if anything, because it's faster to write) checks the nlocktime of the consuming tx
137 2014-03-18 01:45:15 <jtimon> not sure what the less-secure alternatives are though
138 2014-03-18 01:45:32 <maaku> gmaxwell sipa: please tell us which of you convinced the other ;)
139 2014-03-18 01:46:17 <jtimon> hehe, yeah
140 2014-03-18 01:48:03 <maaku> jtimon: well either way would be the same in terms of reorg-compatability as far as I can tell
141 2014-03-18 01:48:32 <maaku> so long as you fail if the tx's height/lock-time is less than some threshold
142 2014-03-18 01:49:41 <jtimon> mhmm I think you will need to set an nlock greater than the value in the script in tx1 for tx2 to be valid
143 2014-03-18 01:50:15 <jtimon> and I think the discussion will be about the name
144 2014-03-18 01:56:54 <maaku> jtimon: yes, it passes if greater than, and fails if less than
145 2014-03-18 01:57:14 <maaku> and op_maturity_verify is better imho, but that's for #bitcoin-bikeshedding
146 2014-03-18 01:57:27 <jgarzik> http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/
147 2014-03-18 01:57:29 <jgarzik> Not bad!
148 2014-03-18 01:59:27 <jtimon> maaku, actually I think gmaxwell is the one bikeshedding since we've been using op_maturity before
149 2014-03-18 01:59:55 <petertodd> jtimon: AFAIK I'm the first person to propose that op, and i called it CHECKLOCKTIMEVERIFY :P
150 2014-03-18 02:01:31 <jtimon> I though I was the one who proposed it, but if you had proposed it earlier than apporximately 2 weeks in the past, it was definitely you and I just changed the name by being unaware of your proposal
151 2014-03-18 02:02:24 <petertodd> jtimon: I proposed it last august
152 2014-03-18 02:02:34 <petertodd> #bitcoin-dev/13/08/13-08-29.log:22:53 < petertodd> gavinandresen: Oh, reminds me, I did a OP_CHECKLOCKTIMEVERIFY implementation redefining OP_NOP1. Copies locktime off the stack, compares it with the IsFinal() algorithm against the block including the spend tx, and fails the script if locktime not reached. Also uses IsMajority with nVersion=3 to enable the behavior.
153 2014-03-18 02:02:50 <jtimon> petertodd why didn't you suggested it as a replacement for expiry-ish proposals when I made them? I'm not 100% yet, but i believe any expiry use case can be replaced with this
154 2014-03-18 02:03:15 <petertodd> jtimon: because I'm not omniscient and can't read everything :P
155 2014-03-18 02:03:17 <jtimon> yes, I believe you, bitcoin's reinvention rate is ashtonishing
156 2014-03-18 02:03:52 <jtimon> we discussed expiry recently on your post about proof of publication markets
157 2014-03-18 02:03:59 <petertodd> heh, you mean its "well, either we're all smart or all idiots" rate...
158 2014-03-18 02:04:29 <petertodd> jtimon: oh, yeah, I didn't get a chance to read all of that conversation in as much detail as I should have
159 2014-03-18 02:05:15 <maaku> only certain nExpiry applications are solved by this
160 2014-03-18 02:05:37 <maaku> sometimes you want the semantics to be "invalidate the transaction if it doesn't get in by this block"
161 2014-03-18 02:05:54 <maaku> e.g. orders
162 2014-03-18 02:06:05 <jtimon> if I knew it earlier, I would have tried to avoid expiries on freimarkets options and expiry timestamps
163 2014-03-18 02:06:21 <maaku> yeah it might solve options
164 2014-03-18 02:07:12 <jtimon> well, expiry avoids bloating the chain, but functionality wise, you can build something equivalent
165 2014-03-18 02:08:00 <jtimon> you may be able to also avoid the bloat with some game theory
166 2014-03-18 02:08:09 <maaku> having to double-spend every time you expire a price is a huge deal
167 2014-03-18 02:09:07 <jtimon> you can build the order in a way that doesn't make sense for anyone to include it (unless they want to give you money for free or something)
168 2014-03-18 02:09:43 <jtimon> I'm mostly talking intuitively, but I think it can be solved
169 2014-03-18 02:10:23 <maaku> jtimon: I want to support hundreds, maybe thousands of unfilled order per every filled order
170 2014-03-18 02:10:40 <maaku> and those never have to hit the block chain
171 2014-03-18 02:10:50 <jtimon> I know
172 2014-03-18 02:12:44 <jtimon> else:
173 2014-03-18 02:12:44 <jtimon> if expiry:
174 2014-03-18 02:12:44 <jtimon> the payer gives me money for free
175 2014-03-18 02:12:44 <jtimon> what I'm saying is you could build the transaction such as
176 2014-03-18 02:12:46 <jtimon> the payer fills the order normally
177 2014-03-18 02:13:27 <jtimon> they can only make you recreate all the orders only by giving you money for free, not a huge loss
178 2014-03-18 02:14:50 <jtimon> maybe we're getting off-topic for this channel anyway...
179 2014-03-18 02:15:23 <Imbue> hello. does anyone know where I should be looking in the (bitcoind) code for information on the chainstate DB?
180 2014-03-18 02:19:18 <maaku> jtimon: no, that construction isn't reorg safe
181 2014-03-18 02:19:24 <maaku> oh i see
182 2014-03-18 02:27:36 <Imbue> got a lead, nevermind. txdb.cpp
183 2014-03-18 03:56:30 <firelegend> I was looking for the Unserialize code for this piece of code vRecv >> pfrom->nVersion >> pfrom->nServices >> nTime >> addrMe;, for the CAddress addrMe but I cannot find it. I know CDataStream's >> operator is overloaded and it calls ::Unserialize, but I can't find the appropriate template for CAddress. Would appreciate some help.
184 2014-03-18 06:06:50 <dexX7> is there a rpc i'm currently not seeing that allows to dump all unspent outputs? (not limited to tx or wallet)
185 2014-03-18 06:09:23 <gmaxwell> maaku: we can have both effectively.
186 2014-03-18 06:10:08 <gmaxwell> maaku: if we do as I suggest and also redefine nlocktime so there is a third mode where really small (e.g. <2016) non-zero values specify maturity. :) (another safe soft forking change which adjusts very little code)
187 2014-03-18 07:37:04 <dexX7> i want to send a tx with about ~220 inputs, 18 outputs and a size of ~25 kb. i'm unable to and the tx gets rejected.. what's the bottleneck here?
188 2014-03-18 07:37:32 <justanotheruser> dexX7: what's the fee?
189 2014-03-18 07:37:54 <dexX7> 0.0001 / kb up-rounded
190 2014-03-18 07:38:21 <justanotheruser> dexX7: addnode 192.3.11.20 add
191 2014-03-18 07:39:06 <justanotheruser> ;;bc,wiki free relay policy
192 2014-03-18 07:39:07 <gribble> https://en.bitcoin.it/wiki/Free_transaction_relay_policy | Nov 8, 2013 ... The original client currently refuses to relay transactions it considers " unacceptable". However, there may be miners that are willing to put these ...
193 2014-03-18 07:39:26 <dexX7> ah sorry, i was already one step ahead in my head. decoderawtransaction already fails
194 2014-03-18 07:39:46 <justanotheruser> dexX7: fails, or just isn't standard?
195 2014-03-18 07:40:00 <dexX7> TX decode failed (code -22)
196 2014-03-18 07:40:08 <dexX7> 0.9rc2
197 2014-03-18 08:07:30 <conman> someone give me a hint about "AcceptBlock() : block height mismatch in coinbase" error before I go digging around indefinitely? What is the block height format in the coinbase?
198 2014-03-18 08:08:32 <Luke-Jr> conman: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
199 2014-03-18 08:09:59 <aquarat> well that was nice of him
200 2014-03-18 08:11:40 <conman> serialized cscript
201 2014-03-18 08:12:49 <Luke-Jr> conman: in other words, signed little endian with minimal length, preceded by a 1 byte octet of the length itself
202 2014-03-18 08:13:54 <conman> ok nm
203 2014-03-18 08:15:47 <conman> though it doesn't say whether it's a signed or unsigned integer
204 2014-03-18 08:16:27 <Luke-Jr> yes, that's missing.
205 2014-03-18 08:16:37 <conman> looks signed
206 2014-03-18 08:17:03 <Luke-Jr> MIT-licensed C implementation: https://gitorious.org/bitcoin/libblkmaker/source/eb33f9c8e441ffef457a79d76ceed1ea20ab3059:blkmaker.c#L69
207 2014-03-18 08:23:14 <vegard> Luke-Jr: have you done any statistics on how often all-0 prefixes of a certain length is found by miners of your pool?
208 2014-03-18 08:23:48 <Luke-Jr> vegard: uh, you mean shares and blocks? kinda the whole goal of a pool?
209 2014-03-18 08:24:43 <vegard> oops, wrong channel. we can take it elsewhere
210 2014-03-18 08:25:59 <vegard> I mean, you'd expect shares with 1 extra 0 to show up about a certain number of percentage of all submitted shares, shares with 2 extra 0s to be rarer, etc.
211 2014-03-18 08:26:18 <Luke-Jr> yes, those are called blocks :P
212 2014-03-18 08:27:12 <vegard> any deviation from what you expect mathematically would indicate either that somebody is withholding blocks or that sha256 output is not uniform
213 2014-03-18 08:28:03 <warren> Luke-Jr: i'm glad people discover math here.
214 2014-03-18 08:28:09 <Luke-Jr> lol
215 2014-03-18 08:28:28 <edcba> sometimes they discover programming
216 2014-03-18 08:29:14 <edcba> maybe at some point we will able to teach economics but i'm not sure :
217 2014-03-18 08:29:14 <vegard> isn't output based only on number of submitted shares and not the actual "difficulty" of the shares found?
218 2014-03-18 08:29:16 <edcba> )
219 2014-03-18 08:31:08 <wumpus> it teaches mostly very hard lessons about trust
220 2014-03-18 08:32:25 <edcba> indeed lol
221 2014-03-18 08:34:10 <vegard> Luke-Jr: well, anyway, my question was just whether you see the curve that you'd expect or not.
222 2014-03-18 08:34:39 <Luke-Jr> I guess
223 2014-03-18 09:18:02 <mn3monic> hi, anyone here, that can I bother in private, have experience with bitcoin-abe? Thank you
224 2014-03-18 09:27:26 <michagogo> cloud|<reading backlog> Erm, what in the world is "P3SH"?
225 2014-03-18 09:29:12 <gmaxwell> michagogo|cloud: a somewhat joking way to refer to revising the script system in the same way p2sh does.
226 2014-03-18 09:29:32 <gmaxwell> basically just embedding a potentially entirely different script system as a data push in the old one.
227 2014-03-18 10:14:39 <anarchystar> is there a way for people to login to mtgox and independently verify that it is real, without anyone having to ask for their password?
228 2014-03-18 10:15:02 <anarchystar> i asked mark to show email + balance and pgp sign that, when logged in, but it seems he didnt
229 2014-03-18 10:15:08 <buZz> eh
230 2014-03-18 10:15:32 <anarchystar> can you for example, intercept SSL info? and that would also show that it came from mtgox and was signed by them?
231 2014-03-18 10:15:36 <anarchystar> im just thinking out loud here
232 2014-03-18 10:16:07 <anarchystar> we want to have people show their balance is what they say it is - mtgox just re-opened logins
233 2014-03-18 10:16:16 <buZz> nice
234 2014-03-18 10:16:53 <wumpus> anarchystar: a similar method is discussed here https://bitcointalk.org/index.php?topic=173220.0
235 2014-03-18 10:17:33 <anarchystar> wumpus: hmm nice thanks for the link
236 2014-03-18 10:25:00 <Rawdawg-> hey guys
237 2014-03-18 10:25:27 <Rawdawg-> anyone on that can awnser a couple quick questions?
238 2014-03-18 10:25:38 <Rawdawg-> i know its a dumb thing thats stumping me but im stuck lol
239 2014-03-18 10:25:50 <antephialtic> just ask it
240 2014-03-18 10:26:08 <Rawdawg-> ok i have my site setup on one VPS and my wallet on another one
241 2014-03-18 10:26:15 <Rawdawg-> (for security)
242 2014-03-18 10:26:28 <Rawdawg-> and i am trying to get the site to communitcate with the other wallet
243 2014-03-18 10:26:32 <Rawdawg-> but it wont seem to do it
244 2014-03-18 10:27:28 <kadoban> doesn't that provide security the same way RAID 0 provides reliability? aka it doesn't?
245 2014-03-18 10:27:29 <ne0futur> you can connect your bitcoind distantly with rpc
246 2014-03-18 10:27:29 <Rawdawg-> rpcuser and pass are correct, i put the ip in and the rpc port, the ports are open on both VPS's
247 2014-03-18 10:27:46 <Rawdawg-> lol kadoban
248 2014-03-18 10:28:04 <ne0futur> check your firewall, incoming and outgoing, on both servers
249 2014-03-18 10:28:11 <Rawdawg-> yea i did that ne0
250 2014-03-18 10:28:17 <Rawdawg-> ne0futur*
251 2014-03-18 10:28:19 <ne0futur> check debug.log and kernel logs
252 2014-03-18 10:28:28 <Rawdawg-> k, 2 secs
253 2014-03-18 10:28:33 <jouke> Rawdawg-: have you set allowip?
254 2014-03-18 10:28:37 <Rawdawg-> ahhh
255 2014-03-18 10:28:41 <Rawdawg-> thats it
256 2014-03-18 10:28:46 <Rawdawg-> i knew it was something stupid lol
257 2014-03-18 10:28:55 <antephialtic> Rawsawg-: after you get this working make sure you set up iptables to only allow rpc port access from trusted servers
258 2014-03-18 10:28:57 <Rawdawg-> forgot to add that in lol
259 2014-03-18 10:29:10 <ne0futur> +1 for a tight firewall setup
260 2014-03-18 10:29:15 <ne0futur> incoming and outgoing, on both servers
261 2014-03-18 10:29:23 <Rawdawg-> yea I have it setup to only allow from the other VPS
262 2014-03-18 10:29:29 <Rawdawg-> not even my own ip lol
263 2014-03-18 10:29:35 <antephialtic> good.
264 2014-03-18 10:32:20 <ne0futur> Rawdawg-: so what was the pb ? firewall ?
265 2014-03-18 10:32:38 <Rawdawg-> nope, it was the bitcoin.conf
266 2014-03-18 10:32:47 <Rawdawg-> i forgot to set allowip to the other vps
267 2014-03-18 10:32:56 <Rawdawg-> i knew it was gonna be something dumb like that lol
268 2014-03-18 10:33:05 <Rawdawg-> been up 31 hours now
269 2014-03-18 10:33:11 <Rawdawg-> im missing stupid shit
270 2014-03-18 10:33:12 <Rawdawg-> lol
271 2014-03-18 10:34:49 <Rawdawg-> top
272 2014-03-18 10:34:51 <Rawdawg-> oops
273 2014-03-18 10:36:03 <Rawdawg-> thank you very much guys!
274 2014-03-18 10:36:13 <Rawdawg-> i am definatly bookmarking this channel :P
275 2014-03-18 10:39:41 <ne0futur> dont forget to have a cold wallet ( securing most coins offline )
276 2014-03-18 10:42:29 <Rawdawg-> Yea I have a paper wallet I put in my safe at home for 75% of the sites funds
277 2014-03-18 10:43:03 <ne0futur> seems good ;)
278 2014-03-18 10:43:07 <Rawdawg-> I also have a VM inside of a usualy offline box (unless i need to send money) with a wallet on it too
279 2014-03-18 10:43:25 <Rawdawg-> Cant screw around with other peoples money :P
280 2014-03-18 10:44:01 <Rawdawg-> hmm, it didnt work
281 2014-03-18 10:45:06 <Rawdawg-> probably because i had the wrong IP haha
282 2014-03-18 10:45:14 <Rawdawg-> i need to go to sleep after this one lol
283 2014-03-18 10:53:18 <Rawdawg-> is it "allowip=ipaddress"?
284 2014-03-18 10:53:28 <Rawdawg-> or rpcallowip=ipaddress
285 2014-03-18 10:54:03 <Rawdawg-> nvm, found the awnser
286 2014-03-18 11:20:54 <kadoban> i've seen a few people say that 1111111111111111111114oLvT2 is the shortest possible BTC address, anyone know what's wrong with 11111111111111111111ufYVpS, if anything?
287 2014-03-18 11:24:50 <Imbue> looks good to me
288 2014-03-18 11:25:04 <Imbue> 4oLvT2 is the address that corresponds to ripemd160 = 0
289 2014-03-18 11:26:22 <Imbue> the latter seems to be able to cram more in because of the way base58encode works
290 2014-03-18 11:27:00 <kadoban> yeah...i wonder if there is actually anything wrong with it, because if not, then this thread i see linked to a lot is wrong, on how to verify btc addresses
291 2014-03-18 11:27:04 <Imbue> another example is 11111111111111111111BZbvjr
292 2014-03-18 11:27:11 <kadoban> not that it would ever come up in practice, but...
293 2014-03-18 11:27:34 <Imbue> the ripemd of 0x00 is a special case because leading 0x00 is always represented as 1 in base58
294 2014-03-18 11:47:04 <justanotheruser> Could someone explain why ECDSA-256 is only acceptable? Should I be worried at all that cisco doesn't classify it as meeting security and scalability requirements of the next 20 years? http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html
295 2014-03-18 11:47:54 <justanotheruser> -384 is NGE, so they seem to be assuming that there is a chance someone will be able to break 128 bit security
296 2014-03-18 11:51:44 <stonecoldpat> justanotheruser: http://crypto.stackexchange.com/questions/2482/how-strong-is-the-ecdsa-algorithm gives a decent explanation
297 2014-03-18 11:54:38 <justanotheruser> stonecoldpat: doesn't seem to cover my question
298 2014-03-18 11:56:48 <stonecoldpat> justanotheruser: i realized that when i re-read your question sorry haha, well i guess the lowest acceptable bit-security to have nowadays, so it probably will be broken within the next 10 years
299 2014-03-18 11:57:16 <justanotheruser> stonecoldpat: a bit scary. That means satoshis funds will be stolen
300 2014-03-18 11:58:27 <justanotheruser> I would guess it's unlikely, but slightly possible
301 2014-03-18 11:59:28 <Imbue> naively; is ecdsa actually in use with lower than 256 keysize? if so, wouldn't -256 be broken pre-384, in which case you have a prior warning mechanism
302 2014-03-18 11:59:28 <thermoman> with 0.9 do i still have to use fixwallet.py --notxes and bitcoind -rescan to get rid of the mutated TX in my wallet?
303 2014-03-18 11:59:47 <Imbue> remove if so. doesn't make sense
304 2014-03-18 12:02:04 <justanotheruser> Imbue: I don't think so. At least I haven't ever seen it mentioned
305 2014-03-18 12:02:19 <Imbue> mentally i want to compare it to sha-256 vs -512
306 2014-03-18 12:02:27 <Imbue> but I am not well versed in the ways of ecdsa
307 2014-03-18 12:03:42 <Imbue> i.e one would expect sha-256 to fall before sha-512 as they are similar in form
308 2014-03-18 12:09:44 <wumpus> thermoman: bitcoind -zapwallettxes does the same
309 2014-03-18 12:14:26 <thermoman> wumpus: does this remove *all* TX's or only the invalid ones?
310 2014-03-18 12:14:38 <thermoman> wumpus: and do i need to run -rescan afterwards?
311 2014-03-18 12:14:59 <wumpus> it removes all txes, just like fixwallet/rescan
312 2014-03-18 12:15:07 <wumpus> and rescan is automatically enabled
313 2014-03-18 12:18:04 <thermoman> wumpus: ok, so i have to run bitcoind -zapwallettxes only once and everything should be good, right?
314 2014-03-18 12:23:03 <thermoman> am i right that each and every time this formula shoud be true? sum(listunspent 6) == sum(listaccounts 6) == getbalance "*" 6
315 2014-03-18 12:23:18 <thermoman> because i have 2 wallets where this is the case
316 2014-03-18 12:23:44 <thermoman> and one wallet where sum(listunspent 6) == sum(listaccounts 6) but != getbalance "*" 6
317 2014-03-18 12:24:07 <thermoman> getbalance reports here appr. half the value of the others
318 2014-03-18 12:24:44 <thermoman> and i have one wallet where the sum of all listaccounts 6 differs for 0.00000004 from the other values
319 2014-03-18 12:24:45 <wumpus> thermoman: yes, you should need to run it only once
320 2014-03-18 12:24:52 <thermoman> wumpus: thanks
321 2014-03-18 12:42:17 <thermoman> wumpus: does this also shrink the wallet.dat file like the fixwallet.py script did?
322 2014-03-18 12:51:16 <wumpus> that's the idea
323 2014-03-18 13:09:30 <gavinandresen_> thermoman: you get sum(listunspent 6) != getbalance "*" 6 running 0.9 ?
324 2014-03-18 13:14:52 <thermoman> gavinandresen_: yes
325 2014-03-18 13:15:17 <jouke> hmm, I believe I noticed something similar recently
326 2014-03-18 13:15:52 <gavinandresen_> thermoman: then there is a bug in getbalance still.
327 2014-03-18 13:15:52 <jouke> didn't have the time to fully look into it
328 2014-03-18 13:17:09 <gavinandresen_> so⦠y'all know that none of us core developer run big wallet-intensive websites where we might encouter weird edge-case bugs, right?
329 2014-03-18 13:17:43 <gavinandresen_> In other words: you shouldn't expect us to be finding and fixing bugs that only turn up if you have wallets with gazillions of transactions in them
330 2014-03-18 13:17:47 <jouke> I know and I normally try to react on it
331 2014-03-18 13:18:04 <jouke> but sometimes we aremtoo busy :(
332 2014-03-18 13:18:45 <gavinandresen_> if you're handling other people's money, then "too busy" to track down a balance discrepancy is just plain irresponsible
333 2014-03-18 13:19:14 <jouke> yeah, we don't do that >_>
334 2014-03-18 13:19:52 <gavinandresen_> jouke: good to hear.
335 2014-03-18 13:20:15 <jouke> I know when to prioritize. this wasn't a high priority item, because our systems doesn't use the calls
336 2014-03-18 13:20:44 <epscy> isn't it known that the account stuff in bitcoind is a bit buggy?
337 2014-03-18 13:21:01 <Apocalyptic> it is, but what they are discussing has no relation to accounts whatsoever
338 2014-03-18 13:22:50 <gavinandresen_> epscy: I fixed several getbalance bugs for the 0.9 release (including a couple of accounts-specific bugs, if I recall correctly)
339 2014-03-18 13:35:19 <helo> ACTION creates a magical 'testnetify' wallet tool that allows jouke to share his buggy wallet without sharing any sensitive info
340 2014-03-18 13:36:01 <helo> i guess with testnet-in-a-box someone could potentially construct a blockchain where such a thing would be possible
341 2014-03-18 14:08:32 <ThomasZ> anyone can point me in the direction of an alternative to blockchain.info for checking transfers?
342 2014-03-18 14:08:54 <shesek> ThomasZ, webbtc
343 2014-03-18 14:09:00 <lianj> webbtc
344 2014-03-18 14:09:01 <shesek> blockr.io
345 2014-03-18 14:09:04 <shesek> blockexplorer.com
346 2014-03-18 14:09:17 <ThomasZ> heh, thanks :) I'll bookmark them all
347 2014-03-18 14:15:13 <buZz> ./bitcoind gettransaction TXIDHERE
348 2014-03-18 14:17:52 <helo> buZz: not likely to work without -txindex
349 2014-03-18 14:18:07 <Apocalyptic> ^
350 2014-03-18 14:19:11 <buZz> sure?
351 2014-03-18 14:19:26 <buZz> ACTION grabs random tx
352 2014-03-18 14:19:44 <buZz> 5007041215d1c95f6c3fda568b0ca71a597928a6eefbe5736f1d85d3543353df
353 2014-03-18 14:20:11 <buZz> ah
354 2014-03-18 14:20:11 <buZz> error: {"code":-5,"message":"Invalid or non-wallet transaction id"}
355 2014-03-18 14:20:12 <helo> if it is in the utxo, it should work
356 2014-03-18 14:20:33 <helo> afaik...
357 2014-03-18 14:20:38 <buZz> bye :)
358 2014-03-18 14:22:03 <helo> well i guess not. it could be much cheaper to save just the outputs, and not the full txes they are in.
359 2014-03-18 14:24:19 <Apocalyptic> <helo> if it is in the utxo, it should work // it only works if the tx is wallet-related
360 2014-03-18 14:24:26 <Apocalyptic> without -txindex that is
361 2014-03-18 14:24:57 <buZz> what would -txindex need to be to read abritrary txid through the wallet?
362 2014-03-18 14:32:27 <shesek> anyone going to CoinSummit next week?
363 2014-03-18 14:34:04 <helo> buZz: basically what it says. it builds a database that indexes the location in the blockhain of all txids.
364 2014-03-18 14:34:37 <buZz> ahhh ok
365 2014-03-18 14:35:04 <buZz> so if you wanted to do that, you would need to push them all in that database?
366 2014-03-18 14:35:09 <helo> yep
367 2014-03-18 14:35:24 <buZz> thats a lot of transactions ..
368 2014-03-18 14:35:56 <helo> -utxo-txindex would be a nice middle ground
369 2014-03-18 14:36:15 <helo> (just indexing the transactions with unspent outputs)
370 2014-03-18 14:36:29 <helo> *might be a nice middle ground
371 2014-03-18 14:36:50 <stonecoldpat> that would be nice, but would it not require a lot of keeping up to date ?
372 2014-03-18 14:37:36 <buZz> i still dont see how that would allow to lookup any txid
373 2014-03-18 14:38:20 <stonecoldpat> Buzz, you need to do ./bitcoind -reindex
374 2014-03-18 14:38:25 <stonecoldpat> before you can use ./bitcoind -txindex
375 2014-03-18 14:38:34 <stonecoldpat> (i'm actually doing it right now, takes hours)
376 2014-03-18 14:38:42 <buZz> doesnt -reindex just work for your own wallet
377 2014-03-18 14:38:55 <stonecoldpat> you can do ./bitcoind -reindex -txindex and as it processes the transactions, you can look them up
378 2014-03-18 14:39:01 <stonecoldpat> no, it does it for all transactions
379 2014-03-18 14:39:08 <buZz> even not yours?
380 2014-03-18 14:39:12 <stonecoldpat> yes
381 2014-03-18 14:39:24 <buZz> i'm quite sure you will get error: {"code":-5,"message":"Invalid or non-wallet transaction id"}
382 2014-03-18 14:39:53 <buZz> after doing this; ./bitcoind gettransaction 5007041215d1c95f6c3fda568b0ca71a597928a6eefbe5736f1d85d3543353df
383 2014-03-18 14:40:33 <stonecoldpat> it wotn work for gettransaction
384 2014-03-18 14:40:37 <stonecoldpat> but it will for getrawtransaction
385 2014-03-18 14:40:52 <buZz> oh it does! tnx
386 2014-03-18 14:41:12 <buZz> some day i'll try to figure out how to decode that output ;)
387 2014-03-18 14:41:23 <stonecoldpat> ./bitcoind decoderawtransaction
388 2014-03-18 14:41:29 <stonecoldpat> gives you a nice JSON version
389 2014-03-18 14:42:31 <buZz> nice!
390 2014-03-18 14:42:45 <buZz> how could i work out what the amount of confirmations is though?
391 2014-03-18 14:43:09 <buZz> i noticed confirmations lacking in many block explorers, so i guess its related to rawtransaction not outputting it?
392 2014-03-18 14:43:22 <mpescador> hello everybody! I've got a question: is there a maximum transaction size?
393 2014-03-18 14:43:31 <buZz> mpescador: should be 50M
394 2014-03-18 14:43:50 <buZz> at least, it is on most coins
395 2014-03-18 14:44:05 <helo> ./getrawtransaction <txid> 1
396 2014-03-18 14:44:06 <mpescador> i thought the maximum block size was 1 MB
397 2014-03-18 14:44:09 <helo> (for nice output)
398 2014-03-18 14:44:24 <mpescador> so I thought a transaction had to be smaller than that
399 2014-03-18 14:44:29 <buZz> helo: ah, that just decodes it all the time
400 2014-03-18 14:44:30 <stonecoldpat> just find out what block it was included in, but i dont know how to do it from the top of my head
401 2014-03-18 14:44:34 <helo> mpescador: you are correct. well, 1000000 bytes
402 2014-03-18 14:45:44 <mpescador> is the maximum transaction size then 1000000 bytes minus the size of the header?
403 2014-03-18 14:48:29 <gavinandresen_> mpescador: maximum transaction size that will be relayed and mined by most miners is 100,000 bytes
404 2014-03-18 14:51:39 <mpescador> thanks, but I just ran into a transaction that is 112 kB, so is there also a maximum valid transaction size (even though it won't be relayed by most miners)?
405 2014-03-18 14:52:50 <gavinandresen_> mpescador: I'd have to look, but the maximum block size (1MB) is the practical limit
406 2014-03-18 14:53:17 <mpescador> ok thanks a lot
407 2014-03-18 14:56:10 <stonecoldpat> in the code, typedef std::vector<unsigned char, secure_allocator<unsigned char>> CPrivKey .... whats the best way to access the unsigned chars for it? i'm not familiar with double-barroled c++ vectors
408 2014-03-18 14:57:25 <stonecoldpat> (sorry if my question is too specific!)
409 2014-03-18 15:03:50 <helo> stonecoldpat: perhaps ##c++ would be more helpful
410 2014-03-18 15:52:59 <davout> why does getrawtransaction return an array of addresses for each vout ?
411 2014-03-18 15:53:27 <davout> in which case could you have more than one address for a tx out ?
412 2014-03-18 15:53:40 <gavinandresen_> davec: multisig transactions
413 2014-03-18 15:53:54 <gavinandresen_> err, davout
414 2014-03-18 15:54:40 <gavinandresen_> davout: (non-p2sh-multisig transactions where you pay to multiple public keys, which can be expressed as an array of addresses)
415 2014-03-18 15:56:00 <davout> gavinandresen_: ok, in that case you don't really have the information of how many signatures are required to redeem the out, i mean without looking at the actual script
416 2014-03-18 15:56:19 <gavinandresen_> davout: yup
417 2014-03-18 15:57:00 <gavinandresen_> davout: oh, and you might get an empty array if the scriptPubKey can't be expressed as one or more addresses.
418 2014-03-18 15:57:02 <davout> gavinandresen_: ok, thanks a lot, i'll just filter on "type" : "pubkeyhash" to get the "usual" txes
419 2014-03-18 15:57:23 <davout> yeah, that makes sense
420 2014-03-18 15:58:48 <davout> gavinandresen_: thanks for the answers!
421 2014-03-18 16:07:55 <rotzoll> dogecoin is the teenager of bitcoin
422 2014-03-18 16:08:15 <rotzoll> sorry wrong window
423 2014-03-18 16:18:57 <michagogo> cloud|Hm, a transaction in my wallet has become conflicted
424 2014-03-18 16:19:01 <michagogo> cloud|And I can't tell why
425 2014-03-18 16:19:12 <michagogo> cloud|"confirmations" : -1, "walletconflicts" : []
426 2014-03-18 16:19:47 <michagogo> cloud|Listed with a ! in the transactions tab
427 2014-03-18 16:44:56 <davout> does rpcallowip take ranges ?
428 2014-03-18 16:45:09 <davout> or just single ips? comma separated ?
429 2014-03-18 16:45:33 <davout> hmm, apparently not
430 2014-03-18 16:45:41 <jaakkos> use iptables instead?
431 2014-03-18 16:46:23 <davout> jaakkos: it'd be nice to use both
432 2014-03-18 16:46:59 <topace> i seem to recall specifying it with /slash subnet and it worked
433 2014-03-18 16:47:32 <topace> 192.168.1.0/24
434 2014-03-18 16:47:38 <jaakkos> davout: you could also set up VPN, eg. with OpenVPN
435 2014-03-18 16:47:39 <topace> maybe im remembering incorrectly
436 2014-03-18 16:47:48 <jaakkos> and only communicate through that
437 2014-03-18 16:48:02 <jaakkos> that's what i do...
438 2014-03-18 16:48:07 <davout> topace: the wiki seems to disagree :-)
439 2014-03-18 16:48:15 <davout> jaakkos: well, that's what i did
440 2014-03-18 16:48:35 <sipa> iirc subnet specification is supported, but i never used it
441 2014-03-18 16:48:47 <davout> jaakkos: allowing external IPs without ensuring transport-level encryption, not good
442 2014-03-18 16:48:56 <sipa> yeah
443 2014-03-18 16:49:03 <jaakkos> so you use the VPN now?
444 2014-03-18 16:49:08 <davout> sipa topace i'll trust you guys and give it a shot
445 2014-03-18 16:49:14 <davout> jaakkos: yep
446 2014-03-18 16:49:20 <jaakkos> yeah
447 2014-03-18 16:49:43 <gavinandresen_> ⦠i thought the only syntax supported was 192.168.1.* ⦠but it is very possible the / syntax was added
448 2014-03-18 16:50:05 <hearn> hello
449 2014-03-18 16:52:21 <wumpus> yes the only syntax supported is 1.2.3.*
450 2014-03-18 16:52:48 <wumpus> it does a wildcard match on the rpcallowips, not a subnet match
451 2014-03-18 16:53:02 <gavinandresen_> wumpus: do you think it is time to tag 0.9.0 final ? rc3 is looking stable from my point of view
452 2014-03-18 16:53:49 <wumpus> gavinandresen_: ack
453 2014-03-18 16:54:12 <gavinandresen_> Anybody else have any issues with 0.9.0rc3? Last call....
454 2014-03-18 16:58:10 <gavinandresen_> wumpus: ok, going to tag commit 92d25e (current 0.9.0 branch HEAD) as v0.9.0 : the four commits since 0.9.0rc3 are all documentation or build system
455 2014-03-18 16:58:30 <jtimon> no issues, just congratulate all core develpers, not only it has new important features but also looks much more readable
456 2014-03-18 16:59:46 <wumpus> gavinandresen_: indeed, there have been no code changes after rc3
457 2014-03-18 17:01:04 <gavinandresen_> * [new tag] v0.9.0 -> v0.9.0
458 2014-03-18 17:12:43 <michagogo> cloud|woot
459 2014-03-18 17:12:47 <michagogo> cloud|ACTION boots his VM
460 2014-03-18 17:13:45 <michagogo> cloud|ACTION wonders how long the SMS message will take
461 2014-03-18 17:15:09 <travj> could I bother a dev for a comment on the bugs mentioned here: http://sourceforge.net/p/bitcoin/mailman/message/32093497/
462 2014-03-18 17:19:18 <wumpus> travj: agreed that something seems wrong; may be a good idea to file an issue on github to make sure this doesn't get lost
463 2014-03-18 17:19:45 <wumpus> travj: I didn't even know that zapwallettxes attempted to keep the ordering of transactions
464 2014-03-18 17:21:10 <michagogo> cloud|Builds running now
465 2014-03-18 17:21:40 <michagogo> cloud|Still haven't gotten the SMS...
466 2014-03-18 17:22:04 <travj> wumpus: okay. any comment on what I'm trying to do with the DB there?
467 2014-03-18 17:22:15 <travj> also, thanks for looking at it
468 2014-03-18 17:22:58 <wumpus> travj: I don't know enough about that part of the code to comment
469 2014-03-18 17:23:02 <travj> i don't think zipwallettxes tries to. I think it's just part of the normal wallet loading
470 2014-03-18 17:23:15 <travj> wumpus: okay, thanks
471 2014-03-18 17:23:56 <michagogo> cloud|The email did come through though
472 2014-03-18 17:24:01 <jgarzik_> ACTION appears... there is a question about -zapwallettx ?
473 2014-03-18 17:24:16 <travj> sipa told me to both Luke-Jr about it :)
474 2014-03-18 17:24:35 <travj> yea, http://sourceforge.net/p/bitcoin/mailman/message/32093497/
475 2014-03-18 17:24:53 <travj> seems to be a bug, wumpus told me to file it in github
476 2014-03-18 17:25:13 <travj> which I shall do. but i'm curious about the approach on the db ordering i'm doing
477 2014-03-18 17:25:21 <travj> wonder if a dev can comment
478 2014-03-18 17:26:19 <michagogo> cloud|Ah, just got the SMS
479 2014-03-18 17:26:24 <jgarzik_> travj, definitely file on github, to track this sort of thing and capture useful discussion of it
480 2014-03-18 17:26:36 <michagogo> cloud|25 minutes after gavin announced the new tag in here
481 2014-03-18 17:30:35 <maaku> gavinandresen_ (or others): there was talk on bitcoin-development about moving from 80 byte OP_RETURN to 40 bytes. did that get resolved?