| 00:19:47 | 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 |
| 00:22:18 | gmaxwell: | michagogo|cloud: I don't see why you think thats a benefit of pruning. |
| 00:26:02 | sipa: | the only advantage is less data that needs to be copied in that case |
| 00:26:28 | sipa: | but making it easy to run in a way that requires absolute trust in another node is not really a priorit |
| 00:37:13 | michagogo|cloud: | gmaxwell: because you don't need to copy 12+ GB |
| 01:13:08 | Luke-Jr: | combined with SCIP it could be trustless perhaps :p |
| 01:13:53 | gmaxwell: | Luke-Jr: yea sure, but we're currently a long way from authoring proofs of state for bitcoin. |
| 01:15:12 | gmaxwell: | e.g. see the benchmarks in 13:59 < andytoshi> a new snark paper from ben-sasson: http://eprint.iacr.org/2013/879 |
| 01:16:48 | adam3us: | gmaxwell: just have to use it recursively as the pow :) (self-evident) proof of making snark proof as the pow |
| 01:17:33 | 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 |
| 01:17:33 | gmaxwell: | less crazy than it might seem. |
| 01:17:42 | andytoshi: | but can you do that in zero knowledge? i'd have to think about it |
| 01:17:57 | gmaxwell: | andytoshi: nah, just pretextually. |
| 01:18:51 | gmaxwell: | andytoshi: e.g. make your POW SHA256(SNARK_PROVE(SHA256(header))) |
| 01:19:17 | andytoshi: | just MAC them ;) |
| 01:19:18 | gmaxwell: | and of course you use a nice universal circuit inside the snark_prove in order to hopefully cutoff sha-256 specific optimizations. |
| 01:20:10 | andytoshi: | gmaxwell: so the idea is, changing the nonce is just as hard as adding transactions? |
| 01:22:59 | 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 |
| 01:24:41 | andytoshi: | gmaxwell: well, if transactions are hard to add that kills the idea immediately because there'd be only empty blocks |
| 01:25:33 | andytoshi: | as it is, an alt could be written today which does this |
| 01:25:37 | andytoshi: | (and nobody would be able to mine it :P) |
| 01:26:03 | 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. |
| 01:26:14 | gmaxwell: | andytoshi: Is it late where you are? :P |
| 01:26:27 | gmaxwell: | andytoshi: transactions are no harder to add than incrementing the nonce. |
| 01:26:35 | gmaxwell: | so there is no incentive to not add them. |
| 01:27:14 | andytoshi: | gmaxwell: no, i think i've just got a cold :P |
| 01:27:19 | gmaxwell: | :P |
| 01:27:41 | andytoshi: | when adam3us first said "use a snark as a POW" i thought, SHA256(SNARK_PROVE(transaction updates) + nonce) |
| 01:27:53 | gmaxwell: | yea, don't do that. |
| 01:28:41 | gmaxwell: | there might be some interesting way to do a reward for producing proofs of prior states though. |
| 01:29:08 | gmaxwell: | two ways to mine the coin: producing blocks or producing proofs for the state in prior blocks. |
| 01:30:02 | andytoshi: | that'd be excellent because you're also paying people to be archival nodes |
| 01:31:00 | 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. |
| 01:31:09 | gmaxwell: | and I'm sure what exists is Academic Quality code. |
| 01:31:20 | andytoshi: | i concur |
| 01:31:41 | 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 |
| 01:31:42 | 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) |
| 01:31:47 | andytoshi: | (though maybe the tinyram paper is more detailed) |
| 01:32:15 | andytoshi: | gmaxwell: i've never worked with cryptography people, but that's standard MO for the rest of math |
| 01:32:42 | gmaxwell: | a lot of the theoretical crypto people just don't implement at all. |
| 01:33:12 | gmaxwell: | actually the verifyable computing stuff is unusual in that people publishing papers have implemented something. |
| 01:33:57 | andytoshi: | oh, damn, that was my first exposure to 21st century crypto, i thought maybe it was an implementation-friendly field :( |
| 01:35:22 | 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. |
| 03:46:43 | Taek42: | I had an idea for variable-speed blockchains |
| 03:47:10 | 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) |
| 03:47:22 | Taek42: | or too fast (meaning that blocks happen faster than nodes can communicate them) |
| 03:47:35 | Taek42: | and right now, most coins seem to pick arbitrary values |
| 03:49:57 | Taek42: | If you count how many blocks have the same parent (as a percentage) |
| 03:50:01 | gmaxwell: | Taek42: amiller proposed several years ago commiting to orphans to control loop the rate. |
| 03:50:23 | Taek42: | how was the reaction to the proposal. Also, is there a link? |
| 03:50:38 | gmaxwell: | Taek42: but the problem with that it has enormous centeralization risks in two different ways. |
| 03:50:53 | Taek42: | how so? |
| 03:52:28 | 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. |
| 03:53:09 | Taek42: | I think I have |
| 03:53:10 | 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. |
| 03:53:46 | Taek42: | that's only assuming that at 1% blocks the blocks (and not the transaction data) are the majority of the information |
| 03:53:55 | Taek42: | *at 1 second blocks |
| 03:54:29 | 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. |
| 03:54:51 | gmaxwell: | and they have no control channel to express this displeasure. |
| 03:55:06 | Taek42: | hmmm |
| 03:56:12 | 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. |
| 03:56:19 | gmaxwell: | amiller_: perhaps has a link to his writeup. |
| 03:57:00 | 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 |
| 03:57:14 | Taek42: | unless a faster blockrate meant that non-miners couldn't verify the balance of an adversary |
| 03:57:31 | gmaxwell: | (uh, you know bitcoin has no balances in it— right?) |
| 03:57:59 | Taek42: | I'm guessing you are saying a semantic thing |
| 03:58:02 | 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. |
| 03:59:07 | Taek42: | how can non-miners validate a block? I thought blocks were validated by additional blocks being mined on top of them |
| 03:59:22 | gmaxwell: | ... |
| 03:59:38 | Taek42: | bear with me |
| 03:59:43 | gmaxwell: | By stepping through the data and checking each piece of it against the hundreds of rules of the system. |
| 04:00:04 | Taek42: | oh okay |
| 04:00:17 | Taek42: | but say that a non-miner finds something incorrect |
| 04:00:25 | Taek42: | what happens? |
| 04:00:57 | wyager: | Mmmm |
| 04:01:07 | wyager: | They ignore the block |
| 04:01:08 | 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) |
| 04:01:16 | wyager: | You're thinking of an SPV node, Taek42 |
| 04:01:23 | wyager: | SPV nodes verify blocks by their depth |
| 04:01:28 | wyager: | (right?) |
| 04:01:36 | wyager: | full nodes actually verify blocks |
| 04:01:47 | Taek42: | okay that makes sense |
| 04:01:54 | wyager: | Like, making sure their hash value is low enough and there aren't any illegal transactions and stuff |
| 04:02:15 | 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. |
| 04:03:08 | 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) |
| 04:03:47 | Taek42: | consistent ordering might be more achievable if you implementing some sorting |
| 04:03:57 | Taek42: | but then miners could still pick different blocks for different transactions |
| 04:04:23 | Taek42: | *implemented |
| 04:05:14 | 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. |
| 04:05:39 | Taek42: | yeah |
| 04:06:33 | gmaxwell: | in any case, thats why we have mining, it solves that little problem. |
| 04:06:53 | Taek42: | with the current bitcoin, what happens when the transaction volume grows to a point where only miners can keep up? |
| 04:07:00 | 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. |
| 04:07:06 | gmaxwell: | Taek42: it can't. |
| 04:07:17 | Taek42: | what do you mean by it can't? |
| 04:07:44 | Taek42: | suppose you reach several thousand transactions per second? |
| 04:07:52 | 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. |
| 04:08:07 | Taek42: | ah |
| 04:08:42 | gmaxwell: | and to increase the limit requires all node software be replaced, so effectively it requires the consent of all the (remaining) users. |
| 04:08:47 | Taek42: | so at some point the demand for transactions could outgrow the hardcoded rule that limits transaction volume |
| 04:09:35 | 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). |
| 04:11:27 | 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? |
| 04:12:34 | wyager: | Well an ideal currency wouldn't require miners or nodes or any of that stuff :p |
| 04:12:43 | gmaxwell: | Taek42: no, thats horiffic. |
| 04:12:47 | Taek42: | that's a good point |
| 04:12:51 | Taek42: | why horrific? |
| 04:12:58 | gmaxwell: | Taek42: because then you'd have to trust miners. And the whole point of Bitcoin was to eliminate trust. |
| 04:13:10 | Taek42: | what if you only have to trust that 51% of miners are honest? |
| 04:13:12 | gmaxwell: | The ideal system would have no miners, just participants. |
| 04:13:34 | Taek42: | participants that don't need to keep track of the entire state of the system |
| 04:13:43 | gmaxwell: | Taek42: what would make them honest? Bitcoin's assumption isn't merely that most are honest. |
| 04:14:49 | Taek42: | what if you only have to trust that only (epsilon approaching 0%) miners are honest? |
| 04:15:04 | Taek42: | but I see what you are saying |
| 04:15:06 | 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. |
| 04:15:22 | Taek42: | with bitcoin you don't need to trust some foreign entity, you can verify the whole chain yourself |
| 04:15:35 | Taek42: | but the cost is a 12GB (and growing) file and some computation |
| 04:15:50 | gmaxwell: | no, thats not quite true. |
| 04:16:03 | Taek42: | expand? |
| 04:16:43 | 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) |
| 04:16:57 | gmaxwell: | you only need the chainstate to verify new blocks that come in. |
| 04:17:09 | gmaxwell: | and thats about 300 MBytes right now. |
| 04:17:47 | gmaxwell: | and grows moderately slowly (looked decidely logarithmic before people started created junk txouts to store data). |
| 04:17:56 | Taek42: | but then you have to trust the incoming chainstate |
| 04:17:58 | Taek42: | if you are new |
| 04:18:06 | gmaxwell: | Nope. |
| 04:18:21 | Taek42: | no? |
| 04:18:29 | 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) |
| 04:18:42 | Taek42: | okay |
| 04:19:05 | Taek42: | you still won't know though if you are looking at the actual chain or a fork |
| 04:19:13 | gmaxwell: | huh?! |
| 04:19:29 | Taek42: | suppose you are on a malicious network |
| 04:19:35 | Taek42: | feeding you a set of blocks from the genesis block |
| 04:19:38 | Taek42: | at some point they fork |
| 04:19:44 | Taek42: | and create an alternate histroy |
| 04:19:46 | Taek42: | *history |
| 04:19:56 | 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. |
| 04:20:22 | Taek42: | assuming you get a block from the correct chain |
| 04:20:39 | gmaxwell: | No, it doesn't matter. |
| 04:20:46 | Taek42: | ??? |
| 04:21:10 | gmaxwell: | Taek42: lets contine your example. |
| 04:21:18 | Taek42: | okay, I'll rework it a little though |
| 04:21:29 | 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. |
| 04:21:30 | Taek42: | (not that I think it's a realistic attack - just having fun) |
| 04:21:36 | gmaxwell: | ? |
| 04:21:44 | Taek42: | start from the gensis block |
| 04:21:53 | Taek42: | connect to the 'internet' (which is actually controlled by the NSA) |
| 04:22:40 | Taek42: | so every block you see has been manipulated |
| 04:22:55 | Taek42: | by your upstream attacker |
| 04:23:19 | gmaxwell: | Yea, okay. You're talking about an isolation attack. |
| 04:23:26 | Taek42: | yeah |
| 04:23:37 | Taek42: | sorry still learning the terms |
| 04:24:40 | 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) |
| 04:25:09 | 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. |
| 04:25:49 | 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) |
| 04:26:36 | Taek42: | wait that last part - newly mined coins can't be spent right away? |
| 04:26:51 | gmaxwell: | no, not for 100 blocks. |
| 04:27:06 | Taek42: | didn't know that |
| 04:27:56 | Taek42: | I'd like to see a currency (soon) that could realistically support blocks every few hundred milliseconds |
| 04:28:04 | wyager: | Why? |
| 04:28:08 | Taek42: | so that bitcoin could be used in stores and be as fast as credit cards |
| 04:28:13 | gmaxwell: | Taek42: ... |
| 04:28:14 | wyager: | It already can. |
| 04:28:26 | wyager: | You don't *need* to wait for a confirmation |
| 04:28:30 | Taek42: | with the help of a centralized party |
| 04:28:43 | Taek42: | or if the store owner takes a risk and doesn't confirm |
| 04:28:43 | gmaxwell: | complete misunderstanding there. Bitcoin transactions are already instant, their irreversability takes time. Credit card transactions are reversable for _months_. |
| 04:28:47 | wyager: | conventional wisdom tells us waiting a few seconds for a double spend is "good enough" |
| 04:28:53 | gmaxwell: | wyager: uhhhh |
| 04:28:55 | wyager: | Which is true |
| 04:29:23 | wyager: | (to be clear: Wait 5 seconds to make sure no one sent out a competing txn, then you're good) |
| 04:29:26 | 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. |
| 04:29:32 | wyager: | OK, true |
| 04:29:47 | Taek42: | credit card transactions are reversible under a set of rules that are trusted by the centralized system we use today |
| 04:29:49 | 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. |
| 04:30:13 | gmaxwell: | Taek42: no they're not, call up your credit card company. They will reverse _any_ transaction. You just have to ask. |
| 04:30:26 | gmaxwell: | (and of course tell them some yarn about how it couldn't have been yours) |
| 04:30:32 | wyager: | ^It's true. You don't even need to sign anything. |
| 04:30:54 | 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 |
| 04:30:56 | Taek42: | yes but for the most part store owners don't have to deal with large enough losses |
| 04:30:57 | wyager: | which no one ever does |
| 04:31:04 | wyager: | They certainly do |
| 04:31:11 | 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. |
| 04:31:11 | wyager: | most stores pay chargeback insurance |
| 04:31:35 | gmaxwell: | Taek42: in any case, you cannot have a bitcoin like system with 100ms blocks, it wouldn't be reliably convergent. |
| 04:31:38 | Taek42: | right but we'd like a system where you don't need all of that fuss |
| 04:31:52 | gmaxwell: | Taek42: already in bitcoin with our moderately sized blocks we get 90% propagation taking a couple seconds. |
| 04:31:55 | Taek42: | well, I don't think you could have a single global blockchain |
| 04:32:24 | Taek42: | I'm here to talk about what types of changes might make it feasible |
| 04:32:27 | wyager: | Then how do you know your blockchain is correct? |
| 04:32:30 | gmaxwell: | if the mean time between blocks falls below the network radius the system will stop converging. (e.g. orphan rate tends to >100%) |
| 04:32:34 | Luke-Jr: | nevermind credit cards, lots of stores take personal checks.. |
| 04:32:55 | gmaxwell: | Taek42: you could have a control loop to control orphan levels, the result wouldn't bee 100ms. |
| 04:33:17 | gmaxwell: | not unless the network collapsed to excluding miners outside of a few geographically close and well connected data centers. |
| 04:33:18 | Taek42: | well let's relax it to 5 seconds then |
| 04:33:30 | Taek42: | actually |
| 04:33:35 | Taek42: | let me think for a minute or so |
| 04:33:39 | gmaxwell: | Taek42: great, so then you have times when the first confirmation takes 50 seconds due to variance. |
| 04:33:48 | Luke-Jr: | Taek42: more often blocks = lower difficulty = less security per block |
| 04:33:57 | Taek42: | true |
| 04:34:09 | Luke-Jr: | there's simply no need for blocks faster than 10 minutes |
| 04:34:18 | Taek42: | why not? |
| 04:34:20 | 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. |
| 04:34:21 | kyrio: | lol |
| 04:34:34 | Taek42: | what if imgur wants to switch to a system where people pay in bitcoins before downloading an image from their servers? |
| 04:34:38 | Taek42: | a true micropayment system? |
| 04:35:07 | Taek42: | gmaxwell people would have said the same thing about bitcoin 10 years ago |
| 04:35:14 | Taek42: | and still say the same about it today |
| 04:35:38 | 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. |
| 04:35:50 | gmaxwell: | and those increment instantly. |
| 04:36:01 | Taek42: | how do micropayment channels work? |
| 04:36:26 | gmaxwell: | seriously, please spend some time researching before showing up asking to redesign a system you aren't fully up to speed on yet. |
| 04:36:53 | Taek42: | I've spent lots of time researching |
| 04:36:55 | Taek42: | but there's lots to look at |
| 04:37:01 | Luke-Jr: | Taek42: there's no need for blocks faster than 10 minutes, because TODAY, 10 minutes is INSANELY FASTER THAN EVERYTHING ELSE |
| 04:37:14 | kyrio: | lol |
| 04:37:20 | gmaxwell: | kyrio: can you say anything else? |
| 04:37:22 | Luke-Jr: | credit cards take 6+ months to confirm |
| 04:37:31 | Luke-Jr: | personal checks, you don't even know if the person has the money! |
| 04:37:48 | 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 |
| 04:37:51 | gmaxwell: | Luke-Jr: Yes, though you may need some additional things to give bitcoin credit card parity, depending on the application. |
| 04:38:36 | Luke-Jr: | gmaxwell: caselaw is the only thing that comes to mind <.< |
| 04:38:50 | gmaxwell: | Taek42: reducing the block time is has a lot of collateral effects, however, and can never guarantee "instant" on its own. |
| 04:39:28 | 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) |
| 04:40:29 | Luke-Jr: | gmaxwell: merchants could easily require scanning your photo id to accept bitcoin payments |
| 04:41:38 | 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 ... |
| 04:41:44 | gmaxwell: | ... 10% orphans. |
| 04:41:47 | gmaxwell: | Luke-Jr: sure. some do. |
| 04:43:39 | 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... |
| 04:44:15 | Taek42: | sounds reasonable to me |
| 04:44:21 | 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. |
| 04:44:34 | gmaxwell: | bitcoin's multisignature transactions directly facilitates that. |
| 04:44:58 | gmaxwell: | and then you can reasonably have deeply subsecond payments for very tiny amounts. |
| 04:44:58 | Taek42: | I've tried reading about the multisignature transactions, and I get a bit confused |
| 04:45:06 | Taek42: | my friend said there's a limit of like 3 signatures? |
| 04:46:52 | Luke-Jr: | just to use the public infrastructure |
| 04:46:59 | Luke-Jr: | up to 20 if you make private arrangements |
| 04:47:10 | Luke-Jr: | and that's to spend, not to receive |
| 04:47:40 | 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. |
| 04:47:58 | Taek42: | ok |
| 04:48:42 | Luke-Jr: | IsStandard isn't centralised either - any miner can change it for himself |
| 04:58:15 | Taek42: | gmaxwell (and everybody), what altcoins do you think are most interesting? |
| 04:59:36 | Luke-Jr: | Tonal Bitcoin, Namecoin, and Freicoin are pretty much all |
| 04:59:48 | wyager: | Primecoin, but I don't trust that prime finding difficulty will stay significant |
| 05:00:00 | wyager: | There is no proof that finding primes is particularly difficult |
| 05:00:08 | wyager: | but I suppose the same is true about the discrete log problem haha |
| 05:00:51 | wyager: | Namecoin is actually useful |
| 05:00:59 | gmaxwell: | primecoin is pretty uninteresting, its not a problem anyone cared about before. |
| 05:01:10 | gmaxwell: | Namecoin might be interesting but it's mostly abandoned and has some serious problems. |
| 05:01:26 | wyager: | Yeah, sadly |
| 05:01:36 | wyager: | I think the tech could seriously replace DNS |
| 05:01:46 | wyager: | Scaling might be a bit of an issue, but maybe not |
| 05:02:06 | gmaxwell: | basically nothing else has done much of anything. peercoin and feather coin have solved their consensus problems (in one case PoS doesn't really work, in the other because their blocks are too fast) with developer controlled selection on the best chain. |
| 05:02:10 | Luke-Jr: | something similar to namecoin could.. |
| 05:02:32 | gmaxwell: | wyager: you can't do a secure lite client resolver for namecoin with the current design. it can be done, but namecoin doesn't do it. |
| 05:02:44 | wyager: | SPV? |
| 05:02:47 | gmaxwell: | I'd suggested how back in 2011, but by then namecoin development was mostly dead. |
| 05:02:51 | wyager: | Or SNV, rather |
| 05:02:58 | gmaxwell: | wyager: can't work in the current system. |
| 05:03:05 | wyager: | Really? Why's that? |
| 05:03:09 | gmaxwell: | (vulnerable to replay of old records) |
| 05:03:18 | wyager: | Don't records expire? |
| 05:03:19 | wyager: | Ah |
| 05:03:20 | wyager: | I see |
| 05:03:25 | wyager: | records can be updated before expiration |
| 05:03:39 | gmaxwell: | easily enough fixed: https://bitcointalk.org/index.php?topic=21995.0 |
| 05:03:48 | gmaxwell: | and the record expiration is rather long. |
| 05:04:58 | wyager: | clever |
| 05:05:33 | gmaxwell: | state proofs have a lot of other advantages, e.g. like being able to prove to a lite node that a block is invalid. |
| 05:06:05 | gmaxwell: | in any case, I have an old (and lost past due for updates) list of alt ideas I think are interesting: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas |
| 05:09:11 | wyager: | hahahaha |
| 05:09:18 | wyager: | I love the timelock chain idea |
| 05:09:26 | wyager: | that would provide a very useful public service |
| 05:10:38 | wyager: | Do you sit around all day and think of clever crypto ideas? It seems like it would be a nice hobby :p |
| 05:11:02 | gmaxwell: | wyager: I mean, it's taken years to produce these. |
| 05:11:15 | gmaxwell: | actually I have a ton more of them that aren't there. |
| 05:11:18 | wyager: | Yeah, but a lot of these are great |
| 05:11:31 | wyager: | People have built entire altcoins on less |
| 05:11:58 | gmaxwell: | correction: no altcoin has ever been built on anything as cool as anything on that list. (except maybe merged mining in namecoin) :P |
| 05:12:05 | wyager: | hehe |
| 05:12:28 | gmaxwell: | well okay, peercoin's PoS was the same scale of an idea, but it doesn't really work— but perhaps some of those ideas won't work either (well, almost certantly some won't work) |
| 05:13:03 | wyager: | What is wrong with PoS? I haven't actually researched any criticisms of Peercoin |
| 05:13:09 | wyager: | But PoS seemed OK |
| 05:13:11 | gmaxwell: | yea, I think the timelock is sexy. I came up with it midsentence while I was telling someone that timelock appears impossible. :P |
| 05:13:17 | gmaxwell: | wyager: the nothing at stake problem. |
| 05:13:32 | justanotheruser: | gmaxwell: What do you think of nxt's PoS? nxt doesn't have checkpointing. |
| 05:13:34 | wyager: | Which is? Aren't you giving up scare coin-days? |
| 05:13:39 | wyager: | *scarce |
| 05:13:43 | gmaxwell: | justanotheruser: lollollol |
| 05:14:12 | justanotheruser: | gmaxwell: I realize it is 100% premined which is why I specified their PoS |
| 05:14:24 | gmaxwell: | Basically in POW you're incentivzed to mine on the ONE TRUE most likely to ultimately survive chain— because they're burning a costly resource forever every attempt they make, and their only compensation is getting a block in that one true chain. |
| 05:15:04 | gmaxwell: | The nothing at stake problem is that since you don't really burn anything there isn't any reason not to mine many forks— in fact its the rational optimal strategy to mine all forks you don't hate. |
| 05:15:30 | wyager: | I see |
| 05:15:38 | wyager: | don't they waste compute power as well though? |
| 05:15:44 | wyager: | by mining on every random ass chain |
| 05:15:45 | justanotheruser: | gmaxwell: To fork PoS you wouldn't have to expend additional resourced, but you would still need more PoS "mining" power than the main chain. |
| 05:15:45 | gmaxwell: | Including all possible hypothetical forks. There was a neet attack once PPC started pos mining: someone programmed their system to consider all possible forks to find the ones where their stake was selected over and over again as the block winner. |
| 05:16:02 | gmaxwell: | wyager: yes and at the limit it just becomes POW in disguise when that happens. |
| 05:16:54 | Taek42: | that's a pretty cool attack |
| 05:17:10 | gmaxwell: | PPC "fixed" that bug by forever requiring POW blocks, and setting it up so the identity of the stake depended on nothing after the last POW block.. which makes the specific all-blocks-are-mine attack harder (requires some POW power), but kinda breaks the energy argument and still leaves weird incentives to mine forks. |
| 05:17:30 | gmaxwell: | justanotheruser: Oh is nxt's fork out? I'll tell you what lines of code to change so you can mine all the blocks. |
| 05:23:32 | Taek42: | I had an idea, 'Proof-of-Storage' |
| 05:23:34 | wyager: | I also like merkelized AST P2SH |
| 05:23:39 | gmaxwell: | wyager: I really wish I knew a way to make POS work, but the best I can offer is if you have one cryptocurrency you could mine another by moving/destroying/etc coins in the first. |
| 05:23:58 | wyager: | Oh, and gmaxwell, my IRC client crashed so I may have missed a few things you said |
| 05:24:02 | gmaxwell: | Taek42: do you mean something like https://bitcointalk.org/index.php?topic=310323.0 |
| 05:24:59 | Taek42: | not quite |
| 05:25:32 | Taek42: | the idea is that nodes contribute storage to the network, that can then be sold over the same network |
| 05:25:36 | Taek42: | like distributed cloud storage |
| 05:25:47 | Taek42: | where being a storage host gives you coin mining |
| 05:26:08 | gmaxwell: | Taek42: yea, I don't know how to do that except via proof of throughput which may not be what you want. |
| 05:26:09 | wyager: | Didn't cryptosphere or something try to do something like this? |
| 05:26:19 | gmaxwell: | And I've thought long and hard about how to actually do that. |
| 05:26:32 | Taek42: | where I'm currently stuck is the blockchain |
| 05:26:50 | gmaxwell: | the problem is that if you prove you have storage via a fiat-shamir of a cut and choose over it, you can just POW grind the proof to hit a fraction of the data you've kept. |
| 05:27:14 | gmaxwell: | ... and worse, its delegatable. |
| 05:27:23 | Taek42: | delegatable? |
| 05:27:30 | gmaxwell: | e.g. a pool can keep the data, and answer queries for other miners. |
| 05:27:38 | gmaxwell: | so you'd only get one copy of the data, which wasn't your goal. |
| 05:28:28 | Taek42: | ah yes, we did think of a solution to that |
| 05:28:32 | Taek42: | a partial solution, that is |
| 05:33:32 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 260 seconds)) |
| 05:34:26 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
| 05:35:09 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
| 05:36:14 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
| 05:37:09 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Connection timed out)) |
| 05:39:49 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: 70.70.46.218 (Connection timed out)) |
| 05:40:03 | pratchett.freenode.net: | topic is: Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas |
| 05:40:03 | pratchett.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot phantomcircuit_ edulix_ MoALTz_ OneFixt wyager Taek42 go1111111 harrow espes___ azariah4 shesek wangbus hnz nsh spinza_ iddo Muis epscy gribble Graet CodeShark maaku nOgAn0o justanotheruser warren HM adam3us michagogo|cloud Ryan52 lianj helo Alanius sipa wumpus Hunger- BlueMatt @ChanServ amiller_ Luke-Jr UukGoblin nanotube typex Fistful_of_Coins petertodd hno kyrio cfields jrmithdobbs Krellan realazthat rs0 Mikalv |
| 05:40:03 | pratchett.freenode.net: | Users on #bitcoin-wizards: jarpiain Sangheili_afk tucenaber midnightmagic ghtdak trn forrestv pigeons gmaxwell EasyAt jgarzik kinlo K1773R |
| 05:40:09 | gmaxwell: | Taek42: you code your data with a locally decidable code, and then encrypt the codewords. then you issue the codewords to peers. |
| 05:40:17 | gmaxwell: | the peers cannot recover your data because its encrypted. |
| 05:40:32 | gmaxwell: | you can test small fractions of the data by requesting and decrypting and then using the local codeword test. |
| 05:40:51 | phantomcircuit_: | phantomcircuit_ is now known as phantomcircuit |
| 05:41:45 | gmaxwell: | (I guess the term is actually "locally testable code") |
| 05:42:14 | Taek42: | so the sacrifice would be that you are the only one who is able to repair the file if nodes go offline |
| 05:42:44 | Taek42: | as opposed to the network self-repairing |
| 05:43:12 | gmaxwell: | Yes. though you could have two levels of redundancy which enabled that. |
| 05:43:42 | gmaxwell: | e.g. for the network self-repair you don't need as much correction because the network will respond fast. |
| 05:45:13 | Taek42: | I think though any time you have a self-repairing network, a large set of collaborating nodes could cheat on the redundancy |
| 05:45:37 | Taek42: | which you would block through penalties for correlated downtime |
| 05:46:03 | gmaxwell: | I still don't see how you hope to achieve that, but I'm not that curious. :) |
| 05:46:26 | Taek42: | hmm |
| 05:48:11 | Taek42: | would you consider it mandatory to a cryptocurrency that when you receive a transaction, you don't need to vest trust in some subset of the network? |
| 05:48:19 | Taek42: | because I've been thinking about building a distributed block chain |
| 05:48:41 | gmaxwell: | you mean trust in Igor and hist 999,999 botnet nodes? |
| 05:48:46 | wyager: | lol |
| 05:48:52 | Taek42: | no |
| 05:49:06 | Taek42: | it would be a randomly sampled subset based on how much work they are contributing |
| 05:49:16 | gmaxwell: | 1,111,111 nodes? |
| 05:50:07 | wyager: | If they don't make more money contributing hashing power to the network than they would contributing hashing power against the network, they can't be trusted |
| 05:50:08 | Taek42: | so Igor would need to control a large % of the work on the network (51% is reasonable) as opposed to merely needing a sufficient quantity of nodes |
| 05:50:47 | wyager: | Which is why we pay people who make the blockchain |
| 05:50:49 | Taek42: | wyager I'm pretty sure you could build it such that you always make the most money contributing towards the network as opposed to against it |
| 05:52:45 | gmaxwell: | it's actually pretty easy to break that. |
| 05:53:06 | gmaxwell: | in any case, as I said in bitcoin we trust to trust the absolute minimum possible, and even then we are not sure the system will survive. |
| 05:53:32 | gmaxwell: | many altcoins have been destroyed by attacks by miners. |
| 05:59:23 | Taek42: | hmm |
| 05:59:29 | Taek42: | also, is bytecoin still actively developed? |
| 05:59:58 | Luke-Jr: | scamcoins are almost never actively developed at any point.. |
| 06:01:00 | Taek42: | would it be bad form to steal their name? |
| 06:02:39 | Luke-Jr: | it would be bad form to steal ByteCoin-the-person's name again. |
| 06:03:07 | Luke-Jr: | imo |
| 06:03:56 | Taek42: | oh is he a person too? |
| 06:04:45 | gmaxwell: | yea, bytecoin is a cryptographer who was very active in bitcoin's early days. |
| 06:05:12 | Luke-Jr: | note: no relation to the scamcoin |
| 16:52:08 | spinza_: | spinza_ is now known as spinza |
| 17:39:38 | TD: | TD is now known as TD[gone] |
| 19:01:23 | kinlo_: | kinlo_ is now known as kinlo |
| 19:51:59 | fagmuffinz_: | justanother |
| 19:52:01 | fagmuffinz_: | What's up |
| 19:52:58 | justanotheruser: | fagmuffinz_: hi |
| 19:53:16 | justanotheruser: | You should change you're name. I think it's borderline banning territory |
| 19:54:20 | fagmuffinz_: | I would hope the nature of movements like this would line up with free speech well enough to overlook something trivial enough like a name |
| 19:54:44 | fagmuffinz_: | A name is a handle - nothing more. You can identify me, and you can identify that I prefer to remain pseudonymous |
| 19:55:32 | justanotheruser: | I wouldn't ban you for it, but free speech doesn't prevent you from getting kicked for having an inflammatory name, it just prevents you from being arrested for having one. |
| 19:55:42 | fagmuffinz_: | Also, who doesn't like muffins? |
| 19:56:06 | fagmuffinz_: | On a more serious note - I meant to get back to you on your decentralized voting scheme, but I've been traveling |
| 19:57:21 | gmaxwell: | (FWIW, a different name would probably be preferable, I had the same initial response... but you were saying thoughtful things, so I didn't bring it up. :) ) |
| 19:58:34 | fagmuffinz_: | Have you made any progress on it, or are you still where you were ~2 weeks ago? |
| 19:59:50 | justanotheruser: | fagmuffinz_: I was just asking if the system would work. I think jamming may be able to be prevented by requiring a certain number of transactions per block. |
| 20:00:54 | justanotheruser: | And a "vote/coin" can only go through a certain number of transactions from its creation |
| 20:01:09 | justanotheruser: | enough to do coinswaps and joins to anonymize them |
| 20:02:13 | justanotheruser: | along with that you wouldn't be able to have unequal inputs and outputs meaning you couldn't turn 1 vote/coin into 1000 divisible units to fill up the block transaction requirement |
| 20:03:03 | gmaxwell: | I don't know why y'all are wasting cycles on blockchain things for voting. (1) minors can trivially censor votes, (2) none of the anonymity procedures for transactions work without an underlying anonymity network, and if you've got one of those, you don't really need more than that for the anonymity part. |
| 20:06:17 | justanotheruser: | gmaxwell: (1) eventually once [vote recipient A] has all their votes, the miners would have to start accepting votes for B because blocks have to have a certain number of transactions. (2) You need to associate votes with real people in the first place so you know everyone is getting a vote. What you don't know is who they are voting. The anonymity network wouldn't do anything unless you mixed the votes before voting. |
| 20:08:18 | gmaxwell: | justanotheruser: if you must have X votes in total, then you don't need the miners at all. Just have some designated party collect the votes.. pick them at random, hell pick 10 of them to each get a copy. |
| 20:08:49 | nsh: | also voting is basically broken by mathematics |
| 20:09:00 | nsh: | there's no right way to do it, and all the wrong ways suck |
| 20:09:06 | gmaxwell: | electronic voting has a ton of research behind it, solving tricky problems you're not even thinking about (e.g. coercision / vote-buying). You're everything-is-a-nailing it with the blockchain as far as I can tell. |
| 20:09:27 | gmaxwell: | There is basically nothing useful bitcoin adds to to this particular problem. |
| 20:10:09 | justanotheruser: | gmaxwell: how do you verify that all in the voting set had their votes counted and that they are real people with "some designated party" |
| 20:10:58 | justanotheruser: | gmaxwell: I don't think coercion or vote buying can be solved in any voting system |
| 20:11:10 | gmaxwell: | justanotheruser: except they do solve these things. (largely) |
| 20:11:25 | justanotheruser: | the only person who can determine if there is coercion is an all knowing state |
| 20:11:31 | gmaxwell: | justanotheruser: Usually voting systems use verifyable reencryption mixes. |
| 20:11:51 | gmaxwell: | justanotheruser: you cannot be reliably coerced if you cannot prove to a third party how you voted. |
| 20:12:12 | justanotheruser: | gmaxwell: yes, but people can bring cellphones to voting booths pretty easily |
| 20:12:25 | justanotheruser: | "Take a picture of you voting for Putin or I will kill you" |
| 20:12:50 | gmaxwell: | justanotheruser: they're prohibited, including by observers. (and even if you had one, it's not hard to take a picture then vote another way) |
| 20:13:57 | gmaxwell: | Seriously, there are hundreds of people working on this domain, and they have good systems proposed. And their solutions do not need and would not benefit from a blockchain. They can make concrete statements about the security. |
| 20:14:49 | justanotheruser: | gmaxwell: I see. What happened in Florida? The government hacking together their own voting system? |
| 20:30:53 | adam3us: | justanotheruser: just another example of real-life-stupidity. dunning-kruger in action etc |
| 20:33:24 | gmaxwell: | certantly had little to do with cryptographic voting systems (none was in use) |
| 20:41:01 | adam3us: | justanotheruser: not directly bitcoin related but if you're interested in voting there are some papers on it, once is damgard-jurik's threshold extension of paillier's crypto system which gives split trust vote validation, user verifiable counting of votes, and summing via homomorphic encryption. phun stuff if u like crypto-math. there's a whole load of other papers, thats just one i happened to have read. |
| 20:41:32 | fagmuffinz_: | (Back) |
| 20:45:29 | fagmuffinz_: | Oh, cool, nsh is in here also. Was wondering if anyone here was working on 3301 |
| 20:45:41 | nsh: | s/on/for/ |
| 20:53:12 | maaku: | :) |
| 20:55:32 | justanotheruser: | adam3us: link? |
| 20:57:30 | adam3us: | justanotheruser: hmm one sec http://en.wikipedia.org/wiki/Damg%C3%A5rd%E2%80%93Jurik_cryptosystem there's an author home page paper link from there, if that doesnt work try citeseer. |
| 20:57:49 | justanotheruser: | thanks |
| 21:00:16 | adam3us: | justanotheruser: i only read it because i knew what pallier was and it is necessary to use DG extended pallier tricks to get a blind signature out of DSA (it sucks that badly compared to Schnorr, its horrendous the complexity of blind DSA, blind ECDSA i am not sure is known to be possible). pallier itself is a nice little RSA related crypto system thta has the unusual property of being additively homomorphic and capable of trapdoor discret |
| 21:00:33 | adam3us: | justanotheruser: truncated much was that? |
| 21:01:16 | justanotheruser: | adam3us: yes, quire discret |
| 21:01:18 | justanotheruser: | *quite |
| 21:01:49 | justanotheruser: | Does your client not automatically make the truncated bit a new message? |
| 21:01:55 | adam3us: | justanotheruser: ... [pallier] capable of trapdoor discrete log with the private key which could be an interesting trick in many settings |
| 21:02:34 | adam3us: | justanotheruser: and a relatively recent invention (1999) for a basic assumption simple crypto system |
| 21:06:05 | justanotheruser: | interesting |
| 21:08:23 | adam3us: | justanotheruser: indeed not, this is pidgin, though there is probably a plugin that could make it do so. |
| 21:08:47 | justanotheruser: | It's not interesting? |
| 21:12:36 | adam3us: | justanotheruser: i thought pallier was an interesting trick, but i collect interesting crypto constructs in a mental check list to have in mind to build esoteric or interesting protocols with |
| 21:17:39 | justanotheruser: | Oh, I was confused by "interesting not" |
| 21:17:50 | fagmuffinz_: | trapdoor discrete log? |
| 21:21:33 | nsh: | adam3us, is this still in the context of leakfree signature systems? |
| 21:23:50 | nsh: | * nsh muses |
| 21:23:55 | adam3us: | nsh: not really, though blinding is one of the technique brands others used to remove leaks (aka subliminal channels) from semi-trusted wallets with observers, and this DG thing was one of the parts used to make the DSA blinding monstrosity . seems simpler to use ecschnorr/ed25519 |
| 21:24:14 | nsh: | right |
| 21:24:17 | maaku: | is there any "unofficially official" conference this year, like bitcoin 2013 was last year? |
| 21:24:26 | adam3us: | fagmuffinz_: so the way you decrypt is you can compute the discrete log with the private key but otherwise |
| 21:24:32 | justanotheruser: | maaku: theres the financial cryptography conference |
| 21:24:34 | fagmuffinz_: | Could someone give me a link to this trapdoor I keep hearing about? |
| 21:24:44 | justanotheruser: | http://fc14.ifca.ai |
| 21:24:59 | justanotheruser: | fagmuffinz_: It has to do with asymmetric signatures. |
| 21:25:07 | justanotheruser: | ;;google trapdoor cryptography |
| 21:25:08 | gribble: | Trapdoor function - Wikipedia, the free encyclopedia: ; rsa - What is the meaning of "trapdoor" in cryptography ...: ; rsa - What is a trapdoor permutation? - Cryptography Stack Exchange: (1 more message) |
| 21:25:25 | fagmuffinz_: | Oh |
| 21:25:41 | fagmuffinz_: | K, that's fine. Just didn't know what "trapdoor" specifically meant |
| 21:26:21 | adam3us: | fagmuffinz_: pallier trapdoor is unusual in providing a trap door discrete log, usually discrete log crypto systems just work around the non-trap door nature, by knowing existentially the discrete log by having set it up; pallier allows computing it |
| 21:26:30 | fagmuffinz_: | Are there other kinds of asymmetric encryption that don't involve "trapdoors?" |
| 21:26:51 | fagmuffinz_: | Time for me to do some reading =] |
| 21:26:59 | maaku: | eh.. not really. that's just a single day workshop run by non-bitcoin people |
| 21:27:16 | justanotheruser: | fagmuffinz_: In asymmetric cryptography you shouldn't be able to get the private key from the public key. The function to get the public key from the private key is the trapdoor (because you can't go back) |
| 21:27:17 | maaku: | i probably only have funds for one trip this year and want to make it count :\ |
| 21:28:01 | justanotheruser: | maaku: I agree (12:33:33 PM) justanotheruser: Seems like a bunch of PhDs are going to explain bitcoin to the bitcoin devs |
| 21:28:22 | adam3us: | maaku: i guess you can get to the san jose one being local to u, plus one other. |
| 21:28:25 | fagmuffinz_: | I understand that justanotheruser |
| 21:28:43 | fagmuffinz_: | Just didn't know terminology - thanks though |
| 21:28:49 | justanotheruser: | yep no problem |
| 21:28:50 | adam3us: | maaku: i was thinking a wizards only "conference" aka a bunch of wizards and a lot of white boards |
| 21:28:57 | maaku: | adam3us: there's another san jose one? |
| 21:29:03 | fagmuffinz_: | I would pay for a plane ticket to that |
| 21:29:15 | justanotheruser: | adam3us: what's the san jose one? A meetup or a conference? |
| 21:29:19 | adam3us: | maaku: i dont know how it works, is it always in san jose? or does it move around the us? |
| 21:29:48 | adam3us: | justanotheruser: last april was the first one i went to so i am not in the loop, just perhaps incorrectly assumed the main one would be in san jose each year |
| 21:30:08 | maaku: | as far as I can figure out from google that was a one-time thing |
| 21:30:20 | maaku: | i'm not involved with the foundation though, which is why i asked |
| 21:30:35 | justanotheruser: | I'm interested in going to a bitcoin conference this year, what usually happens there? New ideas are talked about? |
| 21:31:11 | fagmuffinz_: | adam3us: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B473A49B56321FCEF247063B856A1751?doi=10.1.1.8.5384&rep=rep1&type=pdf this? |
| 21:31:27 | maaku: | if it was happening again in may I would assume there'd be announcements & calls for speakers by now... |
| 21:31:39 | adam3us: | maaku: me either. but what about a wizards only mini-conf with no registration fees (at cost for space)? wizards mostly go to like sit on the edges and talk to each other and scoff at the incorrectness of the presenters at anything semi-tech |
| 21:31:56 | fagmuffinz_: | ^ |
| 21:32:25 | maaku: | adam3us: sure that'd be fun and I'd go to that |
| 21:32:37 | maaku: | but i'm asking more because I have talks I'd like to give to the wider bitcoin audience |
| 21:32:42 | adam3us: | adam3us: y'all could come to malta, maybe the flights wouldnt be so bad out of season. the hotels are cheap out of season. |
| 21:32:56 | adam3us: | maaku: if you're talking some places will pay your flights i think |
| 21:33:10 | maaku: | i'm still up for an iceland meetup if people want to do that :) |
| 21:34:39 | adam3us: | maaku: note iceland not good out of season.. my wife's niece went there and lost lots of $ for damaged rental car (not insured for such things) storm with like big rocks flying by! smashed window, tow, undrivable in the weather conditions |
| 21:38:07 | adam3us: | maaku: plus could snag a visit to the btc mining data center running on geothermal and "open the window" cooling |
| 21:49:54 | BlueMatt: | maaku: adam3us duke conference! |
| 21:50:45 | BlueMatt: | (I'm trying to get together a wizards meetup where wizards are essentially just their own conference but give one or two talks to people |
| 21:51:20 | adam3us: | fagmuffinz_: http://en.wikipedia.org/wiki/Paillier_cryptosystem has link to the paillier's own paper. damgard-jurik also simplified it |
| 21:54:09 | adam3us: | BlueMatt: yeah i'm pumping malta as a location :) actually i bumped into the FC organizer guy ray hirschfield at the amsterdam btc conf and he was suggesting malta as next location after bahamas i think 2015. |
| 21:54:46 | adam3us: | BlueMatt: tho i realize thats more flight expensive for more people. some of the other costs might balance it. |
| 21:55:55 | BlueMatt: | adam3us: well, a conf for bitcoin is being organized at duke anyway, so I figure I'll steal some of their money and put it towards wizard-flights |
| 21:56:40 | andytoshi: | you'd think wizards would be able to fly of their own accord.. |
| 21:56:48 | andytoshi: | maybe we could add something to the blockchain to enable that :) |
| 21:57:36 | adam3us: | BlueMatt: oh ic its another university in the same state as unc (i am limited at times in finer points of us geography so missed the connection) |
| 21:57:46 | nsh: | i think you have to enable flying via a separate protocol layer built on top of the blockchain andytoshi |
| 21:57:55 | nsh: | let me set up an exodus address |
| 21:58:52 | BlueMatt: | (not a big conf, but like a local one) |
| 21:59:37 | adam3us: | andytoshi: oh noes, exodus. pump & dump. stop!! but yes it is a curious effect that $12 bil long term partly depends on fixing some non-trivial ideas that wizars seem to be the most likely to figure out, and yet many cant afford a flight, or understandably not inclined to take $2k out of their own hard earned $ to donate to it. |
| 22:00:52 | adam3us: | andytoshi: seems like a snowcrash hiro protagonist problem (wealthy by brownie points on the metaverse but penniless in meatspace) |
| 22:01:17 | warren: | meatcoins |
| 22:01:18 | andytoshi: | * andytoshi has snowcrash on his HDD, but still hasn't read it.. |
| 22:01:26 | BlueMatt: | adam3us: yea |
| 22:01:37 | warren: | andytoshi: read "The Great Simoleon Caper" first, prequel |
| 22:02:09 | andytoshi: | warren: will do |
| 22:02:20 | warren: | then The Diamond Age |
| 22:02:50 | andytoshi: | does cryptonomicon fit into this ordering? |
| 22:04:16 | warren: | no |
| 22:04:44 | andytoshi: | ok, thx |
| 22:05:00 | adam3us: | warren: someones read his stephenson :) man i gotta read the ones i missed some time. but bitcoin draw is stronger. eat. sleep. bitcoin. |
| 22:05:39 | andytoshi: | warren: thanks a ton, i have 23 books by stephenson on my system, haven't read one :P |
| 22:06:07 | gmaxwell: | if you hold the meetup around DC maybe I can get stephenson to show up? :P |
| 22:06:10 | warren: | apparently I'm supposed to read something called HPMOR but I refuse. |
| 22:06:32 | andytoshi: | warren: you should, it's good fun |
| 22:18:40 | andytoshi: | so, a few days ago tholenst was asking about script extensions to allow outputs with rules like "cannot be spent unless (a valid signature is provided AND blockheight >= 300000) OR (some proof that txin XYZ was double spent is provided)" |
| 22:19:00 | andytoshi: | what he proposed was pretty powerful and it was easy to think of outputs which interacted very badly with reorgs, hurting fungibility |
| 22:19:39 | andytoshi: | but i think, adding a single op FAIL_IF_BLOCKHEIGHT_LESSTHAN [minimum height] would be safe across reorgs |
| 22:19:48 | andytoshi: | am i right? |
| 22:21:20 | andytoshi: | the idea is, once an output can be spent, nothing should change to make it unspendable, otherwise a reorg could invalidate a huge swath of transactions ... but change in the opposite direction (unspendable output suddenly becomes spendable) is safe |
| 22:21:27 | gmaxwell: | andytoshi: perhaps safe enough. technically the chain can shrink. |
| 22:22:58 | andytoshi: | gmaxwell: right. absent deliberate effort this is insanely unlikely though |
| 22:24:09 | andytoshi: | wait, no, it's exactly as likely as somebody one block behind pulling one block ahead |
| 22:29:13 | andytoshi: | ok, whenever tholenst shows up again i'll mention this .. it would be a cool idea for an alt if you could post collateral against double-spends |
| 22:35:27 | Taek: | could you use the bitcoin script + contracts to create a distributed exchange between multiple cryptocurrencies? |
| 22:35:33 | Taek: | Taek is now known as Taek42 |
| 22:35:48 | maaku: | andytoshi: it's possible for an old fork to overtake the main chain |
| 22:36:59 | andytoshi: | for the chain to shrink does a difficulty retarget need to be involved? |
| 22:38:10 | maaku: | to shrink, yes, but it doesn't have to shrink to cause reorg problems |
| 22:38:33 | maaku: | er, n/m |
| 22:38:42 | maaku: | what i was thinking of is really a double-spend |
| 22:39:18 | andytoshi: | maaku: ah, ok |
| 22:39:18 | maaku: | andytoshi: but isn't that what nLockTime is? |
| 22:39:45 | andytoshi: | maaku: nLockTime makes the output 'unreal' until a certain time |
| 22:39:59 | andytoshi: | in the sense that if i make an nLockTime transaction, i can double-spend that |
| 22:40:19 | andytoshi: | what this does is effectively make an nLockTime transaction that gets mined, so it's impossible to double-spend it |
| 22:40:48 | maaku: | ok i see, the restriction is triggered on the spend |
| 22:40:58 | maaku: | you're looking to lock outputs for a certain amount of time |
| 22:41:09 | andytoshi: | exactly, which is why it's a script opcode rather than some property of the transaction |
| 22:50:29 | Luke-Jr: | hmm |
| 22:50:41 | Luke-Jr: | someone should do a scamcoin generator that doesn't need to compile anything |
| 22:50:48 | Luke-Jr: | just find the constants and hack the binaries |
| 22:50:49 | Luke-Jr: | :D |
| 22:58:12 | Emcy: | wow someone put "please consider donating" and address in the torrent comments for bootstrap.dat |
| 22:58:30 | Emcy: | that strikes me as really low for some reason |
| 23:00:14 | nsh: | agreed |
| 23:01:22 | Emcy: | speaking of is it time for a new bootstrap yet? |
| 23:01:30 | midnightmagic: | 13:59 < adam3us> andytoshi: seems like a snowcrash hiro protagonist problem (wealthy by brownie points on the metaverse but penniless in meatspace) |
| 23:01:33 | midnightmagic: | har har. |
| 23:01:36 | Emcy: | this one from august is still seeding pretty good |
| 23:09:34 | michagogo|cloud: | Emcy: personally, I would say an updated bootstrap would not be a bad thing. I think jgarzik maintains it, though, so I'd ask him what he thinks |
| 23:10:05 | michagogo|cloud: | (Though this is a bit ot for here, I think) |
| 23:12:06 | maaku: | iirc he updates it with each new checkpoint |
| 23:12:11 | maaku: | we haven't had a new checkpoint since august |
| 23:14:58 | michagogo|cloud: | maaku: yeah, though it doesn't need to be like that |
| 23:19:29 | maaku: | yeah |
| 23:19:48 | maaku: | regular 3 month or six month updates would be nice |
| 23:46:24 | petertodd: | andytoshi: s/FAIL_IF_BLOCKHEIGHT_LESSTHAN/OP_CHECKLOCKTIME/ |
| 23:47:25 | andytoshi: | hmmm |
| 23:48:10 | andytoshi: | are you just renaming this or changing the behavior? |
| 23:48:54 | petertodd: | andytoshi: pointing out how you should implement it :) |
| 23:49:05 | petertodd: | andytoshi: I actually did implement that as an exercise a few months back |
| 23:49:21 | petertodd: | andytoshi: and actually, OP_CHECKLOCKTIMEVERIFY to be exact |
| 23:49:32 | petertodd: | (need that to be a soft-fork nop) |
| 23:49:40 | andytoshi: | petertodd: gotcha |
| 23:50:42 | gmaxwell: | I kinda wish the locktime time of reference was the median of last 11 time rather than the current block. |
| 23:50:56 | andytoshi: | petertodd: you'd then want nLockTime transactions to be standard, and nLockTime ignored unless it appears in script? |
| 23:51:06 | andytoshi: | unless OP_CHECKLOCKTIMEVERIFY appears in script* |
| 23:51:13 | gmaxwell: | andytoshi: the locktime is already ignored when the sequence number is maximal. |
| 23:51:19 | petertodd: | andytoshi: ? no they're two separate things |
| 23:51:52 | petertodd: | andytoshi: OP_CHECKLOCKTIMEVERIFY takes a number on the stack and compares it with the IsFinal() method, failing the tx if false, leaving the number on the stack if true |
| 23:54:51 | andytoshi: | petertodd: i'm not clear -- how do miners know whether they should bother mining a transaction? |
| 23:55:09 | andytoshi: | if you have an nLockTime'd transaction today everyone will ignore it if it doesn't unlock for a long time |
| 23:55:25 | andytoshi: | but what i want is, the script can override the nLockTime in some cases (eg a proof of double-spend is provided) |
| 23:56:17 | petertodd: | andytoshi: ah, I get you, yeah you can do that with CHECKLOCKTIMEVERIFY too, but only in the sense that the transaction can't be mined because the txout it's tryng to spend isn't unlocked yet |