--- Log opened Sat Jan 04 00:00:52 2014
01:25 < andytoshi> gmaxwell: why can't alice just sybil that?
01:25 < andytoshi> if she wants to borrow more than her lenders want, just restart with a new tree
01:28 < andytoshi> or better, have a new tree for each lender -- then they all see a proof that their entry was added, and each sees only their own total
01:32 < gmaxwell> andytoshi: note the first line— assumption is that the reputation system is already preventing that.
01:32 < andytoshi> oh, derp, i read right through that
01:32 < gmaxwell> andytoshi: a common pattern we see on otc and bitcoin talk is that someone starts an account and makes boring breakeven trades for a year, gradually increasing the amounts, and then does tons of large loans all at once.
01:32 < andytoshi> the line "she publishes the root hash and the proofs in the rep system"
01:33 < gmaxwell> andytoshi: example https://bitcointalk.org/index.php?topic=393593.msg4274997#msg4274997  (thats just one post in a six page thread of people who were ripped off)
01:35 < gmaxwell> suggestions that people publish their loan amounts in OTC in the ratings list have generally been met with unwelcome sounds wrt privacy... though people do it sometimes, esp for smaller amounts with newer traders.
01:35 < andytoshi> ok, i see now, this is really cool .. i think it has the highest usefulness/computational hardness ratio of anything you've posted involving zk proofs
01:35 < gmaxwell> yes, also ... implementable outside of bitcoin.
01:36 < gmaxwell> (Any idea where step 1 is change bitcoin ... is just a lot harder to do, regardless of the details)
01:36 < andytoshi> i'm going to go post this in #coindev and see if anybody wants to implement it..
01:37 < gmaxwell> also, since it involve loss of currency, the CRS-assumption ZKP systems (where you trust that some key creator has thrown away a master key) aren't so bad.
01:38 < gmaxwell> e.g. you're trusting someone to not have kept data that would allow them to make fake loan accumulators. whoptiedo.
01:38 < andytoshi> i wonder if there's a stronger/simpler zk proof system for updating merkle trees like this
01:38 < andytoshi> which maybe doesn't work for general computations
01:38 < gmaxwell> maybe, though as soon as you need proofs for bitcoin thats right out.
01:40 < warren> I suppose this is why the credit agencies ding you for hard pulls.
01:40 < gmaxwell> in any case, proving a very simple function like this should actually be quite realistic, e.g. cpu time of tens of seconds.
01:41 < gmaxwell> warren: hah you could actually make number of proofs a metric that it tracks and extracts.
01:41 < gmaxwell> (e.g. to do a proof for someone they give you nonce, which you must insert into a pulls counter tree.)
01:42 < gmaxwell> it's not quite so cheap that my trivial NIZK would be useful, I expect.
01:42 < gmaxwell> but I guess I should go count how many AND-gates sha256 has.
06:49 < nsh> happy new year, wizards :)
09:57 < jtimon> https://bitcointalk.org/index.php?topic=396991.0
10:08 < tholenst> 24 coins built there already...
10:08 < tholenst> and that's not even counting the ones which prefer to remain private
10:10  * nsh considers a "proof of quality" based blockchain
10:10 < nsh> difficult, all involve voting i suppose
10:11 < nsh> e.g. new block whenever someone comes up with a joke that is considered funnier by >75% of people
10:16 < tholenst> The new scip paper http://eprint.iacr.org/2013/879 seems promising, but they still don't give a download link
10:30 < nsh> hmm, ty
10:32 < tholenst> How long does verification of a ECSDA signature take?
10:34 < nsh> depends on the library, etc.
10:34 < nsh> (and scheme)
10:35 < nsh> --
10:35 < nsh> Wow, it's great.
10:35 < nsh> 187us versus OpenSSL's 1008us, on my test laptop.
10:36 < nsh> -- sipa's implementation of sepk256k1, last July
10:36 < nsh> https://bitcointalk.org/index.php?topic=236477.0
10:38 < tholenst> So they talk of 5ms verification time for a program, but that's not on a lapt, so one would probably have to verify a few hundred signatures -- but they only run their program for 32'000 instructions, so it doens't seem quite useful for signature verification yet
10:39 < tholenst> also they talk of a 16 bit machine...
12:06 < andytoshi>  oh my god, the comments on BlueMatt's altgen thread..
12:09 < nsh> always wear appropriate protective eyewear. do not stare directly at derp
12:10 < adam3us> andytoshi: on bct?
12:10 < andytoshi> adam3us: yeah, https://bitcointalk.org/index.php?topic=396991.0 -- jtimon posted it a few hours ago
12:13 < adam3us> andytoshi: lol 'bulk discounts' etc
12:13 < jtimon> yeah, this was hilariously absurd: https://bitcointalk.org/index.php?topic=398272.0
12:14 < nsh> "We will hard fork you out, then we will have to continue with GPU without you."   (imagines set to all your base graphics...)
12:17 < nsh> or
12:17 < tholenst> It's awesome. It essentially says: "If you give me money, that'll help me to fraud people!"
12:17 < nsh> there's reductio ad absurdum and then there's straight out building a highway to absurdity.
12:30 < jtimon> hehe highway to absurdity...
12:40 < Luke-Jr> "Yes, it works fine and you do not end up on the wrong chain as long as you have a different network packet magic - as your node will never peer with another node with a different magic."
12:40 < Luke-Jr> hahaha
13:59 < jtimon> does anyone know if any of the results have been launched on the alts subforum already?
14:26 < Luke-Jr> nsh: can I quote you? [17:17:31] <nsh> there's reductio ad absurdum and then there's straight out building a highway to absurdity.
14:26 < Luke-Jr> (I already did, but I forgot to ask first..)
14:27 < nsh> sure
14:27 < nsh> :)
14:27 < Luke-Jr> thx
14:31 < Luke-Jr> "hello, is there a way to set a permanent change address?"
14:31 < Luke-Jr> why do I get these PMs now?
14:32  * Luke-Jr replies "No, because that would be broken and stupid."
15:44 < _ingsoc> Does anyone mess around with Go?
15:45 < gmaxwell> tholenst: their scaling is nearly linear, so you can scale up the cycle count. Also, 32000 instructions is enough to do hash based signing. In any case, the tinyram stuff is always going to be less efficient (by ... 10 to 1000 fold) than direct circuits specialized for the task at hand.
15:58 < nsh> tinyram is just a didactic model though. there's no reason you couldn't adapt it to specialized problems
15:58 < nsh> (that i can think of, at least)
16:00 < gmaxwell> nsh: well kinda, there are ways of using this stuff where you want the circuit under evaluation to be a constant thing.
16:01 < nsh> mmm
16:01 < gmaxwell> and with tinyram you could make it constant (or at least constant up to some execution length) and the hash of the program being run is just a public input.
16:01 < gmaxwell> so it really can be useful to have a fully generic circuit.
16:01  * nsh nods
16:03 < gmaxwell> you could, of course, add extra instructions. e.g. for our applications a SHA256 operator would be super useful.
16:03 < nsh> hmm, good point
16:05 < tholenst> gmaxwell: yes, i know... i was trying to get a grasp of whether it would be useful for example just to batch all signature verifications... but I found it difficult to assess. Would be nice if there was an implementation available
16:06 < gmaxwell> tholenst: yea, I don't know why they haven't made it available. They're using the same backend math as pinocchio, so you could look that up.
16:06 < tholenst> I could just ask them :)
16:07 < gmaxwell> tholenst: IIRC only a few of the pairing operators are input specific, as I recall.
16:07 < gmaxwell> So I think that if your circut is constant you can precompute a fair bit.
16:08 < gmaxwell> (A few, being like two pairing operations I think)
16:08 < tholenst> i don't acutally have a specific application in mind...
16:11 < tholenst> I was thinking more about extending the scripting language recently anyhow :)
16:12 < tholenst> It should be like this: if you have a reserved opcode in the pubkey script, the script should automatically accept no matter what happened before.
16:14 < gmaxwell> tholenst: well it's not. Its easy to build extensions that work like that anyways.
16:14 < gmaxwell> e.g. just different OP_EVALs for new P2SHes that make transactions look hashlocked to the old nodes.
16:16 < tholenst> do you mean exactly the same as P2SH, but a different op-code instead of OP_HASH?
16:16 < tholenst> i don't see right now how you mean that
16:18 < Luke-Jr> tempting to revise Script in a P2SH^2
16:21 < gmaxwell> tholenst: effectively.
16:22 < tholenst> oh i see -- you can just take one which is effectively a NOP now
16:47 < tholenst> btw i was thinking more about what it would need in scripting to implement the idea that you can have deposits for your transactions; i.e., if you double spend you lose money
16:47 < tholenst> i think it's reasonable
16:51 < sipa> that implies scriots can access state outside of the chain they operate on
16:51 < sipa> which is extremely jard to get right, i think
16:51 < sipa> scripts, hard
16:51 < tholenst> no
16:52 < tholenst> i don't need thta
16:52 < sipa> double spends don't exist within one chain
16:52 < sipa> if you're even using that word, it implies you're observing other state
16:53 < Luke-Jr> tholenst: double spending is not detectable technically really
16:53 < Luke-Jr> two signed transactions spending the same coin, is not necessarily "double spending"
16:53 < Luke-Jr> it can occur in legitimate circumstances too
16:53 < tholenst> well, the idea is different: I give you a transaction which essentially says: "If you find messages m_1 != m_2, signed with SecretKeyA, then you can have this money here"
16:53 < sipa> ah!
16:54 < sipa> you'd need some higher order construxt in transactions
16:54 < sipa> but indeed, that doean't require access to other data
16:54 < tholenst> yes, you need improved scripting, but it suffices to look at the chain
16:54 < nsh> hrmmm
16:54 < sipa> just means you need to embed the two different spending transactions inside your script
16:54 < nsh> interesting idea
16:55 < sipa> no it does not suffice to look at the chain
16:55 < sipa> within the chain double spends are impossible already
16:55 < tholenst> Luke; I know that; a bit more work is necessary for that
16:55 < tholenst> no you just need to embed the two signatures in the script; I can do that
16:55 < sipa> right, indeed
16:56 < tholenst> the chain will get two signatures, from the same secret key, which I assemble from the double spend; thus, the scripting doesn't look outside the chain
16:56 < sipa> yup
16:56 < sipa> but you need some meta construct
16:57 < sipa> where you embed the two previous conflicting signatures as proof that a double spend existed
16:57 < sipa> which is possible and sane
16:57 < sipa> but doesn't exist currently
16:57 < tholenst> actually, until here you don't need so much; you only need to be able to call ECDSA_CHECKSIG directly, and then you can do it similar to detecting a SHA256 collision
16:57 < sipa> (i'm also not convinced about the usefulness, but that's another matter)
16:58 < tholenst> but -- the problem is that the money which is supposed to back your transaction might be gone once you detect the double spend. For this you need more, and weirder opcodes
16:59 < sipa> well if it's gone, it's gone
17:00 < sipa> going beyond the basic rule of "a coin can only be spent once" is dark magic
17:00 < tholenst> i adhere to that basic rule
17:01 < tholenst> the basic idea is: if you spend a "backing coin", you can only spend it in such a way that for the next... say 100 blocks, it still remains a backing coin
17:01 < tholenst> and only after that it can become a usual coin
17:02 < sipa> mhmm... dark magic :)
17:03 < tholenst> i don't think there's anything dark there
17:03 < sipa> (not impossible, and not necessarily a problem, but i think the consequences become horrible to reason about)
17:04 < tholenst> no, why? will you be happy if i give a proof of some good properties?
17:04 < sipa> no need to convince me :)
17:04 < sipa> it's just interesting to think about
17:04 < tholenst> i seriously think it would be a good idea to have it implemented
17:04 < sipa> as in it means the the spending transaction, as long as the backing coin that can spend from under it, even confirmed, is not actually spendable
17:05 < sipa> or at least, losing fungibility
17:05 < sipa> (those coins would be worth less than other coins)
17:05 < sipa> as they're less certain
17:05 < tholenst> no, you can move them back to normal coins, it just takes 100 blocks
17:05 < sipa> so
17:06 < sipa> you pay me, by spending coins C1, and sending me a coin C2
17:06 < nsh> so wait, we get complete anarchy with a BBC broadcast-loop that removes all the vulgarity and orgies?
17:06 < sipa> as long as C2 is buried less than 100 blocks deep
17:06 < sipa> C1 persists in some form
17:06 < tholenst> no no, I don't send you coin C2; I send you C1, and if I double spend C1, you get to destroy C2
17:06 < sipa> C1 belongs to you, it's the original coin you had
17:07 < sipa> there's nothing special with it, and it's buried 10000 blocks deep
17:07 < tholenst> I own both C1 and C2
17:07 < sipa> wait, what?
17:07 < sipa> i'm not following
17:08 < tholenst> the idea is: in order to pay you with C1, i need to back up the payment with C2. C2 has a different PKScript, which makes it a "backing coin"
17:08 < sipa> wait, let's talk about transactions instead
17:08 < sipa> you create a transaction which spends C1, and what else?
17:08 < tholenst> ok coin = txout
17:08 < sipa> yeah
17:09 < tholenst> I give you a PubKey2-signature of "If you find 2 PK-1 signed messages you may destroy the txout C2"
17:10 < tholenst> "PK-1 signed" is supposed to mean "signed with the same key as C1 is"
17:17 < andytoshi> ok, and C2 needs to be a special invalid-for-100-blocks output?
17:18 < andytoshi> it'd be neat if you could mark outputs as "cannot be spent with fewer than N confirms"
17:18 < tholenst> yes
17:19 < andytoshi> this is cool, i definitely think it changes coin properties too much to be bolted into bitcoin, but istm that it makes sense
17:20 < sipa> istm?
17:20 < andytoshi> as sipa says, there are cases when a "double spend" is a legitimate thing to occur, so these would need to be special transactions
17:20 < andytoshi> it seems to me
17:21 < tholenst> yeah one has to be careful with it; note though that if you can wait a bit (100 blocks) with the double spend, you can first move C2
17:22 < andytoshi> yeah, the receiver of the funds would estimate how long the tx will take to confirm, and require C2 have that many "cannot spent until" ticks left
17:22 < tholenst> anyhow, I plan to write a detailed proposal... I think it's worth it even if it doesn't go into bitcoin. it would finally be some real selling point for an altcoin, imo
17:23 < andytoshi> that'd be great
17:23 < andytoshi> if you can, explore the consequences re fungibility of locking coins like this
17:23 < tholenst> can you elaborate what you mean by that?
17:24 < andytoshi> well, if some coins can be spent quickly and others can't, the quick-spendable ones are more useful
17:24 < nsh> we need an playpit/sandbox for alt-experimentation
17:24 < andytoshi> so rather than "a coin is a coin is a coin" different coins might have different values
17:24 < andytoshi> otoh if they are locked in place, it's hard to claim they have any value, so maybe it's fine
17:24 < andytoshi> nsh: perhaps BlueMatt's thing will give that to us :}
17:25 < nsh> mm, unfortunately as stands it only changes the (mostly) boring things
17:26 < tholenst> well, you  just need 100 blocks to get the backing coins back into normal coins; that's not even a day wait.
17:26 < andytoshi> sure, but given that's apparently popular, i'm sure if you gave BlueMatt a patch he'd inject it into the alts for a few days
17:26 < tholenst> it seems people are already fascinated by BlueMatt's thing :)
17:26 < nsh> haha
17:26 < nsh> i suppose there's no shortage of volunteer test subjects
17:27 < andytoshi> tholenst: ok, another thing to think about is what happens if there is a reorg, and the block at which the coin becomes normal changes
17:27 < nsh> quick, before we end up with ethics panel!
17:27 < nsh> good point
17:27 < tholenst> yes, ok
17:28 < andytoshi> nsh: people releasing cryptographic software without understanding it, and then goading people into putting money into them, are evil, there's no ethical concern in fucking with them
17:28  * nsh smiles
17:30 < Luke-Jr> andytoshi: evil is evil, even if the victim is guilty of evil things themselves
17:31 < andytoshi> Luke-Jr: fair enough
17:31 < andytoshi> tholenst: so, my specific concern is: suppose a coin becomes valid at block 300000, then i spend it in the next block
17:32 < andytoshi> some reorg happens and now the coin becomes valid at block 300005
17:32 < andytoshi> what happens to my spend?
17:32 < sipa> if the coin creation is reorganized, the spending of it is certainly reorganized too!
17:32 < tholenst> maybe bad things? but for that a 100 block reorg needs to happen, and then bad thing happen anyhow
17:32 < andytoshi> sipa: that's my thought, yeah, but it makes reorgs more complicated
17:33 < sipa> i doubt it
17:33 < Alanius> andytoshi: well, as long as they use the power of argument and not of coercion, I'm not sure "evil" is the right word
17:33 < sipa> let's not go there
17:33 < nsh> +1
17:33 < sipa> andytoshi: if everything is defined within one chain, there should be no problem with reorganizations
17:33 < sipa> but i'm not sufficiently understanding the scheme
17:34 < andytoshi> well, i spend something at block 300000, but suppose suddenly it is invalid until block 300500 (this is an extreme case)
17:34 < andytoshi> so suddenly my payment is invalid, and i have a window in which to double-spend
17:34 < sipa> that cannot happen without invalidating the spend as well
17:34 < sipa> as the spend happens after the creation
17:35 < sipa> ah
17:35 < andytoshi> yeah, so this complicates analysis and i think also has consequences for fungibility of recently-valid coins
17:36 < tholenst> I am not sure i understand your problem. Do you agree this only happens if the reorg is something like 100 blocks deep?
17:36 < andytoshi> but i also suspect this is fixable while still retaining the benefits of tholenst's trickery
17:36 < andytoshi> tholenst: yeah, it'd have to be deeper than the coin's invalid-until-N-blocks count
17:36 < andytoshi> so maybe we could require all transactions which do this to have N higher than 100
17:37 < tholenst> ok, i didn't think too much about that yet.
17:37 < andytoshi> or maybe, rather than saying "invalid until 100 confirms" you say "invalid until block 300000" and hardcode the 300000
17:37 < andytoshi> then you don't care about when the tx is actually mined, so there is no concern about reorgs
17:37 < tholenst> you could do that, but then you have to renew the backing txouts periodically; I don't like that
17:38 < andytoshi> well, you'd have to do this anyway i think
17:39 < tholenst> I think it makes sense at this point if I write down the proposal in more detail.
17:39 < andytoshi> yeah, it'd be good to have something precise to discuss
17:41 < tholenst> the input was useful to me anyhow :) more to think about, ty!
17:41 < nsh> what's the distribution of reorg heights?
17:41 < nsh> any theoretical basis for calculating that, or is it near-enough empirical?
17:42 < nsh> s/heights/depths/
17:43 < tholenst> for a theoretical basis, you need to have some kind of clue how fast the block distributes among the miners
17:43 < andytoshi> nsh: (a) hard to make precise, as generally only part of the network perceives a reorg as a reorg, while the rest of them saw the winning chain first, (b) the big ones occur by implementation bugs, which are hard to predict, (c) the small ones probably are also due to network flukes which are also hard to predict, thought they might have a nice distribution since they're frequent
17:44  * nsh nods
17:44 < nsh> but it should be possible to put a 100-block reorg into an improbability bracket
17:46 < tholenst> agreed, using only mild assumptions that should be possible
18:34 < andytoshi> nsh, tholenst: my expectation is that if you can get any number assuming no horrific forking bitcoind bugs, it'd be like 1/googol or something
18:35 < andytoshi> way way way lower than the chance of a serious dev mistake
18:35 < andytoshi> so that's the probability you need to estimate, and good luck with that :)
18:35 < nsh> pft, i crunch graham's number for breakfast
18:36 < andytoshi> it's higher than 1/graham's number ;)
18:36 < nsh> maybe late lunch then :)
19:46 < andytoshi> BlueMatt: you are "everything that is wrong with cryptos" :)
20:03  * gmaxwell claws his eyes out at "cryptos"
20:06 < gmaxwell> if someone has ethical concerns on BM's tool, BM could just add a warning that says "poor selection of the parameters here can result in a trivially insecure coin, the site makes no promises that the settings are good"
20:06 < gmaxwell> "make heavily demanded features are believed by experts in the Bitcoin world to be terrible for security in subtle or even vulgar ways, sometimes thats why Bitcoin doesn't do them. Buyer Beware."
20:06 < andytoshi> the ethical concern from earlier is that i suggested 'secretly' adding wizarding experiments
20:07 < gmaxwell> oh well I don't think there is anything secret needed. You can just add them and make people _pay_ for them.
20:07 < sipa> indeed, just make them extra features
20:08 < gmaxwell> or make turning them off an extra (pay for) feature if you like.
20:09 < Luke-Jr> maybe BlueMatt would donate the site to -wizards ;)
20:10 < Luke-Jr> it'd be neat to make it list all mergable pull requests as options..
20:11 < Luke-Jr> perhaps unmergable ones too, and give a warning about "There is an additional charge for this feature which cannot be calculated automatically. You will receive a quote within 3 business days if you choose it."
20:11 < Luke-Jr> :D
20:11 < Luke-Jr> and then let anyone competent bid on it
20:11 < sipa> it probably needs some deterministic seed
20:11 < sipa> so that new versions of existing coins created with it can be generated
20:12 < sipa> if the upstream source is updated
20:12 < sipa> (which determines magic bytes etc)
20:13 < Luke-Jr> sipa: that would break the merging features a bit
20:14 < Luke-Jr> "I have a magic node which keeps track of peers for each coin and forwards them on in addr messages, but if no one else is running a node, youre sol."
20:14 < Luke-Jr> wow, that probably took some effort
20:15 < gmaxwell> nah, if you get an inbound connection you're silent, the connector sends the network version
20:15 < gmaxwell> so then its just like one of those 100 line python "node" implenmentations with a dict of addresses per network.
20:16 < Luke-Jr> <.<
20:24 < Luke-Jr> wow, BlueMatt's thing has made over $500 already :P
20:25 < warren> it has no disclaimer of warranty
20:27 < Luke-Jr> I suppose sipa's auto-upgrader could bill you
20:28 < sipa> why what?
20:28 < sipa> my what?
20:32 < Luke-Jr> sipa: the idea to let people come back for upgraded builds of the same coin
20:32 < Luke-Jr> sipa: my objection was that it would break merges - but it could work if you get billed for any conflicts ;)
20:33 < warren> Luke-Jr: why do you care about the maintainability of scam coins?
20:33 < sipa> well, my concern about them is pretty much irrelevant, as i have no interest in using the tool
20:33 < sipa> but if the users were serious to any extent about the coins they are creating, they should demand it
20:33 < Luke-Jr> warren: I'm just thinking financing development and testing this way, ignoring how the end products are used ;)
20:34 < warren> Luke-Jr: I think this current tool renames everything to make merges impossible
20:40 < Luke-Jr> warren: maybe.
20:40 < Luke-Jr> warren: I was thinking more of merging before s&r
20:40 < Luke-Jr> ie, rebuild the scamcoin from scratch
20:41 < warren> Luke-Jr: you would have done well as a litecoin dev =)
20:42 < Luke-Jr> well, arguably litecoin *is* using my code.. :P
22:14 < Luke-Jr> too bad Script is neutered
22:14 < Luke-Jr> could make a transaction-fee-for-only-future-blocks..
22:14 < Luke-Jr> sPK: "<txver><inputcount><txinput>" OP_SWAP OP_CAT OP_HASH256 OP_DEPTH 1 OP_SUBTRACT OP_FOR OP_CAT OP_HASH256 OP_ENDFOR OP_SWAP OP_CAT OP_CAT OP_HASH256 <block target> OP_LE
22:14 < Luke-Jr> sS: "<blkver><prevblk>" "<ntime><bits><nonce>" "<end of txn data>"
22:15 < Luke-Jr> petertodd: ^
22:16 < gmaxwell> looping in scrypt is yuck though. e.g. while(true)OP_HASH256.
22:17 < gmaxwell> if you just want to burn coins OP_RETURN them, poof gone and trivially provable they were burned.
22:25 < Luke-Jr> but then they're "too" burned :P
22:26 < Luke-Jr> OP_FOR isn't the same as OP_WHILE :p
22:26 < Luke-Jr> OP_FOR would inherently be non-forever
22:38 < andytoshi> in an alt where fees were tied to runtime, you could do cool things like this
22:38 < andytoshi> it seems to me that even "non-forever" is not sufficient to prevent DoS attacks
22:39 < andytoshi> if you can loop for tens of thousands of iterations, that can cause bad problems .. if you can nest loops, etc
22:39 < andytoshi> otoh, if you -can't- do those things then that sucks
22:43 < gmaxwell> Luke-Jr: yea, 4 billion SHA256 ... big improvement over forever.
22:44 < Luke-Jr> [03:38:09] <andytoshi> in an alt where fees were tied to runtime, you could do cool things like this <-- there is no reason this would be an alt
22:44 < gmaxwell> tying things to runtime is really really likely to cause hardforking bugs.
22:44 < Luke-Jr> gmaxwell: only if they are hard rules
22:44 < gmaxwell> since you need a precise instruction counter.
22:44 < gmaxwell> Luke-Jr: they must, because non-miners must evaluate script too
22:45 < gmaxwell> otherwise you have mining pools incentivized to put in fast hardware script execution engines and no one else can keep up validating the coin
22:45 < Luke-Jr> gmaxwell: I'm okay with letting miners decide on the upper runtime limits, within reason.
22:47 < gmaxwell> within reason is the problem there == hardforks. :P
22:48 < Luke-Jr> nah, within reason is vague enough to use opcode counters
22:48 < andytoshi> gmaxwell: sorry, i meant 'instruction count' which could be defined very precisely in a forth-like script
22:50 < gmaxwell> andytoshi: yes, it can be. What OP_CHECKMULTISIG does is also very precisely defined and that didn't stop several alt implementers from getting it wrong.
22:50 < andytoshi> ah, this is true
22:51 < gmaxwell> this may ultimately be an argument for replacing script with verficiation for some proof of execution, since it may actually be easier to get it right.
22:52 < gmaxwell> or at least alt implementors are less likely to try to reinvent crypto constructs.
22:53 < gmaxwell> it's nuts. SCRIPT is actually a public key signature system itself. People writing their own ECDSA code as a my-first-project would be super frowned on, and yet they re-write script. though somewhat annoying in that at least there are libraries for ecdsa.
22:55 < andytoshi> i think i will start pushing the meme on #bitcoin that cryptography is serious business and that only morons try to roll their own or work with it without understanding it
22:55 < andytoshi> ...which appeared to be common knowledge until altcoins became a thing
22:55 < gmaxwell> Okay, I think I'm going to give up on bitcoin, jesus christ: http://blockchain-link.com/#future
22:57 < andytoshi> gmaxwell: agreed on "this is an argument for snarks", aside from the usual novel crypto warnings it seems to me they'd be way easier from a blockchain engineering perspective
22:57 < andytoshi> and i'd be really jacked to see a turing complete script (and maybe one which could do things like read the past blockchain)
22:58 < andytoshi> gmaxwell: where did you get that URL?
22:59 < gmaxwell> #bitcoin
22:59 < gmaxwell> oh thank god those are fethercoin amounts
22:59 < gmaxwell> I was thinking this person had recieved over 600 btc in donations
22:59 < andytoshi> ahhh wtf
22:59 < gmaxwell> I think if that was true I would probably just never do anything with bitcoin again. I'm getting seriously depressed about all the money flowing into fucking things up.
23:00 < gmaxwell> I am not a very coin operated guy myself, but the funds flowing specifically to _bad_ things is especially demotivating.
23:01 < andytoshi> gmaxwell: as personal advice i'd say you do way too much to correct misinformation and engage with these idiots ... but otoh it does a massive amount of good for the bitcoin communitiy, so i dunno what to say
23:02 < gmaxwell> well I certantly know that I have the option of ignoring everything I don't like.
23:02 < gmaxwell> And I actually consciously ignore enormous swaths of stuff (though I know it doesn't seem like it)
23:03 < andytoshi> maybe i will write a "why alts are retarded" FAQ which discusses cryptography and the horrors of using it blindly or stupidly ... and reminding people that crypcocurrencies are a novel cryptographic concept and these lessons apply -even more so- because of that, and then -even more so- because there is monetary value involved
23:04 < andytoshi> because it appears that people think this shit is magic, people talk as though "cryptos" are a thing , a collection of magical systems that are all on equal footing
23:05 < gmaxwell> you can probably pull up some of the old sci.crypt faqs
23:05 < gmaxwell> things like "anyone can make a cryptosystem that they themselves can't break"
23:06 < gmaxwell> it all applies to the _entire_ altcoin. The whole thing— minus some frills around the edges, but everything that actually makes it an alt— is a cryptosystem
23:06 < gmaxwell> e.g. the decision to go with 10 minutes vs 5 minute block times is a cryptographic decision, and one that isn't very completely understood!
23:06 < gmaxwell> (though more understood than some other things)
23:07 < andytoshi> good call on sci.crypt -- i was a young child when it crossed into mostly-insanity so i forgot all about it :P
23:07 < andytoshi> i'll hack something up this week and post it here, maybe just github the latex and give you all push access
23:07 < gmaxwell> it was pretty much always insanity, but the boundary of sane and not is what produced some of the arguments you need.
23:07 < andytoshi> or rather, git.wpsoftware.net it ... i don't think github likes direct pushing
23:08 < gmaxwell> I think making a concrete argument the whole of the interior rules are a cryptosystem is important. It's a bit sad that OP_CAT is off and that we don't havea OP_PUSH_TXN_HASH as you could implement lamport signatures in script with that.
23:09 < gmaxwell> bluematt's think will help, in a couple of months you'll be able to claim that many alts are created by people who can't use a compiler.
23:09 < gmaxwell> so there will be no illusion that there is some latent stock of cryptographic genuises putting out these things.
23:09 < andytoshi> yeah, that's excellent
23:11 < andytoshi> i might even describe this as a "social experiment which Matt Corallo proposed to the bitcoin developers to illustrate this point"
23:11 < andytoshi> because people on the btct thread seem to think he is some random guy..
23:12 < andytoshi> though i really don't want to give the impression that the bitcoin developers are holy people directing the currency somehow
23:12 < andytoshi> because that kind of thinking causes alts with convergence issues
23:12 < Luke-Jr> Matt Corallo is a bitcoin developer O.o
23:12 < gmaxwell> well, also, while not a secret emphasizing that the tool is intentionally cynical may lower matts income from it.
23:13 < andytoshi> Luke-Jr: i know, i guess i phrased that badly
23:13 < gmaxwell> andytoshi: and fwiw, I do think I was the first person to suggest it. :P (though perhaps matt had been thinking about it independantly)
23:13 < andytoshi> oh, sorry :}
23:13 < gmaxwell> (I spent a while in #bitcoin-mining trying to convince Luke-Jr and/or petertodd to do it. (luke has the nice ability to tie in merged mining))
23:13 < gmaxwell> like ... N months ago.
23:14 < andytoshi> my intention in saying that was exactly to claim it is cynical .. but you are right that i'd be just taking money from Matt
23:15 < gmaxwell> well I think its cyncism is not secret, but emphasizing it now might reduce his income from it, and given the two choices I'd rather have the latter.
23:16 < gmaxwell> the cynical aspect of it is super obvious (it even was one of the first comments in the altcoin thread about it)
23:16 < andytoshi> okay, that's good then .. one of my concerns was that having Matt involved publically might make alts seem legitimate
23:19 < grau> I assume you talk about coingen.io: I think it greatly damages alts, showing how pointless they are, unless there is a network of people supporting one.
23:22 < gmaxwell> grau: thats the idea.
23:22 < gmaxwell> Were you in the #bitcoin-mining discussion where it was proposed eons ago? for some reason I had the impresion you were. :P
23:23 < grau> I never joined #bitcoin-mining
23:23 < gmaxwell> hm! okay!
23:23 < gmaxwell> well as I just said: super obvious.
23:23 < gmaxwell> :P
23:23 < gmaxwell> Part of it is a network effect thing, dillution hurts smaller coins more than bigger ones.
23:24 < grau> but is it good in your opinion, or should we rather embrace alts?
23:24 < gmaxwell> I think it's good to dillute "worthless" alts.  I don't think coingen.io does anything harmful at all to ones that have a solid reason for existing (which currently is .. not very many)
23:26 < gmaxwell> it highlights the worthlessness of things that are clearly worthless, and somewhat undermines the efforts of people who use the internet version of boilerroom techniques to promote worthless things trying to get a quick buck.
23:26 < justanotheruser> I think altcoins are an interesting phenomenon. Normally people wouldn't flock to a new version of software with a new logo and a few variables changed. For example, if I made altfirefox where the scroll bar was half the size and the logo was a dog, it wouldn't get any downloads let alone a thread with hundreds of replies.
23:26 < gmaxwell> though I still have no real answer to altcoins which have good _sounding_ reasons to exist but which are without substance when you pull back the technical covers.
23:27 < gmaxwell> justanotheruser: yea, you're not promoting the altfirefox with an investment ... scheme.
23:27 < warren> protoshares!
23:27 < justanotheruser> exactly, people buy into a purposeless piece of software because they think they will make money off it
23:28 < gmaxwell> right and coingen.io probably dashes those hopes for "YAAC" (yet another altcoin) though not for something with an elaborate vaporware story.
23:28 < gmaxwell> obviously then next thing to do is a coingen2.io that makes whitepapers for non-existing altcoins using a hidden-markov-model
23:29 < grau> those get rich schemes depend on being able to convert to BTC (since direct to fiat is absent) and this keeps me wondering why someone is selling BTC for some alt.
23:29 < andytoshi> gmaxwell: my hope is that i can write a faq which talks about smart-sounding alts
23:29 < justanotheruser> andytoshi: You should. There are only a handful you would have to cover
23:29 < grau> assuming there is no get rich, then motivation might really be the need for cheap tokens
23:29 < andytoshi> e.g. litecrypt and it's goofy scrypt implementation, feathercoin and its super fast alts
23:30 < andytoshi> blocks*
23:30 < grau> there could be applications for near worthless tokesns e.g. for games.
23:30 < justanotheruser> grau: if you want a cheap token, you should buy uBTC
23:30 < andytoshi> realsolid's difficulty algo
23:30 < gmaxwell> grau: my guesses include things like (1) people with large amounts of illicitly gained btc which can't easily be spent other ways, (2) exchanges buying them with fake BTC to pump prices for their own profits, (3) ... just people trying to repeat bitcoins rise in value a second time
23:30 < justanotheruser> I suppose you are talking about small transaction fees though
23:31 < gmaxwell> grau: sure, but we've got plenty of altcoins already, we don't need public exchanges for cheap tokens either.
23:31 < andytoshi> for that matter, solidcoin's seemingly solid reputation, and the character who turned out to be behind it
23:32 < justanotheruser> Is there going to be a point where most of the transactions are off-chain? I mean if we keep the block size at 1mb, people will eventually be competing with higher transaction fees to get their transaction into a block.
23:34 < andytoshi> my feeling is that some sort of {snark+agressive pruning}coin will be released before bitcoin is seriously strained by the tx load
23:34 < petertodd> justanotheruser: nah, hopefully we'll just uncap the blocksize and gmaxwell and I will get the smug satisfaction of being proven right
23:34 < petertodd> andytoshi: snark's don't help with scalability the way I think you think they do
23:35 < justanotheruser> petertodd: how do we deal with the massive blockchain and bandwidth?
23:35 < andytoshi> petertodd: i'm not suggesting they can be used for pruning, but for quicker transaction validation
23:35 < grau> gmaxwell: (4) maybe a also scheme of anonymizing with recourse to BTC
23:35 < andytoshi> (and i'm aware that in 2014 even that is not true)
23:35 < gmaxwell> andytoshi: they're not quicker than trivial txn today. even the fastest stuff is .. well see that tinyram paper you linked to.
23:36 < petertodd> justanotheruser: by sharding the blockchain so that no individual node has to deal with all of it, but that's very tricky
23:36 < gmaxwell> But to the extent that they allow binding offchain systems they do improve scaling.
23:36 < andytoshi> could petertodd's MMR stuff be implemented in an alt today and enable massive block pruning?
23:37 < petertodd> andytoshi: yes, but not in the way you think so :P
23:37 < justanotheruser> petertodd: Is that in development at all? Is there anywhere I can read about that?
23:37 < andytoshi> petertodd: ok, this time you're right that i believe unjustified things :)
23:37 < petertodd> andytoshi: MMR TXO commitments actually make scalability a lot worse
23:37 < andytoshi> really?
23:38 < petertodd> andytoshi: yes, the bandwidth required to prove txin existence is about an order of magnitude more than what it is now
23:38 < gmaxwell> they make the blocks really big, but they allow a bandwidth/storage tradeoff if you can optionally send them when a node already has the data.
23:38 < BlueMatt> andytoshi: yea, I love that comment
23:38 < andytoshi> i thought with TXO commitments we could get away with only storing the last $small_time of actual blocks
23:38 < gmaxwell> bandwidth does tend to be more scarce than storage. though the ratio is kinda hard to reason about
23:38 < petertodd> andytoshi: where they can make things better is in conjunction with sharding techniques that allow that much worse bandwidth to be spread out over multiple nodes
23:38 < BlueMatt> Luke-Jr: I'm not a "bitcoin developer"?
23:39 < Luke-Jr> BlueMatt: you're not?
23:39 < BlueMatt> not a core dev sure, but I think everyone here is...
23:39 < gmaxwell> andytoshi: you can but you made the blocks much bigger because they're carring around kilobyte proofs per txin instead of 32 byte hashes.
23:39 < andytoshi> gmaxwell: ah, i see, that's what i was missing
23:39 < petertodd> BlueMatt: heh, people are starting to call even me a core dev, which you have a much better claim to :)
23:39 < gmaxwell> of course if you have the txo set you don't need the proof, so it could be made optional.
23:39 < andytoshi> i thought this MMR business was basically a smart version of "add a hash of chainstate/ to the blocks"
23:40 < gmaxwell> andytoshi: sure but when a tx spends coins committed in that state the tx has to include a proof that its inputs are in it.
23:40 < andytoshi> and you'd request a copy of the chainstate dir instead of IBD'ing
23:40 < andytoshi> gmaxwell: oh, okay, so my understanding was not wildly far off
23:40 < gmaxwell> andytoshi: oh no, that just SPV security for full nodes you're talking about. sort of orthorgonal
23:40 < petertodd> andytoshi: that's completely right, but bandwidth, esp. anonymous bandwidth is the importatn thing
23:41 < petertodd> andytoshi: also the real importance of chainstate is being able to product compact proofs that rules were violated
23:42 < gmaxwell> andytoshi: if the chainstate is commited then you could have a full validating node without even storing the chainstate, but at the cost of txns having to carry chainstate proofs. (just hashtree fragments)
23:42 < andytoshi> ok, i see, did not realize that bandwidth would be hit so hard -- i was looking at "download 20gb of old transactions and validate them" as being much more overwhelming
23:43 < gmaxwell> and its orthorgonal to if you hot-started or not. If you hotstart without something like a snark proving chainstate faithfulness you reduce full nodes to SPV security— e.g. miners could potentially inflate the coin.
23:43 < andytoshi> well, you might keep the last few weeks of actual blocks so that miners would need to outcompute the network for a long time to do that
23:43 < gmaxwell> and using a snark to prove a full chainstate fidelity isn't technically feasable yet, I think. though perhaps we're close if you skip the script evaluation.
23:45 < gmaxwell> andytoshi: but keep in mind in doing that you change the incentives completely. so the analysis isn't simple. E.g. if non-miner full nodes didn't check the generated amount, would miners just all set their generated coins to 100 and leave them there?
23:45 < grau> checkpoints skip script evaluation
23:45 < gmaxwell> grau: we're going to remove that in bitcoin-qt almost certantly after headers first, and even there there is a commandline switch to reenable.
23:46 < gmaxwell> and miners don't set checkpoints.
23:46 < andytoshi> gmaxwell: presumably at all times non-miner full nodes have the past ten days or so of blocks (and they'd be dropping them), so there'd never be a window when people weren't validating the latest blocks
23:46 < gmaxwell> Basically the point there is that if miners can get themselves a blank cheque its a very different set of incentives than we currently have.
23:48 < grau> I think it will be miner keeping check on each other not user
23:48 < gmaxwell> andytoshi: sure, you just have eluria and ghash.io and slush (>>50% of the network) agree to do a 10 day reorg that harms nothing but gives them 10x the coins. Why not? it's tricky. And then why would people keep 10 days?  0 days is enough until the attack actually happens. Let someone _else_ take the cost of preventing the attack.
23:48 < gmaxwell> BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 260 seconds]
23:48 < grau> user will move to SPV, even merchants may
23:48 < gmaxwell> oops missate there.
23:48 < andytoshi> grau: then there's an incentive to conspire/collaborate and this leads to pool centralization
23:49 < andytoshi> ah, now i see the incentive problem with what i suggested
23:49 < gmaxwell> grau: there are only two or three people in the world required to achieve >50% control of hashrate.
23:49 < gmaxwell> (and one of them (the cex.io guy) has physical control of most of his hashrate directly)
23:50 < andytoshi> ugh, this is so frustrating, i had this massive blind spot in my analysis of pruning schemes
23:50 < andytoshi> if only i could convey that feeling to the alt-chasers..
23:50 < gmaxwell> grau: trusting miners is a pretty terrible idea, far worse than trusting the fed— at least the fed has a sea of regulations and public identity regulating its behavior.  Miners are anonymousish, fully self selecting, unregulated, etc.
23:50 < grau> gmaxwell: assuming 2-3 would and use it to inflate coins. This could be surfaced by anyone and would destroy trust in the currency and that possibility would keep them from doing that.
23:51 < gmaxwell> and if you regulate them, the you just undermine the system in a differnet way.
23:51 < gmaxwell> Instead they can be regulated _naturally_ by the system how it was designed: but not trusting them any more than the absolute minimum needed.
23:51 < gmaxwell> (by having full nodes that impose the rules)
23:51 < Luke-Jr> BlueMatt: anyhow, maybe you misread what I said. I said you *are* a bitcoin dev..
23:51 < BlueMatt> ahh, ok
23:53 < grau> collaborating between miner to change rules is the same dilemma as in "selfish mining", whort term incentives against long
23:54 < grau> *short
23:54 < petertodd> grau: relying on incentives of a small number of quite-possibly non-rational people is crazy
23:54 < grau> if you have an other choice
23:55  * gmaxwell out
23:55 < petertodd> grau: well we do: design crypto-currencies where pools aren't possible, and be ready to deploy them if it becomes an issue (as an example)
23:56 < Luke-Jr> petertodd: if pools aren't possible, then you get worse alternatives (hosted mining)
23:56 < grau> design a migration policy of welth also if you are that
23:56 < petertodd> grau: that's the easy part actually
23:56 < gmaxwell> Luke-Jr: hosted mining is made insecure by the same things that break pools (though perhaps no one cares, which was the argument I gave before: easier to break pools than hosted mining)
23:57 < petertodd> Luke-Jr: basic physics fortunately encourages decentralization of hashing power
23:57 < gmaxwell> oh yea I'm not here
23:57 < Luke-Jr> that's why it's better to make decentralised pooling as cheap as possible, cheaper than hosted mining
23:57 < grau> petertodd: why that? bigger plants should have better ratios of energy/hash
23:58 < Luke-Jr> ^ + bulk orders of hardware get better prices
23:59 < petertodd> grau: nope, the basic unit of production is the chip + power supply, and for that your economy of scale is making them. otoh your costs to run the hardware has a huge component of getting rid of waste heat, which incentivizes decentralization
23:59 < petertodd> grau: e.g. "a bitcoin miner in every water heater"
--- Log closed Sun Jan 05 00:00:55 2014