| 00:21:17 | earlz: | Luke-Jr: is your recommendation forward-only blockchain scans? |
| 00:21:27 | earlz: | I can't remember who recommended that for almost everything |
| 00:22:14 | sipa: | everyone? :p |
| 01:05:33 | bosma: | bosma is now known as basma |
| 01:06:02 | basma: | basma is now known as basma99 |
| 01:10:56 | basma99: | basma99 is now known as bosma |
| 01:32:19 | jgarzik_: | jgarzik_ is now known as jgarzik |
| 02:41:03 | kanzure: | what's the right term for obfuscated/indistinguishable software in "the interclouds"? |
| 02:52:37 | freewil: | obfuscated from who/what? |
| 02:56:42 | maaku: | encrypted computation? |
| 03:07:29 | nuke_: | nuke_ is now known as nuke1989 |
| 04:42:09 | Taek: | maaku: homomorphic encryption? |
| 05:07:32 | maaku: | the word 'homomorphic' scares people it seems |
| 05:26:34 | fluffypony: | kanzure: SAAS? |
| 05:26:55 | fanquake_: | fanquake_ is now known as fanquake |
| 05:53:00 | jcorgan: | maaku: would that be called homophorbia? |
| 07:08:00 | gmaxwell: | I just came up with a space savings / cpu improvement for the pairing crypto provable hash scheme. Refresh: To have p2sh-like hash outputs where you know they are hashes, in some pairing compatible group you set PubkeyHash = h(script)*G and provide proof = h(script)*to_point(H(PubkeyHash)); to verify one checks pairing(proof,g) == pairing(o_point(H(PubkeyHash)),PubKeyHash) |
| 07:08:53 | gmaxwell: | This works because the verifier is the BLS signature scheme verifier, it's checking that you know the discrete log of PubkeyHash. Unlikely ECDSA though there is no sidechannel in the signature scheme that could be used to encode or leak additional data. |
| 07:09:58 | Luke-Jr: | does that require it be a hash *of a key specifically*? |
| 07:10:23 | gmaxwell: | it's a hash of a redeemscript. |
| 07:10:52 | Luke-Jr: | hm |
| 07:11:09 | gmaxwell: | The scheme above requires 64 bytes for each output-- 32 for the pubkeyhash, 32 for the proof. The more costly part is the two pairing operations to verify it. |
| 07:14:33 | gmaxwell: | But the verification can be batched, pairing(sum(PubkeyHash_n * random_n), g) = prod(pairing(to_point(H(PubkeyHash_n)),PubKeyHash_n)^random_n) ... which gets it down to ~1 pairing per output plus some point multiply which is cheap compared to the pairing. |
| 07:16:09 | gmaxwell: | Alternatively, the proofs can be aggregated, so you only need one proof for any number of outputs (e.g. down to 32 bytes, basically no size overhead) but the OWAS style aggregation seems to break the batch verification, and I'm still trying to figure that out. |
| 07:18:42 | gmaxwell: | In any case, I think it's likely I'm being stupid and can get both the aggregation and batching working and get it down to 32bytes per output for the 'hash', plus 32 bytes for a whole transaction (and eventually whole block). Plus only one pairing operation per output + some overhead). |
| 07:19:48 | gmaxwell: | though thats still probably only on the order of 1000-2000 outputs per second verifyable on a current generation core. Though I suppose nothing great is lost if the provable hashness of your outputs isn't absolutely verified by everyone. |
| 08:37:53 | fanquake_: | fanquake_ is now known as fanquake |
| 09:05:17 | hobana.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:17 | hobana.freenode.net: | Users on #bitcoin-wizards: andy-logbot aburan28 ielo soundx vdo xabbix Starduster thrasher` Mably jcluck lclc cbeams orik michagogo waxwing kobud Graftec coiner alawson hollandais TheSeven otoburb hguux__ ahmed_ d1ggy p15 Dr-G2 PRab jbenet Oizopower use_zfs_yo platinuum mappum mortale narwh4l yrashk luny devrandom Cory ebfull hashtag_ jgarzik zooko` justanotheruser Emcy nsh Luke-Jr paveljanik kyletorpey iddo c0rw1n GAit Guest56212 Tjopper shesek adlai dgenr8 delll bosma |
| 09:05:17 | hobana.freenode.net: | Users on #bitcoin-wizards: tromp_ copumpkin HaltingState amincd Meeh nuke1989 SubCreative binaryatrocity antgreen wizkid057 so HM2 berndj wiz espes__ Krellan brand0 kinlo jaekwon epscy_ phedny [d__d] stonecoldpat TD-Linux spinza_ warptangent maaku andytoshi roasbeef OneFixt gwillen grandmaster2 dansmith_btc PaulCapestany CodeShark isis ryanxcharles BrainOverfl0w sdaftuar_ burcin_ BlueMatt wumpus Dyaheon- MRL-Relay nickler Alanius starsoccer harrow Iriez Logicwax huseby |
| 09:05:18 | hobana.freenode.net: | Users on #bitcoin-wizards: a5m0 phantomcircuit gnusha sl01 yoleaux catcow brad_ earlz davout midnightmagic btc___ PFate nick1234abcd__ Hunger- gmaxwell Anduck bobke_ comboy_ null_radix AlexeiTodorov poggy dasource tromp hashtag LarsLarsen amiller artifexd deego fluffypony cryptowest sipa rw_8197 qwopqwop dardasaba veox warren gribble K1773R CryptOprah Muis kumavis coryfields optimator weex jcorgan Fistful_of_Coins EasyAt jaromil btcdrak sneak lnovy d9b4bef9 crescendo |
| 09:05:18 | hobana.freenode.net: | Users on #bitcoin-wizards: Taek azariah eric livegnik asoltys_ pigeons catlasshrugged kanzure heath JonTitor fenn Adrian_G throughnothing helo Graet Apocalyptic lechuga_ ajweiss ryan-c Xzibit17 @ChanServ smooth DoctorBTC BananaLotus tripleslash petertodd bbrittain Keefe s1w nanotube morcos Eliel_ cfields forrestv mr_burdell |
| 13:00:03 | op_mul: | gmaxwell: the aim is to prevent people stuffing data into P2SH hashes, right? |
| 13:00:52 | op_mul: | I can see people trying to get around that by making scripts which just encode the data and reveal it when spent, making even more spam load. |
| 13:03:12 | op_mul: | like. make the output script push 0x6969696969696969 onto the stack, then OP_DROP, then a normal P2PKH, or whatever. |
| 13:04:02 | wumpus: | op_mul: but that doesn't end up in the UTXO set, and you have to spend the output to reveal the script |
| 13:05:07 | op_mul: | oh, very good. |
| 13:05:51 | op_mul: | yep. alright. I like it now. |
| 14:05:12 | andytoshi: | gmaxwell: as you probably know, you can get a big speed improvement (at cost of adding an extra 32-bit value and two curvepoints :/) by replacing the pairing with a NIZK of simultaneous discrete logs DL_g(PubkeyHash) == DL_{to_point(H(PubkeyHash))}}(proof) |
| 14:06:13 | andytoshi: | these NIZKs are essentially schnorr signatures ... can you batch-verify those? |
| 14:07:23 | andytoshi: | s/32-bit/32-byte/ |
| 14:09:07 | andytoshi: | ah, i'm pretty sure you cannot because there is no way to combine the hashes in the schnorr sigs in an algebraically useful way |
| 14:54:02 | sdaftuar_: | sdaftuar_ is now known as sdaftuar |
| 15:04:37 | gmaxwell: | andytoshi: I tried other approaches like that before and found they had sidechannels in the proofs. |
| 15:05:51 | gmaxwell: | op_mul: reveal it in the spend is fine; the point there is that one can forget signatures going forward. the goal is so that the system isn't demanding you store long term any data that isn't a hash. |
| 15:06:43 | andytoshi: | gmaxwell: oh, oops, you're right, any fiat-shamir style proof will (and idk any non-fs efficient ones) |
| 15:11:42 | andytoshi: | actually i'm unsure about "any", in my case i need to use the algebraic structure of the NIZK a bit so maybe there is not a general way |
| 15:30:58 | hearn_: | hearn_ is now known as Guest47026 |
| 16:08:02 | Pan0ram1x: | Pan0ram1x is now known as Guest72520 |
| 16:17:48 | jcluck: | jcluck is now known as cluckj |
| 17:35:29 | starsoccer: | starsoccer is now known as Guest40690 |
| 17:57:34 | hearn_: | hearn_ is now known as Guest47690 |
| 18:22:29 | zooko``: | zooko`` is now known as zooko |
| 18:38:26 | ryan-c|web: | maaku: Are you around? I was wondering where you're at with your UTXO work and how much funding you need to finish it. |
| 20:26:08 | Xzibit17: | Xzibit17 is now known as cryptoLover |
| 20:29:00 | cryptoLover: | cryptoLover is now known as ZieCryptoFckr |
| 20:37:33 | ZieCryptoFckr: | ZieCryptoFckr is now known as Xzibit |
| 20:37:39 | Xzibit: | Xzibit is now known as Xzibit17 |
| 20:40:37 | amincd: | has there been any discussion on not validating OP_RETURN transactions buried under more than a certain number of blocks? That would negate need of archive nodes to store their payload for ever. Would that break Bitcoin? |
| 20:41:08 | sipa: | yes |
| 20:41:23 | sipa: | because the transaction hashes wouldn't match |
| 20:42:03 | amincd: | sipa: but if it's not validated, the transaction hash doesn't have to match |
| 20:42:04 | sipa: | if you don't want the data in the transaction forever, it shouldn't be in the transaction in the first place |
| 20:42:19 | sipa: | send it out of band to the receiver instead, and put a hash of the data in the transaction |
| 20:43:02 | sipa: | which can be done with 0 additional data, using pay-to-contract or sign-to-contract schemes |
| 20:43:44 | sipa: | amincd: well if you mean not validate the transaction at all, you're changing bitcoin's fundamental security properties |
| 20:44:08 | sipa: | it means you need to accept the state of the UTXO set from someone else, without being able to validate it |
| 20:45:06 | amincd: | sipa: right.. there's no way to prove it was an OP_RETURN transaction without being able to match the hash |
| 20:45:40 | sipa: | this doesn't just apply to OP_RETURN |
| 20:46:02 | sipa: | it would be nice to for example be able to *optionally* skip signature download and validation |
| 20:46:42 | sipa: | but that would mean you must be able to omit that signature data without losing the commitment to it |
| 20:48:52 | orik_: | orik_ is now known as orik |
| 20:49:52 | amincd: | sipa: right |
| 21:20:35 | lclc_bnc: | lclc_bnc is now known as lclc |
| 21:23:11 | amincd: | What about having two merkle trees, one for regular Bitcoin transactions, and one for prunable Bitcoin transactions, and their respective roots hash to a 'master merkle root'. The prunable merkle tree is pruned after, say, 100 blocks, with only its root hash stored permanently in the blockchain |
| 21:24:54 | amincd: | The prunable merkle tree would be useful for short term storage of messages, and for time stamping messages |
| 21:26:16 | amincd: | Sort of like a built in Factom |
| 21:33:16 | amincd: | Non-transaction data storage of any kind could then be heavily discouraged in the regular Bitcoin transactions. It would be good if there were a way to prevent permanent storage of non-transaction data, while still allowing non-transaction data to be permanently timestamped. |
| 21:34:04 | Luke-Jr: | amincd: there is |
| 21:34:52 | Luke-Jr: | it's called merged mining |
| 21:37:58 | amincd: | Merged mining requires the cooperation of miners. It's not permissionless in the same sense as encoding information in the Bitcoin blockchain. It's extremely useful for a sidechain architecture, but it's not a panacea. |
| 21:39:11 | Taek: | amincd: I don't understand what problem you are trying to solve |
| 21:40:17 | amincd: | Taek: The problem of permanent storage of non-transaction data. The problem is how to prevent it while still allowing permanent storage of a timestamp of non-transaction data |
| 21:42:01 | amincd: | a 'timestamp' being a hash of the non-transaction data |
| 21:42:55 | Taek: | Couldn't you just hide a hash of the data in a p2sh address? Or do you want it to be prunable? |
| 21:46:39 | Profreid_: | Profreid_ is now known as Profreid |
| 21:47:32 | amincd: | Taek: to me, ideally, everything stored permanently in the blockchain is proven to be a hash before inclusion in the blockchain. So you shouldn't be able to hide a hash in a p2sh address. |
| 21:47:45 | amincd: | as then you'd be able to hide anything |
| 21:47:53 | amincd: | i.e. something that's not a hash |
| 21:48:38 | nsh: | * nsh blinks |
| 21:55:30 | Luke-Jr: | amincd: abusing bitcoin transactions also requires permission from miners (and ethically requires permission from every non-miner too) |
| 21:56:43 | Taek: | Luke-Jr, why is it considered abuse? Data is data, blockchains are for figuring out what order the data is in |
| 21:57:32 | andytoshi: | Taek: bitcoin is a payment processing system; using others' storage and bandwidth for non payment-processing purposes is abuse. this has been covered ad nauseam |
| 21:57:33 | Luke-Jr: | Taek: the Bitcoin blockchain is for ordering of Bitcoin transactions |
| 21:58:41 | ajweiss: | i see no harm in P2CH data storage though, they're just transactions |
| 21:58:54 | Luke-Jr: | ajweiss: no, they're data storage |
| 21:59:19 | Taek: | It's definitely data storage |
| 21:59:24 | ajweiss: | only to people who have stored data in them! |
| 21:59:45 | amincd: | Luke-Jr: if there were a way for all nodes to prune non-transaction data in a block, and leave only a single hash of it in the block, without breaking Bitcoin, then Bitcoin could be much stricter with the transactions that aren't pruned, to prevent the so-called abuse you refer to. With regard to 'permission', technically you're right, a miner has to permit your transaction into a block they generate for it to get into the bl |
| 22:00:17 | helo: | for the data to be in the blockchain meaningfully, it has to be more than just a hash of the data |
| 22:00:33 | ajweiss: | how is it different for someone to send a 0.01 BTC to a fresh address of their own, versus a P2CH address of their own? |
| 22:00:39 | amincd: | 's much easier to do that then to contact a pool and ask them to start merge-mining your chain, and even then it's not very useful unless the pool has significant hash power |
| 22:01:00 | justanotheruser: | amincd: what? How do you know whether something is a hash before inclusion? |
| 22:01:47 | amincd: | justanotheruser: there was a lot of discussion on how to do this when someone encoded links to TOR CP sites in the blockchain |
| 22:02:16 | justanotheruser: | hmm? is it a heuristic? |
| 22:02:20 | amincd: | justanotheruser: yes |
| 22:02:32 | Taek: | Also, amimcd couldn't you rely on out-of-band processes to aggregate data before making a storage transaction? |
| 22:02:54 | Taek: | Then you achieve the only-one-hash goal |
| 22:03:06 | amincd: | Taek: yes, you can, but this doesn't give Bitcoin a way to prevent data encoding |
| 22:08:35 | Dizzle_: | Dizzle_ is now known as Dizzle |
| 22:08:49 | Luke-Jr: | amincd: there IS a way for them to do that. that's EXACTLY what merged mining does. |
| 22:15:46 | amincd: | Luke-Jr: merged mining has a larger barrier to participation. It's still useful for things like sidechains, but for just a small startup or an individual wanting to leverage the Bitcoin consensus process, timestamping data by including a hash of it in the blockchain would be very useful. It'd be nice to have both methods |
| 22:17:03 | andytoshi: | gmaxwell: i took your advice and covered my cracked phone screen in nail polish. the touchscreen inexplicably is much more accurate now, thx! (i know this is OT, but maybe others have the same problem) |
| 22:18:36 | amincd: | andytoshi: that's some valuable information. I can't count how many I've seen with cracked screens |
| 22:18:48 | helo: | * helo has the same problem, appreciated |
| 22:22:44 | justanotheruser: | Luke-Jr: how do you propose a user send merged mining data to a miner without either keeping track of the miners IP or the network allowing free spam |
| 22:43:02 | instagibbs: | I always assumed merge-mined things would be propagated via some other means than bitcoin's p2p network |
| 22:43:40 | instagibbs: | just like data that is hashed/embedded |
| 22:47:49 | gmaxwell: | andytoshi: hopefully you researched it first; I was just relaying second hand advice from Kat. :) |
| 22:49:15 | andytoshi: | gmaxwell: i researched that there were new s3 mini's on amazon.. |
| 22:52:15 | andytoshi: | (i mean, no, i didn't research... but i did take into account that it was second-hand advice when considering how likely it was i'd destroy my phone! and i tested on a small part of the screen first) |
| 23:27:11 | starsocc-: | starsocc- is now known as starsoccer |
| 23:42:42 | rusty: | sipa: was about to send to ml, re: BIP66 check. Prefer a stricter check, < 33 if leading 0, < 32 otherwise. |
| 23:42:51 | rusty: | sipa: creating patch now. |
| 23:43:30 | rusty: | (Sorry, OT) |
| 23:44:26 | sipa: | rusty: i just pointed out that even that is not enough |
| 23:44:52 | rusty: | sipa: OK, will catch up on my mail then :) |
| 23:47:24 | sipa: | also, this probably belongs on #bitcoin-dev |