1 2012-03-09 00:01:24 <rebroad> goodnight all
  2 2012-03-09 00:01:38 <BlueMatt> gnight
  3 2012-03-09 00:06:15 <da2ce7> helllo
  4 2012-03-09 00:07:58 <sipa> hi da2ce7
  5 2012-03-09 00:09:18 <da2ce7> what
  6 2012-03-09 00:09:23 <da2ce7> what's been happening?
  7 2012-03-09 00:10:18 <sipa> a fake BIP16 transaction that killed off rc1 nodes with an earlier switchover date
  8 2012-03-09 00:10:32 <sipa> the top 5 pools support BIP30
  9 2012-03-09 00:11:02 <da2ce7> good well we can moveup BIP30 to tomorow then?
 10 2012-03-09 00:11:05 <da2ce7> or real soon?
 11 2012-03-09 00:11:23 <sipa> support as in promised to update
 12 2012-03-09 00:11:40 <da2ce7> ah. ok
 13 2012-03-09 00:11:44 <da2ce7> no patches yet.
 14 2012-03-09 00:11:50 <sipa> none that i know of
 15 2012-03-09 00:12:06 <sipa> well, there are patches, but not applied where needed :)
 16 2012-03-09 00:12:44 <da2ce7> why don't you have eveyone make a patch, then you turn the patch on with an alert? eg. "Turn on patch BIP30 at blocx xyz"
 17 2012-03-09 00:13:03 <da2ce7> and all the patch puts a 'ready for BIP30 in the coinbase"
 18 2012-03-09 00:13:08 <sipa> because that would make the patch significantly larger and harder to get accepted
 19 2012-03-09 00:13:21 <sipa> the only reason it can be deployed this quickly is because it is so simple
 20 2012-03-09 00:13:28 <da2ce7> ya
 21 2012-03-09 00:14:30 <da2ce7> I was thinking about it... using an alert to turn on a patch, that pre-reports in the coin-base, sounds like a pritty fool-proof way of doing network upgrades.
 22 2012-03-09 00:20:03 <luke-jr> da2ce7: just as well to autodetect it from coinbases :p
 23 2012-03-09 00:21:54 <doublec> copumpkin: isn't that deepbit's payment address?
 24 2012-03-09 00:22:09 <copumpkin> doublec: 6.5 million coins?
 25 2012-03-09 00:22:11 <copumpkin> :S
 26 2012-03-09 00:22:46 <sipa> ?
 27 2012-03-09 00:22:56 <sipa> deepbit's address is 1VayNert
 28 2012-03-09 00:23:00 <sipa> or something like that
 29 2012-03-09 00:23:19 <doublec> copumpkin: right, that's the one copumpkin linked too
 30 2012-03-09 00:23:31 <copumpkin> wow, that's scary then :P
 31 2012-03-09 00:25:09 <gmaxwell> copumpkin: he refuses to use sendmany and is constantly making tiny payments to users, so lots of change is sent back to that address.
 32 2012-03-09 00:25:15 <copumpkin> oh, I see
 33 2012-03-09 00:25:32 <gmaxwell> when I looked a few weeks ago he was responsible for 27% of the recent transactions in the blockchain.
 34 2012-03-09 00:25:35 <BlueMatt> the amount of txes that address has seen is scary
 35 2012-03-09 00:29:26 <da2ce7> luke-jr: no, the human interaction / cross-checking is very important.
 36 2012-03-09 00:31:27 <usergfgt> will bitcoin address be replaced by email for example?
 37 2012-03-09 00:31:57 <sipa> maybe
 38 2012-03-09 00:32:07 <sipa> or urls
 39 2012-03-09 00:33:02 <usergfgt> i think its necessary, because i can delete an address and people still send me btcs
 40 2012-03-09 00:33:20 <usergfgt> so i loose it
 41 2012-03-09 00:33:33 <BlueMatt> huh?
 42 2012-03-09 00:33:35 <usergfgt> ok
 43 2012-03-09 00:33:40 <sipa> yes, i just realized it is very wrong to call it address
 44 2012-03-09 00:33:45 <BlueMatt> you shouldnt be able to delete an address
 45 2012-03-09 00:34:02 <sipa> https://bitcointalk.org/index.php?topic=67431.msg791504#msg791504
 46 2012-03-09 00:34:20 <usergfgt> wil read
 47 2012-03-09 00:43:31 <luke-jr> [20:43:19] <ljrbot> Txn 9027b054caa47738de3c0c465c7fc21fcda99fa859baae5540ed4af189f1b2bd: MtGox 695.63770792 BTC
 48 2012-03-09 00:43:32 <luke-jr> O.o
 49 2012-03-09 00:43:56 <candlepin> your mullet has caught fire
 50 2012-03-09 00:58:06 <da2ce7> lol
 51 2012-03-09 01:04:44 <da2ce7> so about that bad BIP16 tx, has that delaed anything? or what are we waiting on?
 52 2012-03-09 01:05:46 <da2ce7> I guess we just make all BIP16 tx's older than the changerover date, invalid anyway.
 53 2012-03-09 01:06:05 <sipa> definitely not
 54 2012-03-09 01:06:11 <sipa> that would imply a block chain split
 55 2012-03-09 01:06:31 <sipa> the BIP16 rule is only defined after the changeover date
 56 2012-03-09 01:07:29 <da2ce7> so any BIP16 tx included in a block before the changeover date cannot be acted upon anyway.
 57 2012-03-09 01:07:58 <[Tycho]> Hello, bitcoin devs ! :)
 58 2012-03-09 01:08:28 <da2ce7> hello [Tycho]
 59 2012-03-09 01:09:06 <[Tycho]> da2ce7: I don't think so, but there should be some in testnet.
 60 2012-03-09 01:09:34 <[Tycho]> Oh, sorry, misread your phrase.
 61 2012-03-09 01:10:07 <forsetifox> Never seen Tycho here. Heh.
 62 2012-03-09 01:10:22 <[Tycho]> *implementing
 63 2012-03-09 01:10:41 <[Tycho]> forsetifox: hello. Who are you ?
 64 2012-03-09 01:10:46 <forsetifox> Hiya. Good.
 65 2012-03-09 01:11:09 <forsetifox> Is that who are you or how are you?
 66 2012-03-09 01:11:16 <[Tycho]> "who".
 67 2012-03-09 01:11:24 <forsetifox> Nobody. I use your pool though.
 68 2012-03-09 01:11:30 <[Tycho]> Cool. Thanks.
 69 2012-03-09 01:11:36 <forsetifox> Thank you. =3
 70 2012-03-09 01:12:06 <[Tycho]> Have you noticed our news ?
 71 2012-03-09 01:12:07 <forsetifox> I've tried several pools and yours is the only one that gives me predicted profits from my meager hashrate.
 72 2012-03-09 01:12:18 <forsetifox> I visited it this morning.
 73 2012-03-09 01:13:52 <forsetifox> That's alot of BTC. ;)
 74 2012-03-09 01:13:55 <[Tycho]> I'm rarely adding any new news, but today I did it.
 75 2012-03-09 01:16:38 <sipa> [Tycho]: how's BIP30 coming up?
 76 2012-03-09 01:18:27 <sipa> da2ce7: indeed, it would just be a weird pay-to-hash transaction
 77 2012-03-09 01:18:40 <[Tycho]> sipa: today I finished cleaning my bitcoind and started thinking about BIP16.
 78 2012-03-09 01:19:06 <[Tycho]> sipa: can you give me a link to github that produces the diff patch ?
 79 2012-03-09 01:19:44 <sipa> https://github.com/sipa/bitcoin/commit/80f2501c890c226869c4df0a4b7543a656ba7a60.diff
 80 2012-03-09 01:19:48 <luke-jr> forsetifox: you must not have tried Eligius :P
 81 2012-03-09 01:19:58 <da2ce7> lawl
 82 2012-03-09 01:20:06 <sipa> [Tycho]: from what I understand, that should apply cleanly to your code
 83 2012-03-09 01:20:12 <[Tycho]> sipa: 3.19 ?
 84 2012-03-09 01:21:00 <[Tycho]> Looks small enough to fix manually anyway.
 85 2012-03-09 01:21:02 <sipa> the code is very similar for all 0.3.x and 0.4.x releases
 86 2012-03-09 01:21:04 <[Tycho]> Unlike BIP16.
 87 2012-03-09 01:21:16 <forsetifox> luke-jr: Your pool was the first one I tried. =P
 88 2012-03-09 01:21:28 <sipa> [Tycho]: yes, this solution was specifically chosen because it is so easy to implement
 89 2012-03-09 01:21:53 <luke-jr> forsetifox: well, can't get any more predictable than that&
 90 2012-03-09 01:22:03 <[Tycho]> sipa: I think I'll make it in time.
 91 2012-03-09 01:23:19 <sipa> [Tycho]: if possible, I'd really like it if it were implemented some days in advance
 92 2012-03-09 01:23:37 <sipa> so that we can announce that there is effectively a majority that implements it
 93 2012-03-09 01:24:22 <[Tycho]> sipa: yes, I'm planning to deploy updates a couple of days before 15th so Gavin will see my BIP16 blocks at the Decision Day.
 94 2012-03-09 01:24:35 <sipa> Ok, thanks.
 95 2012-03-09 01:25:27 <sipa> [Tycho]: this link is easier to remember, by the way: https://github.com/sipa/bitcoin/tree/nooverwritetx_v0.3.19
 96 2012-03-09 01:25:44 <[Tycho]> This link doesn't gives me the diff :)
 97 2012-03-09 01:26:01 <sipa> click on the commit and add .diff to the url
 98 2012-03-09 01:26:06 <[Tycho]> Actually I'm not remembering most links, I'm copying and saving them.
 99 2012-03-09 01:26:20 <sipa> maybe "transparent" was the better word
