| 00:43:54 | jgarzik_: | jgarzik_ is now known as jgarzik |
| 01:19:47 | Sangheili_afk: | Sangheili_afk is now known as Sangheili |
| 02:13:42 | BlueMatt_: | BlueMatt_ is now known as BlueMatt |
| 04:15:26 | phantomcircuit: | hmm |
| 04:15:28 | phantomcircuit: | cookies |
| 04:37:55 | andytoshi: | petertodd: can you give us a preview of the OP_RETURN based stealth addresses scheme you hinted at in your latest email? |
| 04:52:58 | petertodd: | andytoshi: writing it up now :) |
| 05:00:29 | jgarzik: | jgarzik is now known as home_jg |
| 05:26:36 | brisque: | coingen.io has forged 67 new altcoins. I'm impressed. |
| 05:32:06 | BlueMatt: | brisque: those are just the non-hidden ones, too |
| 05:32:27 | kyrio: | oh yeah |
| 05:32:37 | kyrio: | there's an option to pay to keep it private |
| 05:33:19 | jcorgan: | BlueMatt: of all the ways to earn BTC with a website, coingen.io is the most subversive :) |
| 05:33:38 | brisque: | BlueMatt: I'm extremely impressed. you've done a good job with it. |
| 05:33:56 | BlueMatt: | heh, anyway...its ot for here |
| 05:47:35 | brisque: | almost on topic, can anybody come up with a reasonable explanation for the behaviour of blockchain.info in regards to it's "peers connected" number? they seem to manage to get up to around 1500 connections before dropping them all and starting again. |
| 05:47:40 | brisque: | graph - http://i.imgur.com/iiJYOjo.png |
| 05:48:43 | brisque: | time timeframe is around 30 minutes before each big drop, so they're churning through a lot of connections. |
| 05:58:27 | justanotheruser1: | justanotheruser1 is now known as justanotheruer |
| 05:58:37 | justanotheruer: | justanotheruer is now known as justanotheruser |
| 06:10:25 | jcorgan: | jcorgan has left #bitcoin-wizards |
| 06:19:24 | phantomcircuit: | brisque, they dont understand what the limits of select() are so their client keeps crashing when they go past those limits |
| 06:19:28 | phantomcircuit: | which i personally find hilarious |
| 06:25:07 | brisque: | surely they'd notice the bi-hourly crashes and return the connection limit to something sane. surely. |
| 06:25:22 | brisque: | 72,000 reconnections a day. |
| 06:26:54 | phantomcircuit: | brisque, surely they have no idea what they're doing and haven't noticed |
| 06:27:10 | phantomcircuit: | hint, it's my thing |
| 06:35:01 | maaku: | maaku is now known as Guest18214 |
| 06:36:05 | brisque: | phantomcircuit: really not sure what the hint means |
| 06:36:29 | phantomcircuit: | brisque, surely they have no idea what they're doing and haven't noticed |
| 06:37:04 | brisque: | ah. |
| 07:49:08 | Graet: | Graet is now known as Guest93508 |
| 07:52:16 | Guest93508: | Guest93508 is now known as Graet |
| 08:09:53 | Sangheili: | Sangheili is now known as Sangheili_afk |
| 09:11:22 | epscylonb: | epscylonb is now known as epscy |
| 09:22:21 | Guest18214: | Guest18214 is now known as maaku |
| 09:22:47 | gmaxwell: | petertodd: P2SH^2 2.0: Take H(script) as a private key in a pairing crypto group. Compute G1*private = pubkey. scriptpubkey contains H(pubkey),sign(H(H(pubkey)||txid)) |
| 09:23:50 | gmaxwell: | er sorry pubkey,sign(H(H(pubkey)||txid)) (because you can't to the pubkey recovery for a pairing short signature) |
| 09:23:55 | gmaxwell: | petertodd: so tada, data storage in txouts completely prevented. Overhead of one group element (e.g. 32 bytes) |
| 09:24:35 | gmaxwell: | Why not ECDSA? because signers choice of K can be used to store data in the blockchain... e.g. pick a well known K, and recievers use it to recover the 'private key' (the data) |
| 09:26:48 | brisque: | I'm interested in what The Pirate Bay is planning to do with Bitcoin. by the sounds of their post it is almost like they intend to be storing identifiers in the blockchain, just as you're trying to prevent. |
| 09:27:14 | maaku: | what would be the point? |
| 09:27:26 | gmaxwell: | because omg bitcoin such VC money WOW |
| 09:27:40 | gmaxwell: | people mistake bitcoin for a jamming free network, constantly. ugh. |
| 09:28:15 | brisque: | have you read the article, gmaxwell? |
| 09:28:25 | brisque: | http://torrentfreak.com/how-the-pirate-bay-plans-to-beat-censorship-for-good-140105/ |
| 09:28:35 | brisque: | “The “domain” registrations will be Bitcoin authenticated, on a first come first served basis. After a year the name will expire unless it’s re-verified.” |
| 09:29:41 | brisque: | “Site owners will be able to register their own names, which will serve as an alias for the curve25519 pub-key that will identify the site,” the Pirate Bay insider notes. |
| 09:36:50 | Emcy: | gmaxwell youve been saying jamming network a lot recently. Brief explanation? |
| 10:20:49 | brisque: | just as a thought, the entire sticking point of having a SPV p2pool is that we can't prove to a SPV client that the inputs are unspent, right? we can prove that they exist at some point, but not that the block the p2pool node creates with it will be valid to the wider network (the inputs were spent elsewhere). |
| 10:34:03 | maaku: | Emcy: jamming-free |
| 10:34:33 | maaku: | meaning it is a reliable mechanism for transmitting messages that can't be forceably censored |
| 10:34:36 | maaku: | (which bitcoin is not) |
| 10:37:28 | gmaxwell: | you can have different kinds of jamming freeness, like all or nothing channels.. If you're a >50% hashpower miner bitcoin is arguably an all or nothing jamming resistant network, but it's not to anyone else. :P |
| 10:53:38 | adam3us: | about XCP PhantomPhreak (one of the authors) seems to have changed from spend to fees to proof of sacrifice which they are calling proof of burn but seems to be the same thing, in reaction to someone pointing out that a miner could take their own fees (and maybe worse by the sound of it) |
| 10:59:44 | nsh_: | nsh_ is now known as nsh |
| 11:08:35 | nsh: | yeah, seems to be a very improvised affair |
| 11:18:05 | gmaxwell: | adam3us: do you have a EC discrete log formulatio nof my above P2SH^2 2.0? |
| 11:18:55 | gmaxwell: | the idea is basically to have a hash function where you can prove that the value in question is a hash and not data stuffed into the same spot. |
| 11:21:23 | adam3us: | gmaxwell: i read it earlier, its a subliminal channel suppression, seems a bit analogous to the wallet with observer protocol that relies on blind schnorr. but i dont think that helps because there is no semi-trusted hw wallet in this picture. |
| 11:22:34 | adam3us: | gmaxwell: one thing that occurred to me is the one-use signature or limited use sig, where the extended address is H(Q,r) so r is precommitted. then you are only allowed to make signatures with r. maybe you could prove something about r? |
| 11:22:42 | gmaxwell: | I thought perhaps one of those protocols for schnorr where there is one allowable nonce per private key? |
| 11:22:47 | gmaxwell: | ha |
| 11:22:52 | gmaxwell: | But I didn't quite know how those work. |
| 11:23:07 | gmaxwell: | ah there is an extended address. hm. |
| 11:23:09 | adam3us: | gmaxwell: yes same thought... thats it above, its just to say that you choose the nonce(s) at time of address generation |
| 11:23:19 | gmaxwell: | oh darn. |
| 11:23:29 | gmaxwell: | yea, I think that wouldn't work for the namecoin application. |
| 11:26:05 | adam3us: | gmaxwell: i dont get the namecoin connection. (subliminal channel free signatures would be independently nice however to stop stuffing junk in the block chain:) btw if its purely hash based there is a small subliminal channel in grinding the hash if there is any mutability of the serialization or value hashed. |
| 11:27:20 | gmaxwell: | sure, but the grinding subliminal channel isn't huge and you can reduce it further by requring grinding normally. :) |
| 11:27:55 | gmaxwell: | adam3us: it's just the stop stuffing junk application, I'd fleshed that out a little more in particular to namecoin, https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks_less |
| 11:28:54 | adam3us: | gmaxwell: yes. curious thought that the wallet with observer can have 0 subliminal channel due to the blinding and yet still end up with a valid normal (ec)schnorr sig. actually i saw Brands argue that it has 1-bit channel left: fail or not fail :) (simulated hw wallet death) |
| 11:30:13 | gmaxwell: | hahaha |
| 12:02:23 | nsh: | * nsh exercises blinking muscles |
| 12:34:52 | Muis__: | Muis__ is now known as Muis |
| 14:30:37 | andytoshi: | gmaxwell: sorry, i'm not following your scheme: how is privkey == H(script) enforced here (or even exists(privkey) enforced)? what is txid and why doesn't it depend on its own hash? |
| 14:35:28 | andytoshi: | my concern is, pubkey,sign(H(H(pubkey)||txid)) gives you all of 'pubkey' as a subliminal channel |
| 17:24:50 | petertodd: | Just signed up for the Financial Cryptography and Data Security 2014 conference. |
| 17:24:57 | petertodd: | Who else is going? |
| 17:26:04 | justanotheruser: | I wish I could take a vacation to Barbados |
| 17:27:57 | petertodd: | justanotheruser: heh |
| 17:28:14 | petertodd: | justanotheruser: kinda eye-opening the overall cost - I'm gonna have to bring a tent :P |
| 17:29:26 | justanotheruser: | petertodd: Is Financial Cryptography conference a fancy way of saying bitcoin conference? |
| 17:29:39 | petertodd: | justanotheruser: yup, btc workshop on one of the days |
| 17:30:26 | petertodd: | justanotheruser: http://fc14.ifca.ai/bitcoin/index.html |
| 17:30:38 | petertodd: | justanotheruser: or more interestingly: http://fc14.ifca.ai/bitcoin/accepted.html |
| 17:31:26 | justanotheruser: | petertodd: what, interesting that RS are there? |
| 17:31:51 | justanotheruser: | Or just S |
| 17:32:09 | petertodd: | justanotheruser: ? |
| 17:32:44 | justanotheruser: | nevermind |
| 17:32:55 | justanotheruser: | Interesting that I don't see any familiar names on that list |
| 17:33:34 | justanotheruser: | Seems like a bunch of PhDs are going to explain bitcoin to the bitcoin devs |
| 17:35:16 | petertodd: | Ha, yeah pretty much from the looks of it, will make for an interesting workshop... |
| 17:35:38 | petertodd: | I think amiller said he was going, so maybe it won't be all people totally removed from the dev community. |
| 17:35:44 | petertodd: | (not that him and I write much code...) |
| 17:50:19 | home_jg: | home_jg is now known as jgarzik |
| 18:11:05 | Emcy: | petertodd sleep on the beach |
| 18:16:33 | Emcy: | did anyone figure out how TPB is planning to use bitcoin for its little thing |
| 18:16:42 | Emcy: | or have you been talking about it and its way over my head |
| 18:17:47 | Emcy: | thye best not be spamming the chain......why dont they use namecoin instead |
| 18:31:42 | maaku: | Emcy: have they stated any details? |
| 18:31:54 | maaku: | all they've done is name-drop bitcoin, as far as I can tell |
| 18:32:53 | maaku: | their plan is, apparantly, "BITCOIN!!" |
| 18:33:23 | Emcy: | sounds about right |
| 18:35:23 | skinnkavaj: | gmaxwell: https://litecointalk.org/index.php?topic=12404 |
| 18:36:24 | maaku: | skinnkavaj: sure, google "geistgeld" |
| 18:36:59 | Emcy: | maaku isnt there a data feild in a TX that cam be used for arbitrary data without really bloatingit |
| 18:37:02 | Emcy: | or somthing like that |
| 18:37:26 | maaku: | Emcy: sure, any OP_RETURN output |
| 18:37:54 | Emcy: | and that was specifically done to give people a place to dump thier crap, if they must? |
| 18:38:03 | maaku: | yes |
| 18:39:27 | Emcy: | wait is that a new feild or something repurposed? If its new isnt that just appeasement |
| 18:39:41 | maaku: | and by putting the hash instead of the data itself (or better, the Merkle root of a structure that can hold lots of data), you can keep the wire size small |
| 18:39:46 | maaku: | i think most people here are ok with committing data by hash to the chain |
| 18:39:51 | maaku: | it's an integral part of many of the protocols we design |
| 18:40:52 | maaku: | its just that putting raw data straight on the chain is wastful, inefficient, and (if it's not provably unspendable) freeloads off of full nodes |
| 18:41:57 | maaku: | it's part of the scripting language not a specific field, and it's always been there |
| 18:42:09 | maaku: | it's just being made standard so it can be relayed in 0.9 |
| 18:42:58 | Emcy: | so TX will get slightly bigger, albeit by something that was already in the protocol but disabled until now? |
| 18:43:40 | maaku: | not disabled, you could always use it |
| 18:43:59 | maaku: | just not relayed by default just like other non-standard scripts |
| 18:44:17 | michagogo|cloud: | maaku: It freeloads off of full nodes even when it's provablt unspendable |
| 18:44:26 | michagogo|cloud: | It's still in the blockchain |
| 18:44:34 | maaku: | michagogo|cloud: no, full node != archival node |
| 18:44:37 | maaku: | it's not in the utxo set |
| 18:44:42 | michagogo|cloud: | It just isn't in the utx- |
| 18:44:43 | michagogo|cloud: | oh |
| 18:45:05 | michagogo|cloud: | Erm, do non-archival full nodes exist atm? |
| 18:45:26 | Emcy: | that archival node thing isnt really gonna happen is it? 6tb helium disks soon |
| 18:45:55 | michagogo|cloud: | Emcy: It;s safe to assume that at some point in the future there will be non-archival full nodes |
| 18:51:01 | Emcy: | michagogo|cloud i hope not out of stict neccesity, but to try and poke people into running a node at all |
| 18:53:50 | Emcy: | hmm asking on TPB irc and no one seems to know shit...... |
| 21:19:59 | maaku: | at some point in the near future |
| 21:20:25 | maaku: | i know both petertodd and myself have separately gotten some money to work on a pruned bitcoind |
| 21:21:04 | maaku: | we just have to good sense to make sure that some other fixes make it in first |
| 21:21:20 | maaku: | like headers-first syncing, and being able to advertise which blocks you hold |
| 21:38:55 | gmaxwell: | the later I think is most of the actual work in pruned bitcoind. |
| 21:39:42 | gmaxwell: | I mean, right now you can just delete the old block files and it works until you run a rpc that would access an old block or a peer tries to sync from you.. it's probably just a few lines of code to make those failures tidy. |
| 21:39:58 | gmaxwell: | and a few lines of code to just automatically delete old files. |
| 21:49:10 | Emcy: | id say it was probably a tradeoff worth making if the alternative is full verifiers dwindling to the hundreds because no one wants to run one |
| 21:49:59 | Emcy: | then again im not sure it will help, because even a pruned node is the same mental distance away from "just works instantly" as a proper node |
| 21:50:05 | gmaxwell: | Emcy: it's just a good thing to have even without that concern. |
| 21:50:30 | gmaxwell: | I now only run one full node at home and one on my laptop, because I just don't have the space for N copies of the blockchain. |
| 21:50:54 | Emcy: | SSDs? |
| 22:31:37 | James: | James is now known as Guest22406 |
| 22:31:40 | Guest22406: | Anyone bought from iMine.org.uk? |
| 22:32:08 | Guest22406: | http://iminecryptos.webs.com seems to be their temp. page |