1 2013-08-24 00:04:57 <cjd> Lolcust: An Accumulator Based on Bilinear Maps and
  2 2013-08-24 00:04:58 <cjd> Efficient Revocation for Anonymous Credentials
  3 2013-08-24 00:05:28 <cjd> It doesn't look like it needs trusted setup
  4 2013-08-24 00:05:43 <kuzetsa> accumulators are nice
  5 2013-08-24 00:06:04 <cjd> if any existed they'd be interesting
  6 2013-08-24 00:06:11 <kuzetsa> ?
  7 2013-08-24 00:06:13 <cjd> someone gotta write the code :)
  8 2013-08-24 00:18:25 <rubino123> if I compile with upnp support how does that help?
  9 2013-08-24 00:49:22 <AlexNagy> upnp enables the application to tell your router (if your router supports upnp) to open ports without your intervention.
 10 2013-08-24 01:11:04 <AlexNagy> anyway, I'm off to bed for the night! Good night and God bless. (:
 11 2013-08-24 01:18:37 <warren> Luke-Jr: it seems key people are against removal of internal miner and others don't care enough to fight for its removal, so it would be most expedient to PR a variant that has -disable-wallet and removes getwork but keeps internal miner.
 12 2013-08-24 01:19:12 <warren> Litecoin will continue to have internal miner completely gone.
 13 2013-08-24 02:23:33 <Krellan> I'd vote to keep the internal miner, if only for having it as a de facto reference implementation.
 14 2013-08-24 02:37:53 <gmaxwell> Krellan: it is not a viable reference implementation.
 15 2013-08-24 02:38:04 <gmaxwell> No other miner but the internal one can be implemented exactly that way.
 16 2013-08-24 02:38:13 <gmaxwell> Thats one of the reasons I wanted to ditch it.
 17 2013-08-24 02:44:44 <Krellan> That is strange - does it "cheat" by looking up internal data structures instead of using RPC?
 18 2013-08-24 02:45:01 <Krellan> I used the internal CPU miner only as a cheesy benchmarking tool for comparing computers :)
 19 2013-08-24 03:09:29 <phantomcircuit> Krellan, exactly what it does
 20 2013-08-24 03:09:33 <jgarzik> Krellan, it being an internal miner, it has no need to use RPC
 21 2013-08-24 03:11:25 <jgarzik> I'm tired of waiting for TheUni to update the autoconf stuff
 22 2013-08-24 03:11:48 <jgarzik> 
ACTION wants to create libsatoshi.a in makefile.unix, and dep bitcoind on that

 23 2013-08-24 03:14:56 <jgarzik> hmmm
 24 2013-08-24 03:16:49 <jgarzik> for each module moved to libsatoshi.a: { convert from CClass to namespace bitcoin::class }
 25 2013-08-24 03:19:05 <phantomcircuit> watching videos on youtube
 26 2013-08-24 03:19:08 <phantomcircuit> something is off
 27 2013-08-24 03:19:11 <phantomcircuit> this is gnash
 28 2013-08-24 03:19:15 <phantomcircuit> gnash actually works?????
 29 2013-08-24 03:19:55 <jgarzik> phantomcircuit, surprising
 30 2013-08-24 03:20:48 <phantomcircuit> apparently i spoke too soon
 31 2013-08-24 03:20:51 <phantomcircuit> pandora wont load
 32 2013-08-24 03:20:54 <phantomcircuit> damn
 33 2013-08-24 03:21:16 <phantomcircuit> i wonder how much effort went into making youtube work...
 34 2013-08-24 03:21:53 <Krellan> jgarzik: Thanks.  Hopefully all the internal structures it used to make mining decisions are available now via RPC.
 35 2013-08-24 03:24:57 <jgarzik> Krellan, yes, that happened many eons ago :)
 36 2013-08-24 03:25:53 <Krellan> Good to know.  Maybe dump the internal structures and have it call the RPC instead, just for cleanliness, isolate the miner out from the code.
 37 2013-08-24 03:26:01 <gmaxwell> Krellan: all mining on the actual network happens via rpc... but thats why the internal one isn't a good reference anymore. But it's fine for testing where you're not actually testing the miner.
 38 2013-08-24 03:52:09 <jgarzik> well
 39 2013-08-24 03:52:18 <jgarzik> libsatoshi.a was easy, and worked perfectly the first time
 40 2013-08-24 03:52:24 <jgarzik> namespace conversion?  taking time
 41 2013-08-24 03:53:48 <gmaxwell> jgarzik: satoshi is really super dupe awesome, but I would rather not feed the weird cult stuff, so I hope you ultimately pick a different name!
 42 2013-08-24 03:54:24 <Diablo-D3> CULT OF SATOSHI
 43 2013-08-24 03:56:08 <gmaxwell> "libbtcommodity" perhaps? Both reflecting btc and that it's supposted to be "commodity code" ? :P
 44 2013-08-24 03:56:21 <Diablo-D3> libbitneric
 45 2013-08-24 03:57:41 <gmaxwell> "libdiablod3" for I care. "We hoped if we named it after him some crazy dictatorship would have him taken out"
 46 2013-08-24 04:03:00 <jgarzik> gmaxwell, it is a trollname
 47 2013-08-24 04:03:14 <jgarzik> gmaxwell, the choices -- libcoin, libbitcoin, have all been taken
 48 2013-08-24 04:03:29 <jgarzik> gmaxwell, someone is therefore forced to pick for me, if it matters ;p
 49 2013-08-24 04:22:48 <JustCoder32> #bitcoin-dev Cannot send to channel
 50 2013-08-24 04:22:48 <JustCoder32> jgarzik: what are you talking about (libcoin, libbitcoin) ?
 51 2013-08-24 04:23:14 <gmaxwell> jgarzik: varrious libraries made by other people and not (afaik) widely used for anything.
 52 2013-08-24 04:24:55 <JustCoder32> aha
 53 2013-08-24 04:25:45 <gmaxwell> er JustCoder32 is not jgarzik
 54 2013-08-24 04:26:08 <gmaxwell> naming things is hard, so unfortunately people keep giving really confusing names to thing in bitcoinland.
 55 2013-08-24 04:27:14 <JustCoder32> when these things get popular and useful the names are not a problem :)
 56 2013-08-24 04:29:57 <oleganza> why do OP_CHECKSIG/OP_CHECKMULTISIG drop signatures from scripts? Looks like we never have signatures in scripts in the first place.
 57 2013-08-24 04:30:54 <gmaxwell> oleganza: hm? they consume them.
 58 2013-08-24 04:31:00 <oleganza> seems like it's the code from the early time when input and output scripts were actually concatenated instead of being executed separately
 59 2013-08-24 04:31:15 <gmaxwell> oleganza: or do you mean the masking?
 60 2013-08-24 04:31:21 <gmaxwell> because ... a signature can't sign itself.
 61 2013-08-24 04:31:34 <oleganza> i mean :
 62 2013-08-24 04:31:35 <oleganza> // Drop the signature, since there's no way for a signature to sign itself
 63 2013-08-24 04:31:35 <oleganza> scriptCode.FindAndDelete(CScript(vchSig));
 64 2013-08-24 04:31:53 <oleganza> but we never have this signature in the currently executed script anyway
 65 2013-08-24 04:32:20 <oleganza> unless one puts OP_CHECKSIG in the *input* script for silly reason
 66 2013-08-24 04:32:38 <gmaxwell> right, there is also another consequence of that, yup.
 67 2013-08-24 04:32:51 <oleganza> this find and delete makes sense only when input script is actually a part of the currently executed script
 68 2013-08-24 04:33:04 <oleganza> which was the case initially, if I understand correctly
 69 2013-08-24 04:33:21 <gmaxwell> it was, I think petertodd figured out another application for that, but I don't recall.
 70 2013-08-24 04:33:24 <oleganza> but that created some awful security vulnerability
 71 2013-08-24 04:33:47 <oleganza> ok then
 72 2013-08-24 04:34:05 <oleganza> i ask because i have to document every strange piece of code
 73 2013-08-24 04:34:13 <gmaxwell> kinda, the ability to just return true in the scriptsig did, but it was split because it was easier to make sure that was right.
 74 2013-08-24 04:36:30 <oleganza> how do you return true? OP_RETURN was not failing the script then?
 75 2013-08-24 04:36:39 <gmaxwell> Correct.
 76 2013-08-24 04:36:46 <oleganza> nice
 77 2013-08-24 04:36:53 <oleganza> when was it exactly?
 78 2013-08-24 04:37:48 <gmaxwell> 2010-07
 79 2013-08-24 04:38:25 <gmaxwell> it was never used to rob anyone but was demonstrated on testnet.
 80 2013-08-24 04:39:25 <oleganza> EvalScript(txin.scriptSig + CScript(OP_CODESEPARATOR) + txout.scriptPubKey, txTo, nIn, nHashType);
 81 2013-08-24 04:39:27 <oleganza> wow
 82 2013-08-24 04:39:46 <oleganza> so if one was using OP_CODESEPARATOR to concatenate the scripts, why delete the signatures?
 83 2013-08-24 04:39:56 <oleganza> this is from 2009
 84 2013-08-24 04:40:11 <oleganza> initial commit to current github repo
 85 2013-08-24 04:41:09 <oleganza> actually, all this mess is only one more proof that Bitcoin will survive anything including its own bugs
 86 2013-08-24 04:42:05 <gmaxwell> 2010 is not now.
 87 2013-08-24 04:42:19 <oleganza> you think now it won't survive?
 88 2013-08-24 04:42:33 <gmaxwell> I'm just saying the past evidence doesn't generalize.
 89 2013-08-24 04:42:48 <oleganza> agreed
 90 2013-08-24 04:42:50 <gmaxwell> In any case, I think the idea was that you could use the OP_CODESEPARATORs to have embedded signed data, but I don't think that ever worked.
 91 2013-08-24 04:43:32 <oleganza> i wonder what is the use case for having a signature in the output script?
 92 2013-08-24 04:43:43 <oleganza> e.g. allowing 1 particular output tx
 93 2013-08-24 04:43:49 <oleganza> sounds interesting to me
 94 2013-08-24 04:44:24 <oleganza> e.g. we prepare a contract tx with a predefined redeeming tx
 95 2013-08-24 04:44:48 <oleganza> will think about that
 96 2013-08-24 04:46:58 <gmaxwell> oleganza: yea, you currently can't do that as far as I can determine. we come very close. See this thread:
 97 2013-08-24 04:47:15 <gmaxwell> https://bitcointalk.org/index.php?topic=278992.0
 98 2013-08-24 04:48:05 <oleganza> great read
 99 2013-08-24 04:48:36 <oleganza> i have to finish OP_CHECKMULTISIG implementation, and then i'll check it out
