00:21:17earlz:Luke-Jr: is your recommendation forward-only blockchain scans?
00:21:27earlz:I can't remember who recommended that for almost everything
00:22:14sipa:everyone? :p
01:05:33bosma:bosma is now known as basma
01:06:02basma:basma is now known as basma99
01:10:56basma99:basma99 is now known as bosma
01:32:19jgarzik_:jgarzik_ is now known as jgarzik
02:41:03kanzure:what's the right term for obfuscated/indistinguishable software in "the interclouds"?
02:52:37freewil:obfuscated from who/what?
02:56:42maaku:encrypted computation?
03:07:29nuke_:nuke_ is now known as nuke1989
04:42:09Taek:maaku: homomorphic encryption?
05:07:32maaku:the word 'homomorphic' scares people it seems
05:26:34fluffypony:kanzure: SAAS?
05:26:55fanquake_:fanquake_ is now known as fanquake
05:53:00jcorgan:maaku: would that be called homophorbia?
07:08:00gmaxwell: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:53gmaxwell: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:58Luke-Jr:does that require it be a hash *of a key specifically*?
07:10:23gmaxwell:it's a hash of a redeemscript.
07:11:09gmaxwell: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:33gmaxwell: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:09gmaxwell: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:42gmaxwell: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:48gmaxwell: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:53fanquake_:fanquake_ is now known as fanquake
09:05:17hobana.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:17hobana.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:17hobana.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:18hobana.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:18hobana.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:03op_mul:gmaxwell: the aim is to prevent people stuffing data into P2SH hashes, right?
13:00:52op_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:12op_mul:like. make the output script push 0x6969696969696969 onto the stack, then OP_DROP, then a normal P2PKH, or whatever.
13:04:02wumpus: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:07op_mul:oh, very good.
13:05:51op_mul:yep. alright. I like it now.
14:05:12andytoshi: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:13andytoshi:these NIZKs are essentially schnorr signatures ... can you batch-verify those?
14:09:07andytoshi: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:02sdaftuar_:sdaftuar_ is now known as sdaftuar
15:04:37gmaxwell:andytoshi: I tried other approaches like that before and found they had sidechannels in the proofs.
15:05:51gmaxwell: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:43andytoshi:gmaxwell: oh, oops, you're right, any fiat-shamir style proof will (and idk any non-fs efficient ones)
15:11:42andytoshi: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:58hearn_:hearn_ is now known as Guest47026
16:08:02Pan0ram1x:Pan0ram1x is now known as Guest72520
16:17:48jcluck:jcluck is now known as cluckj
17:35:29starsoccer:starsoccer is now known as Guest40690
17:57:34hearn_:hearn_ is now known as Guest47690
18:22:29zooko``:zooko`` is now known as zooko
18:38:26ryan-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:08Xzibit17:Xzibit17 is now known as cryptoLover
20:29:00cryptoLover:cryptoLover is now known as ZieCryptoFckr
20:37:33ZieCryptoFckr:ZieCryptoFckr is now known as Xzibit
20:37:39Xzibit:Xzibit is now known as Xzibit17
20:40:37amincd: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:23sipa:because the transaction hashes wouldn't match
20:42:03amincd:sipa: but if it's not validated, the transaction hash doesn't have to match
20:42:04sipa:if you don't want the data in the transaction forever, it shouldn't be in the transaction in the first place
20:42:19sipa:send it out of band to the receiver instead, and put a hash of the data in the transaction
20:43:02sipa:which can be done with 0 additional data, using pay-to-contract or sign-to-contract schemes
20:43:44sipa:amincd: well if you mean not validate the transaction at all, you're changing bitcoin's fundamental security properties
20:44:08sipa:it means you need to accept the state of the UTXO set from someone else, without being able to validate it
20:45:06amincd:sipa: right.. there's no way to prove it was an OP_RETURN transaction without being able to match the hash
20:45:40sipa:this doesn't just apply to OP_RETURN
20:46:02sipa:it would be nice to for example be able to *optionally* skip signature download and validation
20:46:42sipa:but that would mean you must be able to omit that signature data without losing the commitment to it
20:48:52orik_:orik_ is now known as orik
20:49:52amincd:sipa: right
21:20:35lclc_bnc:lclc_bnc is now known as lclc
21:23:11amincd: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:54amincd:The prunable merkle tree would be useful for short term storage of messages, and for time stamping messages
21:26:16amincd:Sort of like a built in Factom
21:33:16amincd: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:04Luke-Jr:amincd: there is
21:34:52Luke-Jr:it's called merged mining
21:37:58amincd: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:11Taek:amincd: I don't understand what problem you are trying to solve
21:40:17amincd: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:01amincd:a 'timestamp' being a hash of the non-transaction data
21:42:55Taek:Couldn't you just hide a hash of the data in a p2sh address? Or do you want it to be prunable?
21:46:39Profreid_:Profreid_ is now known as Profreid
21:47:32amincd: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:45amincd:as then you'd be able to hide anything
21:47:53amincd:i.e. something that's not a hash
21:48:38nsh:* nsh blinks
21:55:30Luke-Jr:amincd: abusing bitcoin transactions also requires permission from miners (and ethically requires permission from every non-miner too)
21:56:43Taek:Luke-Jr, why is it considered abuse? Data is data, blockchains are for figuring out what order the data is in
21:57:32andytoshi: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:33Luke-Jr:Taek: the Bitcoin blockchain is for ordering of Bitcoin transactions
21:58:41ajweiss:i see no harm in P2CH data storage though, they're just transactions
21:58:54Luke-Jr:ajweiss: no, they're data storage
21:59:19Taek:It's definitely data storage
21:59:24ajweiss:only to people who have stored data in them!
21:59:45amincd: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:17helo:for the data to be in the blockchain meaningfully, it has to be more than just a hash of the data
22:00:33ajweiss: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:39amincd:'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:00justanotheruser:amincd: what? How do you know whether something is a hash before inclusion?
22:01:47amincd: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:16justanotheruser:hmm? is it a heuristic?
22:02:20amincd:justanotheruser: yes
22:02:32Taek:Also, amimcd couldn't you rely on out-of-band processes to aggregate data before making a storage transaction?
22:02:54Taek:Then you achieve the only-one-hash goal
22:03:06amincd:Taek: yes, you can, but this doesn't give Bitcoin a way to prevent data encoding
22:08:35Dizzle_:Dizzle_ is now known as Dizzle
22:08:49Luke-Jr:amincd: there IS a way for them to do that. that's EXACTLY what merged mining does.
22:15:46amincd: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:03andytoshi: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:36amincd:andytoshi: that's some valuable information. I can't count how many I've seen with cracked screens
22:18:48helo:* helo has the same problem, appreciated
22:22:44justanotheruser: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:02instagibbs:I always assumed merge-mined things would be propagated via some other means than bitcoin's p2p network
22:43:40instagibbs:just like data that is hashed/embedded
22:47:49gmaxwell:andytoshi: hopefully you researched it first; I was just relaying second hand advice from Kat. :)
22:49:15andytoshi:gmaxwell: i researched that there were new s3 mini's on amazon..
22:52:15andytoshi:(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:11starsocc-:starsocc- is now known as starsoccer
23:42:42rusty:sipa: was about to send to ml, re: BIP66 check. Prefer a stricter check, < 33 if leading 0, < 32 otherwise.
23:42:51rusty:sipa: creating patch now.
23:43:30rusty:(Sorry, OT)
23:44:26sipa:rusty: i just pointed out that even that is not enough
23:44:52rusty:sipa: OK, will catch up on my mail then :)
23:47:24sipa:also, this probably belongs on #bitcoin-dev