| 00:03:56 | warren: | justanotheruser: http://www.coindesk.com/bitcoin-technology-anonymous-tor-network-more-powerful/ |
| 00:07:02 | justanotheruser: | "The proof-of-bandwidth concept" |
| 00:07:14 | justanotheruser: | That's an oxymoron. There is no way to prove bandwidth |
| 00:28:09 | Pelican: | Pelican has left #bitcoin-wizards |
| 00:33:41 | [Derek]: | [Derek] is now known as Guest49412 |
| 00:36:12 | dsnrk: | justanotheruser: gmax has some nice comments about that already. https://news.ycombinator.com/threads?id=nullc |
| 00:36:23 | dsnrk: | (he's not impressed) |
| 00:49:57 | amiller: | so that torcoin team was originally part of a larger paper i was on |
| 00:50:28 | amiller: | but the others of us didn't think that bandwidth based proof of work made much sense, so we stuck to a simpler thing http://www.robgjansen.com/publications/tears-hotpets2014.pdf |
| 00:50:49 | amiller: | both of our papers are going to be presented at the same workshop in amsterdam |
| 00:51:13 | amiller: | ours isn't called "torcoin" though so probably no one will care :o |
| 00:53:29 | gmaxwell: | amiller: I talked to one of the authors on hackernews, it didn't seem to me that they really understood what a sybil attack was. |
| 00:53:57 | amiller: | yeah. |
| 00:54:02 | gmaxwell: | ( https://news.ycombinator.com/item?id=7850738 ) |
| 01:20:08 | petertodd: | you know, it'd be useful if someone created a micropayment channel torthing/pay-for-proxy just to show as an example every time this comes up |
| 01:20:31 | petertodd: | heck, I specifically used torcoin as an example of when an appcoin *doesn't* make sense... |
| 01:20:47 | justanotheruser: | petertodd: is the price of the bandwidth even comparable to a transaction fee? |
| 01:21:37 | petertodd: | justanotheruser: hence the micropayment channel! equally could use probabalistic payments (I have a working scheme for that using coinbase outputs) |
| 01:24:27 | justanotheruser: | petertodd: what, on a sidechain? Or by slowly increasing the amount paid? |
| 01:25:10 | petertodd: | justanotheruser: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02159.html |
| 01:26:42 | petertodd: | I'm not sure the idea is really all that of a good one, because it gives larger pools an avenue for earning more money for their mining, but technically at least it works |
| 01:26:58 | dsnrk: | gmaxwell: the core problem is even simplier. they mention users would sell torcoin (or whatever) on an exchange, but who the hell would want to buy it? |
| 01:34:12 | amiller: | have you guys seen this project https://github.com/orisi/wiki/wiki/Orisi-White-Paper |
| 01:34:21 | amiller: | it's aiming to be an implementation of the m/n general purpose oracles stuff |
| 01:36:23 | petertodd: | amiller: nice, looks like they're implementing my revealed secret key suggestion from ages ago |
| 01:36:53 | petertodd: | amiller: could still be improved by getting rid of IsStandard() so they don't need such a ridiculous number of keys mind... |
| 01:38:57 | petertodd: | also, open quetion as to whether or not their high-level-first approach, with primatives for things like "check a website", is better than gmaxwells low-level-first approach, with implementing a VM first |
| 01:39:40 | petertodd: | using bitmessage for this is ugly too - if you know what communication you need to sybil attack doing so isn't all that hard |
| 01:43:39 | jgarzik: | amiller, cool |
| 01:45:50 | jgarzik: | petertodd, What is better than BitMessage? While I agree with BM is ugly, incomplete, attack prone, poorly coded, ... the question remains. |
| 01:46:54 | jgarzik: | I want an easy pay-for-use network that blinds IP source, packet size, packet timing, and does not require sender and receiver to be online at the same time (mailbox) |
| 01:48:12 | dsnrk: | stenography? |
| 01:48:28 | jgarzik: | Having reviewed BitMessage's code circa 12 months ago, scaling problems were obvious in addition to the list just given. Nevertheless... BM has useful properties that no other system provides |
| 01:48:34 | petertodd: | jgarzik: nothing exists that is actually implemented AFAIK, beyond putting the data in the bitcoin blockchain. For certain applications where censorship detection is important, but the timelyness of that detection isn't critical hybrid models that commit to the hash of some sidechain in teh bitcoin blockchain should work. (e.g. the zookeyv stuff I was talking about last year) |
| 01:49:22 | jgarzik: | petertodd, bleh. Pooping in the bitcoin blockchain for temporary comms is just about the worst solution. |
| 01:49:58 | petertodd: | meh, there's no other option if you need decentralized messaging where timely detection of censorship is important |
| 01:50:31 | petertodd: | but that is a pretty specialized application, mainly needed for finance stuff. (e.g. market orders) |
| 01:50:48 | dsnrk: | does bitmessage really hide the origin? I thought low-latency anonymisation was almost impossible |
| 01:51:23 | petertodd: | dsnrk: depends on who is attacking you :) bitmessage has had some pretty awful privacy flaws before, like replying with your public key on demand |
| 01:51:30 | dsnrk: | impossible assuming an all encompassing observer. |
| 01:52:29 | dsnrk: | petertodd: so does bitcoind really, you can test bitcoin nodes for the ownership of a particular address. |
| 01:52:43 | petertodd: | dsnrk: if you assume that observer is just obversing node-to-node communications then you can use padding to hide timing info - that doesn't need to imply high latency, just moderate latency |
| 01:52:51 | petertodd: | dsnrk: yes, thats a bug :) |
| 01:53:25 | sl01: | OTR over pastebin, google for message discovery :P |
| 01:53:26 | jgarzik: | petertodd, need TempCoin |
| 01:53:52 | dsnrk: | padding is sort of only semi-useful, you're limited by the upper bounds of bandwidth. probably alright for oracle messages though. |
| 01:54:04 | petertodd: | sl01: lol |
| 01:54:26 | dsnrk: | sl01: I prefer stenography. communication through popular memes on reddit. |
| 01:54:40 | petertodd: | jgarzik: security vs. scalability is a tradeoff, simple as that. hence tree chains and its powers of two tradeoff choices |
| 01:55:30 | petertodd: | dsnrk: I'm actually part of the USA's last ditch nuclear missile launch system; if I ever make a post advocating blacklisting, Russia's gettin' nuked |
| 01:55:51 | jgarzik: | dsnrk, same problem as Tor. Even if the message remains shrouded, a circuit can be detected if people are looking. https://twitter.com/jgarzik/status/475085846006493184 |
| 01:56:29 | petertodd: | it'll be fun watching all the real-world attacks on zerocash due to metadata... |
| 01:57:12 | dsnrk: | jgarzik: well if each node is assumed to send 1KB/s of packing data to every one of it's peers you can't make that sort of connection. |
| 01:57:16 | jgarzik: | This ignores of course the presumed-then-revealed fact that many Tor nodes are run by the gov't |
| 01:57:37 | jgarzik: | dsnrk, yes, you need to regularize packet size & timings |
| 01:57:40 | jgarzik: | for a start |
| 01:58:36 | petertodd: | jgarzik: Tor isn't as susceptable to that as you'd think - it is after all a centralized system where the majority of Tor bandwidth is provided by known people. |
| 01:58:48 | dsnrk: | it's sort of completely impractical for almost any purpose. for something like bitcoin you want *much* high bandwidth to communicate blocks, and if your packing level was that high the bandwidth would be astronomical. |
| 01:59:05 | jgarzik: | petertodd, sufficient people use BitMessage despite its flaws. I think TempCoin / MessageCoin would have a decently sized userbase, considering all the decentralized apps that want temp messaging |
| 01:59:11 | petertodd: | jgarzik: equally, if I need to use Tor for soemthing sensitive, I can run my own Tor relays and rely on the plausible deniability |
| 02:00:31 | petertodd: | jgarzik: indeed they would, they also accept zeroconf transactions, then lose stacks of money when they find out the security isn't as good as they thought it was. |
| 02:01:02 | dsnrk: | I suppose you would for bitcoin have two channels. one for transactions that was packed at 1KB/s or something, and a second channel for blocks which was in the clear. |
| 02:01:59 | petertodd: | dsnrk: yup - also can integrate that with the Tor network (or any other low-latency network) and use the store-and-forward traffic to pad the low-latency traffic |
| 02:02:49 | dsnrk: | I can't see that ever happening though, for my bitcoin nodes I'd be burning 1KB/s/client plus the clear terabyte a month I already burn on blocks. |
| 02:03:09 | petertodd: | dsnrk: security is expensive :) |
| 02:03:18 | dsnrk: | 2.4GB/client/month |
| 02:03:48 | petertodd: | what's the definition of "client"? |
| 02:03:57 | dsnrk: | someone connecting to my node |
| 02:04:05 | petertodd: | I mean, how do you measure that? |
| 02:04:12 | dsnrk: | getpeerinfo? |
| 02:04:35 | petertodd: | er, I mean, did you run that once, or do you have something more sophisticated? |
| 02:04:55 | dsnrk: | oh sorry, I have two nodes listening with around 100 connections each |
| 02:05:11 | petertodd: | right, so basically Bandwidth / 100 |
| 02:05:16 | dsnrk: | one local for p2pool, one external. |
| 02:06:10 | dsnrk: | * dsnrk shrugs |
| 02:07:53 | dsnrk: | I'm more bothered by the range of fake nodes that connect to mine more than anything |
| 02:08:28 | dsnrk: | lots of things *claiming* to be bitcoin core but not |
| 02:08:31 | petertodd: | how do you know they're fake? |
| 02:09:30 | dsnrk: | yeah I spent way too much time on this. |
| 02:10:35 | dsnrk: | one keeps sending me transactions with invalid signatures that fail the pubkey check for a variety of stupid reasons (don't know why), a few don't ever send inventory but request everything they can, some are just constantly connecting and disconnection like the bitnodes.io scanner (few times an hour) |
| 02:10:49 | dsnrk: | *invalid transactions that fail the pubkey check |
| 02:11:10 | dsnrk: | *disconnecting |
| 02:11:19 | petertodd: | dsnrk: we recently added some new conditions to signature checks; those might be old nodes |
| 02:11:48 | petertodd: | as for never sending inventory, they might not be connected to many other nodes and thus rarely have inventory to snd |
| 02:11:55 | dsnrk: | nah, all my connected nodes are 0.8.5 or older. |
| 02:11:58 | petertodd: | bitnodes.io OTOH :) |
| 02:12:10 | petertodd: | well, could be academics too :) |
| 02:12:34 | dsnrk: | still wish they used subver properly so I could ban them |
| 02:12:38 | petertodd: | I know for a fact that there's enough academic projects analyzing the bitcoin network that they're really analyzing academics analyzing the bitcoin network |
| 02:12:45 | dsnrk: | blockchain.info are IP banned naturally |
| 02:13:09 | petertodd: | meh, write a patch that tests peers for usefullness! |
| 02:13:22 | dsnrk: | gmaxwell had something about that |
| 02:15:12 | petertodd: | yeah, it's a rather political issue because inherently SPV nodes have a hard time being useful |
| 02:16:22 | dsnrk: | I wouldn't care if they just identified themselves. herp derp user agents all over again. next we're going to have /Satoshi/NotreallyItsGoogleLolJks/. |
| 02:16:55 | petertodd: | heh, well, good luck enforcing that in an anonymous decentralized system... besides, revealing yourself is a privacy risk |
| 02:17:22 | dsnrk: | yeah using fake subvers worked for blockchain.info :) |
| 02:22:57 | maaku: | maaku is now known as Guest39249 |
| 03:19:57 | justanotheruser: | petertodd: what do you think of appcoins like storjcoin? |
| 03:20:07 | justanotheruser: | is your writeup complete? |
| 04:19:10 | Sangheil-: | Sangheil- is now known as Sangheili |
| 04:20:21 | dsnrk: | https://blog.blockchain.com/2014/06/10/sharedcoin-and-other-coinjoin-implementations-uses-and-limitations/ |
| 04:20:37 | dsnrk: | ha! blockchain.info just admitted their "sharedcoin" mixer was completely useless. |
| 04:22:40 | dsnrk: | thought the rest of it is bullshit. "Please visit our public GitHub repository to review all of our open source projects and lend us a helping hand", there's almost nothing on their repo that's of any use to anybody. the "my wallet" is worthless without their server and is noted to not be open source, there's some untouched electrum and multibit forks, and that's all. |
| 04:33:10 | jcorgan: | dsnrk: i'm still reading through the analysis, but i think it just proves the hype around coinjoin is false; the actual properties of coinjoin as originally described by gmaxwell seem intact. |
| 04:37:21 | Luke-Jr: | jcorgan: bc.i probably doesn't understand it |
| 04:37:40 | Luke-Jr: | I expect DarkWallet's coinjoin is more solid |
| 04:38:07 | jcorgan: | well, i never took a close look at sharedcoin; i suspect it's not quite what gmaxwell wrote anyway |
| 04:38:13 | justanotheruser: | hmm. Sorry if this is OT, but does darkwallet plan on any decentralization? |
| 04:38:31 | Luke-Jr: | justanotheruser: might ask in #darkwallet |
| 04:38:39 | Luke-Jr: | no clue why those guys refuse to use #bitcoin-dev :/ |
| 04:38:39 | justanotheruser: | ok thanks |
| 04:39:42 | dsnrk: | jcorgan: it's sort of similar but has some stupid behaviour due to blockchain.info not bothering to do the whole BIP32 nonsense (it's just a fad after all). I didn't look into the mixing bit, but it aparantly just mixes with bc.i's wallet and back again. it's possible they're leaking information that way somehow. |
| 04:41:05 | dsnrk: | by the BIP32 comment I mean that their wallets only ever have one address unless you dick around. |
| 04:41:44 | jcorgan: | my impression at the time (again, i didn't look to closely), was that they used the hype around address validation to rebrand their mixer service as sharedcoin, and quietly let people think it was a coinjoin implementation. |
| 04:44:21 | dsnrk: | sharecoin seems to be a different system (it's "open source" but I doubt anybody could ever run it). it's based on bitcoinj and is set up to coinjoin-like transactions with the user. I imagine finding the entry point into the coinjoin chain would be easy identify as blockchain.info would mark it on their site as "relayed by blockchain.info". |
| 04:45:10 | dsnrk: | is not using change addresses a feature of multibit or bitcoinj? |
| 04:45:23 | gmaxwell: | multibit. |
| 04:45:35 | gmaxwell: | though bitcoinj basically leaves it up to the application. soooo... |
| 04:45:39 | dsnrk: | haha |
| 04:45:57 | Luke-Jr: | dsnrk: s/feature/bug/ |
| 04:46:13 | dsnrk: | either way that's stupid. the entry point will have a looped back tansaction (back to the original, no change) and the other transactions in the coinjoin will be using change addresses? |
| 04:46:38 | dsnrk: | if their coinjoin wallet *doesn't* use change addresses that would be stupid as well. |
| 04:48:39 | dsnrk: | https://github.com/blockchain/Sharedcoin/tree/master/lib < just me or are those compiled binaries with no source? |
| 04:49:39 | dsnrk: | so much for open source. |
| 04:51:02 | justanotheruser: | Are there more ideas for making namecoin "suck less" other than g-maxwells page? |
| 04:52:52 | dsnrk: | gmaxwell: heh, yeah it uses change addresses but the input the coinjoin doesn't. |
| 04:58:38 | dsnrk: | cute. sharedcoin has hardcoded paths for running it on a Mac. |
| 05:46:01 | petertodd: | Luke-Jr: modulo having to trust bc.i w/ shared coin, I think it's more solid than dark wallet |
| 05:46:41 | Luke-Jr: | :| |
| 05:47:24 | petertodd: | Luke-Jr: having a guaranteed counterparty that's matching your output amounts is very useful, and it's a much bigger user community in general |
| 05:49:29 | petertodd: | dsnrk: sharedcoin is integrated into bc.i wallets; use it repeatedly and it works just fine, just like any other coinjoin implementation. I've got zero reason to think this "expert" is doing anything novel. |
| 05:50:27 | Guest39249: | justanotheruser: what you say could be true (just require the hash), *if* you modify the p2p protocol to include inclusion proofs for inputs |
| 05:51:00 | petertodd: | dsnrk: very likely he's done the typical thing of doing some test transactions, noting (correctly) that the anonymity set is relatively small per transaction, and thinking that's a remarkable result, it's not. |
| 05:51:29 | justanotheruser: | Guest39249: yes, I was saying it would be a softfork, but sipa pointed out some good flaws in it. |
| 05:52:44 | petertodd: | justanotheruser: and yeah, decentralization will come. what's built right now essentially uses some central servers as dumb conduits for encrypted messages; the servers don't see what you're doing beyond metadata-type vulnerabilities |
| 05:53:39 | Guest39249: | justanotheruser: I'm not sure sipa pointed out any flaws |
| 05:53:59 | justanotheruser: | Guest39249: are you talking about SPV p2pool? |
| 05:54:04 | Guest39249: | he was I think just assuming bitcoin of today, which doesn't mandate prepended proofs |
| 05:54:05 | Guest39249: | yes |
| 05:54:10 | dsnrk: | petertodd: I think it's more than that, given that bc.i posted a blog saying that their sharedcoin isn't really all that useful *and* paid the researcher. |
| 05:54:29 | Guest39249: | Guest39249 is now known as maaku |
| 05:54:29 | justanotheruser: | Guest39249: yeah, he pointed out the flaws if there wasn't a proof for the inputs |
| 05:54:43 | maaku: | yes |
| 05:54:44 | petertodd: | dsnrk: think of it from their perspective: they *want* sharedcoin to not look too secure and anonymous |
| 05:54:53 | justanotheruser: | but are there any ways to make a small proof that wouldn't make SPV pointless other than SNARKs? |
| 05:55:01 | maaku: | imho adding the proofs of inputs is critical for scaling, but not just for SPV p2pool |
| 05:55:13 | justanotheruser: | petertodd: what are you talking about exactly? |
| 05:55:29 | petertodd: | justanotheruser: dark wallet coinjoin decentralization |
| 05:55:58 | maaku: | really it is storageless mining: you can forget the utxo set entirely because txns and blks will have input proofs prepended |
| 05:56:21 | justanotheruser: | petertodd: oh. |
| 05:56:52 | maaku: | justanotheruser: are we talking about side chains? |
| 05:57:05 | dsnrk: | petertodd: if they were worried about become a law enforcement target they wouldn't have a built an ecosystem that 1) prevents their wallets from acting with any privacy 2) publishes a lot of user information "relayed IP", "taint" in order to get people to use either of their two mixing services. |
| 05:57:07 | justanotheruser: | maaku: I wasn't sorry. |
| 05:57:42 | justanotheruser: | I was talking about making a p2pool that uses SPV |
| 05:57:57 | maaku: | well maybe it doesn't matter |
| 05:58:16 | petertodd: | dsnrk: notice how they're talking about privacy, the friendly fuzzy thing that helps honest citizens avoid crooks trying to steal their money, and distancing sharedcoin from the scary criminal anonymity, the thing terrorists and stuff use? |
| 05:58:27 | maaku: | the only way to ensure validation is to include the data and validate it |
| 05:59:02 | maaku: | , or construct some sort of Succinct Non-interactive ARgument of Knowledge that a program verifying it executed correctly |
| 05:59:15 | maaku: | so yes, by definition SNARK is the alternative |
| 06:00:00 | petertodd: | justanotheruser: you seen my TXO commitments? SNARKS is more compact, but they also allow for storageless mining. heck, they're so good it it's kinda scary and probably a vulnerability in itself... |
| 06:00:19 | dsnrk: | petertodd: I do. it's possible they got pressured at some point. I wouldn't be surprised to hear that. |
| 06:01:02 | maaku: | petertodd: that's basically the same as the utxo commitments, right? different tradeoffs but same scaling performance |
| 06:01:26 | maaku: | (O(log) vs SNARK's O(1)) |
| 06:01:28 | petertodd: | dsnrk: that's just their lawyers speaking probably, but you never know |
| 06:02:22 | justanotheruser: | petertodd: link? |
| 06:02:30 | petertodd: | maaku: utxo commitments require that the utxo set always be available, txo commitments have the significant advantage that parts of the utxo set can be dropped entirely |
| 06:03:37 | petertodd: | justanotheruser: https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194 |
| 06:03:42 | dsnrk: | petertodd: yes on that front I would not have run the service that they chose to. |
| 06:03:47 | maaku: | petertodd: yes different tradeoffs as I said, but performance scalability is not constant-size proofs like snarks |
| 06:04:26 | petertodd: | dsnrk: well, they're braver than you :) |
| 06:04:31 | justanotheruser: | petertodd thanks |
| 06:04:50 | petertodd: | maaku: right |
| 06:07:49 | petertodd: | justanotheruser: just keep in mind that without forcing mining to prove posession of blockchain data txo commitments are probably very dangerous for security; nothing in them requires validation at all, or more generally, genuine publication of blockchain data |
| 06:08:59 | dsnrk: | petertodd: I think they're more foolhardy than me actually. I wouldn't be able to sleep with so much BTC under my control in such a weak way. they've already broken their RNG once, I couldn't hire enough experts in the world to assure me everything was going to be alright. |
| 06:09:43 | justanotheruser: | petertodd: yeah, it was pointed out earlier to me that SPV mining is dangerous |
| 06:10:08 | petertodd: | dsnrk: meh, my other hobby is cave exploration - at least running web-wallets is probably not going to get them killed :) |
| 06:10:09 | maaku: | justanotheruser: supremely dangerous |
| 06:10:28 | maaku: | but commitments of either kind give you no excuse: you can do storageless mining will full node security |
| 06:10:33 | petertodd: | justanotheruser: that SPV mining is possible is one of the fundemental flaws of bitcoin |
| 06:10:59 | justanotheruser: | petertodd: Well it's not possible to fix even with a hardfork is it? |
| 06:11:04 | petertodd: | maaku: it's not really full node security |
| 06:11:23 | maaku: | petertodd: ? |
| 06:11:24 | petertodd: | justanotheruser: nope, that's easy to fix in a softfork by requiring miners to prove posession of blockchain data |
| 06:11:47 | dsnrk: | petertodd: I think you underestimate the impact of them going down. by the looks of things they store enough BTC to completely destroy bitcoin if it were compromised. |
| 06:12:01 | petertodd: | maaku: if I sync up block headers, then start mining with commitment proofs I'm trusting other miners to do verification for me |
| 06:12:04 | maaku: | petertodd: I'm talking about doing full validation from genesis, but only storing the root utxo hash, and mandating incoming blocks have input proofs |
| 06:12:09 | justanotheruser: | petertodd: I think we are speaking of different things. I thought you were saying the lack of ability to SPV mine is a flaw. |
| 06:12:25 | maaku: | *incoming blocks and transactions |
| 06:12:34 | petertodd: | dsnrk: no, I know exactly what'll happen if they go down - point is, they'll probably even get away without significant legal troubles if they honestly screwed up |
| 06:13:16 | petertodd: | maaku: sure, but if you don't do that, it's dangerous as heck, and nothing in bitcoin prevents you from taking a huge shortcut |
| 06:13:42 | petertodd: | justanotheruser: heh, well, the lack of scalability of mining is another huge flaw, and SPV in general is also a flaw. lots of flaws to go around here :) |
| 06:14:05 | justanotheruser: | petertodd: I am curious though. I didn't really understand last time. How do we prove that a miner has the blockchain without a hardfork. We can't do it before the mining process or that is outsourceable, we can't do it after because that is outsourceable, we can't do it during because that would change the difficulty significantly (or at least my intuition is telling me this). |
| 06:14:16 | dsnrk: | petertodd: legal troubles is irrelevant. they'd totally destroy all of the markets. they publish a transaction volume for their wallets, they've transfered a large portion of *all* transactions at this point. |
| 06:14:51 | petertodd: | justanotheruser: proving you posess blockchain data is an additional restriction on the validty of blocks, therefore it's a soft-fork |
| 06:15:08 | maaku: | justanotheruser: require a fiat shamir proof of utxo data based on the block hash before accepting or relaying a block |
| 06:15:16 | petertodd: | dsnrk: yes, and my point is all that stuff isn't necessarily *their* problem |
| 06:15:36 | justanotheruser: | petertodd: I understand, but wouldn't the utxo/blockchain querying be very difficult and decrease the difficulty by a factor of at least 100? |
| 06:15:51 | dsnrk: | petertodd: indeed. it's our problem if they fuck up. that's a comforting incentave for them to improve their code. /s |
| 06:15:54 | petertodd: | justanotheruser: equally I'm pretty sure amiller's non-outsourcable-puzzles scheme could be implemented as a soft-fork |
| 06:15:57 | maaku: | justanotheruser: uh, constant adjustments |
| 06:16:04 | maaku: | but you don't need to change the pow method |
| 06:16:34 | justanotheruser: | maaku: I think even a slight adjustment would invalidate every ASIC |
| 06:16:41 | maaku: | you just require 'random' walks through the utxo set based on the utxo root of the block being mined |
| 06:16:49 | maaku: | no adjustment whatsoever! |
| 06:17:00 | maaku: | this is block setup, not hashing |
| 06:17:10 | justanotheruser: | maaku: then how is it not outsourcable? |
| 06:17:47 | petertodd: | justanotheruser: you can essentially make the "difficulty" of this data proof be a factor of 10,000x easier than the ASIC, while still making outsourcing impractical |
| 06:17:49 | maaku: | justanotheruser: i'm not convinced that is a problem |
| 06:18:03 | petertodd: | justanotheruser: or make it part of a non-outsourcable puzzle scheme |
| 06:19:23 | justanotheruser: | petertodd: so for nonces 0-N query the blockchain based on H(block header with nonce=0) and repeat for N+1-2N, etc? |
| 06:19:41 | justanotheruser: | s/blockchain/utxo |
| 06:19:51 | petertodd: | justanotheruser: yeah, something like that - lots of possible schemes out there |
| 06:20:15 | justanotheruser: | and then I guess you would decrease the nonce slighly every block |
| 06:20:30 | justanotheruser: | sorry, not the nonce, N |
| 06:20:48 | maaku: | justanotheruser: what does non-outsoursability solve here? |
| 06:21:28 | petertodd: | maaku: prove genuine publication of blockchain data of course |
| 06:21:35 | justanotheruser: | maaku: miners are forced to audit the mining pools |
| 06:21:45 | maaku: | if you make the walk depend on the block hash, then you make is such that any miner who finds a valid block needs access to the utxo set to have it propogate |
| 06:21:57 | maaku: | no miner in their right mind would outsource that step |
| 06:22:09 | dsnrk: | * dsnrk glances at ghash.io |
| 06:22:18 | dsnrk: | miners already outsource *everything* |
| 06:22:53 | justanotheruser: | * justanotheruser glances at cex.io even harder than dsnrk was glancing at ghash.io |
| 06:22:58 | maaku: | dsnrk: do you think ghash.io would be okay knowing that the person they are relying on to propogate their blocks could just say "nope, haha!" at any time? |
| 06:23:42 | maaku: | petertodd: i'm not convinced of that utility either |
| 06:24:29 | maaku: | the ideal thing to shoot for imho is no data being published, ever |
| 06:24:44 | petertodd: | maaku: that's a nice ideal; doesn't work |
| 06:25:37 | petertodd: | you have to be publishing data so that others are guaranteed to be able to modify the state of consensus; if publishing is distinct from validation you get monopolies on access to the underlying data. no amount of snarks can fix that problem |
| 06:25:44 | dsnrk: | maaku: I just fail to see the point of proving you have the blockchain data- most miners don't. |
| 06:26:23 | justanotheruser: | Sorry if this is OT, but is there any way 51% of miners (mining pools really) could be convinced to allow a UTXO querying PoW/ |
| 06:26:54 | petertodd: | justanotheruser: who knows? that's a political question. |
| 06:27:09 | gmaxwell: | 21:51 < justanotheruser> Are there more ideas for making namecoin "suck less" other than g-maxwells page? |
| 06:27:28 | gmaxwell: | I have a bunch more, but meh, no one seems intersted in working on it. (I would be but its too low on my priority list) |
| 06:27:45 | dsnrk: | justanotheruser: it seems we can't even get ghash.io to not lie about their hashpower. what makes you think they would change anything to help the community out? |
| 06:28:02 | justanotheruser: | gmaxwell: the merkle root in coinbase seems like it would be easy to implement |
| 06:28:59 | justanotheruser: | dsnrk: We would probably need 51% between p2pool, eligius. |
| 06:29:18 | dsnrk: | isn't the coinbase pretty full? WK mentioned there's not a lot of space in theirs after stratum data. |
| 06:30:01 | petertodd: | dsnrk: the coinbase is a bad place to commit to data |
| 06:30:05 | justanotheruser: | I have no idea how active namecoins devteam is re: merkle in coinbase |
| 06:31:09 | dsnrk: | justanotheruser: eligius is only 8%, p2pool is barely anything. we solve a block every 2 days. |
| 06:31:30 | gmaxwell: | justanotheruser: what are you talking about it? |
| 06:31:38 | petertodd: | dsnrk: p2pool's scheme of an op_return + binary merkle tree of committed data is much better and can be compactly proven with a midstate |
| 06:31:47 | justanotheruser: | dsnrk: I know. It would have to be in the future |
| 06:31:51 | justanotheruser: | gmaxwell: regarding what? |
| 06:32:39 | gmaxwell: | "the merkle root in coinbase"? the? |
| 06:33:06 | justanotheruser: | gmaxwell: yeah, that's vague. The merkle root of the utxo merkle tree |
| 06:33:10 | gmaxwell: | oh |
| 06:33:13 | gmaxwell: | petertodd: commitments in the coinbase transaction generally suck. |
| 06:34:01 | justanotheruser: | It's a very good idea though. I think it is essential to namecoin getting mainstream adoption. |
| 06:34:13 | petertodd: | gmaxwell: yeah, I saw maaku's scheme, it suffers from the serious problem that it can't prove the absence of a commitment |
| 06:34:26 | gmaxwell: | justanotheruser: sure but it would be better in a transaction. |
| 06:34:30 | gmaxwell: | petertodd: can if the position is required. |
| 06:34:43 | gmaxwell: | (he had a softforking requirement that lets you prove absense IIRC) |
| 06:35:10 | petertodd: | gmaxwell: yes, then you're block is forced to have certain numbers of transactions in it in convoluted ways; might as well just require that tx #2 be the one true commitment tx |
| 06:35:37 | justanotheruser: | gmaxwell: what do you mean a transaction? I was talking about the inputs for the coinbase tx. |
| 06:35:42 | gmaxwell: | petertodd: yep. |
| 06:36:21 | gmaxwell: | justanotheruser: I know you were, but its a less good place than having it in another position. If it was some hardfork thing in namecoin you'd just put it at the top. but whatever, it's just details. |
| 06:39:02 | dsnrk: | petertodd: I'll have to check, but I don't think bc.i's coinjoin matches output sizes. |
| 06:39:10 | dsnrk: | RE: reddit comment. |
| 06:41:18 | petertodd: | dsnrk: they do |
| 06:41:36 | sipa: | coinjoin without it isbpretty pointless |
| 06:41:39 | sipa: | *is |
| 06:43:29 | gmaxwell: | without what? |
| 06:43:36 | gmaxwell: | oh matching output sizes. |
| 06:43:57 | gmaxwell: | sipa: well, mixed. BC.i's is... in some hypothetical world maybe not. |
| 06:44:58 | gmaxwell: | sipa: if you permit coinjoin users to be concurrently paying each other then all input/output mixtures are plausable (for some payment matrix) |
| 06:45:09 | gmaxwell: | though some are more plausable than others. :) |
| 06:45:30 | dsnrk: | does anybody have an example shared send transaction? |
| 06:45:38 | dsnrk: | I'm struggling to find one. |
| 06:45:41 | petertodd: | dsnrk: go make some yourself :) |
| 06:46:13 | petertodd: | seriously, a lot of misconceptions about this stuff would be cleared up if people actually used these tools themselves... |
| 06:46:40 | dsnrk: | I used it once in the past to try it out and that was the point that stuck with me. |
| 06:46:42 | gmaxwell: | would be easier if they had it running on testnet too.. (or any of their services…) |
| 06:47:05 | dsnrk: | I don't *really* want to post an example here with any of my real outputs. |
| 06:47:27 | petertodd: | dsnrk: then get yourself some public coins, for testing privacy tech :P |
| 06:48:01 | petertodd: | dsnrk: heck, I'll trade you some of your coins for my public ones... |
| 06:49:42 | dsnrk: | I'll be alright thank you. |
| 06:50:08 | gmaxwell: | dsnrk: or use andy's coinjoin to get some public coins. :) |
| 06:54:45 | gmaxwell: | * gmaxwell is black and blue from facepalming at https://bitcointalk.org/index.php?topic=645852.msg7226698#msg7226698 |
| 06:57:01 | gmaxwell: | Vitalik_: Are you going to go reality check that response? |
| 06:57:50 | dsnrk: | gmaxwell: just by the way, you should add coingoo.com to piqures autoban filter, expect a flood of IRC spam for it. it's already hitting reddit and the forums. |
| 07:01:18 | Luke-Jr: | yay gmaxwell is back |
| 07:02:01 | wumpus: | he does have a knack for finding the most cringe-worthy posts :) |
| 07:03:56 | petertodd: | gmaxwell: I thought the goal of ethereum was to get really high and contemplate the universe? |
| 07:04:15 | gmaxwell: | dsnrk: doing |
| 07:05:44 | gmaxwell: | dsnrk: done. |
| 07:07:22 | dsnrk: | "Wallet Recovery Mnemonic" "Please Write Down the Following:" |
| 07:07:30 | dsnrk: | then a blank space and a continue button. |
| 07:09:09 | Luke-Jr: | dsnrk: sounds easy to remember! |
| 07:09:17 | gmaxwell: | hah |
| 07:09:21 | dsnrk: | not that it's a mnemonic at all. it's just the users password XOR their wallet ID. |
| 07:13:39 | dsnrk: | petertodd: well I did what you said to do. got some outputs, spent them to a wallet, dicked around with their signup, and the service doesn't actually work \o/ |
| 07:14:49 | dsnrk: | "send payment" is grayed out and there's no reason why. no logged messages. |
| 07:15:28 | gmaxwell: | a confirmation requirement? |
| 07:16:06 | dsnrk: | output has 3 confirmations (nice run of three blocks in two minutes) and it's not giving me an error saying so. |
| 07:22:09 | dsnrk: | lots of bullshit going on in that wallet. |
| 07:22:44 | dsnrk: | "public note: This message will be permanently embedded in the blockchain. Anyone can read it." yep. no. |
| 07:23:16 | gmaxwell: | ... |
| 07:25:05 | dsnrk: | no wonder people come on #bitcoin thinking that transactions can have messages. |
| 07:25:27 | sipa: | people have been thinking that for ages |
| 07:26:09 | dsnrk: | I'm betting that line has been there for ages too. |
| 07:26:49 | gmaxwell: | they've never argued it when pointing it out. |
| 07:26:51 | dsnrk: | blockchain.info used to encode messages as addresses for a while until someone (gmaxwell?) told piuk he was being an idiot. |
| 07:29:45 | gmaxwell: | sgornick is still persisting on reddit in arguing that mining pools cannot engage in doublespending attacks. |
| 07:31:52 | petertodd: | gmaxwell: lol, where is this? |
| 07:32:01 | dsnrk: | http://www.reddit.com/r/Bitcoin/comments/27qjr4/a_51_attack_is_a_serious_risk_even_if_miners_act/ci3e8zu |
| 07:32:36 | petertodd: | sheesh |
| 07:32:37 | gmaxwell: | also http://www.reddit.com/r/Bitcoin/comments/27m6vk/its_51_day_again/ci2t3y1 |
| 07:32:44 | gmaxwell: | he's posting all over reddit, and being upvoted... |
| 07:33:42 | petertodd: | gmaxwell: well, getting upvoted is all about sounding authorative: https://pay.reddit.com/r/Bitcoin/comments/27oviz/weve_gotten_some_new_math_from_stanford_that/ci36gam?context=3 |
| 07:33:45 | dsnrk: | what's the bit about the two block fork? |
| 07:34:03 | sipa: | can we require that attacker blocks get an 'evil' bit? |
| 07:34:26 | petertodd: | sipa: they already do that; it's called having 'ghash.io' in the coinbase... |
| 07:34:29 | gmaxwell: | where the @#$@ is that 'quote' from? |
| 07:34:43 | dsnrk: | sipa: oh there was a solution on reddit that involved pools having an "ID" and getting a "time out" if they mined two blocks in a row. |
| 07:34:44 | Luke-Jr: | petertodd: ghash.io's hidden blocks don't have that right now |
| 07:35:03 | petertodd: | Luke-Jr: heh, I was just about to say... |
| 07:35:56 | dsnrk: | has anybody tried to find ghash.io's edge routers? that could be a fun rainy-day activity. |
| 07:36:17 | petertodd: | Luke-Jr: would be interesting to see if ghash.io's publicly found blocks has the expected statistical varience properties - probably could be shown if they automatically hide hashing power at some fixed threashold of lucky blocks |
| 07:37:46 | gmaxwell: | oh I see, it makes sense in context. |
| 07:39:30 | dsnrk: | does anybody expect that ghash.io's hidden pool is just a portion of their main one, or a totally isolated pool? |
| 07:40:06 | dsnrk: | you could probably prove loosely by looking at their stratum port and the "unknown" blocks and seeing if the timings matched up, right? |
| 07:41:30 | dsnrk: | that is, if they always see the "unknown" blocks significantly faster than other pools it's very likely to be them. |
| 07:43:09 | Luke-Jr: | petertodd: I doubt it's *that* complexly implemented. |
| 07:43:21 | Luke-Jr: | dsnrk: it's likely cex.io miners using other pools |
| 07:43:50 | dsnrk: | alright. |
| 07:44:37 | dsnrk: | oh sweet, shared coin works now. |
| 07:46:57 | dsnrk: | petertodd: gmaxwell: I was right. Shared Coin *does not* enforce output sizes. |
| 07:48:00 | dsnrk: | if you are interesting in seeing the transactions please private message me. |
| 07:51:45 | petertodd: | interesting, yeah, looks like the behavior changed slightly... |
| 07:51:55 | dsnrk: | actually looking at these basted transactions it's super easy to see the path through. |
| 07:53:24 | petertodd: | https://blockchain.info/tx/f68818249eac95717f414cfa6a6414787ea667a0849c84aa38a750f3103ce8ac <- 1BDTzp7fjoZfK7u6AyEGoQXhyKuLmtz5j7 0.01233445 is the output I selected |
| 07:54:22 | Luke-Jr: | who invented this braindead git-subtree nonsense anyway? -.- |
| 07:59:07 | dsnrk: | just to point out, given only the output of my "coinjoin" petertodd was able to find the input instantly. |
| 08:15:27 | petertodd: | yup, took all of 30 seconds. it used to do proper output matching, but mysteriously doesn't any more |
| 08:17:24 | dsnrk: | ... |
| 08:17:57 | petertodd: | http://www.reddit.com/r/Bitcoin/comments/27rs70/confirmed_blockchaininfo_shared_send_is_broken/ |
| 08:18:36 | dsnrk: | upboated. |
| 08:19:03 | dsnrk: | > expensive |
| 08:19:09 | dsnrk: | yeah I spent like $5 just then. |
| 08:19:33 | dsnrk: | also lost 0.6BTC because the shared send failed. |
| 08:19:41 | dsnrk: | *0.06 |
| 08:21:43 | dsnrk: | there it is, belay that last bit. never made it to my node but it's shown on blockchain.info |
| 08:22:18 | petertodd: | yeah, there is a recovery mechanism there |
| 08:23:00 | dsnrk: | I tried that but my browser hung. |
| 08:24:30 | petertodd: | ha |
| 08:30:29 | dsnrk: | petertodd: you sort of broke that reddit post :| http://www.reddit.com/r/Bitcoin/comments/27rs70/confirmed_blockchaininfo_shared_send_is_broken/ci3qesw |
| 08:35:05 | petertodd: | lol, reposted - I'm gonna have to call my next service Coinbase Bit Block Chain Thing. |
| 08:38:01 | dsnrk: | you need lessons in writing reddit tiles. it needs more hyperbole. SHARED COIN IS REACHING 51% GET OUT OF THE POOL |
| 08:38:20 | dsnrk: | (the title is fine don't change it) |
| 08:40:29 | petertodd: | well, I changed it to the correct name anyway: http://www.reddit.com/r/Bitcoin/comments/27rsv8/confirmed_blockchaininfo_shared_coin_is_broken/ |
| 08:40:39 | gmaxwell: | "DoubleSpend-lite coin based bit-chain pool announces script reorganization. New software version "Genesis" to be written in Node." |
| 08:41:38 | petertodd: | gmaxwell: is there proof it works? |
| 08:41:49 | sipa: | will be it webscale? |
| 08:41:51 | dsnrk: | gmaxwell: I'm not buying it without Antonopoulos |
| 09:00:44 | gmaxwell: | nice, some moron is threatning to DOS attack bitcointalk because I said something negative about darkcoin. |
| 09:00:50 | gmaxwell: | (he thinks bitcointalk is my site) |
| 09:04:23 | BlueMatt: | anyone want a user@bitcoin.ninja email forward or a user.bitcoin.ninja subdomain? =D |
| 09:04:35 | BlueMatt: | jgarzik: ^ |
| 09:05:11 | Emcy: | is that domain real |
| 09:05:15 | BlueMatt: | yup |
| 09:05:30 | Emcy: | greif |
| 09:05:54 | gmaxwell: | BlueMatt: Yep. |
| 09:05:58 | Emcy: | registrars printing money |
| 09:06:02 | gmaxwell: | ninja is a TLD? |
| 09:06:12 | BlueMatt: | it is, some tld company registering things like it |
| 09:06:14 | Luke-Jr: | BlueMatt: haha, so you got it. I think my registrar screwed up on my pre-regs :p |
| 09:06:38 | gmaxwell: | what registrar would y'all suggest for that tld? |
| 09:06:50 | BlueMatt: | no, the registrar had, for some reason, been holding it as a reserved word, but I emailed them and they released it |
| 09:06:55 | dsnrk: | bitcoin.horse is still free. |
| 09:07:11 | BlueMatt: | anyway, first bed, tomorrow setup email and aliases for everyone :) |
| 09:07:38 | gmaxwell: | dsnrk: Best of all the animals. |
| 09:10:11 | dsnrk: | gmaxwell: there's one for Luke-Jr if he was russian too |
| 09:10:50 | dsnrk: | .католик is "catholic" |
| 09:17:42 | gmaxwell: | I just registered codec.ninja |
| 09:19:10 | Luke-Jr: | gmaxwell: very you |
| 09:21:10 | gmaxwell: | crypto.ninja was taken. :( |
| 09:38:59 | dsnrk: | crypto.secure? |
| 09:39:53 | dsnrk: | crypto.cityeats |
| 12:03:28 | jgarzik: | BlueMatt, me me me |
| 12:14:00 | sipa: | BlueMatt: me two! |
| 12:31:15 | wumpus: | crypto.horse is still free! |
| 12:32:00 | dsnrk: | get on it! |
| 12:33:00 | Emcy: | how many dictionary words did they make domains now |
| 12:34:07 | dsnrk: | hundreds. |
| 12:35:04 | dsnrk: | less than 1000 I think. lots of companies like Coke dropped their applications when it got changed to them not being able to have the TLD resolve. they would have originally been able to put an A record on it and be http://coke/ |
| 12:35:06 | Emcy: | it should be illegal |
| 12:41:43 | mtgox555: | where do i find a list? |
| 12:43:12 | dsnrk: | of TLD? |
| 12:43:52 | dsnrk: | I have one somewhere, I'll have to see if I can find it. |
| 12:44:03 | mtgox555: | a list of the new tlds yea :) |
| 12:45:01 | dsnrk: | ah, list I have is all of them godaddy.com has a list of them you can search through under "new TLD" in the menu. that's easiest though fairly evil. |
| 12:56:02 | mtgox555: | good enough for me atm :) |
| 13:16:54 | mtgox555: | bitcoin.foundation is bought |
| 13:43:42 | jgarzik: | gmaxwell, what is the state of your moxie toy? I am tempted to make a working demo out of it |
| 13:51:41 | jgarzik: | and related wizards territory, |
| 13:52:58 | jgarzik: | Has anyone designed a secure, difficult to DoS, pay-to-use comm network? :) |
| 14:15:07 | jgarzik: | sounds like I could re-create the moxie toy easily enough |
| 14:15:08 | hearn: | jgarzik: yeah |
| 14:15:16 | hearn: | jgarzik: the 3GPP ;) |
| 14:30:43 | jgarzik: | http://moxielogic.org/wiki/index.php/Main_Page |
| 14:32:02 | hearn: | jgarzik: what you're really asking is, has anyone created a decentralised network with anonymous participants that is difficult to DoS? |
| 14:32:07 | hearn: | and i suspect the answer is no |
| 14:34:53 | jgarzik: | Browsing around, I see a sim in https://github.com/atgreen/moxiedev/tree/master/src/sim/moxie |
| 14:35:01 | jgarzik: | and another proto-sim in the qemu port |
| 15:48:53 | millsdmb: | millsdmb has left #bitcoin-wizards |
| 15:54:54 | mircea_popescu: | mircea_popescu has left #bitcoin-wizards |
| 16:06:03 | mircea_popescu: | ;;later tell petertodd re: "We really need at least one more group working " see the discussion re actual anonimity and bitbet - http://log.bitcoin-assets.com/?date=20-02-2014 (also notworthy for the historian because it preserves usg agent attempt to railroad teh discussion) |
| 16:06:03 | gribble: | The operation succeeded. |
| 16:06:39 | mircea_popescu: | ;;later tell petertodd so no, "we" don't really need more people derping with coinjoin. what bitcoin needs is what !we already have been doing, for years. |
| 16:06:39 | gribble: | The operation succeeded. |
| 16:07:01 | mircea_popescu: | mircea_popescu has left #bitcoin-wizards |
| 16:28:05 | bob131313: | bob131313 has left #bitcoin-wizards |
| 17:04:30 | adam3us: | hearn: "what you're really asking is, has anyone created a decentralised network with anonymous participants that is difficult to DoS?" that is the topic of this paper we wrote at zks |
| 17:04:46 | adam3us: | hearn: http://cypherspace.org/adam/pubs/traffic.pdf |
| 17:05:12 | adam3us: | hearn: we concur with your conclusion and propose a triangle. |
| 17:08:13 | phantomcircuit: | adam3us, im guessing the basic answer is no |
| 17:28:56 | andrew___: | andrew___ is now known as justanotheruser |
| 17:29:16 | andrew__2: | andrew__2 is now known as justanotheruser |
| 18:31:31 | stqism: | stqism is now known as NikolaiToryzin |
| 18:34:56 | andytoshi: | are there any signature schemes which can be validated by a non-CRS zikp? is it possible to make an extremely restricted cryptocurrency with zkps for blocks? |
| 18:41:15 | andytoshi: | i guess i need slightly more than that, i need to be able to nizkp non-conflicting utxoset updating.. the signature evaluation is just a small subset. but i was thinking, suppose there is no script, every utxo has the same value and consists of just a pubkey. to spend you sign a new pubkey. is this simple enough that we don't need any fancy snark machinery? |
| 19:08:45 | jcorgan: | l |
| 19:16:28 | NikolaiToryzin: | NikolaiToryzin is now known as stqism |
| 19:18:12 | maaku: | andytoshi: sounds like zerocash |
| 19:23:53 | tekto786: | tekto786 has left #bitcoin-wizards |
| 19:54:36 | andytoshi: | maaku: hmm. but zerocash involves a crs yes? i guess it is necessary :( |
| 20:33:17 | wilhelm.freenode.net: | Server Terminating. tomaw |
| 20:33:18 | irc.freenode.net: | Disconnected from irc.freenode.net (Connection reset by peer) |
| 20:34:35 | hobana.freenode.net: | topic is: This channel is not about short-term Bitcoin development | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi." |
| 20:34:35 | hobana.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot K1773R ewust adam3us kanzure Guest24131 kiddouk EasyAt bobke arubi spinza justanotheruser gloriusA_ vfor AttackManatee mortale ielo waxwing gonedrk hearn Krellan_ jgarzik wallet42 _cajg drawingthesun qwertyoruiop_ MoALTz posita polyclef shesek jaekwon maraoz DougieBot5000 llllllllll gavinandresen_ pen Guyver2 mr_burdell Vitalik__ Emcy stephenreed krevil23 Adohgg rdponticelli c0rw1n_ Quanttek artifexd justusranvier |
| 20:34:35 | hobana.freenode.net: | Users on #bitcoin-wizards: AaronvanW_ px1NbxQzEC roconnor__ HaltingState edulix Burrito lnovy melvster dgenr8 stqism TheSeven nanotube maaku postpre altoz tromp realazthat gmaxwell midnightmagic eristisk forrestv tjopper Luke-Jr samson_ mkarrer gavinandresen harrow tacotime_ nickler Cory jchp espes copumpkin nkuttler OneFixt tromp__ iddo UukGoblin alferz Hunger- HM rs0 poggy BlueMatt so asoltys wumpus a5m0 dansmith_btc andytoshi Graet flammit mumu kinlo amiller sipa |
| 20:34:35 | hobana.freenode.net: | Users on #bitcoin-wizards: Alanius zenojis coyo phantomcircuit [\\\] d34th warren LarsLarsen helo bitz emsid nikitab burcin go1111111 sl01 jaromil_ at0mat DoctorBTC digitalmagus7 michagogo davidlatapie petertodd Logicwax keus jcorgan Sangheili weex comboy dsnrk ryan-c lianj [Tristan] Kretchfoop Krellan Eliel pigeons ageis lechuga_ Apocalyptic heakins roasbeef LaptopZZ_ @ChanServ epscy BCB Muis optimator otoburb mhanne lenticulis quackgyver Fistful_of_Coins Mikalv |
| 20:34:35 | hobana.freenode.net: | Users on #bitcoin-wizards: mmozeiko zibbo Dyaheon- Anduck crescendo |
| 20:53:56 | maaku_: | andytoshi: you are into non-published territory if you are looking for a non-CRS, practical SNARK |
| 20:54:30 | maaku_: | although rumors are there are some things in the works ... but 'practical' may be a relative judgement (proofs kilobytes in size) |
| 20:57:23 | andytoshi: | maaku_: yeah, i understand that snarks are uncharted territory.. i was hoping we could simplify things so that a special-purpose NIZK would do. but as you say, what i described is pretty-much what zerocash had to do just to get their crs proofs to be feasible..so if there was a non-crs option they'd have taken it. |
| 20:57:42 | justanotheruser: | Would it be possible to increase block size with a softfork? |
| 21:06:05 | _cajg: | _cajg is now known as cajg |
| 21:08:11 | andytoshi: | no. nodes that didn't changeover would be unaware of the large blocks' content no matter how you orchestrated them |
| 21:11:26 | justanotheruser: | hmm. What if there was an opcode paying to someone that was OP_NOP to the old nodes, but to new clients it was paying to someone and their transactions could only be recognized by new clients in a new merkle tree. |
| 21:11:33 | justanotheruser: | I guess that's basically sidechains though. |
| 21:46:21 | maaku_: | maaku_ is now known as maaku |
| 21:47:29 | maaku: | justanotheruser: precisely |
| 21:53:05 | dsnrk: | petertodd: weird. I was expecting a response from blockchain.info, they are very active on reddit. |
| 21:56:33 | justanotheruser: | dsnrk: Have they ever been called out for doing something wrong like this on reddit? |
| 21:58:59 | dsnrk: | justanotheruser: yeah there was something about them having a vulnerability on their site one and they responses. they respond almost daily to the "blockchain is down!" posts too. |
| 21:59:25 | dsnrk: | *responded |
| 21:59:47 | justanotheruser: | dsnrk: Yeah, this isn't as big of a mess-up as their bad RNG I guess |
| 22:00:00 | dsnrk: | http://reddit.com/user/blockchainwallet < wow they have a lot more downtime than I realised |
| 22:02:51 | dsnrk: | justanotheruser: it's potentially worse. they paid back people who lost money due to their RNG screwup. they can't restore the privacy of those they pretended to protect. andreas hasn't made mention of it either, which is weird for a security officer. |
| 22:03:27 | gmaxwell: | dsnrk: pftt, what, next you're going to suggest people promoting malware should make people whole. |
| 22:04:40 | helo: | only some... like the ones hosting it too |
| 22:09:48 | dsnrk: | wut https://twitter.com/aantonop/status/476085699964198912 |
| 22:10:41 | gmaxwell: | Will he ever say something about technology which isn't incorrect? :( |
| 22:11:09 | Apocalyptic: | heh |
| 22:35:16 | coke0: | gmaxwell: in a forum post from October 2013 you state that systems based on balances (as opposed to txout) have many complicated race conditions. Ethereum deals with this using a nonce, but it seems that you're implying it's not that simple. Can you elaborate? |
| 22:38:20 | gmaxwell: | coke0: There are ways to solve it, including potentially having a nonce, but at least when I've worked through this in the past it ended up being very nearly isomorphic to a non-balance system. Just having a nonce to prevent replay isn't enough, you need to be able to specify nonces to conflict with for conflict control. |
| 22:39:53 | coke0: | you obliviously have to refer to the nonce in your transaction |
| 22:40:11 | coke0: | but apart from that, how is that more complicated |
| 22:40:26 | coke0: | basically (nonce, address) <=> txout |
| 22:42:25 | justanotheruser: | if you use a nonce is there a risk of collisions? |
| 23:57:37 | dsnrk: | any theories on ghash.io having dropped their block size to the default again? |
| 23:57:52 | dsnrk: | they're back to making super-small blocks now. |