1 2011-09-28 00:00:04 <luke-jr> gmaxwell: the key thing with fractions is infinite future-compatibility
  2 2011-09-28 00:00:14 <luke-jr> gmaxwell: so *future* clients can be more and more precise
  3 2011-09-28 00:00:19 <luke-jr> gmaxwell: without changing the protocol again
  4 2011-09-28 00:01:21 <lfm> luke-jr hehe, so why change the protocol at all untill it is actually needed?
  5 2011-09-28 00:01:22 <t3a> is there something that modifies the data being hashed? Because if everyone is just hashing an integer incremented by 1 starting at 0 every time then the fastest computer will always win
  6 2011-09-28 00:01:32 <luke-jr> lfm: I'm not suggesting that.
  7 2011-09-28 00:01:42 <lfm> t3a: ya, its called a nonce
  8 2011-09-28 00:01:43 <luke-jr> lfm: I'm suggesting that *when* the protocol is changed, we cover as much ground as possible
  9 2011-09-28 00:01:51 <gmaxwell> lfm: no, it's not. :)
 10 2011-09-28 00:01:55 <lfm> ah! I see
 11 2011-09-28 00:01:56 <casascius> t3a: everyone is hashing something different
 12 2011-09-28 00:01:59 <t3a> lfm: i thought the nonce was the number being incremented
 13 2011-09-28 00:02:02 <gmaxwell> t3a: yes, they payment address for the generated coin.
 14 2011-09-28 00:02:14 <luke-jr> t3a: the merkle root is different for every miner, because the generation txn has unique data
 15 2011-09-28 00:02:14 <t3a> oh
 16 2011-09-28 00:02:15 <t3a> makes sense
 17 2011-09-28 00:02:18 <gmaxwell> t3a: there is also an extranonce which miners can set freely.
 18 2011-09-28 00:02:31 <gmaxwell> (inside the coinbase txn)
 19 2011-09-28 00:02:44 <lfm> t3a: also everyone has their own merkle roots since everyone want their coinbas transaction to pay out to a different address
 20 2011-09-28 00:03:03 <lfm> like he said
 21 2011-09-28 00:03:30 <lfm> plus there is extra nonce bits in the coinbase txn if needed
 22 2011-09-28 00:03:30 <t3a> wait, i thought the merkle root was a hash of all the transactions?
 23 2011-09-28 00:03:47 <luke-jr> t3a: yes, including the coinbase
 24 2011-09-28 00:03:52 <gmaxwell> Yes, well a hash of a hash tree.
 25 2011-09-28 00:03:52 <t3a> coinbase?
 26 2011-09-28 00:04:00 <lfm> and every time you add another txn you have to update the merkle root yes
 27 2011-09-28 00:04:00 <t3a> the walled ID?
 28 2011-09-28 00:04:02 <casascius> coinbase = transaction that miners create to pay the 50 btc reward to themselves
 29 2011-09-28 00:04:04 <gmaxwell> A special mandatory transaction.
 30 2011-09-28 00:04:04 <luke-jr> t3a: the transaction that says I get 50 BTC new
 31 2011-09-28 00:04:12 <t3a> oh
 32 2011-09-28 00:04:29 <t3a> what is the coinbase based on?
 33 2011-09-28 00:04:36 <lfm> 50 btc
 34 2011-09-28 00:04:39 <luke-jr> whatever you want
 35 2011-09-28 00:04:43 <casascius> the rule that says 50 btc per block
 36 2011-09-28 00:04:43 <t3a> oh
 37 2011-09-28 00:05:03 <lfm> for another year and a half then it will be 25
 38 2011-09-28 00:05:09 <t3a> and im guessing bitcoin miners chose an arbitrary string?
 39 2011-09-28 00:05:12 <luke-jr> t3a: presently, miners use their own address for the output, and use timestamp+incrementing number for input data
 40 2011-09-28 00:05:33 <t3a> oh
 41 2011-09-28 00:05:41 <t3a> brb, thanks for the help
 42 2011-09-28 00:05:48 <luke-jr> (older miners used difficulty-bits+incrementing number)
 43 2011-09-28 00:05:49 <lfm> t3a they generate a public/private key pair and then pay the 50 btc to the public key
 44 2011-09-28 00:06:26 <gmaxwell> well, they pay the maximum amount allows by the protocol unless they're crazy.
 45 2011-09-28 00:06:38 <lfm> new-style?
 46 2011-09-28 00:07:00 <gmaxwell> merged.
 47 2011-09-28 00:07:02 <luke-jr> lfm: due to encrypted wallets, the coinbase format had to be changed
 48 2011-09-28 00:07:15 <luke-jr> lfm: it was bits+extranonce for <0.4
 49 2011-09-28 00:07:16 <gmaxwell> oh... right.
 50 2011-09-28 00:07:16 <lfm> what?
 51 2011-09-28 00:07:20 <gmaxwell> because of running out of keys.
 52 2011-09-28 00:07:21 <luke-jr> now it's timestamp+extranonce
 53 2011-09-28 00:07:43 <gmaxwell> lfm: if your encrypted wallet client runs out of keys you don't want it making duplicate coinbases.
 54 2011-09-28 00:07:59 <gmaxwell> it doesn't do that conditionally, thats kinda lame.
 55 2011-09-28 00:08:16 <luke-jr> http://pident.artefact2.com/block/00000000000009c2d2b97652568f6118052669ba57baa709b933cc87e2d133af is interesting
 56 2011-09-28 00:08:27 <luke-jr> I wonder who that is
 57 2011-09-28 00:09:03 <gmaxwell> whats interesting about it? (not used to the pident output)
 58 2011-09-28 00:09:29 <lfm> so if you generated more than 100 new coinbases before the wallet could be re-encrypted youd have to reuse some keys or generate unencrypted keys or something
 59 2011-09-28 00:10:16 <gmaxwell> lfm: right, it reuses but reusing has a risk of a duplicate coinbase which is unspendable (obviously)
 60 2011-09-28 00:10:46 <gmaxwell> Generally the crypted wallet code will reuse if it runs out of keys, not just specific to this.
 61 2011-09-28 00:10:49 <lfm> ok, if your extranonce also repeated or something.
 62 2011-09-28 00:11:26 <luke-jr> gmaxwell: unusual coinbase
 63 2011-09-28 00:12:22 <luke-jr> lfm: your extranonce *would* repeat
 64 2011-09-28 00:12:27 <gmaxwell> lfm: well, they're often zero for non-pools.
 65 2011-09-28 00:12:35 <luke-jr> lfm: consider prevblock is not part of the coinbase hash
 66 2011-09-28 00:12:42 <lfm> anyway sounds like the change is a non-change really since the protcol ignored that nBits copy and certain "other" miners were already putting silly stuff in there
 67 2011-09-28 00:12:57 <luke-jr> lfm: it's not a protocol change, correct
 68 2011-09-28 00:14:18 <t3a> what exactly are the responsibilites of someone who generates a new block?
 69 2011-09-28 00:14:31 <lfm> why would the extranonce reapeat, cant you just keep incrementing it? you could easiliy remember a copy from run to run if it was resetting at the start of a run.
 70 2011-09-28 00:15:21 <lfm> t3a not really resposibilities, just follow the protocol if you want your coinbase to be honored
 71 2011-09-28 00:15:36 <t3a> yes, thats what i mean
 72 2011-09-28 00:15:51 <gmaxwell> t3a: obey the rules: https://en.bitcoin.it/wiki/Protocol_rules
 73 2011-09-28 00:15:51 <t3a> they have to confirm previous blocks?
 74 2011-09-28 00:16:08 <gmaxwell> t3a: thats implicit in the existance of the prev hash in the block header
 75 2011-09-28 00:16:32 <lfm> t3a: you are not required to actually include any txn besides the coinbase if you are being mean. you might miss out on some txn fees is all.
 76 2011-09-28 00:16:42 <luke-jr> lfm: if you're reusing the same payout address every time, you can NEVER reset extranonce if you do it that way
 77 2011-09-28 00:16:49 <luke-jr> lfm: it's much easier to throw in a timestamp
 78 2011-09-28 00:16:50 <t3a> what is txn?
 79 2011-09-28 00:17:09 <gmaxwell> A transaction.
 80 2011-09-28 00:17:11 <t3a> oh
 81 2011-09-28 00:17:21 <lfm> luke-jr huh? extra nonce is not connected to the payout address!
 82 2011-09-28 00:17:45 <gmaxwell> t3a: read this http://bitcoin.org/bitcoin.pdf
 83 2011-09-28 00:17:46 <t3a> i thought blocks had to confirm that previous blocks were valid?
 84 2011-09-28 00:17:52 <t3a> okay
 85 2011-09-28 00:17:56 <gmaxwell> lfm: ... read what he said again.
 86 2011-09-28 00:18:01 <lfm> oh, but yes, you must not reuse the extranonce(s)
 87 2011-09-28 00:18:12 <lfm> i see hwt you ment
 88 2011-09-28 00:18:23 <gmaxwell> luke-jr: technically you can reset it, you just have to remember to skip your prior blocks. :)
 89 2011-09-28 00:18:44 <gmaxwell> presumably you won't have so many that this is that much of a burden. :)
 90 2011-09-28 00:18:44 <lfm> so just keep incrementing the extranonce forever. do not reset it
 91 2011-09-28 00:18:54 <luke-jr> lfm: easier to include the timestamp
 92 2011-09-28 00:18:58 <gmaxwell> lfm: the timestamp will be more compact after a while.
 93 2011-09-28 00:20:30 <lfm> hmm, maybe but maybe not more compact than a timestamp plus an extranonce
 94 2011-09-28 00:21:02 <gmaxwell> well extranonce is often quite small.
 95 2011-09-28 00:21:28 <lfm> ya, ok. timestamp is easier than passing the extranonce between runs
 96 2011-09-28 00:21:34 <gmaxwell> Because if you're not mining with rolling you can reset it once per second, and thats what the code currently does so it's often just a single byte.
 97 2011-09-28 00:22:27 <luke-jr> gmaxwell: not anymore
 98 2011-09-28 00:22:35 <luke-jr> current code assumes rollntime
 99 2011-09-28 00:22:38 <gmaxwell> Did that get fixed?
