1 2011-09-25 00:06:23 <nanotube> mindphlux: whatcha testing?
  2 2011-09-25 00:06:31 <mindphlux> nanotube: gambling game
  3 2011-09-25 00:06:56 <luke-jr> mindphlux: lrn2mine
  4 2011-09-25 00:07:00 <nanotube> ah heh ic. you could consider using the 'testnet in a box' setup with really low difficulty
  5 2011-09-25 00:07:12 <mindphlux> luke-jr: I'm mining with 14ghash so I know how to mine.
  6 2011-09-25 00:07:22 <luke-jr> mindphlux: so use it for testnet
  7 2011-09-25 00:07:30 <mindphlux> luke-jr: and wait 1 week until the block matures?
  8 2011-09-25 00:07:40 <luke-jr> mindphlux: why would it take that long?
  9 2011-09-25 00:07:53 <mindphlux> luke-jr: someone told me it takes ages to get a confirmed block.. so I decided not to bother
 10 2011-09-25 00:08:13 <luke-jr> if you don't mine onyl
 11 2011-09-25 00:08:13 <nanotube> mindphlux: well, if you're the one mining, you can confirm your own tx, you know
 12 2011-09-25 00:08:47 <gribble> The average time to generate a block at 14000000 Khps, given the supplied difficulty of 170, is 52 seconds
 13 2011-09-25 00:08:47 <nanotube> ;;bc,calcd 14000000 170
 14 2011-09-25 00:09:04 <nanotube> mindphlux: ^ you can generate a testnet block with 14ghps on average in 52 seconds
 15 2011-09-25 00:09:09 <mindphlux> I seei t
 16 2011-09-25 00:09:20 <mindphlux> Thanks
 17 2011-09-25 00:10:19 <luke-jr> (but please don't drive up the difficulty)
 18 2011-09-25 00:10:27 <mindphlux> that kind of implies it
 19 2011-09-25 00:10:32 <mindphlux> Wouldn't want to do that
 20 2011-09-25 00:10:41 <gribble> The average time to generate a block at 1000000 Khps, given the supplied difficulty of 170, is 12 minutes and 10 seconds
 21 2011-09-25 00:10:41 <luke-jr> ;;bc,calcd 1000000 170
 22 2011-09-25 00:10:47 <luke-jr> 1 GH is ok :P
 23 2011-09-25 00:11:07 <mindphlux> Using bitcoins is fine for me. Nothing to loose
 24 2011-09-25 00:30:40 <CIA-101> poolserverj: shadders * 19f36b75b327 r124 / (2 files in 2 dirs): - extra trace targets for longpoll empty and expired responses.
 25 2011-09-25 00:34:30 <mindphlux> Is it wise to allow 0 confirmations ? Just not paying out any winnings when the transaction in question is having less than 6 confirmations - ie he can play with his money, but cannot pay out unless it confirms properly
 26 2011-09-25 00:35:44 <luke-jr> no
 27 2011-09-25 00:36:01 <luke-jr> mindphlux: so he'll play, and let it confirm properly if he wins
 28 2011-09-25 00:36:38 <mindphlux> luke-jr: gotcha.
 29 2011-09-25 00:36:43 <mindphlux> thanks. Didn't think of that
 30 2011-09-25 00:37:19 <mindphlux> But what good does it do with loosing with double spent money?
 31 2011-09-25 00:37:23 <mindphlux> If he can never get it back
 32 2011-09-25 00:37:24 <mindphlux> lol
 33 2011-09-25 00:38:22 <phantomcircuit> he can play the game until he wins never losing anything
 34 2011-09-25 00:38:47 <luke-jr> mindphlux: double-spending usually means the original sender is the guy who gets it ;)
 35 2011-09-25 00:38:50 <mindphlux> I wouldn't pay out any winnings because his deposit has been never confirmed
 36 2011-09-25 00:39:07 <luke-jr> mindphlux: so he'll make new accounts every time
 37 2011-09-25 00:39:26 <phantomcircuit> i dont think he gets it
 38 2011-09-25 00:39:34 <mindphlux> Just trying to understand
 39 2011-09-25 00:39:37 <mindphlux> Bear with me.
 40 2011-09-25 00:41:23 <mindphlux> I'll just leave it at at least 3 confirmations
 41 2011-09-25 01:17:20 <casascius> just got here and read regarding letting someone gamble with 0 confirmations.  it sounds like a novel idea.  if he loses, you most likely still got his money.  but more importantly, if you can wrap HIS tx into the payment of his winnings, then if he were to successfully doublespend, he would void the entire transaction paying him out
 42 2011-09-25 01:18:13 <mindphlux> casascius: I decided against it, until I let someone explain it to me in full detail
 43 2011-09-25 01:18:22 <soap> you say "if" - is this a hard problem (to wrap his tx in to the payment of his winnings)?
 44 2011-09-25 01:18:46 <casascius> in the current client it is... but not with the magic rpc calls i frequently ask for =)
 45 2011-09-25 01:18:49 <soap> won't using a separate wallet per player solve this?  Or is that needless?
 46 2011-09-25 01:19:25 <casascius> if the client offered a "query all transactions benefiting these addresses", then when you go to pay out...
 47 2011-09-25 01:19:38 <soap> (or #2) am I missing something fundamental?
 48 2011-09-25 01:19:45 <casascius> you simply run the query to find the transaction for his recent unconfirmed payment.
 49 2011-09-25 01:20:12 <casascius> then in your own code, build a transaction that incorporates his txid along with your own money to total his winnings...
 50 2011-09-25 01:20:24 <casascius> and then use my imaginary rpc call to send the transaction back to the p2p network
 51 2011-09-25 01:20:42 <casascius> "query all transactions benefiting these addresses" requires my pet index
 52 2011-09-25 01:21:20 <mindphlux> I agree it was a novel idea
 53 2011-09-25 01:21:23 <mindphlux> Had this earlier today
 54 2011-09-25 01:21:26 <casascius> so you would do this scheme instead of just "Sendtoaddress" which would virtually guarantee his winnings got paid out of YOUR money and that you'd be stuck with any doublespend
 55 2011-09-25 01:21:28 <mindphlux> but it turns out I'm playing with fire
 56 2011-09-25 01:21:49 <gmaxwell> casascius: you can always just delay payout when someone wins.
 57 2011-09-25 01:22:48 <gmaxwell> Ideally you want to keep a temporary balance internally making the result of every gamble visible to the blockchain is an unreasonable load on the globally visible bitcoin network and also doesn't do well for increasing the users privacy.
 58 2011-09-25 01:23:25 <casascius> gmaxwell: agree, and probably gets expensive with transaction fees too
 59 2011-09-25 01:24:08 <gmaxwell> Espeically since that model mandates you are constantly short-roundtripping funds, which makes the txn objectively look like a dos attack.
 60 2011-09-25 01:24:38 <casascius> one can delay payout, but if one can wrap the original inputs of a "winner" into an output transaction, he can virtually guarantee immunity to all attacks of the "double-spend to rob the casino" nature regardless of the block height
 61 2011-09-25 01:25:36 <gmaxwell> Yes, you can, and thats a neat optimization regardless of how you groom or delay payouts. Still, it's terrible for privacy.
 62 2011-09-25 01:26:07 <gmaxwell> (and face it, a major use of casinos is to make flows of funds more confusing to trace)
 63 2011-09-25 01:28:12 <casascius> I am thinking re: the mini private key thing - that it would probably be best not to officially support any kind of sha256 mini private keys in the client (which, yes, would eliminate my casascius coins from being redeemable directly in the client)
 64 2011-09-25 01:28:28 <casascius> Which might sound surprising coming from me
 65 2011-09-25 01:29:07 <casascius> And also, for a mini private key that IS supported, completely eliminating the typo check.  (the typo check would become: if the address doesn't have bitcoins, the typo check failed.)
 66 2011-09-25 01:29:07 <gmaxwell> I was warming up pretty well to the idea once you indicated a willingness to stick to >128 bits of entropy.
 67 2011-09-25 01:29:37 <casascius> So, anyway, here is WHY.
 68 2011-09-25 01:29:52 <casascius> I do think SHA256-based codes will exist.
 69 2011-09-25 01:30:01 <casascius> Because hopefully they will be trivial to redeem with a web redeemer.
 70 2011-09-25 01:30:10 <casascius> But official support in the client says something else.
 71 2011-09-25 01:30:38 <casascius> If the only minikey supported by the client were a strong one that had > 128 bits, it would successfully DISCOURAGE people from doing sha256 keys.
 72 2011-09-25 01:31:05 <casascius> Websites (mtgox, marketplace, etc.) could still accept sha256 keys if they wanted to - simply by doing the calculation in their website before passing it on to bitcoind.
 73 2011-09-25 01:31:19 <casascius> But if the strongest form of minikey were the one de-facto in the client, it would STRONGLY encourage people to use it.
 74 2011-09-25 01:31:29 <gmaxwell> Well, web-redeemer basically says that it's okay to deal with private key material with a webpage. Thats a bad message to send.
 75 2011-09-25 01:31:31 <casascius> On the other hand, I can see the problem with STRONGLY encouraging people to use sha256 codes.
 76 2011-09-25 01:31:42 <gmaxwell> casascius: you're making an argument for including it.
 77 2011-09-25 01:32:12 <casascius> Web-redeemer will be OK for my limited run of a few thousand BTC, only a few of which will be torn open.  Guarantee the next run will use the stronger algorithm.
 78 2011-09-25 01:32:31 <gmaxwell> If you're going to web-redeem then there is no reason to put a privatekey on the coin at all.
 79 2011-09-25 01:32:59 <gmaxwell> Just have a page that makes a payment to the users choice of address when they redeem an ID written on the coin.
 80 2011-09-25 01:33:09 <casascius> Other than if it's not the private key, they don't really have a bitcoin, all they have is a promise from me and that's not the same.  What if I disappear?
 81 2011-09-25 01:33:32 <gmaxwell> That situation already exists, because as far as anyone can tell you've kept the private keys.
 82 2011-09-25 01:33:47 <gmaxwell> If you get hacked or decide to disappear you might just take all of them with you.
 83 2011-09-25 01:34:12 <casascius> It does exist, but there is a decent difference between me actively stealing them (something that incurs a real life liability for me), versus me disappearing and making bagholders out of my customers
 84 2011-09-25 01:34:12 <gmaxwell> Even if you haven't kept them, the webpage you provide could simply start stealing them when people use it.
 85 2011-09-25 01:34:29 <gmaxwell> It can do that even if its been audited, because its a webpage and you can change it at any time.
 86 2011-09-25 01:34:49 <gmaxwell> You're correct, I'm just pointing out that the difference isn't as great as it might seem on first blush.
 87 2011-09-25 01:35:16 <casascius> It may not be a terrible idea to put in the client IF it can be discouraged...
 88 2011-09-25 01:35:34 <casascius> For example, if the client were to accept 22-char SHA256's as keys...
 89 2011-09-25 01:35:57 <casascius> then it may be worthwhile to simply drop the requirement for the leading 'S' and the 7 bit check, and simply say that it's any 22 characters and the check is, "if it has btc, it's valid"
 90 2011-09-25 01:36:02 <casascius> That would put it >128 bytes
 91 2011-09-25 01:36:04 <casascius> *bits
 92 2011-09-25 01:36:42 <casascius> that's 128 bits not encumbered by a crc scheme
 93 2011-09-25 01:37:07 <gmaxwell> But then people would use "Thisisabitcoin000000.000" which is pretty terrible.
 94 2011-09-25 01:37:20 <casascius> gmaxwell: 100% agreed...which sort of led me to say, forget SHA256.
 95 2011-09-25 01:37:31 <gmaxwell> (especially if there isn't an obnoxious amount of strenghtening)
 96 2011-09-25 01:38:01 <casascius> (of course, someone could also do "thisisabitcoin00000000q" even with the strongest derivation algorithm, nothing specific to sha256)
 97 2011-09-25 01:38:15 <casascius> i put the "q" to suggest that they probably need only set 1 character to make the crc pass
 98 2011-09-25 01:39:02 <gmaxwell> Yes, strong derivation just makes it harder to run a dictionary through it to look for addresses with coins. At least with the CRC they'd have to try (and remember a character that they didn't choose)
 99 2011-09-25 01:39:17 <gmaxwell> 'CRC' (of course)
100 2011-09-25 01:40:10 <casascius> Hopefully no one will bother trying to generate "vanity" private keys.  They are not quite as useful as vanity addresses, because no one but their owner sees them...
101 2011-09-25 01:40:43 <casascius> I couldn't see someone going out of their way to download a utility explicitly designed to help them make a weak password when they could just as well use a deterministic wallet with , say, a 30 character passphrase
102 2011-09-25 01:40:44 <gmaxwell> Vanity is a bit less of an issue than "totally user memorized text".
103 2011-09-25 01:41:21 <casascius> just curious, do you see the client as having any sort of future with respect to deterministically generated wallets?
104 2011-09-25 01:42:14 <gmaxwell> Not purely passphrase based ones. But sure, I'd like to see it using that in the future. There are some counterarguments, but I feel they're outweighed by the benefits.
105 2011-09-25 01:42:20 <casascius> I used a deterministic wallet to generate the addresses I'm using on my casascius bitcoin website.  I have the comfort of knowing that there's very little possibility that my bitcoins could get stolen because I know the passphrase
106 2011-09-25 01:42:27 <casascius> *or lost too
107 2011-09-25 01:42:35 <casascius> and there are no private keys on the server
108 2011-09-25 01:43:13 <gmaxwell> Thats false comfort. Your passphrases will almost certantly have terrible entropy, even if you used good practices (and the commonly advised practices aren't actually all that good)
109 2011-09-25 01:43:26 <casascius> even at 40+ characters?
110 2011-09-25 01:43:39 <gmaxwell> Even at 40+ characters.
111 2011-09-25 01:44:01 <casascius> given enough characters, even plain text starts to have plenty of entropy assuming it still has enough nonsense in it that makes it non-dictionary
112 2011-09-25 01:44:34 <phantomcircuit> http://www.fourmilab.ch/random/
113 2011-09-25 01:44:36 <phantomcircuit> give it a try
114 2011-09-25 01:44:46 <gmaxwell> The usual ways people add nonsense hardly increase the entropy at all. Almost always they'll meet that kind of requirement by adding a '!' to the end, or the like.
115 2011-09-25 01:45:10 <casascius> i can certainly agree with that
116 2011-09-25 01:45:24 <gmaxwell> casascius: In any case a good passphrase plus 128 bits of solid entropy gives you security that no one can argue with... and that even a moronic user can't screw up.
117 2011-09-25 01:46:00 <casascius> so basically...deterministic wallets are a fantastic idea except for exactly one problem, the user
118 2011-09-25 01:46:03 <casascius> =)
119 2011-09-25 01:46:08 <gmaxwell> Not so.
120 2011-09-25 01:46:25 <casascius> There's more than one problem?  Or less? =)
121 2011-09-25 01:46:41 <gmaxwell> You can simply use a passphrase + random string with enough entropy. There you go, fully determinstic wallet.
122 2011-09-25 01:47:24 <gmaxwell> Don't conflate determinstic wallet with passphrase based wallet. You can have the former without the latter.
123 2011-09-25 01:47:25 <casascius> How does the user ideally persist the random string?
124 2011-09-25 01:47:45 <casascius> gotcha
125 2011-09-25 01:48:07 <gmaxwell> By storing it on disk, and backing it up on paper... they could just write down 16 short english words that encode it, or a base36 version if you like.
126 2011-09-25 01:48:42 <casascius> What do you think about the notion that storing it on disk puts it at risk?  (he'd need to encrypt it with yet another secure key.... a catch 22)
127 2011-09-25 01:48:42 <gmaxwell> The passphrase protects it from theft even if the disk isn't protected.  The data protects it against dictionary attacks (and accidental duplication!)
128 2011-09-25 01:49:04 <gmaxwell> It's no more risky than a purely passphrase based system alone.
129 2011-09-25 01:49:33 <gmaxwell> (at worst, in practice it's far more secure, since everyone has some security on their disk it's not available to the general public)
130 2011-09-25 01:49:47 <casascius> Tell me what you think of this idea (it's for average joe to securely generate a wallet even though we know average joe isn't security conscious).
131 2011-09-25 01:50:14 <casascius> Imagine I run XYZ wallet protection service.  (eye rolling time)
132 2011-09-25 01:50:22 <casascius> But here is how my service works.
133 2011-09-25 01:50:22 <gmaxwell> (not just not security conscious, he also just doesn't know enough and also can't correctly assess the risks)
134 2011-09-25 01:50:39 <casascius> My job is to ensure that the only person with the complete key to joe's bitcoins is joe.
135 2011-09-25 01:50:50 <casascius> Not the guy who rooted his box, and certainly not me.
136 2011-09-25 01:51:26 <casascius> As part of my wallet protection service, someone else maintains an open source bitcoin client that has built-in features to take advantage of my service.
137 2011-09-25 01:51:49 <casascius> And here is how key generation works.
138 2011-09-25 01:51:57 <casascius> I generate some private keys, and Joe generates some private keys.
139 2011-09-25 01:52:06 <casascius> We share with one another the public keys.
140 2011-09-25 01:52:32 <casascius> With both of those public keys, we hash them together with ripemd160(sha256()) to form bitcoin addresses.
141 2011-09-25 01:53:13 <casascius> Given that the only thing that really defines what a bitcoin address is whatever comes right before OP_HASH160
142 2011-09-25 01:53:21 <casascius> nothing says that the bitcoin address has to be the hash of a pubkey.
143 2011-09-25 01:53:31 <casascius> It could be a hash of two pubkeys concatenated together.
144 2011-09-25 01:53:41 <casascius> Anyway, for joe to spend his funds, he goes into this special client and whips up a transaction just like normal.
145 2011-09-25 01:53:47 <casascius> But this transaction needs 2 signatures.
146 2011-09-25 01:54:16 <casascius> The special client makes an api call to my XYZ wallet protection service, and basically says... Here is a transaction from Joe to asdfasdfasdf signed by Joe, just waiting for your signature.
147 2011-09-25 01:54:26 <gmaxwell> I guess you're not aware that we have this functionality already to be merged, accept for the special address type  and thats mostly just delayed because there was some argument about how flexible it should be?
148 2011-09-25 01:54:39 <casascius> As part of my services, I send joe an SMS and make sure it's legit...then I sign...then voila.
149 2011-09-25 01:54:51 <casascius> I am aware the functionality has been discussed, but am not aware of a merged status.
150 2011-09-25 01:55:04 <gmaxwell> https://github.com/groffer/bitcoin/commit/dc2dfbab6a0f75070fc3b962da4eb2967e9659df
151 2011-09-25 01:55:06 <casascius> I am aware up to the extent that there is consideration being made to modify IsStandard
152 2011-09-25 01:55:13 <gmaxwell> It's the secured funds usecase there.
153 2011-09-25 01:55:36 <casascius> but the only problem is that all of those funds have to be "secured" before they become "secure"
154 2011-09-25 01:56:10 <casascius> and any time new funds roll in, unless they're pre-secured by the sender, somebody has to go back and secure them or they're not secure...
155 2011-09-25 01:56:19 <gmaxwell> The question is should the address type only allow 2of2 / 2of3 transactions, or should it allow the full RPN ruleset where someone can specify a full boolean logic statement about what mixtures of keys are allowed to spend from the escrow.
156 2011-09-25 01:56:41 <casascius> when you say the address type, do you mean the bitcoin address?
157 2011-09-25 01:56:43 <gmaxwell> Yes, thats all been discussed on the list, I wish I knew how to link to the archives.
158 2011-09-25 01:57:19 <gmaxwell> casascius: yes, you'd need a new address type so that the sender knows to write the special requirements into the output they write.
159 2011-09-25 01:57:25 <casascius> I am somewhat familiar with the discussion because gavin posted something in the forums a while back about inventing a new kind of bitcoin address that was twice as long and incorporated two privkeys and I said boo
160 2011-09-25 01:57:27 <gmaxwell> And in that address you can encode the required rules.
161 2011-09-25 01:58:25 <gmaxwell> It expanded abit because we realized you could easily encode arbitrary rules.  Like (A and B) or (C and D) (where the letters are addresses)
162 2011-09-25 01:58:27 <phantomcircuit> it's my understanding that the movement related to n of m transactions has been mostly due to his involvement with trucoin
163 2011-09-25 01:58:41 <casascius> by boo, i had the following to say... #1 that it was a very big expense in the minds of users...users would suddenly need to know why people had 2 addresses, a short one and a really long one
164 2011-09-25 01:58:49 <phantomcircuit> ie they want to offer escrow services for bitcoin using n of m transactions and gavin has pushed those forward
165 2011-09-25 01:58:54 <phantomcircuit> which seems kind of scummy
166 2011-09-25 01:59:17 <casascius> and that #2 it made the addresses almost completely infeasible for any kind of printed medium.... to fit one of those addresses in a QR code you'd need it to be huge
167 2011-09-25 01:59:48 <gmaxwell> well, better than the argument you could make in the past that gavin's prior escrow service was retarding N of M because those largely reduce the role of an escrow service.
168 2011-09-25 02:00:21 <gmaxwell> "why people had 2 addresses" ugh! thinking that people 'have' a single address is a terrible thing.
169 2011-09-25 02:00:24 <casascius> I had a proposal to make a modification to OP_CHECKSIG, in fact I pastebinned "pseudo code", the point of which was to enable n of m transactions in the form of bitcoin addresses that still remained well-formed base58 bitcoin addresses based on 160 bit ripemd hash
170 2011-09-25 02:00:32 <gmaxwell> Generally bitcoin addresses should be single shotish.
171 2011-09-25 02:00:58 <phantomcircuit> gmaxwell, he said he stopping running clearcoin specifically because he didn't feel comfortable holding all of those bitcoins himself
172 2011-09-25 02:01:09 <gmaxwell> casascius: you'd still need to know you have to change your output script type, it sounds like you're describing something impossible there.
173 2011-09-25 02:01:11 <phantomcircuit> gmaxwell, n of m would address that issue so he is no longer liable
174 2011-09-25 02:01:22 <casascius> aha...and that's the meat of my proposal.
175 2011-09-25 02:01:22 <gmaxwell> phantomcircuit: well, it's good functionality regardless.
176 2011-09-25 02:01:37 <phantomcircuit> gmaxwell, true but it still seems scummy
177 2011-09-25 02:01:42 <casascius> the meat of my proposal with respect to avoiding the need to change your output script type.
178 2011-09-25 02:02:03 <gmaxwell> casascius: thou shall not break the blockchain by changing the validation logic, either.
179 2011-09-25 02:02:58 <casascius> I shall not break the block chain for me... but what I had essentially proposed was to make the change only for testnet.  (Since it will be a long time before XYZ wallet service ever exists).
180 2011-09-25 02:03:23 <casascius> And to flip the switch only when some other unforeseen circumstance necessitated some forking change to the block chain (sort of what just got whopped on namecoin just recently)
181 2011-09-25 02:04:06 <gmaxwell> as far as QR codes go, we're only talking about ~2x the size of normal addresses for the 2 of 2 case.
182 2011-09-25 02:04:08 <casascius> Does that put it beyond the threshold of consideration?
183 2011-09-25 02:04:13 <phantomcircuit> XYZ wallet service?
184 2011-09-25 02:04:41 <casascius> I am thinking the ideal safety would be a 3-key deal.  With 2 private keys, if XYZ goes under, Joe's screwed out of all his BTC
185 2011-09-25 02:05:28 <casascius> Ideally, it's (A AND B) OR C... key A is on joe's computer...key B is on my XYZ wallet service... and key C is a deterministically generated key, Joe has the seed in his safe, and it's his failsafe against my failure to exist
186 2011-09-25 02:05:36 <gmaxwell> casascius: it's not clear to me how you'd do subsets with what you've described.
187 2011-09-25 02:05:59 <casascius> I'm not sure I understood what you meant by subsets
188 2011-09-25 02:06:27 <gmaxwell> okay I see a way to do it.
189 2011-09-25 02:07:16 <gmaxwell> So you'd provide all three public keys when you spend that input, and then signatures for either A&B or C, and the software would just know (based on the address type) that this was okay.
190 2011-09-25 02:07:59 <gmaxwell> It sounds okay, except it requires breaking the blockchain. Such a change is unlikely to happen any time soon, and when it does happen I wouldn't be surprised to see if it came with a cryptosystem change that made addresses longer than you think is viable in any case. :)
191 2011-09-25 02:08:03 <casascius> exactly
192 2011-09-25 02:08:21 <nanotube> afaik, problem with making funky addresses that are a combination of multiple keys is that currently the concat op is disabled in script
193 2011-09-25 02:08:26 <casascius> No one saw the Namecoin change coming...and besides, we can wait a very long time with this.
194 2011-09-25 02:08:30 <nanotube> so making those a reality would require forking the chain
195 2011-09-25 02:08:43 <casascius> my proposal wouldn't depend on the concat op
196 2011-09-25 02:08:45 <gmaxwell> It also makes the spend transactions unfortunately big, and also gives an attacker a very nice degree of freedom, though if the 'address' is big enough it doesn't matter.
197 2011-09-25 02:09:12 <nanotube> casascius: didn't you mention something about the combination address being a hash of a concat of multiple keys/hashes?
198 2011-09-25 02:09:13 <gmaxwell> casascius: if it doesn't depend on the concat op it still depends on the moral equivilent.
199 2011-09-25 02:09:38 <casascius> nanotube: yep, but the way i see it, the concatenation would occur by the spend transaction emitting multiple pubkeys already pre-concatenated together
200 2011-09-25 02:09:43 <casascius> in place of a single pubkey
201 2011-09-25 02:09:54 <casascius> in other words...if a pubkey is a blob of bytes... I just mean a bigger blob of bytes.
202 2011-09-25 02:10:02 <nanotube> but it all needs to be validated
203 2011-09-25 02:10:06 <nanotube> at /some/ point
204 2011-09-25 02:10:20 <casascius> nanotube: yep, let me find my pastebin link to the pseudo code where i describe how that validation takes place
205 2011-09-25 02:10:26 <phantomcircuit> lol wow
206 2011-09-25 02:10:47 <casascius> http://pastebin.com/5aR9EGcn
207 2011-09-25 02:10:51 <phantomcircuit> gbp spread on intersango overlaps with the mtgox spread
208 2011-09-25 02:10:58 <phantomcircuit> someone running arb could make decent money
209 2011-09-25 02:11:22 <casascius> in this case, I have literally renamed OP_CHECKSIG to OP_CHECKSIGEX and called it check signature expression.  And redefined a blob containing one pubkey as an expression that evaluates, well, one pubkey.
210 2011-09-25 02:11:46 <casascius> Caps are my additions (in the pastebin)
211 2011-09-25 02:12:05 <gmaxwell> What I mean by 'degree of freedom' for an attacker is this, btw: you pay a zillion btc to one of those addresses. I generate a key, put it in the C role, and use it to sign a txn spending those coins, then I search for random numbers A/B to make the hash match. Since A+B >>160 bits I can be pretty sure a solution exits.  Though I'd need a quantum computer to do the search in practice, it's still a new vulnerablility we don't have today.
212 2011-09-25 02:12:14 <nanotube> phantomcircuit: if they overlap, that means no arb. there's only arb if they don't overlap
213 2011-09-25 02:12:35 <phantomcircuit> i guess i mean they're shifted?
214 2011-09-25 02:12:39 <phantomcircuit> i dont know what i mean
215 2011-09-25 02:12:50 <nanotube> phantomcircuit: you mean, the don't overlap, then :)
216 2011-09-25 02:13:01 <casascius> gmaxwell: If you have the capability of finding x such that ripemd160(sha256(x)) = the value of your choice, you already can spend any bitcoin on the whole blockchain without any help.  How would this feature change anything?
217 2011-09-25 02:13:38 <forrestv> i was thinking that addresses could be reimplemented as being the hash of the check script, rather than the hash of the pubkey
218 2011-09-25 02:13:41 <gmaxwell> casascius: today X also must be a valid ecc public key for which you hold the private key.
219 2011-09-25 02:14:23 <gmaxwell> forrestv: hard to know when someone has given you coins, because they might have used a script you weren't expecting.
220 2011-09-25 02:14:54 <forrestv> ah, true
221 2011-09-25 02:15:40 <casascius> gmaxwell: OK, I understand what you're saying by taking away the ecc... I suppose I would argue that in the process, it would take away a real problem we have today, and that's that the news is full of reports about how bitcoin is insecure and how everyone is getting their funds stolen...
222 2011-09-25 02:16:12 <casascius> that the odds of joe losing his bitcoins due to malware is far more probable than the odds of a technology advance that breaks ripemd160(sha256(x)) wide open
223 2011-09-25 02:16:26 <gmaxwell> casascius: one method I use for evaluating the security of proposals is that I ask myself "if we happened to pick the most, restospectively, unluckly design like this and happened to be using MD5 or MD4 algorithims, how screwed would be be right now"
224 2011-09-25 02:17:17 <gmaxwell> And I think that design fails that test, we'd be totally screwed if they could put the junk bytes at the end for md5. But our current system would be completely fine at the moment, because the md5 attacks won't let you pick collissions that happen to be ecc public keys for which you know the private key.
225 2011-09-25 02:18:03 <gmaxwell> And I think it's prudent design to assume that there _will_ be advances that make sha256 and perhaps the composition bitcoin uses for addresses just as weak as md5 is today.
226 2011-09-25 02:19:23 <casascius> If you did this brute forcing, wouldn't A and B have to at least be valid points on the elliptic curve, not just junk bytes you generated incrementally?
227 2011-09-25 02:20:06 <casascius> (not in my pseudo code, but not something that couldn't be added)
228 2011-09-25 02:20:06 <gmaxwell> Only if you stipulated that the validation check that A/B look like valid public keys even if you're only spending with C.  But hey, thats a good point. :)
229 2011-09-25 02:20:47 <gmaxwell> (and thats the kind of good thinking that comes out of this style of paranoid design)
230 2011-09-25 02:21:25 <gmaxwell> If we were to break bitcoin to add a validation type we really should add key recovery.
231 2011-09-25 02:21:26 <casascius> I am not sure how hard it is to generate points-on-a-curve, but i suppose it's better than nothin'
232 2011-09-25 02:21:45 <gmaxwell> (by key recovery I mean recovering the ecc public key from the address and the signature)
233 2011-09-25 02:22:04 <gmaxwell> casascius: yea, it's really trivial, but even that little would probably break the current md5 attacks.
234 2011-09-25 02:22:27 <casascius> what is your idea of key recovery?
235 2011-09-25 02:23:26 <gmaxwell> oh, it's possible if you have data+signature to decode the public key from it. Then you make sure the decoded public key matches the addresses you were expecting. It would reduce the size of normal bitcoin txn by 1/3rd and two sign txn by halfish.
236 2011-09-25 02:24:02 <gmaxwell> (Satoshi probably didn't know that this was possible)
237 2011-09-25 02:24:27 <gmaxwell> It's also possible that certicom has patented it, but I don't believe so. Someone would do well to search to get more confidence on that point.
238 2011-09-25 02:25:13 <casascius> That's interesting, that would be a cool way to chop down the resource requirements
239 2011-09-25 02:25:22 <casascius> is it slow?
240 2011-09-25 02:25:34 <casascius> (compared to say, validating the signature)
241 2011-09-25 02:25:43 <gmaxwell> A little bit. Figure it doubles the validation cost.
242 2011-09-25 02:26:28 <gmaxwell> Though our ecc implementation is far from the fastest possible one in any case. Openssl's code is generic and somewhat speed optimized but not excessively so.
243 2011-09-25 02:27:24 <gmaxwell> The space savings gets important if you're talking about having three keys (or more) on transactions.
244 2011-09-25 02:28:11 <casascius> definitely agree, however, it probably wouldn't work in situations where you don't need all three signatures.  You need all 3 pubkeys to validate the hash, but won't be having all 3 signing the transactions
245 2011-09-25 02:28:25 <gmaxwell> also, in your design I'd avoid providing the keys for anything but the ones being used. The unused keys should be provided as addresses and the hash should be over the addresses not the keys.
246 2011-09-25 02:28:35 <gmaxwell> casascius: you provide the addresses of the keys you aren't using.
247 2011-09-25 02:28:52 <gmaxwell> or rather you provide all addresses, and you recover the public keys of the ones you use.
248 2011-09-25 02:28:59 <casascius> that'd work
249 2011-09-25 02:29:06 <casascius> i suppose it would be a completely different script output type
250 2011-09-25 02:29:12 <casascius> a different op_checksig
251 2011-09-25 02:30:02 <gmaxwell> Yep. but that sort of thing is no big deal if you're already committed to breaking the chain.
252 2011-09-25 02:31:12 <casascius> hashing over the addresses instead of the keys would probably be a pretty great idea...i suppose it would need a different script output
253 2011-09-25 02:31:23 <casascius> (but one that would be compatible with making all normal transactions use it)
254 2011-09-25 02:32:37 <casascius> just thinking here...
255 2011-09-25 02:32:57 <casascius> if instead of scriptsig being signature then pubkey...
256 2011-09-25 02:33:04 <casascius> there would just be signature_blob
257 2011-09-25 02:33:30 <casascius> if it was an (A AND B) OR C transaction, signature blob would contain three things
258 2011-09-25 02:33:42 <casascius> those three things could either be a signature, or a bitcoin address.
259 2011-09-25 02:34:34 <casascius> There would have to be some hash op that turned those into a new blob.
260 2011-09-25 02:34:52 <casascius> so, first OP_DUP the blob so we have two copies of it, one for signature checking, one for comparing it with the hash.
261 2011-09-25 02:35:39 <casascius> Imagine OP_HASH160GROUP turned that blob of 3 things into a new blob of 3 things: hashes left unchanged, but signatures turned into ripemd160(sha256(pubkey)).
262 2011-09-25 02:36:05 <casascius> then OP_HASH160 would produce a single 160 bit hash on the three bitcoin addresses.
263 2011-09-25 02:37:08 <casascius> so, OP_DUP OP_HASH160GROUP OP_HASH160 (bitcoinaddress) OP_EQUALVERIFY OP_CHECKSIGEX
264 2011-09-25 02:38:21 <casascius> the question is, does this eliminate the opportunity for somebody to bruteforce A and B... it almost seems it would.
265 2011-09-25 02:38:34 <casascius> Or would not, rather, the problem would still exist.
266 2011-09-25 02:39:16 <casascius> You provide all the addresses, but there's no constraints on what A and B are.
267 2011-09-25 02:39:51 <casascius> You could provide your own C and a signature for it, and bruteforce random bytes in place of A and B and get away with it, couldn't you?
268 2011-09-25 02:41:02 <casascius> The OP_CHECKSIG(EX) is going to pass based on your C, the only thing in your way is OP_EQUALVERIFY on the hash160, and you have a spot where you can put junk input into the hash that doesn't need to satisfy any constraint
269 2011-09-25 02:43:12 <gmaxwell> Yep, alas, but we made the txn much smaller. Looks like a tradeoff.
270 2011-09-25 03:04:26 <casascius> OP_SIGTOKEY
271 2011-09-25 03:05:53 <casascius> pop a signature off the stack and replaces it with the private key that would have produced that signature
272 2011-09-25 03:06:24 <gmaxwell> casascius: public key,  such an op needs to also know the address you're expecting that key to have.
273 2011-09-25 03:06:45 <gmaxwell> (because the procedure has one bit of ambiguity, there are two possible keys, and you'll use the address to disambiguate them)
274 2011-09-25 03:06:53 <gmaxwell> (well, sometimes two possible keys)
275 2011-09-25 03:06:55 <casascius> yep... OP_DUP OP_SIGTOKEY OP_HASH160 (constant) OP_EQUALVERIFY
276 2011-09-25 03:07:11 <casascius> hmm
277 2011-09-25 03:08:28 <casascius> for each OP_SIGTOKEY run the script twice, each iteration doing "this" versus "that" key?
278 2011-09-25 03:08:40 <casascius> and accepting it if any of them passes?
279 2011-09-25 03:09:26 <casascius> e.g. if there's three OP_SIGTOKEY, script would run up to 8 times, each with a different combination of OP_SIGTOKEY outputs
280 2011-09-25 03:10:23 <gmaxwell> Thats ugly. Just make it take a list of acceptable addresses and have it reorder the list based on what was used.
281 2011-09-25 03:11:46 <casascius> The way I described it is ugly... it would merely be a recursive algorithm where the code for OP_SIGTOKEY recursively calls someting to process the remainder of the script, but does so twice, first with a parameter of 0, second with a parameter of 1
282 2011-09-25 03:11:53 <casascius> and it saves valuable transaction space
283 2011-09-25 03:12:50 <gmaxwell> Hiding that detail from the script is better.
284 2011-09-25 03:13:50 <casascius> not sure I understood what would be hidden
285 2011-09-25 03:14:29 <casascius> if we're trying to save space, wouldn't giving a list of acceptable addresses be undoing that quite a bit?
286 2011-09-25 03:14:36 <gmaxwell> figuring out which signatures match to witch keys.
287 2011-09-25 03:15:49 <gmaxwell> I see what you're saying, I'll have to think about that some.
288 2011-09-25 03:15:52 <copumpkin> I prefer wizard keys
289 2011-09-25 03:15:57 <gmaxwell> hehe
290 2011-09-25 03:16:05 <copumpkin> or maybe warlock keys, since they sound badass
291 2011-09-25 03:16:25 <casascius> We already know what address we're expecting anyway, it should appear later in the script
292 2011-09-25 03:16:53 <casascius> (at least in the case of a 1-address transaction, not m of n)
293 2011-09-25 03:34:33 <casascius> random question...I know i could find this if I look...can anyone tell me off the top of their head what bitcoind sits and does for about two minutes each time you start it?
294 2011-09-25 03:34:43 <casascius> (before it becomes responsive to RPC commands, even help)
295 2011-09-25 03:36:37 <neofutur> updating the blockchain
296 2011-09-25 03:37:31 <casascius> against peers?
297 2011-09-25 03:38:15 <luke-jr> s/updating/loading
298 2011-09-25 03:38:29 <gmaxwell> Loading the addresses most likely.  Look at the logs.
299 2011-09-25 03:40:00 <casascius> oh yep.... Loaded 241349 addresses 69510ms
300 2011-09-25 03:40:35 <casascius> this means bitcoin addresses? or peer addresses?  (241349 seems like too many peers but not enough addresses)
301 2011-09-25 03:42:43 <gmaxwell> Peer addresses.
302 2011-09-25 03:43:10 <casascius> are there really 240,000+ peers on the bitcoin network?
303 2011-09-25 03:43:11 <gmaxwell> It's too many because it never forgets them and it rumors them, and various nodes have been running on dynamic IPs for a long time, so...
304 2011-09-25 03:43:27 <casascius> so i could delete this file and get a better startup time each time i compile
305 2011-09-25 03:45:46 <casascius> blkindex.dat.... this is simply a mapping of block hashes to their respective offsets in blk0001.dat?
306 2011-09-25 03:46:07 <gmaxwell> casascius: no, transaction ids to offsets too.
307 2011-09-25 03:46:17 <gmaxwell> and yes, feel free to delete addr.dat.
308 2011-09-25 03:46:38 <casascius> if i delete blkindex.dat but not blk0001.dat does it rebuild the index?
309 2011-09-25 03:46:39 <gmaxwell> If you delete blkindex.dat you'll need to fetch the blockchain again, I don't think it can rebuild it from the blk0001.da
310 2011-09-25 03:49:00 <casascius> does blkindex.dat also keep flags on which txids are spent vs unspent?
311 2011-09-25 03:49:40 <Toawa> I don't know if anyone is awake... I had an idea for something to add to the protocol and figured this would be a good place to air it...  Ok, I guess at least one person is awake...
312 2011-09-25 03:54:49 <ThomasV> casascius: I have a question concerning your deterministic wallet. if I own a set of addresses generated from a seed, can I infer the seed, or can I generate other addresses that would be generated with the seed ?
313 2011-09-25 03:55:19 <casascius> thomasv: mine as implemented in Casascius Bitcoin Utility? or just in the abstract?
314 2011-09-25 03:55:32 <casascius> You should not be able to infer the seed
315 2011-09-25 03:55:58 <Toawa> Essentially, it would be a "return address", incorporated as some recognizable bit of info in the signatureScript, (guarded by an OP_DROP like any other arbitrary data), which could be used to inform the destination of a return address to send funds, if necessary.  It would be useful in situations where there might be change/refunds forthcoming to the payer, but having them provide a...
316 2011-09-25 03:56:00 <ThomasV> did not know there are several versions of it
317 2011-09-25 03:56:00 <Toawa> ...separate address manually would be difficult, such as when paying a bill at a location with a mobile phone.
318 2011-09-25 03:56:33 <Toawa> The user could incorporate the return address, which would then be available if it should be needed.
319 2011-09-25 03:56:59 <casascius> toawa: the protocol already would support such a thing, nothing to add
320 2011-09-25 03:57:12 <Toawa> Perhaps protocol wasn't the correct word
321 2011-09-25 03:57:56 <ThomasV> casascius: and my second question?
322 2011-09-25 03:58:16 <Toawa> Protocol in the sense that it's something available in the main client, or the docs, and by its presence make it more likely that others will pick up on it.
323 2011-09-25 03:58:22 <casascius> You would not be able to generate more addresses without knowing the seed
324 2011-09-25 03:58:29 <ThomasV> ok thanks
325 2011-09-25 03:59:04 <Toawa> (So, protocol in the academic sense rather than the technical sense)
326 2011-09-25 03:59:16 <Toawa> (er, sociological sense?)
327 2011-09-25 03:59:22 <casascius> i think most people are against allowing arbitrary data in the blockchain
328 2011-09-25 03:59:38 <Toawa> It's not arbitrary data; it's data with a specific purpose.
329 2011-09-25 04:00:11 <casascius> what would the purpose be? one click return to sender?
330 2011-09-25 04:00:17 <Toawa> Exactly.
331 2011-09-25 04:00:21 <ThomasV> the blockchain is not a communication medium
332 2011-09-25 04:00:51 <Toawa> Of course it is; it's communicating all sorts of transaction information.
333 2011-09-25 04:01:01 <casascius> You could vanity-generate your sending addresses to include some sort of flag that "this address accepts returns"...
334 2011-09-25 04:01:51 <Toawa> That's another possibility, certainly, but not as preferable for at least two reasons...
335 2011-09-25 04:01:56 <gmaxwell> casascius: then people who didn't care about that functionality would randomly end up with it.
336 2011-09-25 04:02:08 <gmaxwell> If you care about that just define some allowable suffix on addresses.
337 2011-09-25 04:02:08 <Toawa> That's #1
338 2011-09-25 04:04:03 <casascius> of course you are kind of blowing your anonymity at the same time
339 2011-09-25 04:04:04 <casascius> it's bad because it takes up my hard disk space and yours and bandwidth and everyone else's just to (maybe) save you a click
340 2011-09-25 04:04:04 <Toawa> The other is vanity address generation is adding more complexity on the user side that should really be necessary...  I don't see how incorporating information into signatureScript is so bad.  And of course, it would be completely optional.
341 2011-09-25 04:04:22 <Toawa> It's not a matter of saving a click
342 2011-09-25 04:04:38 <Toawa> This is aimed more at non-Internet usage.
343 2011-09-25 04:04:52 <ThomasV> non-internet bitcoins?
344 2011-09-25 04:04:56 <gmaxwell> Every byte in bitcoin takes up >40,000 bytes, potentially forever.
345 2011-09-25 04:05:31 <casascius> what purpose would it serve?  you mention paying a bill with a mobile phone...under what circumstances would the bill want to pay you back?
346 2011-09-25 04:06:27 <Toawa> Say, gas or hotel.. Something which, using current credit cards, require holds to be placed on the card.  That's obviously not possible with Bitcoin, so you'd have to pay more than you expect to use, and then recieve the rest later.
347 2011-09-25 04:07:00 <Toawa> I'd also like to know how you come up with 1 byte taking 40k.
348 2011-09-25 04:07:26 <Toawa> If you mean in terms of storage duplication, I don't think that's a fair comparison.
349 2011-09-25 04:07:40 <gmaxwell> Toawa: because its stored by every full validating node. There are 40,000 today. There will hopefully be more than that in the future and forever.
350 2011-09-25 04:07:59 <gmaxwell> And of course, it's transmission duplication as well, since the data has to get to them somehow.
351 2011-09-25 04:08:19 <ThomasV> and there are offline clients
352 2011-09-25 04:08:39 <gmaxwell> Well, offline clients don't need to learn the bodies of txn that don't involve them.
353 2011-09-25 04:08:55 <Toawa> It's unlikely to be used for every transaction.  Storage is cheap, and it's already been said that full block chain storage won't be a requirement forever, for everyone.
354 2011-09-25 04:09:03 <casascius> How would that work?  You pay for gas... and then you have to wait for 6 confirmations anyway before you can pump it?
355 2011-09-25 04:09:18 <Toawa> It's a hypothetical.
356 2011-09-25 04:09:37 <gmaxwell> Toawa: It's not a requirement for everyone, but its still a requirement for a great number of nodes. If we don't have a great number of full validation nodes then bitcoin is not decenteralized anymore.
357 2011-09-25 04:09:54 <ThomasV> gmaxwell: I mean full nodes that are currently offline, and that will catch up with the whole chain when they go online. there's a lot of them
358 2011-09-25 04:10:05 <gmaxwell> ThomasV: ah, okay.
359 2011-09-25 04:10:08 <casascius> (otherwise... you'd prepay 10BTC for gas, pump 1 mL, get 9.99 BTC back, and then execute a doublespend and steal the 9.99 BTC)
360 2011-09-25 04:10:32 <gmaxwell> casascius: tisk tisk, you already solved that one.
361 2011-09-25 04:10:42 <casascius> lol
362 2011-09-25 04:10:55 <Toawa> As I said, storage is cheap.  Bandwidth is getting there.
363 2011-09-25 04:11:22 <casascius> but I didn't solve the pay 10 BTC for gas, pump it all, and then double spend and steal the gas!
364 2011-09-25 04:11:58 <gmaxwell> Toawa: cheap is relative. For a given amount of cheapness I'd rather bitcoin supports more users and mode full validating nodes, than to have a flag which could be sent in some other manner.
365 2011-09-25 04:12:24 <gmaxwell> casascius: you did solve that too.. or rather other people did and you were talking about the same tool earlier.
366 2011-09-25 04:12:49 <casascius> yeah, I'm just being difficult =)
367 2011-09-25 04:12:53 <Toawa> And decentralization doesn't mean everyone has to have everything, just that enough need to have enough.  If bitcoin is ever to get to as lofty a height that some seem to envision it, it'll have to overcome much bigger problems than storage issues.
368 2011-09-25 04:13:02 <gmaxwell> casascius: replace your XYZ wallet securirty with VISA double-spending prevention: "We promise to sign things only once!"
369 2011-09-25 04:13:34 <Toawa> And the people to whom storage really is cheap, will be able to keep everything.
370 2011-09-25 04:14:04 <casascius> yep, it would...assuming the gas pump owner could somehow be assured that I was using XYZ security
371 2011-09-25 04:14:16 <gmaxwell> Toawa: of the technical concerns fast storage is one one of the most difficult, Satioshi was quite concerned that it needed too much as is.
372 2011-09-25 04:14:45 <gmaxwell> casascius: presumably he'd require it, not one particular brand but any of hundreds of fundlocking services.
373 2011-09-25 04:15:04 <casascius> i suppose that would work, interesting application I hadn't thought of
374 2011-09-25 04:15:29 <gmaxwell> It's one of the multisig usecases listed in the readme for that pull request.
375 2011-09-25 04:15:33 <Toawa> He might have done a better job of it, then..  The protocol could easily have incorporated ways to reliably store old unfilled outputs and drop earlier blocks...
376 2011-09-25 04:15:58 <casascius> What's an unfilled output?
377 2011-09-25 04:15:59 <gmaxwell> Toawa: er, it does.
378 2011-09-25 04:16:18 <Toawa> In principle, an old block is no longer needed in full once all outputs are used.
379 2011-09-25 04:16:28 <casascius> not true
380 2011-09-25 04:16:31 <gmaxwell> Toawa: you can drop all spent outputs, and only store the merlek root fragements needed to connected it to the chain.
381 2011-09-25 04:16:41 <Toawa> Exactly.  Hence the "in full"
382 2011-09-25 04:17:06 <casascius> toawa: if you drop a block, the transactions that were inputs to the transactions you dropped suddenly look unspent
383 2011-09-25 04:17:11 <gmaxwell> Sure, but thats some serious reduction at that point.
384 2011-09-25 04:17:14 <gmaxwell> No, it could be done.
385 2011-09-25 04:17:21 <ThomasV> could the invisible hand of the market solve storage issues? if storage becomes too expensive, some miners might decide to not include transactions involving very old blocks, and those who include them may charge more
386 2011-09-25 04:17:24 <gmaxwell> By including a hash of a tree of all open txn in every block.
387 2011-09-25 04:17:28 <Toawa> You'd drop those too, obviously.
388 2011-09-25 04:17:34 <gmaxwell> I proposed to to namecoin so that lite namecoins could exist and be secure.
389 2011-09-25 04:17:41 <Toawa> No, I take that back...
390 2011-09-25 04:18:32 <Toawa> Even so, if you're maintaining your block database, you can make provisions for remembering which outputs go to used-but-dropped blocks.
391 2011-09-25 04:18:47 <gmaxwell> I think Satioshi just didn't think of that, plus it would require more cpu to maintain... and doesn't provide much benefit for bitcoin's usage (though the lack of it in namecoin makes lite nodes impossible to make secure)
392 2011-09-25 04:19:11 <Toawa> CPU isn't the big barrier, though... GPU is.
393 2011-09-25 04:19:21 <gmaxwell> 0_o
394 2011-09-25 04:19:30 <casascius> let's suppose you include a hash of a tree of all open transactions in every block.  You still sort of have to download all of the transactions (including the spent ones) to validate that hash
395 2011-09-25 04:19:35 <gmaxwell> okay, I'm out, no use wasting time to people spouting gibberish.
396 2011-09-25 04:19:35 <Toawa> In the amount of computation per block, the vast majority is going to be in the final sign.
397 2011-09-25 04:19:52 <gmaxwell> Toawa: there is absolutely zero interaction between transactions and block validation.
398 2011-09-25 04:20:05 <gmaxwell> 1 txn, 10,000 txn.. same work for the gpu.
399 2011-09-25 04:20:17 <gmaxwell> Why not go actually read up on how bitcoin works before musing on how it could have been better.
400 2011-09-25 04:20:25 <Toawa> I have.
401 2011-09-25 04:20:30 <casascius> I have thought that a hash would be a good way to keep track of which transactions are spent and unspent, but that would make it very difficult to reliably download the whole block chain
402 2011-09-25 04:21:04 <casascius> suppose block 10000 has 20 transactions.  and as of block 140000, 10 of them are spent.
403 2011-09-25 04:21:13 <Toawa> It doesn't take 10 minutes of CPU to validate a new block.
404 2011-09-25 04:21:15 <casascius> but as of block 139999, only 9 of them are spent.
405 2011-09-25 04:22:00 <casascius> If teh current block is about 140000, some peers might send you the one with 11 transactions left, some might send you the 10.
406 2011-09-25 04:23:00 <casascius> bottom line is you might have a very difficult time validating that "open transactions" hash if even one block isn't consistent due to something being spent off of it while you were downloading the block chain
407 2011-09-25 04:23:11 <Toawa> That's already the case... It would depend on whether the winning block had the new transaction in it or not.
408 2011-09-25 04:23:24 <casascius> does this sound like a bogus concern?  If your hash doesn't match, you have no way of knowing which of your blocks needs something new pruned off of it.
409 2011-09-25 04:23:43 <Toawa> I don't envision downloading pre-pruned blocks
410 2011-09-25 04:23:56 <casascius> toawa: so then pruning blocks helps save your hard disk but not your internet bandwidth?
411 2011-09-25 04:23:57 <Toawa> I envision it as you download whole ones, and then decide yourself what can be pruned.
412 2011-09-25 04:24:11 <Toawa> You were concerned about storage...
413 2011-09-25 04:24:13 <Toawa> Er
414 2011-09-25 04:24:17 <Toawa> gmaxwell was
415 2011-09-25 04:24:21 <gmaxwell> Yes, thats how it has to work.
416 2011-09-25 04:24:23 <gmaxwell> Sadly.
417 2011-09-25 04:24:24 <casascius> Not just storage, but resources in general
418 2011-09-25 04:25:13 <gmaxwell> It could be improved e.g. hash commitments to a tree of open txn, but that would mean that every full node would need to also maintain a particular hash tree structure of open txn.
419 2011-09-25 04:26:38 <casascius> This may not be the best proposal, but I also thought that every 2016 blocks, a "superblock" could be written that contains all of the open transactions.  Once such a block gained sufficient age (due to being confirmed by miners comparing it against the real blockchain), all of the blocks coming before it could be stripped to their 80 byte headers
420 2011-09-25 04:26:45 <Toawa> Ultimately, as long as you're the one deciding what can be pruned, and you trust yourself, and you're not telling anyone else what to prune or not to prune, then it shouldn't matter to others what you do with your pruning...
421 2011-09-25 04:26:59 <gmaxwell> if the system had this, this you could do full validation starting at any block simply trusting that bad open txn hashes wouldn't get many confirmations.
422 2011-09-25 04:27:00 <Toawa> That's basically what I thought of, too.
423 2011-09-25 04:27:34 <gmaxwell> casascius: you don't have to do that, see the hash tree thing I was just describing, every block could confirm the open txn set.
424 2011-09-25 04:27:35 <Toawa> I didn't envision it as a superblock; I was thinking more, if an open txn is older than X, put in an update.
425 2011-09-25 04:27:43 <gmaxwell> for only the cost of a single extra hash.
426 2011-09-25 04:27:51 <gmaxwell> (storage/network wise)
427 2011-09-25 04:28:37 <gmaxwell> but ~log2(open txn) per txn extra sha256 operations on the cpu for all full nodes in order to update the structure.
428 2011-09-25 04:28:42 <casascius> gmaxwell: that would work fantastically...i'm just not sure how the tree thing would help the case where someone received a wrongly pruned block during their blockchain download that made it impossible to arrive at that same hash
429 2011-09-25 04:29:21 <casascius> the tree would certainly help you confirm that if you have the right set, that it really is right...
430 2011-09-25 04:29:31 <casascius> but if you end up with the wrong set, what to do about it to make it right
431 2011-09-25 04:29:35 <gmaxwell> because you can walk the tree a segement at a time to find out where a disagreement is.
432 2011-09-25 04:29:50 <gmaxwell> e.g. it the root disagrees, you ask for the left and right hashes. And so on.
433 2011-09-25 04:30:05 <casascius> so this would be some sort of message between the peers
434 2011-09-25 04:30:36 <gmaxwell> You also wouldn't bother asking for pruned blocks. You'd ask for all the headers, and all the open txn _now_. Then you'd validate the hash, and trust your opentxn set once its been burried a bit.
435 2011-09-25 04:31:01 <gmaxwell> so now you have a full validating node which only knows the headers and open txn... bootstrapped interactively from its peers.
436 2011-09-25 04:31:18 <casascius> i always considered "pruned blocks" to be functionally equivalent to "block headers + open transactions"
437 2011-09-25 04:31:44 <gmaxwell> For bitcoin this isn't so important, but for namecoin its critical, because the most interesting naming attack is creating false negative answers, whereas false negative answers in bitcoin is only a bit annoying.
438 2011-09-25 04:32:19 <casascius> wouldn't a false negative be an opportunity for someone to send  you a payment you won't know is fake?
439 2011-09-25 04:32:33 <gmaxwell> Toawa: uses the bitcoin distributed consensus algorithim to maintain a name/value mapping. Distributed DNS.
440 2011-09-25 04:33:04 <Toawa> Wouldn't that always a risk when receiving low-confirmation coins, anyway?
441 2011-09-25 04:33:29 <gmaxwell> casascius: nope! if your peers tell you an input doesn't exist, then you don't think you were paid. For lite clients you only want your peers to prove to your your payments were mined.
442 2011-09-25 04:33:47 <gmaxwell> er prove to you.
443 2011-09-25 04:34:14 <gmaxwell> E.g. someone says I paid you in txid 12345. You then keep asking your peers "tell me when 12345 is mined, and give me the fragement connecting it to the root of the block its in"
444 2011-09-25 04:35:14 <gmaxwell> apply the same model to namecoin and malicious peers can cause nxdomain, and they can force nodes to see old values for domains that have moved... and there is no way to detect that anything funny is going on.
445 2011-09-25 04:37:01 <casascius> OK, so you have the headers and all of the open transactions.  What happens if you are given an extra transaction as open that really isn't, and you have no way to tell?  (because you won't have been given the transaction that spent it).... and this particular transaction grossly distorts your assembly of the tree?
446 2011-09-25 04:38:10 <gmaxwell> It's a binary tree, you can uniquely identify it in log2(opentxn) operations.
447 2011-09-25 04:38:11 <casascius> i am assuming the tree is pre-arranged based on some sort of pre-determinable sequence so everybody builds it the same way...
448 2011-09-25 04:38:17 <gmaxwell> Right.
449 2011-09-25 04:39:29 <gmaxwell> Obviously if you only have malicious peers there is nothing you can do  heck they could just refuse to reply to you at all.
450 2011-09-25 04:39:48 <gmaxwell> The key point is that if your peers are NOT malicious, they actually have a way of proving this to you.
451 2011-09-25 04:39:53 <casascius> so let's assume in an example that there are 9 open transactions, numbered, 1,3,4,5,6,7,8,9,10.  Except someone told me about transaction number 2 and I think it's open and it's really not.
452 2011-09-25 04:40:24 <casascius> I go to build my tree.  At the top is 1, next row is 2,3, next row is 4,5,6,7, next row is 8,9,10,x,x,x,x,x...
453 2011-09-25 04:40:42 <casascius> But everyone else's tree is 1, then 3,4, then 5,6,7,8, then 9,10,11,x,x,x,x,x.
454 2011-09-25 04:40:48 <gmaxwell> thats not how a binary hash tree tree is structured.
455 2011-09-25 04:41:04 <gmaxwell> the txn are only the leaves at the very end, everything else is pseudonodes in the middle.
456 2011-09-25 04:41:33 <casascius> OK, I was thinking you were describing more like a merkle tree.
457 2011-09-25 04:42:33 <gmaxwell> so you'd have the root which has everything under it, the left and right, the left has (1,3,4,5,6) right (7,8,9,10)  (obviously you don't use numbers, they're attached on the basis of their txids so the tree isn't perfectly balanced)
458 2011-09-25 04:42:51 <gmaxwell> so you'd see left was wrong, and you'd keep subdividing.
459 2011-09-25 04:43:10 <casascius> I follow you, but the more you subdivided, you'd never arrive at anything that was right.
460 2011-09-25 04:43:31 <gmaxwell> Sure you would. Right would be correct there, because it doesn't contain 2 in either version.
461 2011-09-25 04:43:49 <casascius> My left has (1,2,3,4,5) and my right has (6,7,8,9,10).  Your left has (1,3,4,5,6) and your right has (7,8,9,10).  At what point will we ever find a match, unless we exchange information about every single node on the tree?
462 2011-09-25 04:43:55 <gmaxwell> No.
463 2011-09-25 04:44:02 <gmaxwell> The split is determinstic based on the tx id.
464 2011-09-25 04:44:21 <casascius> so all on the left starting with 00-7F and on the right 80-FF?
465 2011-09-25 04:44:28 <gmaxwell> Right.
466 2011-09-25 04:44:41 <gmaxwell> then you just shift a bit at each level.
467 2011-09-25 04:45:27 <gmaxwell> But hold on a second. Even if repairing this way weren't possible that would still be okay.
468 2011-09-25 04:45:45 <casascius> I can easily see how this would work to find and fix one error, but what about many errors?
469 2011-09-25 04:45:53 <gmaxwell> You'd ask a peer for the complete open set. They'd give it to you. You'd validate it against the chain committment.. if it fails, you mark that peer as a loser and try again.
470 2011-09-25 04:46:07 <casascius> with many errors, would you not simply be encountering overwhelmingly large numbers of non-matching hashes as you walk the tree?
471 2011-09-25 04:46:33 <gmaxwell> Yes, there are ways to make this work for more errors but they become more costly quicky. What you then need is multiple trees.
472 2011-09-25 04:46:36 <casascius> because any error is going to make all its parents up thru the root wrong.  And you have no way to know which peer is "bad"
473 2011-09-25 04:47:11 <gmaxwell> (and you can design the multiple trees so they have a complementary layout, and for up to M errors at least one tree will be right at the root)
474 2011-09-25 04:47:25 <gmaxwell> but thats silly, in the case of multiple errors you do what I suggested about going from peer to peer. :)
475 2011-09-25 04:48:19 <casascius> I am not sure how you would know which peer gave you an open transaction that wasn't really open.  The tree is how you'd know if it was open, and while you're trying to piece together your tree, it won't help you
476 2011-09-25 04:48:47 <casascius> Once you got your tree done, you would immediately know which peer was lying, but then it wouldn't matter any more, you're up to date.
477 2011-09-25 04:49:22 <gmaxwell> casascius: just do your whole bringup from a single peer.
478 2011-09-25 04:49:41 <casascius> is that how bitcoin does it now?
479 2011-09-25 04:49:50 <gmaxwell> Pretty much.
480 2011-09-25 04:50:08 <gmaxwell> Because of how it works its single threaded in pulling blocks.
481 2011-09-25 04:50:09 <casascius> so it connects to 8 peers but picks one and only takes blocks from them?
482 2011-09-25 04:51:00 <gmaxwell> the connectivity to 8 peers is more about the ongoing forwarding. Once it's up it'll fetch new blocks from the peer that first tells it about them.
483 2011-09-25 04:51:15 <casascius> good to know
484 2011-09-25 04:51:29 <Toawa> What about when it's building its initial chain? Can it get blocks from more than one?
485 2011-09-25 04:51:39 <Toawa> Er, does it? Of course it can
486 2011-09-25 04:51:47 <casascius> so if the block my client picks has sucky uplink, my block chain will take a while for him to push?  (i don't experience it first hand, i have enough computers with bitcoin that i would just connect to one on my lan...)
487 2011-09-25 04:52:02 <gmaxwell> It can't really. I mean, it can, but it can't. It doesn't know the blockids yet.
488 2011-09-25 04:52:37 <Toawa> You'd always have their position in the chain...  The nodes should know that much...
489 2011-09-25 04:52:44 <gmaxwell> So what it does is it picks a node and basically says tell me blocks starting from $mycurrenttop to forever. (which gets clamped to 500)
490 2011-09-25 04:53:17 <gmaxwell> Toawa: you learn the chain from the start on up you have to in order to run the validation logic.
491 2011-09-25 04:53:37 <Toawa> I get that, but that doesn't mean you can't get future blocks; it just means you might have to discard them
492 2011-09-25 04:53:41 <gmaxwell> (well I suppose you could validate and fetch in different orders, but then you wouldn't catch a peer feeding you rubbish until very late)
493 2011-09-25 04:53:55 <bd_> Toawa: block chain fetching tends to be CPU bound
494 2011-09-25 04:54:04 <Toawa> And if you're the one asking, you can control when you ask for more blocks to add
495 2011-09-25 04:54:06 <gmaxwell> bd_: disk bound actually. Try it on a SSD.
496 2011-09-25 04:54:28 <bd_> well, disk bound primarily, cpu bound secondarily :)
497 2011-09-25 04:54:32 <gmaxwell> Toawa: but you don't know what to ask for, you only know your current tip.
498 2011-09-25 04:54:35 <bd_> and network bound at a distant third
499 2011-09-25 04:54:46 <gmaxwell> and indeed, network bound is a distant third.
500 2011-09-25 04:54:49 <Toawa> Ask by position in the chain.. #1, #2, #3, etc.
501 2011-09-25 04:55:03 <gmaxwell> Toawa: but your peers may not have the same chain.
502 2011-09-25 04:55:22 <Toawa> If they don't have the same chain that far down, something's very wrong...
503 2011-09-25 04:55:45 <gmaxwell> Indeed. Though there are broken nodes out there.
504 2011-09-25 04:55:59 <bd_> gmaxwell: well, that's fixable. Ask peer A for its tip, ask peer B for its tip, check that they match. If so, you know you can use matching block indices
505 2011-09-25 04:56:06 <casascius> This little open transactions hash sounds like something that could be added to the client now, like in the coinbase transaction
506 2011-09-25 04:56:07 <bd_> You just need to have a fallback for mismatched chains
507 2011-09-25 04:56:15 <gmaxwell> Once that due to memory biterrors are stuck back in the chain and can't take another block (I assume! I've never actually gotten my hands on them, I've just seen them on the network)
508 2011-09-25 04:56:16 <bd_> but really, go for the disk or CPU bound issues first
509 2011-09-25 04:56:25 <Toawa> Anyway, since block #0 should always be known (built into the software) you can figure out right away if there's a mismatch..
510 2011-09-25 04:56:43 <gmaxwell> Toawa: er, no, they can be mismatched any place in the middle.
511 2011-09-25 04:57:11 <Toawa> You mean orphaned chains?
512 2011-09-25 04:57:24 <gmaxwell> I wouldn't be surprised if there weren't some node out there .. that back on block 20,000 got a bit error that made it think a particular txn didn't exist.
513 2011-09-25 04:57:35 <gmaxwell> then block 20,001 on the network spent that txn, and that node ignored the block.
514 2011-09-25 04:57:43 <Toawa> Oh.. I think we might be talking about two different things...
515 2011-09-25 04:57:51 <gmaxwell> The node is mining and is now up to block 150,000ish like hte rest of the network.. but it's all on its own. :)
516 2011-09-25 04:58:10 <casascius> wasn't someone in the forums just describing how he had a bit error in his blockchain file?  are you familiar with that
517 2011-09-25 04:58:14 <Toawa> Another reason not to ask for all the nodes from one peer
518 2011-09-25 04:58:26 <bd_> Toawa: you can detect if they have an error like that
519 2011-09-25 04:58:27 <bd_> easily
520 2011-09-25 04:58:33 <bd_> and then switch to a different peer at that moment
521 2011-09-25 04:58:41 <gmaxwell> it's chain is much shorter (since chain length includes difficulty) but it can never hop onto the main chain because of the error.
522 2011-09-25 04:59:10 <casascius> somehow i think there ought to be a database rebuild function that verifies the integrity of blk0001.dat and rebuilds blkindex.dat from scratch
523 2011-09-25 04:59:15 <Toawa> I mean, if you have 8 peers, you ask for #1 from peer 1, #2 from peer 2, etc.
524 2011-09-25 04:59:20 <gmaxwell> casascius: ah, hadn't seen that. It's not uncommon though.. for non-ecc ram a desktop with 4g is taking a couple bit errors per day....
525 2011-09-25 04:59:43 <Toawa> unless they're all identically wrong (in which case you're going to get bad data in any case) you'd figure out quickly that someone's wrong.
526 2011-09-25 04:59:44 <gmaxwell> casascius: blk0001.dat has all kinds of orphan junk in it.
527 2011-09-25 05:00:22 <casascius> he was a developer trying to parse his block file into his client and pulling hair out as to why exactly one of his blocks failed, and there was a 1-bit difference for some reason: his block had 0x00000400 in the nLockTime field
528 2011-09-25 05:01:03 <Toawa> But again, I wonder if I'm talking about the same thing; I'm talking about bootstrapping a new node (something I know about, having done it a week or so ago) and how bloody long it took...  And wondering if that couldn't be improved...
529 2011-09-25 05:01:08 <gmaxwell> heh. man, it will be really funny if someday someone shows up on IRC who checked into an old node and found he had a zillion btc.. because it got itself irrepariably orphaned and kept on mining.
530 2011-09-25 05:01:34 <gmaxwell> Toawa: well, as I mentioned its diskbound mostly due to doing sync writes to the index.
531 2011-09-25 05:01:51 <gmaxwell> and if you remove that by using a ssd, you're cpu bound doing the validation.
532 2011-09-25 05:02:02 <Toawa> I'd think if it were so orphaned, it wouldn't be in the peer bootstrap IRC..  I wasn't looking at disk stats, so I'll take your word for it.
533 2011-09-25 05:02:23 <gmaxwell> gavin was suggesting turning off ecdsa before the last checkpoint, but I'm really skeptical that doing so should speed it up much.
534 2011-09-25 05:03:07 <gmaxwell> Toawa: sure it will. if it's orphaned due to some data corruption gltich it'll still run like normal, but just reject all the network's good blocks.
535 2011-09-25 05:03:30 <Toawa> but as I said, if you got each block from a different peer, you'll know quickly that one of them is going down the wrong path...
536 2011-09-25 05:04:07 <gmaxwell> sure sure. that could be done, but its irrelevant. the network doesn't really have anything to do with the speed of syncup.
537 2011-09-25 05:04:21 <Toawa> I know that now...
538 2011-09-25 05:04:28 <Toawa> Well, understand
539 2011-09-25 05:04:52 <gmaxwell> I syncup at ~the same speed across gigabit ethernet to an unloded -connect node as I do against the network.. though ssd or tmpfs makes a huge difference.
540 2011-09-25 05:05:02 <gmaxwell> (like 30 minutes vs hours)
541 2011-09-25 05:05:04 <Toawa> (But it'd have quite a big effect if that network were feeding you blocks from the one wrong node...)
542 2011-09-25 05:05:13 <Toawa> were only feeding
543 2011-09-25 05:06:19 <gmaxwell> another thing that makes syncup old is the number of pre .24 peers...
544 2011-09-25 05:06:33 <gmaxwell> which will start randomly hanging up on nodes fetching the chain from them.
545 2011-09-25 05:06:47 <Toawa> That certainly wouldn't help...
546 2011-09-25 05:07:14 <gmaxwell> so you can end up losing all your peers during syncup... they come back up fast if you're on code past .21 but if you end up with more <.24 peers you'll just get disconnected again quickly.
547 2011-09-25 05:07:53 <gmaxwell> (thus the /topic in here)
548 2011-09-25 05:09:30 <Toawa> That reminds me... I suppose I should update...
549 2011-09-25 05:10:20 <Toawa> Which reminds me... I wish the regular client incorporated some sort of key import ala pywallet...
550 2011-09-25 05:11:10 <gmaxwell> import/export should be merged soon.
551 2011-09-25 05:11:19 <Toawa> Glad to hear it.
552 2011-09-25 05:18:39 <Toawa> As a parting thought, another argument against the idea of a return address being "unnecessary data".  The system is set up (in theory) for all sorts of contracts; it says as much in the completeness of the op set available.  Those contracts are going to take up far more data space then return addresses ever will.. Return address is, say, 40 bytes.  That's less than an extra sig in two-sig...
553 2011-09-25 05:18:41 <Toawa> ...setups.  If the system didn't want transactions deviating from the "official" type, it wouldn't provide for it.  That and we've just spent an hour+ talking about how to reduce space requirements.  This is the kind of thing that would add value to hybrid (not exclusively online) use, and isn't that the goal?  I must be going; goodnight.
554 2011-09-25 05:21:12 <Toawa> (If you've ever returned something you bought with a credit card; you don't have to re-present the card to get the refund.  This kind of thing matters to brick & mortar businesses, who do occasionally have to give refunds.  This adds that possibility to Bitcoin.)
555 2011-09-25 05:21:17 <gmaxwell> Toawa: I was being a bit more negative than justified. In 99.999% of the cases where someone might want a refund what you're suggesting is completely pointless.  A flag in the TXN might make sense in some, I agree.
556 2011-09-25 05:22:10 <Toawa> Indeed... But it's those .001% cases that you have to consider, and businesses will consider them.
557 2011-09-25 05:22:48 <Toawa> But now I really must go.. Goodnight.
558 2011-09-25 05:23:02 <gmaxwell> You can address what you're describing by asking for a refund address with the initial transaction.
559 2011-09-25 05:23:06 <gmaxwell> night!
560 2011-09-25 05:34:46 <Lolcust> hello jgarzik ! Could you kindly help me out a bit ? I'm going to use (a mod of) your ref. CPU miner in a little side project, compiling from fedora succeeds, but on win the app crashes wtih error in pthreadGC2.dll. The downloaded "native" miner from your link dies the same fate (tested on : WinXP 32, WinXP64, Win 7 64). Could you please kindly take a look into this issue ?
561 2011-09-25 06:01:16 <Lolcust> oh, figured it out - jgarzik, that was a false alarm. Nice miner btw :-)
562 2011-09-25 06:08:04 <dikidera> well, its obvious you need that dll lol
563 2011-09-25 06:56:25 <sipa> wow long conversation you guys had, gmaxwell
564 2011-09-25 06:56:47 <[Tycho]> Hello.
565 2011-09-25 07:09:11 <dikidera> hello tycho
566 2011-09-25 07:20:21 <dikidera> ugh..compiling bitcoin takes forever
567 2011-09-25 09:24:38 <basti> hey people
568 2011-09-25 09:25:06 <basti> i'm getting an error like this: http://gcc.gnu.org/ml/gcc-help/2006-09/msg00322.html when I'm trying to compile the bitcoin client.
569 2011-09-25 09:25:33 <basti> it's not obvious to me what to do now, I'd appreciate any help
570 2011-09-25 09:28:32 <basti> it appears to have to do with conflicting "const" declarations
571 2011-09-25 09:32:33 <sipa> basti: could you put the actual error message somewhat?
572 2011-09-25 09:32:57 <basti> sure
573 2011-09-25 09:33:29 <basti> http://pastebin.com/y6UfS7BW sipa there you go :)
574 2011-09-25 09:34:37 <sipa> which version wx are you using?
575 2011-09-25 09:39:42 <basti> sipa: hmm, wx-config says 2.8.10
576 2011-09-25 09:39:56 <sipa> bitcoin's UI requires wx 2.9
577 2011-09-25 09:40:41 <basti> oh okay.
578 2011-09-25 09:40:51 <basti> can i leave out the UI somehow?
579 2011-09-25 09:40:55 <basti> it's on a server anyway
580 2011-09-25 09:41:01 <sipa> if you just compile bitcoind, tes
581 2011-09-25 09:41:05 <sipa> *yes
582 2011-09-25 09:41:11 <basti> how do i do that make ... bitcoind?
583 2011-09-25 09:41:20 <sipa> make -f makefile.unix bitcoind
584 2011-09-25 09:41:36 <basti> okay.
585 2011-09-25 09:41:39 <basti> that appears to work ;)
586 2011-09-25 09:41:47 <Guest54240> compiling takes time
587 2011-09-25 09:41:55 <Guest54240> for me sometimes around 10 for a full rebuild
588 2011-09-25 09:42:01 <Guest54240> 10 minutes*
589 2011-09-25 09:43:08 <basti> apparently i triggered some anti-spam device on blockexplorer.com with a foolish script
590 2011-09-25 09:48:53 <Guest54240> what was the message?
591 2011-09-25 09:49:15 <Guest54240> last time i used the site i looped over 10,000 public keys and had no problems
592 2011-09-25 09:49:30 <Guest54240> though i did stop the script at some point as it was slow
593 2011-09-25 10:03:16 <basti> ok i got it :)
594 2011-09-25 10:03:24 <basti> diki: let me look it up
595 2011-09-25 10:04:29 <basti> diki: "failed to open stream: Connection refused"
596 2011-09-25 10:13:26 <diki> this on the browser or?
597 2011-09-25 15:38:20 <casascius> Toawa's refund proposal could be implemented with a single bit flag or an extra pseudo-op in the transaction that simply means: "Transaction output #0 is the refund address".  And then re-sort the transaction so the change address (which will probably already be there taking up space anyway) is in spot #0 (adding a 0.00 output there if it's not)
598 2011-09-25 15:39:58 <casascius> Another way to accomplish the flagging without actually needing to take up flag space, would be to pay a transaction fee (to a miner) with a very unusual prefix that is unlikely to be duplicated by accident.
599 2011-09-25 15:40:22 <casascius> e.g. a fee like 0.01002842 or 0.00502842 or any fee with 2842 as its least significant digits
600 2011-09-25 15:40:38 <casascius> *prefix -> suffix
601 2011-09-25 15:41:53 <luke-jr> casascius: and how about when the refund address doesn't have any coins to send?
602 2011-09-25 15:42:20 <luke-jr> oh, output, nm
603 2011-09-25 15:42:28 <casascius> luke-jr: the refund address would be one output not input
604 2011-09-25 15:42:34 <casascius> the change output
605 2011-09-25 15:42:41 <luke-jr> still
606 2011-09-25 15:42:53 <luke-jr> kinda abuse of the block chain
607 2011-09-25 15:42:58 <luke-jr> like embedded messages
608 2011-09-25 15:43:11 <luke-jr> no reason you can't provide refund address out of band
609 2011-09-25 15:43:22 <casascius> how would it be abuse?  if it has a zero resource cost and a legitimate business use then why would that be abuse?
610 2011-09-25 15:43:37 <casascius> there will already be a change address
611 2011-09-25 15:43:45 <luke-jr> it does have resource cost; an extra output
612 2011-09-25 15:43:51 <luke-jr> sometimes
613 2011-09-25 15:44:02 <luke-jr> other times, it might not be needed
614 2011-09-25 15:44:58 <casascius> For a legitimate business purpose, I wouldn't object.... (I would be more bothered by, say, coinbase transaction that split the block reward into bitcent fragments =) ) only because they are larger in size and are a cascading resource burden when those fragments are spent
615 2011-09-25 15:45:33 <casascius> I don't know if you saw my comment on the forums, but I thought it funny to point out that:
616 2011-09-25 15:45:42 <luke-jr> out-of-band has much more potential IMO
617 2011-09-25 15:46:01 <casascius> for a block chain that repeatedly tells you "god does not exist", the block chain sure contains the word "G0D" a lot (byte sequence 0x47 0x30 0x44)
618 2011-09-25 15:46:39 <casascius> (it appears anytime a scriptsig starts with 0x30 0x44)
619 2011-09-25 15:46:59 <casascius> out-of-band has unlimited potential by definition
620 2011-09-25 15:55:33 <forrestv> casascius, it's difficult to do secure decentralized bitcoin transactions out of band :p
621 2011-09-25 15:56:10 <casascius> lol agreed
622 2011-09-25 17:50:08 <topi`> if the just recently found block did not include my payment, does it mean my txfee was too low?
623 2011-09-25 17:50:53 <nanotube> topi`: depends on the timing, and whether the tx was 'standard'
624 2011-09-25 17:51:22 <nanotube> (i.e., it could have just not made it into the block because you sent very shortly before it was found, or could have failed to relay across the network because it failed the isStandard check)
625 2011-09-25 17:51:27 <topi`> i guess it depends on the individual or pool who found the block?
626 2011-09-25 17:51:52 <topi`> what's the isStandard check?
627 2011-09-25 17:52:20 <gmaxwell> The bitcoin software shouldn't allow you send a txn with a txfee which is too low to actually work.
628 2011-09-25 17:52:29 <gmaxwell> So unless you modified it, thats not your issue.
629 2011-09-25 17:52:54 <gmaxwell> topi`: some miners have randomish rules.  Your txn also might no thave made it to that miner by the time they prepared that block for solving.
630 2011-09-25 17:54:13 <topi`> so, should I resend or wait?
631 2011-09-25 18:00:39 <gmaxwell> Are you running a current unmodified version of bitcoin?
632 2011-09-25 18:00:49 <gmaxwell> If so, just leave it running and wait. Your txn will go through.
633 2011-09-25 18:06:39 <topi`> yes, unmodified. now I can see it on the newest block.
634 2011-09-25 18:06:44 <topi`> it took 3 blocks to show up.
635 2011-09-25 18:07:05 <topi`> I wonder who minted that block
636 2011-09-25 18:09:22 <diki> it was me
637 2011-09-25 18:15:22 <CIA-101> bitcoinj: hearn@google.com * r223 /wiki/UsingMaven.wiki: Edited wiki page UsingMaven through web user interface.
638 2011-09-25 18:32:26 <CIA-101> bitcoinj: hearn@google.com * r224 /trunk/pom.xml:
639 2011-09-25 21:18:47 <Toawa> Actually, OOB was the first thing I thought of; I thought of the refund mechanism specifically for cases where OOB was infeasible or costly (not just in terms of money, but time and customer interaction.  I had brick-and-mortar transactions in mind when I thought of it.  Casacius's flag idea is functionally identical and better from a space perspective, though.
640 2011-09-25 21:19:38 <gmaxwell> Toawa: you need some way of transfering information about the transaction in order to identify it it.
641 2011-09-25 21:19:53 <Toawa> Hmm?
642 2011-09-25 21:20:16 <sipa> Toawa:, g
643 2011-09-25 21:20:21 <gmaxwell> You have to tell me where to send my payment, this means we already have a communications channel.
644 2011-09-25 21:21:06 <sipa> Toawa, gmaxwell: have you seen my proposal for a payment protocol?
645 2011-09-25 21:21:20 <gmaxwell> I saw that you had one, didn't look into to the protocol itself.
646 2011-09-25 21:21:30 <Toawa> Indeed.  However, (semi-)automatically including a single bit in your transaction to them is much less costly in terms of time and customer interaction than having to ask for a refund address manually.
647 2011-09-25 21:21:42 <Toawa> No, I haven't.. Link?
648 2011-09-25 21:21:46 <gmaxwell> There isn't anything manual required.
649 2011-09-25 21:22:26 <Toawa> How wouldn't there be anything manual required?
650 2011-09-25 21:24:09 <gmaxwell> How would anything manual be required?  The seller asks you to make a payment. Your humdinger pops up a dialog asking if you want to pay (hopefully asking for a password too), and then it responds to the vendor with a copy of the relevant transaction paying the vendor.  It's utterly trivial to completely automatically tag on "and my refund address is X" to that response.
651 2011-09-25 21:24:25 <sipa> https://gist.github.com/1237788
652 2011-09-25 21:24:50 <Toawa> That assumes a direct communications channel between your device and the seller.
653 2011-09-25 21:25:01 <gmaxwell> Toawa: there already _must_ be one.
654 2011-09-25 21:25:09 <Toawa> Not a bidirectional one.
655 2011-09-25 21:25:33 <gmaxwell> A unidirectional one isn't very useful, how would he ever know that you paid him.
656 2011-09-25 21:25:41 <Toawa> Transaction monitoring.
657 2011-09-25 21:25:50 <gmaxwell> Then you have bidirectional communication.
658 2011-09-25 21:25:51 <Toawa> W/ unique payment address
659 2011-09-25 21:25:56 <Toawa> Not directly.
660 2011-09-25 21:26:15 <Toawa> And such systems are already being used, FWIH.
661 2011-09-25 21:26:44 <Toawa> The channel is Seller -> Your Device -> Transaction cloud -> Seller
662 2011-09-25 21:26:48 <gmaxwell> You're stipulating a weird situation where both parties have internet access but can't actually communicate except by spamming the blockchain with more immortal data. Thats broken, don't do that.
663 2011-09-25 21:27:17 <gmaxwell> Thats a bad design because the seller has no control over the transaction propagation at all. It'll result in bad user expirence.
664 2011-09-25 21:27:22 <Toawa> Right now, the only spamming into the block chain that's happening as I describe, is the addition of a new transaction.
665 2011-09-25 21:27:38 <Toawa> I'm not the one that designed it; I'm only describing what I've heard is actually how it's being used.
666 2011-09-25 21:27:52 <gmaxwell> The transmission of the target address _can not_ be done reliably without two way communication, otherwise how would you know to resend if the communication was corrupted?
667 2011-09-25 21:28:12 <sipa> Toawa: read my proposal :)
668 2011-09-25 21:28:17 <gmaxwell> I think you've misunderstood what is being done, and/or those things are broken. :)
669 2011-09-25 21:28:19 <Toawa> Your device has a camera, scans in a QR code with the target address.
670 2011-09-25 21:28:43 <lfm> what device doesnt have a camera these days?
671 2011-09-25 21:28:59 <sipa> and internet access
672 2011-09-25 21:28:59 <Toawa> My iPad; but I've never used it for a transaction...
673 2011-09-25 21:29:04 <gmaxwell> Toawa: a printed QR code is not a unique payment address
674 2011-09-25 21:29:36 <lfm> your ipad is obsolete. I said these days
675 2011-09-25 21:29:41 <Toawa> There's no reason it can't be.  QR codes aren't hard to print, and they're going to be printing receipts, anyway
676 2011-09-25 21:29:51 <Toawa> I got it two months before the new one came out :|
677 2011-09-25 21:30:57 <Toawa> This is specifically the model I had in mind when I came up with the idea: https://bit-pay.com/aboutMobile.html
678 2011-09-25 21:31:58 <gmaxwell> "Both mobile phones must be able to access the internet." < meaning they have two way communication, via some way or another. There is no reason to use immortal storage for their two way dialog.
679 2011-09-25 21:32:06 <Toawa> I admit I've never used them in a B&M setting; I was working hypothetically.
680 2011-09-25 21:32:22 <Toawa> They have two way communication with the internet, not necessarily with eachother.
681 2011-09-25 21:33:09 <Toawa> Indeed, it's rather unlikely that they would have direct comms as you imagine; it would mean handing out your phone# to every merchant you do business with.
682 2011-09-25 21:33:23 <sipa> you have a very corrupted view of the internet then
683 2011-09-25 21:33:33 <gmaxwell> Toawa: if you have communication with the internet you have communication with each other. Communication doesn't mean direct. You're willing to accept indirection via the globally visible non-private blockchain, why not accept indirection via something else.
684 2011-09-25 21:34:42 <Toawa> Because the block chain is already there.  That infrastructure has been built; why not use it?  Especially since, as has been pointed out, my original proposal can be simplified to as low as a single bit.
685 2011-09-25 21:35:12 <sipa> and the block chain is massive thing to maintain
686 2011-09-25 21:35:15 <gmaxwell> It can't actually be a single bit.
687 2011-09-25 21:35:35 <Toawa> Well, a byte might be more realistic, but a bit is technically possible.
688 2011-09-25 21:35:42 <sipa> there is absolutely no reason to use it for more than transaction ladger
689 2011-09-25 21:35:47 <sipa> ledger
690 2011-09-25 21:36:05 <gmaxwell> The blockchain is not an efficient mechenism for ephemerial private communication, which is what you need.  The block chain creates near immortal highly public communication, it's the least efficient communications channel ever realized.
691 2011-09-25 21:36:17 <lfm> Toawa: because the block chain is not really a communication channel. it is a permenant store. using it as a comm channel is sub optimal
692 2011-09-25 21:36:37 <gmaxwell> Toawa: a bit is not technically possible without a lot of insane considerations.
693 2011-09-25 21:36:58 <sipa> Toawa: would you please read my proposal?
694 2011-09-25 21:37:06 <gmaxwell> e.g. requring all address generation to iterate until it generates the kind of address that it wants.
695 2011-09-25 21:37:23 <Toawa> Ah, sorry, didn't see the link.
696 2011-09-25 21:37:32 <lfm> one bit? use the least significant bit of the ammount. round the amount up to the next even or odd satoshi. they are essensially worthless anyway
697 2011-09-25 21:37:57 <sipa> there is still no need
698 2011-09-25 21:38:36 <sipa> once you accept there is going to be bidirectional communication, there are tons of possibilities
699 2011-09-25 21:39:44 <Toawa> I'm not convinced that there will be bi-directional direct communication.  That's the whole point of my proposal; to have something that works in the absence of bi-directional direct communication.
700 2011-09-25 21:39:59 <sipa> like tracking transactions direct
701 2011-09-25 21:40:20 <sipa> there is no need for direct communication
702 2011-09-25 21:40:29 <sipa> just bidirectional
703 2011-09-25 21:40:42 <gmaxwell> lfm: it would still require everyone to not use the wrong value, and would frequently result in additional change generation that we avoid now from round transactions.
704 2011-09-25 21:40:42 <sipa> like the blickchain, indirectly
705 2011-09-25 21:40:50 <sipa> but a lot easier
706 2011-09-25 21:41:44 <Toawa> Hell, I've just thought of a way to do it with as little as zero bits..
707 2011-09-25 21:42:02 <lfm> telepathy?
708 2011-09-25 21:42:20 <Toawa> No.. Transmitting information based on destination address selection.
709 2011-09-25 21:42:37 <sipa> it'll always be less convenient than just negotating the tx outside of bitcoin
710 2011-09-25 21:42:56 <lfm> yup, like the tv idol voting by phoneing different phone numbers?
711 2011-09-25 21:43:00 <Toawa> exactly
712 2011-09-25 21:43:27 <Toawa> However, it potentially brings up a corner case when the inputs match the output exactly.
713 2011-09-25 21:43:29 <lfm> that would be an acceptable technique
714 2011-09-25 21:43:35 <sipa> you're hscking information in things it wasn't designed for
715 2011-09-25 21:43:52 <Toawa> That's the whole point of hscking, is it not?
716 2011-09-25 21:43:59 <Toawa> Finding new ways to use things
717 2011-09-25 21:44:20 <lfm> the address already identifies the buyer in some ways
718 2011-09-25 21:44:35 <sipa> you can do so much more by accepting that the block chain is not the best medium for what you need
719 2011-09-25 21:44:58 <Toawa> I'm trying to think in cases where it's potentially the only medium.
720 2011-09-25 21:45:01 <gmaxwell> Toawa: lets assume for a moment that we decided that it would be okay to modify the bitcoin software to do what you want. Why not instead modify it so that you could create riders on transactions that don't get left in the blockchain but are ephemerial. Wouldn't that be superior?
721 2011-09-25 21:45:28 <Toawa> It would.
722 2011-09-25 21:45:46 <gmaxwell> And if we're going to go that far, why bother multiplexing it on the bitcoin protcol at all, where random bitcoin users have to pay the price when you decide that you want to use it to broadcast porno videos?
723 2011-09-25 21:45:46 <sipa> how can it be the only medium? it requires a tcp connection already
724 2011-09-25 21:45:56 <lfm> should be no need to modify bitcoin. its just another transaction shell that would use existing interfaces
725 2011-09-25 21:46:43 <lfm> but ya, hard to immagine having enuf internet for bitcoin and not enuf for any other internet functions
726 2011-09-25 21:46:47 <gmaxwell> or hell, as lfm points out... just pick which target address you use based on if you accept refunds or not, simple enough.
727 2011-09-25 21:46:50 <Toawa> Because no sane person is going to try and incorporate that much data into a block, and the insane ones are easily detected.
728 2011-09-25 21:47:14 <sipa> but there is no difference
729 2011-09-25 21:47:16 <Toawa> That was my idea at 18:41
730 2011-09-25 21:47:21 <Toawa> er, 23:41
731 2011-09-25 21:47:28 <gmaxwell> Detected via magical mystery what?
732 2011-09-25 21:47:29 <lfm> use UTC
733 2011-09-25 21:47:46 <Toawa> Of course there's a difference.
734 2011-09-25 21:48:27 <lfm> (insane ones? you mean like putting payers to one' diety in a block?) never mind, we don't need that sidetrack right now.
735 2011-09-25 21:48:35 <Toawa> By the fact that suddenly you have a gargantuan transaction which, in all likelyhood, will never be incorporated without a huge fee attached.  Thinking of that, I've always wondered what happens to transactions that no one will use...
736 2011-09-25 21:48:44 <gmaxwell> In any case, it doesn't really matter how much data it is. The amount of this data that belongs in the blocks is zero because it's not information the whole of bitcoin needs to know in order to validate that the transaction is consistent with the global rules.
737 2011-09-25 21:49:36 <gmaxwell> gargantuan? no it wouldn't you'd use a great many free transactions to do it.
738 2011-09-25 21:50:12 <Toawa> Ultimately, in princple, there's no reason why it couldn't happen right now.  Why hasn't it, then?
739 2011-09-25 21:50:15 <gmaxwell> And adding more _legit_ transactions to the network which are objectively indistinguishable from paracitic data storage transactions makes it harder for the system to resist attack without imposing fees on everything.
740 2011-09-25 21:50:30 <gmaxwell> Toawa: it has, run strings on your block file.
741 2011-09-25 21:51:03 <gmaxwell> But at least most data-riding transactions are objectively distinguishable from efficient ones, so we can impose greater fees on them to discourage the practice.
742 2011-09-25 21:51:47 <lfm> hard to impose fees on the coin-base txn tho
743 2011-09-25 21:51:54 <gmaxwell> If you intentionally start stuffing a side channel into legit transactions then it becomes impossible for miners to discourage transactions that look like that without making regular bitcoin users unhappy.
744 2011-09-25 21:52:30 <gmaxwell> lfm: yea, but at least we can generally assume that anyone making coin-base txn has more invested in the healt of the system than j-random-attacker.
745 2011-09-25 21:52:43 <lfm> hehe true
746 2011-09-25 21:53:32 <JFK911> multicast is the ultimate p2p
747 2011-09-25 21:53:42 <JFK911> errybody join group!
748 2011-09-25 21:54:07 <lfm> not really p2p, more like broadcast than p2p
749 2011-09-25 21:54:33 <gmaxwell> well, modern multicast is source specific, so it's not quite everything-broadcast.
750 2011-09-25 21:54:54 <gmaxwell> It still seems unlikely that we'll see multicast being generally available on the public internet anytime soon ISPs don't know how to charge for it.
751 2011-09-25 21:55:26 <lfm> hmm well maybe multicast is just an optimization of  something in between braodcast and p2p
752 2011-09-25 21:55:46 <gmaxwell> multicast is an optimization of unicast plus source replication.
753 2011-09-25 21:56:22 <gmaxwell> in the case where N unicast streams would carry identical data over many hops, multicast saves a lot of capacity.
754 2011-09-25 21:56:26 <lfm> target replication?
755 2011-09-25 21:56:35 <JFK911> internet wide ipv6 multicast address for bitcoin seems like the answer
756 2011-09-25 21:57:02 <gmaxwell> lfm: source replication E.g. where the source does 100% of the replication.
757 2011-09-25 21:57:18 <lfm> oh
758 2011-09-25 21:57:46 <lfm> JFK911: bitcoin is actually pretty darn efficient now imho
759 2011-09-25 21:58:03 <gmaxwell> Target replication is like bittorrent. Where endpoints copy data to other endpoints, which is a model which is pretty different from multicast in particular it puts the highest loads in the edges of the network which tend to have the highest marginal cost per bit.
760 2011-09-25 21:58:18 <gmaxwell> Yea, bitcoin's efficiency is great, the filtering INV scheme works pretty well.
761 2011-09-25 21:59:54 <gmaxwell> well, it's not great if you have 1000 peers, but you shouldn't do that. :)
762 2011-09-25 22:01:02 <luke-jr> gmaxwell: nonsense, multicast can be charged the same way as any other traffic
763 2011-09-25 22:01:27 <luke-jr> it's not like the recipients are charged
764 2011-09-25 22:02:13 <Toawa> sipa: Yeah, that proposal would work... It's not everything I'd have liked to see (my idea doesn't tie you to a specific intermediary, but that's probably not important enough to get worked up over).  As for the remarks; transmission should always be encrypted except when there's a reason not to, but using HTTPS probably counts as encrypted.
765 2011-09-25 22:03:27 <gmaxwell> luke-jr: No, the sender is but the sender now generates 1x traffic at their port, but in network replication turns that into 1000x the load elsewhere in the network. You can no longer just count the bits per second on the customer's port, you need to track replication in the network _per_flow_ and basically nothing collects data for that, plus the customer can't control their cost liablity today
766 2011-09-25 22:03:53 <gmaxwell> you know if you have a 1g port you won't be charged for more than 1g of traffic (likewise if you shape yourself), multicast complicates that greatly.
767 2011-09-25 22:04:07 <luke-jr> hmm
768 2011-09-25 22:04:34 <gmaxwell> So right now, you can find multicast available e.g. with MPLS VPN services, and what the ISPs do is charge for the greater of the sum of all outbound or the sum of all inbound traffic.
769 2011-09-25 22:04:47 <gmaxwell> But thats works because all the participants in the VPN are one customer.
770 2011-09-25 22:06:06 <luke-jr> yeah, I guess I wasn't considering downstream routes
771 2011-09-25 22:06:55 <luke-jr> but still, multicast within ISPs should be possible :/
772 2011-09-25 22:07:05 <gmaxwell> it's especially goofy with multiple providers.. e.g. provider A, your ISP, might have the flow monitoring to bill you for your replicated traffic, but they hand off one flow to provider B who replicates it 1000 fold but doesn't have a relationship to bill you. :)
773 2011-09-25 22:07:15 <gmaxwell> Oh, well, it's possible some ISPs offer it.
774 2011-09-25 22:07:22 <gmaxwell> The long standing example is sprint.
775 2011-09-25 22:08:02 <gmaxwell> Some also use it for their own stuff.. e.g. if they offer an IPTV service they'll probably use it, but they may or may not let their customers get it.. and you can be pretty sure it won't work across isps.
776 2011-09-25 22:09:00 <luke-jr> I suppose multicast escalates DoS risks
777 2011-09-25 22:12:26 <gmaxwell> Well, the reciever specified what S,G they want. (source and group) So it makes some worse, it's at least something you can fight.