1 2012-03-30 03:25:23 <BlueMatt> nanotube: git rebase
  2 2012-03-30 04:09:30 <ferroh> in the big long apt-get string in the readme-qt.rst file in the satoshi client dir,
  3 2012-03-30 04:09:42 <ferroh> it doesn't mention miniupnpc as a necessary package
  4 2012-03-30 04:09:54 <ferroh> might be helpful for some to include that in the string
  5 2012-03-30 04:10:50 <ferroh> hmm.. although on the other hand, this still isn't building with that package installed grr
  6 2012-03-30 04:18:10 <ferroh> oh, i needed libminiupnpc-dev
  7 2012-03-30 08:21:48 <t7> dead in here...
  8 2012-03-30 08:26:47 <sipa> often at this hour
  9 2012-03-30 08:48:50 <t7> do the devs accept donations?
 10 2012-03-30 08:50:01 <t7> sipa are you formally proving something bitcoin related?
 11 2012-03-30 09:00:04 <sipa> not really; donations are certainly welcome, but there is no central donation box or something for the dev team
 12 2012-03-30 09:00:24 <t7> (i saw something on your github)
 13 2012-03-30 09:03:02 <coingenuity> sipa: just my 0.02, it'd be nice if there was
 14 2012-03-30 09:03:11 <coingenuity> also @ gavinandresen jgarzik etc
 15 2012-03-30 09:03:15 <coingenuity> :)
 16 2012-03-30 09:04:00 <coingenuity> it'd be simply badass if a central dev donation system can create a full-time job for you guys
 17 2012-03-30 09:22:03 <Joric> i got ~25 btc from donations and bounties, mostly from etotheipi_ :)
 18 2012-03-30 09:56:39 <etotheipi_> Joric, haha... well you've been helpful, with both Satoshi wallet compiling and OSX stuff
 19 2012-03-30 10:00:52 <gavinandresen> etotheipi_: you might be interested in my 2-person escrow design notes: https://gist.github.com/830ca16758fb9ad496d7
 20 2012-03-30 10:01:21 <gavinandresen> etotheipi_: there's an idea at the bottom for funding client development (failed escrows go to client developers)
 21 2012-03-30 10:01:49 <etotheipi_> gavinandresen, fantastic!  I'll read through it
 22 2012-03-30 10:02:15 <etotheipi_> gavinandresen, I've got a few important upgrades, but then I'll be tackling multi-sig prob within the next month
 23 2012-03-30 10:04:41 <etotheipi_> gavinandresen, any thoughts about using "deposits"?
 24 2012-03-30 10:05:08 <etotheipi_> A wants to buy something for 10 BTC from B, so they select a "risk level":  30%, so A puts in 13 BTC and B puts in 3 BTC
 25 2012-03-30 10:05:27 <etotheipi_> it would be a multi-input transaction to a multi-signature output
 26 2012-03-30 10:05:34 <gavinandresen> I think that will be confusing for most people-- if YOU are paying ME, why do I have to pay???
 27 2012-03-30 10:06:08 <gmaxwell> er. backupwallet rpc doesn't appear to be working.
 28 2012-03-30 10:06:41 <etotheipi_> gavinandresen, admittedly, I haven't fully absorbed your post yet, i just noticed that wasn't part of it and I've seen it suggested quite a few times
 29 2012-03-30 10:06:42 <gribble> New news from bitcoinrss: Diapolo opened issue 1013 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1013>
 30 2012-03-30 10:06:51 <gavinandresen> gmaxwell: I never liked the backupwallet code, too much voodoo in there....
 31 2012-03-30 10:08:28 <gmaxwell> bleh. It's writing it to the directory bitcoind was initially started from now... I'm pretty sure it didn't do that before.
 32 2012-03-30 10:08:44 <etotheipi_> gavinandresen, the nice thing about that is that if you make the "risk level" >= 15%, you could have third-party arbitrators who get involved knowing that there's 30% already in the tx for them to take as a fee
 33 2012-03-30 10:09:15 <gavinandresen> gmaxwell: phew, you had me worried.  I think that IS the same behavior as always
 34 2012-03-30 10:09:35 <etotheipi_> in the event of no dispute, A and B get their money back... but if there is, they appeal to the third-party who takes the X% extra as fee
 35 2012-03-30 10:09:57 <etotheipi_> which also guarantees that both parties contributed to that fee
 36 2012-03-30 10:10:14 <etotheipi_> it's not just one side who ends up paying for the arbitrator
 37 2012-03-30 10:10:25 <gavinandresen> etotheipi_: I'm all for Trying More Than One Way.  I just think it will be hard for people to understand the whole "We both have to deposit before the transaction starts" idea
 38 2012-03-30 10:10:40 <etotheipi_> gavinandresen, fair enough
 39 2012-03-30 10:11:26 <etotheipi_> gavinandresen, I liked the "elegance" of the idea because it allows for working with or without a third-party, and both original parties are invested in finishing the tx without a third-party
 40 2012-03-30 10:11:42 <etotheipi_> but you are certainly right that it could be confusing
 41 2012-03-30 10:13:55 <etotheipi_> gavinandresen, sorry I don't know enough about locktime... but does the LAZY_ALICE scenario actually work?
 42 2012-03-30 10:14:24 <etotheipi_> I thought if you submit a transaction that has a final sequence number but a future locktime... it will just be accepted by the network and just can't be spent until locktime expires
 43 2012-03-30 10:14:30 <gavinandresen> Sure.  All transactions must have locktime <= block.time
 44 2012-03-30 10:14:46 <sipa> gmaxwell: it does work with an absolute pathname, no?
 45 2012-03-30 10:15:38 <gmaxwell> sipa: Yep. Weird. I thought it pulled the cwd from the calling rpc command if you didn't provide one just must have been dumb luck on my part. Broke one of my scripts here. My error.
 46 2012-03-30 10:15:40 <Joric> i remember they actually have, but it's not used atm, a whole uint32
 47 2012-03-30 10:15:49 <gavinandresen> etotheipi_: oh, but if a conflicting transaction comes in with no locktime what happens... good question
 48 2012-03-30 10:17:57 <etotheipi_> gavinandresen, thanks ... I'm going to ponder this... and probably come back for more discussions about it later
 49 2012-03-30 10:18:13 <etotheipi_> (for now I need to finish up Armory RAM-reduction and compressed public keys)
 50 2012-03-30 10:18:45 <Joric> does client take lock_time into account? should delay transaction for a certain number of blocks if i remember right
 51 2012-03-30 10:21:02 <sipa> Joric: number of blocks or timestamp
 52 2012-03-30 10:22:24 <sipa> gavinandresen: afaik a locked transaction is not considered any less valid (so the conflicting one will be a conflict), just not yet acceptable into a block
 53 2012-03-30 10:23:41 <etotheipi_> sipa, so it's really dependent on how long nodes keep it in their memory pool, then?
 54 2012-03-30 10:23:52 <gavinandresen> sipa: I think you're right, but that seems wrong.
 55 2012-03-30 10:24:13 <sipa> gavinandresen: the system to overrule that was transaction replacement, but that is disabled
 56 2012-03-30 10:24:36 <sipa> (afaik)
 57 2012-03-30 10:24:49 <etotheipi_> how does Satoshi client deal with that?  will it receive the locked transactions, verify it, and then keep it in its memory pool forever?
 58 2012-03-30 10:25:05 <sipa> i suppose, yes
 59 2012-03-30 10:25:20 <sipa> looking at CTransaction::IsFinal, i notice something strange
 60 2012-03-30 10:26:08 <sipa> a transaction with nLockTime in the future, but all its inputs at sequence number 0xFFFFFFFF, is considered final
 61 2012-03-30 10:26:17 <sipa> ok, that's not too strange, actualle
 62 2012-03-30 10:26:44 <etotheipi_> final means it can't be replaced
 63 2012-03-30 10:26:47 <sipa> indeed
 64 2012-03-30 10:27:15 <gribble> New news from bitcoinrss: Diapolo opened pull request 1014 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1014>
 65 2012-03-30 10:27:42 <etotheipi_> so, it would work if you could somehow convince miners to include a conflicting tx into the blockchain before the locktime...
 66 2012-03-30 10:27:51 <etotheipi_> but that conflicting tx would not propagate
 67 2012-03-30 10:28:39 <etotheipi_> (by itself)
 68 2012-03-30 10:33:08 <gavinandresen> Will have to think about this some more, but my initial thought is that transactions with lockTime more than (mumble) minutes in the future shouldn't go into the memory pool
 69 2012-03-30 10:34:14 <gavinandresen> Replacement could open up a DoS attack:  I could give you an almost endless stream of the same transaction, just decrementing lockTime, and get you to do an endless relay / ECDSA signature verification
 70 2012-03-30 10:35:47 <etotheipi_> gavinandresen, perhaps replacement algorithm could check whether the replacing transaction actually uses different inputs... meaning the DoS attack requires you to sign as many messages as I have to verify
 71 2012-03-30 10:36:14 <etotheipi_> err... check 1)  use different inputs?   check 2) verify signatures
 72 2012-03-30 10:36:26 <gavinandresen> etotheipi_: but LAZY_ALICE and DISPUTE both use the same input.
 73 2012-03-30 10:36:46 <etotheipi_> oh wait...
 74 2012-03-30 10:36:51 <etotheipi_> but they have to be re-signed
 75 2012-03-30 10:37:00 <etotheipi_> I think that's already the case:  you change the locktime, you need a new sig
 76 2012-03-30 10:37:18 <gavinandresen> true
 77 2012-03-30 10:39:37 <gavinandresen> There might still be some advantage to an attacker if they could pre-compute a gazillion signatures and then flood the network with them
 78 2012-03-30 11:47:12 <etotheipi_> gavinandresen, I think there's a further problem in your proposal:  it looks like the LAZY_ALICE tx is a single point of failure for Alice
 79 2012-03-30 11:47:38 <etotheipi_> Once bob has that tx, he just doesn't do *anything*... doesn't send the merchandise, becomes unreachable
 80 2012-03-30 11:47:48 <etotheipi_> and in 31 days time he gets the money
 81 2012-03-30 11:47:59 <gavinandresen> Alice needs to send the DISPUTE transaction before then
 82 2012-03-30 11:48:56 <etotheipi_> well then it's race to see which tx can make it into the blockchain first
 83 2012-03-30 11:49:23 <gavinandresen> Yeah, I was thinking in the shower this morning that DISPUTE should have a hefty fee attached
 84 2012-03-30 11:49:32 <etotheipi_> and the DISPUTE is really just to try to prevent Bob from screwing Alice (non-literally), Alice doesn't win anything other than prevent Bob from winning
 85 2012-03-30 11:50:17 <gavinandresen> Sure, you could make it more complicated and have bob and alice fund the A+B and then have two versions of dispute that refunding to various people
 86 2012-03-30 11:51:21 <etotheipi_> I think this is why we came up with the "deposit" method... because I don't see a clean way to do this unless both parties have investments in the tx that they get back if everything goes smoothly -- i.e. both have an incentive to just do things right and not get silly
 87 2012-03-30 11:51:43 <gavinandresen> ok.  My case would be a "Bob deposits zero" degenerate case
 88 2012-03-30 11:51:49 <etotheipi_> though it doesn't have a trigger in place if no one does anything... though the third-party is presumably very reliable
 89 2012-03-30 11:53:25 <etotheipi_> I've seen a lot of fancy things that can be done with nlocktime&replacement if it was enabled... but it's not going to help me get something into Armory next month
 90 2012-03-30 11:55:12 <gavinandresen> there aren't going to be reliable trusted third parties next month, either
 91 2012-03-30 11:56:05 <etotheipi_> on the other hand, my proposed idea (amalgamated from the previous discussions on the forum) involves using an alternate hashcode to make sure that Alice puts in 1.X and Bob puts in 0.X into the same tx with A&B output
 92 2012-03-30 11:56:21 <etotheipi_> I was actually in the process of writing it up...
 93 2012-03-30 11:56:36 <gavinandresen> cool, I'd be interested in reading it
 94 2012-03-30 11:56:51 <etotheipi_> it can be done without alternate hashcodes, but it's a couple extra steps because of change outputs, etc
 95 2012-03-30 11:57:35 <etotheipi_> of course, I should triple-check that alternate hashcodes will be accepted as isStandard
 96 2012-03-30 11:57:49 <Blitzboom> hm, will bitcoin.org  list alternative clients in the future?
 97 2012-03-30 11:58:00 <gavinandresen> I'm still very skeptical that there will be many Alices that say "Sure, I'll put 11 BTC into this transaction when I'm paying 10BTC for something" or many Bob's who will say "Sure, I know Alice is paying me but I'm happy to chip in 1 BTC"
 98 2012-03-30 11:58:41 <etotheipi_> gavinandresen, I agree, but I think it's not unreasonable if an appropriate explanation is given
 99 2012-03-30 11:58:43 <gavinandresen> ... even if it is all phrased as "security deposit" ....
