1 2014-09-02 05:11:31 <arowser> arowser tiange
  2 2014-09-02 06:09:24 <dcousens> why is the timestamp in the block header only 32 bit?
  3 2014-09-02 06:10:25 <justanot1eruser> dcousens: because bitcoin thinks time will end before then /s
  4 2014-09-02 06:12:39 <sipa> dcousens: ask satoshi
  5 2014-09-02 06:12:53 <sipa> dcousens: on the other hand, around 20 bits would probably have sufficed
  6 2014-09-02 06:13:33 <sipa> (if the timestamp seems less than the median of the past 11 blocks, assume it has wrapped around)
  7 2014-09-02 06:13:40 <justanot1eruser> dcousens: one day time will start over at 0x0000 and I don't see why there would be a problem. It's not as if the difficulty will be effected by that
  8 2014-09-02 06:14:02 <dcousens> why not just... avoid the complication and use 64 bits?
  9 2014-09-02 06:14:15 <justanot1eruser> dcousens: why use extra data that isn't needed?
 10 2014-09-02 06:14:41 <sipa> dcousens: that would have been a very reasonable suggestion when bitcoin was being designed
 11 2014-09-02 06:14:47 <dcousens> sipa: haha
 12 2014-09-02 06:15:32 <justanot1eruser> I suppose it would be nice for nlocktime to work for times greater than 62 years
 13 2014-09-02 06:15:38 <justanot1eruser> for.. something
 14 2014-09-02 06:15:44 <justanot1eruser> inheritance?
 15 2014-09-02 06:15:59 <justanot1eruser> retirement fund for your great grand children?
 16 2014-09-02 06:16:29 <dcousens> sipa: and I'm assuming updating the block header version increase is a pain because of the delay in clients upgrading?
 17 2014-09-02 06:16:44 <sipa> dcousens: heh, it would be the worst possible change
 18 2014-09-02 06:16:53 <sipa> dcousens: every node, miner and wallet has to be changed...
 19 2014-09-02 06:16:56 <justanot1eruser> dcousens: it would probably be better to record the timestamp in the coinbase
 20 2014-09-02 06:17:38 <sipa> dcousens: we consider changes that just require full nodes to be upgraded already nontrivial
 21 2014-09-02 06:18:06 <justanot1eruser> sipa: you don't think any timing attacks would be possible with a 20 bit timestamp?
 22 2014-09-02 06:18:14 <dcousens> sipa: well, on another note, this questions probably simpler, but why is the UTC timestamp allowed to be < than the previous (provided its greater than a 11 block median iirc)?
 23 2014-09-02 06:18:14 <sipa> such as?
 24 2014-09-02 06:18:20 <dcousens> sipa: also, how would a 20bit timestamp work?
 25 2014-09-02 06:18:22 <justanot1eruser> I suppose the likelyhood of an 11 day block is very low
 26 2014-09-02 06:18:38 <justanot1eruser> sipa: something I haven't thought of.
 27 2014-09-02 06:18:51 <sipa> dcousens: because clocks are not perfectly synchronized across the globe (though the allowed rewind is probably way overkill)
 28 2014-09-02 06:19:08 <justanot1eruser> seems like there may be some problems with making the timestamp 11 days and the diff adjustment 14 days
 29 2014-09-02 06:19:36 <dcousens> sipa: right, but surely you could just reject blocks too far in the future?
 30 2014-09-02 06:19:42 <sipa> dcousens: and we do
 31 2014-09-02 06:19:57 <sipa> (blocks can be up to 2 hours in the future)
 32 2014-09-02 06:20:54 <dcousens> sipa: fair enough
 33 2014-09-02 06:21:21 <dcousens> sipa: so how would the 20 bit timestamp work btw?
 34 2014-09-02 06:22:22 <sipa> dcousens: just put the lowest 20 bits of the timestamp in the block; internally, you know for each block the full (64 bit) timestamp; to compute the full timestamp for an incoming block, look at the full timestamp median of the past 11 blocks, and if the 20 bits are lower than the 20 lowest bits of that median, assume it has wrapped around
 35 2014-09-02 06:22:37 <sipa> justanot1eruser: would work fine, i think
 36 2014-09-02 06:23:15 <justanot1eruser> sipa: a miner with 51% may be able to make a ton of blocks at times 1, 2, 3, 4... when in reality they are a few hours to days in the future, then warp back again and continue their sequence
 37 2014-09-02 06:23:25 <justanot1eruser> strange terminology I'm using to describe that
 38 2014-09-02 06:23:59 <sipa> every block has a single, well-defined, and immutable 64-bit timestamp
 39 2014-09-02 06:24:13 <sipa> it's just that only the lowest 20 bits are in the header
 40 2014-09-02 06:24:16 <justanot1eruser> at least 32 bits ensures the miners needs to maintain their 51% for 62 years
 41 2014-09-02 06:24:21 <gmaxwell> I don't think a 64 bit timestamp would be am improvement at all. IT would just be more cost for SPV nodes for more gain.
 42 2014-09-02 06:24:28 <gmaxwell> er for no gain.
 43 2014-09-02 06:24:41 <justanot1eruser> sipa: oh, well if there's a 64 bit timestamp in the coinbase, no problem
 44 2014-09-02 06:24:46 <gmaxwell> As sipa notes, 20 bits would have been fine. 32 bits is a handy value.
 45 2014-09-02 06:24:46 <sipa> justanot1eruser: no, no, no
 46 2014-09-02 06:24:54 <sipa> justanot1eruser: the 64 bit value is implicit
 47 2014-09-02 06:24:56 <dcousens> justanot1eruser: I think he means stored internally, locally
 48 2014-09-02 06:24:58 <justanot1eruser> oh
 49 2014-09-02 06:25:05 <dcousens> because the remaining 44 bits can be implied
 50 2014-09-02 06:25:05 <sipa> justanot1eruser: but there is a deterministic algorithm for computing it
 51 2014-09-02 06:25:28 <gmaxwell> similar to how the full sequence counter is handled in SRTP.
 52 2014-09-02 06:25:43 <justanot1eruser> how? Isn't it possible that the miner could have just created those blocks that close and they took that long to propogate to you in this system?
 53 2014-09-02 06:26:15 <sipa> the timestamp is fixed
 54 2014-09-02 06:26:34 <sipa> can you give a specific example?
 55 2014-09-02 06:26:39 <justanot1eruser> hmm
 56 2014-09-02 06:27:11 <sipa> let's simplify things first and say the timestamp has to be always at least equal to the previous block hash
 57 2014-09-02 06:27:21 <poutine> I wrote a tutorial on crafting nonstandard transactions using bitcoinjs-lib and nodejs, would appreciate feedback, both stylistic and technical: http://pastedown.ctrl-c.us/#GwNSvBuqgHEBbubtumnd4qQ0yDE.markdown
 58 2014-09-02 06:27:47 <justanot1eruser> sipa: gets rid of some attacks
 59 2014-09-02 06:27:56 <justanot1eruser> (potential attacks I mean)
 60 2014-09-02 06:28:00 <gmaxwell> what gets rid of some attacks?
 61 2014-09-02 06:28:08 <justanot1eruser> saying 02:27 < sipa> let's simplify things first and say the timestamp has to be always at least equal to the previous block hash
 62 2014-09-02 06:28:21 <sipa> i think it doesn't change a thing
 63 2014-09-02 06:28:22 <gmaxwell> No, doing that create attacks, but it simplfies discussion.
 64 2014-09-02 06:28:30 <gmaxwell> er creates*
 65 2014-09-02 06:28:37 <sipa> right, even the opposite
 66 2014-09-02 06:29:50 <justanot1eruser> well it may do both
 67 2014-09-02 06:30:13 <justanot1eruser> not sure of that though
 68 2014-09-02 06:30:31 <sipa> then FullTime(block) = ((FullTime(block->prev) & ~0xFFFFF) | block->nTime) + (block->nTime < FullTime(block->prev) ? 0x100000 : 0)
 69 2014-09-02 06:30:51 <dcousens> poutine: you specify TransactionOut = bitcoin.TransactionOut
 70 2014-09-02 06:30:57 <dcousens> but that doesn't exist anymore, and you never use it anyway
 71 2014-09-02 06:31:05 <gmaxwell> justanot1eruser:  imagine you have an 8 bit counter that can only go up, 0 to 255 and it wraps.  Say you read 100. Then you read 1.  You know the value is now 257— unless it was possible to wrap twice between two sampling intervals.
 72 2014-09-02 06:31:07 <justanot1eruser> the attacks would probably have to be due to the fact that a full node wouldn't know whether you are in the current time or the next time
 73 2014-09-02 06:31:09 <poutine> dcousens, Ah, thanks dcousens, fixed
 74 2014-09-02 06:31:19 <gmaxwell> justanot1eruser: it's unambigious.
 75 2014-09-02 06:31:28 <sipa> justanot1eruser: you're always in the time defined by the chain you're in
 76 2014-09-02 06:31:33 <sipa> the "current time" doesn't matter
 77 2014-09-02 06:31:42 <gmaxwell> justanot1eruser: a block only exists in the context of the blocks that came before it. You cannot evaluate a block without the prior ones.
 78 2014-09-02 06:31:42 <justanot1eruser> hmm
 79 2014-09-02 06:32:01 <justanot1eruser> right
 80 2014-09-02 06:32:12 <sipa> it does complicate some of the early-rejection heuristics, that detect faulty blocks before their parent headers are known, though
 81 2014-09-02 06:32:58 <gmaxwell> only because thats how they're setup in bitcoind, it's not an important difference.
 82 2014-09-02 06:33:16 <sipa> headersfirst doesn't need those anymore :)
 83 2014-09-02 06:34:01 <justanot1eruser> I think if there is a problem, it would be with the fact that you wouldn't know whether a block came 1 hour before, or 11 days after in a system where a 51% miner has the power to make all blocks appear really old
 84 2014-09-02 06:34:33 <justanot1eruser> I guess the deterministic diff adjustment algorithm would accomodate for that
 85 2014-09-02 06:34:41 <sipa> well, obviously, a block can't be more than 11 days after is predecessor
 86 2014-09-02 06:34:45 <justanot1eruser> s/came/has a timestamp signifying
 87 2014-09-02 06:35:04 <sipa> *its
 88 2014-09-02 06:35:14 <dcousens> gmaxwell: if you used the 20bit with 44bits implicit, surely that wrapping problem goes away for a veryveryvery long time, and you could then enforce previous timestamp is < than the currnet?
 89 2014-09-02 06:35:25 <gmaxwell> justanot1eruser: there is a minimum timestamp which is permitted by the protocol. The timestamp must be greater than the median of the last 11 blocks.
 90 2014-09-02 06:35:58 <justanot1eruser> gmaxwell: ah. well then it would automatically be 11 days
 91 2014-09-02 06:36:37 <gmaxwell> dcousens: absolutely not, enforcing the previous timestamp < current opens up attacks where a miner drives the timestamp maximally far forward, and subsiquent miners are forced to lie about the time. The lack of a monotonicity constraint is completely orthorgonal.
 92 2014-09-02 06:36:39 <justanot1eruser> making the timestamp last shorter than the difficulty adjustment period just seems ... weird to me.
 93 2014-09-02 06:36:58 <gmaxwell> dcousens: if you want a monotonic timestamp from bitcoin you can freely postprocess the miner provided ones yourself without creating those issues.
 94 2014-09-02 06:37:07 <sipa> justanot1eruser: the timestamp is 64 bit!
 95 2014-09-02 06:37:16 <sipa> justanot1eruser: it's just stored in a compressed form in the header
 96 2014-09-02 06:37:41 <dcousens> gmaxwell: yeah, aware of the current solution, but what stops a miner from doing the above anyway if they mine the majority?
 97 2014-09-02 06:37:44 <justanot1eruser> sipa: you're implicitly saying there is already a local timestamp system?
 98 2014-09-02 06:37:49 <dcousens> (that is, push the timestamp into the future)
 99 2014-09-02 06:38:13 <sipa> justanot1eruser: yes, only we currently just use 32-bit internal timestamps, and we store the lowest 32 bits of those :p
