00:24:31SubCreative:SubCreative is now known as Sub|afk
02:08:26Sub|afk:Sub|afk is now known as SubCreative
03:08:00bramc:I think I have roshambo figured out now. It can be done with a far, far weaker system than bitcoin has, although committing to a value by the length of the preimage is a key trick, and having malleable transactions where things refer to older ones including the signature is a real problem. You can do a lot more by setting up chains of transactions in advance if you don't have those problems.
03:27:16AdrianG:so how is this chat different from -dev?
03:27:51gmaxwell:AdrianG: see the topic
03:28:45AdrianG:i just did actually, which is why i asked.
03:28:53AdrianG:so long-term, moonshot idea discussions only?
03:37:47bramc:moonshot ideas and high level discussions
03:38:06bramc:And higher level engineering
04:59:19phantomcircuit:nice bc.i changed their production code w/o updating github first
05:08:09bramc:Real men hot patch their web sites by sshing in and using a text editor.
05:25:31rusty:It strikes me that soft-forks would be easier if evaluated OP_NOP immediately made the script evaluate to true.
05:30:14rusty:And a new scripting language could be introduced as long as it always wrapped scripts in OP_TRUE OP_NOTIF ... OP_ENDIF. If we dropped the silly DER encoding from signatures, we'd gain more than the 3 bytes lost anyway.
06:16:26bramc:what is the DER encoding?
06:17:34lechuga_:https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#DER_encoding
06:18:03rusty:bramc: a standard way of encoding datastructures. Of course, it's supposed to be canonical, and duh, it isn't.
06:18:16gmaxwell:rusty: OP_NOP returning true would be pretty devastating in a script sig. :)
06:18:28rusty:bramc: really, all we want is 32 bytes for s and 32 bytes for r..
06:18:44rusty:gmaxwell: Oh yeah :)
06:19:39rusty:* rusty quietly notes that pettycoin got this right, at least.
06:20:24bramc:How is DER not canonical?
06:21:52rusty:bramc: well, it's supposed to be, but seems like libopenssl will actually accept non-canonical encodings.
06:22:28rusty:bramc: using an encoding at all was a weird thing to do, given it wastes 6-7 bytes IIRC.
06:22:54bramc:rusty, My conclusion after going over everything is that trying to make things canonical while generally a good idea isn't something you want to really rely on and that the real problem is that utxos are referenced by transaction + signature instead of just transaction
06:23:30bramc:Using just the transaction would allow you to set up chains of things in advance and actually rely on them.
06:23:31gmaxwell:Issues with non-canonical forms extend far past just narrow malleability concerns.
06:23:50rusty:bramc: canonical txids are really a nice feature, I think they're worth some sweat for.
06:23:55gmaxwell:(and bitcoin.. there have been many cryptographic systems broken because something should have been canonical but it wasn't)
06:25:16rusty:gmaxwell: yes, and the specifiers of DER were aware too. Maybe the openssl implementers weren't...
06:25:17gmaxwell:Seperating the signature from the transaction ID is a favorite point of roconnor, or more general seperating out all the witness parts that show validity from the rest.
06:26:32gmaxwell:rusty: it's not just openssl thats broken there. (I know openssl is a popular punching bag these days, and its well deserved, but it's by far not alone in this case)
06:28:11gmaxwell:There are some reasons you can argue against leaving the signature out of the id, but they're pretty tortured. If that were done the p2p protocol would need a second ID for message relaying though.
06:29:30bramc:The effects on the p2p protocol wouldn't be too bad, peers would need to know to send signatures with certain things
06:29:45gmaxwell:E.g. consider a transaction X which signs for 2 of 3 keys a,b,c. A signatures with a,b or b,c or a,c are all equally valid. But they may have significant semantic and legal differences to the users of the system. Depending on how throughly the seperation is, the system may give no strong record of what signature was used, which may be undesirable. As I said, tortured. :)
06:30:48gmaxwell:bramc: It's not just "need to know to send", it's things like; if you get tx A with a bad signature, you still need to request A again, but you don't want another copy with the same bad signature.
06:31:24gmaxwell:So this could be resolved using a distinct ID for transport (e.g. over the whole thing) or transporting signatures and data seperately (2x inv data overhead), or presumably some other ways.. it's a bit of complexity at least.
06:31:48bramc:And I'm not arguing against canonicalism, just that it's very hard to enforce canonicalism, and it isn't something you want to rely on when you don't have to. I can tell you from experience that people reeeeeally like accepting malformed versions of things if they have an 'obvious' interpretation.
06:32:35bramc:gmaxwell, I worked out how to do roshambo with a minimal set of primitives, it's waaaay harder if you have to know your signatures before you can make dependent transactions
06:33:06bramc:If you have that feature then all you need is the ability to make something depend on a hash preimage of a certain length, and you encode your move in the length.
06:33:29bramc:Same as in the oakland lottery paper. I forget who explained that one to me, but the length encoding trick is a great idea.
06:35:09bramc:Maybe I should do a blog post on this. It's a fun puzzle and construction.
06:35:58gmaxwell:Yes, people love accepting malformed things, and it's absolute doom in a consensus cryptosystem, since _all_ visible consensus behavior must be implemented exactly the same.. "uh, this is crap but I'll interpret it as something" generally means making all kind of twisty implementation details normative. Vs a strict check where you must implement exactly the same well specified strict check, and then you have a bunch of freedom in ...
06:36:05gmaxwell:... your implementation, since it just has to be identical over inputs that past the strict check.
06:41:13bramc:Yes. The one thing you can count on is that everything agrees what digital signatures apply to, because that's definitional in getting the primitive right.
06:41:32bramc:Or at least you hope you can count on that. If someone implements that wrong, there is no hope for them.
06:42:45bramc:by 'fun puzzle and construction' I was referring to precommitting to roshambo, not canonicalizing encodings. Enforcing canonical encodings is universally horrible.
07:03:07ubuntu_:ubuntu_ is now known as aburan
08:45:14pigeons:pigeons is now known as Guest5457
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 [\\\] CoinMuncher1 Guest5457 askmike wallet42 vmatekole Shiftos Burrito ahmed_ rusty koeppelmann paveljanik coiner copumpkin bitbumper gsdgdfs TheSeven jb55 gribble isis nuke1989 Dr-G2 bramc Luke-Jr dgenr8 jgarzik RoboTeddy ebfull tromp luny c0rw1n super3 andytoshi lechuga_ gues__ zwischenzug2 Starduster waxwing Emcy bobke btcdrak coutts CryptOprah artifexd Muis hguux_ michagogo kumavis Flyer9933 nickler go1111111 gavinandresen
09:05:16tepper.freenode.net:Users on #bitcoin-wizards: Graftec Hunger- v3Rve prepost NikolaiToryzin hashtag_ ryanxcharles PRab Aquent warptangent devrandom Fistful_of_Coins phantomcircuit wumpus heath koshii HM2 paperbot kefkius zibbo SubCreative maaku epscy OneFixt prodatalab lnovy EasyAt jaekwon_ Cory digitalmagus LarsLarsen Guest38445 coryfields iddo otoburb_ kinlo azariah4_ Guest6066 grandmaster HaltingState null_radix fenn shesek bosma tdlfbx iambernie mr_burdell adlai mkarrer nsh_ yoleaux
09:05:16tepper.freenode.net:Users on #bitcoin-wizards: btc__ Graet Logicwax pi07r Meeh starsoccer 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 jaromil BigBitz espes [d__d] so gmaxwell
09:05:16tepper.freenode.net:Users on #bitcoin-wizards: cfields-away crescendo petertodd throughnothing Apocalyptic optimator_ Taek mmozeiko comboy poggy Krellan tromp_ bbrittain Dyaheon wizkid057 burcin @ChanServ BananaLotus livegnik gwillen AdrianG gazab a5m0 BlueMatt
09:37:51lclc_bnc:lclc_bnc is now known as lclc
09:50:35lclc:lclc is now known as lclc_bnc
10:11:54starsoccer:starsoccer is now known as Guest82724
10:12:22Guest82724:Guest82724 is now known as starsoccer
10:12:52starsoccer:starsoccer is now known as Guest84994
10:16:49starsocceraway:starsocceraway is now known as starsoccer
10:17:22starsoccer:starsoccer is now known as Guest79334
10:26:40michagogo:bramc: s/a text editor/sed/
10:26:58michagogo:Er, actually
10:27:09michagogo:make that s/a text editor/dd/
12:04:57grandmaster:grandmaster has left #bitcoin-wizards
13:41:57Guest5457:Guest5457 is now known as pigeons
14:11:53jgarzik:jgarzik is now known as jgarzik_
14:31:09Soze49:Hi, I'm new to bitcoin, and I was wondering the status of the multi peer conection for syncronizing blocks, is there any discussion about it ? I want to contribute with full nodes in Argentina, but I notice that first timers consume a lot of bandwidth and right now limiting the bandwidth will punish the 'first timer' and probably chase him away.
14:32:22MRL-Relay:[fluffypony] headers first is probably a good starting point, Soze49
14:32:51MRL-Relay:[fluffypony] https://bitcoinfoundation.org/2013/10/core-development-update-5/
14:33:24sipa:Soze49: #bitcoin-dev
14:37:31Soze49:moving to bitcoin-dev thanks
15:06:57gavinandresen:I’m 98% sure DER encoding IS canonical. The problem is OpenSSL accepts the looser BER encoding (why there is a BER encoding in the first place, I dunno, probably some committee compromise way back when)
15:35:21wumpus:BER was the original encoding for ASN.1, DER came later and is the canonicalized form of BER with most of the wiggling room removed, meant for encoding certificates, keys and such. Accepting BER for those purposes sounds like a mistake though...
15:38:00sipa:DER should have 0 wiggle room; for every piece of data it specifies exactly one encoding
15:38:09sipa:but indeed, OpenSSL accepts BER
16:09:39zooko`:zooko` is now known as zooko
16:47:40tromp_:which is preferable: A) 2KB header and pow verification in time X, or B) 1KB header and pow verification time 8X ?
16:48:04tromp_:(for a prospective nonoutsourceable pow)
16:48:26fluffypony:what's the use-case for more header space?
16:48:31gmaxwell:usually bandwidth is more constrained than computation... but is this a decision that could be decide on a point to point basis?
16:48:52gmaxwell:Being able to choose based on what your own actual capabilities are is best.
16:49:15tromp_:yes, it could easily be a dynamic choice
16:49:54tromp_:but fixed once a block is computed
16:50:51gmaxwell:you can't commit to both and chose on the fly?
16:51:23tromp_:no, they are different pow instances
16:51:56tromp_:X is about 500 sha256
16:53:44tromp_:it's nice that in making pow nonoutsourceable, the large proof size of cuckoo becomes a total non-issue
17:35:14kanzure:"if I go into a coma and wake up 50 years from now, and I look around me and see all the various blockchains, then the one I choose is the one with the largest sum of work done across the blocks, not necessarily the longest, right?"
17:36:20tromp_:yes, it's trivial to creat very long low diff chains
17:36:39HM2:except you don't know if that work is equal
17:37:02HM2:you could arrive on day N where a new supercomputer had been invented on day N-1
17:37:19HM2:so you would want to look at a graph of difficulty over time as well
17:37:29HM2:right?
17:37:31kanzure:i think it is supposed to be highest total-work chain
17:38:42gmaxwell:It's the highest total work chain. Talking about 'longest' is a simplification that is equal when you're not yet considering difficulty changes.
17:55:39phantomcircuit:sooo
17:55:51phantomcircuit:someones offering me $10 for my trolltalk account
17:56:01phantomcircuit:er wrong channel
18:14:07stonecoldpat:ill offer some dust change for it
18:15:56stonecoldpat:HM2: difficult changes over time wouldnt matter really, it would have to be the total-work chain, as the N-1 computer could simply produce the 'difficulty changes over time' chain, perhaps even mimicing the timestamps
18:31:50HM2:question, has the difficulty ever gone down in response to a drop off in hashing power?
18:32:06HM2:or can that not happen?
18:33:57tromp_:it just did
18:34:20tromp_:https://bitcoinwisdom.com/bitcoin/difficulty
18:34:29fluffypony:HM2: https://www.cryptocoinsnews.com/bitcoin-mining-difficulty-decreases-first-time-almost-two-years/
18:35:16HM2:hmm, odd
18:35:19tromp_:we passed peak hash :)
18:50:37kanzure:another thing that would be useful is if you could make a transaction that is only valid as long as some other txid does not exist in the blockchain
18:50:50kanzure:oh wait, i don't mean txid. hmm.
18:53:16gmaxwell:kanzure: that fundimentally changes the verification complexity.
18:53:43kanzure:sure does. probably to an unreasonable degree.
18:58:55cfields-away:cfields-away is now known as cfields
19:00:22jgarzik:in theory that is what happens today with 0conf tx + double-spend
19:00:48jgarzik:TX'A is valid until TX'B comes along and supersedes. See also replace-by-fee.
19:01:39kanzure:i should have been more specific, i meant "where any other transaction can invalidate another transaction (or be mutually incompatible) without requiring the same outputs to be spent"
19:02:03kanzure:i believe that gmaxwell predicted this was the interpretation i intended
19:05:16Emcy:did it really take that long for the mining market to react to lowering coin value
19:05:39Emcy:or was anotehr factor at play. huge lead time on hardware orders maybe
19:06:22kanzure:it goes back to my suggestion (which turned out to be a slightly more nuanced variation of gmaxwell's prior idea regarding "transaction block commitments") to figure out an opcode for making a transaction only valid as ong as some specific blockhash is in the blockchain (and "valid only as long as these other outputs have been spent, without respending the same outputs" is a similar concept in the same family)
19:06:36kanzure:*as long as some
19:10:22AdrianG:is there a bitcoin-specific irc network?
19:21:11Emcy:i hope not
19:21:30Emcy:probably get owned on login
19:23:19phantomcircuit:Emcy, wouldn't be any worse than freenode
19:24:24fluffypony:hah hah
19:28:33jgarzik_:jgarzik_ is now known as jgarzik
20:39:22kanzure:could there be a p2sh scriptpubkey that places an additional constraint (besides signatures) on which scriptpubkeys are used in future outputs?
20:41:25gmaxwell:kanzure: https://bitcointalk.org/index.php?topic=278122.0
20:44:49hearn:hearn has left #bitcoin-wizards
20:59:39kanzure:looks like some new opcodes might be required for that?
21:02:25gmaxwell:the thread points out that it has a lot of unintended consequence potential that is kinda ugly. (there are positive uses, but its easy to accidentaly enable negative ones without making positive uses pratical)
21:04:21kanzure:someone proposed 1-of-2 multisig but with restricted covenants on where anyone can spend to... but this doesn't work unless you're willing to lock everything forever.
21:05:02kanzure:ah maybe it should be more like 1-of-2 multisig where 2 is required to skip the covenant
21:07:20kanzure:recursive covenant sounds a little strange though. hm.
21:12:24gmaxwell:It's really easy to introduce them accidentally, we'd basically have them in bitcoin already if substr and friends were enabled and if you didn't have to have the input txhash under your signature.
21:13:26hearn:there are potentially some helpful use cases. consider giving a child pocket money that they can only spend at a subset of merchants. once they receive the money, those merchants can unlock the covenant and get fully relaxed coins again. you could do it at the wallet ui level but it's not quite as solid.
21:15:03kanzure:one use case that came up was something about collateral and only being able to transfer to certain bip32-style derived keys (from a certain root key) unless both parties were signing
21:42:32gmaxwell:kanzure: keep in mind that testable "bip32-style derived keys" mean they effectively share the same private key.
21:43:26kanzure:well, i was pretending that Luke-Jr's email about p2sh bip32 stuff was figured out, but i didn't make that explicit, so fair enough :)
21:43:46kanzure:let's play a game of 20 hidden assumptions
21:48:46gmaxwell:I don't follow that. I think you're actually thinking something is possible that isn't. Say you have some addresses A, B, C which are verrifyably derrived from master pubkey Q. If you happen to be able to verify that fact, as you would need to be to make use of it in a covenant, and you know the private key behind any of A, B, C, or Q ... then you also know the private key for all the others
21:48:52gmaxwell:.
21:49:41gmaxwell:Maybe instead you just mean to a predefined set of addresses, ignoring bip32-derrived-etc-ness?
21:59:51kanzure:oh you mean "there is no way to distinguish between any separate use of those child keys", which is correct
22:00:07kanzure:s/which is correct/which i agree is correct
22:02:09kanzure:as for the email that i was thinking of,
22:02:19kanzure:http://sourceforge.net/p/bitcoin/mailman/message/33111591/ ("serialised p2sh hd chains")
22:02:56kanzure:as for the quip about 20 questions, i was mocking my poor record for (not) clearly specifying all assumptions
23:13:46cbeams_:cbeams_ is now known as cbeams
23:56:52belcher_:belcher_ is now known as belcher