100 2013-08-24 05:31:06 <ThomasV> gmaxwell: https://bitcointalk.org/index.php?topic=277470.msg2997291#msg2997291
101 2013-08-24 05:32:21 <gmaxwell> ThomasV: gah, oh ThomasV I wasn't trying to hate on electrum. Though I'l also glad by your post.
102 2013-08-24 05:32:50 <gmaxwell> ThomasV: the user there was already using bitcoin-qt.
103 2013-08-24 05:33:03 <gmaxwell> and was getting hammered on by an electrum fan insisting that it was just as secure.
104 2013-08-24 05:33:10 <ThomasV> gmaxwell: sure, I was asked to answer by some electrum users
105 2013-08-24 05:42:50 <gmaxwell> thomasv: https://bitcointalk.org/index.php?topic=277470.msg2997392#msg2997392 (aww he left)
106 2013-08-24 06:17:05 <Krellan> gmaxwell: Hi again, cleaned up my little addrLocal patch.
107 2013-08-24 06:17:21 <Krellan> https://github.com/bitcoin/bitcoin/pull/2929
108 2013-08-24 06:17:40 <Krellan> Now, it only appears in the output if address is valid (no more garbage).
109 2013-08-24 06:19:42 <BW^-> gavinandresen,*: (I will send this kind of thing on the ML in the future.)   Saw the discussion about updating transaction fees. Would be great if transaction fees are proportional to the transfered sum, so that also very small purchases can be done effectively with BTC. I.e., transaction fees are so low that it is meaningful to do 0.0001 - 0.0005 BTC transactions (= 0.05???, the typical price for a piece of candy, nail, etc.)
110 2013-08-24 06:20:12 <BW^-> perhaps by this reason, having the transaction fee proportional to submitted amount would be something.
111 2013-08-24 06:20:37 <BW^-> i'm sure Lots of people said something similar, just wanted to put this on the ether. thanks.
112 2013-08-24 06:26:57 <BW^-> of course i'm aware that as transactions take blockchain space, there is a lower limit where it would not be worth it for the BTC system to transact such a small BTC amount and it would turn even into a DDOS potential, so I guess question is just what's that limit. very well, will be great to see the outcome. i guess everyone is clear that BTC fees should be so low that you could buy a muffin and alike with it (=0.01BTC), effectively.
113 2013-08-24 06:27:06 <sipa> BW^-: it doesn't work that way
114 2013-08-24 06:27:26 <sipa> the cost of a transaction to the network is independent of its transferred value
115 2013-08-24 06:27:40 <BW^-> sipa: mm, i'm aware that the transaction size in the blockchain is not proportional to size of transaction in BTC:s, but to the number of input unspent transactions
116 2013-08-24 06:27:57 <sipa> even stronger! the network does not know the transferred value
117 2013-08-24 06:28:17 <BW^-> sipa: doesn't it??  but, blockchain.info lists the transfered value for every trx made??
118 2013-08-24 06:28:24 <sipa> it guesses
119 2013-08-24 06:28:32 <BW^-> sipa: really?? like, how bad a guess? hehe.
120 2013-08-24 06:28:40 <sipa> the network only sees the amount in every output
121 2013-08-24 06:28:51 <sipa> but an output can be change back to yourself
122 2013-08-24 06:29:09 <gmaxwell> somewhat better than 50/50, hard to know exactly how good it is... depends on your transaction practices.
123 2013-08-24 06:29:24 <BW^-> sipa: if a transaction is made with several outputs, say one to the muffin guy and one back to yourself,
124 2013-08-24 06:29:35 <BW^-> then you can reliably see how much went to the muffin guy and how much to you, right?
125 2013-08-24 06:29:48 <BW^-> presuming you know their btc addresses/hashes/etc.?
126 2013-08-24 06:30:01 <sipa> yes, but that presumption is wrong
127 2013-08-24 06:30:12 <BW^-> which presumption?
128 2013-08-24 06:30:29 <sipa> that you know actual destination's address
129 2013-08-24 06:30:35 <sipa> of course the sender kbows
130 2013-08-24 06:30:40 <sipa> and the receiver too
131 2013-08-24 06:30:51 <sipa> but hopefully the rest of the network doesn't
132 2013-08-24 06:31:12 <BW^-> sipa: in all cases, this is enough for your "Addrindex" patch to know the amount of unspent transactions connected with each bitcoin address?
133 2013-08-24 06:31:21 <gmaxwell> BW^-: in any case, even once you're past this??? the network has no motivation to behave in the way you want. The value doesn't have any correlation to the cost of the transaction for the network or the miners.
134 2013-08-24 06:31:23 <BW^-> (presuming only standard transaction types were involved with the respective addr)
135 2013-08-24 06:31:41 <sipa> BW^-: yes, but what is the relevance?
136 2013-08-24 06:31:51 <BW^-> sipa: mm not so much.
137 2013-08-24 06:31:57 <sipa> you cannot reliably know the value transferred
138 2013-08-24 06:32:08 <sipa> and the network does not care about it
139 2013-08-24 06:32:14 <BW^-> gmaxwell,*: anyhow - can't you make a presumption that people's "change" should not be smaller than a certain size so therefore a candy/muffin-size transaction should always occupy at most a certain amount of blockchain space?
140 2013-08-24 06:32:26 <sipa> nor does it impact it in any way
141 2013-08-24 06:32:43 <BW^-> ..small enough to justify a transaction fee small enough to make candy/muffin transaction deliver well?
142 2013-08-24 06:32:51 <BW^-> *-size transactions
143 2013-08-24 06:32:55 <gmaxwell> BW^-: I don't follow what you're saying there.
144 2013-08-24 06:32:56 <sipa> BW^-: depends how cheap a muffin is
145 2013-08-24 06:33:12 <gmaxwell> My muffins are hand crafted on mars.
146 2013-08-24 06:33:21 <BW^-> sipa: muffin 0.005-0.01BTC, candy 0.00007 - 0.0005 BTC
147 2013-08-24 06:33:22 <sipa> at some price, it is simply not economical to do the transaction via the bitcoin blockchain
148 2013-08-24 06:33:32 <BW^-> exactly
149 2013-08-24 06:33:38 <gmaxwell> BW^-: and cannot be.
150 2013-08-24 06:33:45 <BW^-> hehe
151 2013-08-24 06:33:52 <gmaxwell> The blockchain is a global consensus system, this implies some fundimental costs.
152 2013-08-24 06:33:53 <sipa> what price that is depends on the economy, the network, and the technology used
153 2013-08-24 06:34:05 <gmaxwell> What exactly they are??? who knows??? but it's not a cheap way to communicate something.
154 2013-08-24 06:34:06 <BW^-> right.
155 2013-08-24 06:34:14 <BW^-> yeah.
156 2013-08-24 06:34:21 <gmaxwell> You could, of course, use the bitcoin currency... just not in the blockchain.
157 2013-08-24 06:34:39 <BW^-> exactly. hm.
158 2013-08-24 06:34:49 <BW^-> sipa,gmaxwell: can we make any presumption about how small transaction fees will remain?
159 2013-08-24 06:34:49 <gmaxwell> deposit one btc with a fast confirmation service and buy all the muffins and candies you want all year long.
160 2013-08-24 06:34:56 <sipa> imho, no
161 2013-08-24 06:34:59 <gmaxwell> BW^-: we do not know.
162 2013-08-24 06:35:26 <BW^-> interesting. so, we can presume it will be maintained well under $1,
163 2013-08-24 06:35:30 <BW^-> however how much we cannot know?
164 2013-08-24 06:35:45 <gmaxwell> I don't think you can presume anything, it depens on how bitcoin is used in the future.
165 2013-08-24 06:35:55 <sipa> i am certainly not convinced it will stay under $1
166 2013-08-24 06:36:03 <BW^-> interesting.
167 2013-08-24 06:36:04 <sipa> forever
168 2013-08-24 06:36:31 <gmaxwell> If off chain systems become popular and very good then there will be no particular reason for bitcoin txn to be cheap, as the txn will mostly be settlements between other systems.
169 2013-08-24 06:36:46 <BW^-> right. interesting.
170 2013-08-24 06:36:48 <gmaxwell> (or large transactions like buying a house)
171 2013-08-24 06:37:28 <BW^-> yeah. or, escrows so important that the parties want a publicly verifiable information confirming its existence to all involved parties
172 2013-08-24 06:37:33 <sipa> i don't think the "very good" part is a requirement
173 2013-08-24 06:37:37 <sipa> unfortunately
174 2013-08-24 06:37:55 <BW^-> sipa: "very good" re transaction fees? mm, i'm with you.
175 2013-08-24 06:38:05 <sipa> no
176 2013-08-24 06:38:11 <BW^-> ah. very good re what?
177 2013-08-24 06:38:13 <gmaxwell> alternatively, if networks and computers grow very fast (as fast as we can hope and then some) and people can't sort out the issues that make off chain systems complicated, then perhaps a different path will be followed and more txn will be in bitcoin.
178 2013-08-24 06:38:16 <sipa> anything
179 2013-08-24 06:38:27 <gmaxwell> sipa is saying that my "very good" was not a necessary criteria.
180 2013-08-24 06:38:36 <sipa> popular is enough :)
181 2013-08-24 06:38:38 <gmaxwell> I agree, though perhaps its a sufficient one.
182 2013-08-24 06:38:40 <BW^-> aha
183 2013-08-24 06:39:02 <gmaxwell> sipa: you did see my latest moon wankery on using SCIP to tie in off-chain payment systems?
184 2013-08-24 06:39:15 <gmaxwell> ("CoinWitness")
185 2013-08-24 06:39:25 <BW^-> mhm interesting. so i guess then, a goal would just be to get a reliable mechanism for all involved parties to automatically figure out what transaction fee will work, so the current guessing if the network will take it won't be needed
186 2013-08-24 06:39:28 <sipa> i haven't had the time
187 2013-08-24 06:40:08 <BW^-> mhm
188 2013-08-24 06:40:08 <gmaxwell> BW^-: yes, that will be important. Also good ways to recover when you guess wrong.
189 2013-08-24 06:40:37 <BW^-> btw, do you have any thought on how qualitative ZeroCoin can become?
190 2013-08-24 06:41:23 <BW^-> from my reading up on ZeroCoin, they basically say it's experimental, undergoing development, and that it's not unexotic in nature - didn't get a clear picture of if it's robust and may become common-place to use, or if it will remain exotic and experimental in perpetuity
191 2013-08-24 06:41:32 <gmaxwell> sipa: mostly I just point out that if your offchain system is a type that produces a convincing transacript of its operation, you could move coins in and out of bitcoin by paying to a SCIP scriptpubkey and then proving a proper transcript to move them back.
192 2013-08-24 06:42:19 <gmaxwell> sipa: thats all you really need to know, I spent a lot of words on background that you already have, and details you could work out for yourself.
193 2013-08-24 06:42:55 <gmaxwell> BW^-: The technology behind it will likely become non-exotic eventually, but I don't know that we'd ever use it in bitcoin.
194 2013-08-24 06:44:00 <gmaxwell> BW^-: I posted about a privacy preserving transaction style people can use to get simiar (as good? better? not clear) privacy to ZC which needs no novel crypto or mods to the bitcoin network: https://bitcointalk.org/index.php?topic=279249.0
195 2013-08-24 06:52:36 <BW^-> noted.
196 2013-08-24 06:52:37 <BW^-> aha
197 2013-08-24 06:54:45 <gmaxwell> (I should have said "as good? better? worse? not clear" ??? and the resulting privacy depends on a lot of details and your threat model)
198 2013-08-24 07:03:11 <BW^-> so really, we cannot figure out how *high* the BTC transaction fee *could* become
199 2013-08-24 07:03:17 <BW^-> it could be 1-2BTC at the current value?
200 2013-08-24 07:03:24 <BW^-> i mean, absolutely hypothethically only
201 2013-08-24 07:03:44 <c0rw1n> the fees per block?
202 2013-08-24 07:03:58 <gmaxwell> It could be infinite, given a transaction denying dos attacker.
203 2013-08-24 07:04:50 <BW^-> c0rw1n: yep
204 2013-08-24 07:05:27 <theorbtwo> gmaxwell: As in a large hasher that only creates blocks with no transactions in it?  That seems like a somewhat unlikely way of trashing the currency -- the reward for being just a bit faster keeps going up, as more and more transactions are avilable to claim the fees of.
205 2013-08-24 07:06:15 <gmaxwell> theorbtwo: he said "i mean, absolutely hypothethically only"
206 2013-08-24 07:06:35 <gmaxwell> theorbtwo: altcoins have been trashed that way.
207 2013-08-24 07:06:54 <gmaxwell> but I'm not saying it's likely, I'm just making an example of why you really can't model far future fees.
208 2013-08-24 07:07:00 <gmaxwell> It depends on too many other things.
209 2013-08-24 07:07:32 <theorbtwo> *nod*
210 2013-08-24 07:08:24 <BW^-> to know what transaction fee per block should be accepted within 60 minutes today, what mechanism would you apply for fee autodetection?
211 2013-08-24 07:08:32 <gmaxwell> (I imagine more altcoins would get trashed that way if there were any good way to communicate and respond to fee requirements.. there is little incentive to try to drive the fees up in stock bitcoin software since doing so just kills the whole currency since people can't really respond)
212 2013-08-24 07:08:59 <gmaxwell> BW^-: I would look to see the highest fee per byte mempool transactions which are not being included.
213 2013-08-24 07:09:00 <BW^-> would you keep a log of all transactions made sorted by transaction fee applied, and measure how long it took them to be included?
214 2013-08-24 07:09:21 <theorbtwo> Personally, for me the big worry is the speed at which the blockchain grows.  "We" need to either figure out how to have people not need the full chain to be able to operate as useful nodes, or how to make the chain actually be shorter.
215 2013-08-24 07:09:22 <BW^-> gmaxwell: aha. so, sometihng like this then?
216 2013-08-24 07:09:29 <gmaxwell> looking at what _is_ included can be deceptive. Miners sometimes have external contracts to include some transactions. So it's better to look at what is left out.
217 2013-08-24 07:10:08 <BW^-> gmaxwell: aha. so, look at the highest that was left out, and go with a transaction fee 1% higher than that?
218 2013-08-24 07:10:17 <BW^-> or 1 satoshi higher than that? :))
219 2013-08-24 07:10:25 <gmaxwell> BW^-: something like that.
220 2013-08-24 07:10:54 <BW^-> mhm.  and, i'd count "not included" as not accepted into a block within 20 minutes - then even if i'd bet one too low and mine wouldn't be accepted in 20min too, within 48hrs someone just must accept it
221 2013-08-24 07:11:02 <gmaxwell> I haven't analyized the problem well enough to suggest an exact strategy, only that I think left out is the good metric to use.  "I don't have to outrun the tiger, I have to outrun you"
222 2013-08-24 07:11:19 <BW^-> mm mhm
223 2013-08-24 07:12:09 <theorbtwo> Contrarywise, miners could occasionally broadcast their fee preferences.
224 2013-08-24 07:12:42 <BW^-> theorbtwo: that's a nice idea, though what if they lie?  as a ddos thing
225 2013-08-24 07:13:00 <theorbtwo> Or just as a "make more money" problem.
226 2013-08-24 07:13:10 <BW^-> ah yeah
227 2013-08-24 07:13:32 <theorbtwo> The miner's motivations are pretty much opisite the normal users's in this case.
228 2013-08-24 07:14:53 <gmaxwell> yea, I think the fee broadcasting would be instantly abused.
229 2013-08-24 07:15:21 <gmaxwell> thats something that I'd probably abuse myself as a miner, and I'm generally not terribly prone to abusing things.
230 2013-08-24 07:16:10 <gmaxwell> the nice thing about the highest fee left out is that if a miner wants to raise fees he has to forgo transactions to manipulate that metric. he can't crank it up for free.
231 2013-08-24 07:16:36 <gmaxwell> (by abuse, above, I mean set it higher than I actually accept)
232 2013-08-24 07:27:36 <warren> Not fee broadcasting, but fee/delay statistics could give guidance to senders on the market rate for fees.  I'm not sure how to guard against collusion and escalation though.
233 2013-08-24 07:33:55 <gmaxwell> warren: you don't need collusion, fee bloating is self-coordinating.
234 2013-08-24 07:34:33 <gmaxwell> just raise your floor a little, the cost to you isn't great, and others will see they can raise their floors without much cost, and so on.
235 2013-08-24 07:34:45 <gmaxwell> robots can even to it.
236 2013-08-24 07:35:10 <warren> the current situation is mainly people just don't change defaults?
237 2013-08-24 07:35:18 <warren> or are the pools more sophisticated than that?
238 2013-08-24 07:35:22 <warren> p2pool sure isn't.
239 2013-08-24 07:35:32 <gmaxwell> people don't currently care, but users are also not currently adaptive.
240 2013-08-24 07:36:09 <warren> ah, they can't really be adaptive if they can't see fee/delay easily
241 2013-08-24 07:36:59 <gmaxwell> right. I don't think we have a choice but to help make users more adaptive... but the outcome may be interesting.
242 2013-08-24 07:45:53 <Supa> hey ball licker
243 2013-08-24 07:45:55 <Supa> it's my birthday
244 2013-08-24 07:46:08 <Supa> don't ban me you sister fuckin ass monkey
245 2013-08-24 09:17:31 <sipa> hey, upstream leveldb 1.13
246 2013-08-24 09:18:05 <sipa> it seems to add some extra synchronization calls, so perhaps it affects some of the issues we've been seeing
247 2013-08-24 09:18:10 <sipa> do we want it in 0.8.4?
248 2013-08-24 09:18:33 <warren> you mean the mac issue?
249 2013-08-24 09:18:57 <sipa> yes, among others
250 2013-08-24 09:20:08 <warren> what others?
251 2013-08-24 09:20:20 <sipa> well all corruption issues
252 2013-08-24 09:21:03 <sipa> where we actually have no clue whether they're caused by a single bug, or platform-specific issues, or hardware problems, or really just some amount of random bitflips
253 2013-08-24 09:39:36 <oleganza> hey. Here's how to lock savings for the future date without deleting any private keys: https://bitcointalk.org/index.php?topic=278992.msg2998079#msg2998079
254 2013-08-24 09:42:28 <gmaxwell> oleganza: you cannot do that.
255 2013-08-24 09:42:44 <oleganza> why
256 2013-08-24 09:43:08 <gmaxwell> oleganza: because you cannot change A once B is authored because the hash of A is a TX in in B.
257 2013-08-24 09:43:22 <gmaxwell> and there is no way to mask that.
258 2013-08-24 09:43:26 <oleganza> oh, shit
259 2013-08-24 09:43:27 <oleganza> true
260 2013-08-24 09:43:31 <gmaxwell> (I point this out in my message. :P)
261 2013-08-24 09:44:00 <oleganza> so it's like the same story as with OP_CODESEPARATOR
262 2013-08-24 09:44:07 <oleganza> i'll update my post
263 2013-08-24 09:45:21 <nsh> 
ACTION is uncaffinated, does this proposal solve timelock https://bitcointalk.org/index.php?topic=278992.msg2998079#msg2998079 ?