100 2014-09-02 06:38:21 <gmaxwell> dcousens: that they have to be a (super) majority, which already violates the basic security assumtions, ... vs just mining a single block.
101 2014-09-02 06:38:27 <justanot1eruser> such a silly and accurate way of saying that
102 2014-09-02 06:38:45 <sipa> justanot1eruser: but you could just as well say that we currently have 64-bit timestamps of which 32 bit is stored
103 2014-09-02 06:39:01 <sipa> justanot1eruser: and it's a temporary implementation optimization to just assume the higher bits are all 0
104 2014-09-02 06:39:04 <sipa> :p
105 2014-09-02 06:39:07 <dcousens> gmaxwell: so surely other miners/nodes could just reject a block that miner was attempting to push to far into the future?
106 2014-09-02 06:39:33 <dcousens> s/surely/couldn't
107 2014-09-02 06:39:42 <gmaxwell> dcousens: sure, but then you have an incentives problem. If you don't continue that branch you'll likely be beat out by someone that does.
108 2014-09-02 06:40:20 <dcousens> gmaxwell: but the nodes would reject it?
109 2014-09-02 06:40:31 <dcousens> its not even something to be beaten?
110 2014-09-02 06:40:46 <gmaxwell> No because the attacker can put the time right up against whatever threshold you have there.
111 2014-09-02 06:41:24 <dcousens> true
112 2014-09-02 06:41:26 <gmaxwell> (also, clocks are not synchronous, and can't be made synchronous without the kind of centeralized process mining is supposted to be avoiding)
113 2014-09-02 06:41:36 <dcousens> but
114 2014-09-02 06:41:40 <dcousens> they could only push it 2hrs forward
115 2014-09-02 06:41:46 <dcousens> or whatever threshold
116 2014-09-02 06:41:49 <dcousens> then they'd be stuck on that?
117 2014-09-02 06:42:14 <dcousens> but then you run into synchronous problems... yeah
118 2014-09-02 06:42:32 <gmaxwell> yes, so with only 8% of the hashrate you could constantly drive difficulty down.
119 2014-09-02 06:42:55 <gmaxwell> well drive it down a half percent and then leave the network with tons of invalid blocks that drive it down further.
120 2014-09-02 06:43:23 <gmaxwell> there are altcoins that have broken themselves with changes like this already, can't remember the name now. :-/
121 2014-09-02 06:43:36 <dcousens> gmaxwell: their great for that
122 2014-09-02 06:43:40 <dcousens> s/their/they're
123 2014-09-02 06:45:08 <dcousens> anyway, cheers for clarifying gmaxwell, sipa
124 2014-09-02 06:45:13 <gmaxwell> there are all sorts of things that could be done for better timekeeping in bitcoin, but we need the time only for a very narrow purpose, so adding more of them wouldn't really be all that helpful. :)
125 2014-09-02 06:46:13 <gmaxwell> (e.g. having blocks each commit to the miners observed timestamp for all the prior blocks which they directly observed, so you can do median voting on the observed time of every block)
126 2014-09-02 06:47:48 <dcousens> poutine: if you have any questions regarding bitcoinjs, feel free to ask here or in bitcoinjs-dev.   Always happy to help those using the lib :P
127 2014-09-02 06:48:01 <dcousens> (#bitcoinjs-dev)
128 2014-09-02 06:51:08 <poutine> I read that OP_NOP1-OP_NOP10 are reserved for future opcodes, but I'm still not understanding why the script does not halt on them. Someone (I think gmaxwell) explained that if an opcode replaces a NOP code, it will just use some height rules, but I see no examples of this ever occurring, is there an example where this pattern of checking block height for the replacement of a NOP opcode has occurred?
129 2014-09-02 06:51:58 <gmaxwell> if the script halted on them they'd be useless for backwards compatible enhancements.
130 2014-09-02 06:52:17 <gmaxwell> Because as soon as one was used all non-upgraded nodes would 'halt'.
131 2014-09-02 06:52:23 <gmaxwell> So instead they must be ignored.
132 2014-09-02 06:53:08 <gmaxwell> OP_EVAL was an example of this, but it was replaced with the more terse p2sh. In general though you can't find height triggered rules in the code because we can take out the rule once the transistion passed if there were no earlier violations of it.
133 2014-09-02 06:53:31 <gmaxwell> (BIP 30 is an example of that, there was originally a height triggered rule, and now there is just a test for the two exceptional blocks)
134 2014-09-02 06:53:45 <poutine> gmaxwell, but if I made a tx with OP_NOP1-OP_NOP10 interspersed in the script, the redemption of it could be impossible in the future based on implementation, and things checking validity of transactions will have to then take into account relative block height adoption
135 2014-09-02 06:54:52 <gmaxwell> correct, this is why such outputs must be non-standard now. Since if people start randomly sticking them in scripts, then their use as a forward extension mechenism would be complicated.
136 2014-09-02 06:55:22 <gmaxwell> (bitcoin does keep track of transactions versions and heights for every txout, so the meaning of a scriptpubkey could be conditional)
137 2014-09-02 06:55:56 <justanot1eruser> are ops 176-252 NOPs?
138 2014-09-02 06:56:16 <gmaxwell> But better if there are just no examples, no miners mining examples, and the new behavior can just take effect past some point.
139 2014-09-02 06:58:54 <poutine> I was informed that no such thing currently exists, but is there any report on opcode usage by opcode on mainnet/testnet?
140 2014-09-02 06:59:35 <gmaxwell> I've tallied them in the past, though not recently.
141 2014-09-02 06:59:59 <gmaxwell> there is pratically nothing on mainnet that isn't a ordinary transaction (well, there is some multisig use growing)
142 2014-09-02 07:00:45 <poutine> did you parse the block files?
143 2014-09-02 07:01:12 <poutine> any hint for a duplicated effort?
144 2014-09-02 07:01:33 <gmaxwell> no. Just had bitcoind dump the data on a rescan. (e.g. added a print for scrippubkeys in validation)
145 2014-09-02 07:01:49 <gmaxwell> if you just want the utxo set, instrumenting gettxoutsetinfo works great.
146 2014-09-02 07:04:20 <poutine> Thanks
147 2014-09-02 07:09:43 <shaileshg> Hi, i m creating a raw transaction and signing it with my private key.. but if there is change, i m sending it back to my public address instead of bitcoind creating a new receiving address and sending change to it
148 2014-09-02 07:10:07 <amaclin> poutine, I have analysed blockchain for all non-standard txs. Of course I saw your last one dd754e98867fc8eab853d721d32a160418acca020e6dddeb27592c7628177486
149 2014-09-02 07:10:28 <shaileshg> is it fine to do so? I am asking it because i created some such transactions.. but when i m visiting blockexplorer.com/testnet/tx/txid, it is not showing up thr
150 2014-09-02 07:11:14 <poutine> I wasn't aware using OP_NOP# is bad
151 2014-09-02 07:11:26 <justanot1eruser> poutine: it is?
152 2014-09-02 07:11:31 <shaileshg> one such txid is 622598e4de12b34ea7eef2d1a8f599014dc5bae587ee6abe1dc06e5923fa364a
153 2014-09-02 07:11:33 <justanot1eruser> Seems just like a waste of space in a tx
154 2014-09-02 07:11:47 <shaileshg> http://blockexplorer.com/testnet/tx/622598e4de12b34ea7eef2d1a8f599014dc5bae587ee6abe1dc06e5923fa364a
155 2014-09-02 07:11:51 <gmaxwell> wtf who mined that.
156 2014-09-02 07:13:43 <amaclin> it is much better to use testnet for non-standard txs imho
157 2014-09-02 07:14:01 <BlueMatt> if you can get it mined, go for it
158 2014-09-02 07:14:08 <BlueMatt> but its often hard to get mined
159 2014-09-02 07:43:40 <edcba> i have some random idea : fee according to OP frequency
160 2014-09-02 07:44:17 <justanot1eruser> edcba: fee for whom?
161 2014-09-02 07:44:40 <justanot1eruser> maybe the full nodes would care about how much they compute, but the miners really only care about maximizing profits
162 2014-09-02 08:14:06 <warren> sipa: pingt
163 2014-09-02 08:14:28 <sipa> warren: pongt
164 2014-09-02 09:35:46 <wumpus> ...remind me again, why are we using computers for important stuff? https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf
165 2014-09-02 09:44:11 <gmaxwell> $ grep isca14 \#bitcoin-wizards.log
166 2014-09-02 09:44:11 <gmaxwell> wumpus: your response is much like mine was,
167 2014-09-02 09:44:12 <gmaxwell> 14:51 <@gmaxwell> On today's expisode of eveything is broken and we're doomed. http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
168 2014-09-02 09:44:26 <wumpus> hah, sorry, didn't see that
169 2014-09-02 09:44:35 <gmaxwell> it was some months ago.
170 2014-09-02 09:44:46 <gmaxwell> Interesting paper none the less. Also: I <3 ecc ram.
171 2014-09-02 09:45:51 <wumpus> it looks like assumptions that you make at a certain level are always bound to be undermined from a lower level, even if you prove that your system is safe at some level of abstraction a 'submarine' attack like this will catch you
172 2014-09-02 09:45:58 <epscy> i'm not sure a world run by pen and paper was any less error prone
173 2014-09-02 09:46:35 <z33and000h> http://themoscownews.com/russia/20130711/191758523/Russian-security-agency-to-buy-typewriters-to-avoid-surveillance.html
174 2014-09-02 09:46:49 <epscy> i guess the economies of scale computers allow raise the stakes somewhat though
175 2014-09-02 09:46:58 <wumpus> like you can just twiddle bits and make something happen at a physical level, and there goes your carefully-constructed castle in the air
176 2014-09-02 09:47:45 <wumpus> epscy: oh sure, brains and pieces of paper are nothing better :-)
177 2014-09-02 09:50:05 <epscy> i blame entropy, nothing can ever be stable in this crappy universe ;)
178 2014-09-02 09:53:48 <wumpus> it makes me think of some experiments with evolutionary computation, where the evolution came up with an algorithm no one could initially understand how it worked, but that was because it relied on some low-level hardware properties/bugs
179 2014-09-02 09:54:57 <wumpus> anyhow - we think at well-defined levels of abstraction, but the universe does not :)
180 2014-09-02 10:31:30 <warren> bitcoin-qt: db/version_set.cc:789: leveldb::VersionSet::~VersionSet(): Assertion `dummy_versions_.next_ == &dummy_versions_' failed.
181 2014-09-02 10:31:30 <warren> Hmm, sometimes when shutting down bitcoin-0.9.3 branch it crashes with an assertion failure.
182 2014-09-02 10:32:03 <wumpus> that's a regression of 0.9.3 compared to 0.9.2?
183 2014-09-02 10:32:28 <wumpus> strange; looks like it's in leveldb, we didn't change anything there
184 2014-09-02 10:34:24 <wumpus> jtimon: you have so many pull requests open, it's really hard to keep track of for me
185 2014-09-02 10:34:52 <jtimon> yeah, I'm closing those that are dependent on others right now
186 2014-09-02 10:35:24 <jtimon> sorry, about that, had to clarify my mind first
187 2014-09-02 10:37:32 <jtimon> well, with an exception although #4754 depends on #4812 I'll leave it open
188 2014-09-02 10:38:39 <warren> wumpus: no, I haven't tried local builds on Fedora for a few months, so I don't know when this happened
189 2014-09-02 10:38:56 <wumpus> if it is in 0.9.2.1 I've never heard it reported before
190 2014-09-02 10:42:29 <wumpus> google does turn up some matches on the leveldb mailing list
191 2014-09-02 10:42:41 <wumpus> ...from 2011
192 2014-09-02 10:42:55 <warren> I've literally never seen this error before today.
193 2014-09-02 10:47:23 <Mingw> Hi all.
194 2014-09-02 10:47:31 <Mingw> I'm still stucked.. can somebody help me please?
195 2014-09-02 10:47:50 <Mingw> It's just a problem with paths, since the compilation just fail when making the release..
196 2014-09-02 10:47:59 <Mingw> Somebody expert in c?
197 2014-09-02 10:51:21 <b-itcoinssg> Mingw: Are you referring to the core client?
198 2014-09-02 10:51:52 <b-itcoinssg> Mingw: If so, have you looked at github to search for your error?
199 2014-09-02 10:53:21 <Mingw> no
200 2014-09-02 10:53:24 <Mingw> Not core client
201 2014-09-02 10:53:33 <Mingw> it is litecoin.
202 2014-09-02 10:53:38 <Mingw> Under windows.
203 2014-09-02 10:53:44 <Mingw> it uses .pro file yet.
204 2014-09-02 10:53:52 <Mingw> I guess my error is in .pro file..
205 2014-09-02 10:53:57 <Mingw> Some path is wrong there..
206 2014-09-02 10:54:08 <Mingw> But im stuck since saturda on this shiiiit
207 2014-09-02 10:54:15 <Mingw> I'm starting to being crazy.
208 2014-09-02 10:54:58 <b-itcoinssg> have you looked at the litecoin channels or the github repo then?
209 2014-09-02 11:09:14 <wumpus> no altcoin talk here please
210 2014-09-02 11:34:01 <jtimon> wumpus cleaned up most of it, reduced my open PRs to7 independent ones (with the exception mentioned earlier)
211 2014-09-02 11:34:25 <wumpus> jtimon: ok, I'll need to reserve some time to look at them :)
212 2014-09-02 11:34:51 <jtimon> and sorry again about the mess I was making with so many open PRs
213 2014-09-02 11:36:20 <wumpus> #4812 is trivial and removes code, thats' good
214 2014-09-02 11:36:24 <jtimon> #4506 and #4775 haven't changed much
215 2014-09-02 11:37:07 <jtimon> yeah, it makes no sense to move that code in #4754 only to remove it later
216 2014-09-02 11:40:18 <jtimon> anyway, now I'm going to work on #4812/#4754 with sipa's suggestions, I want #4754 to remain move-only so I may add some preparations to 4812
217 2014-09-02 11:41:01 <jtimon> the rest I shouldn't need to touch in a while but for rebases or nits
218 2014-09-02 11:58:31 <jtimon> nah, it seems I'll just leave both 4812 and 4754 as they are too
219 2014-09-02 12:22:52 <dabura667> Anyone know a good unicode normalization library for javascript? I keep feeding my Japanese into str.normalize('NFKD') and it doesn't separate my string into its components. console.log() shows no change to the string.
220 2014-09-02 12:23:02 <dabura667> (in regards to BIP39)
221 2014-09-02 13:11:04 <ThomasV> dabura667: what are you trying to do with japanese strings?
222 2014-09-02 13:15:02 <dabura667> To create a binary seed from the mnemonic, we use PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as a password and string "mnemonic" + passphrase (again in UTF-8 NFKD) used as a salt.
223 2014-09-02 13:15:16 <dabura667> I am making a Japanese wordlist for BIP39
224 2014-09-02 13:15:41 <dabura667> and I need to run it through UTF-8 NFKD but I am unsuccessful in javascript.
225 2014-09-02 13:16:26 <dabura667> ThomasV
226 2014-09-02 13:18:36 <ThomasV> unduccessful, in which way?
227 2014-09-02 15:21:37 <dabura667> ThomasV: str.normalize('NFKD') to normalize the japanese text, but when I place console.log() before and after the normalizing it only shows the same string in the console. I even put in strings that are known to be split when put through NFKD.
228 2014-09-02 15:22:09 <sipa> isn't the point of normalization that the printed form is identical? (<- unicode noob here)
229 2014-09-02 15:27:33 <dabura667> sipa: is that true?........ so maybe the console is supposed to show the same string?..... hmm.
230 2014-09-02 15:27:47 <dabura667> brb, I'm going to generate two separate seeds and compare.
231 2014-09-02 15:29:49 <sipa> dabura667: look at the actual bytes, not the printed characters
232 2014-09-02 15:30:32 <dabura667> sipa: it looks like the seeds are different.
233 2014-09-02 15:33:36 <earlz> It isn't possible to do multiple RPC calls in a single request, is it?
234 2014-09-02 15:34:03 <sipa> earlz: yes it is, using JSON-RPC 2.0
235 2014-09-02 15:34:22 <earlz> is that only in master/0.10?
236 2014-09-02 15:35:08 <sipa> no; it was merged on juli 3 2012
237 2014-09-02 15:35:27 <earlz> hmm. I'll have to look this up. I never saw any reference to it
238 2014-09-02 15:35:35 <dabura667> sipa: ok I was able to verify the bytes have been properly normalized.
239 2014-09-02 15:35:38 <dabura667> false alarm.
240 2014-09-02 15:35:41 <dabura667> Thanks.
241 2014-09-02 15:35:44 <sipa> earlz: available since 0.7.0
242 2014-09-02 15:35:54 <sipa> it's rarely used
243 2014-09-02 15:35:58 <sipa> but it can reduce overhead
244 2014-09-02 15:36:03 <earlz> is it listed on the wiki?
245 2014-09-02 15:36:07 <sipa> no clue
246 2014-09-02 15:36:15 <earlz> SEriously have never seen any reference to it heh
247 2014-09-02 15:36:41 <sipa> doesn't surprise me
248 2014-09-02 15:37:05 <earlz> I'm building a block explorer and instead of doing the Abe method of reading blockfiles, instead opting to do everything over RPC
249 2014-09-02 15:37:14 <sipa> sounds crazy
250 2014-09-02 15:37:17 <sipa> that will take ages
251 2014-09-02 15:37:25 <sipa> even with batch rpc
252 2014-09-02 15:37:32 <earlz> eh, I get about 1000 blocks in 2 minutes. Not too bad
253 2014-09-02 15:37:39 <earlz> without any processing, anyway
254 2014-09-02 15:37:59 <earlz> After the initial sync up, it shouldn't matter anyway
255 2014-09-02 15:38:30 <earlz> From what I'm seeing, getblock and getrawtransaction also isn't locked, so I can do those multithreaded and speed it up a bit
256 2014-09-02 15:39:17 <earlz> the bad thing is I'm dealing with shitcoins too. So, coins with 1 minute block times are going to be hell because they have so many
257 2014-09-02 15:39:47 <sipa> both getblock and getrawtransaction acquire cs_main
258 2014-09-02 15:39:51 <sipa> so they won't run in parallel
259 2014-09-02 15:40:06 <gavinandresen> earlz: do you happen to be writing in python?  A regression test or three for the batch RPC functionality would be spiffy.
260 2014-09-02 15:40:08 <earlz> I didn't see that :/
261 2014-09-02 15:40:52 <earlz> No, C#. I could try to write a python repro though if I find any bugs heh
262 2014-09-02 15:40:54 <gavinandresen> … and even spiffier is if you then updated the wiki once you made sure everything works properly....
263 2014-09-02 15:41:54 <sipa> earlz: they're listed as 'false' for threadSafe in the rpc table in rpcserver.cpp, so the RPC system will acquire cs_main before invoking
264 2014-09-02 15:42:04 <earlz> ah. the one place I didn't check lol
265 2014-09-02 15:42:18 <earlz> I'm kinda surprised that read-only operations require locks
266 2014-09-02 15:42:36 <wumpus> batch RPC functionality works, I have some basic python code that uses it, could make it into a regression test at some point
267 2014-09-02 15:42:56 <sipa> earlz: could be significantly improved for sure
268 2014-09-02 15:43:01 <wumpus> earlz: well even for reading it's important that data structures don't change while an operation is in progress
269 2014-09-02 15:43:34 <earlz> eh, true. you'd think there would be some "read lock" that could be acquired that'd prevent writing or osme such.. threading is hard
270 2014-09-02 15:43:40 <wumpus> sure, it could use a reader-writer lock, but it'd still need a lock
271 2014-09-02 15:46:24 <earlz> I don't know how the Abe developers stay sane working at the blkxxxx level, manually parsing and intepreting the files heh
272 2014-09-02 15:46:52 <dabura667> sipa: hmm, now the ASCII + English test vectors don't match anymore... running the tests with TREZOR as the passphrase and they used to pass... NFKD shouldn't touch normal ASCII, am I correct?
273 2014-09-02 15:57:10 <dabura667> sipa: nevermind... another oversight on me. it's 1am I should go to bed... thanks again.
274 2014-09-02 16:16:00 <wumpus> earlz: well, they obviously already implemented it though, why don't you just use their routines?
275 2014-09-02 16:16:48 <earlz> because it's too high maintenance, especially since I deal with altcoins as well
276 2014-09-02 16:17:33 <earlz> IF you can setup an Abe block explorer for an X11 coin in under 4 hours, I'll shake your hand
277 2014-09-02 16:18:44 <earlz> in theory, it should be trivial, but it's not because you have to specify how the block is hashed, also have to cover things like address version number and a lot of other low level stuff that using RPC spares you from worrying abou
278 2014-09-02 16:25:28 <dabura667> https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.json
279 2014-09-02 16:25:36 <dabura667> woohoo! thanks sipa!
280 2014-09-02 16:25:50 <dabura667> I am pretty sure these are accurate
281 2014-09-02 17:02:00 <jtimon> threads are locks are hard, that's why I preffer messaging for concurrency, zmq/nanomsg ftw!
282 2014-09-02 17:02:22 <jtimon> s/threads are locks/threads and locks
283 2014-09-02 17:03:24 <wumpus> they're not so much hard, but very error prone, c/c++ are great languages for shooting yourself in the foot, doubly so with threading
284 2014-09-02 17:04:28 <jtimon> well, indepently of the language I believe messaging is a much better design paradigm for concurreny than locks
285 2014-09-02 17:04:40 <sipa> it's more limited though
286 2014-09-02 17:04:57 <jtimon> mhmm, you can do everything with both
287 2014-09-02 17:05:01 <wumpus> jtimon: I don't disagree
288 2014-09-02 17:06:38 <gmaxwell> jtimon: it's very easy to end up with poor performance with message passing, keep in mind that on current hardware memory bandwidth is the most precious resource.
289 2014-09-02 17:06:51 <jintelletec> any rails developers looking for btc work in LA?
290 2014-09-02 17:06:55 <sipa> jintelletec: not here
291 2014-09-02 17:07:11 <wumpus> messaging at least makes proper isolation possible, in principle the threading paradigm is leaky at all sides
292 2014-09-02 17:07:25 <sipa> jintelletec: if you want to do messaging to avoid all locking, you must have a single thread (at most) per shared data structure to do updates to it
293 2014-09-02 17:07:28 <skinnkavaj> Who did js library for BTC?
294 2014-09-02 17:07:30 <sipa> eh
295 2014-09-02 17:07:30 <skinnkavaj> Mike Hearn?
296 2014-09-02 17:07:33 <sipa> jtimon: if you want to do messaging to avoid all locking, you must have a single thread (at most) per shared data structure to do updates to it
297 2014-09-02 17:07:59 <sipa> jtimon: if you need atomic updates across multiple shared data structures, you're forced to make them part of the same thread
298 2014-09-02 17:08:51 <wumpus> skinnkavaj: no, he did the *java* library
299 2014-09-02 17:09:05 <jtimon> no, you're not, you can have a worker for each step of a serial proccess, just like ford did to manufacture cars
300 2014-09-02 17:09:14 <sipa> jtimon: serial != atomic
301 2014-09-02 17:09:51 <sipa> or you need a complex undo procedure to roll back changes
302 2014-09-02 17:10:01 <sipa> which i guess may be possible, but would be terribly error prone
303 2014-09-02 17:10:13 <jgarzik> Indeed; message passing is often an answer to familiar lock/unlock sequencing...  but damn it gets slow
304 2014-09-02 17:10:24 <jgarzik> "everything is a message" is pretty much true, right down to the hardware
305 2014-09-02 17:10:31 <jgarzik> but it doesn't make for the best model in software
306 2014-09-02 17:10:31 <wumpus> use copy-on-write, or immutable data structures *ducks*
307 2014-09-02 17:10:46 <jgarzik> wumpus, transactional memory is the latest buzz...
308 2014-09-02 17:10:54 <jtimon> my point is that there's many ways to do things with messaging besides "no different threads can touch the same shared structure"
309 2014-09-02 17:10:58 <wumpus> ah, yes, transactional memory
310 2014-09-02 17:14:22 <jgarzik> http://en.wikipedia.org/wiki/Tux3 has vaguely similar concepts in storage filesystem tech:  updates are written to long-unused locations in storage, and some time $later the just-invalidated data is forgotten.  in that way, you don't have to carefully order accesses to the same range of bytes, and (this was important at the time) you reduce disk cache flushing to near zero.
311 2014-09-02 17:14:53 <jgarzik> something like an atomic cow
312 2014-09-02 17:15:25 <jgarzik> ok, maybe not, but I just wanted to say atomic cow
313 2014-09-02 17:15:45 <gmaxwell> hah
314 2014-09-02 17:18:28 <MiningBuddy> o/
315 2014-09-02 17:18:34 <wumpus> hehe
316 2014-09-02 18:11:22 <jtimon> sipa regarding CTxDestination, I could rebase 4754 on top of this https://github.com/jtimon/bitcoin/compare/bitcoin:master...jtimon:libscript-2?expand=1
317 2014-09-02 18:11:56 <jtimon> and then move it to script/standard instead of script/script
318 2014-09-02 18:12:45 <jtimon> but if it's going to be controversial maybe it's better to wait after 4754...
319 2014-09-02 18:17:40 <jtimon> what do you think wumpus, before or after?
320 2014-09-02 18:27:44 <sipa> jtimon: anytime you rebase/change 4754, previous review becomes worthless
321 2014-09-02 18:28:17 <jtimon> I just rebased it yesterday or today
322 2014-09-02 18:28:22 <sipa> yes, i know :)
323 2014-09-02 18:28:26 <jtimon> so all review work was gone
324 2014-09-02 18:28:36 <jtimon> but I take that as a later
325 2014-09-02 18:28:40 <sipa> wasn't necessary, btw; it still merged cleanly :p
326 2014-09-02 18:28:48 <sipa> (despite what github said0
327 2014-09-02 18:30:01 <phantomcircuit> sipa, plz2test 4790
328 2014-09-02 18:30:03 <jtimon> yeah, I was confused about not having to resolve any conflicts, I should have left it there then
329 2014-09-02 18:30:18 <sipa> right; do one refactor at a time... it will take a while for a larger set of changes to be merged, but it means you don't need to constantly rebase dependent PRs, while probably few people look at the further ones anyway
330 2014-09-02 18:30:30 <jtimon> anyway, better not thouch it again
331 2014-09-02 18:31:06 <sipa> phantomcircuit: will do
332 2014-09-02 18:32:38 <jtimon> I extended it with all the big code movements though (but without the movements to wallet), once that's merged, all the other changes are more independent
333 2014-09-02 20:31:20 <tigereye> I'm having a bitch of a time generating testnet coins. I just need 1 block, but even at difficulty 1 I can't find a block
334 2014-09-02 20:31:35 <tigereye> Is there anything else I need to do other than ./Bitcoin-QT -testnet -gen
335 2014-09-02 20:32:09 <Luke-Jr> tigereye: get a real miner like BFGMiner?
336 2014-09-02 20:39:47 <tigereye> cpu mining with Bitcoin Core won't work at all?
337 2014-09-02 20:40:26 <tigereye> maybe this will be easier. If any devs have 50 testnet coins they're willing to share, please send to mvrHB2o8u8g4Q19kRc8WPYAymhadpvagL9
338 2014-09-02 20:40:34 <tigereye> I promise to forward all test coins to a faucet when I'm done with them!
339 2014-09-02 20:41:58 <sipa> do you need 50?
340 2014-09-02 20:42:04 <sipa> if not, use the faucet
341 2014-09-02 20:42:22 <sipa> cpu mining will work on testnet, but it may take a long time already
342 2014-09-02 20:42:56 <tigereye> Unfortunately I've over-used all of teh faucets. They limit per-ip. I need to send a bunch of payments for testing. Even 10 will work
343 2014-09-02 20:43:18 <kindoge> plus they're super dry by now
344 2014-09-02 20:43:30 <tigereye> I was using faucets to withdraw directly to my payment addresses for testing, and that slows my testing down considerably when I need to wait 6hrs to be allowed to mimic another payment
345 2014-09-02 20:43:46 <tigereye> I'm hoping to get a batch so I can send whenever I need to without ip limitations
346 2014-09-02 20:48:07 <sipa> what is testnet difficulty these days?
347 2014-09-02 20:48:12 <tigereye> 1
348 2014-09-02 20:48:24 <tigereye> ...which is why I came in here curious about why I can't generate a block with CPU
349 2014-09-02 20:48:46 <sipa> testnet has a special rule that allows a diff1 block after 20 minutes
350 2014-09-02 20:48:47 <kindoge> 524,420.54, 1, 1,1,1,1
351 2014-09-02 20:48:49 <kindoge> last 6 blocks
352 2014-09-02 20:53:30 <sipa> ;;help genrate
353 2014-09-02 20:53:31 <gribble> (genrate <hashrate> [<difficulty>]) -- Calculate expected bitcoin generation rate using <hashrate> Mhps, at current difficulty. If optional <difficulty> argument is provided, expected generation time is for supplied difficulty.
354 2014-09-02 20:53:53 <gribble> The expected generation output, at 1400000.0 Mhps, given difficulty of 524420.54, is 1342.56587853 BTC per day and 55.9402449387 BTC per hour.
355 2014-09-02 20:53:53 <sipa> ;;genrate 1400000 524420.54
356 2014-09-02 20:54:10 <sipa> kindoge: ^
357 2014-09-02 21:13:08 <tigereye> ;;genrate 3.9 1
358 2014-09-02 21:13:09 <gribble> The expected generation output, at 3.9 Mhps, given difficulty of 1.0, is 1961.33541408 BTC per day and 81.72230892 BTC per hour.
359 2014-09-02 21:46:20 <gribble> The expected generation output, at 27.0 Mhps, given difficulty of 1.0, is 13578.4759436 BTC per day and 565.769830985 BTC per hour.
360 2014-09-02 21:46:20 <tigereye> ;;genrate 27 1
361 2014-09-02 21:52:50 <jtimon> tigereye maybe you can use regtets instead of testnet for your tests?
362 2014-09-02 21:53:03 <jtimon> regtest
363 2014-09-02 23:18:54 <mr_burdell> how does the difficulty calculation work in testnet?  couldn't you set your clock forward by 10 minutes to get a more favorable chance of mining testnet blocks?
364 2014-09-02 23:19:07 <sipa> yes
365 2014-09-02 23:19:38 <sipa> the diff1 rule isn't intended to be secure or anything
366 2014-09-02 23:20:02 <mr_burdell> ok... probably why I wasn't getting any blocks either like tigereye
367 2014-09-02 23:20:22 <mr_burdell> I mined a couple weeks ago on testnet for about 4 hours with 35GH and didn't get any blocks
368 2014-09-02 23:20:25 <sipa> you're saying this is being exploited?
369 2014-09-02 23:20:38 <sipa> it should be obvious if you look at the timestamps
370 2014-09-02 23:21:32 <mr_burdell> I didn't really pay much attention to it... ended up getting faucet coins
371 2014-09-02 23:23:10 <phantomcircuit> sipa, the 10 minute rule is actively being exploited but i cant imagine extensively enough to cause a problem
372 2014-09-02 23:23:21 <sipa> 20 minute rule?
373 2014-09-02 23:23:34 <phantomcircuit> whatever it is
374 2014-09-02 23:23:47 <phantomcircuit> i always set my clock forward 10 minutes and it worked
375 2014-09-02 23:28:28 <mr_burdell> ah... my testnet server is running without a wallet, so I guess I can't test it at the moment
376 2014-09-02 23:30:28 <Luke-Jr> mr_burdell: mining doesn't use/need the wallet
377 2014-09-02 23:31:14 <mr_burdell> when I run "help", I don't see the setgenerate option
378 2014-09-02 23:31:44 <mr_burdell> was that changed?
379 2014-09-02 23:34:44 <sipa> the built-in miner requires a wallet yes, otherwise it wouldn't know to which key to send
380 2014-09-02 23:49:05 <Luke-Jr> using the built-in miner for anything is IMO stupid
381 2014-09-02 23:49:23 <Luke-Jr> even for testnet, it makes more sense to use a dedicated CPU miner
382 2014-09-02 23:50:46 <sipa> for regtest it's fine :)
383 2014-09-02 23:51:27 <Luke-Jr> sipa: yeah, regtest is the only case it makes sense :P