1 2013-03-02 00:18:01 <denisx> the last diff change is only one day old but we already have 700 blocks since then?
2 2013-03-02 00:18:42 <denisx> hmm, no. bitcoincharts are messed up I thing
3 2013-03-02 00:18:44 <denisx> think
4 2013-03-02 02:05:14 <BTC_Bear> tcatm: Your site seems to be down.
5 2013-03-02 02:20:10 <tcatm> BTC_Bear: which?
6 2013-03-02 02:20:34 <BTC_Bear> bitcoincharts don't know if it is still down
7 2013-03-02 02:20:39 <BTC_Bear> or is that ngix now
8 2013-03-02 02:22:03 <tcatm> works fine here
9 2013-03-02 02:23:48 <BTC_Bear> it was down earlier, nvm then. sorry to bother.
10 2013-03-02 02:24:38 <BTC_Bear> it was 502 badgateway... meh
11 2013-03-02 04:14:02 <wladston> Would it be hard to make the Pynode client into an SPV light client ?
12 2013-03-02 04:35:46 <wladston> It seems that BitcoinJ is the only SPV client fully working as of now
13 2013-03-02 05:30:41 <muhoo> my god, it's UTXO not UTX0
14 2013-03-02 05:30:58 <muhoo> damned ascii
15 2013-03-02 05:32:17 <lianj> :D
16 2013-03-02 05:54:09 <muhoo> bee doing too much RS-232 and embedded programming
17 2013-03-02 05:54:41 <muhoo> there is no UTX1 or UTX2
18 2013-03-02 06:00:43 <petertodd> /join #bitcoin-otc
19 2013-03-02 06:04:52 <Luke-Jr> petertodd: already there
20 2013-03-02 06:05:52 <petertodd> need to stop hitting space before irc commands...
21 2013-03-02 06:42:46 <muhoo> ok here is the problem i'm having with fees. i don't see how to accept a payment that is > 1 input, because
22 2013-03-02 06:43:47 <muhoo> what if there are say 12 inputs, and the tx i'll need to pass on might have fees as a result (too big)? how could i know that before telling the customer what they owe? i could just eat the fees, but that sucks.
23 2013-03-02 06:44:25 <muhoo> i probably really need BIP32 to do this right, but i ain't waiting.
24 2013-03-02 06:46:10 <gmaxwell> I cannot comprehend how you think BIP32 has anything to do with your fees.
25 2013-03-02 06:46:23 <gmaxwell> Pass on? accept? what are you doing?
26 2013-03-02 06:47:39 <Diablo-D3> I think muhoo is confusing credit card fees with bitcoin fees
27 2013-03-02 06:47:56 <Diablo-D3> in the immoral world where people live on debt, the merchant pays fees
28 2013-03-02 06:48:01 <Diablo-D3> in bitcoin, the customer does
29 2013-03-02 06:48:03 <gmaxwell> pretty sure muhoo knows that bitcoin is sender pays.
30 2013-03-02 06:48:26 <muhoo> yes, i do know that. but i need to pass them on in this case.
31 2013-03-02 06:48:28 <Diablo-D3> then I don't understand his question
32 2013-03-02 06:48:31 <muhoo> because i'm an intermediary
33 2013-03-02 06:48:38 <Diablo-D3> muhoo: then you eat them.
34 2013-03-02 06:48:45 <Diablo-D3> you don't know the fee until the tx is already created
35 2013-03-02 06:48:58 <muhoo> cust buys song from me, i pass the payment on to musician in separate tx
36 2013-03-02 06:49:05 <gmaxwell> muhoo: how many inputs the person paying you used has no influence on the txn you subsiquently create.
37 2013-03-02 06:49:25 <Diablo-D3> gmaxwell: it technically does
38 2013-03-02 06:49:42 <Diablo-D3> gmaxwell: if he has a lot of high input count tx as input, he will invariably have high input count tx as output
39 2013-03-02 06:49:54 <gmaxwell> Gibberish.
40 2013-03-02 06:50:13 <Diablo-D3> why?
41 2013-03-02 06:50:25 <Diablo-D3> oh right
42 2013-03-02 06:50:26 <muhoo> i'm creating one address per sale. i'm waiting for that ddress to collect enough btc to pay for the song. once it's paid up, i create a new tx, collect all the coins sent to that address, into a new tx, pass that on to the musician
43 2013-03-02 06:50:32 <Diablo-D3> because it'd only be one input when he passes it on
44 2013-03-02 06:50:38 <Diablo-D3> since it'd compact the inputs
45 2013-03-02 06:50:38 <gmaxwell> Customer has a tx with 10 input, 1 output (to you), you then write a tx with 1 input (the customers) and 1 output.
46 2013-03-02 06:50:49 <muhoo> no, it could be a bunch, if it were paid with multiple tx'es
47 2013-03-02 06:50:50 <Diablo-D3> muhoo: guess what, you're worrying about nothing
48 2013-03-02 06:51:12 <Diablo-D3> if they were paid with multiple txes, you need better customers
49 2013-03-02 06:51:15 <muhoo> gmaxwell: that's what i expected, but TD pointed out that people could pay with multiple tx'es
50 2013-03-02 06:51:29 <muhoo> claimed i should handle that situation
51 2013-03-02 06:52:05 <muhoo> if that's so rare as to be a theoretical thing, then i won't worry about i
52 2013-03-02 06:52:07 <muhoo> it
53 2013-03-02 06:52:47 <gmaxwell> I wouldn't worry about it, just eat the fee, and if its a concern add 0.001 BTC/txn fee on to eh customer.
54 2013-03-02 06:53:30 <muhoo> man, there's something about this project that is causing me so much analysis paralysis
55 2013-03-02 06:54:40 <gmaxwell> you're not alone.
56 2013-03-02 06:54:53 <gmaxwell> I've seen this happen to other people wrt fees too, fwiw.
57 2013-03-02 06:55:22 <gmaxwell> "You realize you're talking about fees on the scale of cents per transaction, right?" If it becomes a problem thats great news!
58 2013-03-02 06:55:39 <muhoo> true
59 2013-03-02 06:55:47 <Luke-Jr> muhoo: also, you shouldn't be passing it on to the musician until you've aggregated a bunch of purchases togehter anyway
60 2013-03-02 06:56:03 <muhoo> no, i want those coins gone off my network asap
61 2013-03-02 06:56:11 <muhoo> do not want coins sitting around
62 2013-03-02 06:56:16 <Luke-Jr> muhoo: then have them sent direct to the musician -.-
63 2013-03-02 06:56:40 <muhoo> single address, and i need to take a cut out for the label, and hopefuly for myself
64 2013-03-02 06:56:52 <Luke-Jr> then aggregate.
65 2013-03-02 06:56:54 <muhoo> if BIP32 was implemented, maybe i could do that
66 2013-03-02 06:57:03 <gmaxwell> what does BIP32 have to do with anything????
67 2013-03-02 06:57:30 <muhoo> a way to generate a bunch of "child" addresses, i.e. one per sale
68 2013-03-02 06:57:31 <gmaxwell> wrt holding coins??? if your system isn't secure you shouldn't be accepting??? someone who compromises you can still intercept all intcoming transfers.
69 2013-03-02 06:58:13 <gmaxwell> muhoo: just precompute 100k addresses in your wallet and dish them out.
70 2013-03-02 06:59:44 <muhoo> i'm trying to use the chain as an accounting tool too, very transparent
71 2013-03-02 06:59:59 <Luke-Jr> muhoo: that's not what the chain is for; that's basically abusing it
72 2013-03-02 07:01:18 <muhoo> that's kind of the big advantage of using BTC. the audit trail is all there
73 2013-03-02 07:01:20 <gmaxwell> You can have transparent accounting without the chain.
74 2013-03-02 07:01:42 <muhoo> you can look at a sale, and see who took what cut, by looking at the transaction
75 2013-03-02 07:02:26 <gmaxwell> uh, no. it really isn't bitcoin itself doesn't tell you what any of it means. Knowing _who_ any of it is depends on you telling people... and that can be done without creating a bunch of inefficient transactions, or requring a lot of hard to secure online signing keys.
76 2013-03-02 07:02:52 <Luke-Jr> the big advantage to Bitcoin is that nobody can inflate it. everything else is personal extra motives
77 2013-03-02 07:03:23 <muhoo> really? the price seems to eb inflating daily
78 2013-03-02 07:03:29 <muhoo> ;;ticker
79 2013-03-02 07:03:30 <gribble> BTCUSD ticker | Best bid: 33.70000, Best ask: 33.91864, Bid-ask spread: 0.21864, Last trade: 33.92936, 24 hour volume: 60754.39902867, 24 hour low: 33.15000, 24 hour high: 34.90000, 24 hour vwap: 34.13791
80 2013-03-02 07:03:41 <gmaxwell> thats deflating.
81 2013-03-02 07:03:44 <gmaxwell> ::facepalm::
82 2013-03-02 07:04:17 <Luke-Jr> I suppose from one perspective, you could say Bitcoin has a predictable inflation. I just look at the 21 MBTC total and see it never inflating.
83 2013-03-02 07:05:15 <petertodd> Luke-Jr: Bounded inflation :P
84 2013-03-02 07:06:16 <petertodd> By, what is it, 50BTC/21MBTC coins never created right now?
85 2013-03-02 07:08:36 <muhoo> well at this point i'm off topic, but i have to wonder if a deflationary currency is a good thing (for anyone who doesn't already have a nice phat hoard of it, of course)
86 2013-03-02 07:09:00 <muhoo> but i'll march on and not worry about too much of this stuff, we'll see where it all ends up
87 2013-03-02 07:09:11 <muhoo> thanks
88 2013-03-02 07:09:21 <petertodd> off-topic, but keep in mind, deflation vs. inflation is just a way of setting up economic circumstance - inflation is basically taxation, and sometimes taxation turns out to be useful
89 2013-03-02 07:09:22 <Luke-Jr> muhoo: it encourages saving. that's a good thing IMO
90 2013-03-02 07:09:55 <muhoo> saving for what? i mean, if everyone saves, nobody gets any income.
91 2013-03-02 07:10:07 <Luke-Jr> on the other hand, it makes it harder to get adoption against inflating competitors
92 2013-03-02 07:10:14 <Luke-Jr> muhoo: you can't save everything
93 2013-03-02 07:10:16 <Luke-Jr> gotta live..
94 2013-03-02 07:10:21 <muhoo> ACTION pictures a bunch of people sitting on gold and starving to death.
95 2013-03-02 07:10:41 <muhoo> yeah, i dunno. it's hard not to get over analytical about all this
96 2013-03-02 07:10:46 <petertodd> muhoo: It's all just numbers in balance books that encourage people to act in particular ways. There is no such thing as saving outside of society.
97 2013-03-02 07:10:55 <Luke-Jr> also, I bet people would still spend money on "wants" even with deflationa
98 2013-03-02 07:11:20 <muhoo> i do recall seeing discussions of demurrage, so perhaps someone's already thought this through
99 2013-03-02 07:11:36 <Luke-Jr> muhoo: Demurrage is Freicoin
100 2013-03-02 07:12:49 <muhoo> Luke-Jr: nice, thanks!
101 2013-03-02 07:13:17 <petertodd> muhoo: Remember that what demurrage is really saying is "Yes, you did a bunch of work and got these magic work units in return, but unless you use those work units to tell someone else to do some work soon, we're going to not let you do that anymore"
102 2013-03-02 07:13:33 <petertodd> muhoo: Is that a good or bad thing? Depends
103 2013-03-02 07:15:00 <Luke-Jr> petertodd: there will always be deflationary currency - and people will rationally seek to get rid of their inflationary to acquire deflationary for savings ;)
104 2013-03-02 07:15:23 <Luke-Jr> and those not smart enough to think of this, will be trying to live paycheck-to-paycheck more or less
105 2013-03-02 07:15:48 <petertodd> Luke-Jr: well sure, but government can try pretty hard to stamp it out, even gold isn't immune to that. (bitcoin may even prove to be more immune)
106 2013-03-02 07:16:38 <Luke-Jr> petertodd: if you succeed, then you basically force rational actors to live paycheck-to-paycheck as well, and everyone ends up in wage slavery
107 2013-03-02 07:17:20 <Luke-Jr> (but I don't think you can succeed - worst case I use guns/ammo/food as currency)
108 2013-03-02 07:17:21 <muhoo> i spent enough time in business to kind of chuckle at the idea of "rational" actors. humans are not rational.
109 2013-03-02 07:17:48 <petertodd> Luke-Jr: But that's the thing, everyone ending up in wage slavery may or may not be a good thing. Fundementally work needs to be done for society to function.
110 2013-03-02 07:17:49 <Luke-Jr> muhoo: this is why I stay at home and avoid [other] humans. :P
111 2013-03-02 07:18:26 <Luke-Jr> petertodd: I mean wage slavery as opposed to freedom to start your own business
112 2013-03-02 07:18:39 <gmaxwell> Luke-Jr: I don't really quite believe that inflation and deflation are all that different in fact. Consider??? a currency that constantly adds more to everyone that has it... inflating slowly.. or one that has it rot (and go to no one) from everyone holding it.. deflating slowly. I think these systems are actually the same. Where inflation/deflation are different is what winners and losers they make.
113 2013-03-02 07:18:41 <muhoo> look, i can do a reductio ad absurdum for the austrians, or for the occupy guys behind freicoin. reality will have to be somewhere in... reality.
114 2013-03-02 07:18:47 <petertodd> Luke-Jr: Ah, yes, that's saner, can't start without capital for the most part.
115 2013-03-02 07:19:26 <Luke-Jr> muhoo: k, I don't care for either of those groups :P
116 2013-03-02 07:20:08 <petertodd> gmaxwell: That's the fundemental issue, they're just numbers in a computer, and because the numbers change differently on differnt timescales, different groups take advantage of them. Inflation helps those who borrow, deflation those who save.
117 2013-03-02 07:20:18 <muhoo> Luke-Jr: that's good to know. the deflationary aspect of BTC was feeling kind of austrian to me, and i worry about the current bubble being goldbug hoarding.
118 2013-03-02 07:20:39 <petertodd> gmaxwell: (relative, steady state and the economy adjusts as you say)
119 2013-03-02 07:21:03 <petertodd> gmaxwell: Note how central banks are realizing negative interest rates aren't as crazy as they sound...
120 2013-03-02 07:21:14 <Luke-Jr> muhoo: the only thing I know about Austria is that they freely gave their country to Hitler
121 2013-03-02 07:21:18 <Luke-Jr> ACTION runs from Godwin
122 2013-03-02 07:21:23 <gmaxwell> petertodd: though on your work comments, pft. work is fun. People will work no matter what you do. There are interesting questions about which work will get done in what amounts, but the sheer fact of people working to create the things they need to survive can't really be risked by monetary policy, at least not over any longterm period
123 2013-03-02 07:23:14 <muhoo> Luke-Jr: i was thinking of hayek, not the other guy http://en.wikipedia.org/wiki/Austrian_economics
124 2013-03-02 07:24:01 <petertodd> gmaxwell: You've spent way too much time in the tech industry... there is so much work that we get people to do with money that wouldn't be done otherwise.
125 2013-03-02 07:24:30 <petertodd> gmaxwell: All the psych research basically says that creative work is something you support, not buy, but for non-creative work traditional ideas of how to get people to do stuff are actually really effective.
126 2013-03-02 07:24:39 <petertodd> gmaxwell: The bulk of work is non-creative. (for now)
127 2013-03-02 07:25:52 <muhoo> we're living in the future. the trend is for work of the uncreative kind to be done by machines created by workers of the creative kind.
128 2013-03-02 07:26:01 <gmaxwell> petertodd: there are plenty of communities that farm and build structures and take out trash as part of community maintance and not for economic gain. ??? now, I won't argue these places are more efficient, or even that the people in them are happier??? but I don't think the doomsday kind of view where you need to have people struggling for cash or work doesn't get done is valid either.
129 2013-03-02 07:26:55 <muhoo> which leaves a bunch of people without jobs. which wouldn't be a problem if jobs weren't required for income and survival.
130 2013-03-02 07:27:05 <gmaxwell> and yea, I'm leary of slipping into ted-talk-syndrome, where I get to basically predicate my politics on post scarcity because I'm privledged enough to basically live in post scarcity myself.
131 2013-03-02 07:27:07 <petertodd> gmaxwell: Yes, but that's the key thing: communities. People function really well in <200 head communities where social pressures work, they don't function well when social pressures don't work, which is what economics did for us.
132 2013-03-02 07:27:37 <MC1984> dunbars
133 2013-03-02 07:27:39 <MC1984> number
134 2013-03-02 07:27:49 <MC1984> or, why facebook is stupid
135 2013-03-02 07:27:51 <petertodd> gmaxwell: What can I say, my dad had the opportunity to visit the Soviet Union a few months before it collapsed in the early ninties... lets just say it left a hell of an impression.
136 2013-03-02 07:28:33 <muhoo> i've enjoyed reading dmitry orlov's accounts of what happened AFTER the collapse
137 2013-03-02 07:28:53 <gmaxwell> petertodd: it's not just social pressure. I pick up trash in my community whenever I see it. No one asks me to or rewards me for doing it. (this is probably the first time I've mentioned doing it) People aren't total idiots and will self maintain too??? to at least some extent??? without pressure.
138 2013-03-02 07:28:56 <petertodd> Ha, yes, they kinda fucked up that transition...
139 2013-03-02 07:30:05 <petertodd> gmaxwell: *Some* extent. You do that because you live in a functioning community, so the social effects extend further than they normally would. We replace actual face-to-face interactions with implicit ones; fortunately for our brains either method works.
140 2013-03-02 07:30:11 <gmaxwell> Technology can also give us ways to create small communities out of big ones. ... No one paid (directly) for the construction of Wikipedia.
141 2013-03-02 07:30:51 <petertodd> ...and Bitcoin is mostly volunteer.
142 2013-03-02 07:31:17 <gmaxwell> jury is still out on how effectively that's working out. :)
143 2013-03-02 07:31:30 <petertodd> But again, all that rosy thinking was exactly what communism thought they could achieve, and they soon found out it breaks down in large groups.
144 2013-03-02 07:32:21 <muhoo> funny, i've been a few very capitalist startups that went sideways after hitting dunbar's number
145 2013-03-02 07:32:30 <gmaxwell> yea, I should back up, I'm not trying to argue the superiority of anything else, I was just pointing out that a tight wage control loop is not the only tool in the tool belt, and perhaps not even that necessary of one.
146 2013-03-02 07:32:56 <MC1984> muhoo uhuh
147 2013-03-02 07:33:11 <petertodd> Disasterously so really. The Soviet Union was filled with people who displayed remarkable self-sufficiency and camaraderie, but they couldn't translate that into making sane decisions beyond smallish groups. Like factories that would produce baby shoes because they used the least material for the most quota number.
148 2013-03-02 07:33:36 <MC1984> also ask yourslef why the best countries in the world are tiny
149 2013-03-02 07:33:48 <petertodd> gmaxwell: Same :P
150 2013-03-02 07:33:56 <muhoo> anyway, i'll take full responsibilty for causing this massive OT digression, and i apologize :-(
151 2013-03-02 07:33:58 <gmaxwell> well thats a good lesson we've still not learned here in the US: people respond to incentives, often in preverse ways.
152 2013-03-02 07:34:50 <gmaxwell> stuff like that is a reason I've cited about powerful AI scaring me??? optimization processes produce all the freaky corner cases.
153 2013-03-02 07:34:57 <petertodd> Yup, and what's worse, is people's ability to figure out the best ways for themselves to response to those incentives keeps developing. Business practices are subject to R&D just as much as anything else,.
154 2013-03-02 07:35:15 <petertodd> It's incidentally why economics has so little predictive power...
155 2013-03-02 07:35:25 <petertodd> I think the halting problem is a very good analogy
156 2013-03-02 07:39:42 <abrkn> if i run 0.8 with -txindex=1 and without reindex, will only getrawtransaction work on new transactions?
157 2013-03-02 07:40:00 <petertodd> abrkn: *Unspent* transactions
158 2013-03-02 07:40:06 <petertodd> New isn't really the right word
159 2013-03-02 07:40:16 <abrkn> k
160 2013-03-02 07:43:52 <Luke-Jr> abrkn: -txindex is only a valid option *with* reindex
161 2013-03-02 07:46:40 <abrkn> ok
162 2013-03-02 07:46:45 <DarkGhost`> how come I can't sendtoaddress <address> .0001
163 2013-03-02 07:46:51 <DarkGhost`> it saysI need a txfee of .0005
164 2013-03-02 07:46:59 <DarkGhost`> so even if I try to sendi out .00001 it still says txfee
165 2013-03-02 07:47:35 <Luke-Jr> because you're not supposed to flood
166 2013-03-02 07:47:42 <DarkGhost`> so I can't send it?
167 2013-03-02 07:47:48 <Luke-Jr> send more
168 2013-03-02 07:48:23 <gmaxwell> you can??? with a txfee.
169 2013-03-02 07:51:32 <DarkGhost`> I only have .0001
170 2013-03-02 07:51:40 <DarkGhost`> what ocmmand do I do to send that with a txfee?
171 2013-03-02 09:02:27 <sturles> DarkGhost`: You obviously can't add a txfee if you only have 0.0001 BTC. It's stuck. Add more if the 0.34 cents are important to you.
172 2013-03-02 09:03:15 <MC1984> can you really not get zero fee txn mined anymore?
173 2013-03-02 09:05:03 <gmaxwell> MC1984: has nothing to do with non-zero fees and everything to do with dust outputs.
174 2013-03-02 09:05:22 <MC1984> oh right
175 2013-03-02 09:05:24 <gmaxwell> DarkGhost`: get more coin or give away your private keys.
176 2013-03-02 09:40:34 <abrkn> what are the advantages of upgrading to 0.8 if still using txindex?
177 2013-03-02 09:48:32 <Luke-Jr> abrkn: txindex uses a bit more disk space, but it doesn't negate any of the advantages of 0.8
178 2013-03-02 09:49:32 <abrkn> ok
179 2013-03-02 09:55:33 <muhoo> ah, that's the chart i was looking for: http://blockchain.info/charts/tx-trade-ratio
180 2013-03-02 10:03:47 <abrkn> ok, upgrade complete. i wonder how long to catch up
181 2013-03-02 10:03:53 <abrkn> 112068
182 2013-03-02 10:03:56 <abrkn> ,,getheight
183 2013-03-02 10:03:56 <gribble> Error: "getheight" is not a valid command.
184 2013-03-02 10:49:01 <TD> 1mb of unconfirmed transactions
185 2013-03-02 10:49:50 <TD> back down to 760kb
186 2013-03-02 10:50:49 <HM> sec1 is a nice easygoing document
187 2013-03-02 10:51:02 <HM> scary how ecdsa is buggared if your rng is even slightly biased
188 2013-03-02 11:08:52 <tigger0> why do txin's reference a txout with <transactionid,input>?
189 2013-03-02 11:09:12 <tigger0> if the utxo set is indexed by scriptPubKey, why doesn't it reference scriptPubKey?
190 2013-03-02 11:09:59 <tigger0> utxo set could have this hierarchy: [scriptPubKey][value][0][transaction][vout]
191 2013-03-02 11:10:58 <tigger0> if given two identical chains and the same value, the same outputs are selected during spending
192 2013-03-02 11:12:21 <tigger0> for one if you receive lots of transactions, the transaction itself would be much smaller since you wouldn't have the redundancy
193 2013-03-02 11:12:30 <tigger0> (your transaction to spend them, that is)
194 2013-03-02 11:12:47 <gmaxwell> tigger0: because the system tracks txouts and they must be unique for accounting. What you're describing would make it trivial to have duplicate txids for example.
195 2013-03-02 11:13:19 <gmaxwell> tigger0: if bitcoin is used correctly every transaction pays to a new address, it wouldn't make the transactions any smaller to do what you're describing.
196 2013-03-02 11:13:32 <tigger0> ah right
197 2013-03-02 11:14:40 <tigger0> well what i'm describing is allowing the vin to simply describe the scriptPubKey (which all txin's can be identified from), the value claimed, and the scriptSig for each unique account
198 2013-03-02 11:15:00 <tigger0> then you don't have to construct a vin with 500 txin's to claim 500BTC split in 1 BTC increments
199 2013-03-02 11:15:15 <tigger0> also this could make pay-to-policy easier perhaps
200 2013-03-02 11:15:37 <gmaxwell> Such a transaction should normally never exist, because there should not have been 500 txins with a common scrippubkey.
201 2013-03-02 11:15:43 <gmaxwell> That implies address reuse.
202 2013-03-02 11:16:41 <tigger0> i understand i'm just exploring the case, i guess unique addresses do make that pretty unnecessary
203 2013-03-02 11:17:30 <gmaxwell> In any case, for better or worse the system doesn't work around "accounts" it has no concept of them. It just tracks the coins themselves.
204 2013-03-02 11:17:40 <gmaxwell> I'm sure with enough alterations something like your describing could be made to work... without thinking about it more I couldn't guess the advantages/disadvantages.
205 2013-03-02 11:19:00 <gmaxwell> Most people who show up thinking in terms of accounts have their thinking blown up by multisignature transaction or transactions that can be satisfied multiple or unknown ways (e.g. pay to the provider of a solution to a puzzle) ... but what you're saying doesn't actually sound incompatible with any of that.
206 2013-03-02 11:19:30 <tigger0> right
207 2013-03-02 11:19:56 <tigger0> it's sort of like an alternative vin, which allows the verifying process to select the txin's and apply a single scriptSig among them, instead of describing them explicitly or perhaps redundantly
208 2013-03-02 11:19:58 <gmaxwell> It would make the validity of the transactions conditional on the network, which might cause oddness, but I can't think of what.
209 2013-03-02 11:20:21 <tigger0> doesn't the mempool already account somewhat on conditions?
210 2013-03-02 11:20:57 <tigger0> i'm trying to think if this would mess up re-orgs
211 2013-03-02 11:21:02 <gmaxwell> no- mempool really has nothing to do with what goes into blocks. It does influence what gets relayed, but you can sort of think of bitcoin's p2p and blockchain as seperate systems.
212 2013-03-02 11:21:46 <gmaxwell> tigger0: well here is one reason it would be bad??? it would be hard to predict which transactions would be conditionally invalid based on a payment to you becoming invalid.
213 2013-03-02 11:22:13 <gmaxwell> multiple transactions could even become invalid, if you allowed partial value consumption.
214 2013-03-02 11:22:28 <tigger0> as a sort of 0 confirmation flaw?
215 2013-03-02 11:23:06 <gmaxwell> right, you zero confirm spend a payment you just got.. but instead a payment you made previously with fully confirmed balances is what gets rejected by the network.
216 2013-03-02 11:23:08 <tigger0> i guess if you're confused on conditional invalidity, or you even have the difficulty predicting it, you can wait until a confirmation or two
217 2013-03-02 11:23:28 <gmaxwell> but that whole address must wait, not just a single transaction.
218 2013-03-02 11:23:30 <tigger0> but this would subject that to every node
219 2013-03-02 11:23:34 <tigger0> yea
220 2013-03-02 11:24:23 <tigger0> well this would screw up re-orgs anyway
221 2013-03-02 11:24:31 <tigger0> i assume bitcoin does some sort of reverse delta thing
222 2013-03-02 11:24:51 <gmaxwell> well, it's late for me, but I'm suspecting that it could work, the tradeoffs would be slightly different. It would also encourage address reuse (by making it more efficient) which would greatly diminish the privacy properties of the system (which are already really thin and depend on the fragile pseudoanonymity)
223 2013-03-02 11:24:54 <tigger0> if it tried to reverse a transaction, because the transaction is using a selector of sorts, it depends on the state of the utxo's at that point in the chiain
224 2013-03-02 11:24:56 <tigger0> chain*
225 2013-03-02 11:25:02 <tigger0> which isn't encoded in the transaction anymore
226 2013-03-02 11:25:06 <tigger0> and yeah
227 2013-03-02 11:25:09 <tigger0> cool well thanks
228 2013-03-02 11:25:11 <gmaxwell> yes, but we record what was changed.
229 2013-03-02 11:25:22 <tigger0> oh really? ok cool
230 2013-03-02 11:25:53 <gmaxwell> so that we can undo the changes during a reorg, so that could be surrmounted.. though a simplier implementation that didn't record the reverse change (e.g. ours prior to 0.8) wouldn't have handled that well.
231 2013-03-02 11:27:01 <gmaxwell> (the blockchain is forward differences, bitcoin .8 nodes record reverse differences??? this lets us do 100% of the validation using just an index of txouts, without reference to the forward-differences except during reorg and when a new block is recieved)
232 2013-03-02 11:58:26 <sipa> Luke-Jr: -txindex may be specified at any time, but if it is, and its value doesn't match the existing db, it will refuse to start up
233 2013-03-02 13:10:03 <iwilcox> What assumptions does blockchain.info have to make to name the 'from' address of a transaction, that the qt client isn't prepared to make? I understand from elsewhere that it's a shaky assumption but I can't wrap my head around why.
234 2013-03-02 13:10:36 <iwilcox> A transaction has to refer back to a previous one to satisfy its script.
235 2013-03-02 13:11:07 <iwilcox> The previous one, provided it's simple, included a hashed public key (address)
236 2013-03-02 13:12:51 <iwilcox> The reference back to the previous transaction is a signature, but presumably to generate the new txn the client, and all nodes the new txn passes through, have to be able to unambiguously resolve it to a specific txn earlier in the chain.
237 2013-03-02 13:16:39 <sipa> iwilcox: what if all prevouts had a script that don't match an address template?
238 2013-03-02 13:16:55 <sipa> what if the different prevouts belong to different people?
239 2013-03-02 13:17:34 <iwilcox> Does the first one fall under breaking "provided it's simple"?
240 2013-03-02 13:17:34 <sipa> what if the prevout belonged to an e-wallet, not directly associated with the account of the one actually sending?
241 2013-03-02 13:18:20 <iwilcox> Second one, blockchain.info does list multiple previous outputs
242 2013-03-02 13:18:34 <iwilcox> Third one I don't understand :(
243 2013-03-02 13:19:08 <sipa> oh you just mean listing prevouts l, not really defining a "from address"
244 2013-03-02 13:19:56 <sipa> well the only real problem with that imho, is that it gives the false impression that bitcoin does transactions between addresses
245 2013-03-02 13:20:44 <iwilcox> There's a compromise between user-friendliness and technical accuracy, sure
246 2013-03-02 13:21:07 <iwilcox> I was pleased and intrigued to find out about scripting :)
247 2013-03-02 13:21:22 <sipa> the third one: if i have an account at webwallet E, and i send some coins out, it will not necessarily use coins that were previously sent to any of my own addresses at the site
248 2013-03-02 13:22:00 <iwilcox> Ah, yeah. That could confuse users.
249 2013-03-02 13:22:14 <sipa> so the receiver may think all prevout addresses belong to me, but sending them back will not result in crediting my account
250 2013-03-02 13:22:38 <sipa> so imho the only correct answer is that bitcoin transactions do not have from addresses
251 2013-03-02 13:22:50 <sipa> the consume, produce and assign coins
252 2013-03-02 13:22:54 <sipa> the
253 2013-03-02 13:22:57 <sipa> theY
254 2013-03-02 13:23:27 <sipa> and if you need a refund address, ask for one
255 2013-03-02 13:24:34 <iwilcox> That's probably the most compelling argument I've heard so far.
256 2013-03-02 13:24:47 <iwilcox> Thanks
257 2013-03-02 13:25:04 <iwilcox> (s/heard/actually been able to understand/) :)
258 2013-03-02 13:25:11 <sipa> yw
259 2013-03-02 13:25:24 <CodeShark> you can have a metaprotocol that encodes the "from" address
260 2013-03-02 13:25:41 <sipa> yes, the payment protocol does that
261 2013-03-02 13:25:52 <iwilcox> I see there's space for a note in scripts.
262 2013-03-02 13:26:04 <sipa> there is not
263 2013-03-02 13:26:09 <iwilcox> Oh.
264 2013-03-02 13:26:22 <sipa> you can put anything in scripts of course
265 2013-03-02 13:26:54 <sipa> but the only data that belongs on the p2p betwork and in the block chain is data that the world needs to verify your transaction
266 2013-03-02 13:27:02 <sipa> anything else i consider abuse
267 2013-03-02 13:27:09 <CodeShark> no poetry? :)
268 2013-03-02 13:27:28 <CodeShark> no ascii art of bernanke?
269 2013-03-02 13:27:49 <sipa> as it is more efficient, faster and cheaper to communicate that data directly between receiver and sender negotiating the transaction
270 2013-03-02 13:28:39 <iwilcox> OK, I guess I meant "you could abuse OP_DROP"
271 2013-03-02 13:28:53 <sipa> in theory you cab
272 2013-03-02 13:29:08 <CodeShark> or you can even send zero bitcoins and construct arbitrary outputs
273 2013-03-02 13:30:01 <CodeShark> I mean, construct zero bitcoin outputs
274 2013-03-02 13:30:13 <CodeShark> you still might need fees for your transaction to get relayed and included in a block
275 2013-03-02 13:30:29 <sipa> zero value outputs are nonstandard
276 2013-03-02 13:31:05 <CodeShark> as in bitcoind won't relay them?
277 2013-03-02 13:31:10 <sipa> indeed
278 2013-03-02 13:31:21 <CodeShark> you can still use .00000001 btc outputs, then :)
279 2013-03-02 13:32:20 <iwilcox> Is the 3xxxx prefix effectively an optimisation? As in, unless it's 3xxxx you can write faster, simpler code to execute the script?
280 2013-03-02 13:32:35 <sipa> ?
281 2013-03-02 13:32:46 <iwilcox> Multisig addresses
282 2013-03-02 13:32:48 <CodeShark> you need a conditional either way
283 2013-03-02 13:32:48 <sipa> 3xxxx is a pay to scripthash address
284 2013-03-02 13:32:53 <Goonie> Is Blockexplorer down? https://blockexplorer.com/searchgo/fa588a11
285 2013-03-02 13:33:13 <sipa> p2sh is not the same as multisig
286 2013-03-02 13:33:28 <CodeShark> multisig is implemented using p2sh, no?
287 2013-03-02 13:33:37 <iwilcox> Oh. I'm misinterpreting https://en.bitcoin.it/wiki/Address#Multi-signature_addresses then
288 2013-03-02 13:33:46 <sipa> depends what you mean by implemented
289 2013-03-02 13:34:19 <sipa> i can create a non-p2sh multisig transaction now, and it will be relayed fine
290 2013-03-02 13:34:33 <sipa> and verified by the network
291 2013-03-02 13:34:53 <sipa> the wallet in bitcoind can only do p2sh multisig
292 2013-03-02 13:34:59 <MC1984> any way to watch txn relay on you node live?
293 2013-03-02 13:35:04 <CodeShark> that's what I meant, sipa
294 2013-03-02 13:35:15 <sipa> tail -f debug.log
295 2013-03-02 13:36:03 <MC1984> that just logs blocks and other misc, not txn relay individually?
296 2013-03-02 13:36:13 <sipa> yes
297 2013-03-02 13:36:27 <jgarzik> It logs txn relay individually, where your node participates
298 2013-03-02 13:36:32 <sipa> tail -f debug.log | fgrep tx
299 2013-03-02 13:36:49 <sipa> or something like that if you want it filtered
300 2013-03-02 13:37:01 <CodeShark> can you filter a stream like that?
301 2013-03-02 13:37:01 <jgarzik> it logs when you receive a tx not yet seen, when you relay a TX to others, and it logs local transaction creation
302 2013-03-02 13:37:08 <CodeShark> I mean a pipe
303 2013-03-02 13:37:19 <sipa> how else?
304 2013-03-02 13:37:25 <jgarzik> that's what grep does
305 2013-03-02 13:37:47 <MC1984> oh is it the ctxmempool stuff
306 2013-03-02 13:37:52 <CodeShark> yes, I see it works
307 2013-03-02 13:39:25 <sipa> jgarzik: i keep getting errors/crashes with your cnetmessage stuff
308 2013-03-02 13:39:34 <sipa> i don't understand it
309 2013-03-02 13:46:03 <jgarzik> sipa: Yah, I remember your same report from a couple months ago :/
310 2013-03-02 13:46:30 <jgarzik> ACTION hasn't yet rejoined the dev community (anywhere), so I haven't had time to look at it and think
311 2013-03-02 13:46:54 <jgarzik> at the time, it seemed quite strange a report, but reproducible is reproducible.
312 2013-03-02 13:47:08 <jgarzik> Messing with binary packets can lead to problems if not 100% perfect, clearly
313 2013-03-02 13:52:11 <sipa> it's the same problem as before: CNetMessage destructors are called on already freed or even uninitialized data
314 2013-03-02 15:28:53 <jaakkos> do nodes relay double spends if they think they are double spends?
315 2013-03-02 15:29:02 <petertodd> no
316 2013-03-02 15:29:03 <sipa> no
317 2013-03-02 15:30:13 <jaakkos> i was thinking, it prevents a seller from seeing that the coins they received were double spent, until the double spend ends in a block
318 2013-03-02 15:30:46 <jaakkos> otherwise they could see that there was a fraud in seconds
319 2013-03-02 15:31:05 <petertodd> Then ask blockchain.info for a feed from their invasive monitoring network, or stop accepting zero-conf transactions.
320 2013-03-02 15:32:06 <petertodd> Remember, if I were evil, I'd start a pool that allowed you to submit transactions directly to me, and I'd write code that replaced transactions every time I found a different one with a higher fee.
321 2013-03-02 15:32:45 <petertodd> Or heck, not even evil, just profit driven.
322 2013-03-02 15:33:27 <sipa> and the only defense against that, is probably making deals with miners yourself, not to do that to your transaction
323 2013-03-02 15:33:34 <sipa> you, or a payment processor...
324 2013-03-02 15:34:44 <Diablo-D3> jaakkos: what you said doesn't make sense
325 2013-03-02 15:34:56 <petertodd> Yup, and the best thing about this plan, is the only entities negatively affected are, well, Alpaca Socks of course. Yeah, socks.
326 2013-03-02 15:35:16 <Diablo-D3> lets say I send a tx
327 2013-03-02 15:35:24 <Diablo-D3> and then the network goes into a fork split situation
328 2013-03-02 15:35:33 <Diablo-D3> which happens naturally from time to time
329 2013-03-02 15:36:08 <Diablo-D3> a seller trying to detect frauds would think my tx is fraud because it now appears in two splits in two different blocks
330 2013-03-02 15:36:33 <petertodd> Diablo-D3: No, because the transaction is the same each time.
331 2013-03-02 15:37:08 <petertodd> Diablo-D3: Proof of double spend is two signatures on the same transaction inputs, with different transaction outputs.
332 2013-03-02 15:37:20 <Diablo-D3> petertodd: yeah but my client didn't resend
333 2013-03-02 15:37:34 <Diablo-D3> its the same tx that two third parties mined simultaneuously
334 2013-03-02 15:37:35 <sipa> Diablo-D3: irrelevant
335 2013-03-02 15:37:48 <sipa> it's still the same tx, which doesn't conflict with itself
336 2013-03-02 15:38:01 <Diablo-D3> ahh
337 2013-03-02 15:38:18 <Diablo-D3> so how do you detect its a malicious tx?
338 2013-03-02 15:38:29 <Diablo-D3> btw, there really should be a lengthy paper written about subtle stuff like this
339 2013-03-02 15:38:29 <sipa> if it's a different tx that spends the same input
340 2013-03-02 15:38:34 <petertodd> sipa: Well, technically it can, if a fancy SIGHASH is used, and someone later added an additional input.
341 2013-03-02 15:38:39 <Diablo-D3> the original satoshi whitepaper doesn't cover it
342 2013-03-02 15:38:46 <petertodd> sipa: (keeping the output values the same)
343 2013-03-02 15:39:07 <petertodd> Diablo-D3: The satoshi paper is just a rough sketch - lots of the system as it stands isn't in there. Scripting for instance.
344 2013-03-02 15:39:21 <sipa> petertodd: yeah, and tx replacement probably should be taken into account as well (though that implies one of both is non-final)
345 2013-03-02 15:39:28 <Diablo-D3> petertodd: thats what Im saying
346 2013-03-02 15:39:37 <Diablo-D3> theres lots of interesting shit that just isn't written down anywhere
347 2013-03-02 15:39:41 <sipa> petertodd: and signature malleability also complicates things
348 2013-03-02 15:39:51 <sipa> (though that should be fixed independently)
349 2013-03-02 15:40:47 <petertodd> Diablo-D3: So much shit that the statement "the original satoshi whitepaper doesn't cover it" is not interesting. :P
350 2013-03-02 15:41:02 <petertodd> sipa: Yeah, that !@#$ malleability...
351 2013-03-02 15:41:32 <Diablo-D3> petertodd: well, it used to be a rule in here to tell people to read the paper
352 2013-03-02 15:41:43 <Diablo-D3> although that was like 2-3 years ago =/
353 2013-03-02 15:41:49 <sipa> it still is
354 2013-03-02 15:41:58 <sipa> for getting a basic understanding of the system
355 2013-03-02 15:42:29 <Diablo-D3> btw, why was signature malleability allowed?
356 2013-03-02 15:42:51 <sipa> because there are insufficient measures to prevent it
357 2013-03-02 15:42:53 <petertodd> Diablo-D3: Because satoshi screwed up.
358 2013-03-02 15:43:14 <Diablo-D3> ahh
359 2013-03-02 15:43:26 <Diablo-D3> is it too late to require immutable signatures?
360 2013-03-02 15:43:32 <sipa> no
361 2013-03-02 15:43:39 <sipa> just a softfork
362 2013-03-02 15:43:47 <Diablo-D3> maybe worth switching to 0.9.0 over?
363 2013-03-02 15:43:57 <petertodd> sipa: Yeah, what's the current best known approach?
364 2013-03-02 15:45:49 <Diablo-D3> because like in peter's example of fancy SIGHASH
365 2013-03-02 15:46:07 <Diablo-D3> Im not sure how that stuff is used, but maybe require previous version of that sig to be the input for the new version?
366 2013-03-02 15:46:17 <Diablo-D3> it keeps it strictly versioned in the chain and thus transactional
367 2013-03-02 15:47:07 <sipa> petertodd: define a nVersion=2 transaction which has extra rules (no superfluous scriptSig items, signature s value is even, ...), make a client that creates such transactions, poke client authors to do the same, convince miners to switch to a client that enforces the nVersion=2 rules, and at a much later date, when enough miners have switched, enforce the nVersion=2 transaction rules; and at an even mucher later date, make nVersion=1 transactions...
368 2013-03-02 15:47:13 <sipa> illegal
369 2013-03-02 15:47:56 <Diablo-D3> sipa: you forgot one
370 2013-03-02 15:48:09 <Diablo-D3> allow version 1 transactions to be legal after the change date as long as they comply with the new rules
371 2013-03-02 15:48:12 <petertodd> sipa: Ok, so it's likely to be done by just making stronger scriptSig rules?
372 2013-03-02 15:48:30 <sipa> petertodd: i am very unsure whether this can be pushed for
373 2013-03-02 15:48:31 <petertodd> sipa: Also, I thought nodes won't relay nVersion=2
374 2013-03-02 15:48:40 <sipa> even gavin dislikes requiring s=even
375 2013-03-02 15:48:47 <petertodd> sipa: Gavin seemed to be thinking of something broader
376 2013-03-02 15:49:02 <petertodd> sipa: What about odd Gavin?
377 2013-03-02 15:49:28 <sipa> well, i'm in favor of redoing the script language altogether, and use an OP_EVAL like system to switch to it softfork-wise
378 2013-03-02 15:49:48 <sipa> but that doesn't make the problem go away for transactions spending old outputs
379 2013-03-02 15:50:27 <petertodd> sipa: Yeah, I've got a bunch of stuff I think would be nice too; in #bitcoin-wizards we even came up with a whole AST format idea...
380 2013-03-02 15:58:16 <sipa> petertodd: i know :)
381 2013-03-02 15:58:46 <petertodd> sipa: You're so modest.
382 2013-03-02 15:58:52 <petertodd> (turns out sipa came up with the idea)
383 2013-03-02 15:59:09 <petertodd> (well, roconner, but he brought it up)
384 2013-03-02 16:23:54 <muhoo> heh, wizards. is #bitcoin-wizards logged anywhere?
385 2013-03-02 16:51:35 <HM> muhoo: i hope not
386 2013-03-02 16:51:41 <HM> i wouldn't want my ignorance archived
387 2013-03-02 16:53:52 <muhoo> TD: heh, .getPendingPeers -> 5798
388 2013-03-02 16:53:56 <muhoo> and counting
389 2013-03-02 16:54:03 <TD> hmm
390 2013-03-02 16:54:08 <TD> not good ....
391 2013-03-02 16:54:17 <muhoo> it keeps adding the same peerover and over again. i should probably fix this
392 2013-03-02 16:55:02 <muhoo> then again, let me doublecheck that it's not anything i'm doing dumb.
393 2013-03-02 16:58:06 <muhoo> TD: nm, i'm an idiot. i have an onPeerDisconnected event that attempts to reconnect, totalyl forgotten i'd done that :-(
394 2013-03-02 16:58:20 <TD> not good ???.ah :(
395 2013-03-02 17:00:09 <muhoo> yeah, working on a complex project an hour at a time here and there, plus early alzheimer's, not a good combo
396 2013-03-02 17:25:38 <phantomcircuit> muhoo, you really dont want to do that
397 2013-03-02 17:25:39 <phantomcircuit> ok
398 2013-03-02 18:09:46 <xjrn> i hope by the end of the day to have an aperapi test of bouncycastle and maybe phatk kernels
399 2013-03-02 19:24:19 <BlueMatt> gmaxwell: so I finally had a few hours to just sit and think about priority scheduling yesterday evening...
400 2013-03-02 19:24:48 <BlueMatt> gmaxwell: I dont believe people splitting coins for future priority is an issue
401 2013-03-02 19:24:57 <BlueMatt> (with any reasonable priority scheduling system)
402 2013-03-02 19:25:26 <BlueMatt> gmaxwell: the issue is in order for that first split to be accepted, you will have to pay a fee anyway
403 2013-03-02 19:26:15 <BlueMatt> gmaxwell: its not as much a question of waiting for acceptance because your tx wont even be relayed if your priority is really bad
404 2013-03-02 19:27:13 <BlueMatt> gmaxwell: there is ofcourse a possibility that you could pay a lower fee than you would have to in the future, but I would argue that thats actually not gonna be possible
405 2013-03-02 19:27:26 <BlueMatt> because fee is per size, not per priority
406 2013-03-02 19:27:58 <BlueMatt> so your split is going to be fee-expensive due to its size, whereas not splitting means you should be able to create a significantly smaller tx in the future
407 2013-03-02 19:30:05 <rdponticelli1> BlueMatt: But a clever splitting could help in addressing some anonymity issues, right?
408 2013-03-02 19:30:46 <BlueMatt> no
409 2013-03-02 19:30:57 <BlueMatt> well...maybe but priority scheduling should discourage that
410 2013-03-02 19:31:03 <BlueMatt> (ie you should have to pay a fee to do so)
411 2013-03-02 19:31:17 <rdponticelli1> Indeed
412 2013-03-02 19:31:33 <rdponticelli1> What would be fair...
413 2013-03-02 19:31:58 <BlueMatt> that is up to miners
414 2013-03-02 19:32:05 <BlueMatt> and competition
415 2013-03-02 19:39:41 <muhoo> well that was easy. i just created a static PeerDiscovery for my test network, which just returns two static ip addresses of my test nodes. PeerGroup seems to like it just fine, and looks like it does its own autoreconnecting. nice.
416 2013-03-02 19:40:36 <muhoo> that's 3 hours of bikeshedding... complete!
417 2013-03-02 20:31:52 <sipa> implemented a field multiplication in secp256k1 (2^256-0x1000003D1) in pure C (using __int128 though), taking 48ns
418 2013-03-02 20:32:05 <sipa> no idea if that's enough to compete with openssl's montgomery mult
419 2013-03-02 20:34:51 <nanotube> fyi, looks like google summer of code is on for 2013. looks like the deadline for mentoring organization applications is March 29. http://www.google-melange.com/gsoc/events/google/gsoc2013
420 2013-03-02 20:35:24 <BlueMatt> do we have a project we want done?
421 2013-03-02 20:35:48 <BlueMatt> well, ok, obviously yes, but do we have someone who wants to sign up as a mentor?
422 2013-03-02 20:47:37 <wladston> I'm also looking for mentoring btw
423 2013-03-02 20:48:24 <wladston> wanted to learn how to make a light SPV client with bloom filters
424 2013-03-02 20:49:28 <nanotube> BlueMatt: gavinandresen has been saying that the best thing we could get paid work for is improving the test suite....
425 2013-03-02 20:49:32 <muhoo> wladston: there's bitcoinj :-)
426 2013-03-02 20:49:44 <nanotube> as to who wants to sign up as a mentor... that's a different question. :)
427 2013-03-02 20:49:55 <nanotube> would have to be someone who's familiar with the current state of the testing code
428 2013-03-02 20:49:59 <wladston> muhoo: ins't bitcoinj a library ?
429 2013-03-02 20:50:00 <nanotube> if we go for the testing side
430 2013-03-02 20:50:14 <muhoo> wladston: indeed, and there's an android app built on it
431 2013-03-02 20:50:41 <wladston> muhoo: I'm in need of something that I can use with rpc-calls from a webapp
432 2013-03-02 20:51:06 <muhoo> wladston: i'm actually using bitcionj as the back end for a web app
433 2013-03-02 20:51:18 <BlueMatt> probably just use bitcoinj....depending on your motivation
434 2013-03-02 20:51:35 <muhoo> it's pretty good for that. very lightweight, runnign it now on a 500MB RAM VPS
435 2013-03-02 20:52:45 <muhoo> wladston: and since it's jvm, you can write in whatever you like, jruby, jpython, etc. i'm using clojure for this one.
436 2013-03-02 20:53:36 <wladston> muhoo: how ??? would you be kind to explain ? :)
437 2013-03-02 20:54:24 <muhoo> wladston: how what, specifically?
438 2013-03-02 20:54:35 <wladston> muhoo: are you using json-rpc ?
439 2013-03-02 20:55:00 <wladston> what's the name of the app ?
440 2013-03-02 20:55:18 <muhoo> heh, it's not even named. i'm taking an enormouse amount of time.
441 2013-03-02 20:55:24 <BlueMatt> nanotube: whats up with gribble?
442 2013-03-02 20:55:29 <BlueMatt> ;;ping
443 2013-03-02 20:55:30 <gribble> pong
444 2013-03-02 20:56:23 <nanotube> BlueMatt: nothing... seems to be working just fine
445 2013-03-02 20:56:24 <nanotube> ?
446 2013-03-02 20:57:39 <BlueMatt> nanotube: ahh...my internet appeared to have cut out for like 5 minutes...
447 2013-03-02 20:58:03 <nanotube> ah ok
448 2013-03-02 20:58:55 <BlueMatt> nanotube: well, that would probably mean me...though Im not sure I could qualify as a mentor (let alone have the time for the summer...)
449 2013-03-02 21:00:18 <BlueMatt> nanotube: still, it wouldnt take much for any of the other devs to get caught up with all (well...ok not so much) thats going on with testing, so really anyone could do it, Id think
450 2013-03-02 21:15:17 <doe> hi. i am running ./bitcoind. generated an address, then used coinbase.com to send 0.5 btc to that address. coinbase indicates 6 confirmations, but i don't see it in my wallet via ./bitcoind getbalance
451 2013-03-02 21:15:25 <doe> what did i do wrong?
452 2013-03-02 21:15:38 <BlueMatt> how many blocks does bitcoind have
453 2013-03-02 21:15:40 <BlueMatt> (getinfo)
454 2013-03-02 21:15:57 <doe> 210695
455 2013-03-02 21:15:59 <BlueMatt> ;;bc,blocks
456 2013-03-02 21:16:00 <gribble> 223955
457 2013-03-02 21:16:06 <BlueMatt> wait till you have that many and then see
458 2013-03-02 21:16:21 <doe> oh wow
459 2013-03-02 21:16:28 <doe> very cool -- thank you
460 2013-03-02 21:16:38 <doe> where did you get that number?
461 2013-03-02 21:16:46 <BlueMatt> that is the current number of blocks
462 2013-03-02 21:16:48 <doe> up-to-date client?
463 2013-03-02 21:16:51 <BlueMatt> (gribble is obv a bot)
464 2013-03-02 21:17:14 <BlueMatt> dont know where he pulls that from, probably bbe, but any up-to-date client that runs 24/7 should have that many blockx
465 2013-03-02 21:17:15 <BlueMatt> s
466 2013-03-02 21:17:29 <doe> got it. cool.
467 2013-03-02 21:17:33 <doe> whew :)
468 2013-03-02 21:18:17 <Shealan> Is there a place in L4 where you specify custom 404 pages?
469 2013-03-02 21:18:25 <Shealan> or error pages in general?
470 2013-03-02 21:18:26 <doe> vernacular: "bitcoin" is the "unit" (e.g. "dollar" is a "unit") and "satoshi" is the "subunit" (e.g. "cent" is a "subunit") ?
471 2013-03-02 21:18:59 <sipa> doe: indeed
472 2013-03-02 21:19:08 <sipa> a satoshi is 1/10^8 of a bitcoin
473 2013-03-02 21:19:23 <doe> and 100_000_000 satoshi make 1 bitcoin
474 2013-03-02 21:19:48 <doe> oh... exponential notation not my strong side
475 2013-03-02 21:19:51 <doe> :)
476 2013-03-02 21:19:57 <doe> but it is good to be exposed to it
477 2013-03-02 21:28:04 <doe> maybe here: https://blockexplorer.com/q/getblockcount :)
478 2013-03-02 21:29:55 <sipa> that's what ,,bc,blocks fetches, i think
479 2013-03-02 21:29:56 <gribble> 223957
480 2013-03-02 21:30:03 <doe> lol
481 2013-03-02 21:30:59 <sipa> ;;bc,nethash
482 2013-03-02 21:31:01 <gribble> 31005.21299985471
483 2013-03-02 21:34:26 <nanotube> BlueMatt: indeed. i guess just gotta discuss to see if anyone's willing to do it...
484 2013-03-02 21:36:16 <Luke-Jr> nanotube: how much is involved in mentoring?
485 2013-03-02 21:48:03 <nanotube> Luke-Jr: i am not sure, i don't have personal experience with this. gmaxwell has mentioned that he does, though.
486 2013-03-02 21:49:03 <nanotube> there are probably docs about it on the gsoc site and elsewhere. at the very least, we'd need to come up with a relatively-detailed project plan, and then guide the student(s) along to completion.
487 2013-03-02 22:14:12 <fatAgnes> how do i compile bt-qt from source?
488 2013-03-02 22:14:36 <sipa> download it
489 2013-03-02 22:14:41 <sipa> make
490 2013-03-02 22:14:41 <sipa> qmake
491 2013-03-02 22:14:54 <fatAgnes> in windwos?
492 2013-03-02 22:15:10 <sipa> no ide
493 2013-03-02 22:15:29 <sipa> doing a cross-compile under ubuntu will be easier
494 2013-03-02 22:18:11 <swhitt> there's a homebrew keg for bitcoin-qt, bitcoind and armory
495 2013-03-02 22:20:08 <fatAgnes> sorry, but how did they make the windwos version?
496 2013-03-02 22:20:19 <fatAgnes> I think I will make a c# client, better
497 2013-03-02 22:20:23 <fatAgnes> how about mining
498 2013-03-02 22:20:29 <fatAgnes> a client is also a miner?
499 2013-03-02 22:20:34 <sipa> fatAgnes: the windows version is crosscompiled on linux
500 2013-03-02 22:20:48 <fatAgnes> fuck!
501 2013-03-02 22:20:58 <sipa> and writing a full client from scratch probably takes at least a few months
502 2013-03-02 22:21:18 <sipa> not that it's that much code, but there are several intricate things you need to understand
503 2013-03-02 22:21:53 <sipa> and the reference client doesn't really have mining code it (except for a slow, non-pool-capable, non-optimized, CPU-only version)
504 2013-03-02 22:22:28 <sipa> as most mining these days is done by GPUs or FPGAs, and soon probably ASICs, you need very specialized programs anyway
505 2013-03-02 23:11:50 <fatAgnes> i guess these programs are not open source since they earn the owner huge amounts of $$$$$
506 2013-03-02 23:13:22 <sipa> ?
507 2013-03-02 23:56:30 <Luke-Jr> fatAgnes: BFGMiner is pretty open source, GPLv3