264 2013-08-24 09:45:35 <nsh> (in a way that would be usable for general encryption)
265 2013-08-24 09:45:46 <gmaxwell> 04:42 < gmaxwell> oleganza: you cannot do that.
266 2013-08-24 09:45:46 <gmaxwell> 04:42 < oleganza> why
267 2013-08-24 09:45:46 <gmaxwell> 04:43 < gmaxwell> oleganza: because you cannot change A once B is authored because the hash of A is a TX in in B.
268 2013-08-24 09:45:49 <gmaxwell> 04:43 < gmaxwell> and there is no way to mask that.
269 2013-08-24 09:45:52 <gmaxwell> 04:43 < oleganza> oh, shit
270 2013-08-24 09:45:53 <Luke-Jr> gmaxwell: hmm, does that mean the signature removal from scriptPubKey is in fact a noop?
271 2013-08-24 09:45:54 <gmaxwell> 04:43 < oleganza> true
272 2013-08-24 09:46:07 <oleganza> Luke-Jr: to me it seems so
273 2013-08-24 09:46:51 <oleganza> post updated
274 2013-08-24 09:47:29 <sipa> Luke-Jr: it's a noop in every meaningful transaction, imho
275 2013-08-24 09:47:47 <Luke-Jr> sipa: is there a non-noop case for non-meaningful transactions?
276 2013-08-24 09:47:53 <oleganza> sipa: my quest is to find those rare txs where the sig removal could be useful
277 2013-08-24 09:47:55 <sipa> Luke-Jr: but it could in theory be used to put a self-signature in a pubkey
278 2013-08-24 09:48:28 <Luke-Jr> sipa: the pubkey is from the previous transaction, though
279 2013-08-24 09:48:37 <Luke-Jr> or is the signature in that one removed as well?
280 2013-08-24 09:48:41 <sipa> no, this is IN the "previous" transaction
281 2013-08-24 09:48:49 <sipa> before the one spending it exists
282 2013-08-24 09:49:05 <oleganza> thanks, gmaxwell
283 2013-08-24 09:49:07 <sipa> well, you'd need to know the spending one in advance
284 2013-08-24 09:49:32 <sipa> it may just be impossible too
285 2013-08-24 09:50:37 <oleganza> bummer.
286 2013-08-24 09:50:44 <oleganza> time to sell all my btc
287 2013-08-24 09:51:07 <sipa> Luke-Jr: if you find a way to use it in a non-meaningful way, it would be a very interesting pulltester test :)
288 2013-08-24 09:51:43 <Luke-Jr> oleganza: don't you mean "make an altcoin"? :p
289 2013-08-24 09:52:32 <oleganza> Luke-Jr: I don't think altcoins are viable long-term http://blog.oleganza.com/post/54121516413/the-universe-wants-one-money
290 2013-08-24 09:52:44 <Luke-Jr> oleganza: I didn't say they were.
291 2013-08-24 09:53:06 <oleganza> i didn't accuse you :-) i just said why i'm not interested in making my altcoin
292 2013-08-24 09:53:08 <sipa> perhaps (non-alt)coins are not viable long-term either
293 2013-08-24 09:53:23 <oleganza> sipa: you mean BTC or fiat?
294 2013-08-24 09:53:38 <sipa> either
295 2013-08-24 09:53:46 <gmaxwell> the world is a funny place.
296 2013-08-24 09:53:56 <sipa> the distinction between alt and non-alt hardly exists at the technical level
297 2013-08-24 09:54:14 <sipa> the community, economy, scale, ... may differ
298 2013-08-24 09:54:21 <sipa> or the intentions of developers
299 2013-08-24 09:54:25 <oleganza> what would need to happen to replace BTC instead of fixing/extending it?
300 2013-08-24 09:54:36 <sipa> who knows?
301 2013-08-24 09:55:52 <oleganza> if we don't have good arguments when BTC cannot be extended to fix problems, we cannot knowingly say that it might not be viable
302 2013-08-24 09:58:22 <oleganza> sipa: what do you think of this idea of mutual insurance deposit without third party? https://bitcointalk.org/index.php?topic=273539.msg2933633#msg2933633
303 2013-08-24 09:59:59 <oleganza> it'd be cool to have some raw ops for EC point addition/multiplication
304 2013-08-24 10:00:12 <sipa> you mean as RPC?
305 2013-08-24 10:00:20 <oleganza> no, OP_*
306 2013-08-24 10:00:23 <oleganza> but alas
307 2013-08-24 10:00:25 <sipa> oh
308 2013-08-24 10:00:29 <sipa> yes
309 2013-08-24 10:00:42 <sipa> do you have an actual use case?
310 2013-08-24 10:01:16 <oleganza> not really
311 2013-08-24 10:02:00 <Luke-Jr> sipa: I do!
312 2013-08-24 10:02:43 <Luke-Jr> you could implement a HDW child key deriv in Script, so the redeemer can avoid reusing the same EC pubkey :p
313 2013-08-24 10:03:01 <sipa> well what's the point of that?
314 2013-08-24 10:03:15 <sipa> now you're revealing the master pubkey to the world
315 2013-08-24 10:03:23 <Luke-Jr> sipa: workaround idiots doing address reuse against your wishes
316 2013-08-24 10:03:33 <sipa> how is this better than address reuse?
317 2013-08-24 10:03:41 <sipa> it's address reuse at a higher level
318 2013-08-24 10:04:21 <Luke-Jr> maybe it's not.
319 2013-08-24 10:04:34 <sipa> ?
320 2013-08-24 10:04:42 <Luke-Jr> I was thinking "attackers wouldn't know the pubkey", but this only works if you use the pubkey in the scriptPubKey
321 2013-08-24 10:06:23 <oleganza> sorry for getting in again with my bilateral deposit scheme. I've though on how it could help making off-chain micropayments in a novel way.
322 2013-08-24 10:07:18 <oleganza> Mike Hearn already suggested a scheme with adjustable transaction where you send a stream of micropayments to your service provider until the deal is closed.
323 2013-08-24 10:07:35 <oleganza> but it does not work for cases where you just pay 10 cents once to someone and never talk to him again
324 2013-08-24 10:07:59 <Luke-Jr> oleganza: I suggested D-transactions a few months ago
325 2013-08-24 10:08:04 <oleganza> link?
326 2013-08-24 10:08:27 <Luke-Jr> https://gist.github.com/luke-jr/5409899
327 2013-08-24 10:08:47 <oleganza> also, even not-very-micropayments like $5 in a cafe would benefit from off-chain scheme to avoid trusting 0-conf txs and paying mining fees (if they get >10 cents in 5 years)
328 2013-08-24 10:09:54 <oleganza> Luke-Jr: its very similar to my idea, but I don't need user id and personal trust
329 2013-08-24 10:10:09 <oleganza> basically, a mesh of nodes that propagate IOUs between each other
330 2013-08-24 10:10:18 <Luke-Jr> oleganza: IOUs need trust.
331 2013-08-24 10:10:20 <oleganza> and all intermediate IOUs are valid only when both endpoints sign it
332 2013-08-24 10:10:24 <oleganza> yes
333 2013-08-24 10:10:33 <oleganza> the question is how to establish that trust
334 2013-08-24 10:10:44 <oleganza> without getting personal
335 2013-08-24 10:11:10 <Luke-Jr> no reason one couldn't set up their tip/donation addresses to "trust up to 1 BTC from anyone"
336 2013-08-24 10:11:10 <oleganza> so my bilateral deposits allow entering in a contract with total strangers that you never know personally.
337 2013-08-24 10:11:30 <oleganza> Luke-Jr: what do you mean?
338 2013-08-24 10:11:50 <Luke-Jr> oleganza: there is no real need to settle donations/tips made to me
339 2013-08-24 10:12:15 <oleganza> i don't follow you. I'm not talking about donations or tips
340 2013-08-24 10:12:21 <Luke-Jr> if someone hacks their client to double-spend a donation, it's irrelevant to me
341 2013-08-24 10:12:22 <oleganza> i'm talking about real confirmed payments
342 2013-08-24 10:12:32 <Luke-Jr> micropayments are usually donations and tips
343 2013-08-24 10:12:35 <oleganza> when double spending is undesireble
344 2013-08-24 10:12:52 <Luke-Jr> and as long as those exist, there is some flexibility on the network
345 2013-08-24 10:13:19 <Luke-Jr> I can then reassign that debt to anyone who trusts the guy tipping me.
346 2013-08-24 10:13:26 <Luke-Jr> even if they don't know/trust me
347 2013-08-24 10:13:41 <oleganza> but how you establish that trust?
348 2013-08-24 10:14:07 <Luke-Jr> 
ACTION shrugs

349 2013-08-24 10:14:22 <Luke-Jr> the point is that only very limited trust is needed
350 2013-08-24 10:14:48 <Luke-Jr> they don't need to trust me, as long as they trust anyone who has ever tipped me, or anyone who has tipped someone who has tipped me, etc
351 2013-08-24 10:15:02 <oleganza> my use case is this: I want to pay $1 for 10 Mb of wifi access in some foreign country and $2 in a cafe. Both wifi station and the cafe don't want to pay relatively high BTC tx fees or trust 0-conf transactions.
352 2013-08-24 10:15:09 <oleganza> yeah, i see
353 2013-08-24 10:15:30 <oleganza> your network's limitation is only in establishing closest "friends" that you need to trust.
354 2013-08-24 10:15:39 <oleganza> AFAIK, ripple works the same way
355 2013-08-24 10:15:50 <oleganza> (but i haven't spent enough time studying ripple)
356 2013-08-24 10:16:07 <Luke-Jr> perhaps your idea could be combined to make it even more flexible
357 2013-08-24 10:16:17 <oleganza> my idea is to solve this last requirement: to have some personal friends to whom you'll arbitrarily assign some amounts of $ to trust
358 2013-08-24 10:16:22 <oleganza> Yes!
359 2013-08-24 10:16:26 <oleganza> so imagine this
360 2013-08-24 10:16:38 <oleganza> you have this network of IOUs that you already know about
361 2013-08-24 10:17:26 <oleganza> but now in your phone you say something like "use up to 1000 mBTC for micropayments network"
362 2013-08-24 10:18:28 <oleganza> your phone finds some random nodes on the network, like in bitcoin or bittorrent, and establishes with some of them (that accept it) contracts with bilateral deposits of total value < 1000 mBTC
363 2013-08-24 10:19:00 <oleganza> e.g. 200 mBTC with this node, 300 mBTC with another one and 500 mBTC with yet another one
364 2013-08-24 10:19:34 <oleganza> these contracts are real BTC transactions
365 2013-08-24 10:19:38 <oleganza> your max amount of debt/credit is set to, say, 30% of the deposit amount.
366 2013-08-24 10:20:20 <oleganza> so with the first node you may have up to 60 mBTC in debts. After which point you settle debts using a real BTC tx
367 2013-08-24 10:20:24 <oleganza> and reset the debt
368 2013-08-24 10:20:50 <oleganza> since everything is automated, there is no possibility to personally blackmail another party
369 2013-08-24 10:21:07 <oleganza> if a node does not want to settle the debt, it will simply not get its money back
370 2013-08-24 10:22:14 <edcba> that looks like abuse everywhere
371 2013-08-24 10:22:30 <oleganza> irc abuse?
372 2013-08-24 10:22:49 <edcba> abuse of your 'protocol'
373 2013-08-24 10:23:01 <oleganza> how's that?
374 2013-08-24 10:23:35 <oleganza> any node will be able to have as many contracts as it has free money for.
375 2013-08-24 10:23:45 <edcba> if there is trust involved and anonimity there is mass trust violation waiting to happen
376 2013-08-24 10:23:57 <oleganza> So if you want to have 10000 clients with $100 deposits, you'd have to lock up $1M
377 2013-08-24 10:24:19 <oleganza> there's no personal trust, only trust in "nash equilibrium" so to speak
378 2013-08-24 10:24:29 <oleganza> imagine this:
379 2013-08-24 10:24:30 <edcba> wait i didn't read the beginning of your conversation
380 2013-08-24 10:24:39 <oleganza> https://bitcointalk.org/index.php?topic=273539.msg2933633#msg2933633
381 2013-08-24 10:24:50 <edcba> 
ACTION currently in a country where free wifi is lacking...

382 2013-08-24 10:24:59 <oleganza> edcba: where?
383 2013-08-24 10:25:37 <oleganza> you "trust" strangers only because they locked up the same amount of funds as you. And these funds are noticeably greater than the amount of debt. So it's more interesting to pay the debt and get money unlocked, than to lose your deposit.
384 2013-08-24 10:26:43 <edcba> bitcoin's own alledged country :)
385 2013-08-24 10:27:58 <oleganza> ;-)
386 2013-08-24 10:49:36 <porquilho> what
387 2013-08-24 10:49:37 <porquilho> oleganza
388 2013-08-24 10:49:49 <oleganza> ?
389 2013-08-24 10:49:52 <porquilho> oleganza, what is a contract?
390 2013-08-24 10:50:03 <porquilho> I dont get the idea
391 2013-08-24 10:50:09 <oleganza> imagine you live in Australia and I live in Russia
392 2013-08-24 10:50:12 <porquilho> ys
393 2013-08-24 10:50:13 <porquilho> yes
394 2013-08-24 10:50:17 <oleganza> and I want to buy your iPod for $100
395 2013-08-24 10:50:20 <porquilho> yes
396 2013-08-24 10:50:27 <oleganza> i don't know you, you don't know me
397 2013-08-24 10:50:35 <oleganza> and ebay won't help us
398 2013-08-24 10:50:37 <porquilho> yes
399 2013-08-24 10:51:10 <porquilho> ah i think i know the problem you are trying to solve
400 2013-08-24 10:51:22 <oleganza> because 1) we don't have any reputation 2) expensive 3) iPod is prohibited because of drug-porn-national-security 4) Ebay will never be able to figure out why it was or wasn't delivered across chinese borders
401 2013-08-24 10:51:32 <porquilho> nevermind the ebay
402 2013-08-24 10:51:36 <oleganza> so
403 2013-08-24 10:51:39 <oleganza> we both do this
404 2013-08-24 10:52:06 <oleganza> each of us locks up $300 in a single special transaction that only we together can unlock
405 2013-08-24 10:52:16 <porquilho> yes
406 2013-08-24 10:52:20 <oleganza> we don't give that money to third party and we cannot unilaterally spend it
407 2013-08-24 10:52:30 <porquilho> ok
408 2013-08-24 10:52:32 <oleganza> and each of us has a destruction tx with lock time in a month
409 2013-08-24 10:52:41 <porquilho> tx?
410 2013-08-24 10:52:43 <oleganza> so if someone goes rogue, another one can simply blow up the funds
411 2013-08-24 10:52:44 <porquilho> what is tx
412 2013-08-24 10:52:46 <oleganza> tx = transaction
413 2013-08-24 10:52:49 <porquilho> ok
414 2013-08-24 10:52:53 <oleganza> so
415 2013-08-24 10:53:21 <oleganza> we both locked $300 each.
416 2013-08-24 10:53:29 <oleganza> now you send me your iPod by mail
417 2013-08-24 10:53:32 <oleganza> it goes 2 weeks
418 2013-08-24 10:53:35 <oleganza> and then I get it
419 2013-08-24 10:53:39 <oleganza> now I have a choice
420 2013-08-24 10:54:03 <oleganza> either I send you money, or I start playing "poker" with you
421 2013-08-24 10:54:28 <oleganza> e.g. by saying "i won't pay you, but you'd be better off by unlocking the funds"
422 2013-08-24 10:54:44 <porquilho> yes
423 2013-08-24 10:54:53 <oleganza> if I send you the money, e.g. by BTC or wire transfer, we both at some equilibrium
424 2013-08-24 10:55:06 <oleganza> and either of us may try to play another one, or we simply unlock funds and go home
425 2013-08-24 10:55:34 <porquilho> let me see if i get it
426 2013-08-24 10:55:40 <oleganza> but if I got an iPod and start fucking with you, I risk losing my $300 (accounting for iPod, it'll be $200)
427 2013-08-24 10:56:16 <oleganza> because I have no idea how you will behave, your trust in me is zero and you can punish me by blowing up my money so I won't play the trick again in the future
428 2013-08-24 10:56:34 <oleganza> the key here is that we don't have perfect information about other person's possible behaviour
429 2013-08-24 10:56:49 <oleganza> and once anyone tries to be not nice with a counter-party, he risks his deposit
430 2013-08-24 10:57:18 <porquilho> let me think
431 2013-08-24 10:57:36 <oleganza> obviously, no one would enter such a contract with his life savings. So these $300 are most probably not something urgently needed by another person so you can blackmail him
432 2013-08-24 10:57:49 <oleganza> and you never know if he won't try to teach you a lesson
433 2013-08-24 10:58:15 <oleganza> same thing if I send you money first and then you send me iPod.
434 2013-08-24 10:58:21 <oleganza> the deal could be anything
435 2013-08-24 10:58:25 <oleganza> a product, a service, whatever
436 2013-08-24 10:59:01 <oleganza> the coolest use cases are when trust is established programmatically without ability to threaten other party
437 2013-08-24 10:59:35 <porquilho> so the locked funds work as a trust measure
438 2013-08-24 10:59:36 <oleganza> I have two cases in mind: 1) automatic bitcoin mixing peer-to-peer with random nodes during the night 2) mesh of IOU payments for off-the-chain transactions
439 2013-08-24 10:59:39 <oleganza> yep
440 2013-08-24 10:59:52 <oleganza> in my article I emphasize the pattern we use in daily life
441 2013-08-24 11:00:08 <gmaxwell> ...
442 2013-08-24 11:00:13 <oleganza> we trust people only when they demonstrated a heavier investment not worth losing
443 2013-08-24 11:00:18 <porquilho> ofcourse
444 2013-08-24 11:00:20 <gmaxwell> there is no need to use an escrow like transaction for "mixing"
445 2013-08-24 11:00:33 <porquilho> what is 'mixing'
446 2013-08-24 11:00:49 <oleganza> mixing is changing your history of coins for someone else's
447 2013-08-24 11:00:50 <oleganza> gmaxwell: how?
448 2013-08-24 11:01:02 <oleganza> i want mixing to not go through fancy scripts or shared addresses.
449 2013-08-24 11:01:17 <gmaxwell> oleganza: then you certantly don't want escrows involved.
450 2013-08-24 11:01:19 <porquilho> ah you are talking about coding implementations
451 2013-08-24 11:01:28 <gmaxwell> oleganza: https://bitcointalk.org/index.php?topic=279249.0
452 2013-08-24 11:01:28 <porquilho> ok
453 2013-08-24 11:01:31 <oleganza> best mixing is when all txs look like normal spendings, statistically indistinguishable from how normal txs work in economy
454 2013-08-24 11:02:08 <gmaxwell> oleganza: I'd prever to not use "mixing" it's rapidly conflated with money laundering which isn't the same thing. In any case, read and be happy.
455 2013-08-24 11:02:23 <oleganza> i'm talking about true laundering
456 2013-08-24 11:02:36 <gmaxwell> oleganza: then please get out of here.
457 2013-08-24 11:02:47 <oleganza> laundering != killing and raping.
458 2013-08-24 11:02:51 <oleganza> i'm talking about privacy
459 2013-08-24 11:03:02 <gmaxwell> Money laundering is unlawful in many places. If you don't want to refer to unlawful activity, then don't use the name for it.
460 2013-08-24 11:03:04 <oleganza> e.g. you got a paycheck worth $3000 for a month of work
461 2013-08-24 11:03:14 <oleganza> ok, "increasing privacy" then
462 2013-08-24 11:03:18 <oleganza> or "mixing"
463 2013-08-24 11:03:21 <porquilho> i think i like your idea oleganza, although I don't have any idea how to implement it
464 2013-08-24 11:03:30 <porquilho> but i think it wont be hard
465 2013-08-24 11:03:31 <porquilho> at all
466 2013-08-24 11:03:35 <gmaxwell> Thanks! mixing runs into laundering. Go look at my post in any case.
467 2013-08-24 11:03:37 <oleganza> i show how to implement it in my article
468 2013-08-24 11:03:54 <oleganza> gmaxwell: what safe word do you suggest?
469 2013-08-24 11:04:04 <gmaxwell> oleganza: if you think you need an escrow for it then you're going to be pleasently surprised when you _go read my link_
470 2013-08-24 11:04:18 <oleganza> i never said I need an escrow
471 2013-08-24 11:04:27 <oleganza> meaning, 3rd party.
472 2013-08-24 11:04:32 <oleganza> reading your link
473 2013-08-24 11:05:17 <gmaxwell> oleganza: you were referring to escrow transactions, I didn't mean a third party. You don't need an escrow transaction either.
474 2013-08-24 11:05:52 <gmaxwell> (besides, escrow transactions have "hold up risk", .e.g your counterparty could try to play a game of chicken with you)
475 2013-08-24 11:05:59 <oleganza> gmaxwell: my escrow transaction is absolutely separate from actual coins being moved. So it does not need to correlate with the mixed coins in any way
476 2013-08-24 11:06:48 <gmaxwell> 
ACTION cries

477 2013-08-24 11:06:49 <oleganza> hold up risk is lower when both parties are anonymous nodes without a way to chat together. E.g. by design, protocol may blow up funds after 1 week delay. So another party cannot know if it's safe for it to play chicken
478 2013-08-24 11:06:57 <oleganza> (still reading your link)
479 2013-08-24 11:07:02 <gmaxwell> oleganza: and it's all unnecessary. :P
480 2013-08-24 11:07:10 <oleganza> :-)
481 2013-08-24 11:07:19 <oleganza> i'll finish and comment
482 2013-08-24 11:09:00 <oleganza> gmaxwell: "This assumption is incorrect. Usage in a single transaction does not prove common control (though it's currently pretty suggestive)"
483 2013-08-24 11:09:06 <oleganza> you are right
484 2013-08-24 11:09:09 <oleganza> but that's not good enough
485 2013-08-24 11:09:21 <oleganza> this tx shows either of two things:
486 2013-08-24 11:09:34 <oleganza> 1. you control both inputs
487 2013-08-24 11:09:34 <oleganza> 2. you are laundering money with someone else
488 2013-08-24 11:10:08 <oleganza> there are anti money structuring laws (!=AML) that forbid making even legal funds being moved in a fancy way
489 2013-08-24 11:10:23 <oleganza> so by using join txs you sort of show that you are trying to do something fancy
490 2013-08-24 11:10:33 <oleganza> it could be good enough, I admit
491 2013-08-24 11:10:36 <gmaxwell> Performing a joint transaction, which helpfully reduces the transaction sizes and could just be a default behavior of wallet software.
492 2013-08-24 11:10:38 <oleganza> but we could do better
493 2013-08-24 11:11:03 <gmaxwell> oleganza: but I see your proposal too and I think it adds to this ecosystem of ideas.
494 2013-08-24 11:11:11 <oleganza> i think in terms of "histories". Each "coin", so to speak, has a trace.
495 2013-08-24 11:11:20 <oleganza> Join transactions join these traces
496 2013-08-24 11:11:34 <oleganza> But my idea in idealistic form looks like this:
497 2013-08-24 11:11:43 <oleganza> imagine 1024 persons coming together in a circle
498 2013-08-24 11:11:48 <oleganza> each has a single coin
499 2013-08-24 11:11:53 <gmaxwell> I think what I offer here has considerable simplicity, and also will make people stop bothering depending on trying to guess at histories, weather they are valid or not. What you're suggesting obscures the connection entirely, which is interesting.
500 2013-08-24 11:11:58 <oleganza> and a history
501 2013-08-24 11:12:05 <oleganza> each of them splits this coin in two parts and sends to 2 random people
502 2013-08-24 11:12:19 <oleganza> in exchange he gets some other pieces from other random people
503 2013-08-24 11:12:25 <oleganza> that's round 1
504 2013-08-24 11:12:39 <oleganza> then round 2 does the same by splitting existing pieces
505 2013-08-24 11:12:41 <oleganza> and so on
506 2013-08-24 11:13:15 <oleganza> in 7 rounds each of them has 128 different little not-correlated in any way histories
507 2013-08-24 11:13:20 <oleganza> no join transactions etc.
508 2013-08-24 11:13:23 <oleganza> like normal payments
509 2013-08-24 11:13:46 <gmaxwell> oleganza: but also a bunch of additioanl non-normal transaction establishing escrows to secure those funds.
510 2013-08-24 11:14:02 <gmaxwell> Which are seperate, I understand.
511 2013-08-24 11:14:25 <gmaxwell> But there is an additional cost there.
512 2013-08-24 11:14:47 <gmaxwell> In any case, I think more ideas only add to the privacy preserving ways to transact.
513 2013-08-24 11:15:22 <oleganza> these escrows could be completely on the side
514 2013-08-24 11:15:53 <oleganza> if you don't pay with money from these escrow (or mix that money before doing so), these escrows never mark your reputation
515 2013-08-24 11:16:21 <gmaxwell> Yea, I get it. It's a neat I hadn't thought of even while simultaniously proposing almost exactly the same thing for something else. (I'll PM)
516 2013-08-24 11:16:31 <oleganza> yes, it's slower and a bit more expensive to establish an escrow, but as a result you can get as clean money as statistically possible
517 2013-08-24 11:16:43 <oleganza> but you don't need it always
518 2013-08-24 11:16:53 <oleganza> you need it only after receiving a paycheck
519 2013-08-24 11:17:01 <oleganza> so you don't advertise how much do you make
520 2013-08-24 11:17:21 <oleganza> and you do the same before paying big sums to avoid connecting all your little payments in one tx
521 2013-08-24 11:17:35 <gmaxwell> yea, things like income privacy are a big problem.
522 2013-08-24 11:17:41 <oleganza> your wallet can do that automatically during the night
523 2013-08-24 11:17:49 <oleganza> the cost is like under $1 for 10 escrows
524 2013-08-24 11:18:16 <gmaxwell> oleganza: what I sent you in PM was an idea I had for using potentially similar transaction patterns, but for inter service transfers.. totally different application.
525 2013-08-24 11:18:18 <oleganza> if it gets popular, this escrow tx can be standard and be processed quicker+cheaper
526 2013-08-24 11:18:34 <gmaxwell> oleganza: escrow transactions are already standard.
527 2013-08-24 11:18:58 <gmaxwell> multisig will always be somewhat more costly, as they're bigger. alas.
528 2013-08-24 11:19:14 <oleganza> plain multisig is != what I propose
529 2013-08-24 11:19:18 <oleganza> my escrow is mutually atomic
530 2013-08-24 11:19:35 <oleganza> i'll check you PM first
531 2013-08-24 11:20:13 <gmaxwell> oleganza: can you link me to where you described your escrow.
532 2013-08-24 11:20:32 <oleganza> http://blog.oleganza.com/post/58240549599/contracts-without-trust-or-third-parties
533 2013-08-24 11:20:43 <oleganza> there's a minor correction to the script: https://bitcointalk.org/index.php?topic=273539.0
534 2013-08-24 11:21:49 <gmaxwell> oh, this script may look familar: https://bitcointalk.org/index.php?topic=91843.msg1011956#msg1011956
535 2013-08-24 11:22:42 <gmaxwell> do you address what happens if alice is hit by a bus?
536 2013-08-24 11:23:23 <Luke-Jr> she dies
537 2013-08-24 11:23:38 <gmaxwell> Luke-Jr: but is her soul saved?
538 2013-08-24 11:23:56 <Luke-Jr> gmaxwell: depends on the colour of the bus
539 2013-08-24 11:24:02 <gmaxwell> "no, she didn't use backupwallet"
540 2013-08-24 11:25:24 <oleganza> gmaxwell: bitcoin protocol does have OP_IF for death
541 2013-08-24 11:25:38 <oleganza> gmaxwell: generally people try not to die, so we can trust them on this one
542 2013-08-24 11:26:16 <oleganza> to detect death one needs a 3rd party
543 2013-08-24 11:26:33 <gmaxwell> :-/ kind of a big disadvantage in your protocol though.
544 2013-08-24 11:26:46 <gmaxwell> my disk fails at a bad moment and we both lose our coin.
545 2013-08-24 11:26:58 <oleganza> if you cannot/don't want to have 3rd party, that's the risk
546 2013-08-24 11:27:21 <oleganza> same applies to any btc usage
547 2013-08-24 11:27:25 <gmaxwell> well, or you do what I suggest. But in any case, I think diversity of techniques is good.
548 2013-08-24 11:28:07 <petertodd> oleganza: Really similar underlying mechanism to oracle transactions as well as my one-time-password protected wallet idea.
549 2013-08-24 11:28:32 <oleganza> gmaxwell: you mean conjoin?
550 2013-08-24 11:28:36 <oleganza> *coinjoin
551 2013-08-24 11:28:51 <gmaxwell> oleganza: yes.
552 2013-08-24 11:29:10 <gmaxwell> oleganza: has no risk of losing money if a party goes away...
553 2013-08-24 11:29:15 <oleganza> i'm thinking of these contracts in a broader sense
554 2013-08-24 11:29:26 <oleganza> to establish measurable trust with strangers for whatever reason
555 2013-08-24 11:29:39 <Luke-Jr> gmaxwell: did you publish coinjoin yet?
556 2013-08-24 11:29:57 <oleganza> coinjoin could be good enough for privacy, but it's not good enough for AMS/AML
557 2013-08-24 11:30:04 <oleganza> i mean it.
558 2013-08-24 11:30:41 <oleganza> if we didn't have AML/AMS laws, we'd all just use join txs and then we'd truly never knew what's your history and what's mine
559 2013-08-24 11:30:43 <gmaxwell> Luke-Jr: yes.
560 2013-08-24 11:30:56 <oleganza> maybe when Bitcoin gets us to beautiful anarchy, we'd use that
561 2013-08-24 11:31:17 <oleganza> but before, it's better to have as much precaution as possible
562 2013-08-24 11:31:32 <gmaxwell> oleganza: fincen's opinion was that bitcoin _users_ aren't subject to AML/KYC laws. And in any case, you cannot prevent it.
563 2013-08-24 11:31:37 <petertodd> oleganza: Um, my thinking is to make it that using join tx's is the standard thing people do.
564 2013-08-24 11:31:43 <Luke-Jr> oh great, you're one of the anarchist nuts?
565 2013-08-24 11:31:54 <oleganza> fincen will change their opinion any time they want
566 2013-08-24 11:32:03 <gmaxwell> the transactions look every bit like normal ones, and they're pretty prudent to make for non-privacy reasons.
567 2013-08-24 11:32:03 <oleganza> if Bitcoin gets bigger expect bigger invasion
568 2013-08-24 11:32:17 <oleganza> Luke-Jr: i said "maybe"
569 2013-08-24 11:32:25 <petertodd> Luke-Jr: Me? Anarchist? Nah, I just want to make sure that when I give the tax authorities my transaction data it's only they who have it.
570 2013-08-24 11:32:32 <Luke-Jr> petertodd: not you :p
571 2013-08-24 11:32:34 <oleganza> i guess it's me
572 2013-08-24 11:33:00 <Luke-Jr> [13:30:55] <oleganza> maybe when Bitcoin gets us to beautiful anarchy, we'd use that
573 2013-08-24 11:33:01 <petertodd> Luke-Jr: I trust my government, but not foreign terrorists and spys trying to get into on my business.
574 2013-08-24 11:33:12 <petertodd> *info on
575 2013-08-24 11:33:16 <oleganza> petertodd: do you trust NSA?
576 2013-08-24 11:33:36 <gmaxwell> Indeed, I don't care to hid _anything_ from a tax authority, og I spend enough time keeping records for them already.   But seriously, theieves and other nerdowells are exploiting the lack of privacy in bitcoin today and will do more in the future.
577 2013-08-24 11:33:45 <petertodd> oleganza: Of course I trust the NSA. But unless I use coinjoin on all my transactions I have to trust those communists in China too.
578 2013-08-24 11:35:03 <petertodd> I might even need to use coinjoin for HIPAA compliance to ensure that my patients privacy is protected too after all when they pay me for the non-socialist healthcare I provide.
579 2013-08-24 11:35:28 <gmaxwell> In any case, time to get some things done. :)
580 2013-08-24 11:35:32 <sipa> hmm, leveldb 1.13 adds a random number generator somewhere
581 2013-08-24 11:36:19 <oleganza> gmaxwell: i agree with your sentiment.
582 2013-08-24 11:36:19 <petertodd> gmaxwell: Heh, all the python-bitcoinlib work I've done recently is for coinjoin stuff. :)
583 2013-08-24 11:37:23 <oleganza> petertodd: why do you trust NSA? They provided you with a service that you are satisfied with?
584 2013-08-24 11:38:00 <petertodd> oleganza: Maybe my sarcasm didn't quite come through... but I'm serious with the HIPAA example and tax authority example.
585 2013-08-24 11:38:25 <gmaxwell> sipa: I thought it just added testing for good seed values for an existing one.
586 2013-08-24 11:38:31 <oleganza> what I mean to say is how do we generally establish "trust" and how does that apply to your trust in government?
587 2013-08-24 11:38:46 <oleganza> i myself have nothing against government. I just would like it to be not against me as well.
588 2013-08-24 11:39:01 <oleganza> but that's a fuzzy territory
589 2013-08-24 11:39:53 <oleganza> e.g. I establish trust to Apple by asking advice of friends, watching them investing shitload of money in production, and trying out cheaper products before risking paying for more expensive ones.
590 2013-08-24 11:40:02 <oleganza> and I can always measure if they are worth the trust.
591 2013-08-24 11:40:13 <oleganza> if iPhone sucks, i won't buy another one - trust is over.
592 2013-08-24 11:40:31 <oleganza> and if I never was interested in iPhones in the first place, I don't need to trust Apple at all
593 2013-08-24 11:40:42 <oleganza> so i won't have any trust towards them
594 2013-08-24 11:41:12 <oleganza> with government I never had an opportunity to measure trust because I never ordered anything that I need from them
595 2013-08-24 11:41:28 <Luke-Jr> you get your security from them
596 2013-08-24 11:41:32 <oleganza> it was already paid for and given (for anarchists it sucks, for non-anarchists it may not)
597 2013-08-24 11:41:59 <oleganza> that security is given, not asked for. So even if it's the best of the best, I can never know that and have nothing to compare with
598 2013-08-24 11:42:38 <oleganza> it's like trusting a lion that it'll eat a zebra. It will do it anyway, without your approval
599 2013-08-24 11:42:52 <oleganza> or won't, according to his own schedule.
600 2013-08-24 11:43:32 <oleganza> So while people may enjoy stuff that gov gives them, it's all given and creates no trust. Any day for some good reason people giving you security may deny you it.
601 2013-08-24 11:43:44 <oleganza> because they didn't establish trust with you, they have no trust to break.
602 2013-08-24 11:44:36 <oleganza> so if a policeman harms you in some way, he'll get punished not by you, not by your neighbors, but by a government official - his boss, a judge etc. And they may have their own agendas, not correlated with what you have in mind
603 2013-08-24 11:44:48 <Luke-Jr> should a government cease to serve the common good, it would also cease to be a government and would become a criminal organization
604 2013-08-24 11:45:28 <oleganza> i think before forcing people to comply, it's good to peacefully prove that "common good" to those in doubt
605 2013-08-24 11:46:17 <oleganza> e.g. when I want some privacy from my legitimate source of income, I don't agree with AML/AMS laws. But I cannot avoid them - I'll be beaten no matter what. So my doubts have no power.
606 2013-08-24 11:46:56 <oleganza> I can vote, but that's just a suggestion to a delegated power. I need to have 90% of people to agree with me on my tiny issue to be protected.
607 2013-08-24 11:47:22 <oleganza> (not saying i have urgent need to hide some money, just an example)
608 2013-08-24 11:47:28 <Luke-Jr> oleganza: I didn't say the systems are perfect. Far from it. But we're getting off topic here now.
609 2013-08-24 11:47:36 <sipa> gmaxwell: it adds a seed to dbimpl, and a random number generator to some iterator code
610 2013-08-24 11:47:45 <oleganza> well, I was not calling people names by saying "anarchist nut"
611 2013-08-24 11:47:57 <gmaxwell> sipa: :-/
612 2013-08-24 11:48:02 <sipa> gmaxwell: seems to be for se random sampling to trigger compactions, in case many deleted keys exist
613 2013-08-24 11:48:30 <oleganza> i know a few anarchists who have good arguments and I wouldn't call them "nuts" for having an opinion. Killing/detaining/forcing people is not in their agenda, so it's safe to talk to them
614 2013-08-24 11:48:44 <petertodd> oleganza: off topic
615 2013-08-24 11:48:46 <gmaxwell> sipa: I see.
616 2013-08-24 11:48:46 <rodarmor> Question for someone smarter than I: Would it be helpful or harmful to development and testing if I were to create an app or game that integrated testnet coins and testnet chain transactions? I was thinking about a simple gambling game, or a strategy game that used testnet coins as an internal currency.
617 2013-08-24 11:49:07 <gmaxwell> rodarmor: have a blast, make more testnet transactions.
618 2013-08-24 11:49:14 <Luke-Jr> rodarmor: IMO it might help, simply because it gives testnet more activity
619 2013-08-24 11:49:23 <Luke-Jr> certainly shouldn't hurt
620 2013-08-24 11:49:24 <rodarmor> That's what I was thinking.
621 2013-08-24 11:49:35 <oleganza> petertodd: Ok. Just want to underscore my dislike of calling people names here.
622 2013-08-24 11:49:41 <gmaxwell> rodarmor: also if your stuff gets more people using testnet, I will buy you your choice of beverage.
623 2013-08-24 11:49:59 <rodarmor> Although, haven't there been problems in the past when testnet coins somehow gained value and the whole thing had to be reset?
624 2013-08-24 11:50:02 <Luke-Jr> oleganza: my problem is really when people try to make Bitcoin part of their anarchist agenda.
625 2013-08-24 11:50:10 <gmaxwell> rodarmor: yea not really a problem now I think.
626 2013-08-24 11:50:13 <rodarmor> gmaxwell: thanks, I will definitely call that in if this comes of anything :)
627 2013-08-24 11:50:16 <Luke-Jr> oleganza: which harms Bitcoin
628 2013-08-24 11:50:22 <gmaxwell> and if it needs to be reset again we can of course.
629 2013-08-24 11:50:46 <gmaxwell> But I also own like a million testnet btc, so I suspect I can just dump coins to suppress any gain in value.
630 2013-08-24 11:50:47 <petertodd> rodarmor: Worst comes to worst we'll just add a infinite money generator to testnet, and as gmaxwell said it can be reset on a dime.
631 2013-08-24 11:51:00 <oleganza> Luke-Jr: when I was mentioning increasing BTC privacy in respect to AML/AMS, it was 100% technically relevant.
632 2013-08-24 11:51:31 <rodarmor> Good deal. I was also thinking it would be interesting if the game had some notion of an apocalypse event in the narrative, so a test net reset could be integrated into the story :)
633 2013-08-24 11:51:56 <oleganza> Luke-Jr: just like Bitcoin blockchain does not ask money license to operate. Talking about such design is relevant and can be equally called "an anarchist agenda"
634 2013-08-24 11:52:06 <gmaxwell> rodarmor: if your game is actually being used we could figure out how to help make such an event easier on you.
635 2013-08-24 11:52:26 <gmaxwell> oleganza: we're really getting into a political argument here... we could move it to #bitcoin
636 2013-08-24 11:52:37 <oleganza> gmaxwell: ok
637 2013-08-24 11:52:43 <petertodd> rodarmor: lol! seriously, make it cool and shiny and something people play with and I'll throw you a btc, the real kind. Best to include an integrated coin faucet, or make the expected return be 100%
638 2013-08-24 11:52:45 <gmaxwell> (I'd like to respond to some of these points, but I don't want to contribute to it going offtopic more)
639 2013-08-24 11:52:57 <rodarmor> petertodd: What kind of infinite money generator would be added? Do you mean actually patch the test net code?
640 2013-08-24 11:53:23 <petertodd> rodarmor: Yes, like max a special txout that can be spent endlessly.
641 2013-08-24 11:53:27 <petertodd> s/max/make/
642 2013-08-24 11:53:53 <rodarmor> I like it. It's like pulling the plug out of the bathtub in reverse.
643 2013-08-24 11:55:20 <petertodd> rodarmor: Yup. Has some issues because it's a special case - we'd rather not have that - and because people could potentially use it to make transactions that actually overflow ints and what not.
644 2013-08-24 11:55:58 <rodarmor> petertodd: How is the test net client code segregated from mainline client code? Does it build from the same sources with some extra flags?
645 2013-08-24 11:56:40 <gmaxwell> rodarmor: it's the same binary.
646 2013-08-24 11:56:44 <gmaxwell> bitcoind -testnet=1
647 2013-08-24 11:56:46 <petertodd> rodarmor: Exactly. It's very close to 100% compatible - the one major difference is in testnet if a block has a timestamp > 20 minutes from the previous one, it's allowed to have a difficulty 1 PoW.
648 2013-08-24 11:57:51 <rodarmor> petertodd: mmm, gotcha, I was wondering how difficulty fluctuations would work
649 2013-08-24 11:58:03 <rodarmor> gmaxwell: But isn't that kind of dangerous, just because bugs from test net only code could possibly leak into main client code?
650 2013-08-24 11:58:13 <sipa> petertodd: allowed or required?
651 2013-08-24 11:58:33 <sipa> (just a question; i don't know)
652 2013-08-24 12:00:13 <gmaxwell> rodarmor: there is very little testnet specific code by design. And it neatly fits into little if (fTestnet) boxes.
653 2013-08-24 12:01:07 <petertodd> sipa: interesting, no it's required for block.nBits to be == nProofOfWorkLimit in that case
654 2013-08-24 12:01:47 <gmaxwell> petertodd: you can always understate the time.
655 2013-08-24 12:01:50 <petertodd> sipa: The special case is in GetNextWorkRequired(), and the test in AcceptBlock() is block.nBits != GetNextWorkRequired()
656 2013-08-24 12:02:16 <petertodd> gmaxwell: Of course, point is if you don't do that, nBits *must* be set to the min work.
657 2013-08-24 12:02:18 <rodarmor> On a somewhat unrelated note, what is the contingency plan in case of a huge drop in hashing power on the main net? For example, if some unknown third party ran a warehouse of ASICs for a while and then turned them off, driving the block generation time up to impractical levels.
658 2013-08-24 12:03:00 <sipa> rodarmor: the network would be vulnerable anyway in that case
659 2013-08-24 12:03:03 <gmaxwell> rodarmor: go home? I mean if a single failure causes more than a doubling of block time, it means a single party had >50% hashpower and our security assumptions were already out the window.
660 2013-08-24 12:03:22 <petertodd> rodarmor: If you think about it in terms of mining == voting all that means is we've got a new voting block and will just have to accept what they want.
661 2013-08-24 12:03:33 <sipa> the solution would be an altcoin with a different PoW i think :)
662 2013-08-24 12:03:37 <petertodd> rodarmor: Technically speaking there's very little we can do that's compatible with SPV clients.
663 2013-08-24 12:03:55 <gmaxwell> anything up to a 4x-ing of interblock time is probably not a horrible thing in any case... and that would imply a 75% consolidation...