1 2012-01-31 00:00:10 <gmaxwell> etotheipi_: I don't think there is substantial developer disagreement on anything, go look at luke's table.
  2 2012-01-31 00:00:21 <etotheipi_> where is it?
  3 2012-01-31 00:00:32 <etotheipi_> and to be fair... all I've heard is substantial disagreement
  4 2012-01-31 00:00:53 <gmaxwell> etotheipi_: you should be on it too, https://en.bitcoin.it/wiki/P2SH_Votes
  5 2012-01-31 00:01:40 <etotheipi_> gmaxwell, I am honored to be invited to vote on it, but I have no understanding of any of the proposals to be able to distinguish them
  6 2012-01-31 00:01:46 <gmaxwell> (I tried to beg off of it, fwiw, but luke is using a reasonably-informed-technical-folks criteria, you qualify I think)
  7 2012-01-31 00:01:52 <etotheipi_> (except for the OP_EVAL=skynet comment... that felt pretty accurate)
  8 2012-01-31 00:02:39 <poiuh> tempest in a teacup
  9 2012-01-31 00:02:57 <etotheipi_> wow, interesting to see how much everyone has turned against OP_EVAL
 10 2012-01-31 00:03:08 <etotheipi_> considering how close it was to implementation
 11 2012-01-31 00:03:53 <poiuh> the change seems to add significant value to bitcoin... if i were betting tho on a prediction market, i dont see the miners approving it because they dont use multi-sig and from their view the regret of a destablizing change isn't worth it.. game theory
 12 2012-01-31 00:04:07 <gmaxwell> etotheipi_: Absent a less skynetish option I'd still support it. (I guess that means I really should be weak by that criteria?)
 13 2012-01-31 00:04:14 <poiuh> i favor the change.. but the miners arent seeing demand from their "customers" for it, so they dont want to change
 14 2012-01-31 00:04:34 <gmaxwell> poiuh: nah, dunno where you're getting that from.
 15 2012-01-31 00:04:52 <gmaxwell> poiuh: most people mining are just not well informed/ aren't even aware. We don't communicate well.
 16 2012-01-31 00:05:00 <etotheipi_> I'll tell you one thing... once any kind of multi-sig is implemented... I'm going to on the ball with two-factor-auth...
 17 2012-01-31 00:05:41 <poiuh> hidebound reactionaries who dont want to embrace the future!
 18 2012-01-31 00:06:00 <etotheipi_> gmaxwell, I don't remember if I ever got an answer or not... do you know if alternate hashcodes are "non-standard" or completely disabled?
 19 2012-01-31 00:06:13 <etotheipi_> I have some other things I want to see implemented, that are much easier with this hashcodes
 20 2012-01-31 00:06:15 <poiuh> the change is ingenious.. a reliable multisig is significant added capability to bitcoin
 21 2012-01-31 00:06:24 <gmaxwell> etotheipi_: so go mark yourself there as no on No P2SH ever and leave the rest blank if you don't want to have an opinion?
 22 2012-01-31 00:06:42 <gmaxwell> etotheipi_: I think they'd fail isstandard, yes.
 23 2012-01-31 00:06:49 <theymos> I'd probably prefer an OP_EVAL-like solution over 16 or 17 if I was sure it was safe. One idea I had was to require users of OP_EVAL to specify the maximum number of sigops used by the serialized script. Then you could always predict the max number of sigops in the tx. Would this be enough?
 24 2012-01-31 00:06:50 <gmaxwell> etotheipi_: whats your interest there?
 25 2012-01-31 00:07:27 <gmaxwell> theymos: you couldn't tell if they violated that or not without actually going in and executing the script and then finding out the bad news.
 26 2012-01-31 00:07:28 <etotheipi_> gmaxwell, I'm interested to start buyer-seller escrow handling into Armory....
 27 2012-01-31 00:07:57 <theymos> gmaxwell: Then the tx would be rejected and you wouldn't have done more sigops than the maximum specified.
 28 2012-01-31 00:07:59 <etotheipi_> make no mistake... it would need quite a bit of planning and hand-holding to get it "right," but I want to do it
 29 2012-01-31 00:08:58 <etotheipi_> isn't there a way to implement a "global" script-op counter that increments on every op-code, regardless of whether it's inside another script?  kind of sandboxing the script engine
 30 2012-01-31 00:09:09 <gmaxwell> theymos: right but it limits different execution engine styles, because they all have to be able to execute in that manner where they cut out. (e.g. I would expect this to limit JIT compilation, for example)
 31 2012-01-31 00:09:17 <etotheipi_> if that counter ever reaches x, it stops and returns invalid
 32 2012-01-31 00:09:25 <gmaxwell> etotheipi_: you can do that only if you presuppose a very particular execution style.
 33 2012-01-31 00:09:30 <poiuh> at some point, the script will simply need to append a machine-checkable proof that it can be eecuted in linear time
 34 2012-01-31 00:10:03 <gmaxwell> poiuh: we have that with script as is. because it doesn't have anything that could keep it from otherwise. And part of not doing OP_EVAL is keeping it that way.
 35 2012-01-31 00:11:05 <gmaxwell> theymos: I'd point out that with limitations in place OP_EVAL is hardly more expresive than BIP16/BIP17 ... it's really only exciting in full skynet mode. :-/
 36 2012-01-31 00:11:22 <poiuh> a proof-carrying script allows you to have arbitrary complexity in the script
 37 2012-01-31 00:12:09 <gmaxwell> poiuh: yea great now you just have to have all implementations correctly and reliably create and read the proofs.. plus the overhead of sending the proof... on a protocol we're we're absolutely trying to shave every byte.
 38 2012-01-31 00:12:39 <poiuh> this is good because you might want to post a bounty for solving some difficult optimization problem (for instance, intel wants to optimize some instruction, they offload it to the bitcoin cloud to solve the problem)
 39 2012-01-31 00:12:53 <gmaxwell> poiuh: you don't need to do this inside transactions.
 40 2012-01-31 00:13:00 <theymos> gmaxwell: Yeah, it's probably more than the system needs and too much of a risk. The idea interests me, though. Maybe it can be done in the next version of Script.
 41 2012-01-31 00:13:30 <gmaxwell> poiuh: https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked
 42 2012-01-31 00:13:33 <poiuh> shaving bytes.. unfortunately it doesn't work at webscale unless you can get a super-polynomial reduction in size
 43 2012-01-31 00:13:43 <gmaxwell> theymos: yes, I'd like to keep it as an idea for the future for sure.
 44 2012-01-31 00:14:57 <poiuh> intel doesn't know the answer to the optimization problem ahead of time
 45 2012-01-31 00:15:06 <poiuh> so they want the bitcoin supercomputer to solve it for them
 46 2012-01-31 00:15:28 <gmaxwell> poiuh: Thats not how bitcoin works.
 47 2012-01-31 00:15:55 <gmaxwell> poiuh: and please read my why_hash_locked, you can do payment contingent on computation without putting crazy stuff in script.
 48 2012-01-31 00:16:01 <poiuh> zero-knowledge proof is very useful here
 49 2012-01-31 00:17:12 <gmaxwell> poiuh: There is a super-linear function mapping chain size/complexity relative to Kryder's Law/Moore's Law to bitcoin's decentralization.  We don't actually know this function, but it's reasonable to assume that fairly modest changes in
 50 2012-01-31 00:17:13 <poiuh> but that is just a roundabout way of embedding the criteria in the script
 51 2012-01-31 00:17:22 <gmaxwell> the cost of maintaining the chain may have big decentralization impacts.
 52 2012-01-31 00:17:37 <gmaxwell> It's in the interest of all bitcoin users to maintain very high decenteralization.
 53 2012-01-31 00:17:49 <poiuh> indeed
 54 2012-01-31 00:18:10 <gmaxwell> Because all real nodes must completely validate the scripts, it's super important to keep the complexity and size low.
 55 2012-01-31 00:18:47 <gmaxwell> So e.g. doing the hash locked thing to tie payment to an external zero-knowledge proof is good... because it just makes nodes do a hash operation which is very cheap.
 56 2012-01-31 00:19:04 <gmaxwell> Actually having them walk through some big proof, even if its in P time, is not a good idea.
 57 2012-01-31 00:19:39 <poiuh> in the future there will be some pruning function that chops the base of the tree off (based on some pseudo hashpower-voting process)
 58 2012-01-31 00:20:18 <gmaxwell> Hmph anyone know where the paper is that proves PSPACE ??? IP ? I should link it from there.
 59 2012-01-31 00:20:59 <gmaxwell> poiuh: probably, but it would still have to be _deeply_ burried at that point so there was no ambiguity of the identity of the real chain.
 60 2012-01-31 00:21:20 <gmaxwell> I'd want the whole process to include things like publication in newspapers and such. probably a year lag at a minimum.
 61 2012-01-31 00:23:19 <gmaxwell> poiuh: but ignore the storage cost.. runtime bandwidth and cpu still cost, and we want there to be as many full nodes as we can have. If we outpace computer scaling then we'll lose decentralization... and without that bitcoin is kind of pointless.
 62 2012-01-31 00:23:44 <poiuh> youre right
 63 2012-01-31 00:26:24 <etotheipi_> gmaxwell, I updated BIP 0010, do you mind looking at it and verifying it matches what you were expecting?  https://en.bitcoin.it/wiki/BIP_0010
 64 2012-01-31 00:26:54 <poiuh> gmaxwell is a genius
 65 2012-01-31 00:27:03 <poiuh> this zero knowledge proof scheme is awesome
 66 2012-01-31 00:28:04 <theymos> "But we don't trust each other at all, and because we're computer geeks we have no friends who can act as trusted mediators." LOL
 67 2012-01-31 00:29:16 <poiuh> yeah zkp is great.. i would like to see intel offload their next chip optimization problem onto the bitcoin cloud
 68 2012-01-31 00:29:59 <poiuh> miners could switch between bounties and standard mining depending on the prices
 69 2012-01-31 00:35:19 <copumpkin> amiller: how do I interpret http://blockchain.info/double-spends ?
 70 2012-01-31 00:35:24 <copumpkin> does the second one mean it was accepted?
 71 2012-01-31 00:35:44 <amiller> yeah, the first one was in a block that became orphaned
 72 2012-01-31 00:35:50 <copumpkin> yeah
 73 2012-01-31 00:35:59 <copumpkin> but the second one seems disturbing?
 74 2012-01-31 00:37:09 <poiuh> maybe someone had 2 clients running with the same wallet
 75 2012-01-31 00:37:27 <amiller> well the two spends were a month apart
 76 2012-01-31 00:37:37 <amiller> http://blockchain.info/block-height/155181
 77 2012-01-31 00:37:44 <amiller> here's a view of the two alternate blocks for 155181
 78 2012-01-31 00:38:14 <amiller> you can see that one of them has no next block
 79 2012-01-31 00:38:26 <copumpkin> OH
 80 2012-01-31 00:38:32 <copumpkin> I see
 81 2012-01-31 00:38:34 <amiller> there's like a branch
 82 2012-01-31 00:38:45 <amiller> 155179, then there are two versions of 155180, two versions of 155181, and then only one version of 155182
 83 2012-01-31 00:38:49 <copumpkin> yeah, nevermind
 84 2012-01-31 00:39:07 <amiller> so for a while there were two blocks worth of fork
 85 2012-01-31 00:39:13 <amiller> what i'm not sure of is what happens to those transactions
 86 2012-01-31 00:39:25 <amiller> like if they saw the tx in one of the blocks but then the block is canceled
 87 2012-01-31 00:39:30 <amiller> does the tx continue to get relayed
 88 2012-01-31 00:39:45 <copumpkin> it'd be unfortunate if not
 89 2012-01-31 00:40:17 <amiller> well it must be the case that it doesn't in some cases, because there was a valid transaction in a block that became orphaned
 90 2012-01-31 00:40:21 <amiller> and it never got put in a later block
 91 2012-01-31 00:43:23 <theymos> Miners put orphaned transactions back in the memory pool, but they don't relay it again.
 92 2012-01-31 00:53:38 <amiller> i'm still trying to trace through exactly what happened to that transaction, i don't quite follow yet
 93 2012-01-31 00:58:26 <pingdrive> pretty much
 94 2012-01-31 01:02:08 <amiller> so if that transaction was orphaned, and left in the miner's memory pool, when would it be removed from the memory pool?
 95 2012-01-31 01:06:46 <amiller> roconnor, did you write the EcDsaSecp256k1, the sha256, and the ripemd implementations in Purecoin
 96 2012-01-31 01:08:07 <roconnor> amiller: yes
 97 2012-01-31 01:08:15 <roconnor> do you need licence to them?
 98 2012-01-31 01:08:31 <amiller> not atm
 99 2012-01-31 01:08:45 <amiller> i imagine that's quite useful though
100 2012-01-31 01:09:04 <amiller> i've learned a ton from following your code
101 2012-01-31 01:09:25 <roconnor> good, that was the point
102 2012-01-31 01:09:41 <roconnor> warning though, it isn't entirely correct yet
103 2012-01-31 01:10:33 <amiller> also really enjoyed the 3 part talk you gave with bas spitters
104 2012-01-31 01:10:44 <roconnor> :)
105 2012-01-31 01:31:56 <BlueMatt> gmaxwell: gavin noted that "I've also been wondering if it is time to remove the IRC bootstrapping
106 2012-01-31 01:33:44 <gmaxwell> Yes, I guess I should.
107 2012-01-31 01:34:39 <gmaxwell> poiuh: Zero knowledge contingent payments are not my invention, though I don't know where anyone else wrote about them. I'm pretty sure satoshi had them in mind as a possible use of bitcoin when it wrote it.
108 2012-01-31 01:34:43 <gmaxwell> BlueMatt: I would use more words.
109 2012-01-31 01:36:41 <BlueMatt> gmaxwell: yea, that
110 2012-01-31 01:47:01 <BlueMatt> were those tor fixes for nolisten if tor pushed in 0.5.2?
111 2012-01-31 01:57:53 <gmaxwell> BlueMatt: thanks.
112 2012-01-31 01:57:54 <gmaxwell> posted
113 2012-01-31 02:01:53 <gmaxwell> (and hey, I included code with my post)
114 2012-01-31 02:04:26 <BlueMatt> nice
115 2012-01-31 02:08:31 <BlueMatt> does irc go over the proxy?
116 2012-01-31 02:36:42 <poiuh> wheres the secret bitcoin chan
117 2012-01-31 02:37:15 <gmaxwell> I'd like any feedback people here have about this message: https://bitcointalk.org/index.php?topic=61922.msg723476#msg723476
118 2012-01-31 02:40:06 <splatster> gmaxwell: Reading...
119 2012-01-31 02:41:34 <Graet> phew, once again gmaxwell the voice of reason - good work :)
120 2012-01-31 02:44:20 <splatster> Good read
121 2012-01-31 02:44:53 <roconnor> gmaxwell: I think it is an election
122 2012-01-31 02:45:16 <roconnor> sort of
123 2012-01-31 02:47:15 <etotheipi_> is Joric here?
124 2012-01-31 02:47:19 <roconnor> gmaxwell: if a super-majority even 100% of the current miners decide that the subsidy should be 50 BTC forever then the original bitcoin is destroyed because there isn't sufficent power to secure the "real" network. and the only viable network is the 50 BTC forever network
125 2012-01-31 02:47:33 <gmaxwell> roconnor: Some bitcoin users might decide to use elections to help them make decisions about what software they'll run if they want to subject themselves to the benefits and costs of that kind of decision making but bitcoin itself? It's not, as I point out, you can't change the rules by having more miners.
126 2012-01-31 02:47:59 <gmaxwell> roconnor: nah, you've just created an enormous economic incentive to switch sides (or get into the mining business).
127 2012-01-31 02:48:13 <roconnor> ya, you could be right
128 2012-01-31 02:48:52 <gmaxwell> roconnor: what you're suggesting implies that there is some big moat around being a miner. Maybe that someday becomes true? if so.. yea, we'll lose our autonomy and maybe it will then really be controled by some closed clique of miners. But thats not the vision at least.
129 2012-01-31 02:49:25 <roconnor> gmaxwell: heh, well as you know, that's clique of miners is what I expect the future of bitcoin to be.
130 2012-01-31 02:50:30 <roconnor> gmaxwell: so what happens to all the users that refuse to adopt BIP 16?
131 2012-01-31 02:50:34 <gmaxwell> It's not an inevitability. It will be up to the users of bitcoin.  (and I hope to continue to remind people of this to reduce that consolidation)
132 2012-01-31 02:50:52 <roconnor> gmaxwell: under the assumption that BIP 16 "passes"
133 2012-01-31 02:51:09 <gmaxwell> roconnor: BIP16 still validates under the old rules. They can't participate in BIP16 transaction, but .. nothing much. Unless they're mining.
134 2012-01-31 02:52:11 <gmaxwell> roconnor: I also don't believe such users actually exist. Ignoring people who are exagerating their true positions because open decision making encourages doing so, I don't see that kind of opposition to it.
135 2012-01-31 02:52:18 <roconnor> oh right, miners refuse to accept thier bizarre conflicing BIP 16 transactions.
136 2012-01-31 02:52:46 <roconnor> (in the unlikely case they want to spend a transaction that happens to look like a BIP 16 transaction)
137 2012-01-31 02:52:57 <BlueMatt> paraipan: your comment is wrong
138 2012-01-31 02:53:00 <BlueMatt> flat out wrong
139 2012-01-31 02:53:22 <paraipan> yea
140 2012-01-31 02:53:23 <paraipan> so ?
141 2012-01-31 02:53:34 <paraipan> it's what think
142 2012-01-31 02:53:48 <BlueMatt> first of all "Pool owners have the biggest incentives to keep the network running smoothly"
143 2012-01-31 02:53:49 <BlueMatt> really???
144 2012-01-31 02:53:51 <BlueMatt> wtf?
145 2012-01-31 02:53:51 <roconnor> gmaxwell: I guess BIP 16 and 17 are not incompatible then.
146 2012-01-31 02:53:52 <paraipan> post your thinking too
147 2012-01-31 02:54:25 <gmaxwell> roconnor: Correct. Thoug you'd agree that having both would be quite unfortunate from a perspective of making the code easy to understand and impliment.
148 2012-01-31 02:55:49 <gmaxwell> (Luke agrees with that position too)
149 2012-01-31 02:56:36 <theymos> Nice forum post, gmaxwell. I added a quote from it to the ad rotation. :)
150 2012-01-31 02:57:07 <theymos> "Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what."
151 2012-01-31 02:59:58 <roconnor> gmaxwell: what happens when BIP 16 gets say 70% mining support; some new clients are deployed, and for whatever reason mining support drops below 50% with a mix of old and new clients?
152 2012-01-31 03:00:37 <BlueMatt> then the miners who push a chain with invalid bip16 txes gets ignore by people who have upgraded and used by those who dont
153 2012-01-31 03:00:40 <BlueMatt> s/dont/havent/
154 2012-01-31 03:00:52 <BlueMatt> the splits would make the network ugly, but...
155 2012-01-31 03:01:34 <etotheipi_> splatster, I just realized what's wrong with the compile I recommended earlier
156 2012-01-31 03:01:42 <splatster> What?
157 2012-01-31 03:02:20 <etotheipi_> splatster, add libcryptopp.a to the end of the OBJS line (line 7)
158 2012-01-31 03:02:20 <gmaxwell> 12:38 <@gmaxwell> Moron__: but they aren't safe to use unless a majority of all future hash power enforces the rules.
159 2012-01-31 03:02:23 <gmaxwell> 12:42 <@gmaxwell> but thats if and only if they deploy code for one of BIP16/BIP17 and the majority of future hashpower deploys the other.
160 2012-01-31 03:02:27 <gmaxwell> roconnor: notice my use of the word future? :)
161 2012-01-31 03:02:40 <gmaxwell> roconnor: yea, kinda sucks. We're using a current majority as a proxy for the future.
162 2012-01-31 03:02:46 <gmaxwell> roconnor: but thats not a promise.
163 2012-01-31 03:03:10 <splatster> etotheipi_: "make: *** No rule to make target `libcryptopp.a', needed by `swig'.  Stop."
164 2012-01-31 03:03:13 <gmaxwell> roconnor: presumably interest in not having it all go pearshaped (and the reference client shipping with the functionality) will make that true.
165 2012-01-31 03:03:34 <etotheipi_> splatster, oh that wasn't the right place to put it
166 2012-01-31 03:04:07 <splatster> ok
167 2012-01-31 03:04:11 <etotheipi_> splatster, sorry, undo what you just did... instead add that to line 31 just before CppBlockUtils_wrap.o
168 2012-01-31 03:04:47 <luke-jr> roconnor: Can you verify I represented your position(s) correctly? https://en.bitcoin.it/wiki/P2SH_Votes
169 2012-01-31 03:04:51 <splatster> same thing
170 2012-01-31 03:05:14 <etotheipi_> gah
171 2012-01-31 03:06:07 <roconnor> luke-jr: hmm, I think I might prefer to be left off the list if that is okay with you.
172 2012-01-31 03:06:19 <etotheipi_> splatster, same error?
173 2012-01-31 03:06:24 <splatster> yep
174 2012-01-31 03:06:38 <splatster> and when I take that out it gives me the old error
175 2012-01-31 03:06:51 <etotheipi_> uhh... then you put it in the wrong place... put it on the "g++" line, not the "swig" line
176 2012-01-31 03:06:54 <luke-jr> roconnor: it's not for any formal use, just to keep track of where people stand
177 2012-01-31 03:07:11 <roconnor> I think my position is too nuanced to be captured easily
178 2012-01-31 03:07:43 <splatster> i686-apple-darwin11-llvm-g++-4.2: libcryptopp.a: No such file or directory
179 2012-01-31 03:08:13 <luke-jr> roconnor: that's why it's a complicated table? :P
180 2012-01-31 03:08:41 <etotheipi_> splatster, I thought you had copied the .a file to the cppForSwig dir
181 2012-01-31 03:09:08 <roconnor> gmaxwell: thanks
182 2012-01-31 03:09:12 <splatster> I did, but MacPorts got rid of it I think
183 2012-01-31 03:09:40 <etotheipi_> okay, well change it to /opt/local/whatever/libcryptopp.a
184 2012-01-31 03:10:52 <splatster> ld: library not found for -lcryptopp
185 2012-01-31 03:11:18 <etotheipi_> gah!  remove that -lcryptopp ...
186 2012-01-31 03:11:32 <splatster> Woah
187 2012-01-31 03:11:34 <splatster> much worse
188 2012-01-31 03:11:57 <splatster> Maybe about 300 lines of errors
189 2012-01-31 03:12:04 <etotheipi_> okay, nm then
190 2012-01-31 03:12:13 <etotheipi_> undo everything, and wait for someone with more OSX experience :)
191 2012-01-31 03:12:33 <splatster> going to first error
192 2012-01-31 03:12:37 <splatster> Undefined symbols for architecture x86_64:
193 2012-01-31 03:12:38 <splatster> "_Py_InitModule4_64", referenced from:
194 2012-01-31 03:12:44 <splatster> _init_CppBlockUtils in CppBlockUtils_wrap.o
195 2012-01-31 03:12:45 <splatster> and a lot more like that
196 2012-01-31 03:13:00 <etotheipi_> oooh, splatster
197 2012-01-31 03:13:06 <etotheipi_> that might be an improvement, actually
198 2012-01-31 03:13:31 <etotheipi_> contrary to what it looks like:  it may have actually succeeded... allowing the compiler to move on and hit all the other errors it would've hit before
199 2012-01-31 03:14:01 <etotheipi_> that looks like linker errors against the compiled python module
200 2012-01-31 03:14:02 <splatster> Wait is the system that you compiled those files on 32 or 64 bit?
201 2012-01-31 03:14:16 <etotheipi_> splatster, I didn't give you any compiled modules
202 2012-01-31 03:14:27 <etotheipi_> I only gave you a .py and a .cpp
203 2012-01-31 03:14:33 <etotheipi_> which is what swig produces
204 2012-01-31 03:14:38 <splatster> ok
205 2012-01-31 03:14:39 <etotheipi_> err... *.cxx
206 2012-01-31 03:15:24 <etotheipi_> it looks like it might've succeeded at linking to cryptopp, but the compiling of the swig files I gave you didn't work so well...
207 2012-01-31 03:15:55 <etotheipi_> just in case:  http://www.mail-archive.com/cryptopp-users@googlegroups.com/msg05748.html
208 2012-01-31 03:16:59 <splatster> Different problems
209 2012-01-31 03:17:34 <etotheipi_> it talks about linking to cryptopp on OSX.... even if what I gave you worked for cryptopp, it's kind of a hack
210 2012-01-31 03:20:04 <splatster> the symbol "_Py_InitModule4_64" isn't related to cryptopp
211 2012-01-31 03:20:12 <etotheipi_> splatster, I agree...
212 2012-01-31 03:20:23 <splatster> nor is _PyModule_GetDict or _PyCObject_Import or _PyErr_Occurred
213 2012-01-31 03:20:36 <splatster> It's python
214 2012-01-31 03:20:58 <etotheipi_> splatster, I'm going back to the previous problem and trying to make sure it's done right
215 2012-01-31 03:21:12 <etotheipi_> I recognize that this new problem is different
216 2012-01-31 03:21:27 <etotheipi_> on that topic, there might be discussion on this in the forums...
217 2012-01-31 03:21:30 <splatster> Well I will say that almost all the errors are thrown from CppBlockUtils_wrap.o
218 2012-01-31 03:22:05 <etotheipi_> yeah, CppBlockUtils.o should've been compiled with all those symbols, but your system didn't, for some reason
219 2012-01-31 03:39:20 <gmaxwell> BlueMatt: can you take the pool ops motivation discussion out of the BIP16/17 thread?
220 2012-01-31 03:44:34 <splatster> Why is this such a heated argument?
221 2012-01-31 03:45:17 <splatster> Can someone give me an unbiased summary of each and tell me pros and cons and not yell at me for being stupid/uninformed?
222 2012-01-31 03:48:03 <BlueMatt> gmaxwell: sorry, didnt mean to make a side discussion, that comment was just so wrong it had to be pointed out...
223 2012-01-31 03:49:00 <gmaxwell> splatster: I have no idea why anything is heated. I doubt you're stupid.
224 2012-01-31 03:49:07 <luke-jr> splatster: BIP 16 is a quick workaround to a problem with OP_EVAL, by effectively modifying how the entire Bitcoin protocol works in an inconsistent way. BIP 17 just adds a new opcode to accomplish the same thing.
225 2012-01-31 03:49:18 <luke-jr> BIP 16 also allows tweaking the rules more
226 2012-01-31 03:49:41 <luke-jr> but the one case it actually does, is only a long-term problem and has since been solved for BIP 17 too
227 2012-01-31 03:49:48 <BlueMatt> splatster: sadly, at this point I dont think there is anyone qualified to give an unbaised summary
228 2012-01-31 03:50:10 <gmaxwell> splatster: backing up a bit... We want people to be able to have secure wallets even when their computers are compromised and we want people to have the freedom to choose complcated rules for the disposition of their own funds.
229 2012-01-31 03:50:10 <luke-jr> I agree with gmaxwell that this shouldn't be heated.
230 2012-01-31 03:50:43 <gmaxwell> splatster: depending on how we count there have probably been a good two dozen or more specific (and vague) proposals on how to accomplish this end.
231 2012-01-31 03:51:09 <luke-jr> O.O that many?
232 2012-01-31 03:51:21 <splatster> Why must the rules be complicated?
233 2012-01-31 03:51:22 <gmaxwell> luke-jr: if you count things like the OP_CAT multisig.
234 2012-01-31 03:51:58 <luke-jr> splatster: that's why I prefer BIP 17. it's a very simple change.
235 2012-01-31 03:52:15 <gmaxwell> luke-jr: he's referring to my 'freedom to choose comment'
236 2012-01-31 03:52:20 <luke-jr> oh
237 2012-01-31 03:52:34 <gmaxwell> splatster: For example If I want my funds for my charity to be able to be released by the {CEO or 4/5 board members}. I should be able to have an address which embodies this choice.
238 2012-01-31 03:52:40 <splatster> Which one is the simplest that still allows for someone to make a wallet which needs 2 different signatures to be spent?
239 2012-01-31 03:52:42 <luke-jr> splatster: because complicated rules are needed to say "4 of 7 people need to agree to spend money from the corporate wallet"
240 2012-01-31 03:52:43 <gmaxwell> splatster: and people should be able to pay directly into it.
241 2012-01-31 03:52:53 <gmaxwell> splatster: They're all equally powerful in that respect.
242 2012-01-31 03:53:07 <luke-jr> splatster: BIP 17 is easily the simplest.
243 2012-01-31 03:53:09 <splatster> Holy shit I don't think I've ever gotten this many highlights so fast
244 2012-01-31 03:53:11 <luke-jr> lol
245 2012-01-31 03:53:24 <gmaxwell> BIP12 went much further but the general belief is that it was too powerful a tool.
246 2012-01-31 03:53:31 <gmaxwell> As I joked earlier, BIP12 == Skynet.
247 2012-01-31 03:53:48 <gmaxwell> (The fictional AI in the terminator movies that enslaved mankind)
248 2012-01-31 03:53:56 <luke-jr> I wouldn't mind BIP 12. I'd just miss the opportunity to change more rules when deploying it
249 2012-01-31 03:54:06 <luke-jr> like pubkey extraction etc
250 2012-01-31 03:54:34 <gmaxwell> BIP12 may comeback someday. Who knows. We seem to be screwing up the politics on the much narrower change. :(
251 2012-01-31 03:56:09 <luke-jr> splatster: I say BIP 17 is simpler, but *if it didn't change other script rules*, BIP 16 would probably be simpler to implement *for Bitcoin-Qt*, the most-used client right now
252 2012-01-31 03:56:14 <luke-jr> just to clarify that
253 2012-01-31 03:56:15 <splatster> I think there should be between 1 and a certain number of valid keys capable of signing a transaction from a specific address and based on that wallet itself, a certain number of those keys would be required.
254 2012-01-31 03:56:34 <luke-jr> splatster: these P2SH solutions allow any complexity just as easily
255 2012-01-31 03:56:58 <gmaxwell> splatster: from an enduser perspected everything being discussed is absoltely equal. They'd all have the same functionality. The differences are technical, technical-aesthetic, and security paranoia related.
256 2012-01-31 03:57:08 <poiuh> the hash of the redeeming script.. what if you want to use the same redeeming script multiple times. is the hash alreay known? or does the hash include the whole tx
257 2012-01-31 03:57:22 <luke-jr> poiuh: the redeeming script isn't secret
258 2012-01-31 03:57:32 <gmaxwell> poiuh: you can reuse it. It's just like paying to the same address multiple times.
259 2012-01-31 03:57:50 <gmaxwell> Before the first time the pubkey isn't known, after that .. it is. But you can still use it.
260 2012-01-31 03:57:52 <luke-jr> poiuh: the redeeming script is expected to do any pubkey/signature verification
261 2012-01-31 03:58:03 <poiuh> i c
262 2012-01-31 03:59:57 <splatster> If BIP17 is implemented, who gets seen as a misbehaving node, what happens to the two sets of nodes' blockchains, and how anything with the new OP_insertoperationhere(s) look to an older client? What about for BIP16?
263 2012-01-31 04:00:18 <luke-jr> splatster: old clients cannot send/receive P2SH under any conditions
264 2012-01-31 04:00:31 <poiuh> the redeeming script should have some added operations each time, to ensure privacy. so that ppl cant data-mine the hashes
265 2012-01-31 04:00:39 <splatster> Not even relay?
266 2012-01-31 04:00:42 <splatster> not verify?
267 2012-01-31 04:01:05 <luke-jr> poiuh: you'll want to replace the pubkey in the redeeming script
268 2012-01-31 04:01:11 <luke-jr> splatster: correct
269 2012-01-31 04:01:32 <splatster> So all of the newer clients/their blocks and TXs are seen as misbehaving to any old client?
270 2012-01-31 04:01:36 <luke-jr> no
271 2012-01-31 04:01:42 <luke-jr> they are all seen as always-valid
272 2012-01-31 04:02:15 <splatster> So how do the old clients respond to the new stuff?
273 2012-01-31 04:02:19 <luke-jr> worst case scenario, an *old client* sees *1 confirmation* for a false transaction
274 2012-01-31 04:02:26 <poiuh> its good from a privacy pov to use a script hash. that way you dont tip your hand as to what type of payout scheme is going on. in fact, everyone should start using the script hash instead of the standard pubkey thing so that all tx's are masked
275 2012-01-31 04:02:43 <luke-jr> but that attack would be super-expensive, and best practice is to wait for 4-6 confirms
276 2012-01-31 04:03:04 <luke-jr> poiuh: you have to reveal the script when you spend
277 2012-01-31 04:03:14 <poiuh> sure later on
278 2012-01-31 04:03:48 <poiuh> gives you some time in between various stages of a transaction to protect yourself
279 2012-01-31 04:04:08 <luke-jr> I suppose script secrecy could be a good thing for law enforcement
280 2012-01-31 04:24:16 <poiuh> http://www.mendeley.com/research/a-simple-publicly-verifiable-secret-sharing-scheme-and-its-application-to-electronic-voting/
281 2012-01-31 04:26:50 <poiuh> in the future there will be inputless transactions
282 2012-01-31 04:27:16 <poiuh> ppl will share secrets offline, and the last user in the chain will be able to redeem the whole thing
283 2012-01-31 04:29:33 <poiuh> if anyone double spends, another user can reveal the secret and quash the spender
284 2012-01-31 04:29:52 <poiuh> it all becomes private ledgers, enforceable by the threat of revealing the secret
285 2012-01-31 04:30:31 <josephcp> that doesn't work for financial transactions because you can still double spend
286 2012-01-31 04:30:46 <josephcp> give one signed chain to one person and another to a second
287 2012-01-31 04:31:17 <josephcp> neither has an assurance that there is no double spending without a broadcast to all parties
288 2012-01-31 04:32:11 <josephcp> i can definitely see it working for voting though, because there is a single end expiration state where everything is synchronized
289 2012-01-31 04:32:40 <poiuh> all the parties involved have the ability to verify every output (but that information is on a need-to-know basis, it's not published to the whole network)
290 2012-01-31 04:33:04 <poiuh> that is, dont accept a promise unless you have the ability to verify every other output from tha tsource.. he would give you the key privately
291 2012-01-31 04:33:34 <josephcp> yes but it's still open to double spending attacks because it's on a need-to-know basis
292 2012-01-31 04:33:47 <poiuh> youd get cliques of knowledge..
293 2012-01-31 04:34:34 <josephcp> would you be confident enough to receive $1000 in exchange for selling goods with such a system?
294 2012-01-31 04:34:34 <poiuh> as long as the dependent outputs later in the chain remain within the clique, the network at large doesn't need to know
295 2012-01-31 04:34:42 <josephcp> if you didn't know the buyer?
296 2012-01-31 04:35:20 <poiuh> sure why not, id have the key to decrypt every output from the buyer
297 2012-01-31 04:35:34 <poiuh> but random guy whose monitoring bitcoin traffic wouldn't
298 2012-01-31 04:36:07 <josephcp> but you don't have any assurance that the buyer didn't already spend the coins to someone else, this system is unworkable for unknown/untrusted parties
299 2012-01-31 04:36:10 <poiuh> dirty/private money would circulate among a trusted clique...
300 2012-01-31 04:36:33 <josephcp> trusted cliques don't build global economies
301 2012-01-31 04:36:36 <poiuh> the prerequisite before transacting with someone is that they give you the key privately to verify every transaction theyve made
302 2012-01-31 04:36:48 <josephcp> but you don't KNOW every transaction they've made is my point
303 2012-01-31 04:37:03 <poiuh> the block chain has every transaction
304 2012-01-31 04:37:18 <poiuh> in this case you can hide the amount and destination from the public
305 2012-01-31 04:37:51 <josephcp> yes the moment you broadcast on the blockchain, your example says you don't have to broadcast transactions
306 2012-01-31 04:39:02 <poiuh> this is an entirely different scheme from bitcoin.. the blockchain contains encrypted messages consisting of (input, destination, amount)
307 2012-01-31 04:39:44 <poiuh> before accepting payment from someone, he gives you the keys to decrypt all the transactions this one depends on
308 2012-01-31 04:39:56 <poiuh> apply recursively...
309 2012-01-31 04:40:22 <josephcp> doesn't work because you can send the key to two people
310 2012-01-31 04:40:37 <josephcp> unless you use the other person's pubkey, but then hey you've just reinvented bitcoin
311 2012-01-31 04:40:55 <poiuh> after a while, huge portions of the chain would be known to everyone, but people who want to remain private would still be able to
312 2012-01-31 04:41:06 <poiuh> you're supposed to send the key to multiple people
313 2012-01-31 04:42:47 <poiuh> as a bitcoin user, you dont need to verify evey transaction in the network. just the ones your incoming payments depend on
314 2012-01-31 04:43:08 <gmaxwell> poiuh: non-inflation is a general interest to all users.
315 2012-01-31 04:43:23 <poiuh> which means you dont have to have any knowledge about those non-dependent transactions.. they can be hidden from you entirely!
316 2012-01-31 04:43:32 <gmaxwell> thats like saying the fed printing money isn't an issue to dollar users, you just need to worry if your own dollars are counterfet. :)
317 2012-01-31 04:43:44 <josephcp> hidden from you => open to attack from double spending
318 2012-01-31 04:43:56 <poiuh> nah
319 2012-01-31 04:44:03 <josephcp> there is no way around this fact
320 2012-01-31 04:44:06 <poiuh> you only need the details of a transaction if your inputs depend on it
321 2012-01-31 04:44:10 <poiuh> very simple
322 2012-01-31 04:44:34 <poiuh> gmaxwell: not sure what you mean.. the supply is determined by the # of blocks
323 2012-01-31 04:45:05 <poiuh> you can have 0 information about any tx, but sitll konw exactly how many bitcoins there are
324 2012-01-31 04:45:10 <gmaxwell> (also because of split/merge the data you'd need to decrypyt a single coin is exponential)
325 2012-01-31 04:45:37 <gmaxwell> poiuh: no, you can't. Say I have 5 bitcoin I pay both you and josephcp. (giving each the history independantly and in secret)
326 2012-01-31 04:45:47 <gmaxwell> poiuh: so then I've created 5 more from thin air.
327 2012-01-31 04:46:06 <gmaxwell> this conversation should move to #bitcoin btw. I'm also in there.
328 2012-01-31 04:46:13 <josephcp> good point
329 2012-01-31 04:46:21 <poiuh> gmaxwell: josephcp would not accept such a tx, because you already gave him a copy of the one you sent to me
330 2012-01-31 04:46:56 <poiuh> you would not be able to append more than 1 tx in a single block
331 2012-01-31 04:47:12 <gmaxwell> poiuh: #bitcoin (I won't respond here)
332 2012-01-31 06:16:59 <ThomasV> sipa: 24h average seems to be screwed at bitcoincharts
333 2012-01-31 06:59:17 <poiuh> more coins
334 2012-01-31 07:54:25 <Joric> does 0.5.99 support getblockbycount ?
335 2012-01-31 07:55:40 <Joric> theymos mentions this thread on the blockexplorer https://bitcointalk.org/index.php?topic=724.0
336 2012-01-31 07:56:40 <Joric> was it considered unecessary or potentially dangerous?
337 2012-01-31 09:03:40 <sipa> ThomasV: what's wrong with it?
338 2012-01-31 09:04:36 <ThomasV> sipa: I see 6.12 usd as 24h average for mtgox
339 2012-01-31 09:05:01 <ThomasV> it should be lower
340 2012-01-31 09:05:03 <Joric> no it's 5.50668
341 2012-01-31 09:05:05 <sipa> eh, that's not my data
342 2012-01-31 09:05:31 <ThomasV> Joric: where do you see that?
343 2012-01-31 09:05:40 <Joric> mtgox com
344 2012-01-31 09:05:43 <ThomasV> UI am talking about http://bitcoincharts.com/markets/
345 2012-01-31 09:06:08 <Joric> omg it's all red
346 2012-01-31 09:06:29 <ThomasV> it looks like averages are lagging
347 2012-01-31 09:07:05 <Joric> where's that 7.22 came from i haven't seen it for two weeks already
348 2012-01-31 09:15:13 <tcatm> ThomasV, Joric: It's calculated from the last 30d so it matches the mini chart
349 2012-01-31 09:15:30 <ThomasV> tcatm: it used to be 24h, no?
350 2012-01-31 09:15:39 <tcatm> yes
351 2012-01-31 09:15:51 <Joric> maybe it looked too scary
352 2012-01-31 09:16:16 <ThomasV> then why don't you move it to the right, with the 30d data
353 2012-01-31 09:18:07 <tcatm> ?
354 2012-01-31 09:18:19 <da2ce7> hello all :)
355 2012-01-31 09:24:00 <gribble> New news from bitcoinrss: phants opened issue 789 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/789>
356 2012-01-31 09:45:58 <tcatm> ThomasV: like so?
357 2012-01-31 09:49:02 <ThomasV> tcatm: idk
358 2012-01-31 09:49:29 <ThomasV> tcatm: changes are confusing
359 2012-01-31 09:49:43 <ThomasV> it was better before
360 2012-01-31 09:50:06 <tcatm> It's always better before ;)
361 2012-01-31 09:50:45 <ThomasV> yes, but this time it's real
362 2012-01-31 09:51:10 <ThomasV> you're making changes without notice, I think it confuses a lot of people
363 2012-01-31 09:52:37 <tcatm> I don't think notices would help much. At least they didn't help in the past because people who are confused usually aren't reading them.
364 2012-01-31 10:06:50 <marf_away> yeah new bitcoincharts is bad
365 2012-01-31 10:07:03 <marf_away> its more difficult to see the action
366 2012-01-31 10:07:12 <marf_away> not its allways red...
367 2012-01-31 10:07:20 <marf_away> becaouse of 30 avaerage
368 2012-01-31 10:07:22 <marf_away> thats useless
369 2012-01-31 10:07:30 <marf_away> @tcatm
370 2012-01-31 10:12:32 <tcatm> What about those people who would prefer to see a more long term view of prices?
371 2012-01-31 10:13:14 <da2ce7> tcatm: high transaction volume in USD at any price... it is more inportant that extanges are very proffitable.
372 2012-01-31 10:14:00 <da2ce7> the price isn't all that inportant for bitcoins health... what is more inportant it liquidity.
373 2012-01-31 10:14:03 <da2ce7> *is
374 2012-01-31 10:14:40 <Eliel> yep, although, unless the different market players start holding smaller amounts, that's difficult to fix.
375 2012-01-31 10:15:02 <marf_away> ok make it optional tcatm
376 2012-01-31 10:15:03 <marf_away> ;D
377 2012-01-31 10:15:08 <Eliel> so, I'd expect the price to go up along with liquidity.
378 2012-01-31 10:16:09 <tcatm> So... 60s averages?
379 2012-01-31 10:16:48 <marf_away> or make a poll
380 2012-01-31 10:16:54 <marf_away> what the users want
381 2012-01-31 10:17:38 <da2ce7> tcatm: why not do the price of the last tx over the 10 min avg max tx volume. but that is a bit of work to do.
382 2012-01-31 10:17:39 <tcatm> Users don't know what they want :)
383 2012-01-31 10:17:53 <tcatm> da2ce7: ???
384 2012-01-31 10:18:21 <tcatm> Can you write that using LaTeX math or something more easily parseable?
385 2012-01-31 10:19:05 <da2ce7> say if over the last 10min's the average largest tx are 100 bitcoins; then display the price of the last tx that was over 100btc.
386 2012-01-31 10:19:29 <marf_away> good idea
387 2012-01-31 10:19:47 <tcatm> Except it could very well be change...
388 2012-01-31 10:20:28 <marf_away> i think he talks about exchanges
389 2012-01-31 10:20:39 <marf_away> price of last big trade of mtgox
390 2012-01-31 10:20:41 <marf_away> and so on
391 2012-01-31 10:21:54 <da2ce7> last 10min max trades of the last 24 hours, and use the avg as the last trade to eclipce.
392 2012-01-31 10:22:21 <da2ce7> so you would have 144 max trades, and take the average of those.
393 2012-01-31 10:22:50 <tcatm> average price, volume., weighted, ...?
394 2012-01-31 10:23:27 <da2ce7> you are taking the 'last' of the last signifant trade in volume.
395 2012-01-31 10:24:09 <da2ce7> that on average will update every 10 min... but maybe longer.
396 2012-01-31 10:24:13 <da2ce7> or quicker.
397 2012-01-31 10:30:29 <tcatm> 24h averages are back
398 2012-01-31 10:34:17 <gjs278> ;;bc,mtgox
399 2012-01-31 10:34:17 <gribble> {"ticker":{"high":5.58275,"low":5.426,"avg":5.496252882,"vwap":5.499613471,"vol":29997,"last_all":5.52454,"last_local":5.48448,"last":5.48448,"buy":5.48468,"sell":5.48645}}
400 2012-01-31 10:34:23 <gjs278> ;;bc,info
401 2012-01-31 10:34:23 <gribble> Error: "bc,info" is not a valid command.
402 2012-01-31 10:34:31 <gjs278> ;;bc,help
403 2012-01-31 10:34:32 <gribble> Alias bc,24hprc, Alias bc,altprofit, Alias bc,avgprc, Alias bc,bcm, Alias bc,bitpenny, Alias bc,blockdiff, Alias bc,blocks, Alias bc,bounty, Alias bc,btceur, Alias bc,btcgbp, Alias bc,btcguild, Alias bc,btcrub, Alias bc,btcto, Alias bc,calc, Alias bc,calcd, Alias bc,channels, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias (2 more messages)
404 2012-01-31 10:35:50 <da2ce7> tcatm: we need a site that has a set of offline 'bitcoin js tools' such like: min private key to full key; private key to bitcoin address; getting a bitcoin address from a private key; generating a private key from a string.
405 2012-01-31 10:36:14 <da2ce7> or a trusted https website that you can use them from.
406 2012-01-31 10:36:30 <da2ce7> (no private data getting sent over the interent)
407 2012-01-31 10:36:59 <sipa> please don't advocate https sites for dealing with private keys
408 2012-01-31 10:37:04 <sipa> they should never leave your own system
409 2012-01-31 10:38:04 <da2ce7> sipa: I agree.. however for a 1 btc casascis coin it is 'ok' secuirty; as you would import the key as a 'sweep address'
410 2012-01-31 10:38:13 <tcatm> A few shell scripts operating on stdin/out should work.
411 2012-01-31 10:38:35 <tcatm> scripts/commands
412 2012-01-31 10:38:48 <Joric> da2ce7, https://www.bitaddress.org
413 2012-01-31 10:38:53 <UukGoblin> why does blockexplorer show a single transaction with multiple inputs as multiple entries in the address's ledger view? http://blockexplorer.com/address/1FGNrRbpWkqwYz9rWXR8UD2boHVfkLgeQg
414 2012-01-31 10:39:44 <Joric> da2ce7, note 'Enter Private Key (any format)'
415 2012-01-31 10:39:53 <da2ce7> ya cool
416 2012-01-31 10:40:09 <da2ce7> hmmm there is a bug in my windows... it take forever to load https pages...
417 2012-01-31 10:40:11 <da2ce7> :S
418 2012-01-31 10:40:21 <da2ce7> very werid
419 2012-01-31 10:40:44 <da2ce7> only when i visit them the first time tho...
420 2012-01-31 10:41:23 <UukGoblin> da2ce7, slow connection to Certificate Authority?
421 2012-01-31 10:41:51 <sipa> why would you need to communicate with the CA?
422 2012-01-31 10:42:27 <da2ce7> sipa:  to check for revoked certs.
423 2012-01-31 10:42:28 <UukGoblin> to check the signature of a certificate?
424 2012-01-31 10:42:52 <sipa> UukGoblin: everything needed is included in the the https server's response
425 2012-01-31 10:42:52 <UukGoblin> although, maybe not
426 2012-01-31 10:42:58 <UukGoblin> yeah, revokes
427 2012-01-31 10:43:09 <sipa> up to a certificate by a CA that you trust
428 2012-01-31 10:43:13 <sipa> but revokes, indeed
429 2012-01-31 10:44:05 <sipa> shouldn't it?
430 2012-01-31 10:44:06 <da2ce7> and the built in proxy... I think i shall move to firefox.
431 2012-01-31 10:44:31 <sipa> CA handling is something that should be done centralized by the OS, imho, instead of each application separatelky
432 2012-01-31 10:44:44 <Joric> i'd say it's also slower than firefox despite all commercials
433 2012-01-31 10:44:47 <da2ce7> sipa: sure; except I kinda trust mozilla more than msoft.
434 2012-01-31 10:45:09 <sipa> da2ce7: then maybe you should use a different OS :)
435 2012-01-31 10:45:12 <da2ce7> and I cannot be botherd in going throogh all the CA...
436 2012-01-31 10:45:35 <da2ce7> bah... windows on desktop; linux on server is how I roll.
437 2012-01-31 10:52:00 <Joric> i find some logical fallacies in your security system
438 2012-01-31 11:14:24 <pentarh> hello. looking for java developer for writing lightweight namecoin client
439 2012-01-31 11:33:51 <sje> is this a known problem (just did git pull): "/usr/include/boost/interprocess/detail/transform_iterator.hpp:57:15: error: reference m_value cannot be declared mutable [-fpermissive]"
440 2012-01-31 11:34:31 <sje> from bitcoin github
441 2012-01-31 11:38:48 <sje> nm - just boost ver
442 2012-01-31 14:00:22 <helo> it depends what you do with it... for google sites with really heavy javascript chrome seems to be faster (duh)
443 2012-01-31 14:04:23 <gmaxwell> go go grarpamp further strenghtening my heuristic that anyone who says "DHT" is clueless.
444 2012-01-31 14:05:44 <cjd> DHT the cloud dood
445 2012-01-31 14:13:39 <davex__> does the default pushpoold example-cfg.json need to be modified in order to avoid the "JSON parse failed" error?
446 2012-01-31 14:15:20 <davex__> or else the libjansson version i have just doesn't like it
447 2012-01-31 14:16:59 <dissipate_> can someone explain what the hell this proposal is about? https://en.bitcoin.it/wiki/BIP_0016
448 2012-01-31 14:17:54 <sipa> dissipate_: it a proposed implementation for BIP 13
449 2012-01-31 14:18:55 <dissipate_> BIP 13??
450 2012-01-31 14:18:59 <dissipate_> it says BIP 16
451 2012-01-31 14:19:09 <sipa> dissipate_: read my sentence
452 2012-01-31 14:19:20 <sipa> BIP16 is a proposed implementation for BIP13
453 2012-01-31 14:19:50 <ferroh> So, has BIP16 been running on testnet for a while?
454 2012-01-31 14:20:02 <sipa> ferroh: for anyone using git head, yes
455 2012-01-31 14:20:05 <ferroh> What I don't understand is what the big rush is to get this implemented on the productio network.
456 2012-01-31 14:20:08 <ferroh> *production
457 2012-01-31 14:20:22 <ferroh> For how long has it been on testnet?
458 2012-01-31 14:20:28 <dissipate_> whatever this thing is, it sounds pretty damn complicated.
459 2012-01-31 14:20:55 <dissipate_> some kind of scripting language to determine how some chain of transactions should take place??
460 2012-01-31 14:21:03 <sipa> dissipate_: we already have that
461 2012-01-31 14:21:12 <sipa> bitcoin is built around a scripting language
462 2012-01-31 14:21:44 <ferroh> dissipate_: The big feature we're currently missing (in my opinion), is that we don't have multikey transactions -- where multiple keys are needed to spend coins. BIP16 (or BIP17) will give us that.
463 2012-01-31 14:21:49 <sipa> sending money means creating a script that says "only the owner of address X can spend this coin" (simplified)
464 2012-01-31 14:21:50 <dissipate_> sipa, so what the hell is this thing?
465 2012-01-31 14:22:09 <sipa> redeeming money means proving that you own that address
466 2012-01-31 14:22:36 <dissipate_> sipa, how is that different from the way things are now? you sign coins over to another address
467 2012-01-31 14:22:51 <ferroh> dissipate_: One of the things that multikey transactions allow for, is the much safer use of online wallets, because the online wallet operator can't spend your coins without having all the keys (which he doesn't).
468 2012-01-31 14:23:15 <ferroh> dissipate_: What sipa is saying, is that we already have scripting -- BIP16 extends the abilities of the scripting language.
469 2012-01-31 14:24:09 <sipa> dissipate_: note that multisig transactions also already exist, you can create coins that need multiple signature to be spent, but they are not convenient
470 2012-01-31 14:24:36 <sipa> dissipate_: what BIP13 does is define an address type that says "i send this coin to anyone who can provide a valid script whose hash is X"
471 2012-01-31 14:24:55 <dissipate_> ferroh, interesting. sounds good!
472 2012-01-31 14:25:31 <sipa> dissipate_: BIP16 and BIP17 are technical implementations to provide the pay-to-script functionality defined in BIP13
473 2012-01-31 14:26:13 <dissipate_> sipa, how would they get the script that has that hash?
474 2012-01-31 14:26:23 <sipa> they don't
475 2012-01-31 14:26:32 <sipa> if i want you to pay to let's say me and my mother
476 2012-01-31 14:26:38 <sipa> i know that script already
477 2012-01-31 14:26:43 <sipa> and i just give you its hash
478 2012-01-31 14:27:12 <dissipate_> at what point does the script get executed?
479 2012-01-31 14:27:51 <sipa> dissipate_: when i redeem the coin
480 2012-01-31 14:28:51 <dissipate_> sipa, the script runs on all the clients?
481 2012-01-31 14:29:25 <sipa> yes
482 2012-01-31 14:31:29 <dissipate_> scalability issues are coming to mind
483 2012-01-31 14:32:05 <ferroh> dissipate_: the scripts are really limited, and don't run on thin clients.
484 2012-01-31 14:32:11 <dissipate_> could a bitcoin client running on a standard desktop handle a billion 'pay to scripts'?
485 2012-01-31 14:32:42 <sipa> the only cpu-intensive part is verifying signatures
486 2012-01-31 14:32:53 <sipa> a typical desktop can do about 1000 per second of those
487 2012-01-31 14:33:47 <dissipate_> sipa, if bitcoin became as large as just the stock market, those desktops would be overwhelmed.
488 2012-01-31 14:33:58 <gmaxwell> STOP
489 2012-01-31 14:34:03 <sipa> then those desktops shouldn't run full clients
490 2012-01-31 14:34:12 <gmaxwell> dissipate_: Bitcoin _already_ has scripting exactly as described here.
491 2012-01-31 14:34:19 <gmaxwell> dissipate_: P2SH isn't changing that at all.
492 2012-01-31 14:34:50 <gmaxwell> All it changes is when the detailed content of the script is provided. When a payment is made, or when the payment is redeemed.
493 2012-01-31 14:35:01 <gmaxwell> dissipate_: See https://en.bitcoin.it/wiki/Script
494 2012-01-31 14:36:19 <gmaxwell> The execution of these scripts is very computationally cheap compared to signature validations. They aren't in and of themselves a major scaling concern, and even if they were they're already a deeply rooted part of the system.
495 2012-01-31 14:37:18 <gmaxwell> As Sipa says, if your system can't scale to running a full zero-trust validating node then you can run a lite client (like multibit) or a thin client (like electrum) and not do that, but thats unrelated to BIP16.
496 2012-01-31 14:41:05 <dissipate_> gmaxwell, that's great. how is anyone going to be able to interpret something like this transaction: http://blockexplorer.com/testnet/tx/9b8cf14991f5b401d4356bbf2e11f5f3bb5221bbd947b8be4cf600f5492f974d
497 2012-01-31 14:42:12 <gmaxwell> dissipate_: interpret it for what purpose? The system itself already knows how to obey the rules there.
498 2012-01-31 14:43:05 <luke-jr> to clarify, BIP 16 isn't changing whether scripts are used, but it IS changing *how* scripts are used/interpreted fundamentally
499 2012-01-31 14:43:24 <dissipate_> gmaxwell, seems pretty opaque to me
500 2012-01-31 14:43:41 <sipa> dissipate_: which script are you talking about?
501 2012-01-31 14:44:45 <dissipate_> sipa, any of them. how is anyone looking at these things going to tell what the heck is going on?
502 2012-01-31 14:44:59 <gmaxwell> Oh you're talking about the input script? Thats just 'opaque' because block explorer isn't bothering to decode it.
503 2012-01-31 14:45:16 <sipa> dissipate_: they are perfectly clear to me :)
504 2012-01-31 14:45:35 <sipa> gmaxwell: no, what you see IS the decoded scriptSig
505 2012-01-31 14:46:54 <sipa> it contains two pushes, both of which are shown as hex
506 2012-01-31 14:48:39 <lianj> http://test.bitcoin.interesthings.de/script/f4267e963657e4f891acad0afa5d956d2e651091aaedbaa46d5b6879e9b14533:0 :)
507 2012-01-31 14:49:51 <gmaxwell> dissipate_: in any case, it's no less clear than any random ordinary transaction you can pick. (e.g. https://blockexplorer.com/tx/edd34b56fa04c656b3a117a546ee8106a09a1e6ede4681ec377498522daa4ab0 )
508 2012-01-31 14:56:19 <lianj> hm, i would why bbe shows 6451042 OP_DROP though, i get 626f62 OP_DROP :|
509 2012-01-31 14:57:48 <lianj> [6451042].pack("I") => "bobx00";  ["626f62"].pack("H*") => "bob"
510 2012-01-31 15:02:05 <lianj> http://paste.pocoo.org/show/ZcC7zOvEAcNzIceAnQe6/
511 2012-01-31 16:18:54 <luke-jr> gmaxwell: what's the difference between Weak and Very weak? O.o
512 2012-01-31 16:29:28 <ferroh> luke-jr: Similar to the difference between strong and very strong, I imagine.
513 2012-01-31 16:30:41 <BlueMatt> what do people think of a prefix to be added to bip 16 to allow extensibility: any variables prefixed with req:... should be considered required and if the client does not understand them, the uri should be considered invalid
514 2012-01-31 16:31:00 <BlueMatt> that way new incompatible variables can be added and old clients will handle them properly
515 2012-01-31 16:31:09 <BlueMatt> additionally new variables can be added that arent required easily
516 2012-01-31 16:31:48 <Eliel> BlueMatt: you mean bip 20/21 I hope.
517 2012-01-31 16:31:57 <BlueMatt> bip 21, sorry
518 2012-01-31 16:32:51 <user__> luke-jr, devs prefer bip16 right? we have bip 16 and 17. miners wil choose one. so why people are so boring with you?
519 2012-01-31 16:33:11 <user__> it's democracy right?
520 2012-01-31 16:33:13 <gavinandresen> I think I'd prefer something like:  &mustuspport=exptime:sendto
521 2012-01-31 16:33:36 <BlueMatt> ok, however you implement it, I was asking about the idea
522 2012-01-31 16:33:41 <gavinandresen> I like the idea
523 2012-01-31 16:34:00 <BlueMatt> then drop the version field (as its not implemented anywhere either)
524 2012-01-31 16:34:34 <BlueMatt> also, that way support for mustsupport or req or whatever can be added to bitcoin-qt quickly before 0.6 and we dont have to worry about backward compat later (as much)
525 2012-01-31 16:34:40 <justmoon> user__, no it's sonocracy - whoever cries loudest wins
526 2012-01-31 16:35:50 <Ukyo> My quick 2c from experience... in this sort of a project, you take those top few people, and let them make the decision, if one person of the few looses, then they need to deal with it
527 2012-01-31 16:35:56 <ferroh> user__: Actually miners were supposed to vote by Feb 1 (tomorrow), and it looks like there will be no consensus vote, in which case the deadline is being pushed back I assume.
528 2012-01-31 16:36:06 <user__> justmoon,  no. miners wil just look what most devs say, and they prefer bip16
529 2012-01-31 16:36:08 <Ukyo> thats how many versions of things are formed
530 2012-01-31 16:37:10 <gavinandresen> RE: sonocracy:  https://bitcointalk.org/index.php?topic=62037.0
531 2012-01-31 16:37:35 <Ukyo> we are all adults, and while we may have disagreements, someone or some few have the make the ultimate decision for the project.
532 2012-01-31 16:38:56 <Ukyo> we all want to see bitcoin succeed. It would be a shame to see top developers walk away, any of you/them because the feeling that of being right, and getting passed over
533 2012-01-31 16:39:58 <user__> i think  luke is wrng with his drama, but i think he was own to propose a bip that is not flaw
534 2012-01-31 16:40:09 <user__> he has
535 2012-01-31 16:40:14 <user__> own
536 2012-01-31 16:40:22 <gavinandresen> .... watch the video if you haven't already....
537 2012-01-31 16:40:40 <user__> and see what miners decide
538 2012-01-31 16:40:46 <user__> but ok
539 2012-01-31 16:40:54 <user__> just my opinion
540 2012-01-31 16:42:49 <user__> of course i think luke should rethink about his words when posting
541 2012-01-31 16:52:25 <BlueMatt> gavinandresen: actually, Im not a big fan of mustsupport=a:1;b:2& because it means you now have a variable with multiple variables inside it, which makes it look odd...
542 2012-01-31 16:55:36 <gavinandresen> BlueMatt: ok, then mustsupport=foo&mustsupport=bar ....
543 2012-01-31 16:56:09 <gavinandresen> (PHP will even put those into an array for you, if I recall correctly)
544 2012-01-31 16:56:21 <gavinandresen> (which I probably don't)
545 2012-01-31 16:57:05 <BlueMatt> who uses php to parse uris for bitcoin?
546 2012-01-31 16:57:32 <BlueMatt> but then you get like mustsupport=foo:2&mustsupport=bar:1
547 2012-01-31 16:57:40 <BlueMatt> and then you have two variables with the same key...
548 2012-01-31 16:57:45 <BlueMatt> I dunno it just looks ugly to me
549 2012-01-31 16:57:52 <gmaxwell> user__: the idea that its just up to the miners is somewhat wrongheaded. Some people have been promoting that idea, I wrote a counter to it here: https://bitcointalk.org/index.php?topic=61922.msg723476#msg723476
550 2012-01-31 16:58:06 <BlueMatt> anyone else have an opinion?
551 2012-01-31 16:58:31 <BlueMatt> iirc, php has easy access to _GET["foo"]
552 2012-01-31 16:58:49 <BlueMatt> not really _GET["mustsupport"]["bar"]
553 2012-01-31 16:58:55 <BlueMatt> I dont think the second is valid
554 2012-01-31 16:59:03 <BlueMatt> (Im assuming you are talking about webwallets here)
555 2012-01-31 17:00:01 <BlueMatt> _GET["reqfoo"] works fine, as does _GET["foo"] and you can easily just do if isset(_GET["foo"]) foo = _GET["foo"]; else if isset(_GET["reqfoo"]) foo = _GET["reqfoo"]
556 2012-01-31 17:00:45 <justmoon> gavinandresen, php will only put it in an array if you send this: mustsupport[]=foo&mustsupport[]=bar
557 2012-01-31 17:01:03 <justmoon> with what you posted, php will give you $_GET['mustsupport'] == 'bar'
558 2012-01-31 17:01:04 <gavinandresen> justmoon: ah, thanks, I knew I was forgetting something
559 2012-01-31 17:01:35 <justmoon> ;)
560 2012-01-31 17:01:58 <BlueMatt> same here
561 2012-01-31 17:02:12 <BlueMatt> (luckily I dont know it as well as you ;) )
562 2012-01-31 17:02:46 <Eliel> it works, as long as you don't want to do anything too fancy (in conceptual terms) :)
563 2012-01-31 17:03:21 <gavinandresen> BlueMatt: so:  I have a strong opinion that the term "required" is the wrong word to use, and I have the feeling that prefixing the name is the wrong way to express that meta-information, but I don't have a strong opinion about what the right way is.
564 2012-01-31 17:03:53 <BlueMatt> mmm, fair enough
565 2012-01-31 17:04:08 <BlueMatt> who actually has serious enough experience to comment on what the right way is?
566 2012-01-31 17:04:17 <gavinandresen> BlueMatt: If pushed, I'd vote to leave the URI scheme as is and when we need versioning then do... something.
567 2012-01-31 17:04:33 <BlueMatt> that just sounds ugly...
568 2012-01-31 17:05:05 <gavinandresen> (but the thinking-about-the-future argument does make sense.  Kind of too late now, though, we've been shipping a bitcoin with the old URI scheme for a few months....)
569 2012-01-31 17:05:21 <Ukyo> gavinandresen: yes. php will take the uri and make an array for ppl who wish to use it
570 2012-01-31 17:05:58 <BlueMatt> gavinandresen: yea, hence the backward compat section I just wrote: "As this BIP is written, several clients already implement a bitcoin: URI scheme similar to this one, however usually without the additional "req" prefix requirement.  Thus, it is recommended that additional variables prefixed with req not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client dev
571 2012-01-31 17:05:59 <BlueMatt> elopers to release new versions, and users of old clients to upgrade."
572 2012-01-31 17:06:22 <BlueMatt> s/req/whatever way we do it/
573 2012-01-31 17:08:06 <BlueMatt> what about ?mustimplement:variable=data
574 2012-01-31 17:08:10 <BlueMatt> is that valid uri?
575 2012-01-31 17:08:29 <BlueMatt> then you can still get _GET["mustimplement:variable"] or _GET["variable"]
576 2012-01-31 17:08:44 <BlueMatt> so its still split nicely by uri/l libraries
577 2012-01-31 17:10:14 <Eliel> BlueMatt: how about just design a completely new version that will use different uri prefix? The current one is "bitcoin:". the new one could be a little different. For example "btc:"
578 2012-01-31 17:10:48 <BlueMatt> Eliel: you mean instead of a 6 month grace period
579 2012-01-31 17:10:52 <Eliel> yes
580 2012-01-31 17:11:02 <BlueMatt> Eliel: well I have yet to see bitcoin: uris anywhere but one site so I think we are safe enough
581 2012-01-31 17:11:14 <BlueMatt> that clients will upgrade before its really used
582 2012-01-31 17:12:58 <helo> what bip is this?
583 2012-01-31 17:13:17 <Eliel> 21
584 2012-01-31 17:14:45 <Ukyo> we could just skip to 42...
585 2012-01-31 17:14:49 <Ukyo> its the answer to everything :P
586 2012-01-31 17:15:09 <Ukyo> just make sure you have your towel when its time.
587 2012-01-31 17:16:20 <BlueMatt> ok, so I went ahead and did the mustimplement: prefix (see https://en.bitcoin.it/wiki/BIP_0021 ) yea its not ideal, but imho its a pretty simple solution to give use nice forward compat
588 2012-01-31 17:16:46 <BlueMatt> yea, its not an ideal method, but I cant think of a better way so thats what I think should go in bip 21
589 2012-01-31 17:23:41 <BlueMatt> ok, mail about bip 21 sent to mailing list.  quoting: "I want to keep the list of
590 2012-01-31 17:23:42 <BlueMatt> changes from the Bitcoin-Qt implementation to this BIP very, very minimal this late the 0.6 release cycle (I want to get this BIP
591 2012-01-31 17:24:30 <BlueMatt> in other words, better solutions/suggestions would be very, very much appreciated very quickly so that I can write a pull request in the next couple days and have bip 21 finalized before bitcoin-qt 0.6 goes on lockdown for 0.6
592 2012-01-31 17:24:38 <BlueMatt> s/on lockdown/on rc lockdown/
593 2012-01-31 17:39:23 <torsthaldo> Regarding BIP 0021 / URIs: please specify behaviour for cases where comma is used as the radix point
594 2012-01-31 17:42:12 <gmaxwell> I think strings with commas in them should be rejected. (sorry for the i18n insensitivity, but attemping to handle them is highly dangerous)
595 2012-01-31 17:42:50 <tcatm> torsthaldo: undefined ;)
596 2012-01-31 17:47:51 <torsthaldo> okok :)
597 2012-01-31 17:51:49 <torsthaldo> Testing in bitcoin-qt (0.5.0.1): when I paste "5,77" as the amount I want to send, this gets parsed by the client as "577.00000000".
598 2012-01-31 17:52:19 <torsthaldo> This behaviour seems potentially very dangerous.
599 2012-01-31 17:52:28 <torsthaldo> Has this been fixed?
600 2012-01-31 17:53:19 <Diablo-D3> torsthaldo: uh, seeing as , is not a valid character in money, Im not sure how you'd think it could parse it any other way
601 2012-01-31 17:53:39 <torsthaldo> http://en.wikipedia.org/wiki/Decimal_mark#Countries_using_Arabic_numerals_with_decimal_comma
602 2012-01-31 17:53:46 <gmaxwell> Diablo-D3: what happens if you put in 5q77? :)
603 2012-01-31 17:53:55 <Diablo-D3> gmaxwell: isnt that some of luke's total shit?
604 2012-01-31 17:53:58 <vsrinivas> gmaxwell: dangerous?
605 2012-01-31 17:53:59 <gmaxwell> !
606 2012-01-31 17:54:07 <gmaxwell> vsrinivas: see torsthaldo's comment.
607 2012-01-31 17:54:22 <gmaxwell> Diablo-D3: no, follow the wikipedia link you narrowminded american! :)
608 2012-01-31 17:54:27 <BlueMatt-mobile> Iirc bitcoin-qt handles commas in uris the same way as in other send dialogs
609 2012-01-31 17:54:32 <torsthaldo> Well, in this case the recipient would recieve a much larger amount than I intended to send.
610 2012-01-31 17:54:36 <BlueMatt-mobile> What that is, i dont remember
611 2012-01-31 17:54:42 <vsrinivas> that's just a bug, no?; is there anything basically dangerous about them?
612 2012-01-31 17:54:43 <Diablo-D3> until OPEC uses commas, I have no reason to switch.
613 2012-01-31 17:54:56 <gmaxwell> vsrinivas: hows that a bug? thats a correct parse of US style money moneys.
614 2012-01-31 17:55:12 <Diablo-D3> wait wait wait
615 2012-01-31 17:55:13 <gmaxwell> Putting the thousands seperator in odd places is normally supported.
616 2012-01-31 17:55:14 <Diablo-D3> rewind a bit
617 2012-01-31 17:55:19 <Diablo-D3> torsthaldo: what is your locale set to?
618 2012-01-31 17:55:31 <vsrinivas> gmaxwell: LC_* exists for this, no?
619 2012-01-31 17:55:36 <BlueMatt-mobile> The problem with commas in uris is its written by someone whos locale you dont know
620 2012-01-31 17:55:36 <Diablo-D3> QT may actually convert it properly if your locale is set right
621 2012-01-31 17:55:53 <Diablo-D3> BlueMatt-mobile: except uris should NOT be human readable.
622 2012-01-31 17:55:57 <gmaxwell> vsrinivas: Yes, no go back to what we were talking about. A URL that a _SITE_ gives you. How does a site reliably know your locale?
623 2012-01-31 17:56:04 <BlueMatt-mobile> And you cant parse with your locale
624 2012-01-31 17:56:04 <Diablo-D3> which is a programming bug.
625 2012-01-31 17:56:18 <Diablo-D3> this is one of those times where "its a floating point number you dick" is correct behavior
626 2012-01-31 17:56:21 <BlueMatt-mobile> Diablo-D3 yep hance they should be ignored
627 2012-01-31 17:56:22 <BlueMatt-mobile> Imho
628 2012-01-31 17:56:42 <gmaxwell> Diablo-D3: except it's not a (binary) floating point number. It's a bitcoin amount. :-/
629 2012-01-31 17:56:58 <Diablo-D3> gmaxwell: yes, and its a computer use number not a huamn use number
630 2012-01-31 17:57:03 <Diablo-D3> computers use dots in ALL locales
631 2012-01-31 17:57:22 <BlueMatt-mobile> Ill add that to the spec after class
632 2012-01-31 17:57:24 <Diablo-D3> silly humans and your "text"
633 2012-01-31 17:58:03 <Diablo-D3> dear lord, some countries use ` for money commas?
634 2012-01-31 17:58:09 <Diablo-D3> what the fuck people, its a NUMBER
635 2012-01-31 17:58:17 <Diablo-D3> its math!
636 2012-01-31 17:58:27 <Diablo-D3> stop doing that!
637 2012-01-31 17:58:57 <gmaxwell> In any case, since we don't know the locale in the URL we really need to force a particular behavior. The easiest way to do this is to reject any string with a comma anywhere in it.
638 2012-01-31 17:58:58 <torsthaldo> When I manually enter the amount "5,77" it gets correctly interpreted as "5.77" this is the obviously intended, obviously correct, safe, sane behaviour.
639 2012-01-31 17:59:17 <torsthaldo> Not so for copy and paste.
640 2012-01-31 17:59:21 <Diablo-D3> torsthaldo: "wrong"
641 2012-01-31 17:59:28 <poiuh> if you share a url with someone, they might have a totally different locale.. the string should be unambiguous
642 2012-01-31 17:59:35 <Diablo-D3> torsthaldo: if your locale is set to a country that uses commas, then commas will be legit
643 2012-01-31 18:00:23 <Diablo-D3> thus, if you enter 5,77 with a proper locale set, then it should infact work
644 2012-01-31 18:00:43 <Diablo-D3> if it doesnt, then yes, its a bug
645 2012-01-31 18:01:09 <torsthaldo> I'm getting inconsistent behaviour.
646 2012-01-31 18:01:14 <Diablo-D3> no you're not
647 2012-01-31 18:01:19 <Diablo-D3> you're giving it inconsistent behavior
648 2012-01-31 18:01:36 <Diablo-D3> you're telling it you're EN_US but giving it arabic decimal seperators.
649 2012-01-31 18:01:45 <torsthaldo> Well, right. I'm getting inconsistent results. ^^
650 2012-01-31 18:01:55 <jrmithdobbs> that's consistent
651 2012-01-31 18:02:06 <jrmithdobbs> there's no inconsistentancy
652 2012-01-31 18:02:07 <Diablo-D3> lying to a computer and then bitching it didnt work is pebkac
653 2012-01-31 18:02:23 <luke-jr> Diablo-D3: no, Bitcoin-Qt (and wxBitcoin before it) intentionally ignore locales for BTC
654 2012-01-31 18:02:31 <Diablo-D3> luke-jr: are you kidding me?
655 2012-01-31 18:02:33 <Diablo-D3> thats a bug.
656 2012-01-31 18:02:33 <luke-jr> no
657 2012-01-31 18:02:37 <Diablo-D3> qt has a money text box type.
658 2012-01-31 18:02:40 <luke-jr> Gavin decided only "." is legal for BTC
659 2012-01-31 18:02:41 <jrmithdobbs> err, i thought the , thing got fixed?
660 2012-01-31 18:02:50 <jrmithdobbs> really?
661 2012-01-31 18:02:53 <jrmithdobbs> that's dumb.
662 2012-01-31 18:02:54 <luke-jr> IIRC
663 2012-01-31 18:02:55 <Diablo-D3> thats bullshit
664 2012-01-31 18:02:58 <Diablo-D3> gavinandresen: fix this shit
665 2012-01-31 18:02:58 <luke-jr> want me to dig out the log? :p
666 2012-01-31 18:03:04 <jrmithdobbs> gavinandresen: ^
667 2012-01-31 18:03:06 <luke-jr> &
668 2012-01-31 18:03:11 <luke-jr> I agree with Gavin's decision FWIW.
669 2012-01-31 18:03:27 <gavinandresen> Bitcoin-Qt allows commas in the money amounts?  Sounds like a bug.
670 2012-01-31 18:03:27 <luke-jr> just because legacy currencies had this inconsistency doesn't mean Bitcoin should
671 2012-01-31 18:03:29 <jrmithdobbs> of course you do, you're a xenophobe
672 2012-01-31 18:03:39 <Diablo-D3> gavinandresen: no, Im saying its a bug if it doesnt on locales that have it set
673 2012-01-31 18:03:53 <Diablo-D3> do not fuck with qt's input boxes.
674 2012-01-31 18:04:05 <Diablo-D3> inconsistent behavior is bad.
675 2012-01-31 18:04:25 <justmoon> I never thought I'd say this, but I agree with Diablo-D3
676 2012-01-31 18:04:32 <Diablo-D3> if you're a terrorist, and have your locale set to a terrorist country, then using a terrorist decimal seperator should be legal
677 2012-01-31 18:04:35 <jrmithdobbs> justmoon: ya, in the same boat
678 2012-01-31 18:04:37 <jrmithdobbs> heh
679 2012-01-31 18:04:38 <justmoon> you will cause major havoc for german users if you don't understand comma entry
680 2012-01-31 18:04:54 <Diablo-D3> justmoon: well, btc doesnt understand anything
681 2012-01-31 18:04:59 <Diablo-D3> its all handled by qt.
682 2012-01-31 18:05:05 <Diablo-D3> qt has a locale aware money text box
683 2012-01-31 18:05:08 <gavinandresen> wxbitcoin used to allow commas in numbers entered, and that was changed to disallow anything but numbers and the decimal point.
684 2012-01-31 18:05:20 <gmaxwell> justmoon: be mindful of the multiple discussions here, URL vs -qt.
685 2012-01-31 18:05:20 <helo> it would be nice if the UI handled conversion of the input value into a float according to the locale
686 2012-01-31 18:05:36 <Diablo-D3> yeah, URLs _need_ to be computer input only
687 2012-01-31 18:05:40 <justmoon> gmaxwell, yeah, I'm noticing I jumped into something I don't fully understand
688 2012-01-31 18:05:43 <Diablo-D3> that can only ever be "its a floating point number"
689 2012-01-31 18:05:44 <luke-jr> IMO, it should throw an error rather than just ignore the comma
690 2012-01-31 18:05:49 <Diablo-D3> luke-jr: well
691 2012-01-31 18:05:54 <justmoon> I'm just saying that a german user should end up being able to use commas everywhere
692 2012-01-31 18:05:56 <Diablo-D3> it shouldnt even let you type it at that point
693 2012-01-31 18:05:57 <gmaxwell> helo: careful bitcoin values are not 'float'.
694 2012-01-31 18:06:00 <justmoon> otherwise you have a major usability issue
695 2012-01-31 18:06:12 <Diablo-D3> but yes, this is the problem
696 2012-01-31 18:06:22 <Diablo-D3> you use a locale aware toolkit, then thats it, your choice is made for you
697 2012-01-31 18:06:24 <helo> yeah... well conversion into some unambiguous value, at least
698 2012-01-31 18:06:28 <gmaxwell> justmoon: not in URLs because one user can be german the other american.
699 2012-01-31 18:06:30 <jrmithdobbs> gavinandresen: that's a broken change
700 2012-01-31 18:06:39 <Diablo-D3> gmaxwell: woah woah woah
701 2012-01-31 18:06:40 <Diablo-D3> dude
702 2012-01-31 18:06:43 <Diablo-D3> URLs are not for people
703 2012-01-31 18:06:46 <vsrinivas> what was the rationale?
704 2012-01-31 18:06:47 <Diablo-D3> it doesnt matter what a user is
705 2012-01-31 18:06:51 <Diablo-D3> the URLs arent for them
706 2012-01-31 18:06:55 <justmoon> gmaxwell, yeah, urls should be always dot
707 2012-01-31 18:07:06 <Diablo-D3> computer math only has one form: period, not comma.
708 2012-01-31 18:07:06 <gmaxwell> vsrinivas: it was aceepting it everywhere so transfer 1,000 BTC was transfering 1.
709 2012-01-31 18:07:14 <gmaxwell> (even for US locale users)
710 2012-01-31 18:07:17 <vsrinivas> oh heh!
711 2012-01-31 18:07:20 <Diablo-D3> yeah thats broken
712 2012-01-31 18:07:30 <Moron__> why not do away with the point all together
713 2012-01-31 18:07:32 <Moron__> why not have two values
714 2012-01-31 18:07:45 <Moron__> ie... 5 BTC 1438000 satoshis
715 2012-01-31 18:07:47 <gmaxwell> Moron__: I know, we could use tonal!
716 2012-01-31 18:08:03 <Diablo-D3> FUCK TONAL
717 2012-01-31 18:08:19 <gmaxwell> Numers are hard. Lets replace it with a slider and a face that gets happier the further you turn the knob.
718 2012-01-31 18:08:28 <Diablo-D3> goddamn fucking catholic choir boy raping nigger owning white trash!
719 2012-01-31 18:08:32 <gmaxwell> er. s/Numers/Numbers/
720 2012-01-31 18:09:15 <gavinandresen> FYI everybody: https://bitcointalk.org/index.php?topic=62068   Testnet chain split scheduled for Feb 15
721 2012-01-31 18:09:26 <gmaxwell> Diablo-D3: 0_o do you need a bib for that foam?
722 2012-01-31 18:09:49 <Diablo-D3> I forgot "prostitute raping"
723 2012-01-31 18:10:13 <Moron__> prostitutes are ok.. leave our choir boys alone :P
724 2012-01-31 18:11:36 <Moron__> anyway, maybe its time to start using BTC, mBTC, uBTC, satotishis rather than decimal points
725 2012-01-31 18:11:44 <Moron__> because points insinuate floating point accuracy
726 2012-01-31 18:12:06 <gavinandresen> gee, if only there was a pull-down menu in the GUI to select the units.....
727 2012-01-31 18:12:52 <gmaxwell> gavinandresen: just type ??? if you want microbtc. Easy.
728 2012-01-31 18:13:01 <helo> does testnet have consistent hashrate now?
729 2012-01-31 18:13:20 <gmaxwell> hah. No.
730 2012-01-31 18:13:24 <gavinandresen> helo: it will have a minimum block creation rate after Feb 15
731 2012-01-31 18:13:56 <gavinandresen> helo: ... at least 1 block every 20 minutes, assuming somebody is mining with more than a pocket calculator
732 2012-01-31 18:14:38 <gavinandresen> gmaxwell: you trying to be the Testnet Bitcoin Billionaire?
733 2012-01-31 18:14:50 <Diablo-D3> lol
734 2012-01-31 18:14:57 <Diablo-D3> ALLLLLLLL THE TESTCOINS
735 2012-01-31 18:16:36 <Graet> ooh but maybe...the nvidia could finally have a use?
736 2012-01-31 18:17:42 <vsrinivas> anyway. i actually came here for a reason;; while tracing bitcoind's startup on DFly, in a single cycle of 'start bitcoind, answer one getinfo, stop', there were 123,398 read() syscalls, of which 93,000 or so were one page only.
737 2012-01-31 18:18:33 <torsthaldo> Should I file a ticket / bugreport?
738 2012-01-31 18:18:38 <vsrinivas> the vast majority of those are on the db* files; why page at a time?
739 2012-01-31 18:18:43 <gmaxwell> vsrinivas: you should see a blockchain sync.. like 23 GiB of one page ish random writes!
740 2012-01-31 18:18:55 <gmaxwell> vsrinivas: btree lookups, I assume.
741 2012-01-31 18:19:21 <luke-jr> torsthaldo: you can, but I wouldn't expect comma to be accepted as valid
742 2012-01-31 18:19:37 <vsrinivas> ok, cheers; haven't looked at the read offsets, should do that. but booo, difficult to cluster_read() with page-at-a-time read()s.
743 2012-01-31 18:20:32 <gmaxwell> vsrinivas: it would be helpful if you could track this back to the bitcoin code thats causing it. There may well be some really idiotic unneeded lookups.
744 2012-01-31 18:20:52 <gmaxwell> vsrinivas: unfortunately I haven't found a good way to really profile IO activity back to the bitcoin code which is the root cause of it.
745 2012-01-31 18:21:17 <vsrinivas> no really great answer, unfortunately... if read()s could be tagged, that'd be great, but...
746 2012-01-31 18:21:34 <vsrinivas> dtrace might be the right answer;;
747 2012-01-31 18:21:51 <vsrinivas> also concerning -- 1/5th or so of all syscalls (~100k) were gettimeofday()...
748 2012-01-31 18:22:06 <gmaxwell> At least gettimeofday should be fast. :)
749 2012-01-31 18:22:37 <luke-jr> I'd think it's possible to have gdb break on read()
750 2012-01-31 18:22:44 <Diablo-D3> heh
751 2012-01-31 18:22:54 <gmaxwell> luke-jr: yea, but thats myopic. You can do that 100 times and they all look boring.
752 2012-01-31 18:23:12 <luke-jr> automate it to dump a backtrace every read() and then count them? :p
753 2012-01-31 18:23:24 <gmaxwell> I want that 100 million times and then a histogram of the backtrace signatures.
754 2012-01-31 18:23:28 <gmaxwell> right.
755 2012-01-31 18:23:36 <torsthaldo> luke-jr: I want bitcoin-qt to throw an error, and NOT transfer sums that are off by the same number of order of magnitude as the number of digits behind the radix point.
756 2012-01-31 18:23:47 <gmaxwell> oprofile is supposted to be able to do this, but I couldn't get it to work right for it.
757 2012-01-31 18:24:27 <torsthaldo> (which seems to me to be the current behaviour.)
758 2012-01-31 18:24:46 <luke-jr> torsthaldo: sounds reasonable
759 2012-01-31 18:25:07 <luke-jr> gmaxwell: I think gdb has some kind of weird Python scripting now
760 2012-01-31 18:25:32 <torsthaldo> say, if I blindly copied some requested amount of an email, and
761 2012-01-31 18:25:45 <gmaxwell> It does. I've played with it a bit. It would also be possible to create and LDPRELOAD that dumps a backtrace everytime read gets hit.
762 2012-01-31 18:26:08 <gmaxwell> That would likely be much faster than GDB.
763 2012-01-31 18:26:11 <luke-jr> torsthaldo: OTOH, what if I put 100,000? That *is* 100000 for English-speaking people
764 2012-01-31 18:26:27 <luke-jr> torsthaldo: so it might not be completely straightforward
765 2012-01-31 18:26:32 <gmaxwell> luke-jr: rejecting that at least wouldn't make your day suck.
766 2012-01-31 18:26:43 <luke-jr> gmaxwell: true, but I bet someone would report that as a bug ;)
767 2012-01-31 18:27:04 <gmaxwell> people report the direction their toilet watter swirls as a bug.
768 2012-01-31 18:27:19 <gmaxwell> If the rejection message is helpful it would be minimally harmful. :)
769 2012-01-31 18:27:44 <luke-jr> good idea
770 2012-01-31 18:28:26 <luke-jr> actually, Diablo-D3's "just don't let them enter a comma in the first place" is probably best
771 2012-01-31 18:28:35 <luke-jr> I'd think people would notice that
772 2012-01-31 18:28:36 <luke-jr> maybe
773 2012-01-31 18:29:00 <gmaxwell> er.. I don't.
774 2012-01-31 18:30:26 <Diablo-D3> I said that as a joke.
775 2012-01-31 18:30:42 <Diablo-D3> qt has locale aware textboxes, we need to use them
776 2012-01-31 18:31:57 <Ukyo> gavinandresen: hmm, i might have to point 10ghash at testnet to showup gmaxwell :P
777 2012-01-31 18:32:05 <Ukyo> its all about the testnet e-pen :P
778 2012-01-31 18:32:34 <gavinandresen> As long as y'all put transactions in your testnet blocks you can play all you like....
779 2012-01-31 18:32:43 <Ukyo> hehehe
780 2012-01-31 18:32:44 <gavinandresen> ... although I'd prefer if you waited until after Feb 15