1 2012-02-22 00:09:42 <BlueMatt> meeting?
  2 2012-02-22 00:09:53 <sipa> It was tuesday.
  3 2012-02-22 00:11:24 <BlueMatt> you mean last tuesday?
  4 2012-02-22 00:12:06 <sipa> There was once the idea to hold a meeting every tuesday at 21:00 UTC; yesterday however, there was none.
  5 2012-02-22 00:14:36 <luke-jr> today is Tuesday
  6 2012-02-22 00:16:12 <sipa> To me, and in UTC, it is not.
  7 2012-02-22 00:17:35 <luke-jr> :p
  8 2012-02-22 00:49:22 <Kiba> I CHALLENGE YE TO A DUEL!
  9 2012-02-22 01:02:13 <Graet> definitely wednesday
 10 2012-02-22 01:09:46 <luke-jr> [20:51:47] <-- Kiba has left this server (Read error: Operation timed out). <-- I win?
 11 2012-02-22 01:10:02 <k9quaint> unless it is a duel of disconnects
 12 2012-02-22 01:10:07 <conman> lol
 13 2012-02-22 01:10:45 <k9quaint> my favorite viperjbm thread was nuked :(
 14 2012-02-22 01:11:03 <k9quaint> guess I will have to floss my cat instead of post in it :|
 15 2012-02-22 01:12:24 <Graet> still wednesday whether Kiba left or not
 16 2012-02-22 01:12:30 <k9quaint> luke-jr: kiba is kicking your ass in the disconnect contest
 17 2012-02-22 01:13:05 <k9quaint> Graet: its tuesday in the part of the world that is amazing
 18 2012-02-22 01:13:25 <k9quaint> ly stupid
 19 2012-02-22 01:13:32 <Graet> :)
 20 2012-02-22 01:13:37 <k9quaint> pre-mature press of enter key
 21 2012-02-22 01:13:41 <Graet> lol
 22 2012-02-22 01:13:52 <Graet> i was completeing the scentence - but you did :)
 23 2012-02-22 01:14:20 <k9quaint> there is a braincell holocaust going on in my head
 24 2012-02-22 01:14:32 <k9quaint> <--- reading something Rick Santorum wrote
 25 2012-02-22 01:23:54 <JFK911> again?
 26 2012-02-22 01:33:51 <gribble> The average time to generate a block at 4000 Khps, given the supplied difficulty of 7.27, is 2 hours, 10 minutes, and 6 seconds
 27 2012-02-22 01:33:51 <sipa> ;;bc,calcd 4000 7.27
 28 2012-02-22 01:45:13 <sipa> ;;bc,calcd 11500 7.27
 29 2012-02-22 01:45:14 <gribble> The average time to generate a block at 11500 Khps, given the supplied difficulty of 7.27, is 45 minutes and 15 seconds
 30 2012-02-22 02:28:01 <TheEternal> I have a tech support question. my friend was mining back in July of last year. His bitcoin wallet was version 0.3.24 and he couldn't connect. so he upgraded to 0.5.2. it opened but he is stuck at block 144943. does anoyone know why?
 31 2012-02-22 02:29:12 <luke-jr> TheEternal: usually cases like that are because of corrupt blockchains
 32 2012-02-22 02:29:22 <luke-jr> TheEternal: can you confirm he has some connections?
 33 2012-02-22 02:29:34 <luke-jr> also, if that's the case, probably his statusbar will say something about upgrading
 34 2012-02-22 02:29:58 <luke-jr> first thing to do is confirm he has some connections, though
 35 2012-02-22 02:30:40 <TheEternal> yeah he has about 12 connections. it does say "upgrade..."
 36 2012-02-22 02:31:05 <luke-jr> TheEternal: OK, sounds like blockchain is corrupt
 37 2012-02-22 02:31:15 <luke-jr> TheEternal: Delete blk*.dat and restart
 38 2012-02-22 02:31:21 <luke-jr> whatever you do, do NOT delete wallet.dat
 39 2012-02-22 02:31:28 <TheEternal> ok let me try
 40 2012-02-22 02:32:45 <TheEternal> ok. where is the blk*.dat files?
 41 2012-02-22 02:32:52 <luke-jr> somewhere.
 42 2012-02-22 02:33:07 <sipa> The same place as wallet.dat is :)
 43 2012-02-22 02:33:08 <TheEternal> looking
 44 2012-02-22 02:33:22 <sipa> https://en.bitcoin.it/wiki/Data_directory
 45 2012-02-22 02:35:13 <TheEternal> i have 2 files. blk00001.dat and blkindex.dat. delete both?
 46 2012-02-22 02:35:27 <luke-jr> yes, after you stop the client
 47 2012-02-22 02:35:32 <luke-jr> and the icon disappears
 48 2012-02-22 02:35:42 <sipa> Maybe you just want to rename/move then
 49 2012-02-22 02:35:52 <sipa> As it will take many hours to download them again.
 50 2012-02-22 02:36:11 <luke-jr> sipa: I thought not so long with 0.5.2?
 51 2012-02-22 02:36:25 <TheEternal> yeah. i moved them.
 52 2012-02-22 02:36:41 <sipa> luke-jr: in theory only 20 minutes if you have fast disk and network, yes
 53 2012-02-22 02:37:13 <TheEternal> ok. it is starting at 0 and see how long it takes.
 54 2012-02-22 02:38:06 <luke-jr> TheEternal: it will be done before you finish reciting all of pi
 55 2012-02-22 02:38:14 <sipa> Backwards.
 56 2012-02-22 02:39:13 <TheEternal> Thx Luke-jr
 57 2012-02-22 02:50:50 <TheEternal> ok on m y friends computer it is syncing. i wanted to see how fast it would take on my spare computer to sync and im 24% in already. I installed it about 3 minutes ago.
 58 2012-02-22 02:51:18 <luke-jr> 24% isn't really 24% btw
 59 2012-02-22 02:52:12 <sipa> After 100000 is gets slow.
 60 2012-02-22 02:52:37 <TheEternal> ok. mine is at 6% and his is 24%. still timing it...
 61 2012-02-22 03:20:13 <gribble> New news from bitcoinrss: sipa opened pull request 882 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/882>
 62 2012-02-22 07:12:28 <Joric> why client shows insifficient balance message right after the decryption? shouldn't it be done before i enter the passphrase?
 63 2012-02-22 07:50:48 <wumpus> Joric: yes, I guess you could add a balance check before requesting unlock...
 64 2012-02-22 08:34:31 <cande> whats the commandline for bitcoind using rpcuser&passwords ?
 65 2012-02-22 08:40:56 <gmaxwell> -rpcuser=x -rpcpassword=y  ... but normally you don't provide them on the commandline, you put them in the config.
 66 2012-02-22 08:42:22 <cande> ah, thx gmaxwell works now
 67 2012-02-22 08:52:24 <Joric> did anyone notice bitcoin.org has a terrible, terrible 404 page? http://bitcoin.org/12341234
 68 2012-02-22 08:53:24 <Joric> there's no backlink even
 69 2012-02-22 08:54:02 <Joric> how users could get back to the front page
 70 2012-02-22 08:58:09 <wumpus> make a better one, issue a pull request to https://github.com/bitcoin/bitcoin.org
 71 2012-02-22 08:58:46 <UukGoblin> Joric, with their... back button?
 72 2012-02-22 09:00:00 <wumpus> I agree it's terrible though, seems github hijacks them
 73 2012-02-22 09:48:19 <Joric> about print in python
 74 2012-02-22 09:48:25 <Joric> - in python 2.x you must use it as a statement.
 75 2012-02-22 09:48:29 <Joric> - in python 3.x you can't use it as a statement.
 76 2012-02-22 09:49:07 <Joric> guido went crazy
 77 2012-02-22 09:50:15 <sturles> python: Programming the way Guido indented it!
 78 2012-02-22 09:50:22 <wumpus> I think his rationale for making it a function was "to simplify the language", as in why would print be an exception?
 79 2012-02-22 09:50:30 <sipa> why make skmething a statement if it works as well as an expression?
 80 2012-02-22 09:51:27 <wumpus> print had an awful syntax, with >> if you wanted to print to a stream ,wtf
 81 2012-02-22 09:52:21 <Joric> yeah just used it recently, print >> sys.stderr, "..." pretty convenient
 82 2012-02-22 09:53:13 <wumpus> convenience is only a matter of habit
 83 2012-02-22 09:56:00 <Joric> not sure how it would look in python 3, something like print('...', file=sys.stderr)
 84 2012-02-22 09:59:50 <wumpus> yes
 85 2012-02-22 11:05:12 <MagicalTux> https://mtgox.com/api/stats/ua <- stats on user agents seen on online bitcoin nodes (https://bitcointalk.org/index.php?topic=64987.0 for more details)
 86 2012-02-22 12:37:26 <MagicalTux> gmaxwell: I fixed the bitcoin nodes db fyi
 87 2012-02-22 12:37:54 <MagicalTux> issue was way too many unreachable nodes, and the system couldn't scan fast enough to know all nodes. Fixed by implementing parallel scan
 88 2012-02-22 12:39:18 <sipa> MagicalTux: my bitcoin-seeder crawler is able to keep up with the network and work through all nodes in +- 20-30 minutes if I use around 25 threads
 89 2012-02-22 12:39:34 <MagicalTux> sipa: I use a single thread
 90 2012-02-22 12:39:37 <MagicalTux> but 200 active sockets
 91 2012-02-22 12:40:19 <MagicalTux> I'm planning on putting into production 4 "super nodes" that can handle a large number of connection and will appear as connectable from other nodes to collect more info
 92 2012-02-22 12:40:32 <MagicalTux> (also I'm collecting user agents from BIP#0014 too)
 93 2012-02-22 12:43:11 <MagicalTux> so far I only see bitcoin-qt as a user agent
 94 2012-02-22 12:44:44 <sipa> MagicalTux: nanotube compared your nodes database with a dump from my crawler by the way; the conclusion was that only 20% of his selected seed nodes appeared in my list, but those had on average >60% uptime according to my statistics
 95 2012-02-22 12:45:37 <MagicalTux> sipa: my list was quite incomplete since ~september as visible on this graph: http://stats.bitcoin.it/rrd/nodes_total-year.png
 96 2012-02-22 12:45:56 <MagicalTux> the crawling has resumed now and has already more than 50k nodes
 97 2012-02-22 12:47:21 <sipa> I have 21k nodes, but it ignores old version, and bans not-frequently-responsive ones
 98 2012-02-22 12:47:25 <MagicalTux> http://stats.bitcoin.it/rrd/nodes_total-day.png <- resuming of crawling
 99 2012-02-22 12:48:01 <sipa> I can give you a dump of my db, if you like
100 2012-02-22 12:48:41 <MagicalTux> it's building fine here :)
101 2012-02-22 12:48:45 <sipa> ok
102 2012-02-22 12:48:47 <MagicalTux> I don't need to touch it
103 2012-02-22 12:48:54 <MagicalTux> it works by itself, at its own pace
104 2012-02-22 12:49:21 <MagicalTux> and I can easily increase the pace if needed
105 2012-02-22 12:49:42 <badluck> par-T
106 2012-02-22 12:49:42 <gribble> The operation succeeded.
107 2012-02-22 12:49:42 <sipa> ;;later tell nanotube 14:45:37 < MagicalTux> sipa: my list was quite incomplete since ~september as visible on this graph: http://stats.bitcoin.it/rrd/nodes_total-year.png; the crawling has resumed now and has already more than 50k nodes
108 2012-02-22 12:51:36 <sipa> ;;later tell nanotube Maybe another update of the seed list?
109 2012-02-22 12:51:37 <gribble> The operation succeeded.
110 2012-02-22 12:59:13 <MagicalTux> sipa: btw if it's about seed list, using our "bootstrap" list could be possible too (nodes in that list were successfully connected to less than 1 hour ago): https://mtgox.com/api/stats/bootstrap
111 2012-02-22 12:59:42 <MagicalTux> right now I erased the db so it's random nodes, however in ~15 days it'll filter out any node that was down in the past 15 days
112 2012-02-22 12:59:44 <gribble> New news from bitcoinrss: sipa opened pull request 883 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/883>
113 2012-02-22 13:25:25 <luke-jr> MagicalTux: BIP 14 is mostly useless, as bitcoind developers refuse to implement it properly; it is intentionally lying about client/version
114 2012-02-22 13:25:50 <luke-jr> MagicalTux: so it's impossible to tell if a client is Bitcoin-Qt or bitcoind
115 2012-02-22 13:26:00 <MagicalTux> luke-jr: that reminds me of web user agents
116 2012-02-22 13:26:24 <luke-jr> MagicalTux: yeah, it's just annoying because BIP 14 was specifically designed to avoid that problem :/
117 2012-02-22 13:27:56 <sipa> Not distinguishing between bitcoin-qt and bitcoind is reasonable, imho, but always advertizing as bitcoin-qt is strange
118 2012-02-22 13:27:59 <riush> i've seen a /Satoshi:0.6.0/ ua the other day.. isn't that bitcoind?
119 2012-02-22 13:28:20 <luke-jr> riush: that's a BIP 14-compatible bitcoind, not mainline
120 2012-02-22 13:28:33 <riush> ah, i see
121 2012-02-22 13:28:50 <luke-jr> sipa: my BIP 14 bugfix patch says "Satoshi" and has a build-time option for adding the specific client on the end
122 2012-02-22 13:29:06 <luke-jr> riush: probably a next-test or Eligius node
123 2012-02-22 13:29:13 <youdied> gdfgdfg
124 2012-02-22 13:29:33 <sipa> luke-jr: but by default it adds bitcoin-qt or bitcoind as well, no?
125 2012-02-22 13:29:38 <youdied> fuck. how do I hide my IP address?
126 2012-02-22 13:29:46 <sipa> youdied: disconnect from the internet
127 2012-02-22 13:29:54 <luke-jr> sipa: no, by default it omits that
128 2012-02-22 13:30:23 <luke-jr> sipa: you have to build with -DPUBLIC_CLIENT_NAME to add those
129 2012-02-22 13:30:36 <youdied> anyone answering me how to hide my IP?
130 2012-02-22 13:31:02 <sipa> youdied: if you want a more specific answer, you'll need to ask a more specific question :)
131 2012-02-22 13:31:21 <MagicalTux> luke-jr: I guess .ljr2 is you ?
132 2012-02-22 13:31:33 <luke-jr> MagicalTux: a very old codebase I wrote
133 2012-02-22 13:31:33 <MagicalTux> https://mtgox.com/api/stats/ua <- you appear in there
134 2012-02-22 13:31:41 <luke-jr> I don't *think* I use it anywhere anymore
135 2012-02-22 13:31:51 <MagicalTux> luke-jr: I could tell you the ip
136 2012-02-22 13:32:01 <luke-jr> sure
137 2012-02-22 13:32:03 <luke-jr> PM
138 2012-02-22 13:32:06 <sipa> luke-jr: I'd be fine with just advertizing as /Satoshi:0.6.0/, actually
139 2012-02-22 13:32:18 <luke-jr> MagicalTux: yeah, that's not me
140 2012-02-22 13:32:31 <MagicalTux> running bitcoind 3.23
141 2012-02-22 13:32:35 <helo> youdied: write it down on a piece of paper and put it under your mattress
142 2012-02-22 13:32:35 <luke-jr> sipa: it'd be an improvement over the current situation, for sure
143 2012-02-22 13:33:22 <luke-jr> (it'd also be compliant)
144 2012-02-22 13:42:27 <libcoin> would it make sense to distinguish between 0.6.0-bip16 and 0.6.0-bip17 ?
145 2012-02-22 13:43:06 <libcoin> it is different protocols (they will not forward each others P2SHs)
146 2012-02-22 13:43:20 <libcoin> P2SH-tx'es that is
147 2012-02-22 13:44:34 <luke-jr> libcoin: I don't think it's long-term enough to be a concern
148 2012-02-22 13:44:50 <luke-jr> libcoin: neither BIP is valid until adopted, and once one is adopted, there's no purpose keeping the other around
149 2012-02-22 13:46:55 <libcoin> right, that is a point, though it would be nice to be able to see how many of the different clients would be out there
150 2012-02-22 13:48:08 <libcoin> Btw - I just started updating libcoin to support both, do you see any immediate issues with that ?
151 2012-02-22 13:48:58 <libcoin> They are treated as two different chains bitcoin-bip16 and bitcoin-bip17, however, I would like to have a bitcoin-bip16&17 too, but I havn
152 2012-02-22 13:49:04 <Graet> http://blockchain.info/P2SH  <
153 2012-02-22 13:49:21 <libcoin> t been through all the bip 17 code yet
154 2012-02-22 13:50:25 <libcoin> Graet: as you show most agree that P2SH is a good idea, how is the question...
155 2012-02-22 13:50:59 <sipa> There's around 35% support for BIP16 now.
156 2012-02-22 13:51:05 <gavinandresen> that question has been answered, in my opinion.  BIP 16 has the support of the core dev team, the mining pools, and "the community"
157 2012-02-22 13:51:12 <Graet> ^^
158 2012-02-22 13:51:47 <gavinandresen> Last I heard, luke was going to withdraw BIP 17
159 2012-02-22 13:52:22 <sipa> This means that there is 50.7% support from the network-except-deepbit
160 2012-02-22 13:52:36 <gavinandresen> Time to ask Tycho to get busy
161 2012-02-22 13:54:41 <libcoin> gavinandresen: regarding 16/17, I don't really care, one of the points with libcoin is to make it easy to choose any chain, but if there is no need to code both 16 and 17 I can save some time.
162 2012-02-22 13:55:16 <luke-jr> gavinandresen: BIP 17 has just as much dev/community support
163 2012-02-22 13:56:24 <libcoin> gavinandresen: and regarding you statement for withdrawal of bip17 - it ain't final till it is on the mailing list
164 2012-02-22 13:56:45 <libcoin> (according to the nice video you posted the other day)
165 2012-02-22 13:56:49 <gavinandresen> luke-jr: did you watch that poisonous people video?  You're doing it again, saying the same thing over and over and over again hoping nobody notices that you are the ONLY ONE MAKING THE ARGUMENT
166 2012-02-22 13:56:52 <luke-jr> I've deferred withdrawing BIP 17 as a result of more people expressing support
167 2012-02-22 13:58:26 <gavinandresen> There will be people expressing support for any side to any issue. But to keep a project moving forward at some point a decision has to be made and we have to move forward.
168 2012-02-22 13:58:32 <gavinandresen> I don't understand why you can't see that.
169 2012-02-22 13:58:43 <luke-jr> gavinandresen: I did watch it. You are the only one arguing against BIP 17. How about we stop with the name calling, and just drop anything other than useful conversation?
170 2012-02-22 13:59:31 <gavinandresen> Ok, then, what will it take for you to withdraw BIP 17 so we can move forward?
171 2012-02-22 13:59:53 <luke-jr> gavinandresen: BIP 16 achieving a majority, and no reason to expect that to change.
172 2012-02-22 14:00:04 <luke-jr> possibly sooner than that, but that will definitely do it
173 2012-02-22 14:00:16 <luke-jr> how about the inverse? what will it take for you to withdraw BIP 16 so we can move forward?
174 2012-02-22 14:00:21 <sipa> To me, it is obvious that both solutions are viable, but we as a community must be able to choose one above the other; given that BIP16 has more support (for whatever reason), that one is the easiest choice.
175 2012-02-22 14:00:42 <Graet> ^^^
176 2012-02-22 14:00:59 <sipa> Without.
177 2012-02-22 14:01:15 <sipa> Unfortunately, but that would make it even harder to roll out.
178 2012-02-22 14:02:35 <gavinandresen> I'd withdraw BIP16 if the poll you created on the forums showed there was a majority support for BIP17, if the wiki page with developer support you created showed a preference for BIP17, and if there were more votes in the blockchain for BIP17.  Actually, any 2 of those 3 would convince me.
179 2012-02-22 14:03:26 <gavinandresen> Now speaking of moving forward I'm done talking more about BIP16 versus 17, I'm going to get some productive work done.
180 2012-02-22 14:03:33 <luke-jr> sounds good
181 2012-02-22 14:03:47 <luke-jr> hopefully this will all be done by March
182 2012-02-22 14:37:12 <UukGoblin> amazing how close the total hashrate is to 10THash/s
183 2012-02-22 14:37:15 <luke-jr> sipa: https://github.com/bitcoin/bitcoin/pull/884
184 2012-02-22 14:37:18 <UukGoblin> almost like if someone wanted to keep it there
185 2012-02-22 14:41:30 <gribble> New news from bitcoinrss: luke-jr opened pull request 884 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/884>
186 2012-02-22 15:09:23 <wumpus> i'm getting so incredibly tired of this... just had to restrain myself from going into a rage onthe forums. Another idiot that thinks he can just start listing things and we'll start implementing them.. ffs just contribute code or shut up
187 2012-02-22 15:10:22 <gmaxwell> wumpus: Just respond "patches accepted"
188 2012-02-22 15:10:54 <gmaxwell> (it's hard to do that when they're also suggesting idiotic stuff but if they do implement they'll get a clue in the process)
189 2012-02-22 15:11:21 <wumpus> well I love getting your ideas... don't get me wrong, but please don't pretend you know things better if you've never written a line of  bitcoin code, and certainly don't feel entitled to them being implemented...
190 2012-02-22 15:11:29 <wumpus> gmaxwell: yep I did that :)
191 2012-02-22 15:12:09 <gmaxwell> yea. Ideas are cheap still good to hear. Implementation (and testing) is the hard part.
192 2012-02-22 15:12:13 <gavinandresen> "Great idea, somebody should implement that."
193 2012-02-22 15:13:07 <luke-jr> if only there was a reason to expect stuff to get merged once implemented ;p
194 2012-02-22 15:13:16 <gavinandresen> or "Great idea, just not a development priority for me right now."
195 2012-02-22 15:13:29 <wumpus> ideas are great, but I wish people would just bring them like "it might be a good idea to add..." instead of complaining about them as "absent features"
196 2012-02-22 15:14:00 <gavinandresen> Yup. It's not like we're getting rich with all the work we're doing....
197 2012-02-22 15:14:03 <wumpus> exactly gavinandresen
198 2012-02-22 15:14:42 <wumpus> luke-jr: well it depends of course on how controversial the change is / how much impact it has
199 2012-02-22 15:14:43 <gavinandresen> Speaking of which....  I'm really curious to see what happens with etotheipi's crowdfunding experiment
200 2012-02-22 15:14:47 <luke-jr> gavinandresen: would a fulldump option for getblock be accepted?
201 2012-02-22 15:15:08 <wumpus> eotheipi seems to be doing it right
202 2012-02-22 15:15:17 <luke-jr> wumpus: Coinbaser has zero controversy or impact (to people who don't enable it), yet it's been stable for nearly a year ;)
203 2012-02-22 15:15:31 <sipa> I'd like a dumptransaction and a dumpblock feature.
204 2012-02-22 15:15:39 <luke-jr> sipa: a separate RPC command?
205 2012-02-22 15:15:53 <gavinandresen> luke-jr: sure, if you can get agreement on what the output aught to be (raw hex dump? separate fields?  full transactions or just txids?)
206 2012-02-22 15:15:53 <luke-jr> and what would dumptxn do different from gettxn?
207 2012-02-22 15:16:15 <luke-jr> gavinandresen: there's been a somewhat standard format for a long time in jgarzik's dumpblock branch
208 2012-02-22 15:16:44 <luke-jr> the difference from getblock afaik is only that it includes the full txns instead of ids
209 2012-02-22 15:16:50 <luke-jr> so you don't need to flood bitcoind with gettxn for each
210 2012-02-22 15:17:04 <sipa> luke-jr: gettransaction has some things that are mostly wallet-specific (for example, it has a fee calculation that does not need the block chain, and may differ from the actual transaction's fee in exotic cases)
211 2012-02-22 15:17:50 <luke-jr> sipa: doesn't fee calculation *always* need the blockchain? O.o
212 2012-02-22 15:18:08 <sipa> luke-jr: no, wallet transactions store more information
213 2012-02-22 15:18:26 <luke-jr> ok, so a cached fee& but in that case, isn't it a bug if it doesn't match?
214 2012-02-22 15:18:33 <sipa> maybe, yes
215 2012-02-22 15:18:45 <sipa> but it's impossible to calculate the real fee without the block chain
216 2012-02-22 15:19:09 <sipa> and it requires looking at all prevouts
217 2012-02-22 15:20:11 <sipa> so maybe "dumptransaction" should not give the fee at all (it's really a raw dump of the transaction as it exists in the chain), and "gettransaction" should (it gives a transaction from the point of entry-in-wallet-ledger)
218 2012-02-22 15:20:28 <luke-jr> gavinandresen: is there a reason getblock uses mrkl_root instead of merkleroot ?
219 2012-02-22 15:20:49 <luke-jr> sipa: can always ignore extra data imo
220 2012-02-22 15:21:16 <sipa> right, but what when headers-only is implemented?
221 2012-02-22 15:21:48 <luke-jr> sipa: I don't see how that changes anything here
222 2012-02-22 15:22:03 <gavinandresen> luke-jr: ? which getblock?  the getblock in GIT head outputs merkleroot
223 2012-02-22 15:22:06 <sipa> it feels somewhat cleaner that you can say "command X always works, command Y requires full mode", instead of "depending on what is available, command X either gives information or fails, unless it's a wallet tx"
224 2012-02-22 15:22:11 <luke-jr> gavinandresen: sorry, I'm getting my diff backward
225 2012-02-22 15:22:32 <luke-jr> sipa: not for an API, IMO; easier to run one method, then check what's in the result
226 2012-02-22 15:22:45 <sipa> ok, maybe
227 2012-02-22 15:26:57 <sipa> wow, 48 commits since v0.6.0rc1 (exclusing merges)
228 2012-02-22 15:27:10 <LittleDuke> i have two transactions one at .0597889 @ 157 confirms and a 1.0 @ 147 confirms, but i'm getting this error from bitcoind atm when i try to do a sendtoaddress 1.0597889 "error: {"code":-4,"message":"Error: This transaction requires a transaction fee of at least 0.0005 because of its amount, complexity, or use of recently received funds  "}"  -- wondering that triggering conditions are causing this, since i haven't seen this
229 2012-02-22 15:27:11 <LittleDuke> before
230 2012-02-22 15:28:42 <gavinandresen> LittleDuke: https://en.bitcoin.it/wiki/Transaction_fees
231 2012-02-22 15:28:46 <LittleDuke> btw, i'm working on some autopay gateway software atm
232 2012-02-22 15:47:18 <luke-jr> gavinandresen: is it OK if I change hashprevious/hashnext to prevblock/nextblock?
233 2012-02-22 15:47:47 <sipa> Since when were hashprevious/hashnext in use?
234 2012-02-22 15:49:18 <luke-jr> sipa: getblock has it in git master
235 2012-02-22 15:50:07 <gavinandresen> since 0.5 I think.  hash/hashprevious/hashnext makes sense to me.  I'd expect previousblock to be a json object with the entire previous block.....
236 2012-02-22 15:50:42 <gavinandresen> getmemorypool has previousblockhash
237 2012-02-22 15:50:55 <sipa> BBE has prev_block
238 2012-02-22 15:50:58 <gavinandresen> (sigh, I hate naming inconsistencies)
239 2012-02-22 15:52:31 <luke-jr> gavinandresen: may I make it consistent with gmp?
240 2012-02-22 15:52:36 <sipa> gmp?
241 2012-02-22 15:52:50 <sipa> ah, getmemorypool
242 2012-02-22 15:53:32 <vegard> is there a way to get raw transactions in json format as on blockexplorer? I have bitcoin 0.5.2
243 2012-02-22 15:54:05 <gavinandresen> luke-jr: consistency is good, but so is compatibility.   Deprecate hashprevious, report both hashprevious and previousblockhash I think
244 2012-02-22 15:54:40 <sipa> gavinandresen: just checked; getblock was not in 0.5.0
245 2012-02-22 15:54:41 <luke-jr> I don't think getblock was in 0.5 at all?
246 2012-02-22 15:54:56 <gavinandresen> It wasn't?  Great!  Then yes, rename.
247 2012-02-22 15:55:16 <luke-jr> k
248 2012-02-22 15:56:42 <sipa> luke-jr: you'll maybe want to merge with my getalltransactions?
249 2012-02-22 15:56:57 <luke-jr> gavinandresen: blockcount -> height too, to match your proposed getmemorypool change?
250 2012-02-22 15:57:03 <luke-jr> sipa: what's that?
251 2012-02-22 15:57:09 <sipa> luke-jr: https://github.com/bitcoin/bitcoin/pull/841/files
252 2012-02-22 15:57:24 <luke-jr> oh right
253 2012-02-22 15:57:28 <luke-jr> that wasn't merged yet? :/
254 2012-02-22 15:58:47 <sipa> Technically not in scope for merging after a release candidate, but we've violated that already a few times :)
255 2012-02-22 15:58:50 <luke-jr> Is GetSerializeSize slow or cheap?
256 2012-02-22 16:00:25 <sipa> It goes through the same steps as Serialize, but doesn't write anythinh
257 2012-02-22 16:01:45 <luke-jr> I don't know how cheap/expensive Serialize is either :P
258 2012-02-22 16:01:58 <luke-jr> is it acceptable to do it every getblock, to provide the 'size' field?
259 2012-02-22 16:02:18 <gavinandresen> cheap. yes.
260 2012-02-22 16:02:32 <sipa> You're going to deserialize the block anyway already, which is certainly a lot slower.
261 2012-02-22 16:08:26 <luke-jr> gavinandresen: can getalltransactions be merged into master pretty please? <.<
262 2012-02-22 16:08:44 <luke-jr> would make this fulldump mode *so* much simpler, and less redundant work
263 2012-02-22 16:09:14 <luke-jr> sipa: I think it might be waiting for a reply to a comment Gavin made on the code
264 2012-02-22 16:09:16 <sipa> it shouldn't; gavin just found a bug in it...
265 2012-02-22 16:09:29 <luke-jr> ah, didn't notice that was 2 mins ago :D
266 2012-02-22 16:09:39 <BlueMatt> gavinandresen: do you know whats up with deepbit and bip16?
267 2012-02-22 16:09:47 <luke-jr> maybe I'll do this in 2 steps then
268 2012-02-22 16:10:10 <gavinandresen> I'd be happier about making an exception and squeezing it into 0.6rc2 if there was a test plan and somebody other than sipa had tested it thoroughly....
269 2012-02-22 16:10:32 <gavinandresen> A pull to clean up getblock's naming is a good idea
270 2012-02-22 16:11:20 <luke-jr> gavinandresen: (height in coinbase) would it break the auto-enforce rule, if miners start putting the height there without the enforcement code?
271 2012-02-22 16:11:31 <gavinandresen> BlueMatt: nope, I'm going to send tycho an email and ask what's up and what I/we can do to help.
272 2012-02-22 16:12:03 <BlueMatt> gavinandresen: kinda need that tomorrow if you want to make the march 1 target...
273 2012-02-22 16:12:12 <gavinandresen> luke-jr: no, as long as they don't lie about the height that'd be fine.
274 2012-02-22 16:14:27 <luke-jr> gavinandresen: we need to standardize on a base for 'height': is genesis 0 or 1?
275 2012-02-22 16:14:58 <luke-jr> or is this one of sipa's "version king" things? :p
276 2012-02-22 16:15:44 <gavinandresen> It is the number returned by getinfo
277 2012-02-22 16:16:19 <gavinandresen> (that is, we already have a standard-- is there an inconsistency somewhere?)
278 2012-02-22 16:16:32 <luke-jr> gavinandresen: various part of JSON-RPC report genesis==0 and others genesis==1
279 2012-02-22 16:16:47 <luke-jr> I think getinfo blocks is genesis==1
280 2012-02-22 16:17:06 <gavinandresen> I think that's right.  WHen genesis is the tip, there is 1 block in the chain.
281 2012-02-22 16:17:44 <luke-jr> maybe the inconsistency is just internal then
282 2012-02-22 16:17:46 <luke-jr> nHeight is 0-based
283 2012-02-22 16:19:23 <sipa> luke-jr: I'm reworking my pull request a bit to make it easier to pull out extra information
284 2012-02-22 16:19:39 <luke-jr> sipa: a TransactionToJSON would be nice
285 2012-02-22 16:20:24 <luke-jr> gavinandresen: so from now on, I can consider any case of genesis==0 to be a bug? ;)
286 2012-02-22 16:21:13 <sipa> that makes getblockhash non-compliant
287 2012-02-22 16:21:24 <sipa> (it uses genesis==0)
288 2012-02-22 16:23:04 <luke-jr> it does look like whoever wrote getblockhash knew it was 0-based& :/
289 2012-02-22 16:23:34 <luke-jr> gavinandresen: that was you. input?
290 2012-02-22 16:23:36 <LittleDuke> damn coder's can't count to one ;)
291 2012-02-22 16:24:21 <luke-jr> oh
292 2012-02-22 16:24:30 <luke-jr> getinfo shows 0 by default after all -.-
293 2012-02-22 16:24:31 <gribble> New news from bitcoinrss: luke-jr opened pull request 885 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/885>
294 2012-02-22 16:27:03 <gavinandresen> luke-jr: can you do some testing inthe future before asking questions?  I just wasted a few minutes questioning myself because getinfo DOES report genesis==tip as blockcount 0
295 2012-02-22 16:27:19 <luke-jr> gavinandresen: sorry
296 2012-02-22 16:27:22 <luke-jr> I'll try
297 2012-02-22 16:27:27 <gavinandresen> ty
298 2012-02-22 16:27:44 <luke-jr> that pullreq is not suitable for merging now fwiw
299 2012-02-22 16:27:47 <luke-jr> I need to fix this
300 2012-02-22 16:29:34 <luke-jr> & longest testnet block ever -.-
301 2012-02-22 16:30:29 <sipa> I have to go now, I'll finish redoing getalltransactions later today.
302 2012-02-22 16:30:39 <luke-jr> BlueMatt: thanks for the gitian fixes in advance.
303 2012-02-22 16:31:44 <luke-jr> OK, pull 885 fixed
304 2012-02-22 16:32:44 <BlueMatt> luke-jr: np
305 2012-02-22 16:33:03 <BlueMatt> luke-jr: Im also doing debug symbol output, which should help a ton
306 2012-02-22 16:33:10 <luke-jr> BlueMatt: awesome
307 2012-02-22 16:34:00 <luke-jr> gavinandresen: I want to add IsInMainChain to getblock output (in the pull planned after sipa's stuff); what should I call it? "main":bool ?
308 2012-02-22 16:34:58 <sipa> luke-jr: depth?
309 2012-02-22 16:35:22 <luke-jr> sipa: we already have height; this is just to differentiate orphans
310 2012-02-22 16:35:36 <sipa> things outside the main chain have depth 0
311 2012-02-22 16:36:06 <sipa> but just a boolean would be fine too
312 2012-02-22 16:36:35 <gavinandresen> yes, orphans should have depth 0.  Extra credit might be the root of the orphan chain (as a hash)
313 2012-02-22 16:36:56 <sipa> Ok, just added a GetTransaction to main that retrieves a transaction from either the memory pool or the block database, and tells you which blockindex it comes from
314 2012-02-22 16:37:07 <sipa> That should simplify/clean things.
315 2012-02-22 16:38:34 <luke-jr> "confirmations": number<depth>?
316 2012-02-22 16:40:37 <luke-jr> sipa: does it get the wallet info too?
317 2012-02-22 16:41:52 <luke-jr> O.o
318 2012-02-22 16:42:14 <luke-jr> CBlockIndex.IsInMainChain looks wrong to me.
319 2012-02-22 16:42:28 <luke-jr> return (pnext || this == pindexBest);
320 2012-02-22 16:42:42 <luke-jr> won't that return true for the root of a multi-block orphan chain?
321 2012-02-22 16:43:34 <luke-jr> I don't see anything clearing pnext when orphaning&
322 2012-02-22 16:43:51 <luke-jr> ok, found it
323 2012-02-22 17:28:25 <luke-jr> [12:36:56] <sipa> Ok, just added a GetTransaction to main that retrieves a transaction from either the memory pool or the block database, and tells you which blockindex it comes from <-- where did you add this?
324 2012-02-22 17:32:14 <Diablo-D3> https://www.youtube.com/watch?v=fE5AcQsmcbg
325 2012-02-22 17:32:32 <BlueMatt> since when does youtube offer ssl?
326 2012-02-22 17:33:09 <luke-jr> BlueMatt: Google's on a everything-must-be-SSL crusade
327 2012-02-22 17:33:19 <BlueMatt> good, everything should be ssl
328 2012-02-22 17:33:33 <luke-jr> meh, I don't want to waste CPU time serving non-sensitive data
329 2012-02-22 17:34:02 <BlueMatt> its like 1 additional cpu microsecond
330 2012-02-22 17:34:07 <luke-jr> &
331 2012-02-22 17:34:20 <luke-jr> compared to kernel webserver?
332 2012-02-22 17:34:21 <BlueMatt> when google switched (something, I dont remember what) to ssl, they published some stuff on how much cputime it actually took
333 2012-02-22 17:34:28 <BlueMatt> it was next to nothing
334 2012-02-22 17:34:41 <luke-jr> next to nothing *per connection*
335 2012-02-22 17:34:46 <BlueMatt> Im pretty sure it mentioned they didnt even have to roll out new hardware
336 2012-02-22 17:34:58 <luke-jr> anyhow, regular HTTP has a webserver in the Linux kernel that can just use DMA basically
337 2012-02-22 17:35:02 <BlueMatt> oh, it was switching gmail or smth to ssl by default
338 2012-02-22 17:35:34 <BlueMatt> luke-jr: yea for static-only content
339 2012-02-22 17:35:45 <luke-jr> right
340 2012-02-22 17:35:53 <luke-jr> which most content really should be
341 2012-02-22 17:36:02 <BlueMatt> ...
342 2012-02-22 17:36:11 <BlueMatt> and yet most content isnt
343 2012-02-22 17:36:12 <sipa> luke-jr: locally; i'll push it to the getalltransactions branch after reworking the rest
344 2012-02-22 17:36:19 <luke-jr> sipa: ok
345 2012-02-22 17:36:22 <BlueMatt> (it has at least some kind of access logging)
346 2012-02-22 17:36:31 <BlueMatt> (tied to a session)
347 2012-02-22 17:36:38 <luke-jr> BlueMatt: access logging doesn't mean it's non-static
348 2012-02-22 17:36:58 <BlueMatt> no, but if you are tying it to a session in a backend db, you cant do it in a kernel webserver
349 2012-02-22 17:37:22 <BlueMatt> s/no/true/
350 2012-02-22 17:37:22 <luke-jr> unless the kernel webserver has a call to userspace for logging :p
351 2012-02-22 17:37:26 <luke-jr> (I don't know if it does)
352 2012-02-22 17:37:52 <luke-jr> oh well
353 2012-02-22 17:37:56 <BlueMatt> meh, for sites where users dont even log in, alright non-ssl all the way...
354 2012-02-22 17:38:09 <luke-jr> CPU time is at least cheaper than programmer/admin time, so this will probably never be simplified anyway
355 2012-02-22 17:38:11 <BlueMatt> for sites where users log in, having it non-ssl by default is criminal negligence
356 2012-02-22 17:54:43 <helo> it would be nice in some areas of the world for wikipedia (non-login) to be ssl
357 2012-02-22 17:56:47 <BlueMatt> it would be nice in some areas in the world for all sites to be ssl
358 2012-02-22 17:57:03 <gavinandresen> +1  everything should be ssl all the time
359 2012-02-22 17:57:34 <gavinandresen> (but the certificate authority system needs a root canal)
360 2012-02-22 17:59:25 <BlueMatt> /nod
361 2012-02-22 17:59:29 <luke-jr> too bad DNSSEC doesn't allow self-signed certs (or does it?)
362 2012-02-22 18:00:05 <BlueMatt> doesnt it in the sense that you can have a cert that isnt signed by your upstream namservers?
363 2012-02-22 18:00:19 <luke-jr> I mean on the HTTPS level
364 2012-02-22 18:00:54 <BlueMatt> you mean dnssec-signing-https-cert
365 2012-02-22 18:01:09 <luke-jr> yes
366 2012-02-22 18:01:32 <BlueMatt> the problem with dnssec for end-user https is that it was never designed to provide end-user security, only security up to the dns resolver
367 2012-02-22 18:01:51 <BlueMatt> so mitm attacks still apply (which is the point of using https)
368 2012-02-22 18:02:27 <BlueMatt> (at least as far as I understand it)
369 2012-02-22 18:02:39 <luke-jr> AIUI, it's different O.o
370 2012-02-22 18:03:15 <sipa> Is there a way to make git fetch --all reuse the same ssh connection to github?
371 2012-02-22 18:04:18 <luke-jr> sipa: you can make SSH itself reuse connections
372 2012-02-22 18:04:24 <BlueMatt> luke-jr: aiui, dnssec provides sigs from root to the dns name to the dns resolver, but if a client isnt doing the resolving, it still depends on what the resolver returns...
373 2012-02-22 18:04:40 <BlueMatt> (or does the resolver return the entire trust chain from the root to the client?)
374 2012-02-22 18:04:56 <denisx> sipa: google for "ssh ControlMaster"
375 2012-02-22 18:07:49 <sipa> luke-jr, denisx: oh wow; wish i knew that earlier
376 2012-02-22 18:11:43 <denisx> I learned it some years ago when Xcode used svn alot
377 2012-02-22 18:21:53 <luke-jr> I wish the first SSH instance forked into the background&
378 2012-02-22 18:22:00 <luke-jr> automatically
379 2012-02-22 18:22:32 <sipa> luke-jr: there's an option to make it linger in the background after closing
380 2012-02-22 18:25:01 <sipa> any suggestion for the number of vin/vout in dumptransaction?
381 2012-02-22 18:25:10 <sipa> BBE uses vin_sz and vout_sz
382 2012-02-22 18:25:26 <forrestv> sipa, are you dumping the list of txins/txouts too..?
383 2012-02-22 18:25:31 <sipa> forrestv: yes
384 2012-02-22 18:25:38 <forrestv> then why provide the length at all?
385 2012-02-22 18:25:50 <sipa> good question :)
386 2012-02-22 18:25:51 <gavinandresen> yes, size is implicit in length of array....
387 2012-02-22 18:26:05 <sipa> ACK: no separate parameter for that
388 2012-02-22 18:26:27 <luke-jr> ^
389 2012-02-22 18:31:43 <sipa> deserialize scripts or not?
390 2012-02-22 18:32:53 <jack_> does anyone know if the functionality described in this SE post is being worked on? http://bitcoin.stackexchange.com/questions/1741/send-bitcoins-using-just-a-pub-and-private-key
391 2012-02-22 18:34:21 <jack_> I keep my private keys in paper (qr code) form. Currently it seems to send funds using those keys I have to import them permanently into a client...
392 2012-02-22 18:35:40 <jack_> What I really want is to scan the private key qr code only when publishing a send transaction... that way the only place my private keys are stored are on a piece of paper in my wallet (also encrypted of course)
393 2012-02-22 18:36:07 <BlueMatt> he doesnt want to have the full chain, and spend with just pubkey/privkey combo
394 2012-02-22 18:36:08 <BlueMatt> that is impossible without atleast a tx
395 2012-02-22 18:36:24 <BlueMatt> to spend any standard tx you need txout sent to privkey, and the privkey
396 2012-02-22 18:37:55 <jack_> what do you mean by "txout sent to privkey" ?
397 2012-02-22 18:38:52 <sipa> jack_: bitcoin does not keep a balance per address
398 2012-02-22 18:39:07 <luke-jr> sipa: I think get* need 3 modes: hash(n/a for gettxn), hexdump, and deserialize
399 2012-02-22 18:39:26 <sipa> jack_: instead, each transaction consumes outputs created by previous transactions
400 2012-02-22 18:39:38 <sipa> and those must be explicitly references
401 2012-02-22 18:39:46 <BlueMatt_> jack_: the output of a transaction spent to the privkey you have
402 2012-02-22 18:39:49 <luke-jr> sipa: otoh, then there's no way to say "deserialize txn, but hexdump scripts" :/
403 2012-02-22 18:39:56 <BlueMatt_> and then you can only spend what was sent in that tx
404 2012-02-22 18:40:57 <jack_> oh, so each send transaction references all previous transactions for the sending address?
405 2012-02-22 18:41:23 <BlueMatt> no
406 2012-02-22 18:41:37 <BlueMatt> each transaction references the specific transaction its spending
407 2012-02-22 18:41:48 <BlueMatt> bitcoin actually has no real concept of addresses
408 2012-02-22 18:42:00 <gmaxwell> Think: Coins. You send coins to the network to be melted down, split and merged.
409 2012-02-22 18:42:12 <jack_> what information does a published transaction consist of?
410 2012-02-22 18:43:01 <BlueMatt> txin contains a pointer to the previous tx its spending, the info necessary to spend that tx (ie pubkey + signature), and a txout which has what info will be required to spend it
411 2012-02-22 18:43:15 <jack_> my understanding was "amount to send", "address to send to", "address to send from", "signature from private key"
412 2012-02-22 18:43:47 <BlueMatt> no, its amount to send, address to send to, signature from privkey, and the previous tx which we are spending
413 2012-02-22 18:43:53 <BlueMatt> addresses dont have a balance, a tx does
414 2012-02-22 18:43:59 <jack_> right right
415 2012-02-22 18:44:07 <sipa> jack_: list of previous inputs to consume (including signatures that prove you own them), list of new outputs to create
416 2012-02-22 18:44:19 <sipa> *previous outputs
417 2012-02-22 18:44:57 <jack_> and the problem is the 'previous transaction' has to be taken from the blockchain?
418 2012-02-22 18:45:05 <sipa> no, but you have to know it
419 2012-02-22 18:45:28 <jack_> couldn't it be fetched from peers?
420 2012-02-22 18:45:39 <sipa> no, you just know it
421 2012-02-22 18:45:42 <sipa> it's like a wallet
422 2012-02-22 18:45:46 <sipa> you know what coins are in there
423 2012-02-22 18:46:06 <sipa> when you perform a transaction, you pick some from them, give some away, put some new ones back
424 2012-02-22 18:46:24 <BlueMatt> there is no way to ask a peer for a list of txes to a given address, as it would make dos way too easy
425 2012-02-22 18:46:53 <jack_> but if I have a wallet (pubkey) i can see the balance by using a public service like block explorer
426 2012-02-22 18:47:19 <jack_> could I not use this information to create a send transaction along with my private key?
427 2012-02-22 18:47:38 <BlueMatt> yes, you could
428 2012-02-22 18:47:46 <jack_> my understanding is that this is what StrongCoin tries to do..
429 2012-02-22 18:47:59 <jack_> but they seem to be failing atm, sadly :/
430 2012-02-22 18:48:31 <BlueMatt> devrandom: ping
431 2012-02-22 18:49:03 <jack_> do you understand my motives for wanting my private keys to not be stored electronically?
432 2012-02-22 18:49:38 <jack_> or is bitcoin just not designed to be used in this way...
433 2012-02-22 18:50:08 <BlueMatt> there are better ways to not store privkeys on a wallet server
434 2012-02-22 18:50:23 <jack_> how?
435 2012-02-22 18:50:29 <BlueMatt> deterministic wallets
436 2012-02-22 18:51:07 <BlueMatt> jack_: https://bitcointalk.org/index.php?topic=19137.0 see type 2
437 2012-02-22 18:51:35 <jack_> right, but then you have the same problem when trying to publish send transactions right?
438 2012-02-22 18:52:05 <BlueMatt> ???
439 2012-02-22 18:52:28 <jack_> one sec reading link
440 2012-02-22 18:56:57 <jack_> I don't see how this is any different from simply storing the public/private key on paper in relation to sending transactions
441 2012-02-22 18:57:20 <luke-jr> anyone want to figure out projects to submit for GSoc?
442 2012-02-22 18:57:44 <jack_> from the wiki i read: "private and public keys are all derived from a starting seed value"
443 2012-02-22 18:58:18 <BlueMatt> jack_: maybe I dont understand what you want to do, but if your idea is to not store all the info that is required to send coins on a web-facing server, then deterministic keys solves your problem
444 2012-02-22 18:59:34 <jack_> BlueMatt: I already avoid storing all the info required to send coins on a web facing server
445 2012-02-22 18:59:55 <BlueMatt> jack_: so what are you trying to do?
446 2012-02-22 19:00:16 <Graet> secure his electronic crypto currency by writing it on paper
447 2012-02-22 19:00:44 <BlueMatt> I thought a. he already did that
448 2012-02-22 19:00:48 <BlueMatt> and b. you can do that with det keys
449 2012-02-22 19:01:02 <jack_> the trouble is, when it comes to the point where I have to send transactions. I have to do a full import. I don't want to do that. I just want to build a send transaction, sign it with my private key, and publish it to the network.
450 2012-02-22 19:01:18 <BlueMatt> so use an encrypted wallet
451 2012-02-22 19:01:38 <BlueMatt> it gets you the same result - info required to spend coins isnt available until send-time and then is no longer available directly thereafter
452 2012-02-22 19:02:42 <jack_> yes, this is what i'm after - how do I do that?
453 2012-02-22 19:03:06 <vegard> does the client detect attempts at double spending?
454 2012-02-22 19:03:14 <BlueMatt> vegard: on
455 2012-02-22 19:03:15 <BlueMatt> no
456 2012-02-22 19:03:36 <luke-jr> vegard: it can't really
457 2012-02-22 19:04:08 <Ferroh> sigh blockchain.info's json API doesn't work now...
458 2012-02-22 19:04:10 <BlueMatt> jack_: see rpc commands like: encryptwallet, unlockwallet, etc
459 2012-02-22 19:04:45 <jack_> BlueMatt: I thought "StrongCoin.com" would work, however, they seem to be having problems related to the rpc commands available
460 2012-02-22 19:04:50 <vegard> well, if the client receives two transactions spending the same output, that would constitute a double spending attempt, no?
461 2012-02-22 19:05:05 <BlueMatt> jack_: if you want security, depending on a 3rd party to hold your coins is kinda...wrong...
462 2012-02-22 19:05:42 <jack_> exactly, that's why my private keys are encrypted qr codes in my wallet :)
463 2012-02-22 19:07:06 <jack_> but if I want to send transactions from those accounts, I don't want to import them into a client and download the entire blockchain...
464 2012-02-22 19:07:25 <jack_> I just want to publish the send transaction... understand?
465 2012-02-22 19:08:07 <jack_> then I can track my accounts both on local clients and hosted clients just using the public keys
466 2012-02-22 19:09:06 <jack_> when I want to send bitcoins, I scan the qr code, decrypt the data, and sign the and send the transaction
467 2012-02-22 19:09:22 <jack_> no need to store the private key on _any_ client, see?
468 2012-02-22 19:09:56 <jack_> this seems to be possible with how the bitcoin protocol works, but does not seem to be supported by any software
469 2012-02-22 19:10:03 <jack_> unless I'm mistaken ??
470 2012-02-22 19:10:49 <luke-jr> jack_: no, you're right
471 2012-02-22 19:10:54 <luke-jr> jack_: would you like to implement this?
472 2012-02-22 19:11:54 <jack_> Greatly :) I'm very new to bitcoin though
473 2012-02-22 19:12:11 <jack_> also see this thread: https://bitcointalk.org/index.php?topic=45523.0
474 2012-02-22 19:13:27 <jack_> the sweepprivkey proposal is kind of getting at what I want... but imo is flawed in that it would only allow the entire balance to be transferred, which doesn't really support my use case
475 2012-02-22 19:13:42 <Graet> and the 3rd post...
476 2012-02-22 19:14:50 <jack_> and see the 6th
477 2012-02-22 19:15:04 <BlueMatt-mobile> jack_ i still see no reason for not having the peivatr keys vs just encrypting the wallet
478 2012-02-22 19:15:12 <gmaxwell> jack_: bitcoin can only spend whole coins, if you spend less you send the change back to yourself.
479 2012-02-22 19:15:57 <jack_> oh yeah... so sweepprivkey could be used for this use case?
480 2012-02-22 19:16:14 <BlueMatt-mobile> (if you really want it printed, print the wallet passphrase and copy it in when you need it)
481 2012-02-22 19:17:14 <BlueMatt-mobile> sweepprivkey imports the key...
482 2012-02-22 19:17:14 <jrmithdobbs> jack_: ya that + importprivkey
483 2012-02-22 19:17:30 <BlueMatt-mobile> (and sweeps when it sees new txea)
484 2012-02-22 19:17:33 <jrmithdobbs> jack_: the glue needed to make it all work is missing though
485 2012-02-22 19:18:02 <BlueMatt-mobile> Or sends coins to your privkeys in your wallet...
486 2012-02-22 19:18:29 <jack_> i'm going to post in a multi line quote from the thread i referenced... sorry in advance!
487 2012-02-22 19:18:32 <BlueMatt-mobile> At which point you have lost the whole purpose
488 2012-02-22 19:18:51 <jack_> "My understanding is that the only time a private key is needed is when a payment is made. To make it easy to sign payments on the client side it would be nice to have the following in bitcoin.
489 2012-02-22 19:18:53 <jack_> 1. getinfoforpayment - retrieve everything from the block chain required for a payment. You specify the destination addresses and the source address.
490 2012-02-22 19:18:55 <jack_> The client application then signs the information.
491 2012-02-22 19:18:59 <jack_> 2. sendrawtransaction - bitcoin pushes the transaction out onto the network."
492 2012-02-22 19:19:03 <luke-jr> I like the suggestion someone posted
493 2012-02-22 19:19:40 <luke-jr> actually, I guess that suggestion wouldn't be viable (to just put the txn on the card)
494 2012-02-22 19:19:41 <BlueMatt-mobile> Yea thats great for offline signing...
495 2012-02-22 19:20:04 <luke-jr> BlueMatt-mobile: sweepprivkey doesn't import AFAIK, just scans for funds once then discards the key
496 2012-02-22 19:20:18 <jrmithdobbs> luke-jr: ya you'd have to know who you were sending it to beforehand, though, that could (and i think has) be used for gift card like things
497 2012-02-22 19:20:24 <BlueMatt-mobile> (Which would be a great feature, but if i grt what you want, wont help...)
498 2012-02-22 19:20:40 <BlueMatt-mobile> luke-jr its up to the implementor.
499 2012-02-22 19:20:41 <luke-jr> jrmithdobbs: more like Bitbills; you can't keep a balance
500 2012-02-22 19:20:51 <jrmithdobbs> luke-jr: ya
501 2012-02-22 19:20:56 <BlueMatt-mobile> jack_ s
502 2012-02-22 19:20:58 <jrmithdobbs> luke-jr: bitbills is what it reminds me
503 2012-02-22 19:20:59 <luke-jr> I favour the smartcard approach&
504 2012-02-22 19:21:15 <ThomasV> jack_: sendrawtransaction == importtransaction ?
505 2012-02-22 19:21:17 <luke-jr> plug it in, see the total, press a button to allow it
506 2012-02-22 19:21:21 <BlueMatt-mobile> jack_ can you elaborate on exactly what you are trying to do...
507 2012-02-22 19:22:32 <jack_> i have explained it a couple times... what don't you understand? (not being harsh just trying to understand what I should explain differently)
508 2012-02-22 19:22:32 <luke-jr> otoh, smartcard *could* be reloaded&
509 2012-02-22 19:23:16 <BlueMatt-mobile> So far ive heard you say "that may work" on a bunch of solutions with very different use cases...
510 2012-02-22 19:23:16 <jrmithdobbs> luke-jr: hell a smartcard could store the entirety of the wallet with a bit of work
511 2012-02-22 19:23:29 <luke-jr> jrmithdobbs: well, that's my point
512 2012-02-22 19:23:52 <luke-jr> jrmithdobbs: you only need to bring it online to refill it
513 2012-02-22 19:24:45 <jrmithdobbs> luke-jr: ya, makes me a bit uncomfortable for a couple reasons though
514 2012-02-22 19:24:45 <ThomasV> luke-jr: https://en.bitcoin.it/wiki/Smart_card_wallet
515 2012-02-22 19:24:49 <luke-jr> and it never has to expose any of its privkeys
516 2012-02-22 19:25:27 <luke-jr> ThomasV: I don't see what a keyboard is needed for. A single key would be enough I think?
517 2012-02-22 19:25:34 <jrmithdobbs> luke-jr: the most relevant of which being that with widespread use it would lead to harder-to-protect-against attacks, eg, skimmers on readers at pos and such
518 2012-02-22 19:25:43 <ThomasV> luke-jr: pincode?
519 2012-02-22 19:26:13 <jrmithdobbs> luke-jr: i like the cc chip/pin cards that have pin entry on the physical card someone was showing off sometime this last year
520 2012-02-22 19:26:44 <luke-jr> ThomasV: I guess that could be a more secure model :p
521 2012-02-22 19:26:50 <luke-jr> I'm assuming possession = possession
522 2012-02-22 19:26:56 <BlueMatt> jack_: the way I understand it, you are running a bitcoin-based merchant/site/whatever and want a more secure way of storing the coins
523 2012-02-22 19:27:05 <BlueMatt> jack_: but you really havnt said what you are running
524 2012-02-22 19:27:08 <ThomasV> http://www.nidsecurity.com/products/details-306.html
525 2012-02-22 19:27:37 <sipa> luke-jr: no very-much-more-complete version of getalltransactions pushe
526 2012-02-22 19:27:38 <sipa> d
527 2012-02-22 19:27:42 <jrmithdobbs> ThomasV: yup those
528 2012-02-22 19:27:54 <BlueMatt> jack_: you have said what you apparently think is the solution - being able to send with just privkey/pubkey pair, and that isnt possible, but you never said what the actual original problem is
529 2012-02-22 19:28:09 <jack_> I have a piece of paper that I printed out that has two QR codes. One is the public key for an account, the second is the private key for the account. Currently, I can have coins sent to the account by giving people the public key. This works even though my account has never been "online" and never been "imported" into a client. I like this a lot because I am in sole complete possession of...
530 2012-02-22 19:28:11 <jack_> ...my account. I can also use a wallet like strongcoin to track the balance on the public key, without ever sending them my private key. What I lack is the ability to send coins from the said account without importing the private key into a client.
531 2012-02-22 19:28:50 <BlueMatt> jack_: and why does an encrypted wallet not solve your problem?
532 2012-02-22 19:28:50 <jrmithdobbs> BlueMatt: he's asking for sign/import raw txn basically
533 2012-02-22 19:29:03 <jack_> In my understanding of the bitcoin protcol, this is possible - but not supported by any existing software.
534 2012-02-22 19:29:03 <jrmithdobbs> well, sign/import/broadcast
535 2012-02-22 19:29:12 <BlueMatt> jrmithdobbs: yea, but at some point he has to have the privkey in a computer, at which point he may as well have it in an encrypted wallet...
536 2012-02-22 19:29:28 <BlueMatt> unless he wants offline signing
537 2012-02-22 19:29:28 <jack_> see post #6 of the following link: https://bitcointalk.org/index.php?topic=45523.0
538 2012-02-22 19:29:37 <BlueMatt> (which he hasnt said, hence why Im asking for clarification)
539 2012-02-22 19:29:38 <jrmithdobbs> BlueMatt: he wants offline signing
540 2012-02-22 19:29:41 <jrmithdobbs> BlueMatt: and doesn't know it
541 2012-02-22 19:29:48 <jrmithdobbs> basically, from what I can tell
542 2012-02-22 19:29:58 <jack_> let me google offline signing...
543 2012-02-22 19:30:18 <BlueMatt> offline signing would mean you can make the tx on a computer that has never been /is not connected to the internet
544 2012-02-22 19:30:34 <jrmithdobbs> jack_: offline signing being: tell bitcoind to create a txn and export it, have either bitcoind or someother piece of software use the privkey to sign, then import back into bitcoin/bitcoind and broadcast the txn
545 2012-02-22 19:30:36 <BlueMatt> and then copy the signed transaction to another bitcoin client on a computer that is on the internet
546 2012-02-22 19:30:41 <ThomasV> jack_: Electrum can do it
547 2012-02-22 19:30:42 <jrmithdobbs> jack_: that's what you're after, yes?
548 2012-02-22 19:30:43 <BlueMatt> ie never have your privkey on a internet-connected machine
549 2012-02-22 19:31:03 <jack_> close, but not exactly ;)
550 2012-02-22 19:31:20 <jrmithdobbs> well, that functionality would give you all the tools to accomplish what you want, though, yes?
551 2012-02-22 19:31:50 <luke-jr> sipa: no "hash" key on txns?
552 2012-02-22 19:31:51 <BlueMatt> jrmithdobbs: and you wonder why I asked for clarification..."basically, from what I can tell" so you are ass-u-ming
553 2012-02-22 19:31:51 <jack_> I don't care if the transaction is signed on an internet connected machine.. I just don't want to import/store the key and download the blockchain.
554 2012-02-22 19:31:59 <jack_> jrsmithdobbs yes it would
555 2012-02-22 19:32:12 <BlueMatt> jack_: why cant it download the blockchain?
556 2012-02-22 19:32:18 <sipa> luke-jr: "txid"
557 2012-02-22 19:32:23 <jrmithdobbs> BlueMatt: not assuming, just verifying i understood him, looks like i did
558 2012-02-22 19:32:27 <sipa> luke-jr: as gettransaction already had that
559 2012-02-22 19:32:44 <jack_> BlueMatt: because that would involve storing the private key on the machine
560 2012-02-22 19:32:49 <BlueMatt> jrmithdobbs: uh, no..."I don't care if the transaction is signed on an internet connected machine" <-- ie he doesnt care if its offline signed or not...
561 2012-02-22 19:32:52 <jrmithdobbs> jack_: no it wouldn't
562 2012-02-22 19:33:06 <BlueMatt> jack_: you can download the chain on a fresh wallet that doesnt know anything about your privkeys
563 2012-02-22 19:33:16 <BlueMatt> jack_: you can download the chain on a machine that only has your pubkeys
564 2012-02-22 19:33:26 <BlueMatt> (or that doesnt even have that)
565 2012-02-22 19:33:29 <jrmithdobbs> BlueMatt: is the latter actually fixed now?
566 2012-02-22 19:33:35 <jack_> ah ok.. let me further my use case - one sec
567 2012-02-22 19:33:59 <jrmithdobbs> BlueMatt: last i tried it got very nonplussed about not having the privkeys for pubkeys it had associated
568 2012-02-22 19:34:08 <BlueMatt> jrmithdobbs: well, ok you would have to do some hacking to do the latter - make an encrypted wallet with the pubkeys in it, but replace the privkeys with garbage
569 2012-02-22 19:34:17 <BlueMatt> and just dont try to decrypt (as it will fail)
570 2012-02-22 19:34:41 <luke-jr> sipa: TxToJSON doesn't have "txid"& o.o
571 2012-02-22 19:34:54 <luke-jr> sipa: are the scripts disassembled?
572 2012-02-22 19:35:02 <jrmithdobbs> BlueMatt: thats probably something worth thinking about fixing, i've seen it brought up a few times
573 2012-02-22 19:35:28 <jrmithdobbs> but it's not a quick fix
574 2012-02-22 19:35:32 <BlueMatt> jrmithdobbs: meh, it comes with type-2 det keys...
575 2012-02-22 19:35:38 <BlueMatt> (which sipa has implemented)
576 2012-02-22 19:35:43 <jack_> So given a piece of paper with my keys encoded as qr codes, I want to be able to open a bitcoin app on my android phone, scan the private key, and publish a transaction - then the android app instantly forgets my private key.
577 2012-02-22 19:35:49 <sipa> luke-jr: gettransaction does; there is no overlap between TxToJSON and WalletTxToJSON, as they are called both called
578 2012-02-22 19:36:00 <sipa> luke-jr: scripts are disassembled yes; coinbases aren't
579 2012-02-22 19:36:39 <BlueMatt> jack_: and, again, why does an encrypted wallet not work?
580 2012-02-22 19:36:51 <luke-jr> sipa: perhaps 2 keys, one w/ disasm, and one w/ hex?
581 2012-02-22 19:36:57 <BlueMatt> (it gets you the same result - the information required to spend your coins is available only briefly while you are sending)
582 2012-02-22 19:37:10 <BlueMatt> aside from the printable part, its the same thing
583 2012-02-22 19:37:14 <jack_> because I don't want my key stored on other devices
584 2012-02-22 19:37:17 <BlueMatt> and if you want to print, you could do the glue yourself
585 2012-02-22 19:37:27 <jack_> i just want my key stored in one place
586 2012-02-22 19:37:31 <BlueMatt> jack_: its encrypted, so its not accessible without the passphrase
587 2012-02-22 19:37:38 <sipa> luke-jr: i'd argue for a separate dumptransaction call that gives a hexdump of a tx, with an accompanying(?) loadtransaction
588 2012-02-22 19:37:52 <BlueMatt> jack_: the unencrypted privkey never has to leave your computer (though it should for backup)
589 2012-02-22 19:38:03 <jack_> unless the device is compromised either previously, or in the future
590 2012-02-22 19:38:07 <BlueMatt> jack_: and you can make the passphrase only in one place, which has the same result
591 2012-02-22 19:38:23 <BlueMatt> jack_: if your phone is compromised when you spend the coins you are fucked anyway
592 2012-02-22 19:38:51 <jack_> it is the same as the StrongCoin usecase...
593 2012-02-22 19:38:57 <BlueMatt> no matter how you do it, if your device is compromised at the time you spend the coins you are fucked
594 2012-02-22 19:39:00 <jack_> did you read the post I referenced?
595 2012-02-22 19:39:44 <jack_> https://bitcointalk.org/index.php?topic=45523.msg545080#msg545080
596 2012-02-22 19:40:03 <BlueMatt> yes, but again, there is no functional difference (even if there is difference) between printed privkey and encrypted wallet
597 2012-02-22 19:40:12 <jrmithdobbs> BlueMatt: actually if it's compromised on spend he's fine
598 2012-02-22 19:40:25 <jrmithdobbs> BlueMatt: so long as the change addresses it's sending to weren't loaded
599 2012-02-22 19:40:32 <BlueMatt> jrmithdobbs: when you spend, you have to have the privkey unencrypted in memory, so you are fucked...period.
600 2012-02-22 19:40:51 <jrmithdobbs> BlueMatt: except that those coins will go to a new privkey not in memory immediately on spend
601 2012-02-22 19:40:55 <BlueMatt> jrmithdobbs: so the attacker just blocks your bitcoin client from sending your new tx, makes their own tx to them, and sends that instead
602 2012-02-22 19:41:08 <luke-jr> sipa: that doesn't help if someone is accessing via getblock
603 2012-02-22 19:41:12 <BlueMatt> jrmithdobbs: if the attacker controls your computer to begin with, there is absolutely nothing you can do
604 2012-02-22 19:41:15 <jrmithdobbs> BlueMatt: it'd require someone performing a successful double spend at the time you send your transaction
605 2012-02-22 19:41:30 <BlueMatt> jrmithdobbs: the double spend is only hard if the real tx goes out first
606 2012-02-22 19:41:43 <sipa> luke-jr: solution: not make getblock include all transactions
607 2012-02-22 19:41:44 <BlueMatt> jrmithdobbs: but since this attacker controls your computer, its trivial to make sure his goes out first
608 2012-02-22 19:41:51 <jrmithdobbs> BlueMatt: yes through blocking your traffic or similar, it really does not sound like an attack worth modeling, even
609 2012-02-22 19:41:52 <luke-jr> sipa: that doesn't solve it
610 2012-02-22 19:42:00 <luke-jr> sipa: it just makes getblock mostly worthless
611 2012-02-22 19:42:01 <BlueMatt> jrmithdobbs: or, alternatively, just change the tx that you are creating to spend to him instead of to your real dest
612 2012-02-22 19:42:04 <jrmithdobbs> BlueMatt: except for extremely high value targets
613 2012-02-22 19:42:17 <sipa> luke-jr: i have no problem doing an extra RPC lookup
614 2012-02-22 19:42:26 <luke-jr> sipa: you don't seem to do RPC much?
615 2012-02-22 19:42:32 <sipa> haha :)
616 2012-02-22 19:42:38 <BlueMatt> jrmithdobbs: look through bitcoin's memory, s/txouts/txout to attacker/
617 2012-02-22 19:42:40 <BlueMatt> jrmithdobbs: easy peasy
618 2012-02-22 19:43:26 <luke-jr> sipa: new param for get*: {"transaction":"hex"/"full", "script":"hex"/"asm"}
619 2012-02-22 19:43:31 <luke-jr> ?
620 2012-02-22 19:43:43 <jack_> what is involved in importing a private key?
621 2012-02-22 19:44:02 <BlueMatt> import, rescan chain to find that key's txes
622 2012-02-22 19:44:21 <BlueMatt> add those txes to wallet
623 2012-02-22 19:44:33 <BlueMatt> anyone have any ruby experience?
624 2012-02-22 19:44:33 <jrmithdobbs> BlueMatt: yes but you went from someone finding your keys when looking through their dumps a few days later to someone actively mitm'ing you from your own hardware, for most users what he's wanting is enough of an improvement to stop passive collection of privkeys
625 2012-02-22 19:45:07 <jrmithdobbs> for high value targets like large merchants it'd be worth considering your point though, definitely
626 2012-02-22 19:45:15 <luke-jr> sipa: hmm, the old dumpblock uses ToString too, but gave hex :/
627 2012-02-22 19:45:24 <sipa> gave hex?
628 2012-02-22 19:45:47 <jack_> wouldn't scanning the blockchain take a considerable amount of time?
629 2012-02-22 19:46:03 <luke-jr> sipa: yes
630 2012-02-22 19:46:06 <BlueMatt> jack_: its not that much time, but its a few seconds
631 2012-02-22 19:46:07 <luke-jr> "scriptPubKey" : "0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee OP_CHECKSIG"
632 2012-02-22 19:46:09 <luke-jr> oh
633 2012-02-22 19:46:11 <luke-jr> I guess that'
634 2012-02-22 19:46:15 <luke-jr> 's disasm with data
635 2012-02-22 19:46:38 <sipa> yes, pushes are disassembled as literals
636 2012-02-22 19:47:20 <jack_> hmm so my use case and the one detailed in https://bitcointalk.org/index.php?topic=45523.msg545080#msg545080 could be solved by having the client just import the key, scan the blockchain, publish the transaction, and then delete the key?
637 2012-02-22 19:47:27 <ThomasV> jack_: not if you use libbitcoin or Electrum
638 2012-02-22 19:47:34 <BlueMatt> jrmithdobbs: ok, so if you arent concerned with active attacks and only care about key-stealing, how does printed key help? ok, you could import privkey, make a new key offline and print it, spend what you want, send everything else to the new key...but thats a _huge_ pita for each time you want to send coins...
639 2012-02-22 19:47:48 <BlueMatt> jack_: no, because then the attacker has the privkey and can still steal your coins
640 2012-02-22 19:48:00 <BlueMatt> you have to make a new key each time you spend for your case...
641 2012-02-22 19:48:28 <jrmithdobbs> BlueMatt: it is a huge pita, agreed there
642 2012-02-22 19:48:31 <BlueMatt> (and make sure no one ever uses your old key again, which can be very difficult depending on how you use your keys...)
643 2012-02-22 19:48:47 <jrmithdobbs> BlueMatt: but it's really only a pita right now because noone's automated it
644 2012-02-22 19:49:00 <BlueMatt> it would still be a pita in many ways
645 2012-02-22 19:49:05 <jack_> no - I want to keep the same keys :P
646 2012-02-22 19:49:07 <BlueMatt> ie you could never publish a donation address
647 2012-02-22 19:49:12 <jrmithdobbs> jack_: you shouldn't
648 2012-02-22 19:49:15 <jrmithdobbs> jack_: that is bad
649 2012-02-22 19:49:20 <sipa> luke-jr: how would gettransaction + transaction=hex interact with wallet transactions?
650 2012-02-22 19:49:25 <jrmithdobbs> jack_: and antithetical to bitcoin's design
651 2012-02-22 19:49:55 <BlueMatt> anyone have any clues why a ruby call to system!(...) would never return even if the command is clearly returning?
652 2012-02-22 19:49:57 <sipa> jrmithdobbs: you really want a determinstic wallet instead of a static private key
653 2012-02-22 19:50:01 <sipa> eh, jack_
654 2012-02-22 19:50:11 <jrmithdobbs> sipa: ya, i think that's what he really wants
655 2012-02-22 19:50:35 <luke-jr> sipa: I'm not thinking that would be applicable to gettxn
656 2012-02-22 19:50:46 <jrmithdobbs> i could see a use for something like what he's suggesting though
657 2012-02-22 19:51:01 <edcba> ;;bc,mtgox
658 2012-02-22 19:51:02 <gribble> {"ticker":{"high":4.54,"low":4.27,"avg":4.428592945,"vwap":4.433554307,"vol":83738,"last_all":4.52671,"last_local":4.52671,"last":4.52671,"buy":4.51,"sell":4.52671}}
659 2012-02-22 19:51:09 <jrmithdobbs> BlueMatt: what's the command?
660 2012-02-22 19:51:14 <BlueMatt> jrmithdobbs: gitian build
661 2012-02-22 19:51:15 <jack_> oh deterministic wallets don't keep the same keys?
662 2012-02-22 19:51:27 <jrmithdobbs> BlueMatt: children of the process group not exited yet maybe?
663 2012-02-22 19:51:31 <jrmithdobbs> jack_: no
664 2012-02-22 19:51:43 <sipa> jack_: they are equivalent to an infinite list of keys, but generated using a single "formula" that is secret
665 2012-02-22 19:51:53 <BlueMatt> jrmithdobbs: in this case "on-target bash < var/build-script > var/build.log" with on-target being a command to ssh into a local vm and execute the command
666 2012-02-22 19:51:54 <sipa> and the formula cannot be guessed by observing the used keys
667 2012-02-22 19:52:10 <BlueMatt> jrmithdobbs: and i deliberately put the last command in the bash script var/build-script to be exit 0
668 2012-02-22 19:52:16 <jack_> ahhh
669 2012-02-22 19:52:27 <BlueMatt> jrmithdobbs: (and it exits fine when called from a regular bash shell)
670 2012-02-22 19:52:27 <jrmithdobbs> BlueMatt: try it again with set -x; and see what happens
671 2012-02-22 19:52:38 <vegard> why are there a lot of transactions with very small pubkeys, like "1b01"?
672 2012-02-22 19:52:53 <sipa> vegard: that is not a pubkey
673 2012-02-22 19:53:11 <jack_> so how would once check the balance of a deterministic wallet?
674 2012-02-22 19:53:24 <sipa> jack_: by using a client that supports them
675 2012-02-22 19:53:30 <sipa> and scanning through the block chain
676 2012-02-22 19:53:35 <sipa> (e.g. Armory)
677 2012-02-22 19:54:19 <BlueMatt> jrmithdobbs: no, the only children it ever creates is /bin/sh...on-target and ssh -o...
678 2012-02-22 19:54:29 <sipa> luke-jr: so, what output would you expect when gettransaction transaction=hex is applied to a wallet transaction?
679 2012-02-22 19:54:30 <BlueMatt> (and both of those exit no problem)
680 2012-02-22 19:54:45 <luke-jr> sipa: I'm not thinking that would be applicable to gettxn
681 2012-02-22 19:54:45 <sipa> luke-jr: the same as if it were a non-wallet transaction?
682 2012-02-22 19:54:53 <sipa> Ah, ok.
683 2012-02-22 19:55:06 <jrmithdobbs> BlueMatt: what's strace say it's doing?
684 2012-02-22 19:55:31 <jack_> I just really like the idea of managing my wallet(s) completely offline, and only connecting to the network when absolutely necessary
685 2012-02-22 19:56:26 <helo> the client really needs import/export transaction via file
686 2012-02-22 19:56:49 <helo> i suppose "send to file" and "send from file"
687 2012-02-22 19:56:52 <jrmithdobbs> sipa: with the type2 wallet impl you did can you determine the pubkey series independently from the privkeys?
688 2012-02-22 19:57:00 <sipa> jrmithdobbs: that's the point
689 2012-02-22 19:57:11 <jrmithdobbs> sipa: i couldn't remember if that was type2 or not ;p
690 2012-02-22 19:57:23 <sipa> that's not implemented by the way, but it could be done
691 2012-02-22 19:57:25 <sipa> Armory has it
692 2012-02-22 19:57:27 <jrmithdobbs> ah
693 2012-02-22 19:57:45 <helo> how is such a beast implemented?
694 2012-02-22 19:58:04 <ThomasV> sipa: Electrum had it before
695 2012-02-22 19:58:18 <sipa> https://github.com/sipa/bitcoin/commit/b2a186f35d7c17bdc4a4b11edceb3ef137b25dd0
696 2012-02-22 19:58:38 <sipa> ThomasV: Really? Didn't know that.
697 2012-02-22 19:59:32 <sipa> ThomasV: You may be interested in a draft for a BIP about somewhat more complex deterministic wallets I'm working on: https://gist.github.com/1799467
698 2012-02-22 19:59:34 <BlueMatt> jrmithdobbs: strace shows nothing interesting...
699 2012-02-22 20:00:11 <jrmithdobbs> BlueMatt: what's it showing? is it sitting in a loop polling or did the waitpid() never return or something?
700 2012-02-22 20:00:27 <BlueMatt> jrmithdobbs: it returns normally like you would expect bash to return
701 2012-02-22 20:00:43 <BlueMatt> rt_sigreturn(0)
702 2012-02-22 20:00:48 <BlueMatt> exit_group(1)
703 2012-02-22 20:01:01 <jrmithdobbs> right but the pid that launched that
704 2012-02-22 20:01:10 <jrmithdobbs> you strace -f -F'ed right?
705 2012-02-22 20:02:11 <BlueMatt> no, but now that I do, I see no pids except the one pid that bash launced...
706 2012-02-22 20:02:36 <BlueMatt> the 2 pids - bash + ssh
707 2012-02-22 20:02:44 <BlueMatt> ssh returns, and detaches
708 2012-02-22 20:02:46 <BlueMatt> bash exits
709 2012-02-22 20:02:46 <ThomasV> sipa: "Alan Reiner for the
710 2012-02-22 20:04:07 <sipa> ThomasV: I'll credit them too then, but as I didn't know about them, they didn't really influence the idea :)
711 2012-02-22 20:04:19 <vegard> sipa: you are right, thanks.
712 2012-02-22 20:04:42 <ThomasV> sipa: so the idea is that you derive a node from its parent
713 2012-02-22 20:05:04 <sipa> ThomasV: indeed
714 2012-02-22 20:05:11 <sipa> and use that to implement accounts
715 2012-02-22 20:05:24 <ThomasV> sipa: but then you cannot have random access, can you?
716 2012-02-22 20:05:29 <sipa> sure you do
717 2012-02-22 20:05:44 <ThomasV> without replaying the sequence, I mean
718 2012-02-22 20:05:45 <sipa> you can immediately generate the Nth subnode of a given parent
719 2012-02-22 20:06:10 <sipa> the actual keys are all at depth 3 in the tree
720 2012-02-22 20:11:13 <ThomasV> sipa: http://ecdsa.org/2dwallet  (another random idea for deterministic wallets)
721 2012-02-22 20:11:45 <ThomasV> quite simple, actually
722 2012-02-22 20:13:54 <sipa> ThomasV: I'm kinda opposed to using the block chain for storing user information, actually
723 2012-02-22 20:14:46 <sipa> Now, if you could integrate that with normal operation, as in, using the address in the secondary chain for example for change that would need to go to some address anyway, ...
724 2012-02-22 20:16:08 <sipa> ThomasV: reading further on that site, you may wish to know that bitcoin addresses can be derived from a 'signmessage' signature
725 2012-02-22 20:16:17 <sipa> though the API does not expose this
726 2012-02-22 20:16:20 <ThomasV> sipa: I know
727 2012-02-22 20:16:45 <ThomasV> I implemented verifymessage
728 2012-02-22 20:17:14 <sipa> Oh, indeed, I remember.
729 2012-02-22 20:18:03 <ThomasV> I understand you don't like using tx to store information, but I see no other alternatives
730 2012-02-22 20:18:21 <sipa> I doubt it's a problem in reality.
731 2012-02-22 20:18:22 <ThomasV> unless the ban on nonstandard tx is lifted
732 2012-02-22 20:19:23 <sipa> How would that help>
733 2012-02-22 20:19:24 <sipa> ?
734 2012-02-22 20:19:37 <helo> is there an explanation of type2 addresses (how pubkeys are generated without privkeys) online?
735 2012-02-22 20:19:58 <sipa> helo: https://bitcointalk.org/index.php?topic=19137.0
736 2012-02-22 20:20:05 <sipa> that's the original post that introduced them
737 2012-02-22 20:20:08 <helo> thanks
738 2012-02-22 20:20:20 <sipa> the actually implemented algorithms are somewhat different, but the idea is the same
739 2012-02-22 20:20:40 <sipa> helo: oh sorry, that's type-2 determinstic wallets
740 2012-02-22 20:20:47 <ThomasV> sipa: with nonstandard tx you can actually store data
741 2012-02-22 20:21:02 <sipa> ThomasV: that's a very good reason for not lifting the ban, then
742 2012-02-22 20:21:12 <ThomasV> heh
743 2012-02-22 20:21:27 <ThomasV> my point is that you cannot avoid it
744 2012-02-22 20:21:42 <sipa> probably not; but i certainly don't want to encourage it
745 2012-02-22 20:21:57 <RedEmerald> put it in another alt-chain :p
746 2012-02-22 20:22:22 <ThomasV> RedEmerald: namecoin
747 2012-02-22 20:23:11 <RedEmerald> that would work. i'm not sure if it actually makes the wallet recovery process simpler tho. and isn't that the point?
748 2012-02-22 20:23:20 <ThomasV> RedEmerald: I am working on such a project; storing bitcoin aliases in the namecoin blockchain
749 2012-02-22 20:23:38 <ThomasV> but for wallet recovery, no, it does not make sense
750 2012-02-22 20:23:57 <sipa> I'm not sure the gap problem is really a problem.
751 2012-02-22 20:24:12 <ThomasV> sipa: why not?
752 2012-02-22 20:24:22 <sipa> Use a reasonable default, and when recovering, if the user notices that things are missing, try a longer gap.
753 2012-02-22 20:24:41 <ThomasV> that assumes the user can notice
754 2012-02-22 20:25:03 <ThomasV> how about the user inherits a wallet from someone else?
755 2012-02-22 20:26:10 <sipa> In fact, the client could warn the user in advance, when he's creating the Nth address in a row that has not yet received any transactions.
756 2012-02-22 20:26:43 <ThomasV> the first version used to do that
757 2012-02-22 20:27:00 <ThomasV> but it's too complicated for nongeeks
758 2012-02-22 20:27:49 <gmaxwell> I think you may be over thinking this recovering in this way is an emergency operation you should still use a normal backup to handle metadata
759 2012-02-22 20:28:08 <ThomasV> oh no..
760 2012-02-22 20:28:23 <ThomasV> I have no backup except in my brain
761 2012-02-22 20:28:50 <gmaxwell> Well. That sounds like a bad policy it limits functionality you don't have the abillity to store comments on txn?
762 2012-02-22 20:29:11 <gmaxwell> I think its OKAY if a omg-emergecy recovery loses (temporarily) some future funds under weird spending patterns which can still be recovered if the user notices and cares.
763 2012-02-22 20:29:28 <sipa> luke-jr: I wonder if there's any useful thing to report based on CBlockIndex's bnChainWork
764 2012-02-22 20:29:35 <ThomasV> gmaxwell: I do this only for my savings wallet
765 2012-02-22 20:29:48 <ThomasV> not for the one I use everyday
766 2012-02-22 20:29:54 <luke-jr> sipa: what's that?
767 2012-02-22 20:30:13 <sipa> luke-jr: running sum of estimated number of hashes performed in the chain up to that block
768 2012-02-22 20:30:29 <luke-jr> hmm
769 2012-02-22 20:30:52 <sipa> It's one of the coolest statistics imho; "The current bitcoin blockchain has over 2*10^20 hashes in it!"
770 2012-02-22 20:31:05 <luke-jr> sounds like asking for Number problems
771 2012-02-22 20:32:00 <jrmithdobbs> ThomasV: do those nidsecurity guys actually sell like single units of those otp things?
772 2012-02-22 20:32:27 <ThomasV> jrmithdobbs: I think they sell development kits
773 2012-02-22 20:37:36 <ThomasV> gmaxwell: actually, there's a user who only accesses his wallet through the recovery procedure and BitSafe. nothing gets ever written to disk
774 2012-02-22 20:37:50 <sipa> fun fact: the bitcoin network surpassed 2^64 hashes around block 131188
775 2012-02-22 20:38:37 <jrmithdobbs> ThomasV: bleh, the rfid is mifare
776 2012-02-22 20:39:02 <ThomasV> jrmithdobbs: link?
777 2012-02-22 20:39:10 <sipa> Currently it's at 2^67.72
778 2012-02-22 20:39:22 <jrmithdobbs> ThomasV: it's on the link you gave me earlier near the bottom
779 2012-02-22 20:39:36 <jrmithdobbs> ThomasV: or in the faq near the bottom
780 2012-02-22 20:40:02 <ThomasV> i see
781 2012-02-22 20:40:07 <jrmithdobbs> oh, they do emv too, ok
782 2012-02-22 20:40:27 <sipa> That's enough to have tried all alphanumeric passwords of length up to 11
783 2012-02-22 20:42:58 <sipa> luke-jr: why would it ask for number problems?
784 2012-02-22 20:43:28 <jrmithdobbs> ThomasV: seriously can't find anywhere to find small batch pricing
785 2012-02-22 20:43:35 <jrmithdobbs> ThomasV: hate when vendors make me call people
786 2012-02-22 20:43:56 <ThomasV> heh
787 2012-02-22 20:51:55 <gavinandresen> Apropos of nothing:  I hope the DIANNA "namecoin done right" project works out:  https://bitcointalk.org/index.php?topic=64279.0
788 2012-02-22 20:52:46 <ThomasV> is it really better than namecoin?
789 2012-02-22 20:53:16 <jrmithdobbs> there details posted on a webpage that actually works?