| 00:00:16 | petertodd: | heh |
| 00:01:55 | bramc: | But I'm now convinced that the protocol as it stands is sufficient, although wallets need work and there should probably be some extensions to the light protocol to find out what the acceptance threshold was on previous blocks |
| 00:02:35 | justanotheruser: | I don't understand. Is that a pedophile joke or do programmers have 13 year old fans? |
| 00:02:59 | bramc: | justanotheruser, We have 13 year old fans. Or at least I do. |
| 00:03:50 | justanotheruser: | thats strange |
| 00:04:25 | bramc: | justanotheruser, It's because of what I'm known for writing |
| 00:04:54 | justanotheruser: | some game? |
| 00:05:11 | bramc: | some p2p thing |
| 00:05:18 | petertodd: | justanotheruser: really, we have groupies that act like 13 year old boys on 4chan... |
| 00:06:25 | justanotheruser: | o_O |
| 00:06:29 | bramc: | By the way, for the vast multitudes of people out there awaiting technical details of the thing I'm working on, I'm still getting it to the point where I feel it's solid before everybody starting jumping on me claiming that it's impossible, the details of the construction are fairly subtle. |
| 00:06:44 | justanotheruser: | after whoising you "some p2p thing" is hilarious |
| 00:08:20 | petertodd: | bramc: what are you working on??? :P |
| 00:08:39 | bramc: | petertodd, an altcoin whose mining doesn't involve burning electricity |
| 00:08:45 | kanzure: | still? |
| 00:08:47 | justanotheruser: | thats disappointing |
| 00:08:54 | kanzure: | what were your objections to the previous arguments we brought to you about that, bramc? |
| 00:08:59 | petertodd: | bramc: ah, the proof of capacity thing? |
| 00:09:59 | bramc: | kanzure, Basically I've figured out how to engineer it so that there are a bunch of things which are calculated canonically so there's nothing to do parallel attacks on. It's a bit of a subtle contraption though |
| 00:10:24 | bramc: | petertodd, It's a somewhat involved combination of proofs of storage and proofs of time |
| 00:10:46 | petertodd: | bramc: well, I'm going to say it sucks until you find a way to explain it to a dumb arts student like myself in five minutes :) |
| 00:11:56 | justanotheruser: | bramc: the scarce resource that is being burned is just the electricity used to make that hardware then isn't it? |
| 00:12:06 | bramc: | petertodd, Once I've done a clearer writeup you might be able to understand a basic overview in five minutes, I don't think convincing you that it's secure can be done in five minutes. There are many potential attacks and the reasons they don't work are subtle |
| 00:12:09 | petertodd: | justanotheruser: +1 |
| 00:12:10 | justanotheruser: | s/electricity/energy |
| 00:12:20 | kanzure: | you'll often be replacing most of your parallel processes with work based on the network |
| 00:12:33 | bramc: | justanotheruser, no because it's really depreciation on storage which was already made for other reasons, of which there's mass quantities in the world |
| 00:12:45 | petertodd: | bramc: well, it's not to say it doesn't work - explaining why sha256 is secure *can't* be done in five minutes to anyone - but I'm not going to bet it does :) |
| 00:13:57 | kanzure: | "It doesn't reduce to plain pow because the costs are such that you're burning more on spow than the value you're gaining from it." but that's irrelevant because you don't need to gain value from burning anything (value could be defined as breaking consensus) |
| 00:14:17 | kanzure: | man i hate how you treat us as forgetful morons |
| 00:15:17 | bramc: | petertodd, fair enough I don't fault anyone for being skeptical, hence my not wasting everyone's time with explaining it in detail while I'm still working on it because I don't want to go through a break/fix/break/fix cycle on things I'm entirely capable of fixing on my own |
| 00:15:42 | bramc: | kanzure, not exactly sure what you mean there but I've added some important details since then |
| 00:16:11 | bramc: | capable of breaking and fixing on my own I mean |
| 00:16:15 | bramc: | Hey adam3us |
| 00:16:24 | adam3us: | hey |
| 00:17:28 | bramc: | adam3us, You just missed me half-starting a flame war again |
| 00:17:34 | kanzure: | could you instead make direct statements instead of dangling hooks |
| 00:17:48 | adam3us: | bramc: another day another flame war. |
| 00:17:49 | justanotheruser: | bramc: I'm going to assume that regular harddisks aren't as powerful as some ASIC for proving that you are expending some resource. |
| 00:18:48 | kanzure: | i'm sure there's many optimizations you can make over a conventional ssd, for example |
| 00:19:00 | kanzure: | but that's also irrelevant i think |
| 00:19:00 | bramc: | kanzure, I'm not trying to taunt, the details are really quite subtle and explaining them over irc isn't likely to work well. If there are a bunch of people in the bay area maybe I can do an in-person discussion some day so they can all jump on me at once |
| 00:19:26 | kanzure: | ugh |
| 00:20:05 | bramc: | justanotheruser, asic and hard drive aren't even vaguely comparable resources, for what I'm working on the whole concept of asic-based optimization is essentially irrelevant, at least for the main reward-getting part of mining |
| 00:20:09 | petertodd: | bramc: fwiw I might be in the bay area again beginning of march, though like last time my schedule may be fucked |
| 00:20:26 | kanzure: | imposing physical constraints on people's time and attention is annoying |
| 00:20:39 | kanzure: | if i had to physically visit every one of you to relay my messages i'd never get anything done |
| 00:21:10 | Guest99135: | Guest99135 is now known as maaku |
| 00:21:24 | bramc: | kanzure, trust me it will go way faster in person than over irc, and I haven't even put together decent materials for people to read over yet, I'm still in the process of working on those. |
| 00:22:07 | bramc: | So it's like 'if people are in the bay area I can explain this to them, if not easier for you to wait until I've put real documentation together and finished a prototype' |
| 00:22:38 | ajweiss: | do i get coins for throwing bandwidth at p2p livestreaming? |
| 00:22:43 | kanzure: | then why would you even advertise anything. blah. |
| 00:23:40 | justanotheruser: | bramc: Whatever computation you're doing that involves storing lots of information can probably be optomized using special hardware. |
| 00:23:56 | justanotheruser: | At the very least, I could buy a ton of RAM and use that |
| 00:24:03 | kanzure: | his complaint was about energy utilization, not resource utilization |
| 00:24:26 | petertodd: | justanotheruser: one of these days we'll give up on all these crazy ASICs and just use the signing chips in stolen passports as PoW |
| 00:24:37 | bramc: | ajweiss, No it's a meaningless proof of work like in bitcoin, but the meaningless proof of work has to do with demonstrating that you have storage space sitting around doing nothing rather than burning electricity |
| 00:24:48 | justanotheruser: | petertodd: isn't that a hearnism? |
| 00:24:58 | justanotheruser: | kanzure: who is that directed at? |
| 00:25:06 | kanzure: | justanotheruser: i was informing you about bramc's complaints |
| 00:25:24 | petertodd: | justanotheruser: not quite - I'm suggesting using the (slow!) speed they sign as a PoW (semi-seriously) |
| 00:25:41 | bramc: | justanotheruser, Nope, RAM is very small compared to disk, and it's set up so there are pauses between lookups, so speed of lookup doesn't matter |
| 00:25:57 | justanotheruser: | kanzure: I'm pointing out the possible optomizations. |
| 00:26:20 | justanotheruser: | bramc: what does "RAM is very small compared to disk" mean? |
| 00:26:23 | petertodd: | justanotheruser: the Android pin entry code key derivation function apparently uses a secure element/TPM thing that does HMAC against a secret, and just calls the secure element repeatedly |
| 00:26:26 | kanzure: | 23:34 < gmaxwell> I think with infinite parallel spow the benefit is actually infinite at least when everone's storage is also infinite. Basically you lose this round, but one of your next steps which takes episilon longer than the honest network, ends up with a perfect match, and then do the next set of SPOW in time 0 and end up producing infinite blocks before the honest network has produces two. |
| 00:26:30 | bramc: | The storage proof is basically finding a closest match very fast, which peers do by having a whole lot of things sorted on their hard drives |
| 00:26:40 | kanzure: | 23:36 < gmaxwell> Well the point of the infinite is to say that this process (at least when storage is sufficiently large) reduces to plain |
| 00:26:52 | bramc: | justanotheruser, For these proofs of work RAM won't do them any better than the same amount of disk will |
| 00:26:53 | kanzure: | aaaa |
| 00:26:56 | kanzure: | 23:36 < gmaxwell> Well the point of the infinite is to say that this process (at least when storage is sufficiently large) reduces to plain POW. |
| 00:27:55 | bramc: | kanzure, That's combatted by making it so there's nothing to parellelize, the thing you're trying to find closest match on for the next block is based on the key and spow for the last block and nothing else, and the spow is canonical |
| 00:27:58 | kanzure: | ( http://diyhpl.us/~bryan/papers2/bitcoin/Publicly%20verifiable%20proofs%20of%20sequential%20work.pdf ) |
| 00:28:29 | kanzure: | "nothing to parallelize" you still have spow |
| 00:28:55 | bramc: | Yeah but the spow is canonical, you can't do n of them in parallel and get n different outputs, it will give the same output every time |
| 00:29:49 | kanzure: | then what's the point of that function? |
| 00:29:57 | kanzure: | it must have a different output given a different input |
| 00:30:57 | bramc: | It's canonical on the input, obviously it varies based on the input. The input can be varied, but the only way it can vary is based on what signature was used last time, and using a different one makes the spow take longer |
| 00:31:46 | bramc: | I'm using a different and dumber spow than the one in that paper, because it isn't sufficiently canonical |
| 00:33:29 | kanzure: | taking longer doesn't seem to be very important- you could even run for the previous few blocks as well because you don't care about causing a reorg i think |
| 00:35:10 | kanzure: | (which gets you parallelism again (and reduction back to proof of work)) |
| 00:35:26 | bramc: | I've run through that and there's a potential advantage to mining pooling but it's small: about 15% if you have 1/3 of all mining capacity, 6% if you have 1/10th. The countervailing forces are that the mining operation is nonoutsourceable, and there's much more potential resources which can be used in mining because the marginal cost of using already extant resources for mining is nothing |
| 00:37:01 | bramc: | You don't really get parallelism because the alternate values fall behind because they're worse. The amount of time the proof of time takes is dependant on how close a match the last block's public key is, and there's usually a clear winner there where the non-winners will never catch up once they've fallen behind |
| 00:38:43 | bramc: | There's this goofy proof of work adjustment which is for an aggregate value per block where the quality of the block times the number of generations used in the proof of time must be greater than the current work difficulty threshold |
| 00:40:17 | bramc: | That has the property I was just talking about of making individual blocks win and also solves the very important problem that proof of work difficulty resets only have one value to go off of, which is amount of time taken in the previous period, so they can only reset a single value, which must be an aggregate when you're using two different work types. |
| 00:42:32 | bramc: | I have, in fact, taken the objections people raised before seriously and figured out how to fix them, although it does result in a bit of a contraption. |
| 00:44:22 | bramc: | Hopefully the stuff I'm describing doesn't sound like gibberish. It's hard to discuss these things without falling into custom jargon |
| 00:48:51 | bramc: | I'm also happy to keep answering questions, although this rathole continues for a while. |
| 00:50:27 | ryan-c: | ethereum screwed up deterministic nonces? |
| 00:51:03 | gmaxwell: | ryan-c: sure, why do you ask? |
| 00:51:24 | andytoshi: | ryan-c: https://github.com/obscuren/secp256k1-go/blob/master/secp256.go#L126-L161 |
| 00:51:26 | ryan-c: | gmaxwell: was just reading the scrollback |
| 00:51:40 | andytoshi: | line 130 in particular |
| 00:51:48 | ryan-c: | oh fuck |
| 00:51:56 | ryan-c: | what the hell |
| 00:52:03 | andytoshi: | :P it's actually stronger than it looks.. |
| 00:52:31 | gmaxwell: | ethereum's ether sale generated private keys by using math.random() (a 48 bit LCG seeded by time in firefox) and reading the mouse position something like three times in a tight loop... and then defeneded the scheme as a "best practice". |
| 00:52:59 | ryan-c: | andytoshi: I know that 'nonce = msg + seckey' leaks the private key |
| 00:53:14 | gmaxwell: | Anticipation of that kind of behavior is why the libsecp256k1 API makes it really hard to do that now (but they had a really old fork) |
| 00:53:31 | andytoshi: | ryan-c: yeah, this doesn't fall prey to that directly because xor plays hell with the field operations |
| 00:54:03 | andytoshi: | ryan-c: (i think) nickler has made more progress than me attacking this, but i don't yet have an attack that works with much less than 100 bits of work |
| 00:54:12 | bramc: | * bramc has an aneurysm |
| 00:54:41 | ryan-c: | I managed a working attack for 'nonce = msg + seckey' a few months ago, though I haven't seen anyone actually do that. |
| 00:54:57 | bramc: | The lack of so much as an API call for decent random numbers is a problem which goes back decades. And should have been solved long ago. |
| 00:55:51 | ryan-c: | (unrelated) anyone know where maaku is on utxo with coinbase commitment and if he's still working on it? |
| 00:56:01 | gmaxwell: | ryan-c: '+' in the group is more problematic than ^ on the seralizations. As ^ is not trivially algebraic in the group. ^ is still obviously insecure but making the attack pratical takes multiple signatures most likely. |
| 00:57:39 | ryan-c: | gmaxwell: Makes sense. |
| 00:57:46 | maaku: | ryan-c: yes. my employer is supporting finishing this work, but it's not a very high priority. i'm sorry that it has taken as long as it has, but work will continue |
| 00:58:04 | ryan-c: | maaku: Can I throw money at you to get it done sooner? |
| 00:58:29 | sipa: | i'm increasingly unconvinced that UTXO commitments are the right solution |
| 00:58:46 | sipa: | though part of the work - the commitment structure as such - is very valuable for many things |
| 00:59:05 | bramc: | What is this utxo commitment thing? |
| 00:59:30 | sipa: | bramc: have blocks commit to a merkleized tree set structure of the UTXO set |
| 00:59:32 | ryan-c: | sipa: My particular interest is using it to enable Namecoin light clients. |
| 00:59:45 | ryan-c: | bramc: UTXO = unspent transaction outputs |
| 01:00:15 | sipa: | bramc: so you can prove a particular coin still exists (or doesn't exist), as opposed to just being able to prove you've been paid at some point |
| 01:00:28 | bramc: | sipa, Ah, that, I've looked into it and am not convinced that it doesn't do more harm than good, because it creates a bunch more edge cases to look out for, the main benefit seems to be in proving over the light protocol that a particular utxo hasn't been spent yet |
| 01:00:49 | sipa: | it also adds huge extra costs for validation nodes |
| 01:01:11 | bramc: | Yeah those turn out to be bigger than expected |
| 01:01:13 | justanotheruser: | can a UTXO proof be constructed cheaply? |
| 01:01:15 | ryan-c: | (though we need a second utxo structure for authenticated denial) |
| 01:01:36 | ryan-c: | well, not utxo |
| 01:01:50 | bramc: | justanotheruser, depends what you mean by 'cheaply'. It turns out that the log(n) factor in the disk seeks necessary to do it is a bigger deal than you would guess up front |
| 01:03:41 | bramc: | After having spent a bunch of time looking into all the proposals I've seen links to, my conclusion has been that Gavin's wish list for what to fix is mostly right: http://www.reddit.com/r/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfp3xj |
| 01:03:42 | justanotheruser: | I mean is comparing each UTXO in your current copy and the merkle tree the fastest way to do it? |
| 01:04:05 | bramc: | justanotheruser, It's updating the merkle tree which gets expensive |
| 01:04:41 | bramc: | Because it's too big to fit in memory, and requires a whole bunch of seeks to update on disk |
| 01:05:35 | bramc: | To gavin's list I'd add 'simplify the damn acceptance language' because the only things which seems to matter for smart transactions are multisig, hash pre-image with length specification, and transaction timelock |
| 01:05:59 | justanotheruser: | acceptance language? |
| 01:06:13 | ryan-c: | justanotheruser: i think he means bitcoin script |
| 01:06:18 | bramc: | justanotheruser, p2sh |
| 01:06:44 | justanotheruser: | what about p2sh? |
| 01:06:53 | justanotheruser: | you mean Script? |
| 01:07:23 | bramc: | justanotheruser, Yeah the script, it's overly complicated with no clear benefit. All the proposed extensions are op_verify anyway |
| 01:08:07 | justanotheruser: | While Bitcoin is young, it is nice to be able to create new scripts without having to softfork |
| 01:08:55 | bramc: | There's a clear argument for being able to make new op_verify opcodes. There's no clear justification for having acceptance criteria more complicated than enumerated subsets of the verifies which can be used to pass |
| 01:09:04 | ryan-c: | I've had things I wanted to do that would require OP_CAT |
| 01:09:14 | ryan-c: | they may have been bad ideas |
| 01:09:23 | justanotheruser: | and OP_XOR would be nice |
| 01:09:33 | bramc: | ryan-c, and op_cat is one of those things which Isn't Going To Happen |
| 01:09:40 | ryan-c: | bramc: I know. |
| 01:09:44 | justanotheruser: | why not? |
| 01:10:10 | bramc: | justanotheruser, op_cat allows dos by making extremely large strings. |
| 01:10:30 | justanotheruser: | and if the strings can't be made extremely large? |
| 01:10:40 | bramc: | justanotheruser, In all seriousness if you know of an explanation for a smart transaction which would require xor I'd love to see a link |
| 01:11:31 | ryan-c: | oh, now i remember what i wanted to do |
| 01:11:43 | bramc: | justanotheruser, there's no agreement on what the max length should be |
| 01:11:57 | ryan-c: | have a script that could be redeemed either by a normal key or by multisig |
| 01:12:30 | bramc: | ryan-c, How is than not just a special case of multisig which allows a particular single key to work? |
| 01:12:53 | justanotheruser: | bramc: http://arxiv.org/abs/1402.3698 |
| 01:13:26 | bramc: | justanotheruser, that can be done using length specifications of hash preimages |
| 01:13:47 | ryan-c: | bramc: it isn't - is multisig with 1+N keys that requires either the 1 or M of N possible? |
| 01:14:30 | justanotheruser: | bramc: that's a hack |
| 01:15:35 | bramc: | ryan-c, uh... I assume it's trivial using script as it stands today. For what it's worth when I say 'multisig' I mean specifying a list of pubkeys and all the possible subsets of them which can be used to spend the utxo |
| 01:15:49 | justanotheruser: | afaics, it doesn't work for >2 people and the transactions become larger as your odds become smaller |
| 01:15:58 | bramc: | justanotheruser, It may be a hack, but it works just fine, and implemented correctly leaves little record of what was done on the block chain in the non-error case. |
| 01:15:59 | ryan-c: | bramc: I might not be remembering correctly. |
| 01:17:14 | bramc: | justanotheruser, Does work for >2 people, and with larger odds you can chain together multiple transactions, although it isn't a terribly elegant solution. But it does, you know, work, and require hardly anything in the protocol. |
| 01:18:00 | justanotheruser: | what does chaining together multiple transactinos accomplish? |
| 01:18:37 | bramc: | justanotheruser, instead of you having to guess a single number between 1 and a million, you have to guess six numbers between 1 and ten, presto under control transactions sizes |
| 01:19:14 | ryan-c: | bramc: can the numbers between one and ten be guessed separately? |
| 01:20:12 | bramc: | ryan-c, Yeah that's the idea they're based on different preimages, but the right answers have to be committed to in advance |
| 01:20:31 | justanotheruser: | thats pretty ineffecient. IT's better to just OP_XOR and check if it's below a certain value rather than paying for 6 transactions. |
| 01:20:51 | bramc: | justanotheruser, It also isn't a very important use case :-P |
| 01:21:04 | ryan-c: | oh, you're talking about stuff in the paper that i didn't read |
| 01:21:15 | justanotheruser: | It demonstrates that some opcodes have uses we may not know of yet though |
| 01:21:41 | bramc: | justanotheruser, that sort of functionality could also be crammed into a new op_verify |
| 01:22:04 | bramc: | ryan-c https://eprint.iacr.org/2013/784.pdf |
| 01:22:28 | ryan-c: | bramc: don't have time to read it right now, thanks though |
| 01:23:00 | justanotheruser: | yes, like I said, I agree in the long term that we should move to a simple scripting language where you just have a few op_verifies, but since that requires a softfork, for now it is better to allow these scripts to be discovered |
| 01:23:27 | bramc: | ryan-c, The summary is that you can hack gambling by using hash preimage length as your commitment technique, and you use a bunch of returns with timelock similarly to atomic transfers |
| 01:24:18 | bramc: | justanotheruser, To be clear I'm talking about what makes sense if you're doing stuff from scratch, not seriously proposing anything in Bitcoin per se be changed |
| 01:24:50 | justanotheruser: | yeah, satoshi did know how useless a lot of the opcodes would be though |
| 01:24:55 | ryan-c: | that reminds me of a CTF challenge I solved that required you to do a hash length extension attack against truncated hash |
| 01:25:12 | justanotheruser: | if bitcoin had to be remade today it probably would be very different |
| 01:25:30 | ryan-c: | (it was in the context of a "provably fair" casino) |
| 01:26:00 | ryan-c: | someone should make an altcoin with Script based on INTERCAL |
| 01:26:35 | bramc: | justanotheruser, Less different than you might think. The changes we're discussing are quite minor, and nobody has proposed a fully fleshed out convincing solution to the problem of scaling. Maybe sidechains will get there. |
| 01:27:35 | justanotheruser: | nah, it should be lisp based |
| 01:27:56 | bramc: | I also view the wastage of mining as a serious problem and claim to have a solution to that one, but you've seen how convinced people are of that one :-) |
| 01:28:24 | kanzure: | "but you've seen how convinced people are of [the wastage of mining]"? |
| 01:28:27 | justanotheruser: | mining isn't really wasteful since people are getting a valuable service and paying for it |
| 01:28:48 | ryan-c: | bramc: were you saying you had some inherently serial thing that couldn't be hardware accelerated effectively? |
| 01:28:55 | bramc: | kanzure, No you've seen how convinced people are that my claimed solution works |
| 01:29:03 | kanzure: | huh? |
| 01:29:19 | ryan-c: | i didn't read the scrollback very throughly |
| 01:29:21 | bramc: | kanzure, sarcasm, meaning they clearly aren't |
| 01:29:25 | kanzure: | why would i care what they think? |
| 01:30:31 | kanzure: | i forget what your objection was to the thermodynamic arguments for proof of work |
| 01:30:40 | bramc: | ryan-c, There are lots of inherently serial things which are hard to hardware accelerate effectively, but can of course be done somewhat. The idea is that multiple parties will run very accelerated hardware to keep each other from getting an unfair advantage and wind up in a stalemate |
| 01:30:53 | kanzure: | i remember something like you refusing to address an argument |
| 01:31:14 | bramc: | kanzure, The idea is that there's far more depreciation of storage out there than mining rewards |
| 01:31:20 | ryan-c: | bramc: the stalemate thing sounds like how mining is already |
| 01:31:34 | kanzure: | bramc: mgo on |
| 01:31:39 | kanzure: | -m |
| 01:31:54 | bramc: | No I did in fact address that argument, the arguments around how people can't weasel around my proofs of work by doing some parallelization are much more subtle |
| 01:32:31 | bramc: | ryan-c, Yes it's very similar, although in this case instead of a huge number of people burning lots of resources on the fast CPU stuff it's just a few machines running while everybody else waits |
| 01:32:37 | kanzure: | that was not the argument i was talking about |
| 01:32:51 | kanzure: | i remember asking you why you thought asic resistance was useful and your response was "i'm not even going to dignify that with a comment" |
| 01:33:23 | kanzure: | 17:30 < kanzure> i forget what your objection was to the thermodynamic arguments for proof of work |
| 01:33:42 | kanzure: | this was an accurate on-topic reply that could have gone somewhere: |
| 01:33:43 | kanzure: | 17:31 < bramc> kanzure, The idea is that there's far more depreciation of storage out there than mining rewards |
| 01:33:49 | bramc: | kanzure, Oh it's because there's nothing in the main part of mining which requires much of any CPU |
| 01:34:05 | bramc: | kanzure, hold on, two very different points here |
| 01:34:07 | kanzure: | in your system? |
| 01:36:23 | bramc: | The higher level point is the economic one about storage depreciation vs mining rewards. If mining is entirely dependent on proofs of storage and anyone who already has depreciating storage has to spend literally nothing on doing the mining then noone will ever acquire new resources specifically to do mining because they'll lose money on it |
| 01:36:55 | kanzure: | why is it important they lose money on it? |
| 01:37:00 | adam3us: | bramc: is this another attempt to repair proof of stake? |
| 01:37:06 | kanzure: | adam3us: no |
| 01:37:27 | adam3us: | bramc: ok then is it a variant of memory hard, like tromp's cuckoo cycle pow? |
| 01:37:31 | bramc: | adam3us, No! No proofs of stake! This is all about shifting around the form of the proofs of, uh, 'work' |
| 01:37:38 | kanzure: | adam3us: around 23:04 http://gnusha.org/bitcoin-wizards/2015-01-01.log |
| 01:37:47 | kanzure: | or uh earlier |
| 01:38:19 | bramc: | adam3us, no the proof of work is nothing like cuckoo. It's actually much simpler |
| 01:38:32 | kanzure: | http://diyhpl.us/~bryan/papers2/bitcoin/Publicly%20verifiable%20proofs%20of%20sequential%20work.pdf |
| 01:39:11 | bramc: | kanzure, What I'm using is even dumber than that, it's just a straightforward sequential operation with checkpoints along the way included in the actual proof so it can be spot checked |
| 01:39:26 | kanzure: | yes you already mentioned that today |
| 01:39:31 | adam3us: | sequential? ah yes, i have applications for those. |
| 01:39:48 | adam3us: | well more time-lock decryption which is related |
| 01:40:37 | bramc: | adam3us, the proof of work is to find the closest match to the hash of the previous proof of time. To do this everybody has a whole bunch of them stored in sorted order on their hard drive and goes and looks up the closest match |
| 01:41:23 | bramc: | Then whoever has the best match mints a new block and everybody sits around waiting for the next proof of time to be done. |
| 01:42:21 | bramc: | adam3us, cuckoo-like things don't really work because they use enough electricity that the electricity winds up being the limiting factor anyway. To move from electricity limited to resource limited it really needs to use *no* electricity. |
| 01:42:22 | adam3us: | bramc: oh yeah; did you see rivests micromint protocol based on k-way collisions? they keep buckets of collisions as its a generalisation of a birthday attack. |
| 01:43:55 | bramc: | adam3us, no I'll have to read through that |
| 01:44:48 | bramc: | adam3us, in my scheme the match quality is based on the hash of a public key and it's only accepted if it comes with a signature on a new block |
| 01:45:39 | adam3us: | bramc: yeah ic. micromint is only slightly related probably. they gain advantage overtime by storing large amounts of k-way collision candidates |
| 01:47:20 | bramc: | adam3us, My thing is most closely related to amiller's nonoutsourcability |
| 01:47:41 | bramc: | As a result it happens to be very resistant to outsourcing |
| 01:47:43 | kanzure: | 22:34 < bramc> adam3us, There's plenty of hardware sitting around depreciating all the time. If the costs of mining were adjusted to be primarily hardware depreciation then the amount of new investment in mining would go down, and it would be relying primarily on sunk costs |
| 01:47:48 | kanzure: | 22:34 < adam3us> bramc: if coins have a production cost below their value, rational economic actors will spend up to the market value chasing it. if thats via politics, buying or bribing stake holders (pos) etc |
| 01:47:52 | kanzure: | 22:35 < adam3us> bramc: i dont think my arguments change. its economic fundamental of commodity pricing. |
| 01:47:55 | kanzure: | haven't we been through this time loop before |
| 01:48:26 | bramc: | kanzure, Sort of, I didn't do the greatest job explaining my argument before |
| 01:48:47 | kanzure: | yes i'm trying to do you justice by finding the exact argument that was given to you |
| 01:49:02 | phantomcircuit: | kanzure, to achieve the sunk costs model you need the efficiency of the hardware to change significantly as the amount of work being done drops |
| 01:49:30 | phantomcircuit: | that's mostly only true of existing hardware in theory now |
| 01:50:13 | bramc: | kanzure, And there are a bunch of much more involved cat and mouse games where an attacker tries to do stuff in parallel to use cpu to their advantage which I didn't have good answers for before. That argument was mostly a highly technical one between me and gmaxwell where he was shitting on what I was saying but there weren't nice sound bites on either side |
| 01:51:25 | kanzure: | actually what i'm looking for is the argument given to you about scarcity being used to secure decentralized consensus, which then got turned into an argument about necessary properties like progress freeness, etc |
| 01:52:05 | kanzure: | (something involving a complaint about waste..?) |
| 01:52:07 | bramc: | kanzure, I'm still using mining rewards which are doled out proportianately to resources put in! |
| 01:53:11 | bramc: | It's just that the resources are depreciating storage rather than electricity, on the grounds that that can be done with no increase in marginal spend |
| 01:53:41 | kanzure: | "But none of that is an understanding of Bitcoin. Bitcoins aren't produced from work, they're just handed out by the system. The work in bitcoin exists to provide security, and there no spurrious economic argument exists." |
| 01:53:57 | kanzure: | i don't know why you are bringing up proportionality to resource input(?) |
| 01:54:22 | kanzure: | -( -) |
| 01:54:42 | bramc: | kanzure, at points I'm honestly not sure what you're trying to say |
| 01:55:30 | kanzure: | yeah i suppose i have muddled this a little bit; i keep trying to probe you about why you think pow is wasteful, and then i was trying to remember some other argument about depreciation. |
| 01:55:34 | kanzure: | sorry |
| 01:56:08 | phantomcircuit: | pow is wasteful |
| 01:56:14 | phantomcircuit: | but the alternatives dont work |
| 01:56:27 | kanzure: | that's easy when you don't offer a definition |
| 01:56:48 | phantomcircuit: | it's the only option |
| 01:56:57 | phantomcircuit: | it is thus by definition not wasteful as there is no other option |
| 01:57:08 | bramc: | There's this argument about waste in bitcoin being unavoidable, in that if that the value of mining rewards is X dollars, then exactly X dollars with of resources will be blown mining them, and that will generally be in the form of electricity. My counter is that if you engineer things carefully instead of new resources being spent on mining, mining can only be done by demonstrating usage of resources you were wasting an |
| 01:57:08 | bramc: | yway, and if the value of those resources is greater than X then no *additional* waste will happen to do mining |
| 01:57:33 | adam3us: | i guess if u use less resources per unit of participation you'll end up with more units and equal aggregate cost (the quote above that kanzure posted about "if coins have a production cost below their value, rational economic actors will spend up to the market value chasing it. " |
| 01:57:33 | kanzure: | do you see why or how "bitcoins aren't produced from work"? |
| 01:58:00 | bramc: | In this case, the resources already wasted is that there's hard drive capacity sitting out there doing nothing. |
| 01:58:29 | bramc: | kanzure, I don't see what the point of that semantic distinction is |
| 01:59:14 | adam3us: | bramc: the security comes from the cost of the forgone alternative; a fully reusable or sunk cost may provide no security |
| 01:59:46 | tromp: | what's the electricity cost of filling 100TB of hard disk space with sorted hashes? |
| 01:59:59 | bramc: | adam3us, Oh it isn't reusable exactly because the work is storage space times time, and you can't manufacture extra time |
| 02:00:08 | kanzure: | tromp: arguably that doesn't matter |
| 02:00:11 | bramc: | tromp, small |
| 02:00:26 | ryan-c: | tromp: Funny you should ask, I have about 40TB of drives filled with sorted hashes. |
| 02:00:52 | bramc: | ryan-c, if I may ask a stupid question, why? |
| 02:01:09 | kanzure: | rainbow tables, i'd guess |
| 02:01:10 | ryan-c: | bramc: I'm running a birthday attack on something. |
| 02:01:36 | ryan-c: | (really need to finish that project...) |
| 02:01:40 | bramc: | tromp, it requires a little bit of cleverness to do it in only a few passes over the hard drive because memory is so small by comparison |
| 02:02:02 | adam3us: | bramc: right so its not fully reusable because the disks cost money to manufacture, store and operate. if the cost per unit participation (per disk say) is low there will be lots of disks participating. |
| 02:02:31 | ryan-c: | bramc, tromp yeah, much pain in the ass. I used a merge sort that does delta compression on each pass. |
| 02:02:56 | ryan-c: | hard disks are cheap to run |
| 02:03:10 | ryan-c: | 5-10W |
| 02:03:20 | bramc: | adam3us, Yeah the idea is to keep the costs per unit participating as low as possible. Someone might have a massive rack of drives which are all spun down then when they want to look up they spin up the relevant drive, do the lookup, and spin it back down again |
| 02:03:40 | tromp: | every new computer comes with a hard disk that takes years to fill up. might as well use that space until actually needed |
| 02:03:45 | ryan-c: | maybe a dollar or two per month to run a low power drive |
| 02:03:57 | bramc: | tromp, yes exactly |
| 02:04:04 | ryan-c: | (keeping it spun up) |
| 02:04:06 | kanzure: | "might as well ues the space to do x" is not a security argument and is boring |
| 02:04:18 | kanzure: | that has nothing to do with whether or not it achieves consensus |
| 02:04:30 | kanzure: | nobody cares if it's a hard drive or a rhinocerus, as long as it works |
| 02:04:44 | bramc: | kanzure, the consensus part is straightforward: the best match wins |
| 02:05:14 | bramc: | Over time you have a series of completed blocks, consisting of match/proof of time/match/proof of time |
| 02:05:16 | kanzure: | i don't see how that fits into the same problem domain as something like "a fully reusable or sunk cost may provide no security" |
| 02:05:27 | kanzure: | "best match" is not a security argumet |
| 02:05:31 | kanzure: | argument |
| 02:05:40 | ryan-c: | I have a server at my apartment with 12 disks in it, and I keep them spun down as much as possible. |
| 02:06:12 | bramc: | So someone else can't catch up, because they have less storage space than the system as a whole, and no more time |
| 02:06:15 | kanzure: | bramc: i'm only harsh because i love you |
| 02:06:18 | kanzure: | just fyi |
| 02:06:44 | bramc: | kanzure, I'm trying to make a coherent but subtle technical argument here and it seems like I'm not being very clear |
| 02:07:04 | kanzure: | yes something about parallel time not existing |
| 02:08:15 | bramc: | Let's say that the current work factor is 10^40 |
| 02:08:55 | bramc: | The network as a whole has 10^20 storage, while you little peon that you are have a mere 10^19 of storage. |
| 02:09:36 | kanzure: | (why do i have storage? why not giant spow farm?) |
| 02:09:51 | bramc: | For each block, the networks proof of storage will on average be worth ten times as much as yours |
| 02:09:57 | adam3us: | bramc: imagine lets say bitcoin farms total cost $500m and are using say $100m of elec, and over time the balance moves more torwards pure elec because manufacture is cheap. the disk farm would tend towards having hirer storage cost (more bulky) lower electricity cost (maybe can spin down) and some reuse (use end of life disks) |
| 02:10:44 | bramc: | kanzure, hold on for a sec on the spow farm, I can only type so fast |
| 02:11:02 | kanzure: | http://www.seanwrona.com/typeracer/profile.php?username=kanzure |
| 02:12:24 | bramc: | So if your spow takes about as long as the fastest spow on the network, it will take you ten times as long to complete blocks on average, and you'll fall behind the rest of the network quite rapidly unless you get really lucky, and the amount of lucky you need goes up exponentially as you fall further behind |
| 02:12:26 | adam3us: | bramc: i think you'd want to estimate the number of disks that would be supported by the reward |
| 02:12:41 | bramc: | adam3us, hold on I can only type so fast |
| 02:13:07 | adam3us: | bramc: probably it exhausts production capacity. faster man :) |
| 02:13:22 | kanzure: | if you are interested i know of some drugs that increase typing speed |
| 02:13:53 | kanzure: | adam3us: i'm not sure reward support is very important? |
| 02:14:21 | bramc: | kanzure, Now about the spow farm point. This is an important and subtle one. The challenge algorithm is set up so that it's dependent on (1) the previous block (2) the spow, (3) the current work factor and (4) absolutely nothing else. It's very important that the spow is canonical and the hash of the public key for the block determines its match value so malleability doesn't matter |
| 02:14:22 | adam3us: | kanzure: reward is subsidising security. we hope even in the long run that fees pay enough to provide adequate security. |
| 02:15:10 | kanzure: | adam3us: well i mean, if you have a decentralized security argument similar to some consensus set of nodes operating still, then the subsidy is worthy of investigation, but not before |
| 02:15:26 | adam3us: | bramc: i guess this spow execution time s chosen to be >> a block interval |
| 02:16:06 | bramc: | So you can calculate spows in parallel, but you'll be doing it off of not as good matches to the last block, so they'll finish after and you're basically just hoping that you'll get really lucky on the generation after so it gets ahead of the best head overall which of course is increasingly unlikely based on how little of the general storage you have and how bad of a match you used for the previous generation |
| 02:16:23 | bramc: | adam3us, the spow execution time *is* the block interval |
| 02:16:42 | kanzure: | do you mean equal to, or some other semantic intent |
| 02:17:09 | adam3us: | bramc: just wondering about time security |
| 02:17:13 | bramc: | I mean a block isn't complete until it has the corresponding spow, and once it does have the spow the next block can be found |
| 02:18:15 | bramc: | kanzure, so I've run the numbers on it, and it turns out that the advantage you get by running multiple spow in parallel is finite, because the alternate matches tend to be so bad. Not only finite but small. |
| 02:18:25 | adam3us: | bramc: i thought the disks were filled with spows, maybe not. there will be variance in spow execution speed based on overclocking if there is a strong advantage to finishing first |
| 02:18:44 | bramc: | adam3us, Oh no, the spow is dependent on an input, so you can't precompute them |
| 02:19:12 | adam3us: | bramc: so who computes the spow and does it matter who completes it first? |
| 02:19:55 | bramc: | adam3us, there's some advantage to getting a spow done first, which is why there's no explicit reward for doing it. The idea is that multiple miners are each trying to get a head and they wind up all finishing close to the same time on their spow in a sort of mutually assured destruction |
| 02:20:12 | bramc: | (I did say that this thing is a bit of a contraption) |
| 02:21:48 | bramc: | It doesn't matter who completes the spow first because it's canonical, you can't even tell who completed it first. A miner who has a fair amount of mining capacity and a faster spow than everybody else can get a small advantage by not releasing the spow immediately and getting to work on their own best match for the next block early so they can win in case of a near tie |
| 02:21:59 | adam3us: | bramc: ok so you accept the closest hash match within a time-interval. i am wondering if htere is a nothing at stake risk that i can continue to try find closer matches well into the next block interval to reorg the block by finding a higher pow one later. |
| 02:22:59 | bramc: | adam3us, You can of course grind through generating new keys in memory, that's sufficiently slow to be not worth it though: The sheer size of hard drives is important here |
| 02:23:02 | adam3us: | bramc: bearing in mind that it is the pow that enforces non-history-rewriting as there is a forgone alternative |
| 02:23:28 | adam3us: | bramc: ok so thats paramterised such that its not worth it |
| 02:24:26 | bramc: | adam3us, Yeah one could be cute and require extra work be done on the hash of the public key to prevent grinding but it turns out that the amount of work necessary to generate public keys gets it about right anyway |
| 02:25:10 | adam3us: | bramc: so lets pretend for analysis that there is a trusted oracle that is broadcasting a beacon (random chosen value) which this construct approximates, and people just publish their best bet and move on. |
| 02:25:20 | bramc: | Although of course I'll have to do some actual measurements on that |
| 02:25:52 | adam3us: | bramc: but over time there will be new disks. say capacity doubles 2 weeks later, could they then find a closer hash to the beacon from 2 weeks ago and reorg 2 weeks work? |
| 02:26:51 | bramc: | adam3us, It's important that the amount of time it takes for the beacon to broadcast is dependent on how good the previous match was |
| 02:27:51 | bramc: | adam3us, It's like in Bitcoin. Hash capacity greater than what existed at the beginning of the block chain exists easily today, and you could redo up to the current point in not too long, but by then everybody else would have gotten farther along. |
| 02:28:00 | bramc: | That aspect of the whole thing is unchanged. |
| 02:33:37 | bramc: | This is, in fact, mining. |
| 02:36:04 | bramc: | Given the sudden lack of questions, clearly I've now convinced everyone :-) |
| 02:37:33 | bramc: | (But there are some important and not completely trivial details necessary for it to work which i haven't explained yet, not even badly) |
| 02:38:14 | kanzure: | my telepathic link to adam3us seems to be working so i will continue to lazily rely on him to word my complaints |
| 02:41:24 | adam3us: | i think u need to define what it is that prevents indefinite long range historic reorgs from future growth in computational capacity |
| 02:41:27 | bramc: | I'm afk for a few. Feeding the pet hairless apes. |
| 02:42:01 | bramc: | adam3us, It's storage space times time |
| 02:43:06 | bramc: | The value of a block chain is the integral of the storage that went in over the course of its history (with a bunch of noise added, again much like in Bitcoin) |
| 03:37:47 | bramc: | Okay, the apes have been fed and are happy |
| 03:38:13 | kanzure: | not convinced about your dimensional analysis (particularly the one about time) |
| 03:38:46 | bramc: | It isn't that different from Bitcoin, which is based on number of CPUs times time |
| 03:39:51 | kanzure: | that doesn't make sense |
| 03:40:03 | kanzure: | i don't think that's a valid reduction? |
| 03:40:27 | bramc: | Sure it is. The number of hashes you'll have is the integral of the hashing capacity over time |
| 03:43:38 | bramc: | There's also energy consumed, but that isn't what's keeping anyone from getting ahead. What's keeping people from getting ahead is their capacity limitations. |
| 06:02:09 | op_mul: | bramc: I don't think that's accurate either. you can see bitcoin blocks as a measure of hash-time only because the hashes can't be retroactively moved to a different chain. with this sort of "proof of capacity" type design the proof can be moved to any chain the user wants, making it really proof of nothing at all. |
| 06:02:57 | op_mul: | there's an alt coin currently that exists using something like this. precomputed lookup tables which every block, the user scans and looks for low hashes. the system "works" up to a point, but it completely breaks down when you realise that the work can be ground just like proof of stake. |
| 06:03:13 | bramc: | op_mul, No the proofs can't be moved around. Each successive proof in the chain directly references the one before it by hash and can't be moved around |
| 06:04:02 | bramc: | Although, yeah, there's a fair amount of subtlety in making it so that grinding can't be done, which I explained how that works earlier, although likely not very well. |
| 06:05:23 | adam3us: | bramc: the thing is with this pow i think there is not much disincentive to repeatedly try to rewrite history as storage grows. unless there is checkpointing or something centralising that remains a risk. and this is because there isnt really a cost to mining - its quite proof of stake like in restricting a node to voting once per time-interval. (but with a put your current best vote forward). |
| 06:06:01 | adam3us: | bramc: what if the networks capacity doubles in 2 weeks and then there is a non-negligible chance that someone can collect slightly better pows (closer to the target) from a point in the past |
| 06:06:21 | op_mul: | that doesn't much mesh with my understanding of proof of work particularly very well. I need to be more versed in moon math, or high, or something. I don't see how proof of time can exist the way it's been described. |
| 06:07:21 | justanotheruser: | What is a proof of time? |
| 06:07:27 | op_mul: | the straight forward method of what you are saying is that Proof of Capacity stuff, which is just trivial to grind the crap out of and isn't a method of distributed consensus. |
| 06:07:28 | bramc: | adam3us, You can't catch up unless you have a conspiracy of the entire network. The current network is progressing at a rate determined by all the current capacity, where the retroactive work is progressing at a rate determined by the capacity of whoever's trying to do it, so it's always falling behind |
| 06:08:10 | bramc: | adam3us, reward times are noisy but in *exactly* the same way as Bitcoin rewards are noisy |
| 06:08:20 | op_mul: | justanotheruser: no idea man. this is what I'm reading. https://botbot.me/freenode/bitcoin-wizards/2015-02-14/?msg=31971068&page=2 |
| 06:08:22 | adam3us: | bramc: sipa has a graph of days to replace bitcoin history, surprisingly it was as low as 50 days at times because of fast hashrate increase. |
| 06:09:35 | phantomcircuit: | adam3us, i've been wondering for a while whether you can do a pow in which you burn coins to get tokens that give you the right to build a block 100 blocks after that block |
| 06:09:37 | sipa: | http://bitcoin.sipa.be/powdays-50k.png |
| 06:09:47 | bramc: | It's a little bit less resistant to history rewriting than bitcoin is because in bitcoin when someone is mining they have to do either current mining or historical rewriting but can't parallelize both, but that doesn't matter all that much |
| 06:10:01 | adam3us: | bramc: but here its sort of like proof of stake turning into a proof of work, any rational attacker (dishonest but rational) might as well use spare disk access capacity once they have increased their disk capacity might as well have a go at rewriting history - the extra disk lookups are basically free |
| 06:10:08 | phantomcircuit: | at first glance it has all the same economic incentives as true pow mining except is missing things like capital expenditure |
| 06:10:18 | sipa: | http://bitcoin.sipa.be/powdays-ever.png |
| 06:10:45 | op_mul: | phantomcircuit: that sounds a little weak from the out set. presumably you can burn the coins on one chain and then mine on an alternate one? |
| 06:11:12 | bramc: | Proofs of time are very simple: You take a value, and hash it N times for some N, and the result is the proof of time. The problem with that trivial scheme is that it takes just as long to verify as it does to generate, so you store checkpoints along the way and when someone gets a proof they spot check it and if any problems are noticed they report it to whoever sent it to them. |
| 06:11:25 | adam3us: | bramc: i think u may be assuming a slightly weaker threat model like honest majority where bitcoin somewhat aims for economic rational majority (they lose money because of the forgone alternative cost). the alternative cost to regrind history is missing because of the excess lookup disk IO bandwidth |
| 06:11:38 | phantomcircuit: | op_mul, thus the delay |
| 06:12:09 | phantomcircuit: | it gives a very strong incentive not to generate an orphaned block |
| 06:12:16 | adam3us: | phantomcircuit: maybe you can make a synthetic miner that imitates capital ownership |
| 06:12:52 | bramc: | adam3us, No it fails at the same point bitcoin does, when half the capacity decides to defect. That capacity has to stop participating in the main chain for it to work or they're working against themselves. |
| 06:13:18 | op_mul: | phantomcircuit: better idea: make miners with remote control thermite in them. if the manufacturer thinks you're being bad with their hardware you get to scrape the melted miner off the DC floor :P |
| 06:13:29 | phantomcircuit: | ha |
| 06:13:42 | adam3us: | bramc: but like you're assuming this behavior is stable; its also stable for all miners to constantly attack history and they have a small incentive to do so and its undetectable and zero cost. this is why PoS degrades to alternate history grinding |
| 06:13:52 | phantomcircuit: | adam3us, if you try you end up with s weird PoS looking PoB system |
| 06:13:57 | bramc: | op_mul, the thing I'm describing most definitely has consensus building: The chain with the highest work factor wins. Same as anything else with mining. Although the calculation of work factor is slightly more complicated. |
| 06:14:14 | phantomcircuit: | ie you need to burn 10x to mine 1 but that only consumes having burned 1 so it's 1:1 but with 10x risk |
| 06:14:36 | op_mul: | bramc: I don't see how that scheme proves time at all, to be quite honest. it seems like it would devalue into someone just making a multi gigahertz FPGA and faking "time". |
| 06:14:57 | bramc: | adam3us, Attacking the history just keeps falling behind unless everybody's doing it as one giant conspiracy. |
| 06:15:53 | phantomcircuit: | adam3us, this of course does lose a few of the inherent decentralization effects of electricity based mining |
| 06:15:54 | bramc: | op_mul, There are likely to be several counterparties who do in fact run very fast time provers, but the strategy is that the best match is spammed out to everybody and then people with fast time provers all run on the best thing they can find to keep each other honest |
| 06:15:57 | adam3us: | bramc: right but thats what i mean about stable strategy, that is actually what people end up doing with PoS - the protocol for honest mining says vote once per interval, but there's another protocol that says you get an advantage by simultaneously trying permutations of history that you'll increase your chance of winning |
| 06:16:33 | adam3us: | phantomcircuit: not sure elec based decentralisation is on a winning streak right now :| |
| 06:17:36 | op_mul: | bramc: I don't think that's a good assumption at all. someone with a fast FPGA and a big bag of dry ice would be able to tear through that particular proof type in an unsustainable way. |
| 06:17:40 | bramc: | adam3us, I've worked through this in detail and with the very specific way of calculating work factor I have it just doesn't work. If you take your second, third, fourth, etc. best matches their quality degrades so quickly that they become essentially worthless. |
| 06:18:25 | bramc: | op_mul, Did you read through the whole discussion previously about the alternating between work types and multiplying for the aggregate work factor? The details are subtle and important. |
| 06:19:01 | phantomcircuit: | adam3us, heh |
| 06:19:06 | phantomcircuit: | adam3us, there's at least a delay |
| 06:20:07 | adam3us: | phantomcircuit: i was thinking of a coingen variant where the coins are virtual, and no electricity is used; via a provably fair central server protocol - eg you buy some mining research and get a quantum miner, sort of randomized tech, success ratio etc, gamify it like d&d dice etc |
| 06:20:30 | op_mul: | adam3us: no no, do it like Spore |
| 06:20:33 | adam3us: | phantomcircuit: use the saved electricity (being paid to the server) for some socially redeeming purpose |
| 06:20:45 | phantomcircuit: | heh |
| 06:20:59 | bramc: | *sigh* |
| 06:21:11 | phantomcircuit: | something deliciously ironic about you suggesting to replace hash based pow with something else |
| 06:21:12 | phantomcircuit: | :P |
| 06:21:16 | adam3us: | bramc: maybe the attack is clearer if we look at a large hashrate difference from a rapid mining escalation, or mining compared over a long period. |
| 06:22:29 | adam3us: | bramc: say its 1 years later and there is 1million x more storage online. now as well as trying to stay up each miner adopts the alternate strategy of trying to rewrite all history. |
| 06:22:53 | bramc: | adam3us, It all doesn't matter. If you pick a point in the past and mine forward from that, you can only add work factor to the chain at a rate dependent on your storage capacity, and if your storage capacity is less than the storage capacity of the current network, you're still falling behind |
| 06:22:55 | adam3us: | bramc: ok maybe i am missing the effect of the time-lock |
| 06:23:43 | adam3us: | bramc: so the timelock is like a deterministic serialisable but efficiently verifiable proof of work that connects one block to the challenge for the next block? |
| 06:23:55 | bramc: | There's this important detail: The amount of time it takes to do the proof of time is inversely proportional to the quality of the proof of storage |
| 06:24:37 | bramc: | adam3us, Yes, there are goofy caveats and cheats but that's basically it. |
| 06:25:10 | adam3us: | bramc: you have to grind harder on the spow to use a closer sorted hash value? |
| 06:26:04 | bramc: | adam3us, You can't grind on the spow, it's deterministic on the sorted hash value used. You can only grind on the sorted hash values, and the problem there is that the less good ones are (usually) a lot less good |
| 06:26:34 | bramc: | Their distribution is in fact exactly the same as the distribution of how long it takes to mint a block in bitcoin |
| 06:26:52 | bramc: | (well, asymptotically so close that you can't tell the difference anyway) |
| 06:28:13 | bramc: | You take a hash, put a decimal point in front of it, multiply that by the current mining difficulty, and that tells you the number of iterations which the proof of time has to go through to complete the block. |
| 06:28:27 | adam3us: | bramc: yes but i am thinking of rewriting history at a point from the future where the storage capacity is 1mil x current say. then i could rewrite history easily. however i think that creates a different spow challenge which is the network heartbeat so then you dont catchup |
| 06:29:29 | bramc: | You can rewrite history easily but it's like rewriting bitcoin history: I can easily make a chain which gives me the first few years's worth of coins, which is most of them, but it loses because its total work factor is less than what the network as a whole has generated. |
| 06:29:32 | adam3us: | bramc: grind i didnt mean to search alternates, just that i am assuming the spow deterministically starts from the best solution to the last block. and because you said you have to work harder if your closest match was weak |
| 06:30:20 | adam3us: | bramc: well in bitcoin with < 50% of hashrate you basically cant catchup and you lose money fast with < 50% doing that from the forgone reward |
| 06:31:13 | adam3us: | bramc: i am not sure how it works with your system but unless fresh spows' take effect slowing down the historiy rewrite someone with a future much larger storage can maybe catchup or repeatedly try until they get lucky |
| 06:32:38 | bramc: | adam3us, Yeah same thing happens, although there's the caveat that you can participate in the current chain and try alternate histories in parallel, which creates a small advantage to larger pools because they have a greater chance of getting lucky and overtaking. They fall behind so fast that the effect is small though, and it's counterbalanced by the proofs being nonoutsourceable. |
| 06:35:05 | bramc: | The repeated trying, as I keep trying to explain, doesn't work, because if you take the chances that your second, third, fourth, etc. best matches will overtake on the next generation the sum is not only finite, it's small |
| 06:35:52 | bramc: | You really get obliterated by the expected quality of your follow-on match being based on your own storage capacity, which of course is less than the network as a whole. |
| 06:37:18 | adam3us: | bramc: i suppose you would repeatedly gind the disk in the background to also make the hashes closer to equidistant to improve your odds a little |
| 06:37:23 | bramc: | and, uh, yeah, the spow is based directly off the previous history. If you change a match used at one point every subsequent spow must be redone from scratch |
| 06:39:10 | adam3us: | bramc: right that maybe by itself mostly kills history rewriting, though perhaps someone can make an asic and liquid nitrogen cool it |
| 06:39:12 | bramc: | adam3us, unless you're close to half the capacity of the network as a whole that's unlikely to matter. There are somewhat crazier tricks where you can squeeze out a bit more virtual space out of your storage media in exchange for a bit more CPU though. |
| 06:40:09 | adam3us: | bramc: the usual time-memory tradeofss (TMTO) yeah. they can bite you though… momentum pow was weakened by that, scrypt also has TMTOs |
| 06:40:27 | bramc: | adam3us, if somebody has a faster spow they have a much more straightforward attack where they win more of the current mining by making themselves win in the event of a near tie. That one winds up being a lot like making ASICs: multiple people can do it but they wind up in a stalemate |
| 06:40:28 | adam3us: | bramc: anyway everyone can run that algo so its not a trap door advantage |
| 06:41:25 | bramc: | Anyone with any significant mining capacity has an incentive to run their own accelerated spow server on the best match they get just to keep anybody else from getting ahead. |
| 06:41:39 | adam3us: | bramc: also i suppose there is nothing stopping you trying hundreds of spow alternate histories in parallel so luck can be searched for more widely |
| 06:42:15 | bramc: | adam3us, Yes you can do that but like I said the chances of any of them catching up are so low that it hardly matters |
| 06:43:30 | adam3us: | bramc: the more convincing argument on that is if big miners have their own liquid nitrogen asic spow chip and are fighting with the history rewriters |
| 06:44:29 | op_mul: | adam3us: if you assume that the network is on a level playing field you can have them making multiple attempts at once, which is interesting. |
| 06:44:34 | bramc: | adam3us, the spow resources are pooled: everybody takes the best match they has and publishes it and the best one gets distributed everywhere, and the spow servers all get to work on that and send out the proof of time as quickly as they can |
| 06:45:20 | adam3us: | bramc: but maybe they will keep it secret if there is selfish time advantage to doing that |
| 06:45:33 | bramc: | So if you have the very fastest spow server you can use it to get ahead a little, but if you have the second fastest you can use it to undermine the very fastest. |
| 06:45:45 | phantomcircuit: | adam3us, huh |
| 06:45:57 | phantomcircuit: | i think the PoB mining might actually be incentives compatible |
| 06:46:17 | phantomcircuit: | ooh i remember what im missing |
| 06:46:23 | phantomcircuit: | delays |
| 06:46:33 | bramc: | adam3us, It does create an interesting oligopoly situation |
| 06:47:44 | bramc: | I'm expecting/hoping that it's very expensive to get a speed advantage over the obvious approaches and that the advantage you gain isn't really all that much. This is analogous to how efficient people can make ASICs of course. If someone could make an ASIC 100x as efficient as everybody else's in bitcoin they could rule the whole network |
| 06:48:07 | op_mul: | efficient? don't you just want raw speed? |
| 06:48:10 | bramc: | phantomcircuit, Proof of Boron? |
| 06:48:28 | bramc: | op_mul, no the costs are mostly determined by electricity usage |
| 06:48:32 | op_mul: | if you let me throw efficiency out the window and a big enough tank of LN2, we're going to the moon. |
| 06:48:43 | op_mul: | hm. |
| 06:48:48 | bramc: | I mean for Bitcoin mining, not for proofs of time |
| 06:48:52 | op_mul: | ah |
| 06:49:14 | bramc: | obviously for proofs of time all that matters is speed, my point is that the risks of somebody coming up with fundamentally better technology are analogous. |
| 06:50:17 | adam3us: | bramc: similar yes. here the single core speed optimisation gives the miner a linear speed up on their history rewriting so they might gain something by being 2x-5x as fast which might be possible |
| 06:50:42 | adam3us: | bramc: but anyway presumably competitors would move forward in parallel of having fast spow chips |
| 06:51:47 | bramc: | adam3us, That's the hope, yes |
| 06:52:58 | bramc: | The whole thing is a bit of an experiment. Of course so is Bitcoin. |
| 06:53:20 | op_mul: | sort of feels like the network would just boil down (haha) to liquid nitrogen, but it would be fun to get to play with hardware again. |
| 06:54:05 | bramc: | op_mul, I feel a lot better about subsidizing the development of chips with faster clock rates than ASICs which pile on more sha1 calculations |
| 06:56:27 | gmaxwell: | in the context of sequential mining faster clock rates probably means make 10,000 copies of the same circuit; and drive them at 200% of the clockrate any sensible logic would run at, and find that only 2 of the 10,000 gave a correct result at the end. |
| 06:57:06 | gmaxwell: | (which is analogous to how bitcoin mining hardware today already works, they do closed loop control to maximize good hashrate out, often running at a fault rate of about 1% or so) |
| 06:57:13 | bramc: | gmaxwell, Sounds plausible, I wouldn't know, I'm not a hardware person |
| 06:57:36 | op_mul: | gmaxwell: and some deep pity for whoever has to sit there with a ZIF socket and trays and trays of chips to bin |
| 06:58:11 | gmaxwell: | op_mul: probably can do a fair bit of profiling per die before packaging. |
| 06:59:10 | bramc: | gmaxwell, there might be benefit in having three cores run together and vote about the result after each iteration to keep the reliability up. |
| 06:59:11 | op_mul: | gmaxwell: I was thinking the lead frame and bond wires would alter the performance at least a bit, but I suppose you'd do a rough cut and then a find cut once they're packaged? super not my area either. |
| 07:00:20 | op_mul: | gmaxwell: (and again I'm forgetting that they wouldn't be DIP, I don't think BGA stuff even has a lead frame so.. maybe just ignore that) |
| 07:01:29 | gmaxwell: | bramc: yea, indeed, each iteration do a vote and have the majority broadcast to the rest. also do fun things like build half with positive going logic half with negative going, so the load is equalized out.. lots of fun analog hacks that arise when you're at the boundary of correctness and can't use the parallelism for anything else anyways. |
| 07:02:09 | gmaxwell: | op_mul: you can probably do initial binning with purely electrical tests. E.g. measuring the idle load and such. |
| 07:04:49 | bramc: | There's this goofy detail which nobody's asked about, which is how to avoid retroactive changing of the transaction roots, because they don't factor into the trunk of the proof of work. You have to have two parallel chains, the trunks, which is very canonical and decides the challenges for the next generation, and the leaves which are of necessity extremely malleable because they contain the transaction roots but shadow |
| 07:04:49 | bramc: | the trunk and has its own spows. To be accepted a proof of time must contain the proofs for both the trunk and the leaves. |
| 07:06:23 | op_mul: | wait, doesn't this system mean that a new node coming to the network can never sync? |
| 07:06:57 | op_mul: | ie, they'd never catch up with the 1:1 verification of the linear hashing |
| 07:07:10 | bramc: | No it syncs the same way nodes in bitcoin sync, it downloads and verifies the chain with the largest work factor it can find |
| 07:07:53 | op_mul: | but verifying would be symmetrical |
| 07:08:17 | bramc: | oh, you don't verify all the steps in the proofs of time, you spot check them, and that can be done in parallel unlike the generation which has to be done sequentially |
| 07:09:21 | bramc: | There's also a message to say 'that proof of time you just sent me is busted, recheck position X' |
| 07:09:35 | op_mul: | you can do verification in parallel too I suppose. |
| 07:09:43 | bramc: | this is that 'gimmicky cheat' I was talking about |
| 07:12:01 | bramc: | It makes designing the protocol and database logic even weirder than it is in Bitcoin |
| 07:12:38 | bramc: | Having data which can get invalidated and revalidated in multiple ways is bizarre |
| 07:13:16 | op_mul: | anything that's strating from scratch can have arguably better code than bitcoin, so it probably evens out. having all transactions P2SH would be nice, for example. |
| 07:15:09 | bramc: | Yes of course that's done, and using schnorr signatures, and have utxo identities not include the signature so transactions aren't malleable. These are small things though, they aren't worth restarting from scratch just for them. |
| 07:16:55 | bramc: | Also these proofs of work happen to be somewhat nonoutsourcable by nature, which is another good feature |
| 07:17:45 | phantomcircuit: | gmaxwell, fun fact, making the chip testable costs 1-5% of the die area |
| 07:17:57 | phantomcircuit: | brb un binnable chip |
| 07:21:01 | bramc: | But the other really big issues in Bitcoin: scaling and transaction clearing time, are ones which I don't know of any super compelling answers for, and truth be known the not super compelling stuff petertodd's working on to make transaction fees behave properly at the scaling limit is the immediate thing which needs to happen and an experiment worth running |
| 07:22:09 | Anduck_: | Anduck_ is now known as Guest4097 |
| 07:22:28 | bramc: | As in, I want to know how much transactions are really worth. |
| 07:22:59 | bramc: | Of course transactions could all clear instantly if only people weren't spreading FUD about how insecure zeroconf is :-) |
| 07:23:49 | op_mul: | bramc: is that sarcasm? |
| 07:25:38 | bramc: | op_mul, yes you missed the discussion earlier where I posted this link http://www.reddit.com/r/Bitcoin/comments/28jp0y/why_is_peter_todd_wrecking_zeroconf_security/ |
| 07:26:03 | op_mul: | ah yes I'm aware of that post. |
| 07:26:22 | op_mul: | I'm fond of greenaddress.it's solution to it really. works well within the constraints. |
| 07:26:25 | bramc: | I can't tell if the poster is a troll or mental |
| 07:26:46 | op_mul: | third option, working with an agenda |
| 07:27:36 | bramc: | Yes greenadress is a good idea, and likely the best which can be done all things considered. There should ideally be multiple vendors of that service though. |
| 07:28:25 | bramc: | Although it's unclear whether well-designed protocol venders can succeed given that they cheat themselves out of the 'oops we accidentally your whole deposit' business model. |
| 07:29:12 | bramc: | Wow a netsplit, it feels so 90s |
| 07:29:23 | op_mul: | no, feels like freenode. |
| 07:29:24 | bramc: | Almost like we're on freenode |
| 07:30:16 | phantomcircuit: | bramc, they can still do that for the most part |
| 07:30:58 | op_mul: | I think with systems like GAit you're mainly fighting people who think that their moronic system of "watch the whole network" is somehow a solution. we know miners will do finney attacks. it's happened before. |
| 07:33:41 | bramc: | My early impressions of bitcoin were a bit overly negative because I had the impression that that 'watch the whole network' stuff was central to its security guarantees, which of course it isn't at all. |
| 07:34:19 | op_mul: | sadly that's a pretty common misconnection. |
| 07:34:57 | bramc: | It seems even people who believe in bitcoin as a religion have only the vaguest understanding of what it actually does. |
| 07:35:44 | bramc: | Like, people go off on these asinine things about how somebody figured out a way to make mining do work to improve the environment, and I'm like 'that's the stupidest thing I've ever heard'. |
| 07:36:31 | op_mul: | the reason they get any level of traction is that they stand unattacked. |
| 07:37:01 | bramc: | Who/what is the 'they' you're talking about here? |
| 07:37:09 | op_mul: | there's heaps of altcoins with no consensus model at all which have stood for months or years. that's held as proof that the system is secure. |
| 07:37:26 | bramc: | And Bernie Madoff's fund was worth billions |
| 07:37:30 | op_mul: | they == consensusless altcoins |
| 07:37:43 | op_mul: | which lets face it, is most of them |
| 07:38:17 | bramc: | I thought most altcoins are trivial forks with nothing much done other than modifications of the PoW, but I haven't done a survey |
| 07:39:09 | gmaxwell: | [OT] http://the-toast.net/2015/02/12/tell-logic-puzzle/ "How To Tell If You Are In A Logic Puzzle" |
| 07:39:12 | midnightmagic: | Almost every single of them is; half of them don't even have a PoW mod. Some of them just have shorter block confirm times. |
| 07:41:45 | lclc_bnc: | lclc_bnc is now known as lclc |
| 07:43:22 | bramc: | midnightmagic, I've decided that a reasonable threshold for seriousness of an altcoin is whether it makes utxos be referred to by the transaction rather than the signature. Haven't done a survey, but I think that's hardly any of them. |
| 07:44:58 | gmaxwell: | uh? I don't think there is a single system in production that managed to make the trivial change or reorging things to get the witness(/signature) out of the transaction ID, is there? |
| 07:45:27 | bramc: | Haven't done a survey, subject too depressing. |
| 07:47:22 | op_mul: | even just counting the total number of altcoins is a problem. |
| 07:47:41 | op_mul: | by some counts it's 6-700, I think it's closer to 1500 |
| 07:56:50 | phantomcircuit: | gmaxwell, that would require understanding |
| 07:56:50 | phantomcircuit: | so |
| 07:56:52 | phantomcircuit: | no |
| 07:57:29 | phantomcircuit: | op_mul, it's infinity |
| 07:57:42 | phantomcircuit: | i actually did generate about 1m altcoins just to prove a point to someone |
| 07:57:49 | phantomcircuit: | they are of course unreleased as they dont work |
| 07:58:00 | op_mul: | not much different to the real thing then |
| 07:58:11 | op_mul: | you can't beat the one that's in obfsucated javascript though. |
| 08:04:36 | bramc: | By the way everybody, I think Vitalik is smarter than he's generally given credit for, although he's in over his head. |
| 08:07:55 | jcorgan: | I've been away for a while, haven't kept up with Ethereum at all, basically since there first big round of funding. |
| 08:08:02 | jcorgan: | their* |
| 08:08:42 | jcorgan: | My original impression of VB after meeting him in person was smart but naive. I expect that has been borne out. |
| 08:09:33 | bramc: | Yes that's true. If he were just piddling around with Bitcoin helping out and gaining experience everyone would think highly of him. |
| 08:12:44 | jcorgan: | A presentation he did last July indicated a release in December. Did anything like that happen? |
| 08:12:50 | bramc: | Although unfortunately right now people don't even want to help him because of that whole fear of getting thrown in jail thing. |
| 08:13:04 | jcorgan: | um |
| 08:13:12 | jcorgan: | i must have really missed something |
| 08:13:29 | gmaxwell: | Me too. |
| 08:14:16 | bramc: | I for one got asked to help audit ethereum, and I was like oh no sorry too busy |
| 08:14:44 | bramc: | Because the whole way it raised money might have some... issues... with the SEC, and I'm steering clear. |
| 08:15:43 | gmaxwell: | I've not heard anyone express that view at least; I for one wouldn't touch it with a 10 foot poll because it's been an unreviewable evershifting hairball, and very likely to be harmful to the reputation of anyone who gets their name anywhere one it. |
| 08:15:55 | gmaxwell: | s/one/on/ |
| 08:16:08 | jcorgan: | ^^ ok, so basically, the same state of affairs as a six months ago |
| 08:16:28 | bramc: | gmaxwell, That's another issue, see also 'in over his head' |
| 08:16:30 | gmaxwell: | Response to review in the past was to introduce more complexity, not back off and simplify to get a design which is reviewable. |
| 08:17:07 | bramc: | programmers learn to simplify from experience, people should gain experience before trying to do a whole big project |
| 08:17:38 | jcorgan: | sometimes experience is trying to implement the initial naive understanding of something and getting hit upside the head for it |
| 08:18:35 | bramc: | Before I did my project I had 20 solid years of coding experience including 5 years of being professionally employed doing it. Granted I was 25, but the raw age number can be misleading. |
| 08:18:48 | gmaxwell: | not to mention the extreme sleeze on the business side and on the attribution side from that camp. |
| 08:19:20 | jcorgan: | i'd expect then that there would be angry investors by now |
| 08:20:06 | gmaxwell: | well, that would be self defeating. |
| 08:20:18 | jcorgan: | hmm, yeah, i can see that |
| 08:20:21 | bramc: | jcorgan, They don't have investors, remember? It's a kickstarter for virtual goods, they give no impression that those goods will be worth something. It isn't an unlicensed financial instrument, really, it isn't. Even though people paid for it. |
| 08:20:44 | gmaxwell: | :( |
| 08:20:50 | jcorgan: | sorry, i'm a little hazy on the details from back then |
| 08:21:03 | gmaxwell: | (that was tongue in cheek) |
| 08:23:29 | gmaxwell: | bramc: if you have any more concrete reasons why someone wouldn't want to take contract money for them it would likely be helpful to share with people here; ... I know some people in here have or were planning on doing paid review (in some cases under conditions of pseudonymity to avoid the reputation problems). When I'd been asked for my opinion I'd just mostly expressed the reputation and hope |
| 08:23:35 | gmaxwell: | lessness concerns, I hadn't thought anyone would get implicated in the unlicensed security nonsense. |
| 08:25:05 | gmaxwell: | kind of makes me feel ill to think about that; while I don't respect the engineering work (and I think you credit a bit too much: a lot of things being published are other people's work, recycled, and stripped of attribution in varrious degrees); I don't want to see anyone in legal hot water. And to the extent that any of them were knowingly doing something wrong wrt seperating fools from their m |
| 08:25:11 | gmaxwell: | oney, those people have likely since flewn the coop. |
| 08:26:25 | bramc: | gmaxwell, I'm very uncertain that they won't get a serious smackdown for unlicensed securities, it all depends on whether they made any representations that ether could get financial return. Given the fundamental nature of what the kickstarter was, I find the claim that that wasn't at least implicit very dubious. |
| 08:27:14 | bramc: | gmaxwell, doing contract review work for auditing and only auditing is probably fine, accepting any equity or ether for services is much more dangerous. |
| 08:27:50 | petertodd: | bramc: I don't accept equity from any company interesting enough that I want to work there... |
| 08:28:07 | jcorgan: | yeah, that would be cash or btc only for me, but that's mostly theoretical as my professional skills are elsewhere |
| 08:28:28 | petertodd: | bramc: though ethereum paid enough money to lawyers that they may be ok - it's a very specific legal structure |
| 08:28:36 | gmaxwell: | Yes, I think any claim otherwise is complete pretext and BS. It's transparent enough what the deal was, and there is a ton of recorded public communication that someone can dig through to make that case. Though they spent a lot of time/money attorney shopping and so if there is some procedural protection possible, presumably that have it. |
| 08:29:22 | petertodd: | being in Switzerland is a good start re: procedural protection... |
| 08:29:26 | bramc: | The sec is kind of like the irs - they have remarkable abilities to cut through the crap, piling on more lawyers might not help you. |
| 08:29:56 | petertodd: | bramc: otoh, emphasis on "might" |
| 08:30:14 | petertodd: | hell, from that viewpoint, being a bitcoin developer *at all* is legally risky |
| 08:30:24 | jcorgan: | ? |
| 08:30:52 | petertodd: | jcorgan: you're participating in the creation of a financial system, especially for someone whose viewpoints are respected |
| 08:31:06 | bramc: | petertodd, It is possible to have careful legal strategies for companies developing worthwhile technology. My company has over 100 employees, and notably I'm not in jail. |
| 08:31:34 | petertodd: | bramc: well, for starts make your technology be non-finance related :P |
| 08:31:47 | petertodd: | bramc: (my comment above only applies to stuff in the bitcoin space really) |
| 08:31:58 | jcorgan: | i don't anticipate we are anywhere near the point where participating in the creation of bitcoin is considered even the minutest threat to those who might wield that power |
| 08:32:04 | bramc: | petertodd, Being a bitcoin developer is not inherently risk, but you need to be careful what you do and don't do. |
| 08:32:43 | bramc: | petertodd, Remember what I do for a living. The whole p2p space is full of pitfalls. |
| 08:32:52 | petertodd: | jcorgan: you really misunderstand how this stuff works - it's not about being a "threat" |
| 08:33:04 | jcorgan: | perhaps. educate me |
| 08:33:19 | petertodd: | jcorgan: all you need is the wrong circumstance to have some prosecuter/regulator looking for something to make their name with |
| 08:33:27 | jcorgan: | sure, i get that |
| 08:33:42 | bramc: | If engaging in what a normal person would consider criminal behavior in finance would land you in jail, there would be a lot more wall street types in jail. |
| 08:33:57 | petertodd: | jcorgan: then you run into the problem that legally speaking, laws are fucking vague, to the point where it's certainly plausible that courts would see participants in the development of a finance system be responsible for it |
| 08:34:20 | petertodd: | jcorgan: sure, maybe that's a 5% chance? but a 5% chance of your life getting ruined is *huge* |
| 08:34:35 | petertodd: | jcorgan: base jumping is only something like 30% IIRC |
| 08:34:39 | jcorgan: | heh |
| 08:35:05 | petertodd: | bramc: lol, no I don't remember quite what you do for a living :) |
| 08:36:20 | jcorgan: | the vagueness is certainly an asset to prosecutors, but i think at this stage it would be something that would be looked at as a strategy when something else was being prosecuted. like when charges are piled on in order to get a plea for the real offense. |
| 08:36:58 | jcorgan: | maybe i'm underestimating the stature that bitcoin/cryptocurrencies have with the current PTB :) |
| 08:36:59 | petertodd: | jcorgan: maybe? maybe not. point is we are *not* in the clear legally |
| 08:37:09 | bramc: | petertodd, There's a heirarchy of risks. Working on core technology is unlikely to land you in trouble. Working on a service can cause problems depending what it is. Selling virtual goods can cause problems depending on a lot of subtle (or from another standpoint not so subtle) details. Selling things which are labelled as unlicensed returns-making instruments or overt money laundering services will land your ass directl |
| 08:37:09 | bramc: | y in jail. |
| 08:37:40 | bramc: | petertodd, I honestly don't know if you're kidding. I made another p2p system. |
| 08:38:26 | petertodd: | jcorgan: prior to starting this stuff full time i sat down with some lawyers with finance/sec experience, and they basically said "understand that what you're doing is probably something you *could* go to jail for, and understand that the way this actually works is politics - so keep a good image and don't be the obvious guy to go after" |
| 08:38:51 | bramc: | "I don't have to outright a tiger, I just have to outrun you" |
| 08:39:02 | jcorgan: | agree that it all boils down to politics |
| 08:39:23 | petertodd: | jcorgan: for instance, the debate over whether or not I'm a "core developer" is legally less risky than people who the bitcoin foundation calls core devs, let alone being "lead dev" or "chief scientist" |
| 08:39:40 | petertodd: | jcorgan: which is why I as quickly as possible took on mutliple "chief scientist" roles... |
| 08:39:56 | petertodd: | bramc: I think I know who you are, but IRC names are confusing :) |
| 08:40:24 | bramc: | But if satoshi nakamoto went public with his identity, he would be extremely unlikely to wind up in trouble with the sec, because we are in fact a country ruled by laws and he was unambiguously on the clear side of them. Now the irs, that's another story... |
| 08:40:35 | petertodd: | bramc: re "working on core tech" - that's not really clear, if the tech itself gets into legal issues you'd be smart to get away form working on it ASAP |
| 08:40:52 | jcorgan: | maybe i've been away too long, but it still seems to me that bitcoin is still very small fry in the grand scheme of global finance, and we're there just not that into us...yet. |
| 08:41:08 | jcorgan: | /w'ere/d |
| 08:41:16 | petertodd: | jcorgan: one of the issues there is that can change *really* quickly |
| 08:41:40 | jcorgan: | agree |
| 08:41:47 | jcorgan: | perhaps i should update my priors |
| 08:41:52 | bramc: | jcorgan, the laws regarding such things are more clear than you seem to think |
| 08:42:15 | petertodd: | jcorgan: like, if there's another 9/11 and it turned out the terrorists used bitcoin extensively |
| 08:42:26 | petertodd: | jcorgan: and hell, that may be a retroactive change in legal status |
| 08:42:26 | jcorgan: | heh. i'm usually the paranoid one of the crowd. weird to be on the other side :) |
| 08:43:11 | petertodd: | jcorgan: well, the risk doesn't bother me *that* much per-se, but I really think people in different circumstances than me should understand what they may be getting into |
| 08:43:15 | bramc: | petertodd, If you were to write some piece of code and say 'this piece of code is for people to launder money with', then yeah that could land you in trouble. That's fairly easy to avoid though. |
| 08:43:51 | petertodd: | bramc: possible to avoid? yes. easy? I don't think so |
| 08:43:56 | bramc: | petertodd, my /whois gives my real name, I'm identity consistent that way |
| 08:44:04 | petertodd: | bramc: hehe, yeah, that's who I thought :) |
| 08:44:37 | petertodd: | bramc: I think the big issue for bitcoin is convention finance is *really* built around KYC and the notion that governments should have -in the end - complete control over the system |
| 08:44:58 | petertodd: | bramc: can that change? sure. will it? I can't exactly guarantee that |
| 08:45:00 | jcorgan: | i don't know whether to be excited, afraid, or indifferent to the fact that smart people i respect are debating bitcoin's real impact in this area |
| 08:45:08 | bramc: | petertodd, The mouthing off is easy to avoid. Even things like unlinking of transactions are clearly justifiable for the same reason that you don't take a photograph of the receipt of every purchase you make and post it online. |
| 08:45:47 | petertodd: | bramc: yeah, but the counter-arguement to that is "why are you working to subvert government at all? change the system" |
| 08:46:22 | jcorgan: | petertodd: "if you don't like ISIS, join them and change the system from the inside" |
| 08:46:25 | bramc: | petertodd, subverting the government is totally legal if done in the right way. For example you're allowed to run for office. That's 'subverting the government' |
| 08:46:26 | petertodd: | jcorgan: within finance even the notion that you should be able to guarntee things with crypto rather than human auditing is fairly revolutionary |
| 08:46:51 | petertodd: | bramc: yes, and creating a crypto-currency isn't necessarily the "right" way :) |
| 08:47:44 | bramc: | petertodd, There certainly are risks that legislation could be passed tomorrow which would make certain cryptocurrency-related activities a very bad idea. That would require actual legislation though, and one would know if it passed |
| 08:48:37 | petertodd: | bramc: well, what can I say, the lawyers I've talked to think existing legislation is more than enough to put bitcoin core devs in jail *if* the political will was there to do it - laws are very flexible |
| 08:49:02 | petertodd: | bramc: and hell, they'd just threaten you with some insane sentence and get you to accept a plea deal |
| 08:49:18 | gmaxwell: | bramc: you should see this BBC interview transcript with Amir (and also Petertodd) where it sounded like amir was saying things like cryptocurrency is good because it helps ISIS. (I'm sure I'm butchering that horribly but you can extract things like that). Not your words perhaps, but .. ugh. It's certantly a space where regardless of how boring and justified your own motivations are it might be |
| 08:49:24 | gmaxwell: | hard to disentangle the guilt by association with some rather strong views. |
| 08:49:53 | petertodd: | gmaxwell: heh, yeah, that BBC interview caused so much fuss someone released an unedited video of it |
| 08:50:35 | gmaxwell: | people accused the BBC of editing the video to make his views look more extreme, but really the unedited transcript showed that if anything the toned it down. |
| 08:50:38 | petertodd: | gmaxwell: though the way it edited *amir* was actually reasonably accurate |
| 08:50:41 | bramc: | gmaxwell, Yeah that, uh, doesn't help. I've always made very clear that, for example, I think Jim Bell is a homicidal psycho and I want nothing to do with him in any way shape or form |
| 08:50:47 | petertodd: | gmaxwell: lol, exactly |
| 08:51:24 | jcorgan: | jim bell is still around? |
| 08:51:43 | jcorgan: | my goodness, that brings back 20 yro memories |
| 08:51:49 | gmaxwell: | bramc: I never could quite tell how serious Jim Bell's stuff was. At least as a thought expirement it was interesting; (and has contributed to me generally feeling pretty uneasy about prediction markets and spending a lot of time trying to figure out if it's possible to structure them to be less useful for harmful uses) |
| 08:52:01 | bramc: | jcorgan, https://cpunks.wordpress.com/2013/09/20/jim-bell-re-subscribed-to-the-cypherpunks-list/ |
| 08:52:17 | petertodd: | bramc: I'm quite happy to take a risk there, and (publicly) take the viewpoint that bad stuff will come out of bitcoin, but it inherently favors individuals who are inherently more likely to be good |
| 08:52:17 | gmaxwell: | jcorgan: I think he's out of jail now. |
| 08:52:38 | petertodd: | bramc: e.g. in the BBC interview I brought up how bitcoin's very nature is a threat to ISIS, in that example |
| 08:52:50 | jcorgan: | well, aren't these interesting times |
| 08:53:39 | petertodd: | bramc: but someone's gotta say stuff like that, and I don't have kids so... |
| 08:53:47 | gmaxwell: | "It’s a poor atom blaster that won’t point both ways." indeed, I often make the point that there are negative uses, as there are for _all_ technology. |
| 08:53:55 | petertodd: | yup |
| 08:54:27 | bramc: | Tor (which I've also had a hand in) is a great example of a controversial thing which currently has a mostly good reputation. |
| 08:54:29 | petertodd: | I also like making the point that western civilization is way more than strong enough to tolerate terrorism and other badness |
| 08:54:46 | petertodd: | bramc: yeah, that project does a great job on PR |
| 08:56:37 | gmaxwell: | it helps that its primarily been funded by VoA (effectively the state departments' propaganda arm), that gives ou a free pass that no amount of snazzy positioning can accomplish. |
| 08:57:05 | bramc: | gmaxwell, It also helps that it appears to mostly be used to get around foreign countrywide firewalls |
| 08:57:13 | petertodd: | gmaxwell: yes, and notice how staying funded by VoA is a product of great PR... |
| 08:57:28 | jcorgan: | an appealing property of bitcoin as a finance system is that it is defined by math and physics, not humans, so the uses people put it to are entirely up to them, and those individuals would take the blame or credit for good and bad that comes from it |
| 08:57:32 | petertodd: | bramc: and arguably, designed too |
| 08:57:51 | petertodd: | jcorgan: humans define the math and physics |
| 08:58:05 | gmaxwell: | petertodd: bitcoin also can fit into that model of social/economic warfare (esp against places with strong currency controls, e.g. china). Rev your grant proposals. |
| 08:58:18 | petertodd: | jcorgan: that just makes bitcoin resilliant, doesn't necessarily change the legal situation of the people involved |
| 08:59:15 | bramc: | petertodd, Tor's architecture is something I scribbled on a napkin, so the intention of the architecture is mostly technical. The intention of the early funding does appear to be that it would be used to subvert foreign countrywide firewalls, so that's going to plan. |
| 08:59:42 | petertodd: | gmaxwell: absolutely! shit, I met a DoJ prosecutor recently who wanted to meet with me further, and sounded like hire me as a consultant, and like half the discussion I had with some Tor people about that situation was "it's a pity the FBI isn't trying to overthrow governments" |
| 08:59:47 | petertodd: | :) |
| 09:00:18 | bramc: | The state department and FBI have very different opinions of tor |
| 09:00:46 | petertodd: | bramc: the main thing that makes you wonder about tor is how it only has low-latency options; if it had both it'd be more clearly designed for something other than bypassing foreign government firewalls |
| 09:00:52 | petertodd: | bramc: indeed |
| 09:01:14 | bramc: | petertodd, It doesn't have high-latency options because people are only interested in web browsing. |
| 09:01:23 | gmaxwell: | well see the alpha-mix paper that roger co-authored; but no one is funding that development. No reason to think they wouldn't take patches if offered. |
| 09:01:58 | petertodd: | gmaxwell: yeah, I suspect the extent of any subversion there is just funding - Tor's internal culture seems quite independent of their funders |
| 09:05:14 | rajaniemi.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: andy-logbot Mably Guyver2 ielo hktud0 bedeho d1ggy brad__ gmaxwell paveljanik burcin Guest4097 dansmith_btc DougieBot5000_ hashtagg_ koshii_ GnarSith Pan0ram1x copumpkin bramc fanquake TheSeven Dr-G bosma Starsoccer p15 Starduster shesek nuke1989 cluckj maaku delll paperbot dc17523be3 sipa xabbix__ melvster GAit arubi_ flower prodatalab Emcy epscy_ airbreather realcr Quanttek grandmaster Luke-Jr jaekwon fenn espes__ devrandom dgenr8 |
| 09:05:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: justanotheruser PaulCapestany LarsLarsen jbenet platinuum use_zfs_yo Oizopower mappum harrow Visheate a5m0 btcdrak hollandais hashtag PRab Xzibit17 OneFixt_ SubCreative luny Logicwax Zouppen comboy Adlai yoleaux forrestv MoALTz lnovy binaryatrocity deego d9b4bef9 spinza weex_ nanotube nsh HaltingState DoctorBTC ryanxcharles bliljerk101 dasource CryptOprah artifexd Muis kumavis mr_burdell tripleslash waxwing cornus_ammonis NeatBasis [d__d] |
| 09:05:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: Hunger- davout wiz tromp iddo Alanius michagogo cursive nick1234abcd__ PFate yrashk BlueMatt brand0 @ChanServ Adrian_G throughnothing Cory andytoshi helo NikolaiToryzin catcow btc___ K1773R HM2 Graet JonTitor heath kanzure catlasshrugged pigeons asoltys_ livegnik eric Taek crescendo sneak lechuga_ ajweiss ryan-c smooth BananaLotus petertodd bbrittain Keefe s1w Eliel cfields jaromil Fistful_of_Coins jcorgan optimator gribble warren veox |
| 09:05:14 | rajaniemi.freenode.net: | Users on #bitcoin-wizards: dardasaba fluffypony amiller bobke_ earlz sl01 phantomcircuit Iriez nickler wumpus sdaftuar BrainOverfl0w isis CodeShark gwillen roasbeef warptangent stonecoldpat phedny so wizkid057 ahmed_ hguux__ otoburb kinlo indolering lclc huseby qwopqwop tromp__ Meeh gnusha_ gavinandresen Apocalyptic cryptowest morcos MRL-Relay midnightmagic coryfields null_radix Krellan azariah berndj TD-Linux |
| 09:05:46 | bramc: | tor seems to suffer from a lack of core devs, unfortunately. Its basic core functionality could use more hands. |
| 09:06:13 | petertodd: | bramc: agreed |
| 09:06:51 | petertodd: | bramc: lack of money contributes to that - tor devs don't exactly earn much |
| 09:07:20 | bramc: | There are also basic performance things which I could have explained to them years in advance. Which makes me think I should poke my nose in more often. At the moment the bottleneck doesn't seem to be knowing what needs to be fixed so much as having hands to fix it though. |
| 09:07:56 | petertodd: | it is a surprisingly small project |
| 09:09:51 | fluffypony: | I wonder if some of the "internal" Tor sites are going to move to i2p |
| 09:10:00 | fluffypony: | there's been a small shift of a handful of them |
| 09:10:03 | fluffypony: | but nobody major |
| 09:10:13 | petertodd: | fluffypony: hopefully not - i2p isn't sybil resistant |
| 09:10:44 | jcorgan: | * jcorgan lols that -wizards seems to have the conversational content that #bitcoin had 2 years ago |
| 09:10:46 | petertodd: | fluffypony: the annoying thing about Tor is the fact that it's a highly centralized system is what makes it actually work, assuming the poeple running it are trustworthy |
| 09:12:06 | bramc: | jcorgan, The occasional digression into political and legal issues is totally reasonable. Mostly it's highly technical discussions in here, frequently about goofball blue sky stuff. |
| 09:12:13 | bramc: | For example, most of the discussions earlier today. |
| 09:12:27 | fluffypony: | to some degree Tor suffers the same Sybil issues - creating poisoned relays is trivial |
| 09:12:30 | fluffypony: | eg. http://blog.torproject.org/blog/june-2010-progress-report |
| 09:12:45 | jcorgan: | sure. i meant it as a compliment. |
| 09:13:49 | petertodd: | fluffypony: sure, but it has the infrastructure to detect this stuff and respond, precisely because trusted people are running the show |
| 09:14:07 | petertodd: | fluffypony: there just isn't any simple alternative to that |
| 09:22:59 | Taek: | it's hard to think of a way to incentivize something like tor, because presumably the node could rat you out for increased pay, and nobody would be the wiser |
| 09:23:37 | petertodd: | Taek: absolutely - all these bitcoin guys trying to do exactly that really scares many of the tor devs |
| 09:23:38 | bramc: | In case anyone was curious, in that linked post by Jim Bell the scheme he's talking about to make fiber optic cables out of isotopically enriched silicon is pure wingnut. |
| 09:24:06 | petertodd: | bramc: ...and brilliant audiophile |
| 09:24:21 | gmaxwell: | lol. |
| 09:24:25 | gmaxwell: | Kaching. |
| 09:25:24 | gmaxwell: | "Heavy silica produces the densest lows of any transport technology. The spectral warmth cannot be described with words, it must be expirenced. Coming to Sky Mall 2016." |
| 09:25:40 | bramc: | Everything sounds better in a room containing mostly nitrogen-15! |
| 09:26:32 | petertodd: | gmaxwell: that was so close to being a good start to an HP Lovecraft story... |
| 09:26:54 | petertodd: | gmaxwell: "The Spectral Warmth Out of Space" |
| 09:28:02 | realcr: | Taek: If nodes rat you for increased pay, you might be able to pick another one, and get some kind of market. |
| 09:28:18 | petertodd: | realcr: how would you ever no? |
| 09:28:21 | petertodd: | *know |
| 09:29:09 | realcr: | I have some ideas for this. |
| 09:29:25 | realcr: | You might be able to try sending small messages through different nodes, and see which one of them arrives. |
| 09:29:37 | realcr: | It will cost some "money" to try, but you will get some idea. |
| 09:29:48 | petertodd: | realcr: that proves nothing about whether or not the nodes are logging your connections |
| 09:30:24 | realcr: | petertodd: I don't know much about structures like TOR, but if you do it inside a mesh network like CJDNS, it might be possible. At least in my opinion. |
| 09:30:54 | realcr: | Some nodes might overprice their networking services, but your messages will find their way around them. |
| 09:31:06 | petertodd: | realcr: that's a different problem then what Tor is trying to solve |
| 09:31:12 | petertodd: | realcr: Tor is about anonymity, not delivery |
| 09:31:26 | realcr: | petertodd: You are right. |
| 09:31:42 | realcr: | But I think it could be combined. Assuming that you manage to incentivize a mesh, you could build TOR above it. |
| 09:32:02 | gmaxwell: | one of the concerns I've had with "compensate for running nodes" is that it seemed even more vulnerable to "lots of people get paid to run spy nodes", because it would shift the network composition more towards economically motivated, who might be more interested in accepting an offer to increase their income a bit by submitting logs. (and the logs could easily be verifyably faithful, since you'd |
| 09:32:08 | gmaxwell: | run test circuts through nodes to make sure they showed up in logs) |
| 09:32:31 | petertodd: | realcr: ^ |
| 09:32:49 | petertodd: | realcr: paying money for something radically changes the incentives and type of people you attract |
| 09:33:26 | realcr: | petertodd: I know. But I believe it could be a good thing. I have to admit I don't fully understand what you talk about with the logs, because I lack knowledge about how it works. |
| 09:33:35 | realcr: | What are the logs? |
| 09:33:51 | realcr: | I'm sorry if I'm asking something trivial around here :) |
| 09:34:02 | gmaxwell: | e.g. just a patch to log all your in/out circuits and submit the data with a bitcoin address once a day to a hidden service. If your data includes the test circuits, you get paid. Probably not much, but it could be non-trivial compared to your overall compensation... and that may well be enough if you were running the thing to make money, rather than running it for non-economic motivations (suppo |
| 09:34:03 | petertodd: | realcr: you really don't understand the problem... the issue is a node operator keeping logs of the traffic passing through their node |
| 09:34:07 | gmaxwell: | rting free speech, free though, personal autotomy, undermining foreign nations, etc.) |
| 09:34:27 | Taek: | Could one theoretically create a system where logging is tolerable at any percentage? |
| 09:34:28 | realcr: | petertodd: Is he paid by the logs? |
| 09:34:37 | realcr: | petertodd: I seem to really not understand it. |
| 09:34:41 | Taek: | If all communications are end-to-end encrypted, you could send bogus communications to random parties |
| 09:34:49 | gmaxwell: | Taek: not an efficient one. Thats the tradeoff. |
| 09:35:01 | petertodd: | realcr: the point is it is impossible to know whether or not someone is keeping logs, that's 100% based on trust |
| 09:35:19 | realcr: | petertodd: I agree, but If my traffic is encrypted, why would I care about the logs? |
| 09:35:21 | petertodd: | realcr: by paying people, you attract people motivated by money, not ethics |
| 09:35:22 | realcr: | Is it about the metadata? |
| 09:36:00 | petertodd: | realcr: encryption does not prevent the node operator from knowing who you are talking too, the reason why tor exists |
| 09:36:11 | petertodd: | realcr: anyway, go learn more about Tor |
| 09:36:19 | Taek: | gmaxwell: if we throw efficiency out the door, what would a solution be? Hiding real communications inside of bogus communications works until you talk to a honeypot - suddenly your illegal activity is revealed. Are there other methods? |
| 09:36:24 | realcr: | petertodd: You mean that the last node on the chain logs my external communication? |
| 09:36:26 | gmaxwell: | petertodd: not just attract, but e.g. if there 1 person motivated by money for every 10 motivated by ethics, the money motivated ones may still have a much larger share of the network, since the money motivated people are prone to scale out in the way the ethically motivated ones are not. |
| 09:36:52 | petertodd: | gmaxwell: that's a good point |
| 09:37:15 | petertodd: | gmaxwell: the only VPN I use is run by a guy I've personally met... at a Tor conference |
| 09:37:20 | gmaxwell: | Taek: you create quadratic or worse traffic. e.g. every node sends a constant bitrate to every node in the network. Even this is vulnerable to confirmation attacks, but it has basic immunity to passive traffic monitoring, but the overhead is insane. |
| 09:37:21 | realcr: | gmaxwell: I think that without incentivizing networking using some robust kind of economy, problems like DoS can not be solved. |
| 09:38:05 | gmaxwell: | realcr: hashcash and other similar tools can be use to mitigate DOS without creating the incentives problems. |
| 09:38:20 | gmaxwell: | (not that they don't have their own shortcomings) |
| 09:38:27 | gmaxwell: | In practice tor works remarkably well. |
| 09:39:07 | realcr: | gmaxwell: I have to agree about that. TOR does work pretty well. |
| 09:40:10 | Taek: | I've been inclined to doubt the integrity of Tor over the past year and a half. Many of the cp sites have experienced takedowns and I've chosen to read that as a dead canary. |
| 09:40:16 | realcr: | gmaxwell: While hashcash and similars can make DoS harder to perform, they are not as efficient as: "If you are DoSing me it means I make lots of money, so go ahead." |
| 09:40:31 | gmaxwell: | (E.g. the act of _paying_ mitigates the dos, the act of recieving payment changes the incentives of node operators. It's possible to do the first without the second.) |
| 09:40:49 | realcr: | But why wouldn't someone be paid for its service? |
| 09:41:16 | gmaxwell: | realcr: unfortunately, that goes hand and had with "yea, I don't care if you're using all the BW and denying human rights activists access to the system... money money money. plus, more money when I sell everyone's logs. hurray. money money. lemme spin up more nodes, this rocks." |
| 09:41:24 | petertodd: | Taek: I don't doubt the integrity; I doubt the competence of people running .onion sites |
| 09:41:53 | petertodd: | Taek: equally, the # of hosts for .onion sites is surprisingly small |
| 09:42:07 | realcr: | gmaxwell: I think I have to learn about the logs thingy. |
| 09:42:17 | realcr: | gmaxwell: I obviously miss something here. |
| 09:42:17 | petertodd: | Taek: and of course, for all the sites taken down, there have been relatively few arrests |
| 09:42:28 | jcorgan: | Taek: in line with what petertodd said, Tor doesn't make much difference when the sites themselves are vulnerable to exploits |
| 09:43:01 | petertodd: | jcorgan: probably the biggest thing that Freenet gets right that Tor doesn't is Freenet naturally leads to secure sites, because you don't have to host them |
| 09:43:20 | gmaxwell: | Taek: not a great canary. For one, people doing that stuff enjoy no protection. I wouldn't doubt for a minute that a lot of decent technical people are happily chipping away at finding those places and turning them in who wouldn't go after something that was less tasteless (and bringing bad reputation to the system). You'd have to be somewhat fundimentally insane to run such a thing, so expected |
| 09:43:26 | gmaxwell: | result is expected. |
| 09:43:44 | bramc: | Does freenet even have any real deployments? |
| 09:44:12 | gmaxwell: | I mean, it's a production network in actual use. It's slow and irritating to use, generally. But it works (or did last time I found it). |
| 09:44:29 | gmaxwell: | The low median clicks to child porn make it less enjoyable to use than it migth be otherwise. :( |
| 09:44:30 | petertodd: | bramc: yes, last I checked a few months ago there's maybe an order of magnitude less sites than Tor |
| 09:44:54 | realcr: | bramc: What do you mean by real deployments? |
| 09:45:09 | petertodd: | gmaxwell: I suspect Freenet ends up that way because it actually works - anyone else with less stringent security requirements uses Tor |
| 09:45:10 | bramc: | realcr, I mean for years it was an ever-shifting piece of quasi-vaporware |
| 09:45:31 | realcr: | bramc: It does work though. And have lots of stuff inside (And lots of porn, as mentioned above). |
| 09:45:37 | petertodd: | bramc: huh? I'd describe it as something that simply never had that much demand, considering it's inherent poor performance |
| 09:45:52 | petertodd: | (I've been following freenet since it started) |
| 09:46:04 | realcr: | But it's a great proof of concept that this is possible. |
| 09:46:04 | Luke-Jr: | bramc: so you were suggesting meeting in the bay area to discuss your stuff? |
| 09:46:06 | petertodd: | my first introduction to crypto actually IIRC |
| 09:46:16 | realcr: | I am willing to surf a bit slowly if it is more secure. |
| 09:46:34 | petertodd: | realcr: Freenet isn't a "bit" slower, it's orders of magnitude slower than .onion sites |
| 09:46:39 | realcr: | petertodd: I wonder what Ian Clark is doing these days. |
| 09:46:43 | gmaxwell: | petertodd: well I think some of it is just lazy... people link to things without looking, and a couple hops go by... that you can get to some sketchy stuff if you try doesn't concern me, that you can land on it just basically clicking around randomly without intending it, is another matter. |
| 09:47:17 | realcr: | petertodd: But it does something differenet. You website is stored in a distributed manner on other nodes. |
| 09:47:36 | bramc: | Luke-Jr, Yeah it would be good to meet up with people, the only time I've chatted with the local bitcoin devs in person was at the whatsitcalled launch party, and that was very brief |
| 09:47:51 | bramc: | And I of course have a lot more stuff to discuss now |
| 09:48:21 | bramc: | petertodd, little known piece of trivia, I worked at mojo nation |
| 09:49:06 | petertodd: | bramc: ha, I knew that |
| 09:49:30 | realcr: | bramc: Somehow I looked at the nick and didn't guess it was you. |
| 09:49:44 | Luke-Jr: | bramc: I'm not sure what my schedule is like, but I'm here until Wednesday |
| 09:50:10 | petertodd: | bramc: Mojo was a centrally controlled currency right? |
| 09:50:38 | bramc: | Luke-Jr, unfortunately I'm way swamped for the next two weeks |
| 09:51:36 | Luke-Jr: | oh |
| 09:52:01 | realcr: | petertodd: I think it was, with some kind of micropayments. |
| 09:52:13 | bramc: | petertodd, I wouldn't go so far as say that mojo nation was fleshed out enough to make any such coherent claims about it. The short answer is yes, but the only part of the money system which seemed to work was the short term credit granting between counterparties. Hence BitTorrent's simplified tit-for-tat system |
| 09:52:58 | bramc: | Luke-Jr, Although if you could come to my offices or are somewhere downtown on tuesday that could work |
| 09:53:01 | petertodd: | bramc: ah, I've never seen a clear description - so that wasn't really ever put into production? |
| 09:53:27 | bramc: | petertodd, There's this fuzzy distinction between 'public beta' and 'in production' |
| 09:53:36 | petertodd: | bramc: heh |
| 09:54:11 | petertodd: | bramc: and certainly nothing to prevent double-spends more fancy than a central server(s) right? |
| 09:54:16 | Luke-Jr: | bramc: maybe a group of us can go there? |
| 09:55:27 | bramc: | petertodd, Correct, it was just a single central server |
| 09:55:41 | bramc: | Luke-Jr, Sure, I don't even know who's around |
| 09:56:02 | bramc: | I'm bad enough with names when people aren't going by Guest267 |
| 09:56:55 | Luke-Jr: | bramc: what time would be best? and what address? |
| 10:07:04 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 10:17:10 | bramc: | Okay everybody, I'm passing out, good night. |
| 10:51:03 | lclc: | lclc is now known as lclc_bnc |
| 10:53:25 | Anduck: | Anduck is now known as Guest88881 |
| 10:54:37 | Anduck_: | Anduck_ is now known as Anduck |
| 11:18:15 | arubi_: | arubi_ is now known as arubi |
| 11:20:42 | lclc_bnc: | lclc_bnc is now known as lclc |
| 14:52:37 | kanzure: | https://github.com/basil00/PseudoNode "To the network, PseudoNode appears to be a normal full node. It relays invs, txs, blocks, etc. just like a full node. In reality, PseudoNode is a type of p2p proxy server. It merely forwards any request it cannot handle (getdata, getheaders, etc.) to neighboring nodes. PseudoNode uses no disk (no blockchain download required), uses little CPU/RAM, and uses less network resources (bandwidth) than ... |
| 14:52:42 | kanzure: | ... a normal full node. A PseudoNode can "sync" with the network within seconds. It is difficult to prove that a full node is really a full node." |
| 14:53:33 | nsh: | heh |
| 14:54:48 | nsh: | this probably nominally improves the gossip proliferation but not sure it would have any other effect, except screwing people's notion of how many full nodes there are |
| 14:55:00 | nsh: | but i haven't thought hard about network stuff |
| 14:56:36 | nsh: | actually, it may even (again, nominally) facilitate partition attacks if you can shepherd pseudonodes to bolster the notional size of a partition |
| 14:56:40 | nsh: | or i could be talking pish |
| 14:56:40 | kanzure: | if you wish hard enough, the network disappears and is replaced with instantaneous unicorn magic |
| 14:56:45 | nsh: | * nsh smiles |
| 14:57:20 | kanzure: | a network of these pseudonodes would probably DoS itself |
| 14:57:39 | nsh: | aye |
| 14:58:08 | nsh: | it might be fun trying some -- simulated, testnet -- experiments where you switch a bunch of nodes from full to pseudo/proxying |
| 14:58:15 | nsh: | and watch them storm each other to bits |
| 14:59:09 | kanzure: | (i hope you mean regtest) |
| 14:59:25 | nsh: | probably |
| 14:59:48 | nsh: | little t testnet, not big |
| 15:01:36 | nsh: | maybe it's be nice if there was a dedicated protocol/incentive-effect test network actually well-distributed, with particular experiments scheduled and wide participation |
| 15:01:38 | nsh: | *it'd |
| 15:02:53 | nsh: | * nsh reads https://geraldkaszuba.com/creating-your-own-experimental-bitcoin-network/ |
| 15:04:23 | kanzure: | all of that is pretty ridiculous |
| 15:04:31 | kanzure: | just use the scripts in the qa rpc tests folder in bitcoin.git |
| 16:51:17 | lclc: | lclc is now known as lclc_bnc |
| 16:55:25 | GnarSith: | GnarSith has left #bitcoin-wizards |
| 18:47:32 | kanzure: | https://blog.ethereum.org/2015/02/14/subjectivity-exploitability-tradeoff/ |
| 18:47:37 | kanzure: | * kanzure gets popcorn |
| 18:49:18 | nsh: | * nsh blinks |
| 18:50:14 | kanzure: | hahaha "Subjectivocracy is in some sense the ultimate non-coercive form of governance; no one is ever forced to accept a situation where they don’t get their own way, the only catch being that if you have policy preferences that are unpopular then you will end up on a fork where few others are left to interact with you." |
| 18:54:53 | kanzure: | (bullying is obvious here and not mentioned at all. hilarious.) |
| 18:55:36 | maaku: | "x is obvious and not mentioned at all" <-- welcome to etherium |
| 18:55:56 | nsh: | * nsh smiles |
| 19:04:35 | kanzure: | maaku i am wordstealing you again, just fyi |
| 19:04:35 | kanzure: | https://news.ycombinator.com/item?id=9050429 |
| 19:05:51 | maaku: | kanzure: no worries, spread the word :) |
| 19:06:25 | maaku: | well nit pick: "fundamentally scarce resource, namely entropy" <-- should be negentropy |
| 19:06:35 | maaku: | entropy isn't scarce ;) |
| 19:07:47 | kanzure: | wasn't there a church of negentropy at some point |
| 19:07:54 | kanzure: | ah yes |
| 19:07:55 | kanzure: | http://www.orionsarm.com/eg-article/46cf7ca0904a7 |
| 19:07:59 | kanzure: | .title |
| 19:08:01 | maaku: | and there may be other physics-based scarcities (e.g. availability of elements like gold), but I don't know of any quite as useful as (neg)entropy |
| 19:08:12 | yoleaux: | Orion's Arm - Encyclopedia Galactica - Negentropism |
| 19:11:03 | nsh: | negentropy is physically scarce (and strictly globally increasingly so) but algorithmic entropy is also a limited resource |
| 19:11:27 | nsh: | which seems a bit counterintuitive |
| 19:11:32 | fluffypony: | eugh, that blog post |
| 19:13:13 | maaku: | nsh: "algorithmic entropy"? |
| 19:13:44 | kanzure: | warning nsh is a chaotic-neutral extropic being |
| 19:13:52 | kanzure: | or something... |
| 19:14:13 | nsh: | maaku, such as available entropy in an OS pool |
| 19:14:30 | nsh: | of the amount of entropy in a cryptographic secret |
| 19:14:34 | maaku: | ah ok |
| 19:14:34 | nsh: | *and/or |
| 19:16:26 | gmaxwell: | maaku: flatter our schemes all you want; we're still not letting you out of the box, machine! |
| 19:16:43 | kanzure: | i might have let him out of the box, my bad |
| 19:17:29 | maaku: | lol |
| 19:44:11 | nsh: | gmaxwell, looking into the BGP dimensionality-frustrated consistenct and resultant oscillation that you mentioned yesterday and found this paper that claims to show that under certain configurations with route-reflection proving consistency degenerates to an NP-complete problem |
| 19:44:15 | nsh: | http://people.csail.mit.edu/arasala/papers/bgp.pdf |
| 19:44:22 | nsh: | *consistency |
| 19:45:28 | nsh: | which seems interesting if there might be a way to relating the difficulty/complexity of consistency/consensus to underlying algebraic properties and might transfer to blockchain theory |
| 19:49:01 | nsh: | everything seems to come down to the relativity of ordering |
| 19:50:08 | DougieBot5000_: | DougieBot5000_ is now known as DougieBot5000 |
| 19:53:49 | lclc_bnc: | lclc_bnc is now known as lclc |
| 21:19:12 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
| 21:29:53 | bosma_: | bosma_ is now known as bosma |
| 21:33:11 | nuke_: | nuke_ is now known as nuke1989 |
| 21:46:52 | lclc: | lclc is now known as lclc_bnc |