00:03:56warren:justanotheruser: http://www.coindesk.com/bitcoin-technology-anonymous-tor-network-more-powerful/
00:07:02justanotheruser:"The proof-of-bandwidth concept"
00:07:14justanotheruser:That's an oxymoron. There is no way to prove bandwidth
00:28:09Pelican:Pelican has left #bitcoin-wizards
00:33:41[Derek]:[Derek] is now known as Guest49412
00:36:12dsnrk:justanotheruser: gmax has some nice comments about that already. https://news.ycombinator.com/threads?id=nullc
00:36:23dsnrk:(he's not impressed)
00:49:57amiller:so that torcoin team was originally part of a larger paper i was on
00:50:28amiller: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:49amiller:both of our papers are going to be presented at the same workshop in amsterdam
00:51:13amiller:ours isn't called "torcoin" though so probably no one will care :o
00:53:29gmaxwell: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:54:02gmaxwell:( https://news.ycombinator.com/item?id=7850738 )
01:20:08petertodd: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:31petertodd:heck, I specifically used torcoin as an example of when an appcoin *doesn't* make sense...
01:20:47justanotheruser:petertodd: is the price of the bandwidth even comparable to a transaction fee?
01:21:37petertodd:justanotheruser: hence the micropayment channel! equally could use probabalistic payments (I have a working scheme for that using coinbase outputs)
01:24:27justanotheruser:petertodd: what, on a sidechain? Or by slowly increasing the amount paid?
01:25:10petertodd:justanotheruser: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02159.html
01:26:42petertodd: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:58dsnrk: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:12amiller:have you guys seen this project https://github.com/orisi/wiki/wiki/Orisi-White-Paper
01:34:21amiller:it's aiming to be an implementation of the m/n general purpose oracles stuff
01:36:23petertodd:amiller: nice, looks like they're implementing my revealed secret key suggestion from ages ago
01:36:53petertodd:amiller: could still be improved by getting rid of IsStandard() so they don't need such a ridiculous number of keys mind...
01:38:57petertodd: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:40petertodd: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:39jgarzik:amiller, cool
01:45:50jgarzik:petertodd, What is better than BitMessage? While I agree with BM is ugly, incomplete, attack prone, poorly coded, ... the question remains.
01:46:54jgarzik: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:28jgarzik: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:34petertodd: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:22jgarzik:petertodd, bleh. Pooping in the bitcoin blockchain for temporary comms is just about the worst solution.
01:49:58petertodd:meh, there's no other option if you need decentralized messaging where timely detection of censorship is important
01:50:31petertodd:but that is a pretty specialized application, mainly needed for finance stuff. (e.g. market orders)
01:50:48dsnrk:does bitmessage really hide the origin? I thought low-latency anonymisation was almost impossible
01:51:23petertodd: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:30dsnrk:impossible assuming an all encompassing observer.
01:52:29dsnrk:petertodd: so does bitcoind really, you can test bitcoin nodes for the ownership of a particular address.
01:52:43petertodd: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:51petertodd:dsnrk: yes, thats a bug :)
01:53:25sl01:OTR over pastebin, google for message discovery :P
01:53:26jgarzik:petertodd, need TempCoin
01:53:52dsnrk:padding is sort of only semi-useful, you're limited by the upper bounds of bandwidth. probably alright for oracle messages though.
01:54:04petertodd:sl01: lol
01:54:26dsnrk:sl01: I prefer stenography. communication through popular memes on reddit.
01:54:40petertodd:jgarzik: security vs. scalability is a tradeoff, simple as that. hence tree chains and its powers of two tradeoff choices
01:55:30petertodd: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:51jgarzik: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:29petertodd:it'll be fun watching all the real-world attacks on zerocash due to metadata...
01:57:12dsnrk: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:16jgarzik:This ignores of course the presumed-then-revealed fact that many Tor nodes are run by the gov't
01:57:37jgarzik:dsnrk, yes, you need to regularize packet size & timings
01:57:40jgarzik:for a start
01:58:36petertodd: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:48dsnrk: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:05jgarzik: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:11petertodd: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:31petertodd: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:02dsnrk: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:59petertodd: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:49dsnrk: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:09petertodd:dsnrk: security is expensive :)
02:03:48petertodd:what's the definition of "client"?
02:03:57dsnrk:someone connecting to my node
02:04:05petertodd:I mean, how do you measure that?
02:04:35petertodd:er, I mean, did you run that once, or do you have something more sophisticated?
02:04:55dsnrk:oh sorry, I have two nodes listening with around 100 connections each
02:05:11petertodd:right, so basically Bandwidth / 100
02:05:16dsnrk:one local for p2pool, one external.
02:06:10dsnrk:* dsnrk shrugs
02:07:53dsnrk:I'm more bothered by the range of fake nodes that connect to mine more than anything
02:08:28dsnrk:lots of things *claiming* to be bitcoin core but not
02:08:31petertodd:how do you know they're fake?
02:09:30dsnrk:yeah I spent way too much time on this.
02:10:35dsnrk: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:49dsnrk:*invalid transactions that fail the pubkey check
02:11:19petertodd:dsnrk: we recently added some new conditions to signature checks; those might be old nodes
02:11:48petertodd:as for never sending inventory, they might not be connected to many other nodes and thus rarely have inventory to snd
02:11:55dsnrk:nah, all my connected nodes are 0.8.5 or older.
02:11:58petertodd:bitnodes.io OTOH :)
02:12:10petertodd:well, could be academics too :)
02:12:34dsnrk:still wish they used subver properly so I could ban them
02:12:38petertodd: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:45dsnrk:blockchain.info are IP banned naturally
02:13:09petertodd:meh, write a patch that tests peers for usefullness!
02:13:22dsnrk:gmaxwell had something about that
02:15:12petertodd:yeah, it's a rather political issue because inherently SPV nodes have a hard time being useful
02:16:22dsnrk: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:55petertodd:heh, well, good luck enforcing that in an anonymous decentralized system... besides, revealing yourself is a privacy risk
02:17:22dsnrk:yeah using fake subvers worked for blockchain.info :)
02:22:57maaku:maaku is now known as Guest39249
03:19:57justanotheruser:petertodd: what do you think of appcoins like storjcoin?
03:20:07justanotheruser:is your writeup complete?
04:19:10Sangheil-:Sangheil- is now known as Sangheili
04:20:37dsnrk:ha! blockchain.info just admitted their "sharedcoin" mixer was completely useless.
04:22:40dsnrk: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:10jcorgan: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:21Luke-Jr:jcorgan: bc.i probably doesn't understand it
04:37:40Luke-Jr:I expect DarkWallet's coinjoin is more solid
04:38:07jcorgan:well, i never took a close look at sharedcoin; i suspect it's not quite what gmaxwell wrote anyway
04:38:13justanotheruser:hmm. Sorry if this is OT, but does darkwallet plan on any decentralization?
04:38:31Luke-Jr:justanotheruser: might ask in #darkwallet
04:38:39Luke-Jr:no clue why those guys refuse to use #bitcoin-dev :/
04:38:39justanotheruser:ok thanks
04:39:42dsnrk: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:05dsnrk:by the BIP32 comment I mean that their wallets only ever have one address unless you dick around.
04:41:44jcorgan: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:21dsnrk: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:10dsnrk:is not using change addresses a feature of multibit or bitcoinj?
04:45:35gmaxwell:though bitcoinj basically leaves it up to the application. soooo...
04:45:57Luke-Jr:dsnrk: s/feature/bug/
04:46:13dsnrk: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:38dsnrk:if their coinjoin wallet *doesn't* use change addresses that would be stupid as well.
04:48:39dsnrk:https://github.com/blockchain/Sharedcoin/tree/master/lib < just me or are those compiled binaries with no source?
04:49:39dsnrk:so much for open source.
04:51:02justanotheruser:Are there more ideas for making namecoin "suck less" other than g-maxwells page?
04:52:52dsnrk:gmaxwell: heh, yeah it uses change addresses but the input the coinjoin doesn't.
04:58:38dsnrk:cute. sharedcoin has hardcoded paths for running it on a Mac.
05:46:01petertodd:Luke-Jr: modulo having to trust bc.i w/ shared coin, I think it's more solid than dark wallet
05:47:24petertodd: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:29petertodd: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:27Guest39249: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:00petertodd: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:29justanotheruser:Guest39249: yes, I was saying it would be a softfork, but sipa pointed out some good flaws in it.
05:52:44petertodd: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:39Guest39249:justanotheruser: I'm not sure sipa pointed out any flaws
05:53:59justanotheruser:Guest39249: are you talking about SPV p2pool?
05:54:04Guest39249:he was I think just assuming bitcoin of today, which doesn't mandate prepended proofs
05:54:10dsnrk: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:29Guest39249:Guest39249 is now known as maaku
05:54:29justanotheruser:Guest39249: yeah, he pointed out the flaws if there wasn't a proof for the inputs
05:54:44petertodd:dsnrk: think of it from their perspective: they *want* sharedcoin to not look too secure and anonymous
05:54:53justanotheruser:but are there any ways to make a small proof that wouldn't make SPV pointless other than SNARKs?
05:55:01maaku:imho adding the proofs of inputs is critical for scaling, but not just for SPV p2pool
05:55:13justanotheruser:petertodd: what are you talking about exactly?
05:55:29petertodd:justanotheruser: dark wallet coinjoin decentralization
05:55:58maaku:really it is storageless mining: you can forget the utxo set entirely because txns and blks will have input proofs prepended
05:56:21justanotheruser:petertodd: oh.
05:56:52maaku:justanotheruser: are we talking about side chains?
05:57:05dsnrk: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:07justanotheruser:maaku: I wasn't sorry.
05:57:42justanotheruser:I was talking about making a p2pool that uses SPV
05:57:57maaku:well maybe it doesn't matter
05:58:16petertodd: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:27maaku:the only way to ensure validation is to include the data and validate it
05:59:02maaku:, or construct some sort of Succinct Non-interactive ARgument of Knowledge that a program verifying it executed correctly
05:59:15maaku:so yes, by definition SNARK is the alternative
06:00:00petertodd: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:19dsnrk:petertodd: I do. it's possible they got pressured at some point. I wouldn't be surprised to hear that.
06:01:02maaku:petertodd: that's basically the same as the utxo commitments, right? different tradeoffs but same scaling performance
06:01:26maaku:(O(log) vs SNARK's O(1))
06:01:28petertodd:dsnrk: that's just their lawyers speaking probably, but you never know
06:02:22justanotheruser:petertodd: link?
06:02:30petertodd: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:37petertodd:justanotheruser: https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194
06:03:42dsnrk:petertodd: yes on that front I would not have run the service that they chose to.
06:03:47maaku:petertodd: yes different tradeoffs as I said, but performance scalability is not constant-size proofs like snarks
06:04:26petertodd:dsnrk: well, they're braver than you :)
06:04:31justanotheruser:petertodd thanks
06:04:50petertodd:maaku: right
06:07:49petertodd: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:59dsnrk: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:43justanotheruser:petertodd: yeah, it was pointed out earlier to me that SPV mining is dangerous
06:10:08petertodd:dsnrk: meh, my other hobby is cave exploration - at least running web-wallets is probably not going to get them killed :)
06:10:09maaku:justanotheruser: supremely dangerous
06:10:28maaku:but commitments of either kind give you no excuse: you can do storageless mining will full node security
06:10:33petertodd:justanotheruser: that SPV mining is possible is one of the fundemental flaws of bitcoin
06:10:59justanotheruser:petertodd: Well it's not possible to fix even with a hardfork is it?
06:11:04petertodd:maaku: it's not really full node security
06:11:23maaku:petertodd: ?
06:11:24petertodd:justanotheruser: nope, that's easy to fix in a softfork by requiring miners to prove posession of blockchain data
06:11:47dsnrk: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:01petertodd: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:04maaku: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:09justanotheruser: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:25maaku:*incoming blocks and transactions
06:12:34petertodd: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:16petertodd: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:42petertodd: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:05justanotheruser: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:16dsnrk: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:51petertodd:justanotheruser: proving you posess blockchain data is an additional restriction on the validty of blocks, therefore it's a soft-fork
06:15:08maaku:justanotheruser: require a fiat shamir proof of utxo data based on the block hash before accepting or relaying a block
06:15:16petertodd:dsnrk: yes, and my point is all that stuff isn't necessarily *their* problem
06:15:36justanotheruser: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:51dsnrk:petertodd: indeed. it's our problem if they fuck up. that's a comforting incentave for them to improve their code. /s
06:15:54petertodd:justanotheruser: equally I'm pretty sure amiller's non-outsourcable-puzzles scheme could be implemented as a soft-fork
06:15:57maaku:justanotheruser: uh, constant adjustments
06:16:04maaku:but you don't need to change the pow method
06:16:34justanotheruser:maaku: I think even a slight adjustment would invalidate every ASIC
06:16:41maaku:you just require 'random' walks through the utxo set based on the utxo root of the block being mined
06:16:49maaku:no adjustment whatsoever!
06:17:00maaku:this is block setup, not hashing
06:17:10justanotheruser:maaku: then how is it not outsourcable?
06:17:47petertodd: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:49maaku:justanotheruser: i'm not convinced that is a problem
06:18:03petertodd:justanotheruser: or make it part of a non-outsourcable puzzle scheme
06:19:23justanotheruser: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:51petertodd:justanotheruser: yeah, something like that - lots of possible schemes out there
06:20:15justanotheruser:and then I guess you would decrease the nonce slighly every block
06:20:30justanotheruser:sorry, not the nonce, N
06:20:48maaku:justanotheruser: what does non-outsoursability solve here?
06:21:28petertodd:maaku: prove genuine publication of blockchain data of course
06:21:35justanotheruser:maaku: miners are forced to audit the mining pools
06:21:45maaku: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:57maaku:no miner in their right mind would outsource that step
06:22:09dsnrk:* dsnrk glances at ghash.io
06:22:18dsnrk:miners already outsource *everything*
06:22:53justanotheruser:* justanotheruser glances at cex.io even harder than dsnrk was glancing at ghash.io
06:22:58maaku: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:42maaku:petertodd: i'm not convinced of that utility either
06:24:29maaku:the ideal thing to shoot for imho is no data being published, ever
06:24:44petertodd:maaku: that's a nice ideal; doesn't work
06:25:37petertodd: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:44dsnrk:maaku: I just fail to see the point of proving you have the blockchain data- most miners don't.
06:26:23justanotheruser: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:54petertodd:justanotheruser: who knows? that's a political question.
06:27:09gmaxwell:21:51 < justanotheruser> Are there more ideas for making namecoin "suck less" other than g-maxwells page?
06:27:28gmaxwell: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:45dsnrk: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:02justanotheruser:gmaxwell: the merkle root in coinbase seems like it would be easy to implement
06:28:59justanotheruser:dsnrk: We would probably need 51% between p2pool, eligius.
06:29:18dsnrk:isn't the coinbase pretty full? WK mentioned there's not a lot of space in theirs after stratum data.
06:30:01petertodd:dsnrk: the coinbase is a bad place to commit to data
06:30:05justanotheruser:I have no idea how active namecoins devteam is re: merkle in coinbase
06:31:09dsnrk:justanotheruser: eligius is only 8%, p2pool is barely anything. we solve a block every 2 days.
06:31:30gmaxwell:justanotheruser: what are you talking about it?
06:31:38petertodd: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:47justanotheruser:dsnrk: I know. It would have to be in the future
06:31:51justanotheruser:gmaxwell: regarding what?
06:32:39gmaxwell:"the merkle root in coinbase"? the?
06:33:06justanotheruser:gmaxwell: yeah, that's vague. The merkle root of the utxo merkle tree
06:33:13gmaxwell:petertodd: commitments in the coinbase transaction generally suck.
06:34:01justanotheruser:It's a very good idea though. I think it is essential to namecoin getting mainstream adoption.
06:34:13petertodd: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:26gmaxwell:justanotheruser: sure but it would be better in a transaction.
06:34:30gmaxwell:petertodd: can if the position is required.
06:34:43gmaxwell:(he had a softforking requirement that lets you prove absense IIRC)
06:35:10petertodd: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:37justanotheruser:gmaxwell: what do you mean a transaction? I was talking about the inputs for the coinbase tx.
06:35:42gmaxwell:petertodd: yep.
06:36:21gmaxwell: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:02dsnrk:petertodd: I'll have to check, but I don't think bc.i's coinjoin matches output sizes.
06:39:10dsnrk:RE: reddit comment.
06:41:18petertodd:dsnrk: they do
06:41:36sipa:coinjoin without it isbpretty pointless
06:43:29gmaxwell:without what?
06:43:36gmaxwell:oh matching output sizes.
06:43:57gmaxwell:sipa: well, mixed. BC.i's is... in some hypothetical world maybe not.
06:44:58gmaxwell: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:09gmaxwell:though some are more plausable than others. :)
06:45:30dsnrk:does anybody have an example shared send transaction?
06:45:38dsnrk:I'm struggling to find one.
06:45:41petertodd:dsnrk: go make some yourself :)
06:46:13petertodd:seriously, a lot of misconceptions about this stuff would be cleared up if people actually used these tools themselves...
06:46:40dsnrk:I used it once in the past to try it out and that was the point that stuck with me.
06:46:42gmaxwell:would be easier if they had it running on testnet too.. (or any of their services…)
06:47:05dsnrk:I don't *really* want to post an example here with any of my real outputs.
06:47:27petertodd:dsnrk: then get yourself some public coins, for testing privacy tech :P
06:48:01petertodd:dsnrk: heck, I'll trade you some of your coins for my public ones...
06:49:42dsnrk:I'll be alright thank you.
06:50:08gmaxwell:dsnrk: or use andy's coinjoin to get some public coins. :)
06:54:45gmaxwell:* gmaxwell is black and blue from facepalming at https://bitcointalk.org/index.php?topic=645852.msg7226698#msg7226698
06:57:01gmaxwell:Vitalik_: Are you going to go reality check that response?
06:57:50dsnrk: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:18Luke-Jr:yay gmaxwell is back
07:02:01wumpus:he does have a knack for finding the most cringe-worthy posts :)
07:03:56petertodd:gmaxwell: I thought the goal of ethereum was to get really high and contemplate the universe?
07:04:15gmaxwell:dsnrk: doing
07:05:44gmaxwell:dsnrk: done.
07:07:22dsnrk:"Wallet Recovery Mnemonic" "Please Write Down the Following:"
07:07:30dsnrk:then a blank space and a continue button.
07:09:09Luke-Jr:dsnrk: sounds easy to remember!
07:09:21dsnrk:not that it's a mnemonic at all. it's just the users password XOR their wallet ID.
07:13:39dsnrk: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:49dsnrk:"send payment" is grayed out and there's no reason why. no logged messages.
07:15:28gmaxwell:a confirmation requirement?
07:16:06dsnrk:output has 3 confirmations (nice run of three blocks in two minutes) and it's not giving me an error saying so.
07:22:09dsnrk:lots of bullshit going on in that wallet.
07:22:44dsnrk:"public note: This message will be permanently embedded in the blockchain. Anyone can read it." yep. no.
07:25:05dsnrk:no wonder people come on #bitcoin thinking that transactions can have messages.
07:25:27sipa:people have been thinking that for ages
07:26:09dsnrk:I'm betting that line has been there for ages too.
07:26:49gmaxwell:they've never argued it when pointing it out.
07:26:51dsnrk:blockchain.info used to encode messages as addresses for a while until someone (gmaxwell?) told piuk he was being an idiot.
07:29:45gmaxwell:sgornick is still persisting on reddit in arguing that mining pools cannot engage in doublespending attacks.
07:31:52petertodd:gmaxwell: lol, where is this?
07:32:37gmaxwell:also http://www.reddit.com/r/Bitcoin/comments/27m6vk/its_51_day_again/ci2t3y1
07:32:44gmaxwell:he's posting all over reddit, and being upvoted...
07:33:42petertodd: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:45dsnrk:what's the bit about the two block fork?
07:34:03sipa:can we require that attacker blocks get an 'evil' bit?
07:34:26petertodd:sipa: they already do that; it's called having 'ghash.io' in the coinbase...
07:34:29gmaxwell:where the @#$@ is that 'quote' from?
07:34:43dsnrk: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:44Luke-Jr:petertodd: ghash.io's hidden blocks don't have that right now
07:35:03petertodd:Luke-Jr: heh, I was just about to say...
07:35:56dsnrk:has anybody tried to find ghash.io's edge routers? that could be a fun rainy-day activity.
07:36:17petertodd: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:46gmaxwell:oh I see, it makes sense in context.
07:39:30dsnrk:does anybody expect that ghash.io's hidden pool is just a portion of their main one, or a totally isolated pool?
07:40:06dsnrk: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:30dsnrk:that is, if they always see the "unknown" blocks significantly faster than other pools it's very likely to be them.
07:43:09Luke-Jr:petertodd: I doubt it's *that* complexly implemented.
07:43:21Luke-Jr:dsnrk: it's likely cex.io miners using other pools
07:44:37dsnrk:oh sweet, shared coin works now.
07:46:57dsnrk:petertodd: gmaxwell: I was right. Shared Coin *does not* enforce output sizes.
07:48:00dsnrk:if you are interesting in seeing the transactions please private message me.
07:51:45petertodd:interesting, yeah, looks like the behavior changed slightly...
07:51:55dsnrk:actually looking at these basted transactions it's super easy to see the path through.
07:53:24petertodd:https://blockchain.info/tx/f68818249eac95717f414cfa6a6414787ea667a0849c84aa38a750f3103ce8ac <- 1BDTzp7fjoZfK7u6AyEGoQXhyKuLmtz5j7 0.01233445 is the output I selected
07:54:22Luke-Jr:who invented this braindead git-subtree nonsense anyway? -.-
07:59:07dsnrk:just to point out, given only the output of my "coinjoin" petertodd was able to find the input instantly.
08:15:27petertodd:yup, took all of 30 seconds. it used to do proper output matching, but mysteriously doesn't any more
08:19:03dsnrk:> expensive
08:19:09dsnrk:yeah I spent like $5 just then.
08:19:33dsnrk:also lost 0.6BTC because the shared send failed.
08:21:43dsnrk:there it is, belay that last bit. never made it to my node but it's shown on blockchain.info
08:22:18petertodd:yeah, there is a recovery mechanism there
08:23:00dsnrk:I tried that but my browser hung.
08:30:29dsnrk: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:05petertodd:lol, reposted - I'm gonna have to call my next service Coinbase Bit Block Chain Thing.
08:38:01dsnrk:you need lessons in writing reddit tiles. it needs more hyperbole. SHARED COIN IS REACHING 51% GET OUT OF THE POOL
08:38:20dsnrk:(the title is fine don't change it)
08:40:29petertodd: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:39gmaxwell:"DoubleSpend-lite coin based bit-chain pool announces script reorganization. New software version "Genesis" to be written in Node."
08:41:38petertodd:gmaxwell: is there proof it works?
08:41:49sipa:will be it webscale?
08:41:51dsnrk:gmaxwell: I'm not buying it without Antonopoulos
09:00:44gmaxwell:nice, some moron is threatning to DOS attack bitcointalk because I said something negative about darkcoin.
09:00:50gmaxwell:(he thinks bitcointalk is my site)
09:04:23BlueMatt:anyone want a user@bitcoin.ninja email forward or a user.bitcoin.ninja subdomain? =D
09:04:35BlueMatt:jgarzik: ^
09:05:11Emcy:is that domain real
09:05:54gmaxwell:BlueMatt: Yep.
09:05:58Emcy:registrars printing money
09:06:02gmaxwell:ninja is a TLD?
09:06:12BlueMatt:it is, some tld company registering things like it
09:06:14Luke-Jr:BlueMatt: haha, so you got it. I think my registrar screwed up on my pre-regs :p
09:06:38gmaxwell:what registrar would y'all suggest for that tld?
09:06:50BlueMatt:no, the registrar had, for some reason, been holding it as a reserved word, but I emailed them and they released it
09:06:55dsnrk:bitcoin.horse is still free.
09:07:11BlueMatt:anyway, first bed, tomorrow setup email and aliases for everyone :)
09:07:38gmaxwell:dsnrk: Best of all the animals.
09:10:11dsnrk:gmaxwell: there's one for Luke-Jr if he was russian too
09:10:50dsnrk:.католик is "catholic"
09:17:42gmaxwell:I just registered codec.ninja
09:19:10Luke-Jr:gmaxwell: very you
09:21:10gmaxwell:crypto.ninja was taken. :(
12:03:28jgarzik:BlueMatt, me me me
12:14:00sipa:BlueMatt: me two!
12:31:15wumpus:crypto.horse is still free!
12:32:00dsnrk:get on it!
12:33:00Emcy:how many dictionary words did they make domains now
12:35:04dsnrk: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:06Emcy:it should be illegal
12:41:43mtgox555:where do i find a list?
12:43:12dsnrk:of TLD?
12:43:52dsnrk:I have one somewhere, I'll have to see if I can find it.
12:44:03mtgox555:a list of the new tlds yea :)
12:45:01dsnrk: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:02mtgox555:good enough for me atm :)
13:16:54mtgox555:bitcoin.foundation is bought
13:43:42jgarzik:gmaxwell, what is the state of your moxie toy? I am tempted to make a working demo out of it
13:51:41jgarzik:and related wizards territory,
13:52:58jgarzik:Has anyone designed a secure, difficult to DoS, pay-to-use comm network? :)
14:15:07jgarzik:sounds like I could re-create the moxie toy easily enough
14:15:08hearn:jgarzik: yeah
14:15:16hearn:jgarzik: the 3GPP ;)
14:32:02hearn:jgarzik: what you're really asking is, has anyone created a decentralised network with anonymous participants that is difficult to DoS?
14:32:07hearn:and i suspect the answer is no
14:34:53jgarzik:Browsing around, I see a sim in https://github.com/atgreen/moxiedev/tree/master/src/sim/moxie
14:35:01jgarzik:and another proto-sim in the qemu port
15:48:53millsdmb:millsdmb has left #bitcoin-wizards
15:54:54mircea_popescu:mircea_popescu has left #bitcoin-wizards
16:06:03mircea_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:03gribble:The operation succeeded.
16:06:39mircea_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:39gribble:The operation succeeded.
16:07:01mircea_popescu:mircea_popescu has left #bitcoin-wizards
16:28:05bob131313:bob131313 has left #bitcoin-wizards
17:04:30adam3us: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:46adam3us:hearn: http://cypherspace.org/adam/pubs/traffic.pdf
17:05:12adam3us:hearn: we concur with your conclusion and propose a triangle.
17:08:13phantomcircuit:adam3us, im guessing the basic answer is no
17:28:56andrew___:andrew___ is now known as justanotheruser
17:29:16andrew__2:andrew__2 is now known as justanotheruser
18:31:31stqism:stqism is now known as NikolaiToryzin
18:34:56andytoshi: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:15andytoshi: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:16:28NikolaiToryzin:NikolaiToryzin is now known as stqism
19:18:12maaku:andytoshi: sounds like zerocash
19:23:53tekto786:tekto786 has left #bitcoin-wizards
19:54:36andytoshi:maaku: hmm. but zerocash involves a crs yes? i guess it is necessary :(
20:33:17wilhelm.freenode.net:Server Terminating. tomaw
20:33:18irc.freenode.net:Disconnected from irc.freenode.net (Connection reset by peer)
20:34:35hobana.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:35hobana.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:35hobana.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:35hobana.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:35hobana.freenode.net:Users on #bitcoin-wizards: mmozeiko zibbo Dyaheon- Anduck crescendo
20:53:56maaku_:andytoshi: you are into non-published territory if you are looking for a non-CRS, practical SNARK
20:54:30maaku_:although rumors are there are some things in the works ... but 'practical' may be a relative judgement (proofs kilobytes in size)
20:57:23andytoshi: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:42justanotheruser:Would it be possible to increase block size with a softfork?
21:06:05_cajg:_cajg is now known as cajg
21:08:11andytoshi:no. nodes that didn't changeover would be unaware of the large blocks' content no matter how you orchestrated them
21:11:26justanotheruser: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:33justanotheruser:I guess that's basically sidechains though.
21:46:21maaku_:maaku_ is now known as maaku
21:47:29maaku:justanotheruser: precisely
21:53:05dsnrk:petertodd: weird. I was expecting a response from blockchain.info, they are very active on reddit.
21:56:33justanotheruser:dsnrk: Have they ever been called out for doing something wrong like this on reddit?
21:58:59dsnrk: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:47justanotheruser:dsnrk: Yeah, this isn't as big of a mess-up as their bad RNG I guess
22:00:00dsnrk:http://reddit.com/user/blockchainwallet < wow they have a lot more downtime than I realised
22:02:51dsnrk: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:27gmaxwell:dsnrk: pftt, what, next you're going to suggest people promoting malware should make people whole.
22:04:40helo:only some... like the ones hosting it too
22:09:48dsnrk:wut https://twitter.com/aantonop/status/476085699964198912
22:10:41gmaxwell:Will he ever say something about technology which isn't incorrect? :(
22:35:16coke0: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:20gmaxwell: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:53coke0:you obliviously have to refer to the nonce in your transaction
22:40:11coke0:but apart from that, how is that more complicated
22:40:26coke0:basically (nonce, address) <=> txout
22:42:25justanotheruser:if you use a nonce is there a risk of collisions?
23:57:37dsnrk:any theories on ghash.io having dropped their block size to the default again?
23:57:52dsnrk:they're back to making super-small blocks now.