100 2012-03-30 11:59:38 <etotheipi_> and worst case, people who understand it will use it, and something else will crop up for those that don't understand/want to do it
101 2012-03-30 12:00:45 <gavinandresen> well, worst case is you implement it, six people love it to death but it confuses the heck out of six hundred people and causes you lots of customer support.
102 2012-03-30 12:00:56 <gavinandresen> Then you remove it and those six people hate you forever.
103 2012-03-30 12:01:04 <etotheipi_> gavinandresen, lol, fair enough
104 2012-03-30 12:01:37 <etotheipi_> though if you've seen Armory:  I tend to put endless warnings and explanations into all the dialogs to prevent users from even aiming their gun at their own foot, much less firing
105 2012-03-30 12:02:09 <gavinandresen> I haven't tried Armory yet, but now that it is starting to work on the Mac....
106 2012-03-30 12:02:10 <etotheipi_> doesn't mean people won't just blindly click through the dialogs... but it should cut down on it
107 2012-03-30 12:02:27 <gavinandresen> Have you shipped end-user software products before?
108 2012-03-30 12:02:28 <etotheipi_> gavinandresen, I should have a RAM-reduced version this weekend for Linux&OSX
109 2012-03-30 12:02:46 <gavinandresen> (I'm very skeptical that users will read more than 7 words on any dialog box)
110 2012-03-30 12:03:04 <etotheipi_> gavinandresen, no I have not
111 2012-03-30 12:03:05 <gavinandresen> (ok, 7 is exaggerating.  140 characters.)
112 2012-03-30 12:03:10 <sipa> gavinandresen: i don't think people read unexpected dialog boxes at all
113 2012-03-30 12:03:15 <sipa> they're a nuisance
114 2012-03-30 12:03:35 <gavinandresen> ok ok ok ok
115 2012-03-30 12:03:37 <sipa> if there's a button dismiss, they will click it
116 2012-03-30 12:03:50 <gavinandresen> blah blah ok blah blah ok
117 2012-03-30 12:04:24 <etotheipi_> I guess I'm just not seeing a reliable way to implement the escrow without some negative financial reinforcement for both parties if they screw it up
118 2012-03-30 12:04:50 <sipa> so it's an escrew?
119 2012-03-30 12:04:58 <sipa> (sorry, bad joke)
120 2012-03-30 12:05:15 <etotheipi_> if Bob never puts anything in... then he can just trick Alice into dumping some coins into this A&B tx which he will subsequently ignore and then disappear
121 2012-03-30 12:05:16 <gavinandresen> etotheipi_: There's a very good chance I'm wrong, I think lots of experimentation is needed.
122 2012-03-30 12:05:44 <gavinandresen> etotheipi_: I am assuming Bob has a reputation
123 2012-03-30 12:05:53 <etotheipi_> gavinandresen, but we're talking trust-free
124 2012-03-30 12:06:01 <etotheipi_> or as close as we can get
125 2012-03-30 12:06:19 <etotheipi_> if Bob has a reputation, then perhaps the deposit can be 0% (a trivial case of the general solution)
126 2012-03-30 12:06:33 <etotheipi_> but if we're talking ebay or craigslist
127 2012-03-30 12:06:51 <gavinandresen> etotheipi_: so practical matter:  are Alice and Bob's clients talking to each other in real-time to negotiate the deposit?
128 2012-03-30 12:07:05 <gavinandresen> Or do they somehow negotiate in advance?
129 2012-03-30 12:07:06 <jgarzik> coingenuity: I've never objected to people buying us beer :)
130 2012-03-30 12:07:38 <etotheipi_> ... I could just post all sorts of things and have people dump money into A&B transactions that I will never touch... or maybe come back later and extort the money "you're not going to see the money ever again anyway: but you can get half of it back if you sign this tx"
131 2012-03-30 12:08:37 <gavinandresen> etotheipi_: sure, I absolutely see how the both-parties-deposit solution solves the Alice-doesn't-trust-Bob-at-all issue.
132 2012-03-30 12:09:04 <gavinandresen> etotheipi_: I just don't see how to make it easy enough for typical Alices and Bobs to understand.
133 2012-03-30 12:09:17 <etotheipi_> gavinandresen, I am not entirely clear on the interchange yet:  I had planned on BIP 0010 allowing people to manually send each other packets, and then it could be transitioned to client-based exchange later
134 2012-03-30 12:10:13 <etotheipi_> gavinandresen, the escrow transaction will only be created by a single transaction that include inputs from both parties... no one party puts their money in before the other
135 2012-03-30 12:10:18 <gavinandresen> I think any solution that requires the payer to not be lazy won't work in practice.
136 2012-03-30 12:10:30 <etotheipi_> which means that both parties have financial interest in completing the transaction
137 2012-03-30 12:11:02 <etotheipi_> nothing motivates people to not be lazy like getting a refund
138 2012-03-30 12:11:15 <etotheipi_> but your point is not lost on me
139 2012-03-30 12:11:23 <gavinandresen> Meh.  Alice gets a laptop computer and then loses a couple bitcoins deposit because her computer caught on fire.
140 2012-03-30 12:11:39 <gavinandresen> Bob gets screwed...
141 2012-03-30 12:11:59 <etotheipi_> for small transactions, you can take that risk... for large transactions, that's what the third party is for
142 2012-03-30 12:12:49 <etotheipi_> they are part of the 2-of-3 tx, and will help one party recover money if the other party disappears... taking those same deposits as a fee
143 2012-03-30 12:13:07 <etotheipi_> and that also means that the third-party is then funded by both A and B
144 2012-03-30 12:13:16 <etotheipi_> as opposed to A or B funding it entirely
145 2012-03-30 12:13:43 <gavinandresen> So bob and alice have to both deposit AND agree in advance to an arbitrator?
146 2012-03-30 12:14:02 <etotheipi_> you can't have a third-party arbitrator without prior agreement on who it will be
147 2012-03-30 12:14:30 <gavinandresen> Sure you can, the coins could stay in limbo in a two-sig-required transaction until both agree on where they go
148 2012-03-30 12:15:03 <gavinandresen> (and the 'where they go' could be a 3-sig-required transaction)
149 2012-03-30 12:15:09 <etotheipi_> gavinandresen, but that's a huge risk on a large tx for the exact reason you suggested:  one party could have an unexpected disaster (computer explosion, death, etc)
150 2012-03-30 12:15:35 <gavinandresen> true.
151 2012-03-30 12:15:46 <etotheipi_> I think it would be possible for someone to start a companyu
152 2012-03-30 12:16:04 <etotheipi_> the sole purpose of the company is to have a website where you can retreive and verify addresses belonging to that third party
153 2012-03-30 12:16:15 <etotheipi_> they don't even need to be aware that they are being included as a third-party on the tx
154 2012-03-30 12:16:33 <etotheipi_> but as long as there is at least 15% deposit from both parties as part of the tx, they can be contacted later to resolve the dispute
155 2012-03-30 12:16:47 <etotheipi_> and the money is already there to pay their fee
156 2012-03-30 12:17:50 <gavinandresen> We should stop talking and start designing/implementing.  There Will Be Dragons along the way, I'm sure....
157 2012-03-30 12:18:04 <etotheipi_> agreed... I'm running into them in my thought process right now
158 2012-03-30 12:18:22 <etotheipi_> but I've been thinking about this particular idea (blind third-party until needed) for a while
159 2012-03-30 12:18:32 <gavinandresen> yup.  that's why I put up the design gist, to shake out stuff like lockTime and the memory pool.....
160 2012-03-30 12:18:47 <etotheipi_> yeah yeah... formal documentation...
161 2012-03-30 12:18:51 <etotheipi_> :)
162 2012-03-30 12:19:25 <etotheipi_> I'll do it once I finish RAM-reduction in Armory (it's done, but the UI needs a lot of interface upgrades to accommodate)
163 2012-03-30 12:19:45 <gavinandresen> well, we could easily screw it up really badly by designing what we think is a cheat-proof system that turns out to be easily cheated
164 2012-03-30 12:20:20 <etotheipi_> gavinandresen, you know as well as I do that there is a threshold:  a lot of things can be threshed out through thought-experiments before going to the effort to implement and test
165 2012-03-30 12:20:33 <etotheipi_> but at some point you have no choice but to start implementing and testing
166 2012-03-30 12:21:04 <etotheipi_> I'm mainly looking for sanity checks on some of my ideas:  but I'll throw them into gists when I get some time to formalize them
167 2012-03-30 12:22:31 <Joric> did anyone manage to compile/run satoshi client on cellphones?
168 2012-03-30 12:23:18 <etotheipi_> speaking of formalization:  how is signature collection going to work with Satoshi?  is it kind of figure-it-out-on-your-own right now?  I think it would be great to iron out BIP 10 and clean up some of the terminology so that something exists before developers start doing their own things
169 2012-03-30 12:23:19 <sipa> i believe luke-jr compiled it for (on?) a N900
170 2012-03-30 12:23:30 <luke-jr> N900 isn't a cellphone tho
171 2012-03-30 12:23:43 <sipa> can you make calls with it?
172 2012-03-30 12:23:58 <etotheipi_> BIP 10 is already used in Armory's offline-transactions/cold-storage
173 2012-03-30 12:23:59 <luke-jr> sipa: same way you can on any other laptop
174 2012-03-30 12:24:01 <Joric> probably, for, 'on' is too hardcore
175 2012-03-30 12:24:10 <luke-jr> Joric: no, 'on' is correct
176 2012-03-30 12:24:14 <luke-jr> I run Gentoo.
177 2012-03-30 12:24:21 <etotheipi_> but for multi-sig and multi-client environments, it needs to be more rigorous and versatile
178 2012-03-30 12:24:31 <luke-jr> I run Gentoo on my N900
179 2012-03-30 12:25:29 <sipa> luke-jr: it's the size of a phone, and it has hardware to connect to the cell phone network; to me, that qualifies as a phone :)
180 2012-03-30 12:25:35 <gavinandresen> etotheipi_: I don't know yet how signature collection will work.  Magically behind the scenes, I hope
181 2012-03-30 12:26:15 <Joric> i just checked looks like n900 is little-endian
182 2012-03-30 12:26:21 <gavinandresen> etotheipi_: by the way, did you see the other gist I've been working on:  https://gist.github.com/2217885
183 2012-03-30 12:26:26 <etotheipi_> well then I think we should make an effort to clean up BIP 10 or find an alternative:  so far it's worked very well, and gmaxwell came with a great security modification that makes it even more secure
184 2012-03-30 12:26:37 <luke-jr> Joric: ARM is LE by default, yes
185 2012-03-30 12:26:57 <luke-jr> sipa: all its earlier models didn't have cellular capabilities :P
186 2012-03-30 12:27:02 <etotheipi_> (gmaxwell's suggestion is already part of BIP 10 and used in Armory -- for including previous transactions so that input values can be verified by node without blockchain)
187 2012-03-30 12:27:03 <Joric> there were some endianness controversial parts if i remember right
188 2012-03-30 12:27:15 <luke-jr> Joric: Satoshi client does *not* work in BE
189 2012-03-30 12:30:21 <etotheipi_> gavinandresen, btw:  on the topic of of creating and exchanging public keys for 2-factor-auth -- that was part of my design goal with Armory wallets;  one device has full wallet A and watching-only B, another has full B and watch-only A... they both trivially create the same sequence of 2-of-2 addresses
190 2012-03-30 12:31:57 <gavinandresen> neat.  What's the easiest platform to get Armory running on?  Linux?
191 2012-03-30 12:32:32 <etotheipi_> gavinandresen, that 2-of-2 thing is not implemented yet
192 2012-03-30 12:32:44 <etotheipi_> but yes, Linux is pretty damned easy:  6 CLI commands
193 2012-03-30 12:32:55 <gavinandresen> darn, I was hoping you'd solve all the GUI issues for us
194 2012-03-30 12:33:03 <etotheipi_> gavinandresen,  :)
195 2012-03-30 12:33:04 <Diablo-D3> [10:26:37] <luke-jr> Joric: ARM is LE by default, yes
196 2012-03-30 12:33:14 <Diablo-D3> theres only three archs worthy of note that are whores
197 2012-03-30 12:33:19 <Diablo-D3> arm, powerpc, and mips
198 2012-03-30 12:33:24 <jgarzik> does anybody have python code that successfully verifies the block chain, including transactions?
199 2012-03-30 12:33:32 <luke-jr> I like bi-endian.
200 2012-03-30 12:33:33 <jgarzik> phantomcircuit did, didn't he?
201 2012-03-30 12:33:45 <Diablo-D3> you almost never see arm outside of LE, you almost never see powerpc out of BE, and mips is sort of a toss up
202 2012-03-30 12:33:48 <luke-jr> in theory, you can use BE for everything sane, and only compile the rare insane code for LE
203 2012-03-30 12:33:49 <etotheipi_> gavinandresen, all the wallet stuff under-the-hood can already do it... I just need to get my blockchain scanning updated with BIP 16 and make a UI
204 2012-03-30 12:33:55 <Diablo-D3> I think mips is the only OS linux supports both mipsel and mipsbe
205 2012-03-30 12:34:03 <etotheipi_> gavinandresen, http://bitcoinarmory.com/index.php/building-armory-from-source
206 2012-03-30 12:34:21 <Diablo-D3> luke-jr: or I can just use libmowgli2
207 2012-03-30 12:34:26 <etotheipi_> gavinandresen, but if your linux box is short on RAM, wait a couple days
208 2012-03-30 12:34:28 <gmaxwell> Diablo-D3: there is armbe ... debian linux used to be be, though they changed. I think the BE builds are still supported.
209 2012-03-30 12:34:40 <Diablo-D3> gmaxwell: they tried armbe but I think their armbe guy comitted suicide
210 2012-03-30 12:34:45 <helo> etotheipi_: a couple days? :D
211 2012-03-30 12:34:54 <Diablo-D3> gmaxwell: its really rare to see armbe out there though
212 2012-03-30 12:34:56 <etotheipi_> helo, I'm hoping to get a testing release out today
213 2012-03-30 12:35:03 <etotheipi_> (just for linux & osx)
214 2012-03-30 12:35:13 <helo> good news...
215 2012-03-30 12:35:47 <Diablo-D3> http://git.atheme.org/libmowgli-2/tree/src/libmowgli/platform/machine.h
216 2012-03-30 12:35:54 <Diablo-D3> THE HORROR
217 2012-03-30 12:36:10 <Diablo-D3> oh I forgot, itanium can be either as well
218 2012-03-30 12:36:59 <Diablo-D3> I need to add avr32 to that
219 2012-03-30 12:37:00 <Diablo-D3> and amiga
220 2012-03-30 12:37:51 <Diablo-D3> gmaxwell: hey, you wouldnt happen to know how to do a double cas atomically with just cas would you?
221 2012-03-30 12:48:20 <phantomcircuit> jgarzik, i have something that will sort of do that
222 2012-03-30 12:48:26 <phantomcircuit> but it needs a lot of work before it's useful
223 2012-03-30 12:54:32 <gavinandresen> sipa jgarzik gmaxwell : I've already repackaged the rc6 binaries and am in the process of uploading them to SourceForge as 0.6.0 final
224 2012-03-30 12:59:06 <sipa> gavinandresen: what about #1012 ?
225 2012-03-30 12:59:45 <gavinandresen> known issue
226 2012-03-30 13:00:49 <sipa> fair enough
227 2012-03-30 13:01:02 <gavinandresen> I don't think a 25 second versus 12 second shutdown time is a showstopper
228 2012-03-30 13:01:18 <gavinandresen> Both are an order of magnitude longer than I'd like it to be....
229 2012-03-30 13:01:30 <sipa> no, but without indication, i fear many people will kill it, or shut down their computer before it completes
230 2012-03-30 13:02:58 <gavinandresen> I think it's time to ship 0.6 today
231 2012-03-30 13:10:07 <gavinandresen> hmmm, looks like god is trying to tell me something with this SHASUM: addda717badaab03394828af28dc2f8ace265b3b  bitcoin-0.6.0-win32.zip
232 2012-03-30 13:10:13 <gavinandresen> message garbled, though....
233 2012-03-30 13:10:44 <sipa> add a bad aab?
234 2012-03-30 13:11:04 <gavinandresen> rewrite Bitcoin in ada ?
235 2012-03-30 13:11:41 <gavinandresen> I'm a bad dad ?
236 2012-03-30 13:12:26 <sipa> no: ada bad, a baf dc ace
237 2012-03-30 13:12:32 <gavinandresen> maybe if I took all the previous shasums from the previous releases, interpreted them as ascii, crossed out every 11'th letter.....
238 2012-03-30 13:12:36 <sipa> was ada lovelace from DC?
239 2012-03-30 13:14:02 <gavinandresen> Ok, I've run out of reasons NOT to announce a final 0.6.0 release.  Am I forgetting anything?
240 2012-03-30 13:15:58 <luke-jr> gavinandresen: go for it, Apr 1 is coming up
241 2012-03-30 13:16:28 <luke-jr> but I veto my vote on the matter, as I won't be here much for a few days
242 2012-03-30 13:20:41 <gavinandresen> I know what I forgot to do, I forgot to tag the tree and change the tarball/zipball links in the release notes....
243 2012-03-30 13:23:34 <Blitzboom> wow, loading blocks is extremely fast for me now
244 2012-03-30 13:23:56 <Blitzboom> 25% done in maybe 5 mins
245 2012-03-30 13:24:17 <Blitzboom> good job :D
246 2012-03-30 13:24:29 <sipa> Blitzboom: tell me if it completes in less than 31 minutes :)
247 2012-03-30 13:24:52 <Blitzboom> ill do it again to record the exact time
248 2012-03-30 13:25:33 <sipa> (that's how long it took me from a local file)
249 2012-03-30 13:27:32 <Blitzboom> the QR codes are a nice feature
250 2012-03-30 13:35:31 <gribble> New news from bitcoinrss: gavinandresen opened pull request 30 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/30>
251 2012-03-30 14:21:27 <luke-jr> BlueMatt: FWIW, BOOST_THREAD_USE_LIB makes zero difference to either compile output (build.log) or binaries, with 0.6.0rc5
252 2012-03-30 14:21:43 <luke-jr> (and the actual commit with it doesn't build)
253 2012-03-30 14:45:32 <finway> I think bitcoin.org missed something.
254 2012-03-30 14:46:11 <finway> At the top-right section, There's nothing behind "Latest version:"
255 2012-03-30 14:46:24 <finway> I guess there should be 0.6
256 2012-03-30 14:47:04 <finway> or 0.5.3.1
257 2012-03-30 14:49:29 <luke-jr> finway: well, Gavin just pushed 0.6.0 final out
258 2012-03-30 14:49:34 <luke-jr> so I presume it'll be fixed when that hits
259 2012-03-30 14:50:59 <finway> Ok, i guess it's in middle-state
260 2012-03-30 14:52:57 <finway> luke-jr: is compressed pubkey less secure than long pubkey ?
261 2012-03-30 14:53:03 <sipa> finway: no
262 2012-03-30 14:53:11 <sipa> it's just a more efficient representation
263 2012-03-30 14:53:46 <finway> sipa,thanks.
264 2012-03-30 14:54:10 <sipa> you can convert a compressed one into a normal one and vice-versa, one-to-one
265 2012-03-30 14:54:45 <finway> That's good.
266 2012-03-30 14:56:51 <BlueMatt> luke-jr: odd, I know it was required on some platform...
267 2012-03-30 14:58:56 <luke-jr> finway: note that converting between compressed and non-compressed changes the address, so bitcoind doesn't do it
268 2012-03-30 14:59:10 <luke-jr> BlueMatt: or maybe an older boost version
269 2012-03-30 14:59:46 <luke-jr> BlueMatt: do you recall if it was build errors, or some runtime or warnign thing?
270 2012-03-30 14:59:58 <luke-jr> if it was build errors, I can probably safely neglect the backport until someone hits it :P
271 2012-03-30 15:00:39 <luke-jr> or I guess it's safest to backport it once 0.6.0 is more adopted and it's tested
272 2012-03-30 15:02:19 <finway> luke-jr: i hope i was a  C++  pro.
273 2012-03-30 15:02:37 <finway> then there wont be so many questions.
274 2012-03-30 15:02:46 <luke-jr> you wish?
275 2012-03-30 15:03:11 <finway> wish,hope, i can't tell the difference.
276 2012-03-30 15:03:40 <luke-jr> "wish" means you know it isn't reality; "hope" means something that may be future reality
277 2012-03-30 15:04:01 <finway> luke-jr, got it.
278 2012-03-30 15:04:06 <finway> wish
279 2012-03-30 15:04:49 <finway> though i barely know a little bit python.
280 2012-03-30 15:06:25 <finway> are BIP30 supported by most miners ?
281 2012-03-30 15:07:21 <finway> Have we got duplicate coinbase txes to wipe non-BIP30-supports out?
282 2012-03-30 15:08:35 <luke-jr> finway: too expensive.
283 2012-03-30 15:09:39 <finway> heh
284 2012-03-30 15:13:53 <[Tycho]> :)
285 2012-03-30 15:14:32 <riush> [Tycho]: according to blockchain.info, deepbit just generated two empty blocks.. is that correct?
286 2012-03-30 15:16:06 <finway> lol, Donate@Home is generating bitcoins ?
287 2012-03-30 15:16:17 <finway> Oh, Donate@Home
288 2012-03-30 15:16:43 <[Tycho]> riush: use this: http://blockorigin.pfoe.be/blocklist.php
289 2012-03-30 15:17:30 <[Tycho]> May be its Deepbit and may be it's MM relaying her blocks via my external nodes.
290 2012-03-30 15:18:12 <riush> ah, i see. thanks
291 2012-03-30 15:18:42 <[Tycho]> Technically we can create empty blocks if round is shorter than 2 minutes.
292 2012-03-30 15:19:25 <etotheipi_> how is that two minutes measured?
293 2012-03-30 15:19:37 <luke-jr> etotheipi_: longpoll responses get empty blocks
294 2012-03-30 15:19:56 <luke-jr> whenever those miners fetch new work, they get full ones
295 2012-03-30 15:20:05 <etotheipi_> it's not a validation rule, just a "tendency" built into the nodes?
296 2012-03-30 15:20:06 <luke-jr> since work expires in 2 minutes, that's the max
297 2012-03-30 15:20:15 <luke-jr> etotheipi_: ?
298 2012-03-30 15:20:28 <luke-jr> sure
299 2012-03-30 15:20:55 <luke-jr> etotheipi_: Eloipool, at least, will begin sending longpoll works before it's finished calculating the new transaction merkle tree
300 2012-03-30 15:21:30 <etotheipi_> luke-jr, gotcha
301 2012-03-30 15:21:30 <luke-jr> though, it also sends a second longpoll when it's done with that
302 2012-03-30 15:33:10 <etotheipi_> could someone please send me some testnet coins?  I somehow don't have any!  n4jEBj2YxBwyFbwYWhHmbjXXN3ETNwr47T
303 2012-03-30 15:33:22 <etotheipi_> testing sweeping functions, etc, is difficult without coins
304 2012-03-30 15:35:16 <bitcoin> Receive coins>Show QR code>Request Payment... what does Request Payment do?
305 2012-03-30 15:35:53 <luke-jr> etotheipi_: send 10 bTBC
306 2012-03-30 15:36:26 <etotheipi_> I don't want bTBC... :)
307 2012-03-30 15:36:40 <luke-jr> sent 10 GTBC*
308 2012-03-30 15:36:54 <luke-jr> TN*
309 2012-03-30 15:37:20 <etotheipi_> well, thanks Luke
310 2012-03-30 15:37:39 <bitcoin> bong bitcoin
311 2012-03-30 15:38:32 <luke-jr> np
312 2012-03-30 16:11:39 <lh77> ;;ticker
313 2012-03-30 16:11:40 <gribble> Best bid: 4.76333, Best ask: 4.76334, Bid-ask spread: 1.00000000005e-05, Last trade: 4.77, 24 hour volume: 33966, 24 hour low: 4.71699, 24 hour high: 4.83
314 2012-03-30 16:20:06 <Diablo-D3> up vote: https://news.ycombinator.com/item?id=3777335
315 2012-03-30 16:26:48 <gjs278> ati drivers 12.3 makes every single font in my gtk apps one size too big
316 2012-03-30 16:26:58 <gjs278> I revert to 12.2 and everything is back to normal
317 2012-03-30 16:38:33 <BlueMatt> luke-jr: I thought it was build errors, but meh...anyway dont bother backporting if you cant figure out why its necessary imo
318 2012-03-30 16:38:57 <BlueMatt> if it doesnt build for some people, it doesnt build...they can come ask why not
319 2012-03-30 19:01:11 <graingert> BlueMatt: now that 6 wallets are incompatible with 5 wallets
320 2012-03-30 19:01:22 <graingert> can you upgrade the version of bdb?
321 2012-03-30 19:19:17 <Touko> Whats the most complete mining pool software atm?
322 2012-03-30 19:21:03 <Touko> Damn it's quite in here.
323 2012-03-30 19:21:46 <Diablo-D3> Touko: everyone uses p2pool anyhow.
324 2012-03-30 19:22:01 <Touko> Still
325 2012-03-30 19:22:07 <Touko> its not the most efficient
326 2012-03-30 19:35:32 <BlueMatt> <graingert> BlueMatt: now that 6 wallets are incompatible with 5 wallets <-- they are?
327 2012-03-30 19:36:39 <graingert> BlueMatt: yes when using the compressed keys
328 2012-03-30 19:37:15 <BlueMatt> yea but they arent automaticall upgraded unless you make a new one
329 2012-03-30 19:43:08 <graingert> BlueMatt: I still think it might be the time to change wallet type
330 2012-03-30 19:43:16 <graingert> ie a major version upgrade
331 2012-03-30 19:53:48 <coingenuity> jgarzik: next time you're in my hood i'll take you out for one :)
332 2012-03-30 20:59:40 <sipa> graingert: bitcoin 0.6 will *not* automatically upgrade your wallet
333 2012-03-30 20:59:56 <sipa> it will create new wallets that are incompatible with 0.5 though
334 2012-03-30 21:00:20 <graingert> sipa: hmm
335 2012-03-30 21:00:58 <graingert> sipa: in that case we will have to wait for there to be a sensible flat file format
336 2012-03-30 21:01:15 <graingert> that is exported to from the db
337 2012-03-30 21:01:31 <sipa> graingert: i've been working on a different wallet format though, but a binary one (that is however append-only during normal operation)
338 2012-03-30 21:02:03 <graingert> why not something like JSON that is read into an intermediary ?
339 2012-03-30 21:02:13 <sipa> how do you update it?
340 2012-03-30 21:02:36 <sipa> (i'm a large proponent of a json-based wallet interchange format, but not for the wallet itself)
341 2012-03-30 21:03:33 <sipa> graingert: there's also -upgradewallet by the way
342 2012-03-30 21:03:38 <graingert> sipa: you load the json into the db, then update the db then serialize the entire db to json and dump
343 2012-03-30 21:03:49 <graingert> on shutdown
344 2012-03-30 21:04:10 <sipa> that's possible, if it's loaded into memory entirely
345 2012-03-30 21:04:21 <sipa> (which it currently is indeed)
346 2012-03-30 21:04:26 <graingert> no you load the json into a db
347 2012-03-30 21:04:38 <graingert> could be sqlite could in memory could be bdbd
348 2012-03-30 21:04:44 <gmaxwell> ugh
349 2012-03-30 21:04:45 <graingert> then dump afterwards
350 2012-03-30 21:05:31 <graingert> the db is a temporary file
351 2012-03-30 21:05:40 <graingert> the user never knows about it
352 2012-03-30 21:06:52 <graingert> eg how XML works, you take the XML put it into a DOM in memory, manipulate it and write back to disk
353 2012-03-30 21:07:13 <splatster> So using newer addys created by 0.6 will result in smaller TX size?
354 2012-03-30 21:07:39 <sipa> splatster: indeed, the spending of such coins is smaller
355 2012-03-30 21:07:48 <sipa> 32 per input
356 2012-03-30 21:07:49 <gmaxwell> Yes, spending funds sent to 0.6 wallets results in smaller txn.
357 2012-03-30 21:07:55 <sipa> bytes
358 2012-03-30 21:08:19 <sipa> getinfo tells you the wallet format, by the way
359 2012-03-30 21:08:30 <splatster> Then how could I have all my addys upgraded to the compressed format?
360 2012-03-30 21:08:39 <sipa> splatster: impossible
361 2012-03-30 21:09:08 <splatster> Impossible? Not even manually?
362 2012-03-30 21:09:09 <sipa> it only works for new addresses
363 2012-03-30 21:09:24 <sipa> no, changing the pubkey means changing the address
364 2012-03-30 21:09:29 <gmaxwell> I suppose you could at least upgrade the wallet and then getnewaddress until the pool is empty.
365 2012-03-30 21:10:20 <sipa> but since you have to keep the old address around anyway, converting is not better than just generating a new key
366 2012-03-30 21:10:33 <splatster> Can someone explain how this new format works?
367 2012-03-30 21:10:52 <splatster> Or at least how it is different?
368 2012-03-30 21:10:54 <sipa> old format: 0x04 + x + y
369 2012-03-30 21:11:20 <sipa> new format: 0x02 + x (if y is even)
370 2012-03-30 21:11:36 <sipa> new format: 0x03 + x (if y is odd)
371 2012-03-30 21:12:11 <sipa> that information (x and the oddness of y) is enough to reconstruct y
372 2012-03-30 21:12:48 <splatster> Can the newer addresses be distinguished from the old ones?
373 2012-03-30 21:13:01 <sipa> addresses, no
374 2012-03-30 21:13:06 <sipa> public keys, yes
375 2012-03-30 21:26:37 <sipa> splatster: that's how it works: old nodes don't need to and cannot know they are sending to an address backed by a compressed public key
376 2012-03-30 21:27:00 <sipa> and old nodes consider their signatures valid
377 2012-03-30 21:27:17 <splatster> Ok, I think I get it now, thanks.
378 2012-03-30 21:32:34 <luke-jr> sipa: not entirely.
379 2012-03-30 21:32:45 <luke-jr> there was that verifymessage issue that deserves mention :p
380 2012-03-30 21:33:13 <sipa> true, but that has nothing to do with sending to an address
381 2012-03-30 22:22:09 <gribble> New news from bitcoinrss: jondoh opened issue 1015 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1015>
382 2012-03-30 22:42:37 <gribble> New news from bitcoinrss: jondoh opened pull request 1016 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1016>