01:46:52hulkhogan42o:hulkhogan42o is now known as hulkhogan_
01:53:22blazes816:blazes816 is now known as tcrypt
01:55:48gmaxwell:andytoshi: I wonder if it's possible to use this as just a 'devel time dependency' but make it easy to build without it? https://github.com/nrc/libhoare
02:08:27andytoshi:oh gmaxwell, i was just poking at that today
02:08:59andytoshi:the short answer is yes, there are debug_* variants of all the contracts
02:09:24andytoshi:the long answer is yes, rust will let you make any decorator conditional on the compilation mode :)
02:11:41andytoshi:i haven't had an opportuntity to play with it yet, my rust time has been spent on halfsleep (mutation testing) which requires a bunch of work since i need to build a namespace for all the identifiers to get their paths straight
03:09:55bosma:bosma is now known as bosma1957male
03:20:26bosma1957male:bosma1957male is now known as bosma
05:46:04omni:omni is now known as Guest94561
06:58:16CryptOprah_:CryptOprah_ is now known as CryptOprah
06:59:01s1w-:s1w- is now known as s1w
06:59:31s1w:s1w is now known as Guest8638
07:00:12Xzibit17_:Xzibit17_ is now known as Xzibit17
07:04:53[1]LeMiner:[1]LeMiner is now known as LeMiner
07:12:05fluffypony:hktud0: now we have a fluffybunny *and* a fluffypony here, oh dear!
07:18:19mm_0:mm_0 is now known as mm_1
07:46:57davout_:davout_ is now known as davout
08:05:17holmes.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
08:05:17holmes.freenode.net:Users on #bitcoin-wizards: andy-logbot Guyver2 antanst xenog user7779_ fanquake hktud0 crowleyman Adlai forrestv ClipperClap spinza BrainOverfl0w azariah @ChanServ Oizopower epscy gwillen kinlo coryfields_ Muis sl01 michagogo STRML warptangent pigeons espes__ roasbeef_ cursive fluffypony optimator livegnik AdrianG gavinandresen yoleaux nanotube luigi1111 phantomcircuit Logicwax Anduck wizkid057 mariorz TD-Linux BlueMatt midnightmagic otoburb kumavis artifexd yrashk
08:05:17holmes.freenode.net:Users on #bitcoin-wizards: SwedFTP weex starsoccer d9b4bef9 mr_burdell tromp gribble jessepollak ryan-c larraboj jcorgan petertodd Keefe indolering Graet runeks__ cryptowest_ Apocalyptic catlasshrugged_ jaromil comboy manan19 berndj vonzipper harrow GreenIsMyPepper sturles mikolalysenko Sqt null_radix nephyrin eric [ace] merlincorey jonasschnelli ebfull dardasaba wumpus cfields_ nsh Iriez andytoshi sdaftuar Fistful_of_coins gmaxwell amiller throughnothing_ tromp_ smooth
08:05:17holmes.freenode.net:Users on #bitcoin-wizards: platinuum leakypat wiz lnovy afdudley yorick EasyAt_ phedny Zouppen ajweiss poggy Alanius warren Eliel harrigan rustyn lmacken guruvan BananaLotus luny gnusha binaryatrocity [d__d] mkarrer melvster dansmith_btc trstovall prodatalab nickler crescendo heath Hunger- isis helo mappum lmatteis morcos sneak OneFixt waxwing PaulCapestany Taek airbreather Meeh kanzure bliljerk101 Luke-Jr nuke_ bedeho2 sparetire_ veox face arubi_ mm_1 dc17523be3 sipa
08:05:17holmes.freenode.net:Users on #bitcoin-wizards: realcr PRab aakselrod dasource K1773R go1111111 cdecker CodeShark Cory bosma Krellan dgenr8 Guest73375 jtimon dEBRUYNE kyuupichan p15 dignork antgreen pollux-bts justanotheruser kyletorpey stonecoldpat Relos Tiraspol MoALTz sparetire devrandom brand0 hashtag_ Emcy moa rusty delitzer DougieBot5000 Starduster_ Kwelstr GAit unlord_ TheSeven p15x super3 priidu b_lumenkraft Sub|afk davout MRL-Relay a5m0 HM SDCDev huseby Madars jbenet wallet42 Dr-G2
08:05:17holmes.freenode.net:Users on #bitcoin-wizards: CryptOprah iddo_ richardu1 hashtagg NeatBasisW hulkhoga1_ hguux____ gsdgdfs Xzibit17 Guest8638 adams__ catcow koshii LeMiner
09:24:28fanquake1:fanquake1 has left #bitcoin-wizards
10:43:38iddo_:iddo_ is now known as iddo
11:07:34Team:Team is now known as i_am_user
13:19:59Guest8638:Guest8638 is now known as s1w
14:38:16delitzer_:delitzer_ is now known as delitzer
15:01:11StephenM347:gmaxwell: how exactly does the 'Build your own nHashType' proposal "result in a kind of limited covenant" ?
15:13:30Luke-Jr:* Luke-Jr thought we had given up on covenant-avoidence.
15:23:01StephenM347:AFAIK, covenants aren't exactly possible currently, so avoiding them is a given
15:32:04andytoshi:StephenM347: i think gmax is referring to his mechanism for getting the hash of [everything signed] onto the stack
15:32:38andytoshi:if you create a sighash flag which doesn't cover the output script it's spending in any way (including not using the txid) then you can force this to be specific values
15:37:03StephenM347:andytoshi: Right, he mentioned something about OP_MASKED_TRANSACTION_HASH_EQUALS, but my proposal didn't enable that, as far as I can tell.
15:54:57andytoshi:StephenM347: that's already in bitcoin
15:55:13andytoshi:it's just not useful for covenants because every sighash type covers the output itself
15:56:28andytoshi:StephenM347: you can get it by forcing the signature to some dummy value (1, 1) say, then there is one (easily-computable) pubkey which'll give you that signature for any message
15:56:43andytoshi:that pubkey is the "hash"
16:19:09fluffypony_:fluffypony_ is now known as fluffypony
16:55:25omni:omni is now known as Guest54226
17:23:10Starduster_:Starduster_ is now known as Starduster
17:47:59StephenM347:andytoshi: That sounds interesting, do you (or anyone else) know of a link where I could read more about this?
18:11:28delitzer_:delitzer_ is now known as delitzer
18:13:56andytosh1:StephenM347: https://botbot.me/freenode/bitcoin-wizards/2014-09-04/?msg=21030748&page=5 is the only record of it i think
18:14:28andytosh1:i can't believe that was 7 months ago o.O i thought like 2 months
18:19:41gmaxwell:StephenM347: If its possible to completely mask out the input transaction information you can use pubkey recovery to create a coin that can only be spent with by a specific masked transaction.
18:20:30gmaxwell:That doesn't directly create a perpetual covenant; but I would be very unsurprised if it were possible to use a pair of coins with clever masking to get a perpetual one.
18:21:07gmaxwell:The thing I was responding to was a person suggesting the replay vulnerable for for _all_ transactions as a "solution" to malleability; I think that suggestion is really really ill advised.
18:22:37gmaxwell:"It just goes to where it went before" is not a good answer; where it went before may well be a total black hole now. Sure; I agree there are cases where a replay vulnerability is acceptable-- e.g. where you can be fairly sure the software will prevent replay, and where it happening will be recoverable-- but this is not the case for ordinary transactions.
18:23:44gmaxwell:"
18:23:51kanzure:would it be better for a civilization to insist on only doing reversible economic transactions?
18:23:59kanzure:i would imagine you'd have to leave out.. a lot.
18:24:24kanzure:s/reversible/replayable (subtle difference i guess?)
18:24:54gmaxwell:StephenM347: saying that it's not worse that txid mutation seems completely incohearent to me. Changing a txid can not result in funds loss in an even stronger sense than your argument that replay-with-value cannot result in loss.
18:26:07gmaxwell:kanzure: for replay to be safe you must never reuse addresses; not reusing addresses is hard from an application perspective because maintaining state is hard. E.g. say you generate an address but then crash; when you recover you forgot that you already generated that address.
18:26:25gmaxwell:It's not impossible; but it requires a lot of considerations.
18:27:34kanzure:right, you should never generate addresses at run-time anyway
18:27:45kanzure:and ideally you should never allocate addresses at run-time either
18:28:38sipa:whether you generate them at runtime or not is not relevant
18:28:42sipa:whether you mark them as used is
18:30:25StephenM347:gmaxwell: "but this is not the case for ordinary transactions" -- and ordinary transactions have no use for these types of sighash flags anyway. I'm not saying we should all start using these flags all the time, there would just be very specific use cases
18:30:40StephenM347:For example, when setting up a micropayment channel you have to establish the refund TX
18:30:49StephenM347:that could be done with SIGHASH_INPUT_WITHOUT_TXID
18:31:06StephenM347:That refund transaction is never meant to be broadcasted to be blockchain, it's just there as a back up
18:32:22StephenM347:And the refund transaction would be signing away a scriptPubKey that was sent to a 2-of-2 multisig address
18:32:39gmaxwell:StephenM347: "and ordinary transactions have no use" please read the thread you were responding to.
18:34:03gmaxwell:... the person there was basically arguing that BIP66 protections against third party malleability shouldn't be done because your flags proposal was a better solution.
18:34:17gmaxwell:Which would mean using a replay vulnerable form on all transactions.
18:36:25StephenM347:gmaxwell: Oh, right. As I said in the email chain, I don't think this should be seen as a replacement for that BIP at all, they are complementary
18:39:32Luke-Jr:gmaxwell: only transactions with address reuse?
18:40:23Luke-Jr:also, do you mean BIP 62? 66 is just strict DER…
18:41:50sipa:he means bip62 i think :)
18:44:45gmaxwell:62 :)
18:50:16gmaxwell:StephenM347: Well my response was specific to that subject, not a general opposition to more flexible masking; as far as the point that "better to build in a more flexible solution now than to wish we had more flexible nHashTypes later"; there is a straight forward counterargument that every piece of additional complexity has high cost; not just for the system itself but for many of its users (th
18:50:22gmaxwell:ere are applications that become insecure if you're not minding sighash flags set by third party software); Functionality is basically impossible to take away (since removing functionality might confiscate coins), but possible to add; so great care and consideration must be applied.
18:52:11gmaxwell:Though, I'm also not a great fan of the bag-of-flags approach, I'd rather a more programmtic approach to powerful masking, one which is demonstratively fully general. Even though it would likely be somewhat more complex it would not have te outcome of having a lot of complexity that turned out to not be useful.
18:52:55gmaxwell:(which is something we suffer from in the system today; lots of options almost no one uses; missing a few options people really want)
18:54:33StephenM347:gmaxwell: Makes sense :) And if you're software isn't paying attention to sighash flags set by third party software, then it probably already has vulnerabilities just with the set of sighash flags we use now.
18:57:24StephenM347:How could you be more general with a programatic approach? It seems like the so-called bag-of-flags approach general and compact
18:58:22StephenM347:Things like OP_FEELESSTHANVERIFY should probably be done programmatically, though, rather than in sighash flags
19:01:41Luke-Jr:ehh, that sounds like a crappy opcode to have :P
19:02:01Luke-Jr:especially since fees are possible underdetectably
19:08:12gmaxwell:StephenM347: e.g. An op_code that pushes a full parse tree of the transaction onto the stack; and an opcode that pushes elements onto a tagged signature stack for signing.
19:57:15Sub|afk:Sub|afk is now known as SubCreative
20:00:57andytosh1:andytosh1 is now known as andytoshi
20:42:23Taek:I am going to be in SF 14th-16th of May if anyone is interested in grabbing lunch or a drink.
21:25:30mm_1:mm_1 is now known as mm_0
21:37:30gmaxwell:sipa: I think I have a ~log(height) computation, O(1) communication algorithim for selecting and signaling random subsets of the block history.
21:38:26gmaxwell:sipa: History is divided into ranges of some number of blocks for locality purposes, e.g. say 100 or 1000 or whatever. For now I'll pretend the range size is 1 for simplicity, but you'd just substitude range for block in the below.
21:39:33gmaxwell:sipa: Each peer signals a 32-bit seed (which they select uniformly, and a count of the number of blocks they'll store.
21:40:57gmaxwell:When you want to figure out what blocks your peers have, for each peer you pick a random index out of their nr_blocks range. You then compute key = index||seed, and query a jump-consistent hash [1] JCH(key, height), the result is what block they're storing in that slot.
21:41:33gmaxwell:After doing this with all peers, if you've found adequate sources for the block you want, you're done. Otherwise, go back and for peers with more slots, determine what block they have in that slot.
21:42:02gmaxwell:[1] A candidate JCH() is http://arxiv.org/pdf/1406.2294v1.pdf which is better than log(height) in runtime.
21:44:42gmaxwell:I don't think I can do better than this, but I think this is actually good enough to use. Some simulation would be needed, and perhaps some preprocessing of the key to avoid pathological behavior in the JCH due to poor distribution of the nr_blocks index.
21:50:09sipa:gmaxwell: that's good enough for finding what to ask from which peer
21:50:26sipa:gmaxwell: but perhaps not for deciding who to connect to
21:50:49gmaxwell:I'm assuming an extended addr message that includes these seed,nr values.
21:51:25gmaxwell:though ... one could hijack the existing addr messages by using your external IP as the seed, and talking a couple service bits to signal nr. 0_o I'm not a huge fan of that.
21:52:22gmaxwell:(I assume the extended messages would also include a range or flag for how near to the tip do you keep, e.g. 288 vs 2016 vs all blocks.)
22:09:03gmaxwell:In any case, I think this is a pretty big improvement over my prior best approach of using reservoir sampling, which had O(height) complexity. The downside is that you the heights of the blocks you hold are not monotonic increasing. :( At a future height you may find yourself needing to replace a slot with older blocks. :(
22:09:25gmaxwell:Which wasn't a problem the reservoir sampling had.
22:10:37gmaxwell:Though there may be some choice of a consistent hash that would just be monotonically increasing.
22:53:20gmaxwell:[Totally OT but will be of interest to some here]: http://bbcomp.ini.rub.de/ with only 4 days left I'm just going to phone in some pre-fabbed optimization code of mine.
23:37:56bencxr:hi there, are there any /r/bitcoin mods here?
23:45:59justanotheruser:/r/bitcoin is probably a better place to ask, I don't know of any who hang out here