100 2011-09-28 00:22:40 <gmaxwell> hurray.
101 2011-09-28 00:22:43 <luke-jr> we should probably add a header for it too
102 2011-09-28 00:22:51 <luke-jr> yeah, it was a dependency of the timestamp fix
103 2011-09-28 00:22:52 <t3a> are namecoins bitcoins with a different genesis block?
104 2011-09-28 00:22:59 <luke-jr> t3a: and DNS implementation
105 2011-09-28 00:23:19 <t3a> yes
106 2011-09-28 00:27:49 <Diablo-D3> http://www.damnlol.com/watermarked/ea83e08059fd271293365560edd6d795.jpg
107 2011-09-28 00:28:47 <luke-jr> Diablo-D3: Facebook ain't in Britian
108 2011-09-28 00:28:50 <luke-jr> it's in the USA
109 2011-09-28 00:31:36 <imsaguy> but they must still comply with EU laws
110 2011-09-28 00:35:03 <luke-jr> imsaguy: nonsens
111 2011-09-28 00:35:27 <luke-jr> EU has no jurisdiction beyond EU borders
112 2011-09-28 01:00:18 <CIA-101> bitcoin: Luke Dashjr * r27b4ecd7baec gentoo/app-misc/cgminer/ (4 files): app-misc/cgminer: Only depend on dev-util/amd-adl-sdk for building, not for runtime
113 2011-09-28 01:44:12 <shadders> TD: hey
114 2011-09-28 01:44:27 <TD> hi there
115 2011-09-28 01:45:10 <TD> how's it going ?
116 2011-09-28 01:45:14 <shadders> how would you feel about adding a non-parsing constructor to all the message classes... and giving the option to retain byte array after parsing?
117 2011-09-28 01:45:56 <shadders> happy to do it mysel... just wondering if it's likely to be accepted
118 2011-09-28 01:47:08 <CIA-101> bitcoin: Jeff Garzik master * rab1bbe5 / README.md :
119 2011-09-28 01:47:09 <CIA-101> bitcoin: Merge pull request #533 from alexwaters/readme
120 2011-09-28 01:47:19 <shadders> also, is the reason for a monolitic package so you can use package protected access to fields and avoid getters for android performance?
121 2011-09-28 01:48:20 <shadders> if so then I guess we're stuck with it until gingerbread is widely adopted..
122 2011-09-28 02:01:06 <TD> shadders: having parsing of some messages be lazy makes sense
123 2011-09-28 02:01:16 <TD> shadders: in particular for blocks
124 2011-09-28 02:01:47 <TD> shadders: ignoring proxies for a moment, chain download performance is dominated by block parsing time. delaying it until after a scan for interesting keys would be useful.
125 2011-09-28 02:02:22 <TD> shadders: i'm not sure it makes sense to expose as an api though. it might be better to just change how the Message class and descendants are implemented, so it's transparent to the object user.
126 2011-09-28 02:02:57 <TD> shadders: ie add a maybeParse() method call to the front of various getters
127 2011-09-28 02:03:25 <shadders> the way I'd normally do it would be to put a checkParsed() call in each getter and an array=null in each setter.  but without getters and setters the code that wants to use lazy parsing will have to manage it
128 2011-09-28 02:03:42 <TD> shadders: no, getter performance was not a factor in that design. using package-scoped methods/fields just makes it easier to carve out a library api with the public keyword. a lot of the methods/fields only make sense for internal use
129 2011-09-28 02:04:06 <TD> shadders: we can introduce getters/setters as needed. i think most fields have them these days.
130 2011-09-28 02:04:46 <TD> shadders: i think a maybeParse() method would be ok. what's the use case for retaining the underlying byte array after parsing?
131 2011-09-28 02:04:54 <TD> avoiding reserialization costs?
132 2011-09-28 02:04:58 <shadders> yes
133 2011-09-28 02:05:39 <shadders> you may only want to read for example to get hash to lookup... then you may want to resend.
134 2011-09-28 02:06:12 <TD> maybe the c'tor should take an int parseFlags
135 2011-09-28 02:06:16 <shadders> if you write to a field of course you have to take responsibility for deleting the array unless you write through a setter
136 2011-09-28 02:06:22 <TD> NOW = 1;
137 2011-09-28 02:06:23 <TD> LAZY = 2;
138 2011-09-28 02:06:26 <TD> RETAIN = 4;
139 2011-09-28 02:07:07 <shadders> sounds good... easy to maintain backward compatibility. old constuctor just call with default flag.
140 2011-09-28 02:07:07 <TD> yes, sure. we can introduce getters/setters where it'd be useful to have lazy parsing, so for blocks/transactions/addrs/...? anything else?
141 2011-09-28 02:07:28 <TD> yeah. some old c'tors can probably be removed too.
142 2011-09-28 02:08:07 <TD> we shouldn't worry too much about backwards compatibility for the moment. let's avoid gratuitous breakages, but api users are expected to keep up, as long as we don't make it too hard (breaking wallet serialization is a problem)
143 2011-09-28 02:08:11 <shadders> well the quandary is... if getters/setters manage the lazy/retain part so it's essentialy transparent then you'd have to make the fields private
144 2011-09-28 02:08:27 <TD> yeah that's fine. the trend over time was for more fields to become private.
145 2011-09-28 02:08:58 <shadders> one clean break would better than having it potentially still work without people knowing it's changed internallly
146 2011-09-28 02:10:02 <TD> sure. feel free to introduce getters/setters where useful.
147 2011-09-28 02:10:13 <TD> if  you can break up your patches so they're small enough to quickly review, that'd be helpful.
148 2011-09-28 02:10:24 <TD> feel free to leave in some support goop in the interim that is eventually removed.
149 2011-09-28 02:10:38 <shadders> btw I can't see why we should be hiding message fields that are part of the protocol.  There's any number of reasons people may need access to them.
150 2011-09-28 02:11:21 <TD> i think most fields of interest have getters by now
151 2011-09-28 02:11:42 <shadders> I will make the changes but I'd like to adopt a blanket policy of 'if the field is a protocol specified field, give public access'
152 2011-09-28 02:11:52 <TD> some fields are a bit complex because it doesn't always make sense to set them directly (eg, merkle roots)
153 2011-09-28 02:11:54 <shadders> through a getter I mean
154 2011-09-28 02:12:25 <TD> and some stuff probably should change, like, having outpoints be a separate class to inputs is something i copied from the c++, it doesn't necessarily make sense in java
155 2011-09-28 02:12:26 <shadders> well actually I have a use case for accesible merkle roots...
156 2011-09-28 02:12:37 <TD> accessible yes. settable, harder.
157 2011-09-28 02:12:47 <TD> i think there's already a getter for the merkle root on a block
158 2011-09-28 02:13:30 <TD> intellij is failing me right now ...
159 2011-09-28 02:14:06 <shadders> hmm... It might have been the calcMerkle methods I was thinking of that are private.  static merkle utility methods would be useful.  current use case, merged mining in poolserverj
160 2011-09-28 02:14:23 <shadders> anyway I'll stop scope creeping ;)
161 2011-09-28 02:14:33 <TD> ok
162 2011-09-28 02:14:41 <TD> there is a public getMerkleRoot() method
163 2011-09-28 02:14:46 <shadders> Will make the lazy/retain getter/setter changes and submit...
164 2011-09-28 02:14:47 <TD> it calculates the root lazily/on deand
165 2011-09-28 02:15:09 <TD> if you change the transactions in a block, the cached root is deleted and calling the getter will recalculate, as that's quite intensive.
166 2011-09-28 02:15:44 <TD> i tend to be conservative with marking stuff public, as the vague intention is that one day that'll be a stable api. clients can always fork the library a bit in order to make more stuff public if they'd find it useful
167 2011-09-28 02:15:58 <TD> given that the public methods aren't completely stable anyway though, maybe we should make more stuff public
168 2011-09-28 02:16:10 <TD> like Block.addTransaction should probably be public
169 2011-09-28 02:16:36 <TD> maybe some of the setters too, building your own blocks is something that makes sense to be public
170 2011-09-28 02:17:00 <TD> shadders: for the merged mining case, you want to calculate the merkle branches i think?
171 2011-09-28 02:17:11 <shadders> yes I really think bitcoinj should be library first, and client as a reference use case...
172 2011-09-28 02:17:16 <shadders> yes..
173 2011-09-28 02:17:28 <shadders> validate braches, calc them... build a tree etc...
174 2011-09-28 02:17:28 <TD> the current code only calculates full trees.
175 2011-09-28 02:17:42 <TD> we should probably extract that out into a real API
176 2011-09-28 02:18:36 <TD> MerkleTree/MerkleBranch classes make sense. a tree would perhaps implement the List interface and let you add/remove Sha256Hash objects
177 2011-09-28 02:18:57 <shadders> I know.. I was going to make a proper merkle class to add all the missing bits. but I thought I'd talk about the other change 1st in case I frightened with mass change proposals
178 2011-09-28 02:19:07 <TD> the Tree could return a Branch for any given item in the list. Branch objects would know how to verify themselves.
179 2011-09-28 02:19:17 <TD> sure, thanks for checking with me
180 2011-09-28 02:19:22 <TD> making more stuff public i'm fine with
181 2011-09-28 02:19:41 <TD> if you want to introduce a real API for working with merkle trees/branches, posting a sketch of the API to the list would be helpful.
182 2011-09-28 02:20:00 <TD> i don't think it'd be hard to implement and would indeed be useful for some of the more exotic protocols like merged mining, some contract negotiations, etc
183 2011-09-28 02:20:09 <shadders> any idea when we can move to a DCVS? then I can just post a branch...
184 2011-09-28 02:20:35 <TD> oh, sure. soon. we needed to resolve some stuff google-side before doing a new release, that's now done.
185 2011-09-28 02:20:42 <midnightmagic> To the maximum coins convo earlier. t3a et al, the current total bitcoins that will ever be mined I believe is somewhere near this value: 20999999.97689999. It will happen at block 6929999. Since 2016 blocks in 14 days of seconds is the ideal retarget, and we are currently on 147195, that gives us about 129 52-week years before the final Satoshi is mined.
186 2011-09-28 02:20:49 <TD> so i want to get 0.3 out RSN. hopefully i can finish my current patch first.
187 2011-09-28 02:20:53 <shadders> I see I'm outvoted on mercurial... I guess I'll have to make my peace with git
188 2011-09-28 02:20:58 <TD> after 0.3 miron is going to do the conversion to git
189 2011-09-28 02:21:09 <TD> well honestly i'm not a huge git fan myself, but everyone except us seem to like it :)
190 2011-09-28 02:21:11 <midnightmagic> read: long after we're all dead.
191 2011-09-28 02:21:19 <Diablo-D3> midnightmagic: thats pretty much what I figured out a year ago
192 2011-09-28 02:21:37 <t3a> why do people call them satoshis?
193 2011-09-28 02:21:43 <Diablo-D3> t3a: after satoshi.
194 2011-09-28 02:21:46 <shadders> I'm sure I won't hate it as much once I learn how to use it...
195 2011-09-28 02:21:48 <t3a> i know
196 2011-09-28 02:22:03 <midnightmagic> There's no good name for 1x10e-8 bitcoins, which is the smallest indivisible unit of bitcoins.
197 2011-09-28 02:22:06 <TD> conceptually they're all the same. i actually used the very first DVCS many years ago
198 2011-09-28 02:22:08 <Diablo-D3> it seems fitting to name the smallest btc currency unit after him
199 2011-09-28 02:22:13 <TD> tom lords arch, implemented as a single gigantic shell script, lol
200 2011-09-28 02:22:17 <t3a> but people dont call the mona lisa the davinci
201 2011-09-28 02:22:20 <midnightmagic> er..  1x10^-8 i mean.
202 2011-09-28 02:22:32 <midnightmagic> t3a: that's because there's a good name for the mona lisa. the mona lisa.
203 2011-09-28 02:22:39 <Diablo-D3> t3a: no, but you'd call a micro mona lisa a davinci.
204 2011-09-28 02:22:44 <t3a> bitcoin is a bad name?
205 2011-09-28 02:22:54 <t3a> a micro mona lisa?
206 2011-09-28 02:23:27 <midnightmagic> a bitcoin is divisible down to 1e-8 individual units.
207 2011-09-28 02:23:34 <TD> t3a: conventionally a "bitcoin" refers to 100000000 value units. the source code doesn't have any particular name for the smallest amount
208 2011-09-28 02:23:39 <midnightmagic> read: "bitcoin" is already taken.
209 2011-09-28 02:23:40 <Diablo-D3> yes, a very tiny divsion of the mona lisa would be one divinci.
210 2011-09-28 02:23:43 <TD> t3a: it simply refers to it as 'value'
211 2011-09-28 02:23:53 <TD> but that's a fairly ambiguous term
212 2011-09-28 02:24:09 <t3a> oh, so the smallest possible usit of bitcoins is a satoshi?
213 2011-09-28 02:24:13 <Diablo-D3> t3a: you know how dollars have cents?
214 2011-09-28 02:24:23 <Diablo-D3> btc has 8 places of cents, called satoshis.
215 2011-09-28 02:24:34 <Diablo-D3> instead of just 2 like dollars do
216 2011-09-28 02:24:56 <midnightmagic> and they can't just be cents, because cents is short for hundredths
217 2011-09-28 02:25:14 <Diablo-D3> I was calling them ubtc for awhile
218 2011-09-28 02:25:27 <t3a> how about
219 2011-09-28 02:25:31 <Diablo-D3> then someone decided to call them satoshis and it fit
220 2011-09-28 02:25:32 <t3a> 10 nano-bitcoins
221 2011-09-28 02:25:47 <Diablo-D3> t3a: because that implies you can have 1 ubtc.
222 2011-09-28 02:25:48 <midnightmagic> t3a: because you're getting your units mixed up.
223 2011-09-28 02:25:56 <Diablo-D3> and its micro, not nano
224 2011-09-28 02:25:59 <t3a> midnightmagic: goo point
225 2011-09-28 02:26:01 <t3a> *good
226 2011-09-28 02:26:10 <t3a> 500 nano-btc
227 2011-09-28 02:26:19 <Diablo-D3> so satoshis works
228 2011-09-28 02:26:28 <t3a> yep
229 2011-09-28 02:27:47 <TD> shadders: btw if you implement a MerkleBranch class, could you make sure it's compatible with how satoshi defined a branch?
230 2011-09-28 02:27:48 <TD> shadders: https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L876
231 2011-09-28 02:31:23 <TD> shadders: ideally try and avoid the way satoshi wrote this code though, unless the alternatives are much slower. his style is efficient and compact but also involves the sort of logic that lots of people aren't familiar with.
232 2011-09-28 02:31:50 <midnightmagic> what sort of logic is that?
233 2011-09-28 02:32:33 <TD> look at GetMerkleBranch. it uses XOR and bit shifts.
234 2011-09-28 02:32:57 <TD> it works well but you have to think about it carefully
235 2011-09-28 02:33:21 <TD> compare https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L857 vs http://code.google.com/p/bitcoinj/source/browse/trunk/src/com/google/bitcoin/core/Block.java#291
236 2011-09-28 02:33:38 <TD> same function but the latter version has variable names that are a bit more helpful and more comments
237 2011-09-28 02:34:04 <midnightmagic> it makes me sad that features of the language should be avoided.
238 2011-09-28 02:34:24 <TD> *shrug* they don't have to be avoided. just depends what your aims are.
239 2011-09-28 02:34:27 <shadders> ok will have a look... I might write a simple less efficient implementation first then can use that as a test against a more cryptic implementation
240 2011-09-28 02:35:11 <shadders> the more cryptic it is the less likely I am to notice it's behaving oddly...
241 2011-09-28 02:35:16 <midnightmagic> for maximum collaboration. those sorts of constructs are almost certainly avoided by my coworkers too.
242 2011-09-28 02:36:44 <TD> shadders: yeah. at the very least if you copy his code, make sure you write lots of comments to explain each line. otherwise something like int i = std::min(nIndex^1, nSize-1); can be quite inscrutable
243 2011-09-28 02:37:24 <shadders> hehe... well it is to me unless I'm prepared to get a headache...
244 2011-09-28 02:37:35 <midnightmagic> C as a language can contain a kind of terseness that I rarely see these days, and I miss discovering it. it's a kind of purity, like a rare crystal.
245 2011-09-28 02:37:59 <shadders> I bet you had fun deciphering it all to buld bitcoinj
246 2011-09-28 02:38:32 <shadders> honestly bitcoinj is the best documentation bitcoin has imho
247 2011-09-28 02:38:49 <TD> barrels of fun. i mean i know conceptually what these functions all do. sometimes i've had to step through some of the more complex algorithms on paper to convince myself i understand them
248 2011-09-28 02:39:05 <TD> the lightweight-mode reorg handling was a pain in the ass because it has to work differently to the c++ implementation
249 2011-09-28 02:39:15 <midnightmagic> well, crystals do need to be handled delicately. :)
250 2011-09-28 02:39:18 <TD> hehe
251 2011-09-28 02:39:26 <TD> yep. i kind of like these functions too
252 2011-09-28 02:39:31 <TD> once you get them, they are kind of pure
253 2011-09-28 02:40:09 <TD> but satoshi tends to write the kind of stuff i'd throw back in a code review with a request for, at minimum, way more comments.
254 2011-09-28 02:40:33 <midnightmagic> honestly, i can almost hear a sort of bell ringing in my head when I read that stuff. not like a synaethesia or anything, but I get the same thing when I taste coffee that has no flaws in it.
255 2011-09-28 02:40:43 <midnightmagic> yeah for sure..
256 2011-09-28 02:41:10 <midnightmagic> 'tis a harsh mistress for a gourmet..
257 2011-09-28 02:41:34 <shadders> well I'm glad it was you that came up with merged mining not satoshi... I had a week of nightmares getting my head around that... I think if I had to learn from satoshi code I would have gone mental
258 2011-09-28 02:41:50 <TD> i didn't come up with it
259 2011-09-28 02:42:07 <midnightmagic> "vince durham" came up with it. or at least coded the first example I'd seen.
260 2011-09-28 02:42:11 <TD> satoshi proposed it in a couple of paragraphs in some forum post
261 2011-09-28 02:42:20 <TD> however nobody understood what he was talking about.
262 2011-09-28 02:42:32 <shadders> you wrote the original wiki article explain how it was possible
263 2011-09-28 02:42:38 <TD> eventually we came up with a guess, and he confirmed it was correct
264 2011-09-28 02:42:49 <TD> explained a few other details. i wrote it up on the wiki with lots of explanations
265 2011-09-28 02:43:03 <midnightmagic> ah, really?
266 2011-09-28 02:43:03 <TD> satoshi is clearly a very, very sharp guy. sometimes it's tough to keep up :)
267 2011-09-28 02:43:06 <midnightmagic> well, i didn't know that.
268 2011-09-28 02:43:26 <shadders> ahh... there you go.. you are the official satoshi translator then...
269 2011-09-28 02:43:43 <TD> https://bitcointalk.org/index.php?topic=6197.0
270 2011-09-28 02:43:55 <shadders> making his ideas remotely intelligible ;)
271 2011-09-28 02:44:05 <TD> You have one piece of work.  If you solve it, it will solve a block from both Bitcoin and BitDNS.  In concept, they're tied together by a Merkle Tree.  To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.
272 2011-09-28 02:44:14 <TD> In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal.
273 2011-09-28 02:44:17 <TD> Note that the chains are below this new Merkle Tree.  That is, each of Bitcoin and BitDNS have their own chain links inside their blocks.  This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain.  This is two timestamp servers not sharing a chain.
274 2011-09-28 02:44:57 <TD> these three paragraphs are a LONG way from a description of how to implement :/
275 2011-09-28 02:45:42 <TD> "If you're still worried about it, it's cryptographically possible to make a risk free trade.  The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both.  The second signer can't release one without releasing the other."   ..... -> also a long way from being a useful protocol description. he clearly understood the protocol in question but didn't bother to
276 2011-09-28 02:46:12 <TD> anyway. i need to scavenge some food. back later.
277 2011-09-28 02:46:30 <shadders> later...
278 2011-09-28 02:47:55 <shadders> lol... it's almost like a scripture... the satoshi scrolls... cryptoarcheologists of the future will be discovering new techniques for centuries by poring over his old forum posts and trying to work out what he meant
279 2011-09-28 02:50:15 <midnightmagic> wouldn't it be wonderful of Satoshi was +orc
280 2011-09-28 02:50:41 <Gekz> an orc you say
281 2011-09-28 02:50:46 <Gekz> a magical orc or a retarded orc?
282 2011-09-28 02:51:29 <midnightmagic> no, +orc.
283 2011-09-28 02:58:43 <midnightmagic> http://www.home.aone.net.au/~byzantium/found/found1.html
284 2011-09-28 02:58:52 <midnightmagic> +orc knows crypto
285 2011-09-28 03:00:14 <midnightmagic> And nobody knows who +orc is either.
286 2011-09-28 03:00:54 <midnightmagic> +fravia might've but he's dead now, unfortunately for the world.
287 2011-09-28 03:01:32 <t3a> how bad is this? http://bitcoincharts.com/charts/chart.png?width=1016&m=mtgoxUSD&k=&r=&i=&c=0&s=&e=&Prev=&Next=&v=0&cv=0&ps=0&l=0&p=0&t=C&b=&a1=&m1=10&a2=&m2=25&x=0&i1=&i2=&i3=&i4=&SubmitButton=Draw&
288 2011-09-28 03:01:53 <Gekz> bad gateway
289 2011-09-28 03:25:49 <TD> t3a: that's ok. remember that bitcoin is experiencing what is formally defined as hyperinflation until 2012
290 2011-09-28 03:26:12 <t3a> td, good point
291 2011-09-28 03:26:15 <TD> to keep the price stable requires huge amounts of inbound money, to offset the inflation
292 2011-09-28 03:26:44 <TD> and besides, the $ value of a coin is fairly arbitrary. as a way of making/receiving payments, bitcoin works just as well regardless of what value it has because people just use it as a proxy
293 2011-09-28 03:26:51 <TD> stability is more important than absolute value
294 2011-09-28 03:30:06 <Gekz> 100 times this
295 2011-09-28 03:31:01 <mtrlt> but it's not gonna be very stable.
296 2011-09-28 03:31:48 <t3a> what is the lowest hash value thats been created?
297 2011-09-28 03:33:55 <t3a> looks like this one http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d
298 2011-09-28 04:00:37 <d33tah_> hi guys
299 2011-09-28 04:01:01 <d33tah> hiya ;)
300 2011-09-28 04:01:19 <d33tah> anyone familiar with bitcoin's timing functions?
301 2011-09-28 04:02:00 <d33tah> i have a problem - on my virtual server, my universal time is set incorrectly and I can't change it because that would involve changing the system time, for which I have no privilleges
302 2011-09-28 04:02:40 <d33tah> thus the question - can I somehow hardcode in the sources to offset the clock by 8 hours?
303 2011-09-28 04:22:15 <d33tah> ok, i've found the solution - http://www.code-wizards.com/projects/libfaketime/
304 2011-09-28 04:55:20 <d33tah> guys
305 2011-09-28 04:55:23 <d33tah> i have a bitcoind problem
306 2011-09-28 04:55:42 <d33tah> i'm trying to connect to my bitcoind and all i get is connection reset by peer
307 2011-09-28 04:55:55 <d33tah> i wonder what might be wrong
308 2011-09-28 04:56:00 <neofutur> locally or distant ?
309 2011-09-28 04:56:03 <d33tah> locally
310 2011-09-28 04:57:46 <d33tah> the only thing shown in debug logs is:
311 2011-09-28 04:57:47 <d33tah> ThreadRPCServer ReadHTTP timeout
312 2011-09-28 04:58:31 <neofutur> local network setup problem ?
313 2011-09-28 04:58:57 <d33tah> well, my admin put there some weird firewall
314 2011-09-28 04:59:07 <d33tah> but i can open any port fine and receive messages
315 2011-09-28 05:00:02 <ThomasV> perhaps it's your libfaketime?
316 2011-09-28 05:00:18 <d33tah> hm, nice idea!
317 2011-09-28 05:00:28 <d33tah> i wonder if I can set rpctimeout to 8 hours
318 2011-09-28 05:00:34 <d33tah> :D
319 2011-09-28 05:01:13 <ThomasV> you can also use a cronjob to reset your clock periodically
320 2011-09-28 05:01:14 <CIA-101> bitcoinjs/node-bitcoin-exit: Stefan Thomas master * r843db99 / README.md : Fixed installation instructions. - http://git.io/_E0Hhw
321 2011-09-28 05:01:49 <ThomasV> I did that once with a vps
322 2011-09-28 05:02:03 <d33tah> i can't really 'reset' it
323 2011-09-28 05:02:08 <d33tah> openvz forbids me that
324 2011-09-28 05:02:12 <d33tah> whoa
325 2011-09-28 05:02:18 <d33tah> ThomasV, you're my hero :D
326 2011-09-28 05:02:19 <d33tah> that was it
327 2011-09-28 05:02:40 <ThomasV> I mean resync
328 2011-09-28 05:02:49 <ThomasV> with a remote time server
329 2011-09-28 05:03:15 <d33tah> yeah, i know, ntp or smth
330 2011-09-28 05:03:17 <d33tah> the problem is
331 2011-09-28 05:03:24 <d33tah> i can't change my system date
332 2011-09-28 05:03:25 <d33tah> just can't
333 2011-09-28 05:03:31 <ThomasV> google ntp drift
334 2011-09-28 05:03:44 <ThomasV> and do not configure your vps as a server
335 2011-09-28 05:04:04 <d33tah> what do you mean 'as a server'?
336 2011-09-28 05:04:43 <ThomasV> as a time server, ntpd
337 2011-09-28 05:04:57 <luke-jr> &
338 2011-09-28 05:05:01 <luke-jr> ThomasV: he can't change the clock
339 2011-09-28 05:05:09 <ThomasV> oh
340 2011-09-28 05:05:20 <neofutur> bad hosting -> change hosting :p
341 2011-09-28 05:05:32 <d33tah> well, i like this hosting
342 2011-09-28 05:05:34 <ThomasV> yes, change hosting
343 2011-09-28 05:05:37 <luke-jr> http://lightfoot.dashjr.org/?page=vps
344 2011-09-28 05:05:39 <luke-jr> :p
345 2011-09-28 05:05:42 <d33tah> i got it for free :p
346 2011-09-28 05:06:08 <ThomasV> d33tah: I use cinfu now, cheap, accepts btc
347 2011-09-28 05:06:25 <neofutur> [ps30040]$ date -s "-5 min"
348 2011-09-28 05:06:51 <d33tah> i guess that for bitcoinbounties.org it would be best not to use a hosting associated with bitcoins :P
349 2011-09-28 05:06:59 <neofutur> I also cant change the date on a vps, but i still have no problem with bitcoind
350 2011-09-28 05:07:14 <ThomasV> d33tah: why?
351 2011-09-28 05:07:25 <d33tah> because i keep a wallet there
352 2011-09-28 05:07:37 <d33tah> neofutur: perhaps your date -u is correct
353 2011-09-28 05:07:42 <d33tah> it's not on the hosting i use
354 2011-09-28 05:08:26 <neofutur> https://www.kalyhost.com/?_a=96fc0a3d-7839-49ac-9c76-e14642b8358c accept bitcoins for hosting
355 2011-09-28 05:08:54 <neofutur> ( operated by the same company as mtgox )
356 2011-09-28 05:10:01 <c_k> https://en.bitcoin.it/wiki/Trade#Dedicated.2FVirtual_Server_Hosting
357 2011-09-28 05:10:03 <neofutur> whats your budget for hosting ?
358 2011-09-28 05:10:04 <c_k> loads do
359 2011-09-28 05:10:13 <d33tah> neofutur: 0$
360 2011-09-28 05:10:14 <d33tah> :d
361 2011-09-28 05:10:22 <neofutur> loads of untrusted anonymous :p
362 2011-09-28 05:10:31 <neofutur> d33tah: ok, i cant help you
363 2011-09-28 05:10:36 <d33tah> i guessed so ;)
364 2011-09-28 05:11:04 <c_k> tbh, $7 USD per month for 2GB RAM is neat at chicagovps :) - http://www.lowendbox.com/blog/chicagovps-7-2gb-openvz-vps-in-chicago/
365 2011-09-28 05:11:23 <c_k> explicitly not oversold
366 2011-09-28 05:11:44 <neofutur> + limited monthly bandwidth , or hosted on a dsl line . . .
367 2011-09-28 05:12:24 <c_k> heh, 206.217.141.182 is my ip
368 2011-09-28 05:12:51 <neofutur> yup this chicagovps seems cool, i ll have a look
369 2011-09-28 05:14:35 <c_k> Dupont Fabros Technology, Chicago
370 2011-09-28 05:14:39 <c_k> http://www.dft.com/themes/dft/images/data_centers/DFT_brochure_ch1.pdf
371 2011-09-28 05:14:47 <c_k> doesn't look like a kids closet to me ...
372 2011-09-28 05:15:17 <d33tah> daaamn
373 2011-09-28 05:15:24 <d33tah> the old bitcoind connection takes so long...
374 2011-09-28 05:15:28 <d33tah> need to export the data
375 2011-09-28 05:21:09 <d33tah> how can I  check what address is assigned to a particular bitcoind label?
376 2011-09-28 05:23:54 <d33tah> oh, getaccountaddress
377 2011-09-28 05:28:02 <neofutur> c_k: on the link you gave , the coupon coe wont work / out of stock
378 2011-09-28 05:30:16 <neofutur> so its $24.95, not 7$
379 2011-09-28 05:41:56 <d33tah> luke-jr: read my PM perhaps?
380 2011-09-28 05:44:58 <c_k> neofutur: We are currently out of stock on this item so orders for it have been suspended until more stock is available. For furthur information, please contact us.
381 2011-09-28 05:45:11 <c_k> they usually get more stock pretty quick
382 2011-09-28 05:47:12 <neofutur> they have the same servers in stock , only the coupon code is out of stock . . .
383 2011-09-28 05:55:50 <neofutur> tcatm: would be cool to be able to sort by column on http://bitcoincharts.com/markets/
384 2011-09-28 05:56:06 <neofutur> ie sort by volume or 30day volume
385 2011-09-28 05:59:05 <edcba> ;;bc,mtgox
386 2011-09-28 05:59:05 <gribble> {"ticker":{"high":5.028,"low":4.8219,"avg":4.91348668,"vwap":4.904695491,"vol":18537,"last":4.85,"buy":4.84924,"sell":4.85}}
387 2011-09-28 06:15:17 <d33tah> looks like it'll never reach 10USD back
388 2011-09-28 06:16:29 <neofutur> to me, it looks like some big players want to stabilize it
389 2011-09-28 06:16:58 <neofutur> which is not a bad thing for bitcoin, only for traders and speculation
390 2011-09-28 06:17:16 <ThomasV> a 5k bidwall vanished this morning
391 2011-09-28 06:17:42 <ThomasV> well, the wall is still there, but smaller
392 2011-09-28 06:20:56 <neofutur> http://bitcoincharts.com/charts/mtgoxUSD/accumulated_orderbook.png
393 2011-09-28 06:20:59 <neofutur> not so bad
394 2011-09-28 06:21:31 <ThomasV> yes, but there was another 5k bid this morning
395 2011-09-28 06:21:40 <ThomasV> it was removed
396 2011-09-28 06:21:51 <neofutur> but a little bit offtopic here, I d prefer to continue on ##mtgox-chat
397 2011-09-28 06:22:12 <ThomasV> heh
398 2011-09-28 06:22:29 <ThomasV> I prefer #btc-value
399 2011-09-28 06:31:06 <neofutur> seems an interesting chan
400 2011-09-28 06:34:15 <sipa> bit unstable though
401 2011-09-28 08:09:17 <epscy> hey guys, asked this in #bitcoin but thought i might get a better response here
402 2011-09-28 08:09:32 <epscy> are random numbers used in the mining process?
403 2011-09-28 08:09:54 <epscy> and if there are is there any benefit to using an entropy source over a PRNG?
404 2011-09-28 08:13:54 <neofutur> afaik yes the mining process is random you ll try random hashes until you find one
405 2011-09-28 08:14:18 <neofutur> not sure a better entropy is useful
406 2011-09-28 08:14:28 <neofutur> good question indeed
407 2011-09-28 08:27:25 <sipa> epscy: the nonces are tried one by one in sequential order
408 2011-09-28 08:27:55 <sipa> however, the payout is done to a randomly generated public key
409 2011-09-28 08:28:08 <sipa> which is part of what is hashed in the mining process
410 2011-09-28 08:30:04 <epscy> sipa: ahh thanks that makes sense
411 2011-09-28 08:30:34 <epscy> so it is likely that miners are working on the same nonces?
412 2011-09-28 08:30:52 <epscy> still seems like that would favour faster hashers
413 2011-09-28 08:31:46 <epscy> to the point where the fastest hasher would find all the correct hashes first?
414 2011-09-28 08:32:58 <epscy> ok i think understand now
415 2011-09-28 08:33:26 <epscy> your address is part of what being hashed
416 2011-09-28 08:33:30 <epscy> which is unique
417 2011-09-28 08:39:07 <epscy> sipa: is there any reason why the nonces have to be tried in a sequential order?
418 2011-09-28 08:39:20 <epscy> could a random number be used instead?
419 2011-09-28 08:42:30 <sipa> yes
420 2011-09-28 08:42:33 <sipa> but why bother?
421 2011-09-28 08:42:58 <epscy> i suppose sequential should be faster
422 2011-09-28 08:43:08 <epscy> although probably only very slightly
423 2011-09-28 09:46:05 <Eliel> would there be any sense to introduce a slightly modified standard tx type with the idea that if a tranaction is of that type, it means the "from" addresses in the transaction will work as return addresses?
424 2011-09-28 09:46:48 <Eliel> ideally, the difference would be one bit somewhere that's flipped.
425 2011-09-28 09:47:29 <Eliel> or an added byte, if that's not possible
426 2011-09-28 09:48:18 <sipa> i'm not convinced that's the right solution to the problem
427 2011-09-28 09:49:06 <Eliel> I mean, as it is, if it wasn't for web wallets that mix the addresses, you could just use the from addresses as return addresses.
428 2011-09-28 09:50:13 <sipa> but that means you're standardizing on a system that implies suboptimal behaviour for those who have to rely on web wallets
429 2011-09-28 09:50:50 <Eliel> sipa: it's not impossible to make web wallets work with it.
430 2011-09-28 09:50:58 <sipa> how?
431 2011-09-28 09:51:36 <sipa> you mean by not mixing?
432 2011-09-28 09:52:19 <Eliel> at the simplest, they could simply keep separate wallets for each user. But even with mixing, as long as they're not recycling the receiving addresses they use, they should just be able to mark spent addresses as owned by the user whose send it was.
433 2011-09-28 09:52:49 <phantomcircuit> keeping a different wallet for each user is completely out of the question with the current implementation
434 2011-09-28 09:52:57 <sipa> i believe bitcoin transactions shouldn't be more than moving amounts of bitcoin around
435 2011-09-28 09:53:24 <sipa> and that anything beyond does not belong in the block chain, but in an out-of-band protocol outside of bitcoin
436 2011-09-28 09:55:19 <sipa> (see https://gist.github.com/1237788)
437 2011-09-28 09:55:26 <Eliel> sipa: I think it's reasonably important to have a working automatic way of returning bitcoins to the sender that isn't dependant on out of band communication outside bitcoin.
438 2011-09-28 09:55:37 <Eliel> the out of band can't be guaranteed to be there.
439 2011-09-28 09:56:19 <sipa> Eliel: see my proposal :)
440 2011-09-28 10:01:33 <Eliel> oh, you intend to make your out-of-band protocol the standard way of doing bitcoin transactions.
441 2011-09-28 10:01:52 <Eliel> that could work.
442 2011-09-28 10:02:14 <sipa> not necessarily mine - i just argue that using something more than a static txout template would have many advantages
443 2011-09-28 10:02:34 <Eliel> yes, I agree.
444 2011-09-28 12:38:59 <BlueMatt> gavinandresen: ping
445 2011-09-28 12:39:09 <gavinandresen> BlueMatt: what's up
446 2011-09-28 12:40:10 <BlueMatt> gavinandresen: me, devrandom and sipa discussed briefly moving/copying/forking https://github.com/devrandom/bitcoin-release into bitcoin/bitcoin-release to collect gitian sigs and make gitian release process more "official"
447 2011-09-28 12:40:15 <BlueMatt> would be nice to do that...
448 2011-09-28 12:43:10 <gavinandresen> Can one of you write up what the process for managing that more official tree would be?  I have no problem creating it, I just don't want it to become an unloved orphan
449 2011-09-28 12:43:39 <gavinandresen> (stuff like why it exists, what it is used for, who has access to read/write it, etc)
450 2011-09-28 12:46:18 <gavinandresen> Also: I'm not sure "bitcoin-release" is a good name, I'd expect to either get release binaries from there or see released source code...
451 2011-09-28 12:49:57 <BlueMatt> gavinandresen: whatever you call it, maybe bitcoin-gitian-sigs or smth...
452 2011-09-28 12:59:26 <AlexWaters> sipa: hey, can you tell me how I would run the unit test you wrote for 524?
453 2011-09-28 12:59:48 <AlexWaters> sipa: i didn't see it in any commits
454 2011-09-28 13:00:16 <AlexWaters> ;;seen sipa
455 2011-09-28 13:00:17 <gribble> sipa was last seen in #bitcoin-dev 2 hours, 58 minutes, and 2 seconds ago: <sipa> not necessarily mine - i just argue that using something more than a static txout template would have many advantages
456 2011-09-28 13:07:54 <sipa> AlexWaters: build test_bitcoin, run it :)
457 2011-09-28 13:09:00 <sipa> AlexWaters: it's in the third commit of #524
458 2011-09-28 13:14:20 <AlexWaters> oh weird, I didn't realize you could update like that. thanks - didn't see it.
459 2011-09-28 13:14:30 <sipa> update a pull request?
460 2011-09-28 13:14:50 <AlexWaters> yeah, I thought it would have added another comment with the new commit(s)
461 2011-09-28 13:15:00 <sipa> github groups them together
462 2011-09-28 13:15:27 <sipa> and you can do force pushes, overwriting earlier commits
463 2011-09-28 13:17:02 <tcatm> AlexWaters: do we have something to announce proposed changes (like deprecating "midstate" in getwork, see mailing list)? maybe we could have a simple roadmap on bitcoin.org?
464 2011-09-28 13:18:56 <MacRohard> can't the midstate thing be reimplemented using openssl?
465 2011-09-28 13:19:58 <BlueMatt> gavinandresen: https://github.com/bitcoin/bitcoin/pull/536
466 2011-09-28 13:20:10 <BlueMatt> (assuming repo is bitcoin-gitian-sigs)
467 2011-09-28 13:20:46 <tcatm> MacRohard: yes. that's what my pull request does. still, it's redundant information and can be easily calculated more efficiently on the miner.
468 2011-09-28 13:21:52 <MacRohard> tcatm, yea.. but people are using it. if it's easy to keep the functionality it probably should be.
469 2011-09-28 13:22:15 <AlexWaters> tcatm: the mailing list would be the best place to announce changes, what would the roadmap on bitcoin.org look like?
470 2011-09-28 13:22:45 <tcatm> AlexWaters: 0.5 - QT, 0.6 - "midstate" removed, 0.7 - other big change?
471 2011-09-28 13:23:09 <BlueMatt> tcatm: is midstate removal really that big of a change that it gets its own version?
472 2011-09-28 13:23:15 <AlexWaters> tcatm: Gavin has talked about that in the forum, let me try to find the post
473 2011-09-28 13:23:16 <gavinandresen> n
474 2011-09-28 13:23:16 <sipa> i don't think so
475 2011-09-28 13:23:40 <BlueMatt> imho just remove midstate early on in a release cycle and give people a chance to update
476 2011-09-28 13:23:40 <tcatm> BlueMatt: no, but I don't want to remove it too soon so miners have time to update their code
477 2011-09-28 13:23:51 <BlueMatt> ie do it now...
478 2011-09-28 13:23:55 <BlueMatt> or right after 0.5 release
479 2011-09-28 13:23:55 <sipa> we could discuss a roadmap for so future changes, which can include deprecation/removal of certain features
480 2011-09-28 13:24:03 <gavinandresen> no.  speaking of removing stuff, we should remove the deprecated RPC methods
481 2011-09-28 13:24:09 <BlueMatt> just gonna say that
482 2011-09-28 13:24:52 <AlexWaters> https://bitcointalk.org/index.php?topic=44330.msg529670#msg529670
483 2011-09-28 13:25:08 <AlexWaters> so that's all I know...
484 2011-09-28 13:25:51 <sipa> gavinandresen: how far would you consider going in 0.5.0 regarding support for multisig?
485 2011-09-28 13:26:18 <sipa> i'd say make a set of transactions pass IsStandard(), without implemented solver
486 2011-09-28 13:26:44 <gavinandresen> I was playing with unit tests for my simple three-more-standard transactions this morning
487 2011-09-28 13:28:39 <gavinandresen> I'd love to hear TD and genjix's and Stefan's takes on the different IsStandard proposals, since they'll eventually have to implement them
488 2011-09-28 13:29:04 <BlueMatt> too bad TD[gone] is gone
489 2011-09-28 13:29:21 <sipa> the only reason for not letting something pass IsStandard() is fear of implementation bugs, right?
490 2011-09-28 13:30:42 <BlueMatt> that and what goes along with it (dos, etc)
491 2011-09-28 13:31:13 <sipa> gavinandresen: which types of transactions a client supports (i.e., can use as inputs) can be client-dependent
492 2011-09-28 13:32:02 <gavinandresen> sipa: sure, but we want to encourage a standard way of doing things so theymos doesn't go crazy showing the 16 different forms of escrow transaction on block explorer
493 2011-09-28 13:32:07 <sipa> agree
494 2011-09-28 13:32:32 <gavinandresen> ... and so security researchers have a small set of cases to reason about
495 2011-09-28 13:32:45 <sipa> but there is no problem in making IsStandard broader than what the main client can solve
496 2011-09-28 13:33:02 <BlueMatt> except relay issues
497 2011-09-28 13:33:03 <sipa> as long as you trust there are no implementation bugs which verifying those transactions
498 2011-09-28 13:33:30 <gavinandresen> what do you mean by "can solve" ?  You mean extract the keys needed to spend a transaction?
499 2011-09-28 13:33:51 <sipa> "can solve" = be able to construct a txin script using such an output
500 2011-09-28 13:35:01 <gavinandresen> Ah.  No, I think only transactions that the main client can spend should be allowed-- I'd want to see the figure-out-my-wallet-balance code AND the IsStandard() checks (and the choose-coins-to-spend) all updated at the same time.
501 2011-09-28 13:35:11 <casascius> some multisig situations can be forseen to be where the client cannot solve it, but might still recognize that it is its own address (e.g. (A AND B) OR C) when client only has A
502 2011-09-28 13:35:33 <gavinandresen> ... but not give the standard client a way of actually generating multisigs for the first release
503 2011-09-28 13:36:07 <sipa> gavinandresen: i don't agree; for certain escrow transactions you'll need special negotiation with other parties, which is something that shouldn't necessarily go in the main client
504 2011-09-28 13:37:01 <BlueMatt> I would argue for adding to IsStandard in a release prior to the spend/solve code so that stuff gets relayed earlier
505 2011-09-28 13:37:02 <casascius> i have always thought that multisigs would often involve a third party provider, and that third party provider would be in a position to provide a patched client that integrated their multisig functionality (i.e. which would also include rpc's to the multisig provider to get the foreign signature)
506 2011-09-28 13:37:10 <BlueMatt> (though I would have said put that in 0.4...)
507 2011-09-28 13:37:17 <sipa> also, IsStandard() can already legally be bypassed by submitting to a pool that allows them
508 2011-09-28 13:38:05 <gavinandresen> casascius: that's a red herring for what I'd like to see happen ASAP
509 2011-09-28 13:39:04 <BlueMatt> one could define an api and you fill in the provider settings...
510 2011-09-28 13:39:11 <BlueMatt> instead of patched clients
511 2011-09-28 13:39:22 <gavinandresen> sipa:  I want IsStandard plus recognition-of-multisigs-you-can-spend in place at the same time because I'm worried that a complicated multisig solution might make things like GetBalance() or -rescan unbearably slow
512 2011-09-28 13:39:55 <sipa> gavinandresen: i don't see why those are related
513 2011-09-28 13:40:21 <genjix> hey
514 2011-09-28 13:40:25 <gavinandresen> sipa: Have you ever performance profiled GetBalan
515 2011-09-28 13:40:54 <sipa> not really
516 2011-09-28 13:41:04 <gavinandresen> sipa: if I recall correctly, it spends most of its time extracting addresses from transactions and figuring out if you have the keys
517 2011-09-28 13:41:28 <gavinandresen> (I may be confusing it with -rescan,though)
518 2011-09-28 13:41:50 <gavinandresen> genjix : hey.  Do you have an opinion on the two multisig proposals?
519 2011-09-28 13:42:25 <sipa> gavinandresen: the way i see it: you have a client, that client supports a number of incoming transaction types; it will only produce addresses (or whatever equivalent is used to construct a transaction to it) that match those types of transactions, so there is no way you can receive a transaction which is in a form your client doesn't support
520 2011-09-28 13:42:30 <gavinandresen> https://gist.github.com/39158239e36f6af69d6f   versus https://gist.github.com/dba89537d352d591eb36
521 2011-09-28 13:42:42 <genjix> yep i saw them a while back
522 2011-09-28 13:42:47 <genjix> I think I preferred yours
523 2011-09-28 13:42:48 <sipa> however, a larger set of transaction types may be considered safe, and can reliably be verified without risk for DOS by the client
524 2011-09-28 13:42:53 <sipa> and those pass IsStandard
525 2011-09-28 13:43:04 <genjix> the other one was needlessly more complex, but i'd have to re-read them to be sure.
526 2011-09-28 13:43:17 <genjix> gavinandresen: btw i found a few bugs in bitcoin
527 2011-09-28 13:43:24 <wardearia> GetBalan
528 2011-09-28 13:43:45 <genjix> nAskedForBlocks is uninitialized
529 2011-09-28 13:43:47 <gavinandresen> genjix: great, put them in the issue tracker or send them via private email (if they're exploitable)
530 2011-09-28 13:43:58 <genjix> nah they're very minor
531 2011-09-28 13:44:19 <gavinandresen> genjix: ... or submit patches to fix them...
532 2011-09-28 13:44:41 <genjix> was 3 things... damn i forgot 2 of them
533 2011-09-28 13:45:10 <genjix> CNode::Subscribe isn't used anywhere. any idea what the original intention of that was?
534 2011-09-28 13:46:34 <gavinandresen> genjix: Satoshi intended to implement some funky super-anonymous meet-in-the-middle scheme for merchants and customers to connect
535 2011-09-28 13:47:04 <genjix> meh i thought it was something like tracking of messages
536 2011-09-28 13:47:15 <genjix> weird that bitcoin is a message based protocol over TCP
537 2011-09-28 13:48:09 <casascius> in these multisig proposals, what is the expected behavior of the client when the client has one but not all of the keys for an incoming transaction?  ignore it?  or show it as "encumbered" or something similar
538 2011-09-28 13:48:21 <gavinandresen> casascius: Initially: ignore it
539 2011-09-28 13:48:47 <gavinandresen> (if sipa gets his way, then even if you have all the keys it'll be initially ignored....)
540 2011-09-28 13:49:18 <genjix> what are the arguments for hiding it?
541 2011-09-28 13:49:51 <gavinandresen> casascius: eventually:  I dunno, what's the right thing for the UI to do in that case?  "Here's some money you can't spend" ?
542 2011-09-28 13:50:01 <sipa> gavinandresen: it's not hiding; it's not supporting
543 2011-09-28 13:50:04 <sipa> eh, genjix
544 2011-09-28 13:50:20 <casascius> gavinandresen: yeah exactly....thats what paypal does when you sell things on ebay
545 2011-09-28 13:50:28 <sipa> and obviously for the types of transaction you do support (like the onles being discussied now), it will support them, and it will show them
546 2011-09-28 13:50:55 <casascius> gavinandresen: and that's what your bank does just right after you deposit funds (e.g. "available balance" != "balance")
547 2011-09-28 13:51:09 <tcatm> gavinandresen: I made a pull request to remove all deprecated RPCs (not midstate, though)
548 2011-09-28 13:51:27 <gavinandresen> tcatm: cool, thanks
549 2011-09-28 13:51:35 <sipa> but more interesting types of multisig transactions are only useful within a more complex series of actions (see the contracts page), that are not just "you receive a transaction, and use the resulting funds"
550 2011-09-28 13:52:00 <gavinandresen> scope creep
551 2011-09-28 13:52:08 <genjix> sipa: i don't think so. for me the most interesting use would be holding the funds in a group
552 2011-09-28 13:52:16 <genjix> not trusting a single treasurer
553 2011-09-28 13:52:35 <sipa> genjix: sure, and that is a type of transaction that can very well standardized and supported by all clients
554 2011-09-28 13:53:20 <genjix> for me implementing any multisig scheme is easy peasy. the multisig part is just a generalisation of checksig, and the other ops are not hard.
555 2011-09-28 13:53:45 <genjix> so whichever standard is chosen, is fine. i'm more inclined though to the simpler/clearer one
556 2011-09-28 13:54:21 <sipa> i just think that IsStandard shouldn't be used as a way for preventing known-to-be-useful types of transactions from the network, as long as you've verified that they can reliably be checked by the client
557 2011-09-28 13:54:31 <casascius> one feasible way I think it could work, is if you have funds but only "some" of the keys, that you could "spend" the funds, but what you'd get as a result is a cut-n-paste base64-encoded block of the transaction that you could forward to somebody else.  and then if you were to import a pre-signed transaction for which you had the remaining keys, you would have the option to "sign & submit"
558 2011-09-28 13:54:36 <sipa> genjix: checksig and solver are two different things
559 2011-09-28 13:54:52 <genjix> sipa: yep i'd prefer a proper scripting system, not disabled
560 2011-09-28 13:55:03 <genjix> sipa: ?
561 2011-09-28 13:55:37 <sipa> genjix: i'm arguing in favor of relaxing IsStandard(), even for types of transactions that the main client can't use as input
562 2011-09-28 13:55:38 <genjix> ah, by multisig part, i meant multisig op
563 2011-09-28 13:55:46 <luke-jr> d33tah: no PM from you
564 2011-09-28 13:55:53 <sipa> but i understand gavinandresen's view
565 2011-09-28 13:56:13 <genjix> i see, i got told about this convo because of which multisig scheme to choose
566 2011-09-28 13:56:29 <gavinandresen> Before opening up the IsStandard floodgates I think two things need to happen:  1)  fast headers-only initial download.  So block chain size isn't an issue for new users.
567 2011-09-28 13:56:29 <genjix> but yep relaxing the scripting system is the way forwards in general
568 2011-09-28 13:56:47 <genjix> sipa: even a point scoring system could work
569 2011-09-28 13:57:00 <genjix> so checksig is 20 points, add is 1 point
570 2011-09-28 13:57:00 <sipa> gavinandresen: that's reasonable
571 2011-09-28 13:57:12 <gavinandresen> ... and 2) un-hard-code the transaction fee system, so miners and clients can work out what transaction fees
572 2011-09-28 13:57:23 <genjix> if sum(point score) > X: reject tx
573 2011-09-28 13:58:13 <sipa> genjix: that's possible, comparable to the current DOS protection system
574 2011-09-28 13:58:21 <genjix> gavinandresen: then you'll need to re-enable the sequence, no?
575 2011-09-28 13:58:35 <sipa> nsequence is something else
576 2011-09-28 13:58:38 <genjix> sipa: yep except the question is how to random various operations.
577 2011-09-28 13:59:14 <genjix> well if you let users set their own fees, then people are going to try 0 fee transactions that are never picked up
578 2011-09-28 13:59:31 <genjix> so you'd want to allow people to replace old txs that arent getting picked up
579 2011-09-28 13:59:38 <sipa> you need a way to measure how long a tx will take to get confirmed
580 2011-09-28 13:59:44 <sipa> at least estimate
581 2011-09-28 14:00:13 <genjix> it could be subjective
582 2011-09-28 14:01:10 <tcatm> do we have a short document describing the mining process (which arrays to byteswap, how to format buffers)?
583 2011-09-28 14:01:12 <genjix> tbh a checksig vs an add is like 10000+ vs 1
584 2011-09-28 14:01:37 <gavinandresen> yes, that's why I want miners to start deciding how much transactions REALLY cost
585 2011-09-28 14:01:58 <JFK911> why let pools decide that
586 2011-09-28 14:02:12 <genjix> here's an idea.
587 2011-09-28 14:02:15 <genjix> recommend a few
588 2011-09-28 14:02:17 <genjix> fee
589 2011-09-28 14:02:29 <genjix> but show a warning if they try to override it with a lower number
590 2011-09-28 14:02:34 <sipa> i really *really* hope that when we push for configurable fees in miners, they don't all set them to "accept everything"
591 2011-09-28 14:02:45 <genjix> why?
592 2011-09-28 14:03:03 <tcatm> sipa: I'm pretty sure some will do that
593 2011-09-28 14:03:08 <sipa> some is not a problem
594 2011-09-28 14:03:10 <genjix> that's great.
595 2011-09-28 14:03:19 <sipa> but it's in their best interest to allow as much as possible
596 2011-09-28 14:03:49 <sipa> and it is in the best interest of the network to have fees correspond as much as possible with real costs (for all full nodes, not only miners, who are the ones who get paid)
597 2011-09-28 14:04:10 <tcatm> maybe we can calculate the fee automatically similiar to how we calculate difficulty?
598 2011-09-28 14:04:16 <casascius> here is a crazy idea: implement a little script interpreter (e.g. Lua) which allows the user to set the "include/notinclude" decision, and allow people to trade their own scripts via their clipboards, so being able to set your price for mining doesn't require compiling anything
599 2011-09-28 14:04:39 <genjix> sipa: why does it matter?
600 2011-09-28 14:04:56 <sipa> genjix: it may not matter
601 2011-09-28 14:04:57 <genjix> block reward is subsidising txs anyway
602 2011-09-28 14:05:02 <sipa> that's the problem
603 2011-09-28 14:05:06 <sipa> block reward pays the miners
604 2011-09-28 14:05:09 <sipa> but nobody else
605 2011-09-28 14:05:21 <genjix> it's not a big deal.
606 2011-09-28 14:05:25 <sipa> for now, no
607 2011-09-28 14:05:33 <genjix> well then :)
608 2011-09-28 14:05:42 <sipa> anyway
609 2011-09-28 14:06:26 <luke-jr> casascius: QtScript? :D
610 2011-09-28 14:06:37 <sipa> i don't think you need to make it that complex
611 2011-09-28 14:06:48 <sipa> that will make it hard to estimate time-to-inclusion too
612 2011-09-28 14:07:12 <casascius> luke-jr: i'm unfamiliar with it, but if it worked, i couldn't complain
613 2011-09-28 14:07:25 <luke-jr> casascius: it's an ECMAScript implementation
614 2011-09-28 14:07:51 <sipa> anyway, i'm off for a while
615 2011-09-28 14:08:02 <luke-jr> unfortunately, the problem with any scripting language is that it will be limited to making decisions periodically at best
616 2011-09-28 14:08:34 <luke-jr> ie, there'd be no way to setup a rule "accept this at a discount for the first hour after we see it, but then stop accepting it"
617 2011-09-28 14:11:27 <phantomcircuit> genjix, tcatm a properly constructed headers only client should be able to process very large numbers of transactions fairly cheaply
618 2011-09-28 14:11:52 <phantomcircuit> i've noticed that a lot of things that happen in bitcoind are far from optimal
619 2011-09-28 14:12:36 <genjix> yeah no shit
620 2011-09-28 14:12:50 <phantomcircuit> <3 genjix
621 2011-09-28 14:13:43 <gavinandresen> I'd say "patches welcome" but I know that wouldn't get anywhere with you two....
622 2011-09-28 14:14:37 <phantomcircuit> lol
623 2011-09-28 14:15:04 <genjix> start with the freecoin branch, we put lots of things in there (build system, python/java/lua/perl bindings, strings in rpc, rpc immediate initialisaton, ...)
624 2011-09-28 14:15:05 <phantomcircuit> most of the things which are sub optimal are almost certainly going to break other things by fixing them
625 2011-09-28 14:15:44 <gavinandresen> fixing a car when it is running is definitely harder than one you're building from scratch
626 2011-09-28 14:15:48 <genjix> but lots of small things can be improved in bitcoin, like the merkle root function or the bignum implementation
627 2011-09-28 14:16:10 <luke-jr> gavinandresen: "patches welcome" is quite often not true of bitcoind mainline
628 2011-09-28 14:16:58 <genjix> well it's a difference in ideas, which i'm cool with
629 2011-09-28 14:17:06 <genjix> like upstream vs downstream
630 2011-09-28 14:17:28 <luke-jr> gavinandresen: btw, kinda up in the air whether your "DoSprevention" code should be merged to stable or not (it's on the boundary of bugfix and feature); what do you think?
631 2011-09-28 14:17:47 <luke-jr> I'm leaning toward omitting it, due to the higher risk of potential bugs
632 2011-09-28 14:18:21 <BlueMatt> Id say omit
633 2011-09-28 14:18:31 <genjix> and i did try for a long while to add these features to mainline, but it's annoying to be stone-walled all the time.
634 2011-09-28 14:21:44 <gavinandresen> genjix: stonewalled by me or by Satoshi?  I'll admit I've been super conservative about changes because it is way too easy to screw up and break important things unintentionally
635 2011-09-28 14:22:28 <gavinandresen> (and I'll freely admit I don't know the code inside-out-and-backwards)
636 2011-09-28 14:23:00 <tcatm> IMHO new features should live in their own branches until they are a stable and well tested and are merged in small steps so they are easy to review. they are also separate from bug fixes (those should be as small as possible and may contain code that will become obsolete soon as part of a better implementation of the "broken" feature)
637 2011-09-28 14:23:04 <genjix> want to make an omelette, then you have to crack some eggs
638 2011-09-28 14:23:23 <kjj> tcatm: that's a very good idea, but might be hard to do in practice
639 2011-09-28 14:23:44 <luke-jr> nothing is ever perfectly stable
640 2011-09-28 14:24:37 <luke-jr> wallet import/export has been fairly stable for some time, and not merged yet IIRC because of the risk some n00b uses it wrong
641 2011-09-28 14:25:11 <luke-jr> despite the fact that it only has a JSON-RPC interface, which is explicitly for webapps, not n00b users
642 2011-09-28 14:25:32 <gavinandresen> wallet import/export hasn't been merged yet because sipa says there are still bugs.
643 2011-09-28 14:26:16 <luke-jr> O.o
644 2011-09-28 14:27:28 <CIA-101> bitcoin: Matt Corallo master * r4572358 / doc/release-process.txt : Update release-process.txt with gitian release instructions. - http://git.io/BLeF9A
645 2011-09-28 14:27:29 <CIA-101> bitcoin: Update release-process.txt with gitian release instructions. - http://git.io/bHlSlA
646 2011-09-28 14:37:37 <casascius> i had reported an unfixed bug in wallet import/export two days ago, he has a fix for it now that worked for me (though that's not to say there is nothing else wrong)
647 2011-09-28 14:38:38 <luke-jr> would be cool to run bitcoind through that LVMM thing
648 2011-09-28 14:39:13 <luke-jr> http://llvm.org/pubs/2008-12-OSDI-KLEE.pdf
649 2011-09-28 14:39:34 <gavinandresen> casascius: that was key import/export, wasn't it?
650 2011-09-28 14:40:22 <gavinandresen> (sipa has two pulls pending, key import/export and full wallet import/export)
651 2011-09-28 14:44:53 <gmaxwell> luke-jr: KLEE is ... mostly a pita.  It would be useful to pull out small parts of bitcoin (e.g. unit tests) through it.
652 2011-09-28 14:45:25 <gmaxwell> But good luck getting it working, I had to setup a VM to match their linux distro of choice the last time I screwed with it.
653 2011-09-28 14:46:39 <gmaxwell> zzuf + valgrind is a more pratical tool. E.g. setup a node in valgrind (patch openssl first) with -connect to a single basteon node and use zzuf on the socket. Remove the 'crc' check on the protocol messages.
654 2011-09-28 14:56:29 <jrmithdobbs> gmaxwell: doesn't your distro's valgrind package have the proper ignores for openssl by default? ;p
655 2011-09-28 14:56:35 <casascius> gavinandresen: yeah that was key import/export only
656 2011-09-28 14:56:46 <casascius> my bad
657 2011-09-28 14:57:43 <gmaxwell> jrmithdobbs: it's not possible openssl splatters uninitilized tractable memory into its output.. where it triggers branches in the application code.
658 2011-09-28 15:05:44 <CIA-101> libbitcoin: genjix * rbbd01f83b797 / (3 files in 3 dirs): One line implementation of CBigNumber::set_uint64 :)
659 2011-09-28 16:14:14 <helo> how often do transactions with one confirmation get overturned by a competing block?
660 2011-09-28 16:14:29 <helo> i assume it never happens after more than one confirmation...
661 2011-09-28 16:14:52 <imsaguy2> there's a reason that the bitcoin.org version waits until 6
662 2011-09-28 16:15:00 <helo> not that it could not, but that it in practice does not occur
663 2011-09-28 16:17:01 <imsaguy2> it becomes easier to do as difficulty drops
664 2011-09-28 16:17:22 <helo> are there any statistics available?
665 2011-09-28 16:19:48 <phantomcircuit> helo, i believe 6 was chosen because that's the longest known block chain reorganization
666 2011-09-28 16:19:53 <phantomcircuit> but that happened a long time ago
667 2011-09-28 16:20:00 <tcatm> phantomcircuit: wrong
668 2011-09-28 16:20:40 <phantomcircuit> care to flesh that out?
669 2011-09-28 16:22:38 <tcatm> bitcoin.pdf 11. Calculations
670 2011-09-28 16:23:00 <phantomcircuit> the chart?
671 2011-09-28 16:23:23 <phantomcircuit> i dont remember seeing a specific reference to 6
672 2011-09-28 16:24:42 <helo> it apparently is where the "long tail" of the poisson distribution begins
673 2011-09-28 16:27:55 <phantomcircuit> tcatm, honestly anybody who doesn't trust the larger mining pools should be waiting for > 10 blocks
674 2011-09-28 16:28:00 <tcatm> yep. I think satoshi assumed an attacker might easily have about 10..15% of the network and thus 6 confirmations would be enough to make an  successful attack unlikely (<0.1%)
675 2011-09-28 16:29:10 <imsaguy2> but if a person could maintain a sustained 10-15% of the network, you could continue to plug at it
676 2011-09-28 16:29:49 <helo> is there any problem with using the least significant digits of the fee and transfer amount to encode data?
677 2011-09-28 16:30:05 <tcatm> helo: yes. lots of small change
678 2011-09-28 16:30:32 <tcatm> and it will break once bitcoins are worth a lot more
679 2011-09-28 16:31:23 <helo> that seems acceptable :)
680 2011-09-28 16:32:22 <gavinandresen> helo: what data do you want to encode?  There are much cooler ways of hiding data in the block chain, like picking a particular value for the 'random' nonce used for signatures....
681 2011-09-28 16:32:53 <helo> right... i was just thinking that may be a better idea. would just take longer
682 2011-09-28 16:34:19 <helo> for now it may not be worth the extra effort of trying to generate a suitable signature, but in the future it may be
683 2011-09-28 16:35:04 <gavinandresen> well, using the amounts will make it obvious to anybody who cares to look that you're doing SOMETHING mysterious.
684 2011-09-28 16:39:59 <ThomasV> oh, it's cute!
685 2011-09-28 16:42:20 <helo> encoding the data in the amounts allows the receiving party (via bitcoin qr generation) to be solely responsible for both encoding and decoding it consistently. maybe a better alternative meeting that requirement would be for the requester to generate receiving addresses that contained the data.
686 2011-09-28 16:45:58 <ThomasV> the qt gui is very nice. did it ship with 0.4 ?
687 2011-09-28 16:46:25 <tcatm> no, it will be in 0.5
688 2011-09-28 16:49:51 <ThomasV> hmm, I guess wallet encryption is not handled by the gui. can I safely encrypt my wallet using the qt gui ?
689 2011-09-28 16:50:29 <ThomasV> well, let's see :-)
690 2011-09-28 16:54:47 <Blitzboom> wallet goes poof
691 2011-09-28 16:54:49 <Blitzboom> :P
692 2011-09-28 16:59:12 <ThomasV> ok, I really like that gui. just sent a payment, it asked me for my passphrase at that moment
693 2011-09-28 16:59:28 <ThomasV> the only thing that I find annoying is the decimal point
694 2011-09-28 17:01:48 <Blitzboom> the GUI includes new units such as mBTC, doesnt it?
695 2011-09-28 17:02:54 <jrmithdobbs> where is qt tree / os x build instructions?
696 2011-09-28 17:03:50 <ThomasV> jrmithdobbs: git pull; qmake; make
697 2011-09-28 17:04:10 <jrmithdobbs> ThomasV: it's in head now?
698 2011-09-28 17:04:16 <ThomasV> Blitzboom: yes it does, but that just moves the decimal point elsewhere
699 2011-09-28 17:04:22 <ThomasV> jrmithdobbs: yes
700 2011-09-28 17:05:05 <jrmithdobbs> ThomasV: is that seriously all the docs? needs boost/miniupnpc/qt anything else?
701 2011-09-28 17:05:26 <ThomasV> jrmithdobbs: I did not find any doc
702 2011-09-28 17:05:40 <ThomasV> I compiled without upnp
703 2011-09-28 17:06:10 <ThomasV> and then I figured out that the .pro was in the upper dir, not src
704 2011-09-28 17:06:47 <ThomasV> I hope someday it uses configtools
705 2011-09-28 17:07:00 <Joric> just compiled qt win32 build of the main branch with upnp and stuff, wasn't easy
706 2011-09-28 17:07:45 <tcatm> I wish I had VMs for compiling linux, win and osx binaries. and maybe even VisualStudio on windows
707 2011-09-28 17:07:46 <Joric> current version of qt sdk refuses to build it had to download the older one
708 2011-09-28 17:08:39 <Joric> used this one ftp://ftp.qt.nokia.com/qtsdk/qt-sdk-win-opensource-2010.05.exe
709 2011-09-28 17:09:53 <Joric> also there was no prebuilt miniupnpc in deps for some reason like upnp is not important
710 2011-09-28 17:10:08 <ThomasV> hmm, the encrypted wallet only encrypts the private keys ; the rest is not encrypted. so I would need to encrypt it again before I put it on my remote backup storage
711 2011-09-28 17:10:57 <tcatm> yes, that feature is mostly to avoid spending coins "by accident"
712 2011-09-28 17:11:12 <Joric> it's so ugly i want to scoop my eyes out http://img827.imageshack.us/img827/1908/bitcoinwallet2011092901.png
713 2011-09-28 17:11:38 <ThomasV> no, it's not ugly
714 2011-09-28 17:12:21 <ThomasV> I was irritated by the plain "xyzt confirmations" written on each line
715 2011-09-28 17:14:16 <ThomasV> it was a pure waste of space
716 2011-09-28 17:14:29 <Joric> that shapeless green check irritates even more
717 2011-09-28 17:15:48 <ThomasV> it's a question mark when the tx is unconfirmed
718 2011-09-28 17:16:29 <tcatm> It should be (red x), 1, ... 9, (green check)
719 2011-09-28 17:16:56 <ThomasV> oh, now it is a clock (1 confirmation)
720 2011-09-28 17:18:38 <ThomasV> I wish it could encrypt the whole wallet, not just the keys, as an extra safety measure. a wallet contains private information
721 2011-09-28 17:18:56 <gmaxwell> ThomasV: then use disk encryption, thats what thats for.
722 2011-09-28 17:19:20 <gmaxwell> It's _very_ good that the wallet doesn't encrypt the whole thing, if it did the key would have to be in memory 100% of the time bitcoin was running.
723 2011-09-28 17:19:41 <gmaxwell> The way it currently works you can leave bitcoin running and you only need to provide your key when you send money and it can forget it right after.
724 2011-09-28 17:19:45 <ThomasV> no it would not
725 2011-09-28 17:20:14 <gmaxwell> The key or the same plaintext data.
726 2011-09-28 17:20:25 <luke-jr> ThomasV: what "else" do you want excrypted?
727 2011-09-28 17:20:25 <ThomasV> gmaxwell: you can encrypt the whole thing, and ask again for passphrase when doing a tx
728 2011-09-28 17:20:27 <luke-jr> encrypted*
729 2011-09-28 17:20:41 <luke-jr> ThomasV: the only thing besides the private keys is the public keys
730 2011-09-28 17:20:48 <luke-jr> ThomasV: and it needs the public keys to handle p2p traffic
731 2011-09-28 17:20:51 <log0s> i created an encrypted keystore for my private keys so i didn't have to deal with that nonsense
732 2011-09-28 17:20:54 <gmaxwell> ThomasV: you need to know the other content of your wallet to know your balance, know what txn you have, know when a new txn is yours, etc.  These are the only things not encrypted.
733 2011-09-28 17:20:56 <ThomasV> luke-jr: no, there's labels, etc
734 2011-09-28 17:21:10 <luke-jr> ThomasV: needs those too
735 2011-09-28 17:21:11 <gmaxwell> ThomasV: you need those in order to simply run the client, to see your balance and such.
736 2011-09-28 17:21:26 <ThomasV> gmaxwell: what is your point?
737 2011-09-28 17:21:28 <gmaxwell> (and for the internal accounting to update those balances as txn come in)
738 2011-09-28 17:21:39 <tcatm> encrypting labels and comments would be a good idea
739 2011-09-28 17:21:59 <luke-jr> tcatm: if the labels are encrypted, you can't do the accounting as transactions come in
740 2011-09-28 17:22:30 <tcatm> luke-jr: yes, you could. you just won't be able to see the label in cleartext
741 2011-09-28 17:22:32 <gmaxwell> tcatm: all you could do is obsecure their text. .. and even with that you'd then have constant pressure to keep the key data available just to see the balances.  Comments might have a better argument.
742 2011-09-28 17:22:48 <luke-jr> tcatm: oh, I get it
743 2011-09-28 17:23:07 <ThomasV> gmaxwell: I used to encrypt my wallet with a script that decrypts, launches the gui, and encrypts it back when I am done. don't tell me that I should use disk encryption...
744 2011-09-28 17:23:09 <tcatm> but yes, FDE would be the easier and probably better solution
745 2011-09-28 17:23:18 <gmaxwell> It would mean the user would have to present their key signficantly more often, increasing the oppturnties for it to tget taken.
746 2011-09-28 17:23:31 <ThomasV> oh come on...
747 2011-09-28 17:23:35 <luke-jr> ThomasV: that must be painful
748 2011-09-28 17:23:47 <ThomasV> why ?
749 2011-09-28 17:23:48 <gmaxwell> ThomasV: thats a perfectly fine thing to do, and you can still do that.  Wallet encrpytion does something that what you were doing _cannot_ do.
750 2011-09-28 17:24:06 <ThomasV> I know I can still do that
751 2011-09-28 17:24:34 <ThomasV> but what I was doing might be useful for more people than just me
752 2011-09-28 17:24:42 <gmaxwell> What wallet encryption does which a fully encrypted wallet cannot is keep a fully fuctional read and recieve only copy of bitcoin running.
753 2011-09-28 17:25:12 <ThomasV> gmaxwell: I understood that; you really think I am retarded ?
754 2011-09-28 17:25:23 <gmaxwell> Well, there have been indications&
755 2011-09-28 17:25:25 <gmaxwell> ;)
756 2011-09-28 17:26:09 <ThomasV> all I'm saying is that there is some private info in a wallet, and that "use disk encryption" is not an answer
757 2011-09-28 17:26:27 <gmaxwell> Well, what do you want. The way it works provides very useful functionality which is very useful and can't be achieved another way. And you want it to instead do something less useful, which can be easily provided by disk encryption.
758 2011-09-28 17:26:34 <gmaxwell> (or file encryption, etc)
759 2011-09-28 17:27:02 <ThomasV> I know I want it too
760 2011-09-28 17:27:08 <ThomasV> I never said it's wrong
761 2011-09-28 17:36:19 <jrmithdobbs> ThomasV: your method leaves the private keys sitting around on the device too, it's awful really