--- Log opened Mon Jan 06 00:00:29 2014
--- Day changed Mon Jan 06 2014
00:26 < brisque> coingen.io has forged 67 new altcoins. I'm impressed.
00:32 < BlueMatt> brisque: those are just the non-hidden ones, too
00:32 < kyrio> oh yeah
00:32 < kyrio> there's an option to pay to keep it private
00:33 < jcorgan> BlueMatt: of all the ways to earn BTC with a website, coingen.io is the most subversive :)
00:33 < brisque> BlueMatt: I'm extremely impressed. you've done a good job with it.
00:33 < BlueMatt> heh, anyway...its ot for here
00:47 < brisque> almost on topic, can anybody come up with a reasonable explanation for the behaviour of blockchain.info in regards to it's "peers connected" number? they seem to manage to get up to around 1500 connections before dropping them all and starting again.
00:47 < brisque> graph - http://i.imgur.com/iiJYOjo.png
00:48 < brisque> time timeframe is around 30 minutes before each big drop, so they're churning through a lot of connections.
01:19 < phantomcircuit> brisque, they dont understand what the limits of select() are so their client keeps crashing when they go past those limits
01:19 < phantomcircuit> which i personally find hilarious
01:25 < brisque> surely they'd notice the bi-hourly crashes and return the connection limit to something sane. surely.
01:25 < brisque> 72,000 reconnections a day.
01:26 < phantomcircuit> brisque, surely they have no idea what they're doing and haven't noticed
01:27 < phantomcircuit> hint, it's my thing
01:36 < brisque> phantomcircuit: really not sure what the hint means
01:36 < phantomcircuit> <phantomcircuit> brisque, surely they have no idea what they're doing and haven't noticed
01:37 < brisque> ah.
04:22 < gmaxwell> petertodd: P2SH^2 2.0:  Take H(script) as a private key in a pairing crypto group. Compute G1*private = pubkey.   scriptpubkey contains H(pubkey),sign(H(H(pubkey)||txid))
04:23 < gmaxwell> er sorry pubkey,sign(H(H(pubkey)||txid))  (because you can't to the pubkey recovery for a pairing short signature)
04:23 < gmaxwell> petertodd: so tada, data storage in txouts completely prevented. Overhead of one group element (e.g. 32 bytes)
04:24 < gmaxwell> Why not ECDSA?  because signers choice of K can be used to store data in the blockchain... e.g. pick a well known K, and recievers use it to recover the 'private key' (the data)
04:26 < brisque> I'm interested in what The Pirate Bay is planning to do with Bitcoin. by the sounds of their post it is almost like they intend to be storing identifiers in the blockchain, just as you're trying to prevent.
04:27 < maaku> what would be the point?
04:27 < gmaxwell> because omg bitcoin such VC money WOW
04:27 < gmaxwell> people mistake bitcoin for a jamming free network, constantly. ugh.
04:28 < brisque> have you read the article, gmaxwell?
04:28 < brisque> http://torrentfreak.com/how-the-pirate-bay-plans-to-beat-censorship-for-good-140105/
04:28 < brisque> “The “domain” registrations will be Bitcoin authenticated, on a first come first served basis. After a year the name will expire unless it’s re-verified.”
04:29 < brisque> “Site owners will be able to register their own names, which will serve as an alias for the curve25519 pub-key that will identify the site,” the Pirate Bay insider notes.
04:36 < Emcy> gmaxwell youve been saying jamming network a lot recently. Brief explanation?
05:20 < brisque> just as a thought, the entire sticking point of having a SPV p2pool is that we can't prove to a SPV client that the inputs are unspent, right? we can prove that they exist at some point, but not that the block the p2pool node creates with it will be valid to the wider network (the inputs were spent elsewhere).
05:34 < maaku> Emcy: jamming-free
05:34 < maaku> meaning it is a reliable mechanism for transmitting messages that can't be forceably censored
05:34 < maaku> (which bitcoin is not)
05:37 < gmaxwell> you can have different kinds of jamming freeness, like all or nothing channels.. If you're a >50% hashpower miner bitcoin is arguably an all or nothing jamming resistant network, but it's not to anyone else. :P
05:53 < adam3us> about XCP PhantomPhreak (one of the authors) seems to have changed from spend to fees to proof of sacrifice which they are calling proof of burn but seems to be the same thing, in reaction to someone pointing out that a miner could take their own fees (and maybe worse by the sound of it)
06:08 < nsh> yeah, seems to be a very improvised affair
06:18 < gmaxwell> adam3us: do you have a EC discrete log formulatio nof my above P2SH^2 2.0?
06:18 < gmaxwell> the idea is basically to have a hash function where you can prove that the value in question is a hash and not data stuffed into the same spot.
06:21 < adam3us> gmaxwell: i read it earlier, its a subliminal channel suppression, seems a bit analogous to the wallet with observer protocol that relies on blind schnorr.  but i dont think that helps because there is no semi-trusted hw wallet in this picture.
06:22 < adam3us> gmaxwell: one thing that occurred to me is the one-use signature or limited use sig, where the extended address is H(Q,r) so r is precommitted.  then you are only allowed to make signatures with r.  maybe you could prove something about r?
06:22 < gmaxwell> I thought perhaps one of those protocols for schnorr where there is one allowable nonce per private key?
06:22 < gmaxwell> ha
06:22 < gmaxwell> But I didn't quite know how those work.
06:23 < gmaxwell> ah there is an extended address. hm.
06:23 < adam3us> gmaxwell: yes same thought... thats it above, its just to say that you choose the nonce(s) at time of address generation
06:23 < gmaxwell> oh darn.
06:23 < gmaxwell> yea, I think that wouldn't work for the namecoin application.
06:26 < adam3us> gmaxwell: i dont get the namecoin connection.  (subliminal channel free signatures would be independently nice however to stop stuffing junk in the block chain:)  btw if its purely hash based there is a small subliminal channel in grinding the hash if there is any mutability of the serialization or value hashed.
06:27 < gmaxwell> sure, but the grinding subliminal channel isn't huge and you can reduce it further by requring grinding normally. :)
06:27 < gmaxwell> adam3us: it's just the stop stuffing junk application, I'd fleshed that out a little more in particular to namecoin, https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less
06:28 < adam3us> gmaxwell: yes.  curious thought that the wallet with observer can have 0 subliminal channel due to the blinding and yet still end up with a valid normal (ec)schnorr sig.  actually i saw Brands argue that it has 1-bit channel left: fail or not fail :)  (simulated hw wallet death)
06:30 < gmaxwell> hahaha
07:02  * nsh exercises blinking muscles
09:30 < andytoshi> gmaxwell: sorry, i'm not following your scheme: how is privkey == H(script) enforced here (or even exists(privkey) enforced)? what is txid and why doesn't it depend on its own hash?
09:35 < andytoshi> my concern is, pubkey,sign(H(H(pubkey)||txid)) gives you all of 'pubkey' as a subliminal channel
12:24 < petertodd> Just signed up for the Financial Cryptography and Data Security 2014 conference.
12:24 < petertodd> Who else is going?
12:26 < justanotheruser> I wish I could take a vacation to Barbados
12:27 < petertodd> justanotheruser: heh
12:28 < petertodd> justanotheruser: kinda eye-opening the overall cost - I'm gonna have to bring a tent :P
12:29 < justanotheruser> petertodd: Is Financial Cryptography conference a fancy way of saying bitcoin conference?
12:29 < petertodd> justanotheruser: yup, btc workshop on one of the days
12:30 < petertodd> justanotheruser: http://fc14.ifca.ai/bitcoin/index.html
12:30 < petertodd> justanotheruser: or more interestingly: http://fc14.ifca.ai/bitcoin/accepted.html
12:31 < justanotheruser> petertodd: what, interesting that RS are there?
12:31 < justanotheruser> Or just S
12:32 < petertodd> justanotheruser: ?
12:32 < justanotheruser> nevermind
12:32 < justanotheruser> Interesting that I don't see any familiar names on that list
12:33 < justanotheruser> Seems like a bunch of PhDs are going to explain bitcoin to the bitcoin devs
12:35 < petertodd> Ha, yeah pretty much from the looks of it, will make for an interesting workshop...
12:35 < petertodd> I think amiller said he was going, so maybe it won't be all people totally removed from the dev community.
12:35 < petertodd> (not that him and I write much code...)
13:11 < Emcy> petertodd sleep on the beach
13:16 < Emcy> did anyone figure out how TPB is planning to use bitcoin for its little thing
13:16 < Emcy> or have you been talking about it and its way over my head
13:17 < Emcy> thye best not be spamming the chain......why dont they use namecoin instead
13:31 < maaku> Emcy: have they stated any details?
13:31 < maaku> all they've done is name-drop bitcoin, as far as I can tell
13:32 < maaku> their plan is, apparantly, "BITCOIN!!"
13:33 < Emcy> sounds about right
13:35 < skinnkavaj> gmaxwell: https://litecointalk.org/index.php?topic=12404
13:36 < maaku> skinnkavaj: sure, google "geistgeld"
13:36 < Emcy> maaku isnt there a data feild in a TX that cam be used for arbitrary data without really bloatingit
13:37 < Emcy> or somthing like that
13:37 < maaku> Emcy: sure, any OP_RETURN output
13:37 < Emcy> and that was specifically done to give people a place to dump thier crap, if they must?
13:38 < maaku> yes
13:39 < Emcy> wait is that a new feild or something repurposed? If its new isnt that just appeasement
13:39 < maaku> and by putting the hash instead of the data itself (or better, the Merkle root of a structure that can hold lots of data), you can keep the wire size small
13:39 < maaku> i think most people here are ok with committing data by hash to the chain
13:39 < maaku> it's an integral part of many of the protocols we design
13:40 < maaku> its just that putting raw data straight on the chain is wastful, inefficient, and (if it's not provably unspendable) freeloads off of full nodes
13:41 < maaku> it's part of the scripting language not a specific field, and it's always been there
13:42 < maaku> it's just being made standard so it can be relayed in 0.9
13:42 < Emcy> so TX will get slightly bigger, albeit by something that was already in the protocol but disabled until now?
13:43 < maaku> not disabled, you could always use it
13:43 < maaku> just not relayed by default just like other non-standard scripts
13:44 < michagogo|cloud> maaku: It freeloads off of full nodes even when it's provablt unspendable
13:44 < michagogo|cloud> It's still in the blockchain
13:44 < maaku> michagogo|cloud: no, full node != archival node
13:44 < maaku> it's not in the utxo set
13:44 < michagogo|cloud> It just isn't in the utx-
13:44 < michagogo|cloud> oh
13:45 < michagogo|cloud> Erm, do non-archival full nodes exist atm?
13:45 < Emcy> that archival node thing isnt really gonna happen is it? 6tb helium disks soon
13:45 < michagogo|cloud> Emcy: It;s safe to assume that at some point in the future there will be non-archival full nodes
13:51 < Emcy> michagogo|cloud i hope not out of stict neccesity, but to try and poke people into running a node at all
13:53 < Emcy> hmm asking on TPB irc and no one seems to know shit......
16:19 < maaku> at some point in the near future
16:20 < maaku> i know both petertodd and myself have separately gotten some money to work on a pruned bitcoind
16:21 < maaku> we just have to good sense to make sure that some other fixes make it in first
16:21 < maaku> like headers-first syncing, and being able to advertise which blocks you hold
16:38 < gmaxwell> the later I think is most of the actual work in pruned bitcoind.
16:39 < gmaxwell> I mean, right now you can just delete the old block files and it works until you run a rpc that would access an old block or a peer tries to sync from you.. it's probably just a few lines of code to make those failures tidy.
16:39 < gmaxwell> and a few lines of code to just automatically delete old files.
16:49 < Emcy> id say it was probably a tradeoff worth making if the alternative is full verifiers dwindling to the hundreds because no one wants to run one
16:49 < Emcy> then again im not sure it will help, because even a pruned node is the same mental distance away from "just works instantly" as a proper node
16:50 < gmaxwell> Emcy: it's just a good thing to have even without that concern.
16:50 < gmaxwell> I now only run one full node at home and one on my laptop, because I just don't have the space for N copies of the blockchain.
16:50 < Emcy> SSDs?
17:31 < Guest22406> Anyone bought from iMine.org.uk?
17:32 < Guest22406> http://iminecryptos.webs.com seems to be their temp. page
19:19 < michagogo|cloud> Hmm, another benefit of pruning is that it means that a full node can be bootstrapped from another trusted full node very easily
19:22 < gmaxwell> michagogo|cloud: I don't see why you think thats a benefit of pruning.
19:26 < sipa> the only advantage is less data that needs to be copied in that case
19:26 < sipa> but making it easy to run in a way that requires absolute trust in another node is not really a priorit
19:37 < michagogo|cloud> gmaxwell: because you don't need to copy 12+ GB
20:13 < Luke-Jr> combined with SCIP it could be trustless perhaps :p
20:13 < gmaxwell> Luke-Jr: yea sure, but we're currently a long way from authoring proofs of state for bitcoin.
20:15 < gmaxwell> e.g. see the benchmarks in 13:59 < andytoshi> a new snark paper from ben-sasson: http://eprint.iacr.org/2013/879
20:16 < adam3us> gmaxwell: just have to use it recursively as the pow :)  (self-evident) proof of making snark proof as the pow
20:17 < andytoshi> adam3us: i was about to say that .. you'd have to tie the reward to the number of transactions considered, otherwise including transactions is costly
20:17 < gmaxwell> less crazy than it might seem.
20:17 < andytoshi> but can you do that in zero knowledge? i'd have to think about it
20:17 < gmaxwell> andytoshi: nah, just pretextually.
20:18 < gmaxwell> andytoshi: e.g. make your POW   SHA256(SNARK_PROVE(SHA256(header)))<target  ... (ignoring the fact that the pairing snarks are like.. perfectly malleable).
20:19 < andytoshi> just MAC them ;)
20:19 < gmaxwell> and of course you use a nice universal circuit inside the snark_prove in order to hopefully cutoff sha-256 specific optimizations.
20:20 < andytoshi> gmaxwell: so the idea is, changing the nonce is just as hard as adding transactions?
20:22 < gmaxwell> andytoshi: well thats true but its not the idea, the point there is that it creates an incentive for people to optimize the SNARK_PROVE() function. :P
20:24 < andytoshi> gmaxwell: well, if transactions are hard to add that kills the idea immediately because there'd be only empty blocks
20:25 < andytoshi> as it is, an alt could be written today which does this
20:25 < andytoshi> (and nobody would be able to mine it :P)
20:26 < gmaxwell> Luke-Jr: in the vnTinyram paper (I think their vnTinyram is slighly slower than regular tinyram), they're showing that their prover basically runs at 25 Hz ... can you imagine verifying the blockchain on a 25Hz cpu? :P  ... a dedicated blockchain checking circuit could be maybe 1000x faster, but it would still be verfy slow to generate the proofs.
20:26 < gmaxwell> andytoshi: Is it late where you are? :P
20:26 < gmaxwell> andytoshi: transactions are no harder to add than incrementing the nonce.
20:26 < gmaxwell> so there is no incentive to not add them.
20:27 < andytoshi> gmaxwell: no, i think i've just got a cold :P
20:27 < gmaxwell> :P
20:27 < andytoshi> when adam3us first said "use a snark as a POW" i thought, SHA256(SNARK_PROVE(transaction updates) + nonce)
20:27 < gmaxwell> yea, don't do that.
20:28 < gmaxwell> there might be some interesting way to do a reward for producing proofs of prior states though.
20:29 < gmaxwell> two ways to mine the coin: producing blocks or producing proofs for the state in prior blocks.
20:30 < andytoshi> that'd be excellent because you're also paying people to be archival nodes
20:31 < gmaxwell> in any case, I think we're still a ways off. E.g. you can't even download and screw around with any of this stuff.
20:31 < gmaxwell> and I'm sure what exists is Academic Quality code.
20:31 < andytoshi> i concur
20:31 < andytoshi> i'm about halfway through the first snark paper, the impression i get is that i can't reimplement this just based on the paper
20:31 < gmaxwell> (meaning it's probably crashy garbage and half of it runs in matlab and the other half works by manually pasting things from matlab into mathmatica and back)
20:31 < andytoshi> (though maybe the tinyram paper is more detailed)
20:32 < andytoshi> gmaxwell: i've never worked with cryptography people, but that's standard MO for the rest of math
20:32 < gmaxwell> a lot of the theoretical crypto people just don't implement at all.
20:33 < gmaxwell> actually the verifyable computing stuff is unusual in that people publishing papers have implemented something.
20:33 < andytoshi> oh, damn, that was my first exposure to 21st century crypto, i thought maybe it was an implementation-friendly field :(
20:35 < gmaxwell> well, it's mixed. A lot of things in pairing crypto are easily implemented. E.g. I went and implemented the OWAS from that paper in under half an hour, including learning to use the pairing crypto library.
22:46 < Taek42> I had an idea for variable-speed blockchains
22:47 < Taek42> which I think would be desirable, because when you set a static rate, you can either be too slow (meaning you could go much faster)
22:47 < Taek42> or too fast (meaning that blocks happen faster than nodes can communicate them)
22:47 < Taek42> and right now, most coins seem to pick arbitrary values
22:49 < Taek42> If you count how many blocks have the same parent (as a percentage)
22:50 < gmaxwell> Taek42: amiller proposed several years ago commiting to orphans to control loop the rate.
22:50 < Taek42> how was the reaction to the proposal. Also, is there a link?
22:50 < gmaxwell> Taek42: but the problem with that it has enormous centeralization risks in two different ways.
22:50 < Taek42> how so?
22:52 < gmaxwell> Say for example that 60% of the hashpower was within the east cost of the US, such as system might happily adapt itself down to 100ms blocks, and just exclude the outside world. Even if the outside blocks were enough to slow it down, the majority could just happily ignore them, since its in their interest to keep it fast. Now, okay, perhaps you have some sensible floor to prevent this.
22:53 < Taek42> I think I have
22:53 < gmaxwell> Then you have the fact that only miners play in this scheme but the block rate is very important to clients as well. 1 second blocks would be a ~600x increase in bandwidth and cpu for SPV clients over 10 minutes blocks.
22:53 < Taek42> that's only assuming that at 1% blocks the blocks (and not the transaction data) are the majority of the information
22:53 < Taek42> *at 1 second blocks
22:54 < gmaxwell> so while the miners are all getting paid for their mining and can afford fast networks— tunnels through the earth and neutrino reactor transmitters and what have you—  the rest of nodes have to keep up with the flood but aren't compensated to pay for these increased costs.
22:54 < gmaxwell> and they have no control channel to express this displeasure.
22:55 < Taek42> hmmm
22:56 < gmaxwell> Taek42: why wouldn't it be at 1 second though? the system will keep speeding up until miners can't get lower latency networks, and then it will start excluding miners who are too far out— e.g. in .au.  Right now there is hardly any incentive to do anything heroic about your network as a miner, but if the time kept going down as miners improved their connectivity there would be.
22:56 < gmaxwell> amiller_: perhaps has a link to his writeup.
22:57 < Taek42> Well the idea is that when you want to send money over the network you just tell a miner. I don't think faster blockrates would result in less transactions
22:57 < Taek42> unless a faster blockrate meant that non-miners couldn't verify the balance of an adversary
22:57 < gmaxwell> (uh, you know bitcoin has no balances in it— right?)
22:57 < Taek42> I'm guessing you are saying a semantic thing
22:58 < gmaxwell> It would intefear with other nodes imposing the rules. Bitcoin is a trustless system, and part of the incentive alignment for miners is that non-miners vaidate their blocks too.
22:59 < Taek42> how can non-miners validate a block? I thought blocks were validated by additional blocks being mined on top of them
22:59 < gmaxwell> ...
22:59 < Taek42> bear with me
22:59 < gmaxwell> By stepping through the data and checking each piece of it against the hundreds of rules of the system.
23:00 < Taek42> oh okay
23:00 < Taek42> but say that a non-miner finds something incorrect
23:00 < Taek42> what happens?
23:00 < wyager> Mmmm
23:01 < wyager> They ignore the block
23:01 < gmaxwell> They just ignore the block forever and all successive blocks. This is what prevents a malicious group of miners from inflating the currency or stealing people's coins (which might have returns great enough to justify their misbehavior)
23:01 < wyager> You're thinking of an SPV node, Taek42
23:01 < wyager> SPV nodes verify blocks by their depth
23:01 < wyager> (right?)
23:01 < wyager> full nodes actually verify blocks
23:01 < Taek42> okay that makes sense
23:01 < wyager> Like, making sure their hash value is low enough and there aren't any illegal transactions and stuff
23:02 < gmaxwell> Bitcoin's security is predominantly autonomous zero trust— you don't trust anyone at all to the extent that thats possible.  Miners influence is strictly limited to transaction ordering— which is powerful, but hopefully limited enough to keep them honest.
23:03 < gmaxwell> (and we only trust miners for ordering because we don't have an alternative... it would be nice if physics allowed a decenteralized, autonomous, and consistent ordering— but it appears not to)
23:03 < Taek42> consistent ordering might be more achievable if you implementing some sorting
23:03 < Taek42> but then miners could still pick different blocks for different transactions
23:04 < Taek42> *implemented
23:05 < gmaxwell> Taek42: sorting can't work unless you have a jamming proof network which can reach all parties in finite time. Otherwise someone can know of a transaction that others don't and the rest only learn later.
23:05 < Taek42> yeah
23:06 < gmaxwell> in any case, thats why we have mining, it solves that little problem.
23:06 < Taek42> with the current bitcoin, what happens when the transaction volume grows to a point where only miners can keep up?
23:07 < gmaxwell> But mining means bitcoin isn't like most cryptosystems, the good guys don't have an exponential advantage over the attacker, only a linear one; so that makes the economics very important too.
23:07 < gmaxwell> Taek42: it can't.
23:07 < Taek42> what do you mean by it can't?
23:07 < Taek42> suppose you reach several thousand transactions per second?
23:07 < gmaxwell> The system has hardcoded rules on the maximum size of blocks technically as absolute as the limit of 21 million total bitcoins. This means that even if the miners want to make huge blocks to stop other people from validating they can't.
23:08 < Taek42> ah
23:08 < gmaxwell> and to increase the limit requires all node software be replaced, so effectively it requires the consent of all the (remaining) users.
23:08 < Taek42> so at some point the demand for transactions could outgrow the hardcoded rule that limits transaction volume
23:09 < gmaxwell> Sure, though there are many differnet ways to deal with that (beyond just upping the limit— which is perhaps possible, but there is that decenteralization tradeoff).
23:11 < Taek42> forgive me as I start to talk about things I don't know much about; wouldn't a more ideal currency (if theoretically impossible) not require non-miners to participate at all?
23:12 < wyager> Well an ideal currency wouldn't require miners or nodes or any of that stuff :p
23:12 < gmaxwell> Taek42: no, thats horiffic.
23:12 < Taek42> that's a good point
23:12 < Taek42> why horrific?
23:12 < gmaxwell> Taek42: because then you'd have to trust miners. And the whole point of Bitcoin was to eliminate trust.
23:13 < Taek42> what if you only have to trust that 51% of miners are honest?
23:13 < gmaxwell> The ideal system would have no miners, just participants.
23:13 < Taek42> participants that don't need to keep track of the entire state of the system
23:13 < gmaxwell> Taek42: what would make them honest? Bitcoin's assumption isn't merely that most are honest.
23:14 < Taek42> what if you only have to trust that only (epsilon approaching 0%) miners are honest?
23:15 < Taek42> but I see what you are saying
23:15 < gmaxwell> Taek42: after all, the fed's employees are mostly honest.  The fact that everything else gets enforced by mathmatical proof with 100% strength is one of the reasons the fact that honest users don't have an advantage over attackers is perhaps acceptable.
23:15 < Taek42> with bitcoin you don't need to trust some foreign entity, you can verify the whole chain yourself
23:15 < Taek42> but the cost is a 12GB (and growing) file and some computation
23:15 < gmaxwell> no, thats not quite true.
23:16 < Taek42> expand?
23:16 < gmaxwell> You can go ahead and delete the historic blocks, they're only used to initialize new peers.  (well not quite, at least not yet— if you delete them your node will work fine until a new peer tries to grab a historic block from you and then you'll crash)
23:16 < gmaxwell> you only need the chainstate to verify new blocks that come in.
23:17 < gmaxwell> and thats about 300 MBytes right now.
23:17 < gmaxwell> and grows moderately slowly (looked decidely logarithmic before people started created junk txouts to store data).
23:17 < Taek42> but then you have to trust the incoming chainstate
23:17 < Taek42> if you are new
23:18 < gmaxwell> Nope.
23:18 < Taek42> no?
23:18 < gmaxwell> You can build it for yourself, but not store the historic data. (e.g. you have to inspect it once, but no storage cost)
23:18 < Taek42> okay
23:19 < Taek42> you still won't know though if you are looking at the actual chain or a fork
23:19 < gmaxwell> huh?!
23:19 < Taek42> suppose you are on a malicious network
23:19 < Taek42> feeding you a set of blocks from the genesis block
23:19 < Taek42> at some point they fork
23:19 < Taek42> and create an alternate histroy
23:19 < Taek42> *history
23:19 < gmaxwell> No, you inspect headers first to decide which chain has the most proof of work. Then validate it it. If you find a rule violation you black list that block and reorg.
23:20 < Taek42> assuming you get a block from the correct chain
23:20 < gmaxwell> No, it doesn't matter.
23:20 < Taek42> ???
23:21 < gmaxwell> Taek42: lets contine your example.
23:21 < Taek42> okay, I'll rework it a little though
23:21 < gmaxwell> they create malicious blocks, okay fine.  Does this chain of malicious blocks have the most total POW of all the chains you can see.
23:21 < Taek42> (not that I think it's a realistic attack - just having fun)
23:21 < gmaxwell> ?
23:21 < Taek42> start from the gensis block
23:21 < Taek42> connect to the 'internet' (which is actually controlled by the NSA)
23:22 < Taek42> so every block you see has been manipulated
23:22 < Taek42> by your upstream attacker
23:23 < gmaxwell> Yea, okay. You're talking about an isolation attack.
23:23 < Taek42> yeah
23:23 < Taek42> sorry still learning the terms
23:24 < gmaxwell> So, a couple defenses: any client software should have the total work of the real network at the time of its creation coded into it, so a rewrite from genesis attack reduces to being able to get honest software. (unless the attacker has enough hashpower to overcome the network throughly)
23:25 < gmaxwell> If thats the case, then they can only isolate you relative to a recent forking of the network— which means unless they have very significant hashpower they can only create blocks slowly.
23:25 < gmaxwell> Because you're validating blocks they can only create an apparently valid chain— only spend their own coins on you (or newly mined coins, but those can't be spent until they've produced >100 blocks)
23:26 < Taek42> wait that last part - newly mined coins can't be spent right away?
23:26 < gmaxwell> no, not for 100 blocks.
23:27 < Taek42> didn't know that
23:27 < Taek42> I'd like to see a currency (soon) that could realistically support blocks every few hundred milliseconds
23:28 < wyager> Why?
23:28 < Taek42> so that bitcoin could be used in stores and be as fast as credit cards
23:28 < gmaxwell> Taek42: ...
23:28 < wyager> It already can.
23:28 < wyager> You don't *need* to wait for a confirmation
23:28 < Taek42> with the help of a centralized party
23:28 < Taek42> or if the store owner takes a risk and doesn't confirm
23:28 < gmaxwell> complete misunderstanding there. Bitcoin transactions are already instant, their irreversability takes time.  Credit card transactions are reversable for _months_.
23:28 < wyager> conventional wisdom tells us waiting a few seconds for a double spend is "good enough"
23:28 < gmaxwell> wyager: uhhhh
23:28 < wyager> Which is true
23:29 < wyager> (to be clear: Wait 5 seconds to make sure no one sent out a competing txn, then you're good)
23:29 < gmaxwell> wyager: thats really not true, not at all. It depends on the specifics of your situation and doesn't generalize. In some cases it's perfectly fine, in others its not.
23:29 < wyager> OK, true
23:29 < Taek42> credit card transactions are reversible under a set of rules that are trusted by the centralized system we use today
23:29 < wyager> Don't do that for expensive transactions. But if you're buying milk and eggs at the store, I'd say it's fine.
23:30 < gmaxwell> Taek42: no they're not, call up your credit card company. They will reverse _any_ transaction. You just have to ask.
23:30 < gmaxwell> (and of course tell them some yarn about how it couldn't have been yours)
23:30 < wyager> ^It's true. You don't even need to sign anything.
23:30 < wyager> And the *only* time the CC companies side with the merchant is if the merchant has an ink imprint of your physical card and a physical copy of your signature
23:30 < Taek42> yes but for the most part store owners don't have to deal with large enough losses
23:30 < wyager> which no one ever does
23:31 < wyager> They certainly do
23:31 < gmaxwell> Taek42: the merchant gets told and of course could sue you or ban you from their store. But they could do the same with a bitcoin transaction if their security procedures were setup for it.
23:31 < wyager> most stores pay chargeback insurance
23:31 < gmaxwell> Taek42: in any case, you cannot have a bitcoin like system with 100ms blocks, it wouldn't be reliably convergent.
23:31 < Taek42> right but we'd like a system where you don't need all of that fuss
23:31 < gmaxwell> Taek42: already in bitcoin with our moderately sized blocks we get 90% propagation taking a couple seconds.
23:31 < Taek42> well, I don't think you could have a single global blockchain
23:32 < Taek42> I'm here to talk about what types of changes might make it feasible
23:32 < wyager> Then how do you know your blockchain is correct?
23:32 < gmaxwell> if the mean time between blocks falls below the network radius the system will stop converging. (e.g. orphan rate tends to >100%)
23:32 < Luke-Jr> nevermind credit cards, lots of stores take personal checks..
23:32 < gmaxwell> Taek42: you could have a control loop to control orphan levels, the result wouldn't bee 100ms.
23:33 < gmaxwell> not unless the network collapsed to excluding miners outside of a few geographically close and well connected data centers.
23:33 < Taek42> well let's relax it to 5 seconds then
23:33 < Taek42> actually
23:33 < Taek42> let me think for a minute or so
23:33 < gmaxwell> Taek42: great, so then you have times when the first confirmation takes 50 seconds due to variance.
23:33 < Luke-Jr> Taek42: more often blocks = lower difficulty = less security per block
23:33 < Taek42> true
23:34 < Luke-Jr> there's simply no need for blocks faster than 10 minutes
23:34 < Taek42> why not?
23:34 < gmaxwell> seriously, expecting a blockchain consensus to be instant is foolish and unnecessary. There are plenty of ways to secure payments for instant transactions which doesn't involve centeralizing things.
23:34 < kyrio> lol
23:34 < Taek42> what if imgur wants to switch to a system where people pay in bitcoins before downloading an image from their servers?
23:34 < Taek42> a true micropayment system?
23:35 < Taek42> gmaxwell people would have said the same thing about bitcoin 10 years ago
23:35 < Taek42> and still say the same about it today
23:35 < gmaxwell> Taek42: then they can't use direct bitcoin payments for every item regardless because of scalablity. Bitcoin is a global broadcast network. People in china don't care about imgur's dust payments.   They could use a micropayment channel, for example, however.
23:35 < gmaxwell> and those increment instantly.
23:36 < Taek42> how do micropayment channels work?
23:36 < gmaxwell> seriously, please spend some time researching before showing up asking to redesign a system you aren't fully up to speed on yet.
23:36 < Taek42> I've spent lots of time researching
23:36 < Taek42> but there's lots to look at
23:37 < Luke-Jr> Taek42: there's no need for blocks faster than 10 minutes, because TODAY, 10 minutes is INSANELY FASTER THAN EVERYTHING ELSE
23:37 < kyrio> lol
23:37 < gmaxwell> kyrio: can you say anything else?
23:37 < Luke-Jr> credit cards take 6+ months to confirm
23:37 < Luke-Jr> personal checks, you don't even know if the person has the money!
23:37 < Taek42> Luke-Jr that's a bit of a poor argument. Just because it's better than everything that currently exists doesn't mean that it's better than what is maximally useful
23:37 < gmaxwell> Luke-Jr: Yes, though you may need some additional things to give bitcoin credit card parity, depending on the application.
23:38 < Luke-Jr> gmaxwell: caselaw is the only thing that comes to mind <.<
23:38 < gmaxwell> Taek42: reducing the block time is has a lot of collateral effects, however, and can never guarantee "instant" on its own.
23:39 < gmaxwell> Luke-Jr: well, for example, digital ID that will allow a defrauded merchant to sue the cheating customer in the case of a reversal. (for items of value great enough to bother doing that)
23:40 < Luke-Jr> gmaxwell: merchants could easily require scanning your photo id to accept bitcoin payments
23:41 < gmaxwell> Taek42: e.g. say you have an orphan rate targeting thing and you ignore the node and client operating costs. What will it's speed be if you're targeting <10% orphans or whatever?  median time to network saturation is a few seconds, so λ needs to be 1/ some multiple of that, say 10 seconds.  Which means you're going to get 1+ minute confirmation times pretty often, and a single confirm is not terribly persusive esp in a network with ...
23:41 < gmaxwell> ... 10% orphans.
23:41 < gmaxwell> Luke-Jr: sure. some do.
23:43 < gmaxwell> Taek42: for something which is a true micropayment system, some semi-decenteralized but not trustless  clearing house probably does provide a pretty optimal tradeoff.  Because you can have instant processing, and the trust exposure is minimal since you're talking about very small values...
23:44 < Taek42> sounds reasonable to me
23:44 < gmaxwell> e.g. you assign coins to a bank run by 5 entities such that it requires 3 out of the 5 to spend the coins, then the 5 entities cooperate to operate a micropayment system.
23:44 < gmaxwell> bitcoin's multisignature transactions directly facilitates that.
23:44 < gmaxwell> and then you can reasonably have deeply subsecond payments for very tiny amounts.
23:44 < Taek42> I've tried reading about the multisignature transactions, and I get a bit confused
23:45 < Taek42> my friend said there's a limit of like 3 signatures?
23:46 < Luke-Jr> just to use the public infrastructure
23:46 < Luke-Jr> up to 20 if you make private arrangements
23:47 < Luke-Jr> and that's to spend, not to receive
23:47 < gmaxwell> No. Distinction between IsStandard() and the rules of the system. Basically unusual transactions are not relayed by the network to prevent them from being used for DOS attacks... IsStandard doesn't need to be consistent across the network and is easily changed in updates.
23:47 < Taek42> ok
23:48 < Luke-Jr> IsStandard isn't centralised either - any miner can change it for himself
23:58 < Taek42> gmaxwell (and everybody), what altcoins do you think are most interesting?
23:59 < Luke-Jr> Tonal Bitcoin, Namecoin, and Freicoin are pretty much all
23:59 < wyager> Primecoin, but I don't trust that prime finding difficulty will stay significant
--- Log closed Tue Jan 07 00:00:00 2014