00:47:51starsoccer:starsoccer is now known as Guest18637
01:03:20Guest18637:Guest18637 is now known as starsoccer
01:03:49starsoccer:starsoccer is now known as Guest45653
01:04:16Guest45653:Guest45653 is now known as starsoccer
01:40:05Sub|afk:Sub|afk is now known as SubCreative
02:03:53belcher_:belcher_ is now known as belcher
02:57:02tdlfbx:Could a "work" algorithm be devised that computes something internally useful to the bitcoin network? For instance, network topology optimization? Can anyone suggest something "internally useful" that a brute-force computation could be applied to?
02:57:49phantomcircuit:tdlfbx, some sort of evidence of expended effort for example
02:57:57phantomcircuit:* phantomcircuit flees the scene of the crime
02:58:08tdlfbx:Hahaaa
02:58:51tdlfbx:This is IRC. The arXiv is over there ----> http://arxiv.org/
03:48:08op_null:kanzure: I think covenants also have a really nasty interface problem, no matter how you go about it users *can not* be shown coins they aren't certain they can be able to spend, so you know somebody will write software that does.. and trouble lies that way.
03:51:30op_null:kanzure: I mean, there's no way you should *ever* be showing unauthenticated namecoin data to users right? letting them put in a name and it comes back with an unauthenticated address is just madness. only that happens in real wallet software now :C
03:53:48kanzure:how will clients use the data if they ever get see it or validate it?
03:54:04kanzure:*never get to see it
03:54:24op_null:gmaxwell: thought of a nice one for the CoinCovenants thread too. every output must contain the same restriction. it is that the output script can be either spent by a standard pubkeyhash, OR make a hash collision of a decaying amount. the security gets weaker the more you spend the output.
03:55:51op_null:128 bit collision, then the next spend a 127 bit collision, got to weigh up the costs of spending it again and possibly losing it as a result. hot potato outputs.
03:56:35gmaxwell:Well all this does have an answer of "don't do something stupid" (like don't ever show coins assigned to a script you didn't write). Maybe people will write such stupid software, maybe they won't.
03:56:35BurritoBazooka:BurritoBazooka is now known as Burrito
03:56:57gmaxwell:The only thing that have suffered from e.g. 1 of 2 and I can steal the coins back were ... well.. things I wouldn't consider counting.
03:57:02op_null:kanzure: that's sort of the thing. if you just resolve random names from namecoin, how do you know if they are at all legit? could be squatted, fake, just old. type in "gmaxwell" and you get the bitcoineater address and a note telling you not to use software so stupid.
03:57:25op_null:it's not an easy problem to solve.
03:59:09op_null:gmaxwell: thing is, I would have said that until I saw the wallet with blind namecoin address resolution. I think people just write whatever software they think people want, rather than what is safe.
07:00:53lclc_bnc:lclc_bnc is now known as lclc
07:01:44lclc:lclc is now known as lclc_bnc
08:32:19leathan:leathan has left #bitcoin-wizards
09:05:16tepper.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:16tepper.freenode.net:Users on #bitcoin-wizards: andy-logbot davejh69__ Shiftos user7779_ damethos rusty coiner nullbyte coinheavy vmatekole Luke-Jr gues__ Starduster_ wallet42 cfields digitalmagus8 Dr-G TwoKoolFourSkewl adlai Graftec austinhill1 samson_ TheSeven Burrito hashtagg_ tacotime ryanxcharles bitbumper starsoccer c0rw1n prodatalab tdlfbx OneFixt stonecoldpat gmaxwell hashtagg mkarrer_ davejh69_ Soze49 Flyer9933 SubCreative zwischenzug Greed [\\\] pigeons ahmed_ copumpkin gsdgdfs
09:05:16tepper.freenode.net:Users on #bitcoin-wizards: gribble isis nuke1989 dgenr8 jgarzik ebfull tromp luny super3 andytoshi lechuga_ waxwing bobke btcdrak coutts CryptOprah artifexd Muis hguux_ michagogo kumavis nickler gavinandresen Hunger- v3Rve NikolaiToryzin PRab warptangent Fistful_of_Coins phantomcircuit wumpus heath koshii HM2 paperbot kefkius zibbo maaku epscy lnovy EasyAt jaekwon_ Cory LarsLarsen Guest38445 coryfields iddo otoburb_ kinlo azariah4_ Guest6066 HaltingState null_radix fenn
09:05:16tepper.freenode.net:Users on #bitcoin-wizards: shesek bosma iambernie mr_burdell nsh_ yoleaux btc__ Graet Logicwax pi07r Meeh PaulCape_ DoctorBTC nsh mappum K1773R nanotube dansmith_btc kanzure spinza arowser1 Anduck Nightwolf hollandais berndj lclc_bnc s1w Eliel_ LaptopZZ sneak harrigan JonTitor sl01 Grishnakh sipa Alanius jbenet MRL-Relay fluffypony asoltys smooth amiller danneu catcow TD-Linux ryan-c roasbeef harrow warren BrainOverfl0w midnightmagic phedny huseby Iriez Keefe helo
09:05:16tepper.freenode.net:Users on #bitcoin-wizards: jaromil BigBitz espes [d__d] so crescendo petertodd throughnothing Apocalyptic optimator_ Taek mmozeiko comboy poggy Krellan tromp_ bbrittain Dyaheon wizkid057 burcin @ChanServ BananaLotus livegnik gwillen AdrianG gazab a5m0 BlueMatt
12:22:52wallet421:wallet421 is now known as wallet42
12:32:36lclc_bnc:lclc_bnc is now known as lclc
12:57:07lclc:lclc is now known as lclc_bnc
13:07:20lclc_bnc:lclc_bnc is now known as lclc
13:54:22wallet42:wallet42 is now known as Guest66937
13:54:22wallet421:wallet421 is now known as wallet42
14:54:21samson2:samson2 is now known as samson_
15:40:27Guyver2:Guyver2 has left #bitcoin-wizards
16:21:05Dizzle__:Dizzle__ is now known as Dizzle
16:54:12zooko`:zooko` is now known as zooko
17:38:31lclc:lclc is now known as lclc_bnc
18:29:35bramc:Good morning everybody
18:29:53bramc:A friend of mine asked if I know Jed. It's like, yeah, I know Jed, but he isn't responding to my mail.
18:52:32bramc:Now I'm reading how siphash works internally. The level of yak shaving here is truly astounding.
19:05:42nsh_:i bet i could shave 100 yaks
19:15:33lechuga_:no man can shave 100 yaks
19:16:17sipa:bramc: how so? i never really heard about siphash
19:18:40bramc:sipa, It's used in cuckoo, and I'm trying to integrate cuckoo and nonoutsourceability, and this requires creating a data dependence...
19:20:36bramc:This discussion has mostly moved to ##altcoin-dev because it was getting far enough afield to get on peoples's nerves, and there are some of the same people in that channel too.
19:35:27Pan0ram1x:Pan0ram1x is now known as Guest4661
20:34:40bramc:I'm waffling on whether I think it's better to put timelocks in transactions or utxos. It seems cleaner for them to be in transactions, but it does less polluting of the block chain and hence has more anonymity if they're in transactions
20:35:02bramc:because in many protocols the timelocks are the exceptional case and never get used.
20:44:46Eliel_:having timelocks in utxos is more secure as with a timelocked transaction there tends to be some party who can cancel it.
20:45:05Eliel_:usually the sender
20:47:17bramc:Usually the whole point of a timelocked transaction is that you might want to cancel it
20:50:25Eliel_:I think it's probably the best to support both.
20:51:08Eliel_:there are use cases where timelock in the utxo is preferable.
21:00:53pigeons:i guess an important consideration with the timelock stuff is unintended effects from reorgs
21:19:42gmaxwell:bramc: The use cases are only partially overlapping. Both have uses. There is a general mechenism that effectively unifies both, but to be honest. .. not really excited about designing your altcoin for you; esp after you've already expressed a desire to keep parts of it secret.
21:22:04gmaxwell:But whatever, might as well since I've described it before. I call the general discussion delegation. Bitcoin's code seperator was supposted to accomplish delegation but it was bugged. The notion is that I should be able to construct a signature which provides a new scriptPubKey and a signature of it with the old scriptPubkey. Basically saying "I sign over that old scriptPubKey to whatever t
21:22:10gmaxwell:his new one says.
21:22:48gmaxwell:By doing this you can leave timelocks out of the transaction, and then if a spending transaction wants a timelock, it delegates to a new scriptPubkey in the signature that has one, then satisifies that key too.
21:23:54gmaxwell:Now, even with delegation there can be strong advantages to having all of the validation state in a transaction explicit in its serialization; because that allows the validity of a transaction to be a pure function... which is useful for layering, and simplifies things like mempools.
21:24:15gmaxwell:(or making code that works with transactions externally to the blockchain)
21:25:44gmaxwell:Efficient delegation is one of the top level really-wants on my script 2.0 design list. (along with branch elision)
21:26:38Taek:has there been a ton of discussion on a script 2.0?
21:26:40hearn:gmaxwell: afaik OP_CODESEPARATOR was an artifact of the first implementation where scripts were concatenated
21:26:48hearn:gmaxwell: not intended to support any particular feature
21:27:22hearn:it can be seen in the very first version of the code, i think
21:29:40lechuga_:// In case concatenating two scripts ends up with two codeseparators,
21:29:42lechuga_:// or an extra one at the end, this prevents all those possible incompatibilities.
21:29:58gmaxwell:hearn: what lechuga_ said. :)
21:30:16gmaxwell:It really was intended to allow cascading scripts too, as far as I can tell.
21:30:45gmaxwell:(obviously I'm aware of how it was used prior to the pub/sig seperation, too)
22:13:54petertodd:hearn: even now you can use OP_CODESEPARATOR to implement efficient payword schemes
22:14:50petertodd:hearn: early on you could have used it to do some really useful after-the-fact signing delegation by wrapping a IF ENDIF around the CODESEPARATOR introduced into the middle of the scriptSig/scriptPubKey pair - shame we got rid of that without thinking the design through
22:15:17petertodd:hearn: e.g. "create a signature that delegates signing authority to another pubkey"
22:15:36petertodd:probably all 100% accidental... but a nice accident
22:16:17hearn:it's probably for the best. i can imagine such things being a surprise for implementations not expecting them. a script 2.0 effort that incorporates lots of neat features but still lets script 1.0 work would be nice to have, one day
22:17:04petertodd:satoshi belived in 1 implementation, and by putting CODESEPARATOR into the scriptSig/scriptPubKey concatenation you had to opt-in to making that feature possible to use in any particular scriptPubKey
22:17:43petertodd:w/o the mis-matched ENDIF you can't pull off that trick because you can't turn CODESEPARATOR off
22:19:07petertodd:to be explicit: scriptPubKey: ENDIF CHECKSIG, then the normal case is scriptSig: 1 IF
22:19:51petertodd:they concatenate to 1 IF ENDIF CHECKSIG, CODESEPARATOR is evaluated, and the signature is evaluated on the script ENDIF CHECKSIG
22:20:49petertodd:to delegate signing authority after the fact sign a signature on the script 0 IF ENDIF CHECKSIG
22:21:10petertodd:(remember that CODESEPARATORS are removed by SignatureHash())
22:22:02petertodd:oops, I mean: CHECKSIGVERIFY 0 IF ENDIF CHECKSIG
22:22:56petertodd:anyway, to finally spend it, create another signature with pubkey2 signing the script CHECKSIGVERIFY 0 IF ENDIF CHECKSIG again, and finally spend it with the scriptSig: CODESEPARATOR 0 IF
22:24:45petertodd:after concatenation the script: CODESEPARATOR 0 IF CODESEPARATOR ENDIF CHECKSIG is evaluated, the inner signature satisfies, and the outer signature is satisfied only if the scriptPubKey was essentially changed after the fact to also require the inner, second, pubkey2 to be satisfied
22:26:19petertodd:a nice use-case would, forinstance, have been to have a signing robot be able to create signatures offline for a given txout with SIGHASH_SINGLE such that you had a spending limit enforced, and exactly who was then allowed to spend the funds - say a department of a company - could be picked after the fact without re-spending the txout
22:33:34petertodd:gmaxwell: re: script validation state, a good model would be to have the tx input to EvalScript() essentially be a CMerkleTx, and the prevout scriptPubKey be the prevout CTxOut (*maybe* the prevout tx itself... bit dubious there...)
23:03:56bramc:gmaxwell, Not entirely sure what you're describing, but giving utxos some degree of control over the utxos of their targets is very powerful, and makes a number of protocols much simpler. It may even be necessary for some protocols if you're stuck with utxos being referenced by transaction + signature
23:10:58bramc:gmaxwell, You'll be happy to hear that I'm probably going to want to discuss the interesting part of my 'secret' idea with everybody. I'm pretty sure you're going to shit on it though.
23:11:30bramc:I'm busy working through a bunch of other stuff first though. Right now still trying to work through nonoutsourcable proofs of work
23:12:01helo:a proctored exam with only pencil and paper might work
23:13:34bramc:As far as smart transaction support, mechanisms for supporting them are very interesting but I continue to be very skeptical than anything beyond some very basic functionality is useful/needed, especially given how much can be done with even simple primitives.