100 2012-03-09 01:26:25 <sipa> instead of "easier"
101 2012-03-09 01:27:18 <[Tycho]> Sadly there is still no any progress on liberation of bitcoin scripts :(
102 2012-03-09 01:28:00 <luke-jr> [Tycho]: so you're giving in to BIP 16?
103 2012-03-09 01:28:09 <sipa> sure there is, a few more standard transaction types are added
104 2012-03-09 01:28:14 <sipa> that's a first step
105 2012-03-09 01:28:24 <[Tycho]> sipa: which ones ?
106 2012-03-09 01:28:46 <sipa> [Tycho]: N-of-2 and N-of-3, iirc
107 2012-03-09 01:28:50 <[Tycho]> luke-jr: what else can I do ?
108 2012-03-09 01:29:13 <luke-jr> [Tycho]: become the 4th (to my knowledge) pool to support BIP 17, and help turn the tide :p
109 2012-03-09 01:29:39 <sipa> luke-jr: please; it's pointless
110 2012-03-09 01:29:41 <forsetifox> BIP changes how bitcoin transactions go around?
111 2012-03-09 01:29:53 <luke-jr> sipa: no, if [Tycho] supports BIP 17, then we have a tie
112 2012-03-09 01:29:55 <[Tycho]> I'm I bit afraid of more actions agains my pool from The Evil One.
113 2012-03-09 01:30:25 <luke-jr> sipa: and people won't feel than BIP 16 is the "only realistic route" anymore, so hopefully defect to BIP 17 :p
114 2012-03-09 01:31:01 <sipa> wishful thinking :)
115 2012-03-09 01:31:15 <[Tycho]> BIP16 would be not that worst if it at least had some opcode.
116 2012-03-09 01:31:27 <luke-jr> sipa: even without [Tycho], more and more people have been reading the BIPs and expressing support
117 2012-03-09 01:31:42 <sipa> luke-jr: which people? forum members?
118 2012-03-09 01:31:51 <luke-jr> sipa: some on the forum, some on IRC
119 2012-03-09 01:32:18 <[Tycho]> But I'm just tired of this standoff.
120 2012-03-09 01:32:22 <sipa> i'm sure some of them are easy to convince; and it isn't that hard, few people claim there is much difference in the quality of the proposals
121 2012-03-09 01:32:42 <luke-jr> sipa: I didn't even try to convince them :p
122 2012-03-09 01:32:55 <luke-jr> a good number of them just got around to reading the BIPs
123 2012-03-09 01:32:59 <sipa> my concern is that if no concensus can be reached here, we will never be able to reach a consensus when it is necessary
124 2012-03-09 01:33:13 <luke-jr> maybe. but no reason that consensus can't be 17
125 2012-03-09 01:33:16 <[Tycho]> Of course technically I can hold BIP16 for at least 2 months, but it doesn't looks like anyone is going to offer something better.
126 2012-03-09 01:33:22 <sipa> i am very glad BIP16 is at least uncontroversial
127 2012-03-09 01:33:24 <sipa> eh
128 2012-03-09 01:33:25 <sipa> BIP30
129 2012-03-09 01:33:53 <luke-jr> [Tycho]: BIP17 *is* better. -.-
130 2012-03-09 01:34:04 <sipa> according to some
131 2012-03-09 01:34:08 <[Tycho]> luke-jr: the difference is not so dramatic.
132 2012-03-09 01:34:32 <[Tycho]> I can agree that it's better because there is some opcode instead of magic.
133 2012-03-09 01:34:41 <sipa> I agree it is nicer; not better
134 2012-03-09 01:34:53 <[Tycho]> But it's still a crutch.
135 2012-03-09 01:34:55 <luke-jr> I don't expect to see anything better than BIP 17, so if you're just holding out for even better, it isn't going to happen.
136 2012-03-09 01:35:17 <luke-jr> so if that's the case, go ahead and support 16, and I'll just withdraw 17 :/
137 2012-03-09 01:35:30 <luke-jr> [Tycho]: it's not a crutch, though.
138 2012-03-09 01:35:38 <luke-jr> BIP 17 is a natural extension to the existing protocol
139 2012-03-09 01:35:46 <forsetifox> You can always change later? It's not a hard upgrade is it?
140 2012-03-09 01:35:55 <luke-jr> forsetifox: no
141 2012-03-09 01:36:01 <[Tycho]> I'm talking about both things, not the opcode specifically.
142 2012-03-09 01:36:14 <forsetifox> So.. try out BIP 16 for a while then try BIP 17 for a while.
143 2012-03-09 01:36:19 <[Tycho]> Looks like The Big Change will never happen.
144 2012-03-09 01:36:30 <jrmithdobbs> forsetifox: no lets not
145 2012-03-09 01:36:30 <luke-jr> forsetifox: it's irreversible.
146 2012-03-09 01:36:38 <forsetifox> Ooh.
147 2012-03-09 01:36:48 <luke-jr> [Tycho]: BIP 17 *is* just an opcode&
148 2012-03-09 01:36:59 <[Tycho]> luke-jr: cool.
149 2012-03-09 01:37:13 <sipa> forsetifox: many people have opinions about either, but most agree that either solution is better than both
150 2012-03-09 01:37:21 <forsetifox> Heh.
151 2012-03-09 01:37:29 <[Tycho]> It's very sad that we will never see full-featured scripts working :(
152 2012-03-09 01:37:35 <sipa> [Tycho]: please
153 2012-03-09 01:37:39 <sipa> who said that?
154 2012-03-09 01:37:50 <luke-jr> [Tycho]: &what?
155 2012-03-09 01:38:02 <[Tycho]> sipa: how it will be possible to enable all the opcodes ?
156 2012-03-09 01:38:14 <luke-jr> [Tycho]: Bitcoin 2.0 - block chain fork edition
157 2012-03-09 01:38:14 <[Tycho]> I mean the math and strings.
158 2012-03-09 01:38:21 <jrmithdobbs> um, luke already will mine such txns
159 2012-03-09 01:38:24 <sipa> [Tycho]: oh that, no, indeed
160 2012-03-09 01:38:26 <jrmithdobbs> wont you?
161 2012-03-09 01:38:31 <[Tycho]> luke-jr: do you really think that it can happen ?
162 2012-03-09 01:38:36 <[Tycho]> jrmithdobbs: no, he can't.
163 2012-03-09 01:38:39 <sipa> [Tycho]: but isstandard may be weakened over time
164 2012-03-09 01:38:40 <luke-jr> [Tycho]: someday.
165 2012-03-09 01:39:27 <[Tycho]> luke-jr: BIP16 standoff shows something about that. Such a small change is delayed by months. Total fork will be delayed by ages :)
166 2012-03-09 01:39:46 <luke-jr> [Tycho]: BIP 16 isn't as small as BIP 17 :p
167 2012-03-09 01:40:03 <[Tycho]> luke-jr: but it still didn't happened yet.
168 2012-03-09 01:40:24 <luke-jr> [Tycho]: that's because there's problems with it
169 2012-03-09 01:40:46 <[Tycho]> So I think that big fork will take close to forever.
170 2012-03-09 01:41:06 <sipa> BIP17 is nicer considering it is more of a return to the meaning scripts had before the parsing was split in two; BIP16 is nicer because it fewer changes to the operational semantics (BIP17 adds extra data flow from the scriptSig to scriptPubKey)
171 2012-03-09 01:41:10 <sipa> imho
172 2012-03-09 01:41:31 <sipa> +does
173 2012-03-09 01:41:43 <forsetifox> Which one is simpler? =P
174 2012-03-09 01:41:54 <[Tycho]> Sadly both will require out-of-chain communications :(
175 2012-03-09 01:41:59 <sipa> forsetifox: that's a philosophical question
176 2012-03-09 01:42:08 <sipa> [Tycho]: i consider that a good thing
177 2012-03-09 01:42:29 <sipa> the chain should only be used for communicating what is necessary for the world to verify it
178 2012-03-09 01:42:36 <[Tycho]> I like blockchain :)
179 2012-03-09 01:42:57 <sipa> sure, your spam fills 27% of it
180 2012-03-09 01:43:14 <jrmithdobbs> haha
181 2012-03-09 01:43:19 <[Tycho]> It's not spam, it's legitimate payload.
182 2012-03-09 01:43:24 <jrmithdobbs> no it's spam
183 2012-03-09 01:43:33 <[Tycho]> It may be a little bit suboptimal.
184 2012-03-09 01:43:35 <jrmithdobbs> you need to start using sendtomanys already
185 2012-03-09 01:43:42 <sipa> it is legitimate, but it is certainly not wanted
186 2012-03-09 01:43:51 <[Tycho]> Yes, I was thinking about sendmany yesterday.
187 2012-03-09 01:44:22 <[Tycho]> May be it will be implemented during the planned transition to increased security.
188 2012-03-09 01:44:55 <candlepin> so a dup tx could overwrite the previous one?
189 2012-03-09 01:44:56 <candlepin> interesting
190 2012-03-09 01:45:12 <sipa> candlepin: yes, in the tx index at least
191 2012-03-09 01:45:50 <jrmithdobbs> [Tycho]: pretty sure your spam wasted an hour and a half of my time earlier
192 2012-03-09 01:45:58 <[Tycho]> No way !
193 2012-03-09 01:46:21 <jrmithdobbs> [Tycho]: i had to bump bdb locks up to 1mil to get a reorg to go to fix a borked client that had rc1
194 2012-03-09 01:46:23 <forsetifox> I'm part of that spam! With my .15 payouts. LOLz
195 2012-03-09 01:46:28 <[Tycho]> "Spam" is something unwanted, but my payments are the opposite.
196 2012-03-09 01:46:57 <jrmithdobbs> so yes, really
197 2012-03-09 01:48:21 <[Tycho]> You can convince me into sendmany, but what will you do if someone will start the real flooding ? Or, in fantasy scenario, people will adopt bitcoin ? :)
198 2012-03-09 01:49:11 <luke-jr> sipa: BIP 17 just fixes a bug in that respect :P
199 2012-03-09 01:49:38 <luke-jr> forsetifox: BIP 17 is much simpler, both in practical terms (code) and theory (BIP 17 adds a new opcode; BIP 16 rearranges the whole system)
200 2012-03-09 01:50:32 <sipa> [Tycho]: then countermeasures will have to be found
201 2012-03-09 01:50:51 <sipa> [Tycho]: or if it is actual usage, adapt the way people use bitcoin (less full nodes, for example)
202 2012-03-09 01:50:53 <[Tycho]> Countermeasures against widespread adoption ? :)
203 2012-03-09 01:51:01 <forsetifox> Re-arranging might be a terrible idea. Making something complex more complex.
204 2012-03-09 01:51:59 <[Tycho]> I think that full nodes are cool and I like full nodes, but downloading 1 Gb is ALREADY too much for your average housewife.
205 2012-03-09 01:52:30 <[Tycho]> Unless it takes no more than 1 hour.
206 2012-03-09 01:53:10 <[Tycho]> I wonder how many potential users just give up before it's done.
207 2012-03-09 01:53:24 <sipa> forsetifox: BIP16 was still the preferred way among developers, is in my opinion cleaner in terms of semantics (though it requires a more complex standard-checking for compatibility reasons; on the other hand, it has the (used) opportunity to fix a flaw in the sigop counting); all this means indeed more code though
208 2012-03-09 01:54:03 <gmaxwell> [Tycho]: There are things other than full nodes but moreover, once we get things fixed we should be down to under an hour at least on recent computers.
209 2012-03-09 01:54:37 <gmaxwell> I can sync on 30 minutes if I cheat and run on tmpfs or with fsync bypassed.
210 2012-03-09 01:54:43 <luke-jr> sipa: developers are split between preferring 16 and 17. the sigop counting change is yet more complication, and proven unnecessary.
211 2012-03-09 01:55:10 <sipa> luke-jr: it can be worked around by dropping some functionality (CHECKMULTISIG)
212 2012-03-09 01:55:13 <[Tycho]> Ok. I wonder if Gavin will answer my e-mail today or not... Let's see.
213 2012-03-09 01:55:19 <sipa> that's something else than unnecessary
214 2012-03-09 01:55:45 <luke-jr> sipa: the same functionality as CHECKMULTISIG can be reproduced with a script
215 2012-03-09 01:55:48 <[Tycho]> sipa: since what version did plain multisig become standard ?
216 2012-03-09 01:56:02 <luke-jr> [Tycho]: BIP 11
217 2012-03-09 01:56:14 <sipa> luke-jr: yes, i just said it can be worked around
218 2012-03-09 01:56:25 <[Tycho]> luke-jr: what bitcoin version equals to it ?
219 2012-03-09 01:56:30 <sipa> [Tycho]: 0.6.0
220 2012-03-09 01:56:31 <luke-jr> [Tycho]: 0.6
221 2012-03-09 01:56:35 <[Tycho]> Ok.
222 2012-03-09 01:56:46 <sipa> [Tycho]: it's part of the changes you saw as BIP16, i suppose
223 2012-03-09 01:56:50 <luke-jr> BIP 19 is low-sigop multisig
224 2012-03-09 01:57:01 <[Tycho]> sipa: I saw it even earlier in OP_EVAL too.
225 2012-03-09 01:57:12 <sipa> oh yes, indeed
226 2012-03-09 01:57:27 <sipa> well, it's part of neither, just implemented simultaneously
227 2012-03-09 01:58:04 <gmaxwell> [Tycho]: full node also doesn't imply waiting no matter how slow the initial sync is the only reason a node can't sync in the background while acting as a thinclient/spv-node is because no one has written the software for that yet.
228 2012-03-09 01:58:43 <gmaxwell> Of course if it isn't under an hour on typical hardware after the performance is further improved it will be _directly_ as a result of your poor decision making with respect to not using sendmany.
229 2012-03-09 01:59:16 <[Tycho]> If I'll create unencrypted wallet.dat with 0.6.0 will it be incompatible with older versions ?
230 2012-03-09 01:59:23 <sipa> [Tycho]: no
231 2012-03-09 01:59:33 <sipa> eh, yes, it will be incompatible
232 2012-03-09 01:59:38 <sipa> unless you turn of compressed pubkeys
233 2012-03-09 01:59:38 <tcatm> http://188.138.99.157/stuff/qtvert.png I've made the toolbar vertical. What do you think?
234 2012-03-09 01:59:56 <sipa> tcatm: i like
235 2012-03-09 02:00:20 <[Tycho]> sipa: I like the import/export functionality, but it cannot be implemented in 0.3, so I'm thinking about using other versions for that.
236 2012-03-09 02:00:21 <gmaxwell> tcatm: whats all the empty space for (sorry, I don't use the GUI)
237 2012-03-09 02:00:49 <sipa> [Tycho]: the first version of key import/export i wrote was for 0.3.20
238 2012-03-09 02:00:59 <[Tycho]> Also I wonder if it would be possible to import a new key without rescan.
239 2012-03-09 02:01:15 <sipa> that's often requested and not hard to change
240 2012-03-09 02:01:36 <[Tycho]> sipa: I saw some patches, but those were created for something else.
241 2012-03-09 02:02:20 <[Tycho]> I'm thinking about the possibility of re-creating a new wallet for 1VayNert without all the old TXes, but with same key.
242 2012-03-09 02:02:33 <sipa> that's possible
243 2012-03-09 02:02:55 <[Tycho]> Bitcoind works much better without creating a new address each time, but still slowing down a bit.
244 2012-03-09 02:04:30 <[Tycho]> I also have old backups of that wallet, but not sure if it's clean or not. It it's not, I'll have to create a "double-spending TX" (of course failed) to empty it out.
245 2012-03-09 02:10:37 <sipa> gmaxwell: just thought of an extra recovery hint for HD wallets (buzzword compliant name for hierarchical determinstic wallets): if the internal and external chain are split, you don't need any (or much) allowed gap between internal keys... they are allocated and used at the same time, so there should never be gaps; you also know that inputs of transactions that spend to them are always yours, so you could perform a "gap extension" if such a...
246 2012-03-09 02:10:44 <sipa> transaction was found with an unknown prevout key
247 2012-03-09 02:11:20 <da2ce7> tcatm: don't like it :( takes up way more space.
248 2012-03-09 02:12:02 <sipa> da2ce7: horizontal space yes, but that is usually more adundant anyway
249 2012-03-09 02:12:46 <tcatm> I'm trying to implement something cool like the Design Proposal from that email some devs get today... :)
250 2012-03-09 02:14:23 <sipa> tcatm: good; i wasn't sure what to answer
251 2012-03-09 02:14:52 <tcatm> http://188.138.99.157/stuff/qtvert2.png let's figure out how to add hover/active/clicked/whatever styles :)
252 2012-03-09 02:15:04 <da2ce7> hmm... on 2nd thought it isn't too bad.
253 2012-03-09 02:15:28 <nanotube> what design proposal? was that on the list?
254 2012-03-09 02:15:46 <luke-jr> hmm
255 2012-03-09 02:15:47 <sipa> nanotube: no, privately to some devs
256 2012-03-09 02:15:55 <luke-jr> I didn't get a straight answer from [Tycho] re P2SH :/
257 2012-03-09 02:16:07 <gmaxwell> sipa: thats an excellent point. There should never be any gaps at all in the internal ones, since even if you restore a backup or shutdown you'll just reuse as soon as you can.
258 2012-03-09 02:16:31 <sipa> gmaxwell: indeed
259 2012-03-09 02:20:30 <da2ce7> sipa: I have been doing some thinking... the wallet shouldn't be stored in 'user data'  or .bitcoin/  but rarther in "Documents/Bitcoin" or ~/Documents/Bitcoin ... we should have a folder called 'wallet'
260 2012-03-09 02:21:05 <da2ce7> where users can place files called home.hdwallet
261 2012-03-09 02:21:17 <da2ce7> or as many .hdwallet files as they want.
262 2012-03-09 02:21:31 <da2ce7> so they are not in a hidden folder, and and are easy to manage.
263 2012-03-09 02:22:02 <sipa> da2ce7: once wallets are made independent from the block chain datadir
264 2012-03-09 02:22:55 <gmaxwell> While we continue to use bdb (at least with a single bdb session) any seperation would be a nice disaster recipe.
265 2012-03-09 02:23:07 <da2ce7> gmaxwell: yes.
266 2012-03-09 02:23:40 <andytoshi> has testing been done with sqlite or another, stabler, database?
267 2012-03-09 02:23:48 <da2ce7> however there isn't any reason that the hdwallets are not either a basic binary file, or base64 encoded text file.
268 2012-03-09 02:24:11 <sipa> da2ce7: i plan to implement them using the current wallet format after some thinking
269 2012-03-09 02:24:28 <sipa> the move towards independent wallet files, or a different storage format can then happen independently
270 2012-03-09 02:24:32 <da2ce7> sipa: included the bdb?
271 2012-03-09 02:24:39 <sipa> yes
272 2012-03-09 02:25:35 <da2ce7> maybe we should write up a standard base64 encoded text file format that, all the differnt bitcoin apllications can use. (or at least support)
273 2012-03-09 02:26:29 <gmaxwell> da2ce7: jgarzik was very much opposed to creating our own format for wallets.
274 2012-03-09 02:26:59 <sipa> da2ce7: the bitcoinj people are already working on a standard wallet format
275 2012-03-09 02:27:07 <da2ce7> having them in a Documents/Bitcoin/wallet/ location... measn that i can one-day load Multibit, then the next Stashoi... and not care about downgrade or upgrade or changing version or hidden files.
276 2012-03-09 02:27:35 <sipa> i'm not sure about the approach, many wallets are implemented from a rather different viewpoint
277 2012-03-09 02:27:53 <sipa> i'd much more like a common interchange format rather than a wallet format itself
278 2012-03-09 02:28:41 <da2ce7> sipa: that means that private files get stored in differnt places for every differnt application...
279 2012-03-09 02:28:55 <da2ce7> private files should be sotred in one place only. in a standard format.
280 2012-03-09 02:29:01 <da2ce7> for evey differnt bitcoin app.
281 2012-03-09 02:29:15 <sipa> da2ce7: i think it is naive to think you can just move the file from one application to the next
282 2012-03-09 02:29:33 <da2ce7> sipa: why not... private keys should be stored in ram only.
283 2012-03-09 02:29:46 <andytoshi> they need to be stored across reboots somehow ;)
284 2012-03-09 02:30:12 <sipa> one will have accounts, the other will have determinstic keys; one is intended to work as a ledger, the other only functions to keep a balance, ...
285 2012-03-09 02:30:13 <andytoshi> i agree with sipa here -- if all bitcoin clients can use the same wallet
286 2012-03-09 02:30:13 <da2ce7> andytoshi: of coures... that is why you save them to a standard location, in a standard format.
287 2012-03-09 02:30:22 <andytoshi> that pretty much forces them to have the same featureset
288 2012-03-09 02:30:55 <da2ce7> sipa: I don't store my Open Office documents, in a differnt location to my KOffice documents, to my AbiWord docs...
289 2012-03-09 02:31:20 <andytoshi> no, but they -are- different files, and you need importers/exporters to convert between them
290 2012-03-09 02:31:20 <sipa> but open office, koffice and abiword all implement a remarkably comparable application
291 2012-03-09 02:31:24 <andytoshi> which break things
292 2012-03-09 02:31:39 <andytoshi> plus, there's a fair bit of money involved in making office apps work together
293 2012-03-09 02:32:02 <da2ce7> but they all impment the same Open Document format...
294 2012-03-09 02:32:16 <andytoshi> no, there is stuff Word can do that nothing else can
295 2012-03-09 02:32:22 <da2ce7> even if they don't individualy impment ALL the features of the Open Document format.
296 2012-03-09 02:32:37 <nanotube> on an unrelated note - i notice the 0.5.2 qt client still recommends a "paytxfee 0.01" setting in the preferences. seems like that's outdated?
297 2012-03-09 02:32:53 <andytoshi> that's a fair point da2ce7, but i think bitcoin wallets will be more varied
298 2012-03-09 02:33:05 <andytoshi> as sipa pointed out, what if one has deterministic wallets and the other doesn't?
299 2012-03-09 02:33:10 <sipa> da2ce7: how are you going to merge the idea that armory has, where each "wallet" is a single determinstic chain, and the satoshi client that has wallets consisting of several accounts, with individually created keys
300 2012-03-09 02:33:19 <sipa> there is no way to make those applications comparable
301 2012-03-09 02:33:49 <sipa> and i don't think they should be
302 2012-03-09 02:34:45 <sipa> (etotheipi has expressed intentions to switch to the key deriviation scheme of hdwallets if they get implemented, so a single chain could be exported/imported between them)
303 2012-03-09 02:35:45 <da2ce7> sipa: no problem... make an extendable format where armory's format is defined as an 'optional' feature... however, a warning should be showed... "Multibit unfortunaly dosn't yet support the Armory wallet features, some funds may be unavaliabe in this program"
304 2012-03-09 02:36:05 <andytoshi> that's a maintenance nightmare for everyone involved
305 2012-03-09 02:36:38 <da2ce7> andytoshi: not at all... if 95 % of the clients support an agreed standard.
306 2012-03-09 02:36:53 <sipa> they don't agree on *what* a wallet is
307 2012-03-09 02:37:00 <sipa> how are they going to agree on how to store it?
308 2012-03-09 02:37:19 <andytoshi> if i go off in my bunker and write BunkerClient that stores keys as tiles with letters on them
309 2012-03-09 02:37:22 <andytoshi> like in indiana jones
310 2012-03-09 02:37:22 <da2ce7> sipa: a wallet is a place that stores the private keys.
311 2012-03-09 02:37:39 <andytoshi> there's no way i can keep up with all the other clients and their crazy new features
312 2012-03-09 02:37:53 <da2ce7> or stores the information used to generate the private keys.
313 2012-03-09 02:37:53 <sipa> da2ce7: i disagree; electrum stores no private keys in their wallets afaik
314 2012-03-09 02:38:00 <andytoshi> but i'd still like to import/export to the satoshi client
315 2012-03-09 02:38:08 <luke-jr> nanotube: as a miner, I have no objections to 0.01 BTC transaction fees.
316 2012-03-09 02:38:14 <andytoshi> so it'd be nice if that import/export process was standardized
317 2012-03-09 02:38:27 <sipa> and saying that a wallet is something that stores private keys is not complete
318 2012-03-09 02:38:39 <sipa> at least it supports creating transactions
319 2012-03-09 02:38:56 <sipa> which means knowledge about existing outputs to addresses for which you have keys
320 2012-03-09 02:39:21 <da2ce7> andytoshi: Open Office dosn't store my documents in .OpenOffice, and only allows me to export them throogh their interface into a 'standard format'
321 2012-03-09 02:39:50 <sipa> so we agree; try to find consensus about an interchange format, not an own internal format?
322 2012-03-09 02:40:05 <luke-jr> use html
323 2012-03-09 02:40:11 <sipa> haha :D
324 2012-03-09 02:40:14 <andytoshi> :P
325 2012-03-09 02:40:44 <andytoshi> to that point, we might as well use json, since that's what everything else is
326 2012-03-09 02:40:50 <luke-jr> noooooooo
327 2012-03-09 02:40:56 <da2ce7> sipa: I do not agree... I beleve that the the 'saving on hdd' format should be standard, in standard places, with standard wallet management tools. (eg, copy and paste)
328 2012-03-09 02:40:57 <sipa> andytoshi: that's what my dumpwallet patch uses
329 2012-03-09 02:41:08 <andytoshi> luke-jr: why nooooo?
330 2012-03-09 02:41:10 <sipa> da2ce7: good luck with that :)
331 2012-03-09 02:42:05 <gmaxwell> da2ce7: by "copy and paste" you mean  "trivial accidental corruption because maintaining the referential integrity is non-trivial", right?
332 2012-03-09 02:43:24 <da2ce7> gmaxwell: it should be the same as a important text document..  the application always saves a tempory file before updating the orignal, and always dose a full check after updating.
333 2012-03-09 02:43:38 <da2ce7> however it should be extendable so each program can still impment their own specal features, and the other clients, while not supporting the features, should warn and elagantly handel the other 'not supported' features
334 2012-03-09 02:43:50 <sipa> da2ce7: but text document applications agree on *what* a document is
335 2012-03-09 02:44:05 <sipa> it is like wanting to make ms word and latex use the same format
336 2012-03-09 02:44:13 <da2ce7> sure... that is the task for a BIP imho
337 2012-03-09 02:44:18 <andytoshi> heey, i like that analogy
338 2012-03-09 02:44:18 <gmaxwell> ...
339 2012-03-09 02:44:53 <gmaxwell> da2ce7: You're totally failing to understand me here. It's not a text document. It's a database. Some elements refer to other elements. If you copy and paste you will potentially create nonsense.
340 2012-03-09 02:45:06 <gmaxwell> The handling of this nonsense will likely be undertested in the software
341 2012-03-09 02:45:20 <da2ce7> gmaxwell: no...copy and paste the _file_ not the text in the document.
342 2012-03-09 02:46:01 <gmaxwell> da2ce7: and what happens if you truncate some of it?  if you want the whole thing to be copy and pastable .. use the base64 command.
343 2012-03-09 02:46:03 <da2ce7> we should have wallets named "mum.hdwallet" and "business.hdwallet"
344 2012-03-09 02:46:24 <da2ce7> in a 'wallet' directory.
345 2012-03-09 02:46:36 <da2ce7> in the Documents folder of the User.
346 2012-03-09 02:46:44 <forsetifox> I agree with that.
347 2012-03-09 02:47:07 <da2ce7> you doubble click on a wallet, and it dosn't load up your text editor... but rarther you default bitcoin client.
348 2012-03-09 02:47:08 <forsetifox> Don't know why the blockchain, wallet , logs etc are buried in a system directory.
349 2012-03-09 02:47:29 <andytoshi> %APPDATA% isn't really a system directory..
350 2012-03-09 02:47:38 <sipa> forsetifox: it's not a system directory; it is your user's application data directory
351 2012-03-09 02:47:40 <andytoshi> but i think we all agree that wallet.dat should be more visible
352 2012-03-09 02:47:47 <da2ce7> forsetifox: logs, and blockchain makes sence in a hidden app folder... however the WALLET DOSE NOT.
353 2012-03-09 02:47:51 <sipa> and that is certainly where the blockchain belongs
354 2012-03-09 02:47:55 <sipa> i agree the wallet does not
355 2012-03-09 02:48:00 <andytoshi> the blockchain and stuff are -very- client-specific, and can be lost without serious consequence
356 2012-03-09 02:48:02 <andytoshi> ditto for the logs
357 2012-03-09 02:49:26 <andytoshi> da2ce7: you are assuming that all clients are fundamentally the same
358 2012-03-09 02:50:25 <andytoshi> suppose, for example, someone wrote a "corporate wallet", where three execs had to sign every transaction
359 2012-03-09 02:50:32 <andytoshi> then everyone has copies of the public keys
360 2012-03-09 02:50:41 <andytoshi> but only personal pieces of the private ones
361 2012-03-09 02:50:46 <da2ce7> andytoshi: no... I assume that there are some standard features between every client, such as managmenet of private keys of some sort.
362 2012-03-09 02:51:06 <sipa> da2ce7: i believe that common functionality will be very small
363 2012-03-09 02:51:12 <da2ce7> andytoshi: and that would be handeld by a specal 'optional' feature in the wallet.
364 2012-03-09 02:51:23 <andytoshi> alternately, suppose a client stored the keys partially in the TPM chip of the system
365 2012-03-09 02:51:34 <andytoshi> these are just off the top of my head
366 2012-03-09 02:51:57 <andytoshi> and to implement them as "features" that are optional, we'd basically need multiple whole new wallet formats
367 2012-03-09 02:52:09 <sipa> agree
368 2012-03-09 02:52:13 <sipa> anyway; /me -> bed
369 2012-03-09 02:52:33 <da2ce7> yes... then the other private data should be stored in the bitcoin wallet folder so other apps can make use of the TPM chip also, if they choose to impment that part of the optional requirements also.
370 2012-03-09 02:53:10 <andytoshi> that's crazy, we'd need knowledge of all TPM chips and all similar functionality in a -wallet- format!
371 2012-03-09 02:53:37 <andytoshi> what if it's not a tpm chip, but a biometric of some sort?
372 2012-03-09 02:54:25 <andytoshi> what if it's a usb dongle, or a darknet hook, or a roomba dance?
373 2012-03-09 02:54:27 <da2ce7> andytoshi: no it ain't crazy at all... as APP XYZ will use a part of the wallet file called "APP XYZ"... unless annother app knows what it is and wants to use it... it will just skip right over it.
374 2012-03-09 02:54:50 <andytoshi> then we aren't talking about a wallet format, but a "generic data" format
375 2012-03-09 02:54:54 <andytoshi> along the lines of xml, json, yaml
376 2012-03-09 02:55:01 <sipa> skip? or warn the user that data will be lost?
377 2012-03-09 02:55:15 <nanotube> luke-jr: haha
378 2012-03-09 02:55:24 <da2ce7> skip and warn that some features are unsupported.
379 2012-03-09 02:55:33 <sipa> dream on :)
380 2012-03-09 02:55:39 <sipa> that's what I'm going to do now
381 2012-03-09 02:55:46 <andytoshi> alright, gnight
382 2012-03-09 02:55:57 <andytoshi> da2ce7: then we've lost the benefit of standardization
383 2012-03-09 02:56:45 <andytoshi> you use office docs as an example, but suppose our main use case was the viewing of documents?
384 2012-03-09 02:56:59 <andytoshi> then word processors, LaTeX, PDF, and image formats would all achieve that
385 2012-03-09 02:57:20 <andytoshi> and which one you used, would depend on things completely unrelated to "viewing documents"
386 2012-03-09 02:57:28 <da2ce7> andytoshi: no we don't... don't you see... that while clients 'can skip and warn'  they also can make use of it... if they support that particualr extention.
387 2012-03-09 02:57:30 <andytoshi> similarly, the main use case of wallets is "bitcoin transactions"
388 2012-03-09 02:58:05 <da2ce7> the main beniift of the standadization is that now there IS a standard, if apps want to choose to impment it.  or not.
389 2012-03-09 02:58:42 <andytoshi> they wouldn't choose to, if it had the scope of "typesetting language OR word processor language OR compressed image data OR portable document format"
390 2012-03-09 02:58:54 <andytoshi> 0% of people wold
391 2012-03-09 02:58:56 <da2ce7> so maybe super perculear business wallet app... features will not be impmented by anyone else... however the baseic private key import featues may be impment by all sorts of apps.
392 2012-03-09 02:59:23 <andytoshi> yes, and we are back to sipa's argument - standardize on a method of exchanging keypairs
393 2012-03-09 02:59:25 <andytoshi> and not much else
394 2012-03-09 02:59:45 <andytoshi> because those, in the end, are all the bitcoin protocal knows about
395 2012-03-09 02:59:54 <luke-jr> oh ok
396 2012-03-09 02:59:56 <andytoshi> and all we are guaranteed, clients would have to implement
397 2012-03-09 03:00:03 <da2ce7> andytoshi: no... we are talking about an extendable format for storing the privtae data, where apps can make use of it in a 'best-effort way'
398 2012-03-09 03:00:08 <luke-jr> then obviously the answer must be UTF-8
399 2012-03-09 03:03:46 <da2ce7> it is no differnt to how KOffice make a 'best effort' on the Open Document format... while there are things that only Open Office supports, they all save in the same extendable data format.
400 2012-03-09 03:04:11 <andytoshi> yes, it is very different
401 2012-03-09 03:04:21 <andytoshi> and where word processors differ, it is very frustrating
402 2012-03-09 03:04:22 <da2ce7> how?
403 2012-03-09 03:04:34 <andytoshi> when i do cool stuff in excel, and openoffice bricks it
404 2012-03-09 03:04:42 <andytoshi> i can't imagine if there was money involved
405 2012-03-09 03:05:00 <andytoshi> i have explained to you how it is different, as has sipa
406 2012-03-09 03:05:39 <da2ce7> andytoshi: sure... that is why the standard must define how 'unsupported featues' are handeld... but not limit what _can_be_ defined...
407 2012-03-09 03:05:55 <da2ce7> aka... no losses, just warnings.
408 2012-03-09 03:06:47 <da2ce7> if multibit dosn't suport th TPM, then dispay a warning, but still make use of the standard private keys. and hd wallet features.
409 2012-03-09 03:06:58 <andytoshi> alright, suppose i write a roomba-dance client
410 2012-03-09 03:07:20 <andytoshi> i send transactions to the roomba, it dances out a signed transaction, which a webcam translates into something the network can read
411 2012-03-09 03:07:28 <andytoshi> how would your imagined format let me do that?
412 2012-03-09 03:08:18 <k9quaint> nobody encodes transactions in roomba via webcam anymore
413 2012-03-09 03:08:21 <k9quaint> upgrade your shit
414 2012-03-09 03:08:38 <andytoshi> maybe i'm a mountain hermit running openbsd
415 2012-03-09 03:08:45 <andytoshi> on a vax
416 2012-03-09 03:08:49 <k9quaint> then you are thrice damned!
417 2012-03-09 03:09:02 <da2ce7> well do you need to store any private data?  If so, you will make a "RoombaClient" section in one of the wallet files, and store your unique data there... I doubt any other client will bother supporting that section tho.
418 2012-03-09 03:09:36 <andytoshi> da2ce7: then does the standard need to have a "RoombaClient" section, or am i required to ignore the standard?
419 2012-03-09 03:09:41 <andytoshi> either way, the standard sucks
420 2012-03-09 03:10:17 <da2ce7> andytoshi: no anyone is free to make any named section in the wallet...
421 2012-03-09 03:10:24 <da2ce7> unless that name is defined in the standard.
422 2012-03-09 03:10:28 <da2ce7> or reseverd.
423 2012-03-09 03:10:29 <andytoshi> so it's just so underspecified as to be useless
424 2012-03-09 03:11:05 <da2ce7> no... as the 'standard private key stoarge' section is well defined and supported by many clients.
425 2012-03-09 03:11:06 <andytoshi> you're essentially advocating a "generic data storage" format
426 2012-03-09 03:11:33 <andytoshi> da2ce7: you mean, every client who stores pregenerated private keys supports it
427 2012-03-09 03:11:39 <andytoshi> and only those clients
428 2012-03-09 03:16:52 <da2ce7> hello... sorry stupid mobile conenction.
429 2012-03-09 03:19:39 <da2ce7> the clients that support the pregenerated private key usage, can choose the implment that standard-named section of wallet file format.
430 2012-03-09 03:32:29 <andytoshi> i think, better to have -all- clients support export of private keys, and those who store them, also support import
431 2012-03-09 03:32:42 <andytoshi> then arguably we could just use the satoshi client as a "standard" wallet.dat
432 2012-03-09 03:33:17 <andytoshi> then if you want to transfer wallets, you could install the satoshi client, and use just it as an importer/exporter
433 2012-03-09 03:33:30 <andytoshi> i appreciate you want "double click and it chooses your favorite client"
434 2012-03-09 03:33:49 <andytoshi> but that's simply not practical except for clients who closely match the satoshi featureset
435 2012-03-09 03:33:58 <andytoshi> and they could just use the satoshi wallet.dat as their standard
436 2012-03-09 03:36:15 <da2ce7> andytoshi: the satoshi wallet.dat makes for a very bad format... it is a bdb, contains unnessary information, is not easly extendable... etc.
437 2012-03-09 03:37:06 <da2ce7> also you shoudn't need to export data to use a differnt application... that means if I want to restore a backup to a diffent client, I need to first install the orignal client, export, then inport into the new one.
438 2012-03-09 03:37:43 <da2ce7> that is lots of work that could be saved just by supporting an extendable wallet, that where common features can be supported by many differnt clients.
439 2012-03-09 03:39:37 <da2ce7> the "satoshi featureset" btw, is just a list of private keys.... not that hard for other clients to support.
440 2012-03-09 04:14:58 <gmaxwell> da2ce7: No, that _isn't_ the satoshi fatureset.
441 2012-03-09 04:15:32 <da2ce7> gmaxwell: well it includes refrences to transactions, and what one is uesd also. and naming.
442 2012-03-09 04:15:45 <da2ce7> and so that addresses can be linked to a human readable name.
443 2012-03-09 04:16:11 <da2ce7> but the 'private data' part is only a list of private keys.
444 2012-03-09 04:16:37 <gmaxwell> da2ce7: You appear to have an awful high ratio of opinion to information. The reference client includes an accounts feature that tracks many seperate balances, a pool of future address, change-designated addresses which are hidden, and multiple kinds of keys.
445 2012-03-09 04:17:00 <gmaxwell> Not to mention wallet encryption, and the new p2sh stuff.
446 2012-03-09 04:17:50 <nanotube> and, apparently, some config that should really be in .conf but isn't. :)
447 2012-03-09 04:17:59 <gmaxwell> nanotube: hah, indeed.
448 2012-03-09 04:18:08 <luke-jr> wasn't*
449 2012-03-09 04:18:26 <gmaxwell> I'm sure if I think for a bit I'll come up with some more.
450 2012-03-09 04:18:30 <da2ce7> hmm... I hadn't heard abou the other kind of keys... but otherwise it is just a list of private keys (either encypted or unencypted).
451 2012-03-09 04:19:16 <gmaxwell> No, it's not just a list of private keys.
452 2012-03-09 04:19:21 <da2ce7> for p2sh we will need to store public keys also.
453 2012-03-09 04:21:10 <da2ce7> and in the address book, we can make a key as, 'unused, change, or used'
454 2012-03-09 04:22:53 <gmaxwell> I like how you totally ignored my mention of accounts because it's not something you know about.
455 2012-03-09 04:24:11 <da2ce7> accounts is a features that allows balances of bitcoins to be maintined for difernt names... from my understanding it isn't tied to a particaular private key.
456 2012-03-09 04:24:35 <da2ce7> it can be used in accounting, however there is no gui support for it atm.
457 2012-03-09 04:24:47 <gmaxwell> I recommend you actually learn more about the system before you work on proposals for it.
458 2012-03-09 04:25:27 <da2ce7> gmaxwell: I recomend you stop being a complete dick, I beleve I know bitcoin quite well by now.
459 2012-03-09 04:25:44 <gmaxwell> You're demonstrating that you don't.
460 2012-03-09 04:26:02 <gmaxwell> And you've been doing so for about two hours now.
461 2012-03-09 04:26:43 <gmaxwell> and yes, accounts are related to particular keys/addresses.
462 2012-03-09 04:27:00 <da2ce7> ah... well then my memory decevies me.
463 2012-03-09 04:28:15 <gmaxwell> Had you spent the last two hours looking at the system instead of blathering here about ideas which you seemingly expect other people to implement, perhaps your memory would have been fresher.
464 2012-03-09 04:28:30 <gmaxwell> And on that note, goodnight.
465 2012-03-09 04:29:22 <da2ce7> well sleep well.
466 2012-03-09 04:36:36 <da2ce7> ah yes... accounts are for incoming coins... not outgoing.
467 2012-03-09 04:38:17 <Raccoon> Is there a config for specifying the path to a wallet without altering the path to block data?  or visa versa?
468 2012-03-09 04:39:33 <Raccoon> In the scenario that someone has a portable install of bitcoin that they use between multiple machines that utilize bitcoin, and they wish to only store their wallet info on the USB but not block data
469 2012-03-09 04:40:00 <Raccoon> since block data is not only large, but also induces wear for SSD.
470 2012-03-09 04:40:18 <andytoshi> i believe the answer is no
471 2012-03-09 04:40:26 <andytoshi> i'm scanning through the source to make sure..
472 2012-03-09 04:40:30 <andytoshi> but this has come up before
473 2012-03-09 04:40:34 <Raccoon> ok
474 2012-03-09 04:41:21 <gmaxwell> Raccoon: the block data is append only, though the index is probably wear inducing.  That sounds like an application for a thin client like electrum.
475 2012-03-09 04:41:35 <Raccoon> i'd like to propose more granular path configs, as well as a "switch wallet" option on the client interface
476 2012-03-09 04:42:56 <Raccoon> and a change in the order of bitcoin.conf file searching.  always looking for a bitcoin.conf in the same location as the compiled bitcoin binary, before moving onto user folders
477 2012-03-09 04:43:11 <Raccoon> since that follows standard convention for most other apps.
478 2012-03-09 04:43:20 <Raccoon> and makes bitcoin more portable
479 2012-03-09 04:44:50 <andytoshi> that sounds simple enough that you could write a patch for it
480 2012-03-09 04:45:02 <andytoshi> which gives you more chance of someone paying attention to your proposal
481 2012-03-09 04:45:34 <andytoshi> the path config business, would require a change to the command-line options, and for that you'd need a consensus
482 2012-03-09 04:45:42 <Raccoon> only other thought on the subject is that '' and '/' be automatically converted for the OS, and that '~/' automatically resolves to '%appdata%' in windows.
483 2012-03-09 04:45:45 <andytoshi> (i am not a dev, but that is how things work on projects where i -am- a dev)
484 2012-03-09 04:46:57 <Raccoon> andytoshi: I by no means wish to interrupt the way things are done, but since I'm not at all familiar with the code, I hope that suggestions are welcomed by those who are.
485 2012-03-09 04:47:07 <andytoshi> but fwiw, i second your request -- i would like to have wallet.dat on a sshfs
486 2012-03-09 04:47:11 <andytoshi> and the blockchain local
487 2012-03-09 04:53:56 <Raccoon> andytoshi: sshfs is a mounted network drive right?
488 2012-03-09 04:54:19 <andytoshi> yes, that's right
489 2012-03-09 04:54:28 <Raccoon> ok
490 2012-03-09 04:54:29 <andytoshi> it uses SSH to encrypt all i/o
491 2012-03-09 05:13:35 <ageis> http://ageispolis.net/test/code.jpg
492 2012-03-09 05:13:57 <andytoshi> :(
493 2012-03-09 05:14:01 <andytoshi> :) i mean
494 2012-03-09 05:33:19 <pentarh> p2pool generated block has transaction with inputs < outputs http://blockexplorer.com/tx/ad2ab11753a96e2ca9e161de2766ed93ae6f1d26f819c53449e35569fe13c824
495 2012-03-09 05:34:17 <gmaxwell> ...
496 2012-03-09 05:34:32 <gmaxwell> pentarh: this is the generated transaction. It includes fees.
497 2012-03-09 05:34:53 <gmaxwell> Note at the top, input "50 + fees"
498 2012-03-09 05:35:18 <pentarh> ah, yeah )
499 2012-03-09 05:47:40 <Raccoon> ageis: whatever's on that monitor is way too high resolution for that era. :p
500 2012-03-09 05:48:02 <Raccoon> i don't think that's even 4 color capable
501 2012-03-09 05:49:10 <Raccoon> dig the wood paneling though
502 2012-03-09 07:33:45 <neofutur> fyi http://bitcoin.gw.gd
503 2012-03-09 08:11:45 <opr> https://bitcointalk.org/index.php?topic=66790.0
504 2012-03-09 08:11:48 <opr> mods on that forum are useless
505 2012-03-09 08:12:21 <opr> please reply
506 2012-03-09 09:11:36 <sturles> Running latest git bitcoind, I get the following error today:
507 2012-03-09 09:11:38 <sturles> "errors" : "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."
508 2012-03-09 09:19:18 <sturles> I get a lot of errors like this as well:
509 2012-03-09 09:19:19 <sturles> EXCEPTION: 11DbException
510 2012-03-09 09:20:10 <edcba> maybe you lack memory ?
511 2012-03-09 09:23:05 <sturles> 2 GiB + 10 GiB swap.
512 2012-03-09 09:23:18 <sturles> All swap free.
513 2012-03-09 09:23:37 <sturles> 64bit system.
514 2012-03-09 09:39:12 <sturles> Restarted bitcoind on two nodes half an hour ago.  One of them is now getting in sync with the network again.  The other one has supiciously few connections.  Only 10 with two incoming.  Normal is about 100 shortly after starting, almost all incoming.
515 2012-03-09 09:53:54 <Raccoon> gah.  i need access to big numbers.
516 2012-03-09 09:54:18 <Raccoon> what is 4^52 in base2
517 2012-03-09 10:00:06 <edcba> 2^104
518 2012-03-09 10:13:19 <sturles> I restarted the synced node with addnode=the other node, but the other node is still stuck at block 170061 and the same error.  The error is gone from the first node.
519 2012-03-09 10:17:52 <sturles> Darnit!  I have another node stuck at block 170061 as well.  This one has no error message and runs an earlier version from git > 0.5.2.
520 2012-03-09 10:35:08 <neofutur> a good question on http://bitcoin.stackexchange.com/questions/3122/bitcoind-statstics/3124#3124
521 2012-03-09 10:35:34 <neofutur> am I right to say the bitcoin client cant know the latest block number until it have reached it ?
522 2012-03-09 10:35:43 <neofutur> so its impossible to tell the user
523 2012-03-09 10:35:56 <neofutur> you have reached block XXX / YYYY
524 2012-03-09 10:39:05 <sturles> It can't know for sure until all are verified, but it can report what other clients claim they have.  A malicious client can report arbitrary numbers to your client, so the bitcoin client can not be sure until the last block is verified.
525 2012-03-09 10:39:46 <sturles> It can also make a guesstimate based on the current time and the age of the last verified block.
526 2012-03-09 10:44:05 <neofutur> thanks
527 2012-03-09 10:44:31 <neofutur> I ll ad this to my answer (  or you prefer to do it yourself if you use stackexchange ?)
528 2012-03-09 11:00:55 <sturles> Hmm.  There was a blockchain split at block 170059 resulting in three different versions of block 170061.  Could this be the source of my problems?  The node stuck at 170059 synced fairly quickly after a restart.  I finally managed the third node to start synching again.  The second node is still stuck on a probably orphaned block 170061.
529 2012-03-09 11:06:13 <neofutur> I suppose the only way to have this "guesstimate" would be to modify the client code ? nothing in the API ?
530 2012-03-09 11:12:41 <sturles> Not that I know of.  You may look for messages like "version message: version 32300, blocks=170346" in debug.log to check where your connected nodes were when you connected to them.  It's the closest I know of, but I don't know everything about the API.
531 2012-03-09 11:15:22 <sturles> Btw, a few hosts keep connecting with the following:
532 2012-03-09 11:15:24 <sturles> version message: version 60000, blocks=140700
533 2012-03-09 11:16:44 <superjames> getmemorypool  => "time" : timestamp appropriate for next block          would that be it?
534 2012-03-09 11:17:08 <sturles> No.
535 2012-03-09 11:17:51 <superjames> damn
536 2012-03-09 11:33:34 <sturles> The split from 170059 is interesting.  The orphaned chain made it to three blocks and contained about 400 more transactions than the surviving chain.
537 2012-03-09 11:46:39 <sturles> Doh!  jrmithdobbs had the solution to my problem yesterday!  Same error message: "Lock table is out of available lock entries"
538 2012-03-09 11:47:42 <sturles> Trying the patch..
539 2012-03-09 12:09:48 <neofutur> I could not find a rss feed annoucing new versions of bitcoind
540 2012-03-09 12:10:17 <neofutur> neither on bitcoin.org not on https://github.com/bitcoin/bitcoin
541 2012-03-09 12:10:53 <edcba> ;;bc,mtgox
542 2012-03-09 12:10:54 <gribble> {"ticker":{"high":4.9499,"low":4.809,"avg":4.898139312,"vwap":4.905515502,"vol":37973,"last_all":4.91957,"last_local":4.91957,"last":4.91957,"buy":4.91957,"sell":4.91958}}
543 2012-03-09 12:12:40 <neofutur> a rss feed on bitcoin.org would be cool
544 2012-03-09 12:24:32 <sturles> Patch worked!
545 2012-03-09 16:19:17 <[Tycho]> Hello, devs.
546 2012-03-09 16:21:25 <sipa> hi [Tycho]
547 2012-03-09 16:21:33 <[Tycho]> Hello, sipa
548 2012-03-09 16:21:46 <BlueMatt> hi [Tycho]
549 2012-03-09 16:23:27 <BlueMatt> [Tycho]: whats your status in deploying bip16?
550 2012-03-09 16:25:20 <sipa> Inaba of eclipsemc has a weird issue eith COINBASE_FLAGS
551 2012-03-09 16:26:11 <sipa> he's using git head of a few days ago, and tried to tweak the coinbase flags to add something himself, just a constant string
552 2012-03-09 16:26:39 <sipa> but the produced blocks seem to.contain garbage
553 2012-03-09 16:27:20 <[Tycho]> BlueMatt: I successfully backported it today.
554 2012-03-09 16:27:33 <sipa> o/
555 2012-03-09 16:27:42 <BlueMatt> [Tycho]: nice! so when does it go online?
556 2012-03-09 16:27:59 <[Tycho]> Have a couple of questions before deploying it.
557 2012-03-09 16:28:04 <sipa> shoot
558 2012-03-09 16:28:42 <[Tycho]> What's the point of removing  WalletUpdateSpent(txin.prevout); there ?
559 2012-03-09 16:29:02 <[Tycho]> May be its replaced by something. If yes - where ?\n3089393
560 2012-03-09 16:29:11 <sipa> where exactly?
561 2012-03-09 16:29:17 <sipa> in script?
562 2012-03-09 16:29:27 <[Tycho]> In VerifySignature(const CTransaction& txFrom, const CTransaction& txTo, unsigned int nIn, bool fValidatePayToScriptHash, int nHashType)
563 2012-03-09 16:29:38 <sipa> it absolutely does not belong there
564 2012-03-09 16:30:10 <sipa> and it was hard to keep doing it that way when CWallet was introduced
565 2012-03-09 16:30:16 <[Tycho]> How this functionality is performed now
566 2012-03-09 16:30:17 <[Tycho]> ?
567 2012-03-09 16:31:40 <sipa> let's see
568 2012-03-09 16:31:48 <sipa> you mean in current master?
569 2012-03-09 16:32:29 <[Tycho]> No, after BIP16 patch
570 2012-03-09 16:33:14 <sipa> you'll have to ask gavin
571 2012-03-09 16:34:11 <[Tycho]> His patch does this:
572 2012-03-09 16:34:14 <[Tycho]> -    // Anytime a signature is successfully verified, it's proof the outpoint is spent,
573 2012-03-09 16:34:16 <[Tycho]> -    WalletUpdateSpent(txin.prevout);
574 2012-03-09 16:35:02 <sipa> where is the patch?
575 2012-03-09 16:35:09 <[Tycho]> I don
576 2012-03-09 16:35:19 <[Tycho]> 't know, he sent it by mail
577 2012-03-09 16:35:24 <sipa> ok
578 2012-03-09 16:35:36 <[Tycho]> I can forward it to you
579 2012-03-09 16:36:07 <sipa> sure
580 2012-03-09 16:37:05 <[Tycho]> Mail sent
581 2012-03-09 16:39:50 <t7> why is main.cpp so many LOC ?
582 2012-03-09 16:42:06 <sipa> t7: satoshi didn't write very encapsulated code :)
583 2012-03-09 16:42:19 <sipa> a lot was already moved to separate files
584 2012-03-09 16:42:38 <t7> are there any other clients (that are reasonably complete) ?
585 2012-03-09 16:43:00 <sipa> libcoin is a heavily-refactored version of the satoshi code
586 2012-03-09 16:43:11 <sipa> libbitcoin is not complete, last i heard
587 2012-03-09 16:43:41 <sipa> bitcoinj is complete but only does simplified verification
588 2012-03-09 16:43:43 <t7> how about an implementation in a language without ptr arithmetic?
589 2012-03-09 16:43:51 <t7> ah java?
590 2012-03-09 16:43:52 <TD> i heard the word, bitcoinj
591 2012-03-09 16:43:53 <sipa> yes
592 2012-03-09 16:44:57 <t7> ok one last things, is the constant growth of the blockchain going to be an issue at some point?
593 2012-03-09 16:45:30 <TD> probably not
594 2012-03-09 16:45:37 <TD> it requires some smart engineering on the consumer clients
595 2012-03-09 16:45:42 <TD> which we're not quite done with yet
596 2012-03-09 16:45:47 <TD> in the next few months, i hope (for bitcoinj)
597 2012-03-09 16:47:45 <sipa> [Tycho]: i have to go, i'll have a look at it later
598 2012-03-09 16:47:58 <[Tycho]> sipa: did you received it ?
599 2012-03-09 16:48:03 <sipa> yes
600 2012-03-09 16:48:04 <[Tycho]> Ok.
601 2012-03-09 16:48:14 <[Tycho]> At this moment it
602 2012-03-09 16:48:21 <[Tycho]> s the last questiong
603 2012-03-09 16:48:34 <sipa> it should not be a problem, unless you need to restore a wallet backup
604 2012-03-09 16:48:58 <sipa> it seems like the corresponding adding of that call was not backported
605 2012-03-09 16:49:12 <sipa> but i need to look at it closer
606 2012-03-09 16:49:25 <[Tycho]> May be I'll have to replace wallet.dat and don't know what will happen.
607 2012-03-09 17:19:18 <mcorlett> Is it possible to create a generation transaction with thousands of tiny single-satoshi outputs in order to spam the network?
608 2012-03-09 17:27:31 <JFK911> yes
609 2012-03-09 17:48:47 <luke-jr> [Tycho]: ping
610 2012-03-09 17:48:51 <[Tycho]> pong
611 2012-03-09 17:48:57 <denisx> peng
612 2012-03-09 17:49:49 <luke-jr> [Tycho]: I didn't get a clear answer as to BIP 16 the other day; are you deploying it for sure, or still uncertain?
613 2012-03-09 17:50:51 <[Tycho]> Currently I'm working on the support of BIP16, but didn't deploy it yet. May be I'll start making BIP16 blocks before 15.03
614 2012-03-09 17:51:10 <[Tycho]> I'm a bit concerned about the fragile majority.
615 2012-03-09 17:51:13 <gavinandresen> You'll inconvenience a lot of people if you don't.....
616 2012-03-09 17:51:44 <[Tycho]> If just one pool will disappear somehow, the 51%+ of BIP16 will be lost.
617 2012-03-09 17:52:26 <gavinandresen> [Tycho]: the remaining miners will have a VERY strong incentive to upgrade once we're past 51%
618 2012-03-09 17:52:45 <gavinandresen> If they don't, they risk hashing on an invalid chain.
619 2012-03-09 17:52:48 <[Tycho]> gavinandresen: are you sure you can reach them ?
620 2012-03-09 17:52:59 <[eval]> the majority won't be fragile after consensus is achieved, otherwise the minority will produce orphaned blocks like what eclipsemc/ozcoin accidentally did
621 2012-03-09 17:53:28 <[Tycho]> BTW, I wonder who is the new MM from Spain
622 2012-03-09 17:54:06 <Graet> [eval], ?
623 2012-03-09 17:54:08 <[Tycho]> [eval]: I think I have just one problem left to solve before BIP16 will be available to me.
624 2012-03-09 17:55:55 <upb> what is BIP?
625 2012-03-09 17:57:26 <[Tycho]> Graet: don't forget to deploy BIP30 before 15.03
626 2012-03-09 17:57:39 <Graet> we are [Tycho] :)
627 2012-03-09 17:57:45 <Graet> ty :)
628 2012-03-09 17:58:41 <forsetifox> BIP30 is ok with BIP16?
629 2012-03-09 17:58:48 <forsetifox> Or was that a joke?
630 2012-03-09 17:59:08 <[Tycho]> BIP30 is almost twice as cool as BIP16
631 2012-03-09 17:59:31 <Graet> ^^
632 2012-03-09 18:02:02 <luke-jr> [Tycho]: I just need to know if it's inevitable that Deepbit will support BIP 16. If so, I might as well withdraw BIP 17
633 2012-03-09 18:03:08 <[Tycho]> luke-jr: sorry, but I think that its time to resolve this standoff.
634 2012-03-09 18:03:38 <luke-jr> [Tycho]: So "yes, I am deploying BIP 16 on Deepbit for sure, it's just a question of when"?
635 2012-03-09 18:03:51 <[Tycho]> BIP17 is possibly better, but the enemy has Gavin's support, so almost nothing can be done.
636 2012-03-09 18:04:33 <luke-jr> I'm not trying to argue what you should do. I'm sure I've done that before. I just want to know what your decision is when you make it.
637 2012-03-09 18:04:34 <forsetifox> Who is the "enemy" Tycho?
638 2012-03-09 18:04:39 <luke-jr> forsetifox: BIP 16
639 2012-03-09 18:05:47 <[Tycho]> I wasn't participating in the voting, but BIP16 is still winning (on the pie chart)
640 2012-03-09 18:06:29 <luke-jr> [Tycho]: the pie chart is erroneous and doesn't even show BIP 17
641 2012-03-09 18:06:47 <luke-jr> BIP16: 37% support vs 4% oppose
642 2012-03-09 18:06:49 <luke-jr> BIP17:  4% support vs 0% oppose
643 2012-03-09 18:07:03 <luke-jr> as of Tuesday
644 2012-03-09 18:07:49 <luke-jr> [Tycho]: I am interpreting your responses as "I am holding back on making a decision just yet"; if I should interpret it otherwise, please be more clear.
645 2012-03-09 18:07:53 <[Tycho]> So 4% of oppose equals to the support of BIP17 ? Then it shows it correctly.
646 2012-03-09 18:07:54 <Graet> how does that maths work i wonder?
647 2012-03-09 18:08:11 <luke-jr> Graet: based on the last 1000 blocks
648 2012-03-09 18:08:45 <[Tycho]> luke-jr: as for this moment, I'm planning to deploy BIP16 before 15.03
649 2012-03-09 18:09:15 <Graet> so theres a vote to oppose bip16 in the vote for bip17, but no vote against 17 in 16? so thats how you come up with those figures?
650 2012-03-09 18:10:22 <candlepin> bip16 is excellent
651 2012-03-09 18:10:29 <[Tycho]> Looks like the wallet thing is resolved now.
652 2012-03-09 18:10:44 <[Tycho]> candlepin: no.
653 2012-03-09 18:11:23 <luke-jr> Graet: there are 4 identifiers
654 2012-03-09 18:11:26 <candlepin> gavinandresen++
655 2012-03-09 18:11:37 <luke-jr> Graet: /P2SH/ NOP2SH p2sh/CHV p2sh/NOCHV
656 2012-03-09 18:11:45 <[Tycho]> See - they are just Gavin's fans.
657 2012-03-09 18:11:57 <luke-jr> candlepin: try actually reading the BIP
658 2012-03-09 18:12:04 <candlepin> i have
659 2012-03-09 18:12:13 <gavinandresen> BIP16 has just one identifier.
660 2012-03-09 18:12:14 <Graet> havent nseen /CHV p2sh/NOCHV widely publicised... shame
661 2012-03-09 18:12:21 <candlepin> it does what we need..
662 2012-03-09 18:12:41 <gavinandresen> ... and four seems like two too many.
663 2012-03-09 18:12:45 <luke-jr> Graet: it's part of the patch
664 2012-03-09 18:12:46 <[Tycho]> candlepin: plain multisig also does what we need and WORKS :)
665 2012-03-09 18:12:53 <luke-jr> [Tycho]: no, it doesn't.
666 2012-03-09 18:13:00 <Graet> luke-jr, its a way to enhance your fud is all...
667 2012-03-09 18:13:02 <[Tycho]> luke-jr: why ?
668 2012-03-09 18:13:12 <luke-jr> candlepin: it does what is needed, by breaking the existing rules in strange ways
669 2012-03-09 18:13:32 <gavinandresen> I'm going to go away; somebody /msg me when y'all are done beating the dead horse.
670 2012-03-09 18:13:43 <candlepin> i think from an interoperability standpoint, there might be need for a libsatoshi, just to make it easier for improvements to get deployed
671 2012-03-09 18:14:27 <luke-jr> candlepin: BIP 17 does what is needed within the existing system
672 2012-03-09 18:15:08 <[Tycho]> Someone is buying large amounts of shares at GPUMAX and points it to DeepBit. I wonder if they doing it without any reason or for supporting BIP17...
673 2012-03-09 18:15:33 <luke-jr> [Tycho]: I think if they wanted to support BIP 17, they would point it at Eligius
674 2012-03-09 18:15:47 <luke-jr> [Tycho]: pirat says GPUMAX buyers do so as gambling
675 2012-03-09 18:16:23 <Graet> [Tycho], they try to get short rounds, apparently it can be quite profitble, thats all they care about there ;)
676 2012-03-09 18:16:40 <candlepin> gpumax is a pool-hopping casino
677 2012-03-09 18:17:00 <Graet> except u cant really hop with it :)
678 2012-03-09 18:17:09 <candlepin> right i mean max internally is hopping around
679 2012-03-09 18:17:09 <denisx> how much hashing power do they have?
680 2012-03-09 18:17:16 <[Tycho]> Graet: someone tried :
681 2012-03-09 18:17:19 <[Tycho]> )
682 2012-03-09 18:17:41 <Graet> :)
683 2012-03-09 18:17:54 <sipa> Graet: you're ozcoin's operator, right?
684 2012-03-09 18:18:04 <Graet> yers sipa
685 2012-03-09 18:18:33 <sipa> Graet: any progress on implementing BIP30?
686 2012-03-09 18:19:06 <Graet> not yet but it will be by the 15th sipa
687 2012-03-09 18:19:47 <Graet> hopefully over the weekend
688 2012-03-09 18:20:31 <sipa> Graet: ok, good
689 2012-03-09 18:20:59 <sipa> btcguild just deployed it
690 2012-03-09 18:21:17 <Graet> cool, we get most done on weekends
691 2012-03-09 18:21:18 <[Tycho]> Cool.
692 2012-03-09 18:21:50 <sipa> and eclipsemc too, i believe
693 2012-03-09 18:24:31 <[Tycho]> Will the BIP16 address start from the same letter always ?
694 2012-03-09 18:25:16 <sipa> always a 3, afaik
695 2012-03-09 18:25:47 <sipa> technically, it is a bip13 address
696 2012-03-09 18:26:00 <sipa> bip16 is its implementation
697 2012-03-09 18:26:24 <[Tycho]> Looks like this part is missing from the backport
698 2012-03-09 18:33:05 <BlueMatt> "Quit: ERC Version 5.3 (IRC client for Emacs)" brings a whole new level to the idea "Emacs is a great OS, not such a great text editor"
699 2012-03-09 18:49:44 <[eval]> i retract the ozcoin thing i said, it was just eclipsemc and not ozcoin (sorry, i had a meeting right after i said that)
700 2012-03-09 18:50:53 <Graet> thanks [eval]
701 2012-03-09 18:51:12 <[eval]> :D
702 2012-03-09 19:02:18 <[Tycho]> 1 000 000 BTC mined :)
703 2012-03-09 19:03:02 <[eval]> congrats!
704 2012-03-09 19:03:09 <[Tycho]> Thanks.
705 2012-03-09 19:03:30 <gmaxwell> ;;bc,blocks
706 2012-03-09 19:03:31 <gribble> 170403
707 2012-03-09 19:03:43 <[eval]> we're at just under 31% annualized inflation at this point :)
708 2012-03-09 19:04:24 <[eval]> wb gavinandresen
709 2012-03-09 19:06:41 <andytoshi> haha, bitcoincharts is claiming 14 THash
710 2012-03-09 19:06:43 <andytoshi> what a network
711 2012-03-09 19:35:48 <gmaxwell> helo: Are you also one of the people that say that global warming is obviously impossible when you see a picture of snow?
712 2012-03-09 19:36:00 <forsetifox> Heh.
713 2012-03-09 19:37:07 <gmaxwell> (for more context, I'm looking at http://bitcoin.sipa.be/speed-lin-10k.png and not seeing any particular reason to justify helo's question)
714 2012-03-09 19:53:29 <[Tycho]> sipa: Gavin's example at testnet is
715 2012-03-09 19:53:35 <[Tycho]> "2", not "3".
716 2012-03-09 19:53:44 <[Tycho]> It's to separate testnet addresses ?
717 2012-03-09 19:54:58 <gavinandresen> Yes, testnet multisigs are '2something'
718 2012-03-09 19:59:27 <userttu> hi, will possible something like: can onl spend btc if 60% of 100 pre definied agree.
719 2012-03-09 19:59:34 <userttu> only
720 2012-03-09 20:00:08 <userttu> 100 pre definied address
721 2012-03-09 20:00:18 <userttu> ?
722 2012-03-09 20:03:01 <BlueMatt> 100 is a bit much - would require too much cpu power for the network to accept them
723 2012-03-09 20:03:06 <BlueMatt> but in theory, yes
724 2012-03-09 20:03:15 <BlueMatt> and in practice, less than 100, you can do any n of m
725 2012-03-09 20:04:34 <userttu> hum, there are some good examples where should be interesting more than 100
726 2012-03-09 20:04:59 <BlueMatt> yea, but enabling txes like that makes them a great ddos target
727 2012-03-09 20:05:54 <userttu> Maybe on future something like this can be done, right?
728 2012-03-09 20:06:07 <userttu> not impossible? right
729 2012-03-09 20:06:17 <BlueMatt> yea, just need a much more effecient signing algo
730 2012-03-09 20:06:26 <BlueMatt> (which would probably require a hard fork...)
731 2012-03-09 20:06:44 <userttu> ok, thanks for explanation
732 2012-03-09 20:10:52 <helo> perhaps it is a little premature to think the hashrate is actually higher...
733 2012-03-09 21:36:29 <gribble> New news from bitcoinrss: gavinandresen opened issue 922 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/922>
734 2012-03-09 21:42:21 <kish> ************************
735 2012-03-09 21:42:26 <kish> still working
736 2012-03-09 21:59:26 <sturles> kish: This happened to me today, and bitcoind got suck in an orphaned chain.
737 2012-03-09 22:01:30 <[Tycho]> anyone here ?
738 2012-03-09 22:02:39 <forsetifox> I am. But I doubt you need me.
739 2012-03-09 22:13:03 <BlueMatt> hi [Tycho]
740 2012-03-09 22:13:26 <[Tycho]> Wow, looks like I did it.
741 2012-03-09 22:13:53 <BlueMatt> what?
742 2012-03-09 22:14:08 <[Tycho]> Sent a P2SH TX
743 2012-03-09 22:14:48 <BlueMatt> ah
744 2012-03-09 22:14:59 <BlueMatt> well they arent checked yet...
745 2012-03-09 22:15:34 <BlueMatt> well, not on mainnet at least
746 2012-03-09 22:17:17 <luke-jr> :p
747 2012-03-09 22:18:19 <[Tycho]> luke-jr: you can, but it needs to be mined first :) Which is not possible yet, I supose.
748 2012-03-09 22:18:34 <luke-jr> [Tycho]: sure it is.
749 2012-03-09 22:18:41 <BlueMatt> any valid or semi-valid  p2sh tx should be mined atm
750 2012-03-09 22:18:45 <luke-jr> unchecked = anyone can take it
751 2012-03-09 22:18:58 <[Tycho]> I doubt it gets relayed somewhere.
752 2012-03-09 22:19:06 <luke-jr> [Tycho]: I bet Eligius has it.
753 2012-03-09 22:19:17 <[Tycho]> Show it to me :)
754 2012-03-09 22:19:20 <BlueMatt> relaying would be the issue, but you can peer with luke
755 2012-03-09 22:19:21 <luke-jr> txnid?
756 2012-03-09 22:19:28 <[Tycho]> BTW, what is redeeming script for it ?
757 2012-03-09 22:19:29 <luke-jr> BlueMatt: I intentionally peer with Deepbit. ;)
758 2012-03-09 22:19:36 <BlueMatt> oh, well then ok
759 2012-03-09 22:19:44 <BlueMatt> (if tycho sent it from the pool...)
760 2012-03-09 22:20:04 <[Tycho]> I doubt because my own nodes won't relay non-standard TXes yet.
761 2012-03-09 22:20:28 <[Tycho]> txid is 658fc92061f1c4125d5cd1034eb8a1f09bfebd32a988d855eb7ee63689759a21
762 2012-03-09 22:20:29 <BlueMatt> yet?
763 2012-03-09 22:20:50 <[Tycho]> Yet.
764 2012-03-09 22:21:15 <luke-jr> I don't have it.
765 2012-03-09 22:21:43 <[Tycho]> I'll enable relaying soon.
766 2012-03-09 22:21:47 <BlueMatt> why?
767 2012-03-09 22:22:50 <[Tycho]> Because 15.03 is coming soon.
768 2012-03-09 22:22:56 <BlueMatt> 15.03?
769 2012-03-09 22:23:11 <luke-jr> Bitcoin 15.0.3 ofc
770 2012-03-09 22:23:22 <[Tycho]> 15.03.2012
771 2012-03-09 22:23:35 <BlueMatt> and why are you enable nonstd relaying on 15.03.2012?
772 2012-03-09 22:24:05 <[Tycho]> Because it will be standard P2SH TX.
773 2012-03-09 22:24:38 <BlueMatt> well yea, enable relaying on standard p2sh txes, but why enable nonstd txes?
774 2012-03-09 22:25:15 <[Tycho]> I was talking about relaying P2SH
775 2012-03-09 22:25:33 <[Tycho]> But today it looks like non-standard TX for my relayers.
776 2012-03-09 22:25:35 <BlueMatt> oh, ok well yea, was that not part of the p2sh patch?
777 2012-03-09 22:26:01 <[Tycho]> It's not deployed to all nodes yet.
778 2012-03-09 22:26:30 <BlueMatt> oh, but you arent enabling all nonstd tx relaying are you?
779 2012-03-09 22:26:44 <[Tycho]> I'm not.
780 2012-03-09 22:27:02 <BlueMatt> ok, good to hear