1 2012-09-11 00:31:15 <sipa> ;;bc,blocks
  2 2012-09-11 00:31:16 <gribble> 198238
  3 2012-09-11 01:02:09 <ub3rst4r> i was wondering if anyone knows if its possible to convert USD to BTC using PHP?
  4 2012-09-11 01:05:12 <sipa> ub3rst4r: there is no well-defined conversion rate
  5 2012-09-11 01:06:21 <ub3rst4r> sipa but is there a API or something to use?
  6 2012-09-11 01:09:38 <sipa> typically, exchanges' last trade price, or some weighted average is used as conversion rate
  7 2012-09-11 01:09:50 <sipa> i'm sure mtgox and other exchanges have api's
  8 2012-09-11 01:10:11 <Arnavion> https://www.google.com/search?q=1+btc+to+usd
  9 2012-09-11 01:10:15 <Arnavion> ETA till that works?
 10 2012-09-11 01:10:20 <Arnavion> :)
 11 2012-09-11 01:36:10 <sebicas> It there any performance problems with wallets that have lots of transactions ( talking over 10K txs )
 12 2012-09-11 01:36:29 <sebicas> ?
 13 2012-09-11 03:06:30 <slush> Hello, maybe someone is interested in this? http://mining.bitcoin.cz/stratum-mining
 14 2012-09-11 03:07:03 <Luke-Jr> slush: sounds like reinventing BIP 22+23
 15 2012-09-11 03:07:04 <MagicalTux> slush: sounds good
 16 2012-09-11 03:07:21 <MagicalTux> this said I don't know other similar attempts to do that
 17 2012-09-11 03:07:23 <slush> Luke-Jr: re-inventing? :)
 18 2012-09-11 03:07:26 <Luke-Jr> slush: yes
 19 2012-09-11 03:07:33 <slush> Luke-Jr: did you read it?
 20 2012-09-11 03:07:36 <Luke-Jr> am
 21 2012-09-11 03:07:39 <slush> obvously not yet
 22 2012-09-11 03:07:42 <Luke-Jr> why not?
 23 2012-09-11 03:07:54 <slush> because it is quite long, you cannot read it so fast :)
 24 2012-09-11 03:07:58 <Luke-Jr> :p
 25 2012-09-11 03:08:25 <slush> MagicalTux: this is quite funny stuff, me and eleuthria published very similar concept at the same time :)
 26 2012-09-11 03:08:55 <Luke-Jr> slush: the comments on GBT aren't entirely correct
 27 2012-09-11 03:09:20 <slush> GBT?
 28 2012-09-11 03:09:28 <Luke-Jr> BIP 22/23, getblocktemplate
 29 2012-09-11 03:09:46 <slush> what's wrong?
 30 2012-09-11 03:10:25 <Luke-Jr> 1) the fundamental BIP 22 operation is fairly easy to implement, just making use of the more advanced functionality (which SMP doesn't even support yet) is complex
 31 2012-09-11 03:10:44 <Luke-Jr> 2) GBT does not require or depend on HTTP; it is intentionally designed to be JSON-RPC over any transport
 32 2012-09-11 03:11:04 <Luke-Jr> 3) GBT does not require a complete dump of the server's memory pool
 33 2012-09-11 03:11:18 <Luke-Jr> 4) checking shares shouldn't be any different AFAIK?
 34 2012-09-11 03:12:12 <slush> 1) there's still much more options than in stratum
 35 2012-09-11 03:12:31 <slush> I wanted to make it as easy as possible
 36 2012-09-11 03:12:46 <Luke-Jr> options are options
 37 2012-09-11 03:13:02 <slush> 2) well, but if you want to get it implemented in miners, you have to define whole stack.
 38 2012-09-11 03:13:51 <slush> If I remember it well, the "response" for getblocktemplate is "submitblock"
 39 2012-09-11 03:14:08 <slush> so pool have to do full block validation for every share, right?
 40 2012-09-11 03:14:13 <slush> sounds quite hardcore for me
 41 2012-09-11 03:14:24 <Luke-Jr> depends on what the pool allows
 42 2012-09-11 03:14:45 <slush> yes, all depends on everything :) That's what I'm saying that it's too much complicated for real world
 43 2012-09-11 03:14:55 <slush> anyway it was great to implement stratum pool ON TOP of it
 44 2012-09-11 03:15:09 <Luke-Jr> if you use the same feature set as stratum, it's just as simple
 45 2012-09-11 03:19:18 <Luke-Jr> slush: it would have made sense, if you had participated in forming BIP 22/23 :/
 46 2012-09-11 03:21:21 <Luke-Jr> why silently wait, developing something alternate in private, and announce it after the new standards are just about adopted?
 47 2012-09-11 03:21:42 <slush> Luke-Jr: Actually I don't know that stuff as well as you so I did not understand many of the options provided by the interface
 48 2012-09-11 03:21:57 <slush> I just wanted to design something easy, so I picked very limited subset from your megaproposal
 49 2012-09-11 03:22:12 <Luke-Jr> slush: ignore the sections you don't want? :p
 50 2012-09-11 03:22:50 <slush> Another reason is that I didn't know about the BIP 22/23 discussion before I started implementing my idea :)
 51 2012-09-11 03:23:25 <Luke-Jr> slush: are you on the Bitcoin development ML? ;)
 52 2012-09-11 03:24:00 <slush> yes, as well as on tor mailing list, tahoe-lafs mailing list, pyfilesystem mailing list and ~10 of ohers
 53 2012-09-11 03:24:07 <Luke-Jr> XD
 54 2012-09-11 03:24:52 <slush> Not that I'm proud of it, but I have 6500 unread emails just in inbox :)
 55 2012-09-11 03:25:08 <Luke-Jr> 14889 here >.>
 56 2012-09-11 03:25:21 <Luke-Jr> going back to 2005
 57 2012-09-11 03:27:35 <slush> well, back to topic. This is nothing against you. I think that BIP 22/23 do the job perfectly, really
 58 2012-09-11 03:28:00 <slush> But now the question is if we want universal solution for all use cases
 59 2012-09-11 03:28:04 <slush> And I say no
 60 2012-09-11 03:28:10 <Luke-Jr> that's silly
 61 2012-09-11 03:28:33 <slush> why?
 62 2012-09-11 03:29:11 <Luke-Jr> why would you want entirely different protocols for superset use cases?
 63 2012-09-11 03:30:05 <slush> How do you solve notification about new blocks in BIPs?
 64 2012-09-11 03:30:24 <slush> Let me guess - long polling?
 65 2012-09-11 03:30:51 <Luke-Jr> sure, it's proven to work well even with HTTP, and works fine over any transport
 66 2012-09-11 03:31:29 <slush> Did you read the beginning of my doc? There's really no reason to defend it by "it even runs on HTTP"
 67 2012-09-11 03:31:50 <Luke-Jr> it doesn't need to use a separate connection, though
 68 2012-09-11 03:32:09 <Luke-Jr> and I don't know what trouble you've had with it, but it works just fine for me (and most pools)
 69 2012-09-11 03:34:32 <Luke-Jr> btw, single quotes aren't valid as string delimiters in JSON :P
 70 2012-09-11 03:35:02 <slush> I know, I should fix it, wrote it off my head :(
 71 2012-09-11 03:36:00 <slush> All reasons why I described it as it is are in the docs. Including why long polling is hell
 72 2012-09-11 03:36:11 <slush> And I think that you're the only poolop who like LP :)
 73 2012-09-11 03:36:49 <Luke-Jr> tbh, I'm writing a similar example using GBT, and finding Stratum's to be much more complex in practice :p
 74 2012-09-11 03:37:48 <slush> why exactly?
 75 2012-09-11 03:38:31 <Luke-Jr> just the initial setup work so far ???
 76 2012-09-11 03:38:42 <doublec> what is GBT?
 77 2012-09-11 03:38:51 <Luke-Jr> doublec: BIP 22
 78 2012-09-11 03:39:02 <doublec> oh getblocktemplate
 79 2012-09-11 03:39:05 <doublec> thanks
 80 2012-09-11 03:39:15 <slush> with socket based protocol where shitty miners are not polling me every second, I can handle thousands of connections per server core
 81 2012-09-11 03:39:22 <slush> no way to do it with http and lp
 82 2012-09-11 03:39:27 <Luke-Jr> so don't use HTTP
 83 2012-09-11 03:39:29 <Luke-Jr> LP != HTTP
 84 2012-09-11 03:39:39 <slush> I know
 85 2012-09-11 03:39:43 <slush> there's no reason for LP
 86 2012-09-11 03:40:06 <slush> lp is just workaround for restricted environments
 87 2012-09-11 03:40:09 <slush> like HTTP
 88 2012-09-11 03:40:43 <doublec> use zeromq - no sockets, no http :)
 89 2012-09-11 03:42:39 <slush> doublec: what's wrong with sockets? :)
 90 2012-09-11 03:44:16 <doublec> slush: nothing :)
 91 2012-09-11 03:49:40 <jrmithdobbs> note to self, post that shit to twitter immediately to get immediate feedback next time
 92 2012-09-11 03:49:44 <jrmithdobbs> lol
 93 2012-09-11 04:20:10 <wumpus> zeromq great within systems, but is not safe for use over the internet (at least last time I checked it out)
 94 2012-09-11 04:23:10 <jrmithdobbs> why the fuck does github have markdown or wtfever in comments, it makes talking about C/C++ code fucking infuriatingly annoying
 95 2012-09-11 04:23:38 <wumpus> well the markdown is ok.. the annoying thing is that it supports a html subset as well so swallows <
 96 2012-09-11 04:24:21 <wumpus> but yes the * can be annoyting too :-)
 97 2012-09-11 04:24:39 <wumpus> always put code fragments between ` quotes
 98 2012-09-11 04:25:23 <Luke-Jr> I think if you put ```C++ for the start, it will even do syntax highlighting :p
 99 2012-09-11 04:26:38 <wumpus> yes you can make it syntax highlight
100 2012-09-11 04:34:42 <slush> Luke-Jr: do you have any example how looks submit from BIP22/23 miner?
101 2012-09-11 04:34:53 <slush> Luke-Jr: is there any other standard than serialized block?
102 2012-09-11 04:35:02 <slush> aka submitblock() call
103 2012-09-11 04:35:35 <Luke-Jr> that's the simplest submission, but you can use extensions to make it less bandwidth heavy
104 2012-09-11 04:35:55 <Luke-Jr> if you don't allow miners to change transactions, for example
105 2012-09-11 04:36:33 <Luke-Jr> Add "submit/truncate" to the "mutations" Array, and miners can send you just the header, for example
106 2012-09-11 04:36:38 <Luke-Jr> https://en.bitcoin.it/wiki/BIP_0023#Submission_Abbreviation
107 2012-09-11 04:36:54 <Luke-Jr> "submit/coinbase", "share/truncate" might make a bit more sense, though ???
108 2012-09-11 04:38:13 <slush> well, you still have to validate coinbase transaction
109 2012-09-11 04:39:32 <jrmithdobbs> Luke-Jr: <3 you opened up that cheapshot and i couldn't resist ;p
110 2012-09-11 04:41:18 <slush> Luke-Jr: honestly I cannot imagine that any miner can implement all that stuff correctly
111 2012-09-11 04:41:23 <slush> don't say it's "easy"
112 2012-09-11 04:41:51 <jrmithdobbs> Luke-Jr: (re: github comment, not this bip discussion)
113 2012-09-11 04:41:57 <slush> and if there's no strict standard, how can miner know what to support and what not. When poolop can pick any optional feature he likes
114 2012-09-11 04:42:38 <Luke-Jr> slush: the same way miners know what getwork extensions to support or not
115 2012-09-11 04:43:32 <slush> yes, that's awkward as well
116 2012-09-11 04:43:46 <slush> I was reffering these "magic" http headers in my post too ;)
117 2012-09-11 04:44:09 <Luke-Jr> it's awkward because they're out of band only :p
118 2012-09-11 04:44:40 <slush> like ufasoft expects x-long-polling header even in long polling response. wtf
119 2012-09-11 04:44:49 <slush> I find it out last week
120 2012-09-11 04:45:20 <Luke-Jr> makes sense to fix problems in revision, not throw the whole concept out because problems existed
121 2012-09-11 04:47:22 <slush> well, I created new revision of getwork and I call it stratum
122 2012-09-11 04:47:29 <slush> it fixes all known issues with previous revision
123 2012-09-11 04:47:30 <slush> :P
124 2012-09-11 04:48:50 <Luke-Jr> slush: I call it Betamax :<
125 2012-09-11 04:51:36 <Luke-Jr> slush: do you really expect to throw away months of open development and design thought, for a limited subset developed in secret?
126 2012-09-11 04:52:50 <jrmithdobbs> Luke-Jr: do you forget you're talking bitcoin? ha
127 2012-09-11 04:54:21 <Luke-Jr> jrmithdobbs: >_<
128 2012-09-11 05:04:12 <midnightmagic> aaargh what does >_< mean
129 2012-09-11 05:06:15 <jrmithdobbs> usually that the person saying it is an anime nerd ragingg against the smiley man and can be ignored... little confused by luke's use
130 2012-09-11 08:19:06 <LolcustBackup> while I'm not exactly the person to judge mining/pooling things, but slush 's stuff is quite comprehensible at my level of understanding
131 2012-09-11 08:24:51 <LolcustBackup> meanwhile BIP 22/23 read like some arcane grimoire devoted to witchcraft and summoning Yog-Sothoth
132 2012-09-11 08:25:45 <LolcustBackup> of course, they are probably more versatile but oh boy the complexity....
133 2012-09-11 08:29:34 <sipa> well, slush's text is an explanation; bip22 is just a formal specification
134 2012-09-11 08:30:45 <sipa> they do have different purpose too; BIP22 allows local block construction
135 2012-09-11 08:31:21 <sipa> so it allows miners to see which transactions are going to end up in the block, or even modify them
136 2012-09-11 08:39:45 <LolcustBackup> well, I do understand that 22nd allows for local block construction (which I suppose might become needed when pool server can no longer cope with work generation needs)...
137 2012-09-11 08:40:57 <LolcustBackup> it's just that as it stands, it seems massively complex and way over my head when I try to grok it as a whole
138 2012-09-11 08:42:29 <sipa> the idea is not very complex: you get a list of metadata for transactions to be included plus some requirements for the header
139 2012-09-11 08:42:42 <LolcustBackup> maybe luke-jr should, I don't know, make something like a "case-action" explanation (and a comic ;) )
140 2012-09-11 08:42:54 <doublec> bip 22 suffers from a lack of example usage
141 2012-09-11 08:43:00 <sipa> indeed
142 2012-09-11 08:43:20 <doublec> if this, then that, else maybe this, unless they include that, then maybe this
143 2012-09-11 08:43:23 <doublec> very hard to follow
144 2012-09-11 08:44:07 <doublec> slush and btcguild's proposals are a cakewalk to implement in comparison
145 2012-09-11 08:44:50 <LolcustBackup> exactimundo, doublec
146 2012-09-11 08:45:22 <doublec> which is a little unfair to Luke-Jr since feedback could be provided earlier
147 2012-09-11 08:45:28 <doublec> but the complexity puts me off
148 2012-09-11 08:46:08 <doublec> LolcustBackup: long time no hear from :)
149 2012-09-11 08:54:17 <LolcustBackup> yeah, doublec, had a lot of things happen in so-called RL... changed careers. now back to scheming tbx revival and having other forms of fun in the coinmunity ))
150 2012-09-11 12:43:15 <shamoon> if i run ./bitcoind with -addnode=x.x.x.x -addnode=y.y.y.y, will it definitely connect to those nodes (if they are valid bitcoin nodes)?
151 2012-09-11 12:44:41 <sipa> it will definitely try
152 2012-09-11 12:44:51 <shamoon> what conditions would cause it to not connect?
153 2012-09-11 12:49:27 <gmaxwell> shamoon: not being able to, being at max connections, IIRC.
154 2012-09-11 12:49:34 <shamoon> ahh, gotcha
155 2012-09-11 12:56:00 <helo> are devs generally supportive of colored coins?
156 2012-09-11 12:57:24 <kjj_> they seemed interested to me, but not exactly jumping at the chance to make the stock client deal with them in special ways
157 2012-09-11 12:58:12 <helo> i guess it gives some direction to how the coin control interface should work
158 2012-09-11 12:58:26 <sipa> the nice thing about colored coins is that it doesn't require upgrading every client
159 2012-09-11 12:58:29 <helo> at least to make it straightforward to avoid mixing coins from one source with coins from another
160 2012-09-11 12:58:46 <sipa> if you're using colored coins, you'll be using a client that supports them
161 2012-09-11 12:58:59 <sipa> otherwise there would be no point in receiving them in the first place
162 2012-09-11 12:59:04 <kjj_> sipa: the poor thing about colored coins is that they are just coins, waiting to get shuffled randomly off to the ether the first time someone accidently runs the stock client on them
163 2012-09-11 12:59:37 <helo> which would be the same mechanism in standard coin control where you might mark an input as "do not send or count as part of bitcoin balance"
164 2012-09-11 12:59:38 <sipa> you shouldn't send coins to someone who isn't expecting them ever; that is even more true for colored coins
165 2012-09-11 13:00:11 <kjj_> sipa: I'd still rather have a totally distinct structure
166 2012-09-11 13:00:37 <sipa> sure, that has more elegance, but is much harder to do practically
167 2012-09-11 13:00:46 <kjj_> following the orders of inputs and outputs seems hack-ish
168 2012-09-11 13:00:50 <helo> so the interface would only need to allow someone to label an input (or group of inputs), and mark them "do not send". and then allow them to be manually sent.
169 2012-09-11 13:01:39 <sipa> but typically you'll assign some meaning to some colored coins
170 2012-09-11 13:01:50 <helo> i guess one would create "groups" of coins, and could select each group's label (via combobox) to switch the client to report and send from that group
171 2012-09-11 13:01:50 <sipa> more than just it being a colored coin
172 2012-09-11 13:02:03 <kjj_> my idea was for a chain to handle financial instruments (not cash), but still use bitcoin addresses so that a corporate officer, for example, could query which addresses held them at a given block so they could pay dividends
173 2012-09-11 13:02:46 <gmaxwell> helo: I think things people have talked about doing with them are generally daft... but they're a least bad option from what I can tell.
174 2012-09-11 13:02:50 <kjj_> but that chain's software would need to understand the meanings of things so that it could enforce the network rules
175 2012-09-11 13:03:57 <epscy> colored coins sounds sort like the accounts system in the stock client
176 2012-09-11 13:04:06 <helo> yeah
177 2012-09-11 13:04:18 <sipa> epscy: they're completely unrelated
178 2012-09-11 13:04:31 <sipa> accounts have nothing to do with labeling individual coins
179 2012-09-11 13:04:56 <gmaxwell> They're similar to the extent that they both apply local meaning to global data... but thats about where it ends.
180 2012-09-11 13:05:22 <kjj_> and coloring breaks down if you want to do quantities
181 2012-09-11 13:06:30 <epscy> i don't really understand coloring coins, everything i have read about reminds me of open transaction
182 2012-09-11 13:06:36 <gmaxwell> kjj_: huh?
183 2012-09-11 13:06:45 <gmaxwell> epscy: you're getting confused by hype then.
184 2012-09-11 13:07:10 <helo> gmaxwell: can you explain where the similarities end?
185 2012-09-11 13:07:13 <kjj_> maybe I should read the proposal again, but the one I read watched the order of inputs and outputs
186 2012-09-11 13:07:20 <helo> rather, an example
187 2012-09-11 13:07:36 <gmaxwell> epscy: somehow you and I agree that code 12345 signifies owership of the car that is currently mine.  Then 12345 can be spent and there is a rule to determine which output gains the new color. In this way bitcoin tracks the ownership of the car.
188 2012-09-11 13:08:19 <gmaxwell> (you could use whatever rule you want to decide which of multiple outputs the color folows, and different applications might have different rules)
189 2012-09-11 13:08:27 <epscy> can the 12345 be spent partially?
190 2012-09-11 13:08:44 <gmaxwell> epscy: no input can be 'spent partially' that just isn't how bitcoin works.
191 2012-09-11 13:09:28 <Luke-Jr> gmaxwell: but there can be multiple outputs
192 2012-09-11 13:09:30 <gmaxwell> every coin is spent complete. You could spent it to two outputs, one being change... and then your rule determins how the color flows. Maybe to the first output, maybe to the largest. Perhaps your color has a quantity which is proportional to the value. etc.
193 2012-09-11 13:09:50 <gmaxwell> The rule you use is just part of how the color your tracking is defined.
194 2012-09-11 13:09:53 <helo> it seems that a simple rule would be to never send colored coin with non-colored coin... i guess needing to pay fees requires mixing...
195 2012-09-11 13:10:15 <Luke-Jr> helo: no, you'd often WANT to send coloured with non
196 2012-09-11 13:10:33 <Luke-Jr> helo: for example, this way you guarantee payment for the deed
197 2012-09-11 13:10:59 <Luke-Jr> (inputs are car and payment for car; outputs are payee and buyer; both parties sign)
198 2012-09-11 13:11:34 <helo> ahh, that is kind of neat
199 2012-09-11 13:11:57 <gmaxwell> helo: I think the example implementation just had the color followed the first output. So you have a 1BTC deed holder, then you and the person buying the car jointly write a transaction that takes as input the sale price (provided by him), and the deed coin, and output the deed coin to him and the sale price to you.
200 2012-09-11 13:12:06 <gmaxwell> and so that transaction atomically confirms or it doesn't.
201 2012-09-11 13:12:14 <Luke-Jr> gmaxwell: I don't like that model because it prohibits barter :p
202 2012-09-11 13:12:39 <helo> it kind of throws transaction fee cost calculation out the window
203 2012-09-11 13:12:42 <gmaxwell> Luke-Jr: well then you just use an escrow style transaction and do whateve.r
204 2012-09-11 13:12:55 <kjj_> also, it has the quantity problem
205 2012-09-11 13:12:57 <helo> if 1 satoshi can represent ownership of a multi-billion-dollar business
206 2012-09-11 13:12:58 <gmaxwell> helo: how so? you'd just include whatever exces you what as fee and not take it in the output.
207 2012-09-11 13:13:09 <Luke-Jr> helo: no? O.o
208 2012-09-11 13:13:18 <sipa> helo: better, 0 satoshi can represent the same :)
209 2012-09-11 13:13:27 <gmaxwell> helo: fees have ~nothing to do with value except for the anti dustspam thing.
210 2012-09-11 13:13:59 <Luke-Jr> (you can't reliably identify value of a txn anyway)
211 2012-09-11 13:14:06 <gmaxwell> kjj_: it doesn't??? if you want a divisible color you can just define some bitcoin value and use that. (then you have to have a color rule that has the first N btc in output value is colored.
212 2012-09-11 13:14:19 <helo> err yeah, the fees would just have to cover its value-in-bitcoin
213 2012-09-11 13:14:34 <gmaxwell> helo: fees aren't based on bitcoin values, not sensible to do so.
214 2012-09-11 13:14:47 <helo> which will be less than its "colored" value
215 2012-09-11 13:15:47 <kjj_> gmaxwell: the network won't enforce that.  what happens when a transaction takes 2 colored and 3 uncolored and outputs 2.5 and 2.5?
216 2012-09-11 13:15:57 <Luke-Jr> helo: fees already don't care if you're sending 5 BTC or 50000 BTC. nor is there any reliable way for miners to know which
217 2012-09-11 13:16:26 <sipa> kjj_: you'd assign a map<color,amount> to each txout
218 2012-09-11 13:17:00 <sipa> so the first 2.5 output would have value 2.5 color, and the second one 0.5 color
219 2012-09-11 13:17:01 <helo> i thought miners look at age as well as size. (where size ~= value)
220 2012-09-11 13:17:23 <sipa> helo: weighted age of the inputs
221 2012-09-11 13:17:29 <kjj_> sipa: ugh.  I don't think I'm alone in thinking that that sucks
222 2012-09-11 13:17:31 <helo> not size in kB, but size in bitcoin amount, that is
223 2012-09-11 13:17:31 <sipa> helo: not of the payment (which is unknown)
224 2012-09-11 13:17:41 <gmaxwell> helo: size is the _data size_, and the regular anti-dos priority rules (which have nothing to do with fees other than if your txn gets qualified as free) do look at age, yes.
225 2012-09-11 13:17:45 <epscy> it doesn't seem like colored coins are something we desperately need
226 2012-09-11 13:18:00 <epscy> all this stuff can be done with or without it at the moment
227 2012-09-11 13:18:05 <sipa> kjj_: not arguing for or against; just saying that sane semantics are possible
228 2012-09-11 13:18:19 <gmaxwell> helo: fee calculation is purely fee/datasize, and ignoring fees on txn where the fee is pure dust.
229 2012-09-11 13:18:30 <kjj_> epscy: the idea is that bitcoin doesn't need to support it, it is something people can do on their own and piggyback on bitcoin's security
230 2012-09-11 13:18:37 <helo> i guess to core bitcoin developers, there isn't anything to be done to "support" colored bitcoin
231 2012-09-11 13:18:44 <gmaxwell> helo: right.
232 2012-09-11 13:18:58 <gmaxwell> And right, I agree that at the moment it does nothing useful.
233 2012-09-11 13:20:51 <helo> so if someone bought a vps, the vps provider could send a "colored" satoshi to the paying address. maybe whichever address owns that satoshi could be the one used for authentication?
234 2012-09-11 13:21:14 <helo> so one person could buy a vps, and then send the auth satoshi to someone else's address to allow them to use it instead
235 2012-09-11 13:21:26 <gmaxwell> helo: sure, but what really did this accomplish? if the vps provider wants to rip you off they still can.
236 2012-09-11 13:21:47 <gmaxwell> helo: and you could just change the password for it. Or hand over the key and let them change the password.
237 2012-09-11 13:22:22 <gmaxwell> Smartproperty is of questionable value without transparent tamperproof hardware, which is an impossiblity; though perhaps it could be approximated well enough to do something useful.
238 2012-09-11 13:25:14 <jgarzik> the value is in ownership tracking and transfer, without VPS provider intervention
239 2012-09-11 13:26:17 <jgarzik> In the distributed bond example, the bond writer will pay interest to whomever holds the bond
240 2012-09-11 13:26:19 <gmaxwell> jgarzik: in that case the value is meaningless without the VPS provider's good graces (or reputational upkeep); and if you assume the vps provider will behave then you can do far simpler things. Like just have them sign a contract with their well known public key.
241 2012-09-11 13:26:35 <jgarzik> amiller: httpsrv going?  :)  I'm gonna have to move forward without, otherwise :/
242 2012-09-11 13:26:46 <gmaxwell> sure. well, I was talking about smart property there. Not bonds.
243 2012-09-11 13:26:47 <jgarzik> wanna get bonds going for the trip
244 2012-09-11 13:27:01 <jgarzik> aren't bonds a subset of smart property?
245 2012-09-11 13:27:29 <helo> gmaxwell: the assumption with colored bitcoin is that it is backed by a trusted entity, that will be required to track the movement of the colored coin they issue
246 2012-09-11 13:27:48 <gmaxwell> I don't think so? the bond itself has no existance.  At least I thought smart property refered to resources (like cars and computers) that identified their ownership through blockchain data.
247 2012-09-11 13:28:17 <gmaxwell> helo: huh? anyone aware of and interested in the asset can track it. Thats completely decenteralized.
248 2012-09-11 13:29:19 <gmaxwell> helo: giving the asset meaning ??? e.g. when it's controlling a VPS or whatever??? may be another matter, but it depends on the application.
249 2012-09-11 13:29:44 <helo> gmaxwell: i mean as far as it being worth more than its value in bitcoin, the issuer would follow it and, for example, give gold ounces to whoever comes in and demonstrates ownership of their colored coin
250 2012-09-11 13:30:07 <gmaxwell> in the case of bond the centeralized party is the bond issuer, ... and without their good graces the dividends just don't happen. So, indeed you might as well just have them track the ownership changes.
251 2012-09-11 13:31:02 <gmaxwell> helo: right but a color could be used for other things. It could be used, for example, to indicate membership in the satoshi-super-31337 club.. anyone who holds coin tracable to block 1's genesis is a member. :)  There is no centeral party in that example.
252 2012-09-11 13:31:31 <gmaxwell> (you can prove to anyone you're a holder with a sign message, and a list of your 6 degrees of bacon transaction list)
253 2012-09-11 13:31:31 <kjj_> gmaxwell: that's why I think that trying to put payment policy in the system is a bit silly
254 2012-09-11 13:44:02 <helo> would the resulting blockchain bloat be bad?
255 2012-09-11 13:48:22 <gmaxwell> helo: coloring doesn't add any size, though it might add txn volume. Hard to say, depends on the application.
256 2012-09-11 14:02:26 <helo> how would a UI for accounts differ from a UI to allow safe manipulation of colored coin?
257 2012-09-11 14:02:37 <helo> presumably a UI for accounts would include coin control
258 2012-09-11 14:02:48 <helo> which seems to be what colored coin handling requires
259 2012-09-11 14:06:37 <helo> ignoring the two-party "deed transfer" use case...
260 2012-09-11 14:07:45 <amiller> jgarzik, yeah move on without me, i may catch up later
261 2012-09-11 14:38:21 <MC1984> Hub Nodes - A list of the most well connected bitcoin super nodes.
262 2012-09-11 14:38:22 <MC1984> what
263 2012-09-11 14:38:49 <gmaxwell> Context?
264 2012-09-11 14:51:39 <MC1984> blockchain.info
265 2012-09-11 14:51:56 <MC1984> http://blockchain.info/hub-nodes
266 2012-09-11 14:53:14 <eian> I am collecting my own data on hub-nodes - I have a different result set
267 2012-09-11 14:53:32 <eian> actually, very different at first glance
268 2012-09-11 14:54:30 <eian> I wish there was a way to download a csv from blockchain.info
269 2012-09-11 14:56:38 <MC1984> i said things like this would probably be an emergent property of bitcoin
270 2012-09-11 14:56:51 <MC1984> even without any sort of network logic towards this end
271 2012-09-11 14:56:56 <MC1984> perhaps there should be
272 2012-09-11 14:57:17 <MC1984> but i was told its vulnerable to attacks or womthing
273 2012-09-11 14:57:28 <jgarzik> I'm terribly disappointed
274 2012-09-11 14:57:40 <jgarzik> maybe I need to -addnode blockchain.info and some other key sites, to get my hubs on the list
275 2012-09-11 14:57:51 <jgarzik> or just increase the outbound connection count
276 2012-09-11 14:58:03 <MC1984> whats the optimal number
277 2012-09-11 14:58:14 <jgarzik> being on the fallback node list _and_ listed in a DNS seed apparently isn't enough
278 2012-09-11 14:58:26 <MC1984> isnt there any research on optimal # of interconnects for x mesh net size
279 2012-09-11 14:58:28 <eian> Optimal might be a uniform distribution for relay counts across all nodes
280 2012-09-11 14:58:36 <jgarzik> should probably add a bunch of pools as direct connects
281 2012-09-11 14:59:06 <jgarzik> 
ACTION had hoped for something more organic

282 2012-09-11 14:59:20 <eian> jgarzik, I have my own data set
283 2012-09-11 14:59:26 <eian> it doesn't look that skewed on my end
284 2012-09-11 14:59:37 <denisx> does addnode still only connects once and then tries never again?
285 2012-09-11 15:00:39 <jgarzik> eian: do you see in your list us2.exmulti.net, us4.exmulti.net or eu3.exmulti.net (alster013.startdedicated.com)
286 2012-09-11 15:01:13 <eian> jgarzil, I will let you know in a few
287 2012-09-11 15:01:18 <eian> one sec
288 2012-09-11 15:02:40 <eian> also, I don't know what interval of time blockchain.info is looking at for these intervals? is the relay count within one hour? one day?
289 2012-09-11 15:04:22 <MC1984> i think there might be quite a few stats on that site that are bollocks
290 2012-09-11 15:04:47 <eian> jgarzik, we are connected to you on ports 8333 and 8334
291 2012-09-11 15:04:58 <eian> for us2
292 2012-09-11 15:05:06 <eian> let me see the relay counts
293 2012-09-11 15:08:00 <eian> us2.exmulti.net has sent 133095 total relays between a time period of July 24th to Sept 1st
294 2012-09-11 15:08:54 <jgarzik> eian: that means 133,095 transactions were seen first from us2, before other nodes?
295 2012-09-11 15:09:18 <eian> us4.exmulti.net has sent 132986 total relays between a time period of July 24th to Sept 1st
296 2012-09-11 15:09:22 <eian> Not the first, just in total
297 2012-09-11 15:09:26 <jgarzik> ok
298 2012-09-11 15:10:35 <eian> eu3.exmulti.net has sent 133153 total relays between a time period of July 24th to Sept 1st
299 2012-09-11 15:10:51 <gmaxwell> 09:58 < MC1984> isnt there any research on optimal # of interconnects for x mesh net size
300 2012-09-11 15:10:56 <gmaxwell> Optimal is not what you want.
301 2012-09-11 15:11:15 <gmaxwell> the amount of data exchanged in bitcoin is very small.
302 2012-09-11 15:11:23 <eian> jgarzik, I have more recent data, but it takes a while to process
303 2012-09-11 15:11:25 <gmaxwell> What you want is secure without wasing enormous amounts of resources.
304 2012-09-11 15:11:33 <MC1984> in terms of hops
305 2012-09-11 15:11:38 <gmaxwell> And randomly wired graphs of decent order get that pretty well.
306 2012-09-11 15:11:42 <eian> jgarzik, I even have a list of all tx's you've relayed :)
307 2012-09-11 15:11:45 <MC1984> seeing as prop latency is ahuge issue now
308 2012-09-11 15:11:55 <gmaxwell> MC1984: the hop minmizing network is for all nodes to connect to all others.
309 2012-09-11 15:12:13 <MC1984> yes but thats insane
310 2012-09-11 15:12:23 <MC1984> a balance could be struck
311 2012-09-11 15:12:30 <MC1984> hence i wondered i there was research
312 2012-09-11 15:12:55 <gmaxwell> MC1984: the only latency that matters (block propagation) really has little to do with the network topology. It gets high now because blocks take a long time to process and there are a high number of slow nodes.
313 2012-09-11 15:13:13 <MC1984> oh
314 2012-09-11 15:14:14 <eian> about tx propagation - a tx lives on the network for about 40 minutes (median time)
315 2012-09-11 15:14:19 <gmaxwell> MC1984: there is lots of research into efficient multicast distribution. (google Steiner tree problem) But all the efficient solutions result in networks where a single cut partitions, meaning they'd be highly vulnerable to attackers.
316 2012-09-11 15:15:24 <MC1984> ah yes partitioning is ultra bad in this case
317 2012-09-11 15:16:37 <eian> about tx propagation - I have seen inv messages that advertise a tx for weeks
318 2012-09-11 15:16:46 <MC1984> still, it seems like people are manually peering for efficiency anyway, which might still give you your single break = partitioned netowrk scenario
319 2012-09-11 15:19:21 <gmaxwell> MC1984: er, manually peering doesn't replace the randomly wired network, it's in addition to it.. so it can't reduce security.
320 2012-09-11 15:19:47 <gmaxwell> (I mean, I suppose some people are disabling the normal networking, which we don't make terribly easy to do accidentally, but .. well, sucks to be them)
321 2012-09-11 15:20:17 <MC1984> not replace, but by definition the random links will be the less efficient ie less able to take the load if a fat link goes down
322 2012-09-11 15:20:20 <MC1984> have i got taht right?
323 2012-09-11 15:20:24 <gmaxwell> eian: they advertise a tx for weeks because the source is continually reannouncing it ever half hour or so while its unconfirmed.
324 2012-09-11 15:21:39 <eian> It's seems that anything longer than a few days seems excessive
325 2012-09-11 15:21:40 <gmaxwell> MC1984: 'huh'?  Bitcoin's peak average datarate is about 13.3kbit/sec on average. No one cares much about very low latency except miners, who can presumably take care of themselves.
326 2012-09-11 15:21:56 <gmaxwell> eian: why? their transaction hasn't been confirmed yet. They'll continue forever.
327 2012-09-11 15:26:56 <ThomasV> tcatm: http://bitcoincharts.com/charts/mtgoxUSD#rg10ztgSzm1g10zm2g25zv <-- it is broken
328 2012-09-11 15:27:54 <MC1984> oh good charts is back
329 2012-09-11 15:38:26 <firelegend> When EC multiplication is done with base point, what does it multiply against?
330 2012-09-11 15:46:03 <kjj_> firelegend: context?
331 2012-09-11 15:49:06 <firelegend> kjj_:Context?
332 2012-09-11 15:49:16 <kjj_> you asked about EC multiplication
333 2012-09-11 15:49:30 <jrmithdobbs> btw, on that build update request .... I'm pretty sure static builds are completely broken as is anyways with makefile.unix
334 2012-09-11 15:49:43 <firelegend> Yes, when you need to figure out anything from a private key, you do EC multiplication. I just wondered what it multiplied with.
335 2012-09-11 15:49:47 <jrmithdobbs> I'm trying off master now but even re-adding -ldl it will not build with STATIC=all at all!
336 2012-09-11 15:49:54 <jrmithdobbs> Luke-Jr: ^
337 2012-09-11 15:50:26 <jrmithdobbs> (as in, read: so why am I trying to work around something that is already broken without my changes?)
338 2012-09-11 15:50:29 <kjj_> well, EC multiplication takes two operands, just like regular multiplication
339 2012-09-11 15:50:46 <firelegend> Yes, and one should be the private key.
340 2012-09-11 15:50:53 <firelegend> And the other is...context?
341 2012-09-11 15:51:05 <kjj_> when you create a public key from a private key, you multiply the generator of the curve you are using by the private key
342 2012-09-11 15:51:20 <firelegend> Ah.
343 2012-09-11 15:51:55 <kjj_> I'm not sure what actually gets used when signing something.  I only studied it enough to figure out how to manipulate keys.
344 2012-09-11 15:53:16 <firelegend> I was just experimenting with private keys from low values like 1 to 10.
345 2012-09-11 15:58:41 <firelegend> It is also fun to experiment with different values. For instance, the block hashes(which should be numbers) can also be used as private keys(though a little insecure probably) :)
346 2012-09-11 15:59:11 <kjj_> any random value can be used as a private key
347 2012-09-11 15:59:36 <kjj_> but the curve has less than 2^256 values, so some of them wrap around and are totally insecure
348 2012-09-11 15:59:45 <firelegend> wrap around?
349 2012-09-11 16:01:20 <kjj_> the EC field is finite, and has fewer possible values than 2^256
350 2012-09-11 16:01:48 <kjj_> if you start from the maximum value and count up, you get MAX, 0, 1, 2, 3 etc.
351 2012-09-11 16:01:53 <firelegend> kjj_:Yes, I found that out today by dividing 2^256 by the max possible number governed by secp256k1
352 2012-09-11 16:02:17 <firelegend> oh, that doesn't sound nice.
353 2012-09-11 16:02:27 <kjj_> so, if your random key is too big, it is the same as only having a few bits of key length
354 2012-09-11 16:02:48 <firelegend> This website is useful, http://gobittest.appspot.com/
355 2012-09-11 16:02:56 <firelegend> But it crashes when the number is exceeded.
356 2012-09-11 16:03:11 <jrmithdobbs> sipa / gmaxwell / Luke-Jr / BlueMatt / denisx: can any of you build with STATIC=all on current master on any of the platforms you use? As far as I can see this was broken before i got to it. It's a glibc thing related to their getaddrinfo implementation it looks like. STATIC=1 works fine on master but breaks on my change on linux. STATIC=all is completely broken.
357 2012-09-11 16:03:25 <firelegend> Wow, major highlight.
358 2012-09-11 16:03:42 <Joric> firelegend, nice private key harvester
359 2012-09-11 16:04:11 <firelegend> Joric:That website is not mine, but is useful in trying random values you can dig around.
360 2012-09-11 16:04:26 <jrmithdobbs> and STATIC=1 is pretty worthless since it builds statically all the stuff that has constant security problems but dynamically links pthread/libz and that's it
361 2012-09-11 16:04:47 <kjj_> jrmithdobbs: you always run into problems with the dlopen
362 2012-09-11 16:05:22 <firelegend> Though implementing the private key thing was rather easy in Java, since all you needed to do was set the curve and do curve.multiply(privatekey).getEncoded();
363 2012-09-11 16:05:26 <jrmithdobbs> kjj_: there's nothing in bitcoin that actually *uses* dlopen directly, real static builds are barely possible on anything using pthreads anyways
364 2012-09-11 16:05:30 <jrmithdobbs> I'm not seeing the value
365 2012-09-11 16:07:31 <kjj_> jrmithdobbs: I don't see the point either, but it was beyond my skills to solve, and STATIC=1 was static enough for what I wanted to do, so I just gave up
366 2012-09-11 16:09:57 <phantomcircuit> jrmithdobbs, getaddrinfo requires dynamic linking
367 2012-09-11 16:10:01 <phantomcircuit> it's dumb as hell
368 2012-09-11 16:14:13 <jgarzik> phantomcircuit: static linking to libc would be dumb as hell
369 2012-09-11 16:14:57 <phantomcircuit> jgarzik, generally speaking that's true
370 2012-09-11 16:15:09 <phantomcircuit> except getaddrinfo actually has strange requirements beyond that
371 2012-09-11 16:15:35 <phantomcircuit> so if for example you're building an initrd image using static binaries
372 2012-09-11 16:15:42 <phantomcircuit> you're gonna have a slightly annoying time
373 2012-09-11 16:37:17 <gavinandresen> Anybody know why I'm getting:  "/usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file or directory"  when gitian-building qt-win32 ??
374 2012-09-11 16:37:28 <gavinandresen> (from the gitian var/build.log)
375 2012-09-11 16:38:20 <kinlo> I'd say coz you're missing a file, but I feel like I'm stating the obvious...
376 2012-09-11 16:39:23 <wumpus> can you post the rest of the error message?
377 2012-09-11 16:40:57 <gavinandresen> https://gist.github.com/3700714
378 2012-09-11 16:42:48 <wumpus> wtf, why is it trying to build qmake with -m64
379 2012-09-11 16:42:56 <firelegend> Recently I thought of myself, that if Github supported some linkback to function definitions, that would make the platform even more user-friendly.
380 2012-09-11 16:43:24 <wumpus> I thought gitian built all the mingw stuff on the 32 bit vm
381 2012-09-11 16:43:26 <firelegend> *to myself
382 2012-09-11 16:43:51 <sipa> gavinandresen: gitian build of what? git head?
383 2012-09-11 16:44:04 <wumpus> of qt for win32
384 2012-09-11 16:44:11 <sipa> ah
385 2012-09-11 16:44:15 <wumpus> but it appears to be using the 64 bit image instead of the 32 bit one
386 2012-09-11 16:44:21 <gavinandresen> sipa ./bin/gbuild --commit bitcoin=HEAD ../bitcoin/contrib/gitian-descriptors/qt-win32.yml
387 2012-09-11 16:44:52 <wumpus> the qt build process first builds qmake for the local machine, then uses that to build for the target arch
388 2012-09-11 16:45:05 <wumpus> it fails on the very first file
389 2012-09-11 16:45:29 <wumpus> I'm sure the current qt-win32.yml worked here
390 2012-09-11 16:47:09 <gavinandresen> ok....  this is the same VM I successfully built rc2 on.  I wanted to get a step ahead and get the new qt dependency built
391 2012-09-11 16:47:38 <gavinandresen> Oh, I'm building using USE_LVM ...
392 2012-09-11 16:47:38 <gmaxwell> gavinandresen: thoughts on when the final realse will happen?
393 2012-09-11 16:47:48 <sipa> LVM? you mean LXC?
394 2012-09-11 16:48:02 <gavinandresen> Right, LXC...
395 2012-09-11 16:48:21 <wumpus> ok that could explain why it suddenly uses 64 bit -- that's never tested
396 2012-09-11 16:48:26 <gavinandresen> gmaxwell: when the showstopper bug if fixed
397 2012-09-11 16:48:41 <gmaxwell> gavinandresen: which one is the showstopper?
398 2012-09-11 16:48:47 <sipa> ipv6 rpc stuff
399 2012-09-11 16:48:56 <gmaxwell> ah, okay, I was only following that mindly.
400 2012-09-11 16:49:09 <gmaxwell> er mildly. I actually misread something and thought it was said to not be a showstopper.
401 2012-09-11 16:58:46 <sipa> gavinandresen: same error
402 2012-09-11 16:59:35 <gavinandresen> ok, must be a LXVMC thing then
403 2012-09-11 17:00:54 <sipa> i suppose some of the platform detection code fails
404 2012-09-11 17:01:27 <gavinandresen> My KVM (or am I misremembering that acronym too) machine should be up and running tomorrow
405 2012-09-11 17:02:27 <sipa> KVM = kernel virtual machine, LXC = linux containers, LVM = logical volume manager
406 2012-09-11 17:05:40 <freakazoid> Too many TLAs!
407 2012-09-11 17:06:12 <freakazoid> KVM is also keyboard, video, and mouse
408 2012-09-11 17:06:49 <sipa> yeah and LVM is also Las Vegas Monorail!
409 2012-09-11 17:07:52 <wumpus> well I think simply the package is missing that includes that stubs64.h file
410 2012-09-11 17:08:26 <sipa> maybe, maybe not; but the real problem is still that it builds in 64-bit mode...
411 2012-09-11 17:09:21 <wumpus> yes, but it's certainly possible to cross compile qt for win32 in 64 bit mode
412 2012-09-11 17:09:35 <wumpus> it's just that we never tested that possibility
413 2012-09-11 17:10:01 <sipa> huh, that makes no sense...
414 2012-09-11 17:10:23 <wumpus> the host system can be 64 bit
415 2012-09-11 17:10:46 <wumpus> qt first builds qmake for the host system
416 2012-09-11 17:10:53 <sipa> ah
417 2012-09-11 17:10:58 <wumpus> then uses that qmake to build for the target system
418 2012-09-11 17:11:02 <sipa> right
419 2012-09-11 17:12:00 <wumpus> /usr/include/gnu/stubs-64.h is in package libc6-dev on 64 bit ubuntu, and  libc6-dev-amd64 on 32 bit ubuntu
420 2012-09-11 17:14:03 <sipa> it's using a 32-bit VM, which means it's trying to use a 32-bit linux C compiler to build a 64-bit qmake?
421 2012-09-11 17:14:19 <wumpus> for gitian it's using a 32-bit VM
422 2012-09-11 17:14:33 <wumpus> all bets are off for LXC
423 2012-09-11 17:14:34 <sipa> yes, but it means we're building a 64-bit qmake
424 2012-09-11 17:14:47 <sipa> which makes no sense at all, as that won't tun in the 32-bit VM
425 2012-09-11 17:14:54 <sipa> *run
426 2012-09-11 17:15:14 <wumpus> in a 32 bit VM it works fine
427 2012-09-11 17:15:21 <wumpus> I've tested it with gitian
428 2012-09-11 17:15:32 <sipa> s/32-bit VM/32-bit chroot/
429 2012-09-11 17:15:58 <wumpus> I think it's because it's running a 32 bit linux os in 64 bit CPU mode :-)
430 2012-09-11 17:16:29 <sipa> ys, sounds pobable
431 2012-09-11 17:16:33 <wumpus> chroot doesn't change the processor mode to good old i386
432 2012-09-11 17:17:04 <sipa> there's linux32, which switches the CPU seen by a subprocess to 32-bit
433 2012-09-11 17:17:23 <wumpus> ok, that would probably make this work
434 2012-09-11 17:17:33 <sipa> i'm surprised that LXC doesn't use that
435 2012-09-11 17:18:27 <sipa> or maybe it does, but the Qt set uses more exotic methods for detecting its host
436 2012-09-11 17:19:13 <wumpus> indeed
437 2012-09-11 17:22:08 <wumpus> I wonder where it gets the idea to add -m64
438 2012-09-11 17:29:13 <wumpus> it simply uses uname
439 2012-09-11 17:30:09 <wumpus> if that returns x86_64, it uses qt mkspec linux-x86_64-g++, which adds -m64
440 2012-09-11 17:31:06 <wumpus> seems a pretty sane thing to do... ofc there might be a configure option to override the host system
441 2012-09-11 17:33:53 <sipa> running gbuild in linux32 seems to help
442 2012-09-11 17:33:56 <sipa> gavinandresen: ^
443 2012-09-11 17:34:47 <wumpus> QMAKESPEC=qws/linux-x86-g++ ./configure
444 2012-09-11 17:35:08 <sipa> gavinandresen: USE_LXC=1 linux32 bin/gbuild --commit bitcoin=HEAD ...
445 2012-09-11 17:35:25 <wumpus> hehe, that's possible too of course
446 2012-09-11 17:35:45 <sipa> though i think either lxc or gitian should be doing that for us
447 2012-09-11 17:41:05 <sipa> 118beff946faf30a7fb40c59e094ca62ee8bae8be357c4e5bc2b69817ba9eb24  qt-win32-4.7.4-gitian.zip
448 2012-09-11 17:41:08 <sipa> 8715fc65434ce3dae964cdcf2205d4afff8c2937de748d5cc7cd9efb7c90e3e6  qt-res.yml
449 2012-09-11 18:35:19 <jgarzik> getblocks 165036 to 000000000000076adfd2 limit 500
450 2012-09-11 18:35:19 <jgarzik> getblocks stopping at 165040 000000000000076adfd2
451 2012-09-11 18:35:20 <jgarzik> getblocks stopping at 165040 000000000000076adfd2
452 2012-09-11 18:35:27 <jgarzik> quite odd client behavior
453 2012-09-11 18:35:37 <jgarzik> (this is from the server log)
454 2012-09-11 18:40:57 <gavinandresen> sipa: linux32 fixed it, but my build doesn't match yours (but if I recall, that doesn't matter for final bitcoind...)
455 2012-09-11 18:41:00 <gavinandresen> 0b0a324274989506abfe65246ef728699e9b5282dfd4597c888f2e30c41e9bd0  qt-win32-4.7.4-gitian-r1.zip
456 2012-09-11 18:44:09 <sipa> i recall something similar
457 2012-09-11 18:46:04 <sipa> jgarzik: i believe that's the effect of the stuck-blockchain fix attempt #3
458 2012-09-11 18:46:14 <sipa> i wonder whether we shouldn't just disable that
459 2012-09-11 18:46:57 <sipa> the only thing it helps against is when someone's client changes rules incompatible (such as the clients with the too-early BIP16 switchover date)
460 2012-09-11 18:47:30 <sipa> when they switched to later builds with correct timestamp
461 2012-09-11 20:06:18 <TD> jgarzik: that's a bug in bitcoinj
462 2012-09-11 20:06:23 <TD> jgarzik: i fixed it the other day
463 2012-09-11 20:06:44 <TD> jgarzik: if the subver was logged you could see the peer was advertising itself as such
464 2012-09-11 20:09:01 <jgarzik> ah
465 2012-09-11 20:44:00 <BlueMattBot> Project Bitcoin build #58: FAILURE in 3 hr 47 min: http://jenkins.bluematt.me/job/Bitcoin/58/
466 2012-09-11 20:52:17 <weex> Luke-Jr: what's the name of your handy dandy transaction channel?
467 2012-09-11 20:52:27 <Luke-Jr> #bitcoin-watcfh
468 2012-09-11 20:52:28 <Luke-Jr> #bitcoin-watch
469 2012-09-11 20:55:01 <weex> thx, don't know what's up with #bitcoin-market
470 2012-09-11 21:01:58 <sturles> AFAIK #bitcoin-market use a feed from bitcoincharts, and the feed is down.
471 2012-09-11 22:25:36 <benjamindees> so, this is my running understanding of how locktime works... please correct me if it's wrong
472 2012-09-11 22:26:12 <benjamindees> I transmit a locked transaction, it is confirmed and added to the blockchain.
473 2012-09-11 22:26:31 <benjamindees> My balance doesn't change.
474 2012-09-11 22:27:11 <benjamindees> I create another transaction to spend the locked coins.  It is not confirmed until after the lock expires?
475 2012-09-11 22:27:23 <gmaxwell> no.
476 2012-09-11 22:27:39 <gmaxwell> You create a locked transaction. It can't be confirmed until the lock expires.
477 2012-09-11 22:28:26 <benjamindees> well something ain't right then.  how can I extract a raw transaction from the blockchain to verify it was locked?
478 2012-09-11 22:29:21 <gmaxwell> was locked in the past but the lock has since expired?  run getrawtransaction on it and use some non-existing tool to parse it out of the hex.. or add some code to bitcoin's rawtransaction decode to print it (I don't think it does now)
479 2012-09-11 22:29:54 <benjamindees> it does print it, and it's easy to verify from the hex since it's at the end
480 2012-09-11 22:32:08 <benjamindees> http://blockchain.info/tx/13e100dd08b6da0a7426ea520b0bb3ae54cef79dd045e2e4f7116023df3a5c95
481 2012-09-11 22:32:29 <benjamindees> that's the txid.  it shows as locked until block 198370.
482 2012-09-11 22:34:17 <gmaxwell> oh indeed, it does print it. cool.
483 2012-09-11 22:37:40 <benjamindees> and it was included in block 198359 :(
484 2012-09-11 22:44:42 <gmaxwell> 0_o
485 2012-09-11 22:45:35 <gmaxwell> I ... really wish people would test these things in testnet first. crap.
486 2012-09-11 22:47:51 <wizkid057> testnet? whats that? ;)
487 2012-09-11 22:48:01 <midnightmagic> holy crap there's a net where tests happen?!
488 2012-09-11 22:51:22 <Joric> blkindex wont open how to fix?
489 2012-09-11 23:10:32 <gmaxwell> So, did we previously know that nlocktime has always been broken?
490 2012-09-11 23:11:05 <gmaxwell> IsFinal can never be false.
491 2012-09-11 23:12:47 <wizkid057> dont people have to test this stuff before it's merged?
492 2012-09-11 23:13:19 <gmaxwell> wizkid057: day one bugs.
493 2012-09-11 23:13:57 <gmaxwell> and as I've mentioned before, the unit tests we have now are terrible in terms of confirmation bias... they mostly test things that pass.
494 2012-09-11 23:14:18 <jgarzik> gmaxwell: nlocktime has been disabled in the code since satoshi's time, yes
495 2012-09-11 23:14:37 <wizkid057> :(
496 2012-09-11 23:15:01 <jgarzik> requires a major effort to enable, at this point
497 2012-09-11 23:15:21 <jgarzik> I don't think anybody thought through all the issues, like DoS'ing
498 2012-09-11 23:16:19 <jgarzik> it leverages the mempool quite a bit more, and would force us to start thinking about mempool limits -- something we DO really need to do anyway.  But it turns up the heat quite a bit.
499 2012-09-11 23:17:40 <gmaxwell> jgarzik: are you confusing nlocktime with replacement, because replacement has dos and mempool limit issues, nlocktime doesn't.
500 2012-09-11 23:17:47 <gmaxwell> And I knew replacement was disabled.