| 01:04:15 | super3: | the standard size of a bitcoin transaction is ~500 bytes correct? |
| 01:04:46 | sipa: | s/standard/average/ ? |
| 01:05:08 | super3: | average |
| 01:05:35 | super3: | i'm going off this: https://en.bitcoin.it/wiki/Transaction_fees |
| 01:06:12 | sipa: | ;;nethash |
| 01:06:13 | gribble: | 151332404.533 |
| 01:16:19 | wallet421: | wallet421 is now known as wallet42 |
| 01:52:48 | justanotheruser: | I would like to discuss outsourcable problems. If we have less outsourcable problems then mining pools have less power. Block validation is the main outsourcable problem today, however, in the future we may have ZKPs of the block. Because it is faster to validate a ZKP than to validate a block, blocks with ZKPs will have the advantage of faster propogation time and and lower stale rate. Because ZKPs of the utxo will have ... |
| 01:52:54 | justanotheruser: | ... a lower stale rate than a traditional block, equilibrium will force miners to make ZKPs along with their block. This is why I think that that problem needs to be made un-outsourcable as well. Do you agree or disagree that ZKP generation and UTXO querying should eventually be part of the PoW? If you agree, what else should be done to prevent outsourcing and weaken mining pool centralization? |
| 02:13:53 | Emcy: | is there a danger that making mining un-outsourcable will just have pool ops saying "fuck it pools closed" and mine all in house instead, massively increasing physical/juristictional centralisation of mining |
| 02:14:19 | Emcy: | and have pool hashers saying "fuck it, this thing is going on ebay ill buy from now on" |
| 02:23:39 | amiller: | i think i like this train of thoguht but dont follow it yet. |
| 02:24:41 | amiller: | yeah a snarked'up concise proof about a series of blocks can be faster to validate than downloading an actual whole block |
| 02:25:17 | amiller: | "zero knowledge" proofs of work and "succinct" proofs of work are kind of orthogonal concerns though |
| 02:25:49 | amiller: | it's the ability to make a zero knowledge proof that makes its non-outsourceable/stealable in my sort of schemes, but you can have a proof that's succinct but not zero knowledge so that's not the same |
| 02:28:51 | Eliel: | Emcy: none of the changes being discussed make pooled mining impossible. They won't prevent pools from doing the thing they were made to do. It'll still be possible to pool together to reduce variance in payments. |
| 02:29:39 | Eliel: | The only thing that would change is that the pool would no longer have control over anything else but the division of profits from the blocks found by the pool's miners. |
| 02:30:13 | Emcy: | i thought that was a solved problem |
| 02:30:13 | amiller: | Eliel, what changes being discussed are you talking about |
| 02:30:17 | Emcy: | with gbt |
| 02:31:27 | amiller: | there's changes that make decentralized pools more attractive and solomining more attractive, and changes that make centralized pools or cloud mining less attractive, or both |
| 02:33:37 | Eliel: | amiller: as long as it's possible to use lesser successes in the mining process to prove you're working, a pool can be used to reduce variance. That's pretty much the main point. |
| 02:35:09 | amiller: | ok, well the point of the "nonoutsourceable puzzle scheme" i'm evangelizing is that it prevents doing what you said |
| 02:35:36 | amiller: | (not that that's the only change being discussed) |
| 02:35:44 | Emcy: | so....no comment on whether that would make the mining warehouses even worse? |
| 02:36:03 | Emcy: | already with cex the pool is a sideshow |
| 02:36:06 | Eliel: | amiller: oh, then I was wrong I guess. |
| 02:36:21 | amiller: | Emcy, it's a complicated argument because good incentive models are hard to come by, but with the right additional change to the payoff structure, it *also* prevents cloud mining. |
| 02:36:48 | amiller: | if you just use the pool-busting puzzle, and don't change anything else, yeah that would totally be a horrible thing and drive everyone straight to cloud mining which is even worse. |
| 02:37:18 | Emcy: | do you mean s/prevents/disincentiveses |
| 02:37:24 | Eliel: | Emcy: Well, GBT theoretically fixes the problem... but only if pools start supporting it. And that's the thing. They don't really have too much incentive to do so. |
| 02:37:45 | justanotheruser: | Emcy: There will be another ASIC hurdle if the PoW is changed, but I don't think it would make mining warehouses worse |
| 02:38:12 | Emcy: | i dont think were talking about changing the pow |
| 02:38:16 | Emcy: | are we? |
| 02:38:37 | Eliel: | Emcy: that's what the topic was about when you asked. |
| 02:38:46 | justanotheruser: | Emcy: are you referring to my premise that the PoW should include ZKP creation and UTXO querying? |
| 02:38:55 | Emcy: | oh |
| 02:38:59 | super3: | hey amiller |
| 02:39:05 | Emcy: | so doing the ZKP thing would be a change to pow? |
| 02:39:16 | amiller: | Emcy, yes prevents = decentivizes in my world (sorry it's not stronger than that!) |
| 02:39:25 | justanotheruser: | Emcy: not unless you force the PoW to involve creation of ZKPs |
| 02:39:37 | amiller: | hi super3 |
| 02:39:43 | justanotheruser: | you can have ZKPs of the UTXO without a PoW change |
| 02:39:53 | Emcy: | ok |
| 02:40:05 | Emcy: | i dont see the pow getting changed at this point |
| 02:40:12 | justanotheruser: | But that means that you have an outsourcable problem |
| 02:40:12 | Emcy: | lest for some sort of super emergency |
| 02:41:01 | justanotheruser: | I could see it happening, but it is probably unlikely |
| 02:41:14 | justanotheruser: | I think adding those two changes to the PoW would be a softfork |
| 02:41:21 | Emcy: | amiller yes thats about all you can do |
| 02:41:23 | Eliel: | Emcy: I don't think it's practically possible to change the PoW without an emergency forcing it. |
| 02:41:29 | super3: | so lets say you did technically disincentive with non-outsourceable puzzles(NOPs?) |
| 02:41:31 | amiller: | adding zkp is not a softfork hcange.. |
| 02:41:40 | Emcy: | but i think ive mentioned before i dont think you can rely on pure economic rationality to fix things |
| 02:41:47 | justanotheruser: | amiller: adding zkp isn't a fork at all |
| 02:42:10 | super3: | i feel like large mining pools wouldn't want to switch |
| 02:42:13 | justanotheruser: | adding zkp to the PoW is a softfork afaics |
| 02:42:46 | amiller: | justanotheruser, i think i see what you're saying... it has nothing to do with the zk part but the succinct part, you should just say snark |
| 02:43:00 | justanotheruser: | amiller: fair enough |
| 02:43:19 | amiller: | doesn't let the person who solves the puzzle "steal" it in any way (that's something you can do with ZK), but you're saying rahter than a miner waiting to read all the blocks, he just checks some succinct digest that the blocks are correct |
| 02:43:27 | amiller: | and that alone might improve decentralization? maybe |
| 02:43:39 | amiller: | super3, yeah i don't know about that it's a good question |
| 02:43:52 | amiller: | super3, maybe the individual members of a pool would all switch away from the pool though and switch to this |
| 02:44:09 | super3: | eh, there is a way you could do it |
| 02:44:23 | justanotheruser: | amiller: well I assume a UTXO proof would be smaller than a block, therefore it should have a lower stale rate |
| 02:44:26 | Eliel: | super3: current miners can't prevent the mining algorithm from changing. It's enough to convince a super majority of users. There will be miners ready to mine with a new algorithm, no question about it. |
| 02:45:02 | Emcy: | that would be a huge ass window of attack for bitcoin though |
| 02:45:04 | justanotheruser: | super3: large mining pools certainly wouldn't want to change |
| 02:45:17 | super3: | i mean either way its not going to be a fun ride |
| 02:45:18 | Emcy: | like, lets all go back to 2010 level security |
| 02:45:48 | Eliel: | Emcy: that depends on the difficulty level the new algo is started with. |
| 02:45:49 | Luke-Jr: | super3: NOPs would be a super stupid idea |
| 02:45:49 | super3: | so the question is how do you incentize the transition |
| 02:45:58 | Luke-Jr: | you don't |
| 02:46:26 | justanotheruser: | Eliel: It can probably be designed so the difficulty doesn't change much |
| 02:46:45 | Eliel: | justanotheruser: yes, that's my point. |
| 02:47:17 | justanotheruser: | oh right, missed Emcys comment |
| 02:47:59 | gmaxwell: | Eliel: saying "pools have to support it" is a bit history blind, quite a few pools did support it. cgminer wouldn't for a long time. Support has since died off somewhat. |
| 02:48:40 | super3: | well any algorithm that has disincentives for centralization |
| 02:49:04 | amiller: | Luke-Jr, lol. |
| 02:49:05 | Eliel: | gmaxwell: yes, the incentive to support it isn't there. |
| 02:50:17 | justanotheruser: | heh, I wonder how much you would have to bribe mining pools for them to accept a softfork removing all outsourcable problems |
| 02:50:23 | gmaxwell: | Eliel: as opposed to what? I mean— it's built into bitcoind, and it's considerably simpler to support for a pool from a straight software perspective. |
| 02:51:02 | gmaxwell: | justanotheruser: because you're investing in cloud mining? and softfork? huh? you're making no sense? |
| 02:51:57 | justanotheruser: | gmaxwell: if the PoW had UTXO querying, you would have to get miner support for a softfork, correct? And that support can probably be bought, correct? |
| 02:52:15 | super3: | justanotheruser: bought with what? |
| 02:52:20 | justanotheruser: | super3: bitcoins |
| 02:52:28 | super3: | justanotheruser: from who? |
| 02:52:30 | Luke-Jr: | justanotheruser: UTXO querying is outsourcable |
| 02:52:42 | justanotheruser: | super3: donors |
| 02:53:14 | super3: | so basically a bitcoin bailout? |
| 02:53:38 | justanotheruser: | Luke-Jr: yeah, but why would you outsource it if the outsourcing was a significant bottleneck on your hashing? |
| 02:53:48 | Luke-Jr: | justanotheruser: it isn't |
| 02:54:04 | justanotheruser: | super3: I wouldn't use those terms to describe it myself |
| 02:54:20 | justanotheruser: | Luke-Jr: why not? Light can only travel so fast |
| 02:54:32 | Luke-Jr: | justanotheruser: … |
| 02:54:51 | gmaxwell: | justanotheruser: you're not making any sense though, like layers of confusion. UTXO querying is prefectly outsourcable (dunno what word you actually mean), and if you did have something that broke outsourcing pools could have _zero_ role in deploying it, since they'd have no participation in the new system. |
| 02:54:59 | Emcy: | it would be spun as a bitcoin bailout so hard |
| 02:55:00 | Emcy: | oh the hilarity |
| 02:55:27 | gmaxwell: | justanotheruser: and it is far from clear the breaking outsourcing would be desirable at all because it would enormously incentivize cloud mining which is already much larger of a problem. |
| 02:55:28 | super3: | miners. too big to fail. |
| 02:56:25 | Emcy: | i lvoe how it always comes down to we have to pay a bunch of guys not to be tossers |
| 02:56:32 | Emcy: | lessig is trying that with congress too |
| 02:57:01 | amiller: | it's not worth even calling it "break outsourcing" if it doesn't also disincentivze cloud mining |
| 02:57:06 | amiller: | this terminology admittedly sucks |
| 02:57:09 | gmaxwell: | Emcy: would you please not be stupid? |
| 02:57:26 | Emcy: | :( |
| 02:57:33 | justanotheruser: | gmaxwell: I must be missing something. If you have to perform a UTXO query every N hashes, and it is faster to do the UTXO query locally, then outsourcing the querying to some mining pool hosted 500 miles away would be a bottleneck. |
| 02:58:09 | amiller: | i shouldn't have even brought up nonoutsourceable puzzles thouhg, i think justanotheruser just wanted to talk about UTXO queries and compressed snark block proofs |
| 02:58:41 | gmaxwell: | justanotheruser: all thats doing is changing the POW function. So now you have to have different hardware to mine. |
| 02:59:04 | gmaxwell: | (assuming N is low enough that it makes sense) |
| 02:59:08 | justanotheruser: | gmaxwell: right, but it also means that you have to have the blockchain and you can validate blocks yourself much cheaper |
| 02:59:21 | Luke-Jr: | justanotheruser: but you can still outsource it to anyone with the UTXO |
| 02:59:23 | gmaxwell: | justanotheruser: who says your validating anything? much cheaper than what? |
| 03:00:09 | gmaxwell: | Than the current _$1_ in diskspace it costs to have the blockchain when you're not forced to make artifical queries against it? Than the $.05 required for a full validating node on the existing system? |
| 03:00:14 | justanotheruser: | gmaxwell: it is much cheaper to validate blocks when every miner is forced to have the UTXO set than if not every miner has the UTXO set |
| 03:00:44 | justanotheruser: | because the cost of storing the UTXO is included in finding the equilibrium |
| 03:01:26 | Luke-Jr: | … |
| 03:01:35 | gmaxwell: | justanotheruser: all I can see is a cost increase there, now participants have to do tends of gigabits of non-productive utxo/queries per second. |
| 03:02:18 | gmaxwell: | and cost increases for all other nodes, since you now have to carry around query proofs of some kind. |
| 03:02:44 | gmaxwell: | probably on the order of a minimum of a 4x bandwidth increase for SPV nodes. |
| 03:02:45 | justanotheruser: | gmaxwell: I'll give you that 2nd point, it does hurt full nodes |
| 03:02:52 | justanotheruser: | and SPV nodes |
| 03:03:20 | gmaxwell: | justanotheruser: And for what? I think you're blindly addressing a symptom. No one uses a pool because $0.05 in storage for a utxo set is a big consideration. |
| 03:03:21 | justanotheruser: | however, if all hashers have the UTXO, it is significantly cheaper to see if your mining pool is misbehaving |
| 03:03:40 | gmaxwell: | justanotheruser: no one cares, there are lots of stateless checks you can do, but people largely do not do them. |
| 03:04:54 | justanotheruser: | gmaxwell: so you are saying that the reason use GHash isn't because they don't require you to have the blockchain, but some other reason? |
| 03:06:05 | Emcy: | it could be as simple as their website just looks all official and stuff imo |
| 03:06:08 | gmaxwell: | Most of ghash's hashrate is cloud mining (the exact figure is indeterminable). |
| 03:06:53 | gmaxwell: | Emcy: for the longest time there was no way on the ghash website to even use it. To get access you had to first sign up at cex.io. |
| 03:06:59 | justanotheruser: | that was just an example. I'm referring to centralized pools that don't require you to have the UTXO in general |
| 03:07:08 | Emcy: | hm ok |
| 03:07:33 | gmaxwell: | justanotheruser: the reason people use them is to pool income to reduce variance, and because they believe their returns are increased when they are on the 'fastest' pool. |
| 03:08:02 | gmaxwell: | I have _never_ heard a miner talk about operating costs when talking about their decision to use some pool vs solo mine. |
| 03:08:20 | justanotheruser: | gmaxwell: I see. I suppose my premise is off then. |
| 03:09:36 | gmaxwell: | it's as simple as— when people no longer were finding a block a day on convention hardware, centeralized pools were created. Some of the earliest ones were completely insecure (e.g. paying people based on time spent connected lol). They just tapped into the existing function calls being dispatched to the internal miner. |
| 03:09:58 | gmaxwell: | If it had occured to someone that you could pool for shared income without handing over control at that time, they didn't mention it to anyone else. |
| 03:10:19 | justanotheruser: | lol really? pptc |
| 03:11:11 | justanotheruser: | gmaxwell: do you think treechains will decentralize mining more as a side effect? |
| 03:11:32 | justanotheruser: | at least mining pools |
| 03:11:59 | gmaxwell: | I can't figure out what treechains is, it doesn't make much sense to me... |
| 03:12:44 | gmaxwell: | (or at least to the extent it makes sense to me it doesn't seem worthwhile in the slighest— e.g. results having to hand people oob payment data which is quasi-exponential in size.) |
| 03:14:05 | gmaxwell: | it's really hard to say anything about the future of mining, things are in a very odd state. |
| 03:14:36 | gmaxwell: | There is a nontrivial amount of people involved who have zero or only a dim idea that mining plays any role in the system other than being a lottery for new bitcoins |
| 03:14:44 | tacotime: | gmaxwell: afaik treechains is a blockchain of binary trees with each level having half the difficulty of the previous level, with some kind of referencing between these nodes on trees, and which must use some kind of deterministic algorithm to figure out when a given tx at some level occurred in well defined temporal space. |
| 03:14:53 | tacotime: | the last point is always what baffled me. |
| 03:16:17 | tacotime: | (if everything is being attached in an unpredictable manner temporally, how to figure out the precise ordering of tx that appear) |
| 03:16:54 | justanotheruser: | Is there a treechains post or whitepaper? All I know about it is from the greenaddress.it blog :O |
| 03:16:57 | gmaxwell: | tacotime: The first part buys you nothing unless you assume participants will not view everything... and then it's not clear how to produce compact proofs that a payment to someone is valid. (PT calls this 'linear' size, but I think thats misleading. If you extract the history of most coins in bitcoin it's enormous, and exponential in the age of the coins due to splits and merges) |
| 03:18:27 | tacotime: | yeah. i don't really know. certainly it would seem that a proof would be much more computationally intensive, not to mention storage overhead. |
| 03:18:43 | justanotheruser: | oops, found it https://github.com/petertodd/tree-chains-paper |
| 03:19:34 | tacotime: | i think there was quite a large post about it in the mailing list a long time ago too. |
| 03:19:48 | justanotheruser: | yes, I have found that as well http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04388.html |
| 03:20:47 | gmaxwell: | There was. I don't mean that I don't understand the words, I think I do as anyone else. I don't understand why anyone would see it as attractive... esp with how really hard it's been to get people to keep their transaction metadata out of band already. |
| 03:21:04 | gmaxwell: | er s/do as/do as much as/ |
| 03:26:29 | gmaxwell: | justanotheruser: in any case, most of the centeralization today in bitcoin seems to be driven out forces like vertical integration (people funding mining who actually have an explicit goal of controlling some huge fraction of the hashrate, sometimes because they suffer the non-linear returns misunderstandings), and things like a majority of all mining hardware companies being business failures and ripping people off. |
| 03:27:15 | gmaxwell: | so you get screwed up situations like savvy buyers will not buy hardware, and irrational people wanting to centeralize mining because they think it will increase their returns. |
| 03:28:19 | gmaxwell: | and the only seemingly "low risk" way to do anything with mining is to buy into these cloud operations, though some have been ponzi operations in the past and we'll probably find that more are in the future. |
| 03:35:40 | Emcy: | do people really set out to warehouse mining in a huge scale for themselves whilst not understanding that having all the power in one place doesnt neccesarily get you more coin |
| 03:36:50 | gmaxwell: | Yes. |
| 03:36:56 | Emcy: | i mean i understand pool hashers doing what they do because they misunderstand pools, and i thought that pool ops/cloudhashers were the ones taking advantage of that with better information |
| 03:36:59 | super3: | well in the early days some people just want to write off mining equipment |
| 03:37:32 | super3: | if cloud mining was really profitable then why let the users take all the profit? |
| 03:37:48 | gmaxwell: | super3: ... because they're taking the risk and giving you money up front. |
| 03:37:48 | Emcy: | yes i suppose it really is that simple |
| 03:37:59 | super3: | cloud mining as a business model is great because you offload all the risk to the end user |
| 03:39:04 | super3: | pretty morally grey area |
| 05:00:13 | dsnrk: | grey? nothing grey about it. |
| 09:58:06 | petertod1: | gmaxwell: my linear size proofs for tree chains use the NI trick i explained to you months ago to o ly pick one coin path history and make fraud economically non-rational on average |
| 09:58:57 | petertod1: | gmaxwe: it *is* a linear scaling, so stop tellig people otherwise, or show that it doesnt work |
| 10:00:59 | petertod1: | gmaxwell: like i explained on the list, a token transfer scheme is the obvious versiom of linearlu scalimg history |
| 10:14:04 | petertod1: | gmaxwell: also, non-linear ROI on mining isnt a misundersranding, its a fact, one that is made significantly worse by merge mined sidechains |
| 10:14:33 | petertod1: | * petertod1 cant type on an android |
| 10:37:59 | nsh: | petertod1, how does merge-mining affect the linearity of return? |
| 10:38:18 | nsh: | can this be modeled rigorously? |
| 13:02:47 | hearn: | gmaxwell: do you think there's a way to do the merkle tree exchange audit protocol without revealing the total size of deposits at all? i am pretty sure the answer is "no" but was asked this recently |
| 13:15:13 | e4xit_: | e4xit_ is now known as e4xit |
| 13:18:21 | Dr-G3: | Dr-G3 is now known as Dr-G |
| 13:19:23 | jgarzik: | hearn, it wasn't necessarily a merkle tree exchange, but IIRC there was some ZK way of auditing bitcoin banks |
| 13:19:30 | jgarzik: | jgarzik is now known as home_jg |
| 13:20:41 | hearn: | i think the roadmap for combining ZKPs with the merkle tree protocol is pretty clear, but it still requires revealing the total amount on deposit at the exchange |
| 13:21:19 | hearn: | i'm not sure if there's a way to avoid that (not sure it's important either) |
| 13:48:20 | nsh: | hearn, that's the kind of figure the public arguably ought to know wrt exchanges |
| 13:50:01 | sipa: | i'm not convinced |
| 13:50:36 | sipa: | what people actually care about is whether 1) the exchange has their money 2) that it's not 'shared' with anyone else's balance |
| 13:52:26 | hearn: | nsh: possibly. it's a privacy leak though (for the exchange) |
| 13:53:29 | nsh: | * nsh nods |
| 13:53:54 | hearn: | e.g. if the figure is much higher than expected it may lead to extortion attempts |
| 13:54:02 | hearn: | (the achilles heel of any bitcoin user but especially institutions) |
| 13:57:01 | nsh: | it'd be nice to have actual data (statistics, etc.) of extortion risk. it seems somewhat romanticised and overemphasised at time |
| 13:57:27 | nsh: | at the same time, ddos rackets do exist and aren't likely to go away soon |
| 13:57:39 | fanquake_: | fanquake_ has left #bitcoin-wizards |
| 13:57:40 | zooko`: | zooko` is now known as zooko |
| 13:58:14 | nsh: | (and people who have been successfully extorted are likely to be reticent about reporting) |
| 13:59:21 | wumpus: | still, it is a valid reason for not wanting to report the total amount |
| 14:06:06 | gmaxwell: | hearn: the merkle tree style proof could be evaluted inside a ZKP— basically it looks just like a zerocash proof. (also a merkle tree membership proof) |
| 14:08:51 | hearn: | gmaxwell: well, what i've been telling people is that basically to get confidence and usage you need to have some kind of javascript that checks the users own merkle branch, then auditing-the-audit becomes "check some js is loaded" or "use a browser extension that checks some specific js was loaded and run" |
| 14:09:01 | hearn: | otherwise the problem is, nobody is going to check their branch |
| 14:09:22 | hearn: | nsh: e.g. http://gizmodo.com/pizza-shop-were-being-extorted-for-bitcoin-whats-a-bi-1598785564 |
| 14:09:31 | hearn: | nsh: i see this problem only getting nastier with time |
| 14:10:19 | hearn: | so far the worst is still cryptolocker and imitators i think, though |
| 14:10:29 | hearn: | gmaxwell: so i'm not sure how to do ZKP in that context |
| 14:10:30 | home_jg: | home_jg is now known as jgarzik |
| 14:10:32 | gmaxwell: | That always remains, otherwise the site proves that it's solvent on a set of 0 user balances and without the user input thats not obviously wrong |
| 14:10:44 | gmaxwell: | but the total balance could be hidden |
| 14:11:58 | hearn: | gmaxwell: what does the merkle tree look like in that case? i thought each node contained the sum(balance) of the child nodes? |
| 14:13:43 | gmaxwell: | H(sum_balance||nonce) and you have a ZKP riding along the side, which works almost exactly like a zerocash spend, which says that the signer knowns a nonce for which the balances sum up. |
| 14:15:32 | gmaxwell: | so at the top of the tree where in the non-zk scheme you'd have the total assets under proof, in this you have the H(total|nonce) with a nonce known to the service. |
| 14:15:40 | hearn: | hm, right. i guess the zkp verifier would need a js version. or at least a c++ compiled to js version :) |
| 14:15:51 | gmaxwell: | yea. |
| 14:15:59 | hearn: | thanks |
| 14:16:44 | jgarzik: | I think failing to report the total amount is largely pointless. |
| 14:17:02 | jgarzik: | People tend to know or have a good guess, as users self-report and such reports gather over time. |
| 14:17:27 | jgarzik: | Either the users tend to want to know the total, or the universe self-reports a reasonable guesstimate anyway. |
| 14:17:52 | hearn: | very hard to know for sure what the distribution of balances amongst users is. and users probably have no interest in self reporting to find the total, i guess |
| 14:17:56 | hearn: | not much in it for them to do that |
| 14:18:46 | jgarzik: | hearn, I mean, through the normal course of talking about websites you use, sharing experiences, website bug reports, etc. Not explicit self-reporting practice, but more organic, unconscious self-reporting. |
| 14:19:13 | hearn: | maybe |
| 14:19:14 | jgarzik: | hearn, One could discern mtgox probably had "a lot" of bitcoin deposits based on user reports |
| 14:19:36 | jgarzik: | You don't know a specific amount, but you get an idea whether a site is holding $1m, $10m, $100m, .... |
| 14:19:38 | hearn: | right. but how much is "a lot"? i was pretty surprised to see bitstamp had such a huge amount on hand, especially given it was not so long after the collapse of gox |
| 14:19:56 | hearn: | i'd have thought (hoped) it'd be a smaller amount |
| 14:22:18 | gmaxwell: | jgarzik: What I was talking about was a scheme by which you could still be proving the amounts add up, without disclosing the total. Really disclosing the total is best, but its "commercial sensitive information", and so the disclosure is used as an excuse to not implement. |
| 14:27:23 | jgarzik: | About to update blockchain torrent. Anybody know of a good HTTP tracker or two? I only have UDP trackers listed. |
| 14:51:48 | gmaxwell: | ZKP-izing the balances removes that excuse. Creates a new one though— the required ZKP doesn't exist, but I'm hoping that when the zerocash examples are added to libsnark that should just be a fairly small amount of adaptation. |
| 14:52:18 | hearn: | yeah, we need more gadgets. way more. |
| 14:52:30 | hearn: | trying to do it with the current libsnark would be like trying to write an entire OS in assembler. |
| 14:53:13 | maaku: | hearn: done that, not fun (OS in assembler) |
| 14:53:59 | gmaxwell: | for a chip running at 1KHz in asic-emulation. :) |
| 14:55:10 | gmaxwell: | (libsnark is actually pretty fast, but doesn't seem like it once you calculate out an effective clockrate for your circuit. :P ) |
| 14:56:58 | hearn: | well, that's kind of a confusing way to put it, snark circuits aren't clocked. but i get what you mean |
| 14:57:56 | gmaxwell: | hearn: yes, it's a satisfaction, but it has a depth. So 40 seconds for a circuit with depth 10000 doesn't sound like an impressive clockrate! :) |
| 14:58:45 | hearn: | oh i see, you mean with tinyram. yes :) |
| 14:58:57 | hearn: | with depth ~= clock edge, it's comparable |
| 14:59:14 | hearn: | i guess the next wave of research will be how to parallelise it using gpus or cloud hardware |
| 14:59:21 | hearn: | and/or how to make really compact circuits :) |
| 14:59:32 | gmaxwell: | almost all the time is spend in the mult-exponentiation. |
| 14:59:56 | gmaxwell: | and its completely parallel, though there is a bunch of data which may get in the way of cloud-ing it. |
| 15:00:10 | gmaxwell: | s/spend/spent/ |
| 15:01:16 | gmaxwell: | the zkp for the balance side is easy— it really is just the zerocash membership proof with some small modifications. The other half of the proof (proving you can spend coins totaling some encrypted balance) will need secp256k1 point addition implemented inside the proof. But at least only that and not a full dsa verification. (using the ZKP-ECDSA blinding I came up with a while back) |
| 15:01:37 | hearn: | right, i remember |
| 15:02:12 | hearn: | i think the team said they'd be looking at doing crypto inside the proof as one of their next highest priorities |
| 15:02:19 | hearn: | along with a better PCP |
| 15:03:31 | gmaxwell: | * gmaxwell wishes he had this conversation about 10 minutes earlier... was just on the phone with someone who was doing work on signatures inside ZKP and forgot to ask about it. |
| 15:04:27 | hearn: | yeah well i told the people asking me about this that yes it is theoretically possible and practically possible maybe in 24 months, earliest. |
| 15:04:38 | hearn: | where 24 months was pulled out of thin air based on wild guesstimates |
| 15:06:37 | gmaxwell: | yea, thats a reasonable sandbagged number. Realistically I think there could be something tech demoable in a couple weeks if there were a couple people working hard on this specific thing... absent a bunch of interest it might take years. In the 24 months timeframe enough related things may get released that one of us does it 'on accident' along the way at some point with some probablity. |
| 15:08:12 | hearn: | i was thinking that libsnark seems to move pretty slowly, they're obviously still working through questions of commercialisation and the like. so it'll probably be some months before the needed code is available, a few more months before the right people find time to get a prototype really working, more months before it's documented well, usable, etc. then people need to learn to trust it, so that's more explanations that need to |
| 15:08:12 | hearn: | be written. etc. |
| 15:09:00 | gmaxwell: | fortunately the trust story on this is pretty good from a cryptographic perspective, if the snark is insecure all that happens is that someone can lie about their solvency proofs. |
| 15:09:11 | hearn: | yeah |
| 15:09:38 | hearn: | the exchange i was talking to saw it as a strictly additive thing. they still wanted a pillar of society to turn up and assert things seemed OK based on manual inspection too. |
| 15:09:46 | hearn: | it'll take time for people to learn to trust it, even if the maths is sound |
| 15:10:26 | gmaxwell: | I also think the existing libsnark is technically adequate for it, it's just an activation energy thing... right now you'd have to go do a by hand implementation of sha256, but it doesn't make sense to do that when they've supposidly already done this for zerocash. |
| 15:10:55 | hearn: | right |
| 15:11:21 | hearn: | i thought about it briefly for about 10 seconds and then realised the learning curve was so steep by the time i was making real progress, they'd probably have released their gadgets for it anyway |
| 15:15:36 | gmaxwell: | I've implemented sha256 before as a boolean circuit, but the style needed for this is pretty substantially different, ... there is a very cool way that libsnark lets you make circuits mixing both arithemetic and boolean parts, but using it effectively seems to have a pretty big learning curve. |
| 15:16:29 | hearn: | you mean the dual/packed words thing? |
| 15:16:47 | hearn: | i sent them a giant feedback email about the tutorial and they added a lot of extra comments as a result. |
| 15:16:56 | hearn: | more discussion of that technique was a part of it |
| 15:17:39 | hearn: | on the other hand, i was quite impressed at the quality of the code and the api, the tutorial app was also quite nice |
| 15:17:50 | hearn: | it's not some crappy academic code dump where indentation was clearly an afterthought, like some i've seen |
| 15:18:04 | gmaxwell: | yea, the dual words and the pack/unpack. It's basically a perfect fit for sha256, since rounds basically alternate between 32 bit adders and a bunch of bitops. |
| 15:19:16 | hearn: | perhaps the right place to start is with a dummy app that doesn't use real sha256, just a basic arithmetic operation that stands in for it, but that you can still hang the merkle tree summation structure around |
| 15:24:05 | hearn: | brb |
| 15:28:18 | gmaxwell: | Fair point, yea, the 'hash' could just be addition mod G2.order() or whatever the arithemetic adders due natively. |
| 15:33:26 | gavinandresen: | I really like this paper, points towards constant-time propagation of arbitrarily sized blocks: http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p218.pdf |
| 15:34:54 | gavinandresen: | (and no moon-math involved) |
| 15:39:12 | gmaxwell: | gavinandresen: the block network coding wikipage with a bunch of blather I put up is working in the same space. I was (for some reason!) unaware of the set reconciliation work done so far, and so had some inefficiency in that I still assumed a txid list needed to be sent... which actually can be eliminated. |
| 15:39:50 | hearn: | lol@bitcoin.ninja |
| 15:40:47 | gmaxwell: | gavinandresen: the pgp SKS-keyservers contain an implementation of very fast set-reconciliation for 64 bit values. |
| 15:41:19 | gavinandresen: | gmaxwell: yes, your block network encoding blather was helpful. Although not being an encoding expert I've got to admit much of it was moon-math to me. |
| 15:41:27 | gmaxwell: | If you don't mind adding one round trip to block propagation then purely that plus sending the missing transactions (one rtt later) gets you efficient block forwarding. |
| 15:42:42 | hearn: | i was never 100% satisfied that we can't achieve good efficiency with even simpler things. nodes are supposed to know what their peers mempools look like, even in the current protocol. minimizing the differences and making that chatter more explicit might get us 95% of the way there? |
| 15:42:47 | gavinandresen: | mmm. I think my next coding project will be to gather data from several nodes on exact timing that they get tx and block messages, and creating a framework for trying out different optimization algorithms. |
| 15:42:59 | hearn: | i know this was tried before and the basic "just reuse bloom filters" apparently didn't work well |
| 15:43:24 | hearn: | but it still feels like it *should* be possible |
| 15:44:25 | gmaxwell: | hearn: if you have some protocol that makes some promises about what it keeps in the mempool then you can get some pretty good efficiency. E.g. "I promise I'll keep the last 2000 transactions, and I promise I'll keep the last 2000 I sent you" |
| 15:44:36 | sipa: | i think the easiest solution is a protocol where nodes tell others what they know, but push new changes (instead of waiting for a request) |
| 15:44:38 | gavinandresen: | It absolutely should be possible. I wonder if reconciling memory pools or reconciling the-block-I'm-working-on would be the better approach |
| 15:44:39 | gmaxwell: | or even s/sent/inved/ |
| 15:45:06 | hearn: | gavinandresen: at any rate some kind of simulator would be useful indeed |
| 15:45:20 | gmaxwell: | well circulating around shares has an advantage of creating some pursusaive evidence of what the network is doing. |
| 15:45:47 | dgenr8: | gavinandresen: block-WHO-is-working-on? |
| 15:46:11 | gmaxwell: | dgenr8: 'the network' if it took the form of circulating shares. |
| 15:46:32 | gavinandresen: | dgenr8: block my peer is working on. I'm assuming this is all mostly a miner-to-miner network. Maybe with people eavesdropping to get a preview of what txns miners are going to include in their blocks..... |
| 15:46:57 | dgenr8: | fascinating. in the case of txes, reducing the propagation time variance as paper hints at, will payoff better than reducing the mean, for being confident in %propagated after x seconds |
| 15:47:13 | gmaxwell: | hearn: though any amount of {behave consistently} can't quite achieve complete efficiency since you will know about txn from other peers which wouldn't be covered by a straight up consistency model. |
| 15:47:17 | sipa: | gavinandresen: i don't think we should be focussing on improving miner-to-miner propagation... they're already paid for that |
| 15:47:41 | gavinandresen: | The incentive will be for all miners to be working on approximately the same set of transactions, since propagation will be O(d) where d is the number of transactions that differ from what the rest of the network is working on. |
| 15:47:47 | sipa: | gavinandresen: i'd rather see the network itself improve its general propagation speed, so miners aren't incentivized to build their own separate relay network |
| 15:49:06 | hearn: | i suggested in private chat that maybe Core should auto-adapt block sizes. so as propagation speeds improve due to other improvements, miners automatically start building larger blocks. like a simple drift formula that keeps increasing block sizes until orphan rates go over a certain percentage, specified on the command line |
| 15:49:23 | gavinandresen: | sipa: ok, I have no strong feeling on whether this is an extension of the existing p2p network or a separate miner-to-miner-before-I-find-a-block network. |
| 15:49:43 | hearn: | otherwise it's possible for "we made things faster, please make blocks larger" to get lost in the general mining noise. |
| 15:50:15 | gmaxwell: | hearn: the optimal case for it is that there is one pool that never orphans itself mininging infinite sized blocks. :) |
| 15:50:15 | hearn: | but not sure what the dynamics of such a system would be. needs thought |
| 15:50:33 | hearn: | gmaxwell: we could call it Citibank :) |
| 15:50:37 | sipa: | hearn: that just means you're incentivizing miners to collude (which yields 0% orphans) |
| 15:50:52 | hearn: | sipa: why? are they not already incentivised to collude? |
| 15:51:10 | gavinandresen: | if they are colluding to be Good and not Evil, then collusion is great! |
| 15:51:15 | sipa: | sipa has left #bitcoin-wizards |
| 15:51:27 | hearn: | sipa disappears in a puff of logic |
| 15:51:45 | gmaxwell: | gavinandresen: well no not quite, if today's good collusion is setting up centeralization which can be turned around tomorrow. :( |
| 15:52:18 | gmaxwell: | hearn: No, they're not— at least not substantially. (e.g. you can pool to share income without colluding at all about network state, e.g. what p2pool does) |
| 15:52:37 | hearn: | sure, but i don't see how auto-adapative block sizes changes that. it'd just be automating what we assume/hope miners already do |
| 15:53:33 | gmaxwell: | Oh because there is an inherent advantage to being the one miner to rule them all in that case, or being as closely connected as possible. Basically that would let the system scale to the point where no one else was physically able to participate. |
| 15:54:40 | hearn: | i was talking about "auto adaptive within the fixed block size limit", but i think this turns back into the 2011 era "infinite traffic growth means infinite centralisation" type debates |
| 15:55:02 | hearn: | [un]fortunately, infinite traffic is not a problem we currently suffer. far from it .... |
| 15:56:06 | gmaxwell: | hearn: bytecoin/monero/forks does a clever but— I think sadly totally busted thing— where the blocksize is constrained to the median, plus an additional amount which goes up with the square of the amount of coins the miner burns. So they argued in there whitepaper there is an equilibrium where additional fees match the additional burn. Sadly, that doesn't work out once the subsidy goes down because you can just pay fees out of ... |
| 15:56:12 | gmaxwell: | ... band. |
| 15:56:38 | gmaxwell: | (and, in practice, it seems to not work out even without the OOB fees... monero is like two months old and already the blockchain is like 2GB :( ) |
| 15:56:59 | gmaxwell: | hearn: ah! yea, within limits that otherwise keep things sane is perhaps interesting. |
| 15:57:37 | gmaxwell: | well infinite traffic, kind of a funny thing. If I'm a large miner and you tell me that I can reduce my compeition by just padding my blocks… doesn't cost anything to do so. |
| 15:59:36 | hearn_: | * hearn_ just generated a random 256 bit number and the last two bytes spell beef! |
| 15:59:42 | hearn_: | it's like winning $10 on the lottery |
| 15:59:43 | gmaxwell: | so monero is apparently going to be imposing an additional limit to get things under control (sounded like a kind of uninspired 1MB limit last I heard), and also hardforking to relax the median, because the behavior is also bad on the too small size (e.g. the network goes quiet for a few hours and the median becomes too low). |
| 15:59:51 | hearn_: | hearn_ is now known as hearn |
| 16:00:25 | hearn: | gmaxwell: they have an adaptive hard block size limit? |
| 16:00:35 | gavinandresen: | gmaxwell : where do you find time to keep up with what the wacky alts are doing… (or is there an intelligent-persons-alt-news site I don't know about) |
| 16:01:51 | hearn: | i think gmaxwell is a team of people, like satoshi |
| 16:02:14 | hearn: | probably a renegade unit somewhere inside the NSA given their level of crypto knowledge and general all-round total information awareness :) |
| 16:02:43 | gmaxwell: | gavinandresen: People bring things to my attention! Currently only keeping up with a couple things, sadly. ('sounded like' also points out the lack of fidelity in my following there) The bytecoin/monero/forks family are doing a couple watch-worthy things. |
| 16:03:39 | gavinandresen: | gmaxwell: so you ARE working in the NSA with junior analysts sending you memos..... |
| 16:03:51 | hearn: | gavinandresen: iirc monero/bytecoin is actually a from-scratch cryptocurrency implemenation that doesn't share any code with bitcoin at all. primary feature is a fancy ring signature based mixing system. it apparently was "circulating on tor for a while" before it emerged out of the darkness .... |
| 16:04:13 | gmaxwell: | 'circulating on lies' but whatever, the technology is interesting. :P |
| 16:05:15 | gmaxwell: | hearn: yes. Median of last N blocks, with a very small minimum, plus some additional amount related to the square of fees+subsidy burned, up to 2x the median. Unfortunately, it seems to not be well controlled, both resulting in huge blockchain bloat and long confirmation delays. |
| 16:05:38 | gmaxwell: | hard to sort out how much of that is the unsoundness of the technique vs immature ecosystem noise though. |
| 16:06:02 | hearn: | so someone is deliberately spamming their system just to troll? |
| 16:06:02 | gmaxwell: | though the monero developers are hardforking to adjust it (to increase the minimum, and to impose a hard maximum) |
| 16:06:15 | zooko: | I'd just like to mention that I'm really grateful to you folks for spilling all this good knowledge on this channel where I can listen. |
| 16:07:41 | gmaxwell: | hearn: more complicated. Bytecoin came out with this weird almost-certantly-completely-fabricated "circulating on tor for a while" history and 80% of the coins already mined. It was immediately forked. Several times. Leading fork is monero, but several of them are viable, and so there is substantial motivation for them to attack each other, on top of stuff like attacking pools that has long been common in the altcoin space. |
| 16:08:07 | gmaxwell: | The codebase is, as you note, written from scratch and super immature. |
| 16:08:10 | hearn: | yeah. tor isn't somewhere things really circulate. |
| 16:08:43 | hearn: | that story triggered my BS detector when i first heard it. but who knows, maybe there are really exotic cryptocurrency forums running as hidden services nobody seems to know about. |
| 16:09:53 | gmaxwell: | sure sure, though the blockchain is full of back dataed stuff like newspaper headlines and such, as if someone were trying to prove this thing existed years ago, but in spite of all of that effort they never thought to put a hash of its own chain in, say, the bitcoin blockchain. |
| 16:10:12 | jgarzik: | RE Tor.... Had an interesting opinion (perhaps obvious in hindsight w/ Snowden) on Tor: The ultimate goal of the network is to protect people hiding from non-US entities. Given the level of nodes run by NSA/FBI/GCHQ, that certainly seems true. |
| 16:11:04 | hearn: | jgarzik: did you read the "tor stinks" presentation? it claimed gchq/nsa tried running nodes for a while but gave up on that approach, and that they haven't managed consistent penetration and suspected they never would? |
| 16:11:08 | zooko: | I don't think the Tor network is the sort of thing that can have an ultimate goal. |
| 16:11:11 | gmaxwell: | Plus there is also a bunch of weirdness... POW function is suspiciously complex "cpu only" function. Initial code ran about ~4 verifies per second (!). A few rounds of undeoptimization got a desktop cpu up to 120/sec. .. there are now much faster gpu miners. So now even though monero forked to remove the premine it seems likely that a lot of those coins went to people with gpu miners created with a headstart. |
| 16:11:12 | hearn: | * hearn suspects they are too pessimistic, but still, that's what the doc said |
| 16:11:14 | zooko: | At least not *that* sort of ultimate goal. |
| 16:11:41 | hearn: | gmaxwell: premines usually seem to indicate badness of some kind indeed |
| 16:11:49 | zooko: | Although to be fair, I did once accuse NickM of colluding with NSA, using that sort of reasoning. |
| 16:12:04 | gmaxwell: | so it seems this layerd it, e.g. premine but knew it would be forked, but thats okay because the POW was "optimization trapdoored". |
| 16:12:22 | gmaxwell: | But regardless of the nonsense, the crypto approach is neat and useful for many things, not just cryptocurrency. |
| 16:12:29 | jgarzik: | zooko, That was the express reason why the Department of State funded bits of Tor for a time -- helping those inside repressive [implicitly non-US] regimes communicate and surf freely. |
| 16:12:43 | gmaxwell: | Andytoshi and I believe we've improved their cryptosystem further too. |
| 16:12:47 | zooko: | jgarzik: I know. And I agree that those funders can and do have that ultimate goal. |
| 16:12:58 | hearn: | jgarzik: iirc the original devs said the motivation was actually to hide their own spies traffic. open source intelligence gathering without revealing it was the cia doing it, etc. |
| 16:13:03 | hearn: | there's a post somewhere where they say that |
| 16:13:05 | zooko: | And that who funds you is very important and influential, even if you want to be not too much influenced by it. |
| 16:13:06 | hearn: | i could dig it out if you like |
| 16:13:23 | gmaxwell: | zooko: yea, my own expirence is that it's very hard to not be influenced by funding. |
| 16:13:35 | zooko: | hearn: I've been friends and collaborators with those devs since before Tor existed. |
| 16:13:43 | zooko: | So, I remember the thing to which you refer. |
| 16:14:15 | zooko: | I really admire the way Tor has done this — taken funding and also very importantly political support from the U.S. federal state while also creating a very generally useful and decentralized thing. |
| 16:14:32 | zooko: | As far as I can tell there is no way that the U.S. state can actually have secret control of Tor. |
| 16:14:41 | gmaxwell: | “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” |
| 16:14:51 | zooko: | And I *think* that my opinion is not too much influenced by the fact that I've been working with and befriending those folks all along. ;-) |
| 16:15:26 | gmaxwell: | zooko: you're not very imaginative! but most of this exists within the threat model that tor is pretty transparent about. |
| 16:15:39 | zooko: | I'm actually hoping to model a new venture on a similar strategy — to try to make it acceptable and positive from the perspectives of opposing factions, including the U.S. military/industrial/espionage complex. |
| 16:16:02 | zooko: | gmaxwell: yes, the transparency of the Tor project about limitations and threats is another beautiful, confidence-inspiring thing about them. |
| 16:16:15 | gmaxwell: | e.g. tor and all realtime systems are very very weak against very large attackers who can see most of the network. Now, couple this with funding which is only centered around realtime anonymity netowkr.s |
| 16:16:39 | jgarzik: | same with bitcoin. everybody worries about a 51% attack |
| 16:16:42 | zooko: | I've succeeded at that strategy on a very small scale with Tahoe-LAFS — NSA, DARPA, and other military/industrial folks like Tahoe-LAFS, as well as underground anarchists like it. |
| 16:16:45 | jgarzik: | but it's easy just to take down the network |
| 16:16:48 | jgarzik: | no comms, no bitcoin. |
| 16:16:50 | pigeons: | wonder why i2p gets so much less usage seemingly |
| 16:17:15 | zooko: | gmaxwell: yes, that's the argument with which I angered my friend NickM, claiming that he is de facto collaborating with NSA, for money, even if he doesn't think he is. |
| 16:17:28 | zooko: | He replied that I was de facto being a paranoid shithead, even if I didn't think I was. ;-) |
| 16:17:36 | gmaxwell: | You'll note that though some of the people involved in tor have been co-authors on papers about store and forward anonymity systems, none of that has been developed. I don't mean to suggest that anyone is doing anything naughty explicitly, but tor's capabilities are no doubt influenced by what can get funded, and it turns out that current featureset is in a sense maximally weak against the nsa. |
| 16:18:04 | hearn: | i think it's more likely that store-and-forward would not be very useful for solving the original goal, of hiding navy intelligence personell who want to browse the web |
| 16:18:16 | hearn: | the snowden docs seem pretty persuasive. they were never meant to be seen by anyone. |
| 16:18:31 | zooko: | gmaxwell: yes. I was there for some of those decisions. I didn't join in the Tor project, when Roger Dingledine conceived it as a successor to the Mixminion project, for that reason, and said that was my reason. |
| 16:18:39 | hearn: | i'd actually worry about the opposite - it's too strong against governments and tor is going to run into problems in the coming years because of it |
| 16:19:03 | hearn: | where by "governments" i mean regular Joe Cop type police investigations, not the NSA or GCHQ. |
| 16:19:10 | zooko: | Roger's stated reason at the time was what I *now* think the right reason: people like to browse the web. If you want to help lots of people and have lots of impact, you need to make web browsing work. |
| 16:19:43 | zooko: | hearn: the "Tor stinks" docs? Yes, to me too, but they are dated! |
| 16:19:45 | hearn: | right |
| 16:19:48 | zooko: | Aren't they from around 2008? |
| 16:19:57 | hearn: | zooko: only by a couple of years, i thought. 2012. but i'd have to check |
| 16:20:07 | gmaxwell: | Yea sure. The best kind of 'conspiracy' is the one where you do nothing because the world already does what you want. :) |
| 16:20:11 | hearn: | * hearn checks |
| 16:20:17 | hearn: | "tor stinks" is from jun 2012 |
| 16:20:20 | zooko: | Oh, yeah there was a timestamp that was from some kind of publication or sharing, but not necessarily from the date of authorship. |
| 16:20:30 | zooko: | hearn: are you sure that's not when it was, like, added to Microsoft Sharepoint or something? |
| 16:20:36 | zooko: | I thought there were two dates associated with it. |
| 16:20:38 | hearn: | and then it was marked "derived from", with a date in 2007 |
| 16:20:40 | hearn: | right |
| 16:20:41 | zooko: | 2012 is a lot more recent than 2007. |
| 16:20:55 | zooko: | gmaxwell: yeah. I worry about that, a lot. |
| 16:21:04 | zooko: | gmaxwell: the "are we playing into their hands" problem. |
| 16:22:43 | hearn: | zooko: i'd say it's ambiguous. 2012 is the date that's biggest on the title slide so i would expect that's the most useful/informative date. but impossible to say for sure. at any rate, given that Cameron directly instructed GCHQ to target the "dark web" as their highest priority, i suspect if they didn't already make good progress in the last two years they will soon |
| 16:22:58 | zooko: | Yeah. |
| 16:23:10 | Emcy: | zooko im not sure how much tor can really be influenced by its US funding |
| 16:23:30 | Emcy: | at least one of the devs is now in self imposed exiles from the US for his own safety he feels |
| 16:23:32 | gmaxwell: | Emcy: well I think I just described a compelling case. |
| 16:23:46 | Emcy: | might not be specifically due to work on tor though |
| 16:24:44 | zooko: | Emcy: I have no reason to think that any of it is due to his work on Tor. |
| 16:24:51 | gmaxwell: | All realtime anonymity systems are inherently weak against attackers who can watch most of the network. If you're an attacker who has a very broad view of the network you'd want to fund realtime anonymity systems to the detriment of non-realtime functionality which is inherently stronger against global observers. |
| 16:24:55 | jgarzik: | Tor is fun as an internal VPN between my own remote sites. |
| 16:24:58 | zooko: | Except, of course, generalized paranoia about such things, which I *do* have. But no specific reason. |
| 16:25:03 | jgarzik: | Someone breaks into one box, they don't automatically get access to another. |
| 16:25:12 | jgarzik: | Like IPsec, but actually useful. |
| 16:25:27 | hearn: | gmaxwell: except freenet was tried and sucked so hard nobody used it. tor doesn't have that many users compared to the commercial equivalents |
| 16:25:32 | hearn: | but it's still done way better than freenet |
| 16:26:06 | hearn: | (little known fact: people behind arab/islamic-country firewalls vastly prefer a california based commercial VPN service to tor) |
| 16:28:08 | gmaxwell: | hearn: well freenet is something else entirely too, it's a DHT. ... (vomit). See, for example, the Alpha mixing paper that Roger Dingledine was a coauthor on. |
| 16:29:01 | gmaxwell: | Basically if tor included some high latency functionality it would also improve privacy for the realtime users, because nodes could be playing out stored high latency traffic in gaps in the realtime traffic— basically making traffic analysis harder. |
| 16:29:21 | Emcy: | i thought tor was semi-realtime |
| 16:29:34 | Emcy: | random store and forward delays on the circuits etc |
| 16:29:37 | zooko: | hearn: that's because the VPN has lower latency, better reliability, etc., right? |
| 16:29:45 | Emcy: | to mitigate watermarking/correlation and all tha tnasty stuff |
| 16:29:56 | jgarzik: | Just in, Stripe is supporting a decentralized network called Stellar: https://stripe.com/blog/stellar |
| 16:30:00 | jgarzik: | some money behind that |
| 16:30:00 | hearn: | zooko: probably. plus an iOS client. plus it works for all apps, doesn't break youtube, etc |
| 16:30:04 | gmaxwell: | zooko: it's just easier, and also no shenanagins with exits that hork your traffic. |
| 16:30:06 | hearn: | zooko: Tor has an incredibly extreme threat model |
| 16:30:10 | maaku: | Emcy: you are limited in what you can do when you want to support live web browsing |
| 16:30:12 | jgarzik: | sounds like Ripple |
| 16:30:13 | jgarzik: | rebranded |
| 16:30:20 | hearn: | zooko: HSS has a weaker threat model more appropriate for people stuck behind government firewalls |
| 16:30:34 | jgarzik: | ah, ripple 2.0. Lead dev is Jed. |
| 16:30:37 | hearn: | jgarzik: basically is yes, my understanding |
| 16:30:41 | zooko: | Wow! https://stripe.com/blog/stellar looks very exciting! |
| 16:30:53 | Emcy: | maaku surely at decent traffic levels it only takes a few randomised seconds of delay per hop to fuzz things sufficiently? |
| 16:30:56 | maaku: | can we have the ripple brand back please? |
| 16:31:01 | pigeons: | yeah please |
| 16:31:05 | Emcy: | tor is pushing loads of gigabits now right |
| 16:31:14 | gmaxwell: | ::yawn:: another altcoin. :( "In return, we received 2% of the stellars" |
| 16:31:17 | zooko: | I'm a big fan of David Mazières research, too. |
| 16:31:36 | gmaxwell: | maaku: start a petition. :P |
| 16:31:39 | zooko: | Oh, coincidentally he was one of the Mixminion team, along with me and the people who would later found Tor. |
| 16:31:59 | pigeons: | but by the way jed left over a year ago, and the latest great antifeaturenewripple has implement is "account freezing" |
| 16:32:30 | jgarzik: | maaku, +1 |
| 16:32:45 | gmaxwell: | pigeons: BUT RIPPLE IS DECENTERALIZED! |
| 16:32:57 | pigeons: | i consider freimarkets the spiritual successor to ryan fugger's vision ;) |
| 16:33:02 | hearn: | jgarzik: found it: https://www.evernote.com/shard/s1/sh/96791ee9-98d5-44a0-b0a9-c2a5b3b6ec31/72b5e81135196815a23eb969d080ddf0 |
| 16:35:09 | Emcy: | http://www.theregister.co.uk/2014/07/31/multipath_tcp_will_bork_your_network_probes_flummox_your_firewalls/ kinda topical |
| 16:39:22 | maaku: | need to login via facebook to get stellars. yuck :( |
| 16:40:10 | hearn: | yes their "stop people claiming all the inflation" is to rely on facebook's abuse team |
| 16:40:23 | jgarzik: | Stripe CEO cofounder replies on twitter, RE Stellar/Ripple 2.0: "To be clear, it's not a Stripe project -- we just provided initial funding." |
| 16:40:25 | hearn: | i pointed out to them this makes the max reward they should be able to give out per account around 20 cents |
| 16:40:27 | jgarzik: | heh |
| 16:40:32 | jgarzik: | disclaimers already appearing |
| 16:40:46 | hearn: | and the response was that stellars don't matter anyway because they're like XRP |
| 16:40:50 | jgarzik: | Glad to see Stripe funding projects in this space though...! |
| 16:40:56 | hearn: | yeah! |
| 16:45:46 | Eliel: | oh, interesting, another implementation of the ripple idea. I hope there's some interesting techinical differences :) |
| 16:50:18 | pigeons: | nope, looks like an old fork |
| 16:50:49 | pigeons: | even some ripple references left in |
| 16:50:52 | pigeons: | https://github.com/stellar/stellard/blob/master/src/ripple_data/crypto/StellarPrivateKey.cpp |
| 16:51:16 | pigeons: | thre are some interesting technical differences in freimarkets! |
| 16:51:23 | Eliel: | well, at least they're distributing some of them to all bitcoin and ripple holders by default. |
| 16:51:49 | Eliel: | I'm surprised I haven't seen an altcoin do that before. |
| 16:52:18 | zooko: | Eliel: I'm glad to see that, too! |
| 16:52:19 | jgarzik: | indeed |
| 16:52:35 | zooko: | I'm trying to launch a new cryptocurrency, and planning to do that as part of it. |
| 16:52:37 | jgarzik: | it's just a hook, one that will quickly become overused |
| 16:52:45 | jgarzik: | free samples |
| 16:52:52 | jgarzik: | to a target market |
| 16:52:54 | pigeons: | there are some not really worth metnioning that do it with other altcoins, for example memorycoin2 let you importkeys from "protoshares" nonsense |
| 16:53:30 | zooko: | warner: what you missed: https://defuse.ca/b/WyYcPoEykcur3aFfJS6jxg |
| 16:53:41 | jgarzik: | forks like the "50 BTC forever" fork automatically give you bitcoins in their network |
| 16:53:45 | warner: | zooko: thanks |
| 16:53:59 | Eliel: | zooko: it's also something I would do if I ever did my own altcoin. |
| 16:56:58 | maaku: | Eliel: eh, it's just a hidden pre-mine imho |
| 16:57:31 | maaku: | (1) distribute to people who don't care about your shitty new alt, (2) buy it back from them at bit-cents on the coin |
| 16:58:16 | Eliel: | maaku: the difference is, anyone can do that. |
| 16:59:25 | zooko: | maaku: good point, thanks for the reminder. |
| 17:00:07 | zooko: | maaku: if I move ahead with my plans, I'd institute transparency rules that forbid my organizations to buy or sell within a time-lock. |
| 17:00:42 | zooko: | The forbidden-to-sell-within-a-time-lock part can be decentralizedly enforced, too! The other part probably just has to be social/legal imperative combined with transparency. |
| 17:06:47 | Eliel: | maaku: but yes, that's the problem. No matter how evenly you try to distribute the coins to people, some people won't value them and will most likely sell them for much less than they potentially could be worth in the future. (Assuming it's a coin with actual potential, not just a copycat) |
| 17:07:33 | zooko: | So I have an idea about that, Eliel & maaku. |
| 17:07:39 | maaku: | Eliel: so why unfairly bias the distribution to current users of bitcoin (a small minority of future users)? |
| 17:08:03 | zooko: | Which is to have coins which can't be irrevocably spent until a time-lock elapses. |
| 17:08:03 | jgarzik: | maaku, PR |
| 17:08:06 | jgarzik: | maaku, bootstrapping |
| 17:08:09 | Eliel: | maaku: you got a better idea on how to distribute them evenly? |
| 17:08:21 | zooko: | This should deter speculation and pump-and-dump. |
| 17:08:41 | zooko: | I originally came up with this idea as an anti-theft feature, but later thought it could be used as an anti-pump-and-dump feature. |
| 17:08:48 | Eliel: | zooko: ah, true, time lock would help a bit. |
| 17:08:51 | gmaxwell: | so instead of farming ripples via bitcointalk accounts you farm stellers via facebook accounts? |
| 17:09:26 | maaku: | yeah, unless it involves pointy hats and magic wands we should probably move this elsewhere |
| 17:09:38 | maaku: | jgarzik: the money-typedef PR? I'm working on that right now |
| 17:10:01 | maaku: | oh haha PR as in public relations, n/m |
| 17:10:36 | gmaxwell: | zooko: you can't technically achieve anti-sell locks, I can just sell you my future control (e.g. give you a private key, and a dead tree promise to not spend it out from under you). (I wonder if you were the person to introduce that idea to ethereum? they're also doing that for talking point purposes) |
| 17:10:38 | jgarzik: | It is pretty easy to use the same ECDSA public/private key across chains. In theory you could send to addresses on $MyAltCoin chain, which were unlocked with bitcoin pubkeys or pkh's |
| 17:11:10 | jgarzik: | simply conversion util gets access to $MyAlt |
| 17:11:41 | gmaxwell: | jgarzik: yes, I realized/recalled last night that the 1GMax hash160 on litecoin has funds. |
| 17:16:57 | jgarzik: | gmaxwell, zooko: Right. You can trade/sell your rights to something in the future. That's done all the time. |
| 17:17:12 | jgarzik: | monetize now, deliver in the future |
| 17:17:16 | zooko: | maaku: this discussion is inappropriate for this channel? |
| 17:17:40 | zooko: | gmaxwell: I'm aware of that, but I think it provides a good deterrent anyway. |
| 17:17:59 | zooko: | gmaxwell: I can't prove to you that I don't still have the ability to yank it back from you before the timeput elapses. |
| 17:18:01 | jgarzik: | zooko, it is trivial to automate the trading of such digital entities |
| 17:18:28 | zooko: | gmaxwell: do you have a reference to Ethereum talking about it? I haven't seen that before and I'm very interested in their process. |
| 17:18:55 | zooko: | jgarzik: yeah, true. |
| 17:19:19 | zooko: | jgarzik: I'll be careful not to exaggerate it as though it is something that prevents trading. |
| 17:23:21 | jgarzik: | zooko, a lock-in period for IPOs is a well known concept, so that's fine. it is good to read some discussion on that general subject. e.g. One impact, you wind up with a "dump cliff" at the end of lock-in period, as free market signals that have been artificially impeded for N days are suddenly freed. |
| 17:23:45 | zooko: | jgarzik: right! Yeah, I've been thinking of having a series of smaller cliffs. |
| 17:23:49 | jgarzik: | In a completely untrusted digital system, trading of such rights would emerge immediately. |
| 17:24:16 | zooko: | So, one thing we could do is say that the only product you can buy is one that comes with 48 batches of time-locked coins, each one unlocking one month later than the previous one. |
| 17:24:20 | jgarzik: | Thus, the problem remains of the holders human-ly agreeing to uphold the lock period. |
| 17:24:26 | jgarzik: | Cannot be guaranteed digitally. |
| 17:24:30 | zooko: | Right. |
| 17:25:01 | maaku: | zooko: not sure; we tend to avoid discussions of alts here. asking "what change should i make to pump my alt?" is a good way to get kick/banned |
| 17:25:02 | zooko: | And the part about *my* organizations doing that I can establish social and legal rules against, i.e. we'll publish our balances and we'll agree not to do any such trading, etc., |
| 17:25:06 | zooko: | but I can't do anything about other people. |
| 17:25:11 | maaku: | thats not at all what you are doing, but where do you draw the line? |
| 17:25:31 | maaku: | anyway the regulars here seem to be engaging, so /me bows out |
| 17:25:33 | gmaxwell: | zooko: 'legal rules' are also what make the selling of the futures effective. |
| 17:25:41 | zooko: | maaku: okay, I'd be willing to move it to another channel if there's a consensus about that. |
| 17:26:23 | zooko: | gmaxwell: you mean if someone will enforce delivery of those futures for those folks? |
| 17:26:30 | zooko: | Then that enables those futures contracts? |
| 17:26:50 | gmaxwell: | zooko: would punish someone who broke their agreement and kept the private keys they said they destroyed. |
| 17:27:19 | jgarzik: | zooko, maaku: My personal and completely subjective measure is whether or not other subjects are getting drowned out, or are channel participants generally engaged |
| 17:27:33 | jgarzik: | IMO trust related structures are on topic here |
| 17:27:36 | zooko: | gmaxwell: right |
| 17:27:55 | jgarzik: | as long as it doesn't veer too far into altcoin land |
| 17:28:12 | gmaxwell: | bringing it back ontopic. :) there are also purely technical measures if you want to set this up in advance— for example, if I think I want to sell my shares, I ask five people that would be trusted to not conspire with me, and then have them generate six public keys on my behalf, one each |
| 17:28:19 | zooko: | If any of the regulars here would like me to pipe down so you can resume talking about improvements to the bitcoin mining protocols, feel free to say so publicly or privately. |
| 17:28:20 | gmaxwell: | er five from them, one from me. |
| 17:28:30 | zooko: | In which case I'll invite everyone who cares to continue this to join me in another channel. |
| 17:28:33 | gmaxwell: | I sum these six public keys, and submit that one as the one that gets the shares |
| 17:28:38 | jgarzik: | zooko, cease worrying about meta |
| 17:29:10 | zooko: | gmaxwell: Um, what's the consequence of that? I don't understand the "summing" part yet… |
| 17:29:14 | zooko: | * zooko ceases worrying |
| 17:30:13 | gmaxwell: | zooko: Pub1 = Priv1*G Right? Standard ECC stuff. So also assume Pub2 = Priv2*G and Pub3 = Priv3*G |
| 17:30:18 | zooko: | gmaxwell: in any case, I well understand that the time-lock enforcement can be worked-around by technical and other means in order to more-or-less effectively sell before the time expires. |
| 17:30:27 | zooko: | gmaxwell: *nod* |
| 17:30:49 | gmaxwell: | thus Pub123 = Pub1 + Pub2 + Pub3 (point addition) and Priv123 = Priv1 + Priv2 + Priv3 (scalar addition mod order of the curve) |
| 17:31:00 | zooko: | *nod* |
| 17:31:05 | gmaxwell: | so I can generate a public key for which I don't have the private key, it's shared among multiple parties. |
| 17:31:18 | gmaxwell: | and then later I can direct those parties to give _you_ and only you, their share. |
| 17:31:19 | zooko: | Neat! ☺ |
| 17:31:31 | gmaxwell: | so I can create pretty compelling evidence that no one but you has the private key. |
| 17:32:03 | zooko: | Yeah, that's a nice hack. |
| 17:32:22 | gmaxwell: | also if I arrange with you in advance, of course you can just give me the pubkey to pay to. Or, alternatively, those privatekeys in the above protocol can be remote attest oracles (in addition or instead) |
| 17:32:39 | gmaxwell: | with the oracles you can even do things like having the ownership tradeable, if you don't mind trusting the oracles. |
| 17:32:58 | gmaxwell: | and of course with some slightly more complex math (interpolation) you can make it N of M instead of N of N. |
| 17:33:16 | gmaxwell: | even works with dsa, since you don't mind that eventually the private key gets known by one party. |
| 17:34:26 | gmaxwell: | e.g. to make a simple example with a colored coin (yuck), you have M oracles which will one-time reveal their share to the owner of some particular satoshi on bitcoin, whenever that person wants... then you can just trade around that satoshi. |
| 17:34:43 | zooko: | *nod* |
| 17:35:01 | zooko: | So, this doesn't convince me that it is useless to put a time-lock on initial coins of my new currency. |
| 17:35:05 | gmaxwell: | now you have a fully liquid transferable control of this supposidly locked asset. :) subject to some security assumptions. |
| 17:35:15 | zooko: | Especially since I want to *implement* the time-lock feature anyway for the purpose of anti-theft. |
| 17:35:19 | gmaxwell: | Well I don't know that it's useless, but I think it's more for show than anything else. |
| 17:35:26 | zooko: | *nod* |
| 17:35:27 | zooko: | Show counts. |
| 17:35:41 | gmaxwell: | well it counts when you're trying to pump a speculative asset. :( |
| 17:35:48 | zooko: | Because there is an implicit and explicit social "contract". I guess "contract" is not the right word here. |
| 17:35:55 | zooko: | No, that's not the only time that it counts. |
| 17:36:30 | zooko: | People's understandings and expectations are important, even or especially when I, and many (but probably not all) of the other parties, are honestly working to provide real and lasting value. |
| 17:37:22 | gmaxwell: | zooko: funny, I work on bitcoin without having any privileged position to be receiving it. |
| 17:37:33 | zooko: | *nod* |
| 17:37:41 | zooko: | Are you getting paid to work on Bitcoin right now? |
| 17:37:44 | zooko: | If you don't mind my asking? |
| 17:37:59 | zooko: | I ask not to use it against you in a debate, but because I really care about funding cryptocurrency innovation. |
| 17:39:52 | gmaxwell: | No harm in asking— public info. I am not currently, by my own choice. See the earlier conversation about the great difficulty in seperating interests from funding sources. |
| 17:39:59 | zooko: | *nod* |
| 17:40:16 | zooko: | So that suggests that… impartial philanthropic funding would suit you? |
| 17:40:41 | zooko: | Like some foundation or philanthropist could make you a "fellow" or whatever they're called, where you get money on the condition that you keeping being yourself. |
| 17:40:59 | jgarzik: | Michael Crichton has proposed blinded funding orgs for science, in general. |
| 17:41:04 | jgarzik: | fun to think through that |
| 17:41:16 | jgarzik: | but it is incredibly difficult to fully blind, in the real world |
| 17:41:19 | zooko: | Ooh, like the recipients are anonymous to the funders ? |
| 17:41:23 | zooko: | And/or vice-versa? |
| 17:41:24 | zooko: | Neat idea. |
| 17:41:34 | jgarzik: | funders anonymous to recipients |
| 17:41:37 | zooko: | Hey, relatedly, L.M. Goodman gave me an exciting idea the other day. |
| 17:41:51 | jgarzik: | could possibly do recip anon as well |
| 17:41:54 | hearn: | gmaxwell: as the topic came up, would you be interested in receiving funding for projects via crowdfunding, if e.g. the max pledge size was capped and some basic/trivial id blinding was done, so you wouldn't know the source of the funds? |
| 17:42:14 | jgarzik: | the main problem being addressed is bending -- even if unconsciously or by selection bias -- towards the funders. |
| 17:42:18 | zooko: | It was that there could be a donation of newly-created currency in each block that goes to an (ostensible) deserving charity, as determined by some consensus mechanism. |
| 17:42:23 | zooko: | hearn: Yeah!! ☺ |
| 17:42:23 | gmaxwell: | zooko: for my own interests, I've mostly also been concerned about how to also get other people funded. |
| 17:42:24 | hearn: | gmaxwell: i.e. you'd get to pick the projects and if there are sufficient interested parties, and you complete the project, you get the money? if it's just worry about undue influence that's the issue it seems solvable |
| 17:42:29 | jgarzik: | there are way too few _negative_ results published, for science in general. |
| 17:42:30 | zooko: | gmaxwell: *nod* |
| 17:42:46 | zooko: | gmaxwell: yeah, that's what I don't like about philanthropic funding is that there isn't a feedback loop where more value automatically means more funding. |
| 17:42:50 | zooko: | Instead it's an open loop. |
| 17:42:50 | jgarzik: | commercial interests have economic incentive against publishing negative results |
| 17:43:03 | zooko: | Or, more realistically, there's a feedback loop of, you know, sales and marketing and sucking-up and whatnot. |
| 17:43:20 | zooko: | So there are a few interesting things about L.M. Goodman's suggestion. |
| 17:43:37 | gmaxwell: | hearn: I'm pretty skeptical about 'bounty' like funding in general, but I think it should exist as a thing people do. My expirence in OSS in general is that project bounties have a very low hitrate at either bringing in new contributors OR sustaining big tallent. e.g. mostly funds one-shot things that vanish afterwards. But perhaps no one has found the magical formula. |
| 17:43:41 | zooko: | Obviously creating new currency ex nihilo and giving it to the recipient is transferring a tiny bit of value from all current holders and giving that value to the recipient, right? |
| 17:44:10 | gmaxwell: | zooko: yea, one interesting question is how to have useful feedback loops without the feedback being an excessive control / distorting point. |
| 17:44:29 | zooko: | But the thing that started intriguing me about it is that the decision for each participant in the consensus is interestingly different than a normal donation, *and* interestingly different than an assurance contract. |
| 17:44:30 | hearn: | gmaxwell: what i'm working on is not bounties in the traditional sense. it's more like, someone can post a project and say "this is what i will do, if i get at least X coins pledged". so it's not an open fund, it's specifically for you. |
| 17:44:40 | hearn: | gmaxwell: kickstarter style, using SIGHASH_ANYONECANPAY. |
| 17:44:43 | zooko: | gmaxwell: yeah, exactly the problem. |
| 17:44:56 | hearn: | so you control the project definition, the amount of money needed to create/release it, the timelines, etc |
| 17:45:12 | gmaxwell: | hearn: I'm aware... No one added to a SIGHASH_ANYONECANPAY I tried posting on reddit once. :P tools will be good. |
| 17:45:42 | hearn: | ok, good :) then i guess i'll try it out and if it goes well, will ask again once i have some proof that it's different :) |
| 17:46:20 | jgarzik: | SIGHASH_ANYONECANPAY is an interesting type of pledge. You are provably committing funds. The funds may be revoked at any time prior to crowdfunding close with a double spend. |
| 17:46:30 | jgarzik: | So it is a pledge, but a backed one.l |
| 17:47:03 | hearn: | right. it's not quite an assurance contract, actually |
| 17:47:09 | hearn: | which is annoying because i want a term that isn't crowdfunding |
| 17:47:29 | hearn: | i suspect there is no word for the exact form i'm implementing which is irritating. crowdfunding is rapidly becoming useless as a piece of vocabulary |
| 17:48:48 | hearn: | it could be turned into an assurance contract with a refund tx step, but then we're back to needing some p2p network of nodes that stores locktimed transactions for you |
| 17:48:50 | jgarzik: | I had to write my auction software to constantly monitor for double spends, as users back out of the auction :( |
| 17:48:55 | hearn: | otherwise you have to be online all the time, which is annoying |
| 17:48:58 | jgarzik: | made it less than useful |
| 17:49:23 | jgarzik: | indeed |
| 17:53:24 | zooko: | Thanks for the good conversation, folks. |
| 17:59:44 | nsh: | I'd just like to mention that I'm really grateful to you folks for spilling all this good knowledge on this channel where I can listen. <---- i was just thinking the same about your handy summary and links ( https://tahoe-lafs.org/trac/tahoe-lafs/wiki/SNARKs ) |
| 18:00:46 | zooko: | nsh: that's due to warner |
| 18:00:48 | pigeons: | pigeons is now known as pigeons` |
| 18:01:34 | pigeons`: | pigeons` is now known as pigeons |
| 18:01:52 | nsh: | ah, then thanks to warner :) |
| 18:03:14 | pigeons: | pigeons is now known as pigeons_ |
| 18:03:50 | pigeons_: | pigeons_ is now known as pigeons |
| 18:06:02 | pigeons: | pigeons is now known as pigeons- |
| 18:06:28 | pigeons-: | pigeons- is now known as pigeons |
| 18:07:15 | Guyver2_: | Guyver2_ is now known as Guyver2 |
| 18:10:29 | pigeons: | pigeons is now known as pigeon |
| 18:10:59 | pigeon: | pigeon is now known as Guest72354 |
| 18:11:05 | Guest72354: | Guest72354 is now known as pigeons |
| 18:41:16 | warner: | nsh: please feel free to add to that list.. I don't understand very much about the subject myself :) |
| 18:42:07 | nsh: | will do if i ever get any confidence of understanding it myself :) |
| 18:54:31 | maaku: | so aparantly on sign-up stellar sends a "recovery code" (aka master password) in plaintext to your email |
| 18:54:33 | maaku: | awesome |
| 18:55:46 | ucerr: | lmao |
| 18:56:02 | ucerr: | it's from the creator of mtgox what would you expect |
| 18:57:10 | ucerr: | co-founder |
| 18:59:59 | mapppum: | it's just a ripple clone, to be pumped and dumped |
| 19:00:06 | mapppum: | mapppum is now known as mappum_ |
| 19:02:20 | maaku: | so was Jed's voluntary divestment of XRP insider trading? |
| 19:03:54 | grubles: | he never actually sold them |
| 19:03:57 | grubles: | if i read correctly |
| 19:04:06 | pigeons: | yeah he sold as many as the market would bear |
| 19:05:15 | grubles: | hm |
| 19:05:19 | grubles: | not what coindesk said |
| 19:05:21 | grubles: | "Despite his post, however, McCaleb has not yet sold the XRP, which he was awarded when he joined the company. When Ripple set aside 20 billion XRP for distribution amongst its founders, a 9 billion slice was awarded to McCaleb." |
| 19:07:57 | pigeons: | grubles: i'll stop the off topic after this but he sold 177 million between 6/13 and 7/20 |
| 19:08:07 | pigeons: | there isnt enough demand to dump all that stuff |
| 19:08:20 | pigeons: | he also donated millions to miri |
| 19:08:35 | grubles: | hm i see |
| 19:09:31 | maaku: | i forgot about the miri donation |
| 19:09:42 | maaku: | i think lukeprog managed to sell most of those though |
| 19:10:44 | maaku: | iirc he hit up MIRI's donor list to see if anyone wanted to buy the XRP off them in a private party sale |
| 19:10:49 | grubles: | i guess coindesk has the facts wrong |
| 19:11:32 | pigeons: | shocking |
| 19:23:49 | jaekwon1: | jaekwon1 has left #bitcoin-wizards |
| 20:03:20 | gmaxwell: | So I determined what newegg does for refunds on bitcoin sales— they give you a newegg giftcard. |
| 20:06:24 | midnightmagic: | lol |
| 20:09:17 | jgarzik: | Peter Todd's employment status is in a state of quantum superposition. He simultaneously works at multiple organizations but if he is ever observed at work it collapses. |
| 20:09:19 | jgarzik: | rofl |
| 20:12:34 | kanzure: | nobody has heard of contracting, i guess |
| 20:16:53 | maaku: | kanzure: "Chief Scientist" usually isn't a part-time contracting position |
| 20:17:09 | Luke-Jr: | lol |
| 20:17:25 | Luke-Jr: | gmaxwell: NewEgg says that upfront on the checkout page |
| 20:17:37 | Luke-Jr: | gmaxwell: you don't read the fine-print⁈ |
| 20:17:59 | kanzure: | maaku: approximately what amount of overlap with MIRI people is there here |
| 20:18:16 | pigeons: | mayor of our town is a part time position paying $8000 usd/year. and then they act shocked when the fbi arrests him for taking bribes |
| 20:18:40 | maaku: | you and me, if you can count me (I'm a vocal MIRI critic) |
| 20:18:57 | jgarzik: | MIRI? |
| 20:19:03 | kanzure: | "ai is going to blow up the world" |
| 20:19:05 | kanzure: | those guys |
| 20:19:13 | pigeons: | i know wei dei, author of b-money, metnioned in satoshi's paper is active with miri |
| 20:19:27 | kanzure: | wei dei predates MIRI and SIAI heh |
| 20:19:48 | maaku: | eyah but sadly he's not been involved in bitcoin at all |
| 20:19:55 | kanzure: | that's not entirely true |
| 20:20:31 | maaku: | kanzure: ? |
| 20:20:50 | pigeons: | he mined a little back when we all did with pcs |
| 20:20:55 | kanzure: | i am trying to remember his bitcoin address |
| 20:21:09 | pigeons: | and there were no pools or gpu mining |
| 20:21:09 | maaku: | jgarzik: http://intelligence.org/ |
| 20:22:36 | maaku: | kanzure: iirc his "involvement" other than intellectual geneology of b-money was cpu mining for a few hous/days in 2009 |
| 20:22:47 | jgarzik: | In any case, altcoins and protocoins and metacoins and whatnot are all potentially nutso investment schemes that are easy to manipulate, if not pre-manipulate. "the world's easiest pump-n-dump scheme" as I've said. |
| 20:22:58 | jgarzik: | contracting for multiple such entities complicates the trust waters |
| 20:23:32 | kanzure: | i don't know what the terms of those contracts are |
| 20:23:41 | kanzure: | for example, suppose they were paying for a few hours of code review time |
| 20:23:44 | jgarzik: | that's the point; you never do |
| 20:23:58 | kanzure: | well, you're not supposed to make assumptions about what you don't know |
| 20:24:00 | pigeons: | what is viacoin |
| 20:24:11 | jgarzik: | presumably you can reach a saturation point where trust starts to be regained if you simply contract with everyone |
| 20:24:39 | Emcy: | does the recent discovered attack on tor have any indications for tor support in bitcoin |
| 20:24:48 | Emcy: | hidden service support or something |
| 20:25:07 | jgarzik: | kanzure, you make a guess as to the range of possibilities, from good faith to bad faith to duress to ... |
| 20:25:31 | pigeons: | --to mascot |
| 20:25:38 | jgarzik: | Emcy, bitcoin hidden service support has long existed |
| 20:26:13 | kanzure: | even for the "5 hours of looking at this chunk of code, to make up a review" doesn't mean "guarantee me that this is perfect", it means "provide me some amount of value in the form of yelling at me about what type of crappy code i've written" |
| 20:26:13 | Emcy: | i know, i mean its all tors problem right |
| 20:26:20 | zooko: | zooko has left #bitcoin-wizards |
| 20:26:33 | kanzure: | the guarantees are a game of warranties or something, which is different i think |
| 20:26:34 | TeoDerich: | kanzure, you just lost the game! |
| 20:27:35 | kanzure: | that's not helpful |
| 21:19:02 | petertodd: | pigeons: "what is viacoin" <- dunno exactly, I haven't looked. they just asked me to answere some tech questions at my $250/hr rate, liked the answeres, and asked if I'd be willing to do some research into treechains and make a prototype |
| 21:20:26 | petertodd: | kanzure: my recent counterpartyd audit is a good example of that, resulting in a list of issues to fix: https://github.com/CounterpartyXCP/counterpartyd/labels/Peter%20Todd%20Audit |
| 21:22:32 | petertodd: | jgarzik: fastest way to lose trust in my minds is promote obviously broken ideas... I see merge-mined sidechains as one such idea, others see embedded consensus anything as another. |
| 21:30:34 | kanzure: | if you "lose the game" for providing any value whatsoever, then i'm not sure what game i am playing |
| 21:30:34 | TeoDerich: | kanzure, you just lost the game! |
| 21:30:40 | kanzure: | oh, it's a bot :) |
| 21:30:52 | gmaxwell: | gmaxwell has kicked TeoDerich from #bitcoin-wizards |
| 22:13:38 | gmaxwell: | in other altcoin news, that mini blockchain thing that had the somewhat infamous don't-bother-me-with-the-security-problems-i-just-work-here in this channel has launched. Already seemed to be turning pearshaped with mining collapsing mostly to a single entity, seemingly due to private optimization of their crazy 7-hash POW function (especially bad considering that it seems to only have SPV security). ... contains a bunch of really ... |
| 22:13:44 | gmaxwell: | ... hard to follow trie code, and uses public key recovery for signatures (but completely removes script). |
| 22:14:01 | gmaxwell: | (why something would use public key recovery to make multisig efficent but not just implement schnorr is kinda beyond me, but neat to see it being used) |
| 22:22:36 | Emcy: | 7 hash you say |
| 22:22:58 | jcorgan: | i bet those were 7 *scientific* hashses, though |
| 22:23:20 | pigeons: | that's safer than going through 7 proxies |
| 22:23:44 | Emcy: | maybe its like 7 cheese omlette......sor tof arcane and a pita to make but is nice in the end |
| 22:24:18 | helo: | needs more hashes |
| 22:26:05 | Emcy: | gmaxwell surely though we still cant bring people down for trying new things, even if they seem nutty |
| 22:26:57 | gmaxwell: | Emcy: huh? I brought it up to specifically mention the two things I thought were interesting (along with the we called it on the overall approach) |
| 22:27:40 | gmaxwell: | though we absolutely can, if you deploy cryptographic software and it fails on people you have some moral responsibility for that, doubly so when you were recklessly indifferent to it— |
| 22:28:04 | Emcy: | point taken |
| 22:28:33 | Emcy: | disclaim, warn and disclaim again i guess |
| 22:41:22 | dsnrk: | jcorgan: oh yeah. 7 "secure" hashes that are chained together. |
| 22:42:06 | dsnrk: | well multiplied not chained, but the idea is the same. it's easier on a CPU! (except for the one dude who wrote a GPU miner ahead of time) |
| 22:44:41 | jcorgan: | heh. altcoins seem to be the perpetual motion of our era. maybe enough people have always believed in bullshit to make such efforts pay off in the short-run. |
| 22:53:10 | tacotime: | i was surprised that bitcoin didn't use public key recovery for sigs when i first read how they worked. |
| 22:53:26 | sipa: | satoshi presumably didn't know about it |
| 22:53:32 | sipa: | for message signatures, we do use it |
| 22:53:46 | tacotime: | sipa, right, that was where i first learned of it |
| 22:54:43 | tacotime: | when i first started learning about bitcoin i had a two hour freakout because i couldn't figure out how signatures were verified just from the signature when signing messages. heh. |
| 22:55:04 | sipa: | haha |
| 22:56:45 | Adohgg: | Adohgg is now known as LTCpro |
| 23:23:53 | jps_: | jps_ is now known as jps |