01:33:49zz_lnovy:zz_lnovy is now known as lnovy
02:54:53zz_lnovy:zz_lnovy is now known as lnovy
03:25:35rusty:gmaxwell: OK, I posted the results of my hacky simulator for the server concept. Code needs some neatening before posting, but RSN. http://rustyrussell.github.io/pettycoin/2014/12/04/Pettycoin-Revisited-Part-II:-Proof-of-Propogation.html
03:48:33nsh:rusty plays "simulator", earns SEVENTEEN cool-points|!
04:37:58maaku:maaku is now known as Guest37856
04:38:42Guest37856:Guest37856 is now known as maaku
04:40:57jps_:jps_ is now known as jps
05:54:03op_null:op_null is now known as OP_MUL
06:04:23bramm:bramm is now known as bramc
06:09:37bramc:A dumb question about transaction malleability: Are bitcoin transactions not cleanly separated into a 'transaction' part and a 'signature' part? If they were it would seem reasonable to view the transaction part as the important/canonical bit
06:13:05OP_MUL:some people at one point made an alternate "normalised transaction hash" that did just that. it never made it into bitcoin core or anywhere else as far as I can see.
06:13:57OP_MUL:you can find a lot of talk about it here, and why it's not a solution to malleability as such. https://github.com/bitcoin/bitcoin/pull/3656
06:14:53OP_MUL:(this was just before Mt Gox went away for good, part of the reason why it was made suddenly and then denied was that Mt Gox claimed transaction malleability was responsible for their losses)
06:16:44OP_MUL:(it might have been, the backstory was that their system would send out a transaction with their known hash, then look for the transaction in a block, if it wasn't there after a certain period they would resign a new transaction with different outputs as a replacement. if the initial TX was mutated they ended up paying some transactions many times under different TXID)
06:17:42adam3us:the mistake being to not double spend one or more of those inputs so that someone couldnt use it to withdraw multiple times
06:17:53OP_MUL:(I think the code was supposed to sign double spends so that this couldn't happen, but it didn't function properly or something, I can't quite remember. the end result was that they lost maybe a few BTC)
06:17:56midnightmagic:it likely was not responsible for most of the thefts (presuming they were thefts)
06:20:13OP_MUL:oh no, but the whole situation explains nicely about normalised transaction IDs and why they probably aren't a good idea.
06:31:03OP_MUL:OP_MUL is now known as op_null
07:02:10midnightmagic:for sure
07:04:26bramc:You know, the important thing is which utxo(s) the payment came out of. Those are what needs to be kept consistent, and should be plenty for the receiving side to verify that they got the payment
07:06:15op_null:BIP62 means it's very hard for people on the network to mutate transactions, but you can't stop people making the transaction from creating mutants.
07:06:20bramc:And yes, it seems hardly anyone believes mtgox's story
07:07:03op_null:bramc: that's because there's nothing to support 700k BTC being mistakenly sent like that.
07:07:12bramc:op_null, but any resulting transaction will involve the same utxos. At least I hope it well!
07:07:17bramc:will not well
07:08:46op_null:the maker of a transaction will always be able to change and grid the UTXO hash though, signature or no signature. just rolling the change address output would do the trick.
07:09:42nsh:grid?
07:09:52op_null:grind
07:10:36op_null:somebody had a lottery at one point which used the TXID as a random oracle, hence that comment.
07:13:00op_null:and somebody was trying to convince me earlier that a mod to ECDSA would stop people from being able to roll nonces, well, obviously that can't happen without exposing the private key :P
07:17:38gmaxwell:op_null: it wasn't applicable there, but technically one can convert ecdsa into a one time signature by requring the key use only a single nonce which is pre-commited to. Though if someone wants a unique signature there are probably better constructions (esp since even with making it one time, it's still not unique).
07:18:12nsh:hmm
07:25:20maaku:maaku is now known as Guest84438
07:32:32bramc:Oh, are output utxos dependent on the exact encoding of a transaction? If so, that causes issues even for very simple things like atomic transfers
07:37:51wallet421:wallet421 is now known as wallet42
07:53:12op_null:bramc: yes. when you reference a previous transaction as a vin, you reference the TXID and the index down the TXID of the output you wish to spend.
07:54:36op_null:bramc: that's one of the reasons spending unconfirmed outputs is a bad idea, you risk making large chains of transactions that could be invalidated by an alternate inclusion in a block.
07:55:58bramc:op_null, a send-back transaction signed by the counterparty is part of the atomic transactions protocol, at least until the opcode to make ways of unlocking utxos be timelocked is added
07:56:11lclc_bnc:lclc_bnc is now known as lclc
07:57:40bramc:So that's a case where not being able to reference an output before it's happened is a real problem.
08:11:41nsh:* nsh is tempted to have another go at an auto-citing tweet
08:11:55nsh:*self-citing, clearer
08:13:41bramc:nsh, What's the algorithm twitter uses for picking tweet urls?
08:14:20nsh:no idea, seems to be roughly increasing
08:15:25nsh:presumably it's decentralized somehow, but not clear to me intuitively a simple way of doing that
08:19:30op_null:bramc: incrementing.
08:20:43nsh:can't be single counter. that would not scale
08:21:15nsh:they could delegate blocks of integers to clusters and then maybe sweep up the unused ones later, or just leave them as so
08:21:56nsh:between about 3s-apart tweets was 16152264705 difference
08:22:09nsh:16 billion
08:36:17op_null:nsh: for a while at least they were incremental. maybe they are sharded so different nodes don't overlap?
08:36:41op_null:nsh: when I first used twitter it was in the billions so that's where that comment came from.
08:36:50nsh:* nsh nods
08:42:57bramc:the algorithm has likely changed over time
09:05:15holmes.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:15holmes.freenode.net:Users on #bitcoin-wizards: andy-logbot zibbo nuke1989 soundx webdeli RoboTeddy Aquent wallet42 damethos kristofferR Guest84438 epscy coiner OneFixt_ paveljanik bramc Transisto TheSeven go1111111 warptangent Starduster prodatalab lnovy Dr-G2 hashtag_ gues ryanxcharles atgreen jb55 EasyAt Shiftos c0rw|zZz jaekwon_ Cory digitalmagus LarsLarsen Guest38445 coryfields iddo devrandom davejh69__ otoburb_ kinlo azariah4_ luny` Guest6066 SDCDev hashtagg grandmaster HaltingState
09:05:15holmes.freenode.net:Users on #bitcoin-wizards: null_radix Luke-Jr fenn shesek op_null bosma tdlfbx iambernie nubbins` mr_burdell hguux_ dgenr8 adlai tacotime jgarzik mkarrer Greed Emcy_ nsh_ yoleaux btc__ Graet Logicwax samson_ andytoshi pi07r prepost ybit Meeh starsoccer PaulCape_ DoctorBTC NikolaiToryzin nsh stonecoldpat waxwing btcdrak mappum tromp K1773R ahmed_ artifexd nanotube dansmith_btc kanzure spinza Flyer33 arowser1 SubCreative Anduck lechuga_ harrow roasbeef ryan-c TD-Linux
09:05:16holmes.freenode.net:Users on #bitcoin-wizards: catcow danneu amiller smooth gribble asoltys pigeons warren BrainOverfl0w midnightmagic phedny huseby Iriez Keefe helo jaromil wumpus BigBitz espes [d__d] so gmaxwell Fistful_of_Coins cfields-away CryptOprah crescendo petertodd throughnothing Apocalyptic [\\\] optimator_ Taek mmozeiko comboy poggy Krellan tromp_ nickler bbrittain Dyaheon wizkid057 coutts burcin @ChanServ BananaLotus livegnik gwillen AdrianG gazab a5m0 BlueMatt fluffypony
09:05:16holmes.freenode.net:Users on #bitcoin-wizards: MRL-Relay Muis kumavis jbenet Alanius sipa Grishnakh sl01 phantomcircuit JonTitor gavinandresen michagogo harrigan sneak isis LaptopZZ bobke Eliel_ s1w lclc Hunger- berndj hollandais Nightwolf
09:49:13wumpus:twitter used to use an (open sourced) approximately increasing 64-bit id generation system called snowflake (https://www.github.com/twitter/snowflake), but it appears that it has been retired
09:52:57nsh:ah, i thought i recalled the algorithm being known at some point
10:58:44lclc:lclc is now known as lclc_bnc
11:27:48lclc_bnc:lclc_bnc is now known as lclc
13:18:26luny`:luny` is now known as luny
15:17:42kanzure:nsh: they could allocate increments of their counter to different nodes in their cluster.
15:17:56kanzure:nsh: because it would be weird if it is impossible to slice up portions of a number faster than your users post bad content.
15:25:38op_null:kanzure: they need some sort of ordering system without central authority..
15:26:14op_null:maybe a DHT?
15:28:31kanzure:what's the ordering for?
15:28:38kanzure:they only need local ordering per user i think
15:29:29op_null:I think having a roughly increasing integer means they can order without needing to look up metadata.. but I don't know really.
15:29:51kanzure:i don't think they ever really need to do an actual ordering of all messages
15:31:32pigeons:you can't suggest DHT in this chennel! lol ;P
15:31:51kanzure:why not?
15:31:53op_null:pigeons: (that's the joke)
15:32:37pigeons:kanzure: its a joke because people used to suggest they could improve any issue you could think of with bitcoin by using a DHT before they had actually thought it through
15:33:00pigeons:it was very very common occurance to the point of cliche
15:33:16kanzure:apparently i was not around for that
15:34:54lclc:lclc is now known as lclc_bnc
15:35:01sipa:we need a quotebot
15:35:46kanzure:sipa, for a while i had a gradstudentbot in another channel
15:35:49pigeons:i noticed gnu name system uses both sycrypt for PoW and a DHT for db storage
15:36:05kanzure:most of his quotes were taken directly from https://www.youtube.com/watch?v=ovEghdXC4tE
15:48:02gmaxwell:kanzure: now adays instead of the DHT gibberish, instead people are flooding other communities and telling people to use blockchains where they may not make any sense.
15:49:31stonecoldpat:i cant remember from the top of my head, but if someone sends you enough to cover a transaction fee, can you create a transaction with a single OP_RETURN output? (so the transaction fee is spent)
15:49:55Luke-Jr:stonecoldpat: yes, but don't.
15:50:29stonecoldpat:i know its considered spamming (not going to do it), but its more out of interest atm
15:50:55op_null:gmaxwell: it's telephony with a block chain!
15:51:05amiller:what happens when you put an op_true out there? does someone take it?
15:51:11Luke-Jr:amiller: I do!
15:51:20op_null:no. the script can just never be made true.
15:51:39op_null:so we can drop it from the UXTO if we choose.
15:51:47Luke-Jr:* Luke-Jr runs with a patch that tries to spend any output it sees with up to 100 OP_TRUEs
15:52:30amiller:Luke-Jr, ok that was my next question :p
15:53:29stonecoldpat:Luke-Jr: although, doing the transaction fee thing, would be better than those proof of burn ideas (where you send bitcoins to an unspendable address) if you wanted to finish a chain
15:53:48Luke-Jr:stonecoldpat: "finish a chain"?
15:54:05stonecoldpat:well transactions are all chained, they will eventually come to an end at some point
15:54:15Luke-Jr:…
15:54:19stonecoldpat:when you do a proof of burn, you finish the chain of transactions as its no longer spendable
15:54:29op_null:not really. when you spend an output it is destroyed. no chain of anything.
15:54:48Luke-Jr:stonecoldpat: I see what you're saying, but this is not a useful concept.
15:55:34stonecoldpat:op_null: what I mean is that there is a trace left on the blockchain, so you can hop transaction to transaction
15:55:50stonecoldpat:luke-jr: i agree its not useful, just interesting atm from my perspective
15:56:15stonecoldpat:or at least shouldnt be used to any large extent as it just bloats the blockchain
15:56:40Luke-Jr:the most use I see of it would be if someone sold custom made chain-link blankets(?) that were designed with the actual transaction linkage in the real blockchain <.<
15:56:48Luke-Jr:as a kind of … pointless toy
15:57:21op_null:chain link stuff sucks. it pulls all of the hairs out of your skin if you touch it.
15:57:28Luke-Jr:O.o
15:57:39stonecoldpat:well, what im thinking is, if you want someone to certify a message for you, lets say some authority, you send them the transaction fee, plus the message to certify, and then they certify it
15:57:50Luke-Jr:hm. I bet if someone was producing those, we'd suddenly have a surge of spammers trying to embed art in the product
15:58:10op_null:Luke-Jr: the chains pinch hairs between them, so if you put on a chain link shirt without anything under it you're in for a really, really painful day.
15:58:11Luke-Jr:stonecoldpat: or you just send them the message and they PGP sign it
15:58:13amiller:Luke-Jr, that would be an amazing gift, the bitcoin transaction graph knitted out of silk fibers
15:58:16Luke-Jr:stonecoldpat: no need for a blockchain
16:28:34wallet42:wallet42 is now known as Guest25033
16:28:34wallet421:wallet421 is now known as wallet42
16:45:48lclc_bnc:lclc_bnc is now known as lclc
17:10:10lclc:lclc is now known as lclc_bnc
17:46:15kanzure:"The uneasy relationship between mathematics and cryptography" http://www.ams.org/notices/200708/tx070800972p.pdf
17:55:06HM2:Neal Koblitz?
17:55:14HM2:as in the guy the Koblitz curves are named after?
18:18:13gmaxwell:HM2: Koblitz invented ECC, not just Koblitz curves.
18:22:48andytoshi:an interesting article kanzure, the talk of cryptographers submitting tons of barely-reviewed mostly-worthless papers is familiar
18:22:53andytoshi:and very upsetting, coming from mathematics
18:22:58HM2:I thought that was Al Gore
18:22:59HM2:;)
18:29:08pigeons:is he working for ethereum yet? :P
18:43:48HM2:who, Al Gore?
18:44:33phantomcircuit:ha
19:02:46gmaxwell:kanzure: presumably you've seen the anotherlook site? all the papers there are great.
19:14:26devrando1:devrando1 is now known as devrandom
19:23:10kanzure:gmaxwell: nope i have not
19:23:44ybit:http://anotherlook.ca/
19:24:16kanzure:oh, yes
19:24:27kanzure:"blue one with annoying red flashing NEW text"
19:56:08bramm:bramm is now known as bramc
20:47:02bramc:Well let's see, last two days of work my goals were to understand atomic transfer and nonoutsourcable puzzles, what will it be today?
20:53:08bramc:The upshot of things I've worked through so far: cuckoo is a good idea, maybe should use a weakened siphash. Atomic transfers are a good idea, depend on timelock and hash preimage signing. Nonoutsourcable puzzles are a good idea, probably should intermingle with cuckoo a bit.
20:55:43andytoshi:cuckoo i think we discussed at great length, nonoutsourcable puzzles seem not to leave any variance reduction mechanism (except trusted hosted mining), so those are quite controversial claims..
20:56:06andytoshi:but might be worth looking at the wiki Contracts page, has some interesting examples of script iirc
20:56:43andytoshi:or look at alternate implementations of the protocol and find consensus bugs (but pls do not publish them immediately! they are security bugs)
20:59:19bramc:Looking through alternative implementations for security bugs is not the sort of thing which improves one's outlook on life.
21:00:11andytoshi:this is true, but consensus bugs in particular improve your intuition about consensus systems
21:00:25andytoshi:or rather, your intuition about how hard they are :P
21:01:13andytoshi:if you want a math/crypto problem to work on, you can always try proving that ECDSA is or isn't a strong signature..
21:01:29tromp_:cuckoo is also at odds with variance reduction
21:02:00bramc:Yes nonoutsourcable puzzles are bad for variance reduction, that's kind of the point
21:02:02andytoshi:(well, it's definitely not because given a valid sig (r, s) it is true that (r, -s) is also a valid sig ... but are there any other ways to mar an ECDSA sig without breaking it?)
21:02:27bramc:I really want to explore ways that partials could be rewarded at the protocol level, basically turning all miners into one gigantic mining pool
21:03:23bramc:andytoshi, that question is well outside my mathematical forte and current interests. I did mail djb asking his thoughts about cuckoo and whether ed25519 might be malleable though.
21:03:37kanzure:"all miners" is a tough concept
21:04:10kanzure:so what you can get is proofs-of-work relayed around.... which will need some sort of consensus about which proofs-of-work are valid.. and uh...
21:04:14tromp_:did djb reply yet?
21:04:26bramc:tromp_, Not yet I mailed him like 20 minutes ago
21:04:38andytoshi:i think ed25519 is nonmalleable (or can be easily made to be) since eddsa is basically schnorr, and schnorr is nonmalleable
21:05:15andytoshi:this is one of those things that we've been meaning to check on for ages and never gotten around to..
21:05:34andytoshi:"ages" about six months
21:06:14bramc:kanzure, Consensus of what partials are valid isn't the problem, it's a question of how you incentivize later miners to include rewards for them
21:06:33bramc:I tried to start a discussion about that yesterday but nobody seemed interested
21:07:02kanzure:because many of the previously proposed implementations have been pretty bad (like "oh just have complete history of every partial ever, and then verify based on that")
21:07:28bramc:nonoutsourcability doesn't imply there aren't partials
21:07:52bramc:What's wrong with including the partials in the block chain? There has to be a transaction to reward them anyway.
21:09:04bramc:andytoshi, I think it's a good idea for the identity of a utxo to include the transaction which created it but not the signature, just, you know, in case malleability comes up later.
21:10:12bramc:kanzure, It can be compared in a very apples to apples way to what the mining pools do now, which basically create the same number of transactions
21:12:17andytoshi:bramc: yeah, that's how i would've done it
21:12:21kanzure:those mining pools have that information because of a centralized ledger
21:12:36andytoshi:(if i were inventing bitcoin, and was somehow doing so from the perspective of a -wizard in 2015)
21:13:20bramc:andytoshi, Yeah I probably would have gotten hit by the same gotcha had I done it in the first place
21:13:47bramc:kanzure, Not sure what you mean, they're still basically handing out one reward per partial, and those rewards have to be in the block chain
21:14:05kanzure:i don't know which definition of partial you are using here
21:14:15tromp_:bramc: including partials in the blockchain is starting to look like lowering block interval time by an order of magnitude
21:14:26kanzure:many pools do not pay per share until some participant has accumulated a balance sufficient enough to warrant a bitcoin transaction withdrawal
21:14:54bramc:tromp_, In some ways yes, but it doesn't create lots of orphans like lowing block interval times would
21:15:06bramc:And doesn't collide with cuckoo's minimum running time either.
21:15:06andytoshi:hard to say whether a real cryptography would've, who was thinking of script as a signature scheme and was aware of concepts like "strong signature" and "unique signature" and how they would've been helpful
21:15:12andytoshi:real cryptographer*
21:15:39bramc:I'm not a real cryptographer :-)
21:16:15andytoshi:nor am i :)
21:16:17bramc:kanzure, A partial is an accepted proof of work which isn't quite strong enough to mint a new block. Basically all the mining pools reward partials.
21:16:17andytoshi:but one day maybe
21:16:54kanzure:what do you mean by accepted
21:16:56bramc:I've been trying very hard to disavow being a real cryptographer for a while
21:17:29bramc:kanzure, accepted == given a reward for
21:17:46kanzure:have you looked at p2pool?
21:18:45kanzure:https://en.bitcoin.it/wiki/P2Pool
21:18:54bramc:Oh, hmm, p2pool is more interesting than I thought, I assumed it was just another mining pool
21:19:02bramc:just another centralized mining pool
21:19:06kanzure:"P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 30 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify ...
21:19:12kanzure:... that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many ...
21:19:18kanzure:... shares they have found in the last while."
21:20:00bramc:Yes I found the page before you posted the link
21:20:15bramc:Maybe I'll make my task for today to be to absorb this
21:21:08tromp_:when i said "cuckoo is also at odds with variance reduction" i meant it doesn't leave room to reduce the share interval time in p2pool
21:21:57bramc:tromp_, Maybe slightly older partials could be rewarded later
21:34:52bramc:tromp_, What do you think of my suggestion of intermingling the nonoutsourcable puzzle and cuckoo?
21:38:19tromp_:what is the nonoutsourcable puzzle you have in mind, bramc?
21:41:10bramc:tromp_, The one proposed in http://cs.umd.edu/~amiller/nonoutsourceable.pdf
21:42:03bramc:Basically my proposal is that the cuckoo edges be directly defined by the secret nonces, each nonce defining an equal fraction of the edges
21:43:11bramc:It shouldn't make any difference for the difficulty of cuckoo, and increases the communications needed by an attacker dramatically
21:44:10tromp_:let me read andrew's paper and ponder that a bit:)
21:46:12tromp_:how much slower will edge endpoint generation be compared to a single siphash?
21:49:57bramc:tromp_, Should be identical, assuming that you're already doing the work of making the nonoutsourcable puzzle
21:50:10bramc:Maybe the few hundred more siphash setups might matter
21:50:34bramc:But since each of them is used for a lot of edges that shouldn't be a big deal
21:51:29tromp_:are you using the weakly or strongly nonoutsourcable puzzles?
21:52:13kanzure:what's the difference from http://cs.umd.edu/~amiller/nonoutsourceable_full.pdf and http://cs.umd.edu/~amiller/nonoutsourceable.pdf
21:52:49bramc:tromp_, Not sure the difference, isn't there only one construction given?
21:53:33tromp_:i'd have to read it:) just skimmed the sectoin headers, and saw these two types
21:54:12bramc:The idea is that the nonoutsourcable puzzle outputs a nonce which is then run through cuckoo, I'd like to make it so that there's more than just a nonce so that if an attacker is trying to farm out work on just the cuckoo step they have to use more bandwidth than just sending the nonces
21:56:20tromp_:ic; you're using a nonce set other than just 0..2^{N-1}-1
21:57:38tromp_:how does that affect verification (e.g. by light clients?)
21:58:34tromp_:is the proof still the nonces as used in cuckoo, or something that generates them?
22:00:35bramc:tromp_, The proof is to reveal the 42 edges by revealing the nonces which generated them and giving an index for each, so the proof is made a bit longer
22:00:50bramc:Although not really because it's already dwarfed by the nonoutsourcable proof anyway
22:01:36bramc:Since there are only 42 reveals (or less) there's still plenty of room for the one signature giving a destination.
22:08:29tromp_:maybe we shld let variance reduction solve itself... by waiting a few decades till the reward is much smaller:)
22:09:37bramc:I'm curious what's going to happen when the rewards fall in half next time. I might buy some coin a month in advance in case the price goes up.
22:12:20bramc:So p2pool is a separate project not officially related to bitcoin proper?
22:13:47tromp_:correct
22:15:10bramc:Okay, I've now finished the top thing on my todo list: organize todo list
22:17:20kanzure:"officially related" is difficult, i mean what's official? bitcoin.git?
22:20:35bramc:kanzure, I mean, they don't directly collaborate on planning
22:23:59amiller:bramc, one of them has full proofs the other doesn't in the appendix
22:24:01amiller:kanzure, ^
22:24:17kanzure:oh, uh, others would know whether or not the p2pool people have collaborated with bitcoind development
22:24:25kanzure:more than i currently don't
22:24:50kanzure:+know
22:26:40phantomcircuit:bramc, now you can start writing todo lists for your todo list items
22:30:34bramc:Things left on my to review: p2pool, coinswap, the hardfork wishlist, and gmaxwell's commentary on proofs
22:45:00bramc:Is it possible with current bitcoin opcodes to do a smart contract for storage? That is, you can unlock something by showing a reveal of paths to a specified hash root based on the previous generation's block id?
22:47:04amiller:i tried once, i think i got stuck becuase OP_CAT is disabled
22:48:37bramc:Which is the opcode which satoshi dice used to pull out the root?
22:50:15op_null:bramc: they didn't at all.
22:50:22amiller:bramc, are you thinking of the oakland lottery paper
22:50:29amiller:they used OP_SIZE as a hack
22:50:47amiller:i doubt that's what you're talking about anyway, but that's the only surprise workaround for something related i know of
22:51:02bramc:Why is op_cat disabled? Did some num-nuts make a DOS by doubling up a string repeatedly?
22:51:10op_null:bramc: they published a list of hashed nonces, did something with TXID + nonce, and then paid out if the transaction was a winner. the hashed nonce would be revealed the next day to prove it was "fair".
22:51:19op_null:bramc: you've got it.
22:52:39op_null:bramc: nobody actually did it, but with the disabled opcodes you could blow up the stack and end up with scripts nobody in the network could verify due to their huge memory footprints.
22:53:27bramc:amiller, What do you do OP_SIZE on?
22:55:15amiller:lets say you wanted to do a two player rock-paper-scissors / lottery game
22:55:29bramc:right
22:55:31amiller:you can have each player pick a value 1 2 or 3 and commit to it by hashing it
22:55:46amiller:if you hash it directly though its easy to brute force
22:56:12amiller:you could do a 32 bit integer, since op_mod and the like operate on 32 bit integers but that's still sort-of easy to brute force or precompute
22:56:36amiller:so until this oakland paper came out, we had all given up making lottery games like that work.
22:57:16bramc:Got a link for the paper?
22:57:44amiller:https://eprint.iacr.org/2013/784.pdf
22:57:47amiller:best paper at Oakland 2014
22:58:20amiller:the amazing clever workaround they came up with is to pick a random string thats either 21, 22, or 23 bytes long
22:58:59amiller:it's too big to do op_mod 3 on, but you can recover a small number by doing op_size and op_sub 20
22:59:07amiller:great, huh?
23:00:24bramc:Well that's a cute hack for processing the reveal
23:01:10bramc:But how are we supposed to make it so that once we've committed our money the other side can't DOS us and not let us have it if they lose out of spite?
23:02:25bramc:it would be really handy if there was an OP_SUBSTRING
23:02:47bramc:and a OP_BLOCKID
23:03:03amiller:bramc, are you asking how you make sure that the other party doesn't just refuse to reveal anthing at all?
23:03:12bramc:that second one being given a block number, and it would return the hash of that particular block
23:03:15bramc:amiller, yes
23:03:18amiller:bramc, the answer is the same as with the tiernolan protocol, you use these hashlock commit things
23:04:11amiller:it's described well enough in the paper, there's also an earlier forum post by iddo that shows the same thing (except for not coming up with the op_size hack! https://bitcointalk.org/index.php?topic=277048.0 )
23:05:27waxwing__:waxwing__ is now known as waxwing
23:05:47bramc:Has anyone suggested adding an OP_BLOCKID which takes a block number and is timelocked until that block comes out? Doesn't seem like it hurts in any way, potentially useful for all kinds of stuff.
23:06:51amiller:bramc, sure, here's some OP_BLOCKHEIGHT / OP_DEPTH fuss http://sourceforge.net/p/bitcoin/mailman/message/31183644/
23:07:08op_null:bramc: you really don't want scripts that could be valid, get orphaned, and then become invalid.
23:07:33amiller:petertodd, is i think the only one who's trying to push something like that through
23:07:49op_null:bramc: wait, I misread what you were asking. ignore me.
23:08:27bramc:op_null, that's a bit inherent with gambling protocols, but also having a third party reveal of path to root
23:08:45bramc:so while I understand the point there might be useful anyway
23:09:13bramc:There's always the unavoidable form of invalidation that something could become a double spend on a reorg when it wasn't before
23:10:41phantomcircuit:op_null, it probably would have been better to limit the stack space instead of remove the op codes though
23:10:56phantomcircuit:or at least i think it would
23:11:00phantomcircuit:maybe im missing something there
23:12:56op_null:phantomcircuit: maybe, I don't know the rationale for it very well. I would have said to limit the space, but whatever, they're gone and they can't be enabled again.
23:13:01bramc:phantomcircuit, you can get an exponential blowup in the size of a string by repeatedly doubling it
23:13:48bramc:BIP 65 is for OP_CHECKTIMELOCKVERIFY which has a stronger case than the other stuff by far, anybody know the current status of that?
23:16:58op_null:I don't think anybody has any glaring issues with it at least
23:18:32phantomcircuit:bramc, so? you can easily calculate how much additional stack space you would be taking before using it
23:18:41gmaxwell:bramc: I expect it to go in with BIP62 in the next couple months. (and take a bit of time to reach saturation)
23:19:34bramc:phantomcircuit, Oh I see you're talking about the total size of everything on the stack rather than the number of things on the stack. Yeah, capping that could work.
23:19:55gmaxwell:(BIP62 also fixes the protocols with refunds, in another more limited way. So they're partially overlapping.)
23:20:24phantomcircuit:gmaxwell, any idea why those op codes were disabled instead of implementing a maximum stack size?
23:20:57phantomcircuit:or were those things which could be abused to make scripting turing complete?
23:21:48Luke-Jr:phantomcircuit: AFAIK none of the opcodes removed were intended to be permanent
23:22:04Luke-Jr:just a temporary thing to be reverted later on after testing
23:22:18gmaxwell:Luke-Jr: they were not disabled in a way that facilitated that, alas.
23:22:35Luke-Jr:gmaxwell: well, this was back when Satoshi did hardforks on his whim
23:22:45gmaxwell:phantomcircuit: because its surprisingly hard to be sure you got it right. e.g. if you only did that you'd still have failed from the leftshift memory corruption.
23:22:48Luke-Jr:(ok, maybe that's a bit exaggeratory)
23:22:57gmaxwell:Luke-Jr: thats untrue.
23:23:15gmaxwell:Changes made were all softforking.
23:23:35bramc:so there are string cats which are in the block chain?
23:23:53Luke-Jr:gmaxwell: in practice maybe, but I'm not sure if that was intentional
23:24:33op_null:bramc: I don't think so, no.
23:24:38gmaxwell:it very clearly was. E.g. how nlock overlays or how some of the changes triggered based on heights. It's hard to make things softforky.
23:24:57gmaxwell:bramc: There are not.
23:27:45gmaxwell:bramc: Your question was also a bit ambigious though I believe that the answer is the same: There could be scriptpubkeys with OP_CATs in them, but if so they could never be spent.. I don't think there are. And there cannot be any spend ones in the history at all, since they're invalid. Basically any "disabled" opcode is just not a feature of the system.
23:27:53phantomcircuit:i guess the scripting engine could be expanded by using one of the OP_NOP codes as an OP_EX_OPS and then just parse stack values as a new type of script
23:28:02gmaxwell:They were in there but they were disabled and ... consensus system... sooo.
23:28:18gmaxwell:phantomcircuit: Sure, and _we've done that_, p2sh effectively replaced the script system.
23:28:27gmaxwell:(though it replaced it with a hash-nested copy of itself)
23:28:36phantomcircuit:gmaxwell, yeah
23:28:38gmaxwell:Same mechenism can be used.
23:28:48Luke-Jr:gmaxwell: I don't recall any height-based things from back then..
23:29:09gmaxwell:Also OP_NOPs can be turned into OP_FOOVERIFY
23:29:39gmaxwell:Luke-Jr: e.g. defintion of locktime changed that way. A lot of stuff wasn't really discussed... so you have to go read the old code.
23:29:56bramc:How many utxos really go to script hashes these days?
23:30:47op_null:in total. 15770000 P2PKH, 145000 P2SH
23:30:57op_null:that's spent and unspent.
23:31:14bramc:huh, mostly satoshi dice probably
23:31:46op_null:and some pay to raw pubkey.
23:31:46Luke-Jr:bramc: SD shouldn't have many unspent..
23:32:03op_null:and 12,000 op_return outputs.
23:32:12bramc:Luke-Jr, Yeah the spent vastly outnumber the unspent
23:32:19op_null:and 215,000 raw multisig
23:32:42Luke-Jr:op_null: got stats on how many raw multisig are abused for data storage?
23:32:46bramc:I have mixed feelings about scripts. They're fun and interesting and all, but I'm not sure how relevant they are.
23:33:13op_null:Luke-Jr: no, I'll have to write a parser to see how many have junk pubkeys in them.
23:33:40Luke-Jr:op_null: that would be useful information to support making them non-IsStandard
23:34:02op_null:Luke-Jr: just looking through a filtered list almost all are abuse. in the last 40 only like 10 have decodable pubkeys.
23:34:37Luke-Jr:25% is annoyingly high in this case
23:34:46Luke-Jr:I wonder what's using them
23:34:49op_null:1c434e5452505254590000000000000000000000010000000253734d8000000000 = "CNTRPRTY"
23:35:21gmaxwell:op_null: spent and upspent is a little distorted... much better to look at the most recent blocks. since it's change a lot.
23:35:28Luke-Jr:op_null: I mean the legit ones
23:35:32bramc:by 'abuse', you mean people throwing crap into the block chain as a distributed storage system?
23:35:38Luke-Jr:bramc: yes
23:35:40op_null:yeah it's all counterparty. ballparking I would say 75% raw multisig are CNTRPRTY.
23:35:48Luke-Jr:bramc: or really anything where the keys aren't keys
23:36:04Luke-Jr:op_null: but what are the non-abusive ones?
23:36:14bramc:How do those get accepted by miners?
23:36:56phantomcircuit:bramc, they look like a normal multisig transaction
23:37:03Luke-Jr:bramc: spammers make it politically hard to get defaults changed, and most miners are neglegent at configuring their policies
23:37:04phantomcircuit:they just have bad signatures
23:37:28Luke-Jr:eg https://github.com/bitcoin/bitcoin/pull/5231
23:37:35gmaxwell:In any case, 4.6% of all bitcoins are in p2sh outputs.
23:39:04op_null:Luke-Jr: actually it's more like 90%+ are counterparty. there's one dude making lots of them spending outputs all from one address. couple of normal looking ones without anything interesting about them.
23:39:15gmaxwell:bramc: so script allows things like threshold multisignature (which see ^ is used and important) sort of worth it for that alone. But then you also have the potential for things like the atomic swaps, but as you see, it's currently underutilized (somewhat for technical reasons).
23:40:02bramc:Yes I'm sold on the utility of threshold multisignatures and hash preimages and locktimes
23:40:48gmaxwell:There are also a lot of usecases lost to things that were disabled; so e.g. the original potential was much better.
23:41:40op_null:Luke-Jr: here's a "normal" one, there's very few though. I'll scrape some proper stats at some point to find all the counterparty ones. d6bfbf12c247617e5d3f36f74d2d214fabff96a58f416472034db6879c6f6632
23:42:09bramc:Those things could all be supported with a much, much simpler scripting system
23:42:31Luke-Jr:bramc: only if someone thought of them in advance
23:42:56Luke-Jr:but now we need OP_X86VERIFY
23:43:12bramc:I assume that was a joke
23:43:15Luke-Jr::P
23:43:27op_null:Luke-Jr: OP_JAVASCRIPTVERIFY
23:43:31op_null:get with the times.
23:43:41Luke-Jr:op_null: that one's more horror than joke
23:44:08bramc:Extensibility is a bit different. All of the things I just said are individual checks and the requirement for a signature could be that any of a given set of subsets of the individual checks is a valid signature
23:44:19gmaxwell:bramc: only if you enumerate them in advance, which is a risky thing to try doing.
23:44:52bramc:You could allow the addition of new individual types of verifications without having a forth-like thing in there
23:45:05gmaxwell:bramc: We call that kind of criteria thresholding a monotone function. Classical signature criteria are montone functions.
23:45:33bramc:Granted that could always be extended by adding a new check which has forth built in, but most of the 'obvious' stuff remains very simple.
23:45:33gmaxwell:Yes you could, but there are things you cannot do... e.g. take this blocb verify it matches, check some criteria in it.
23:45:57gmaxwell:bramc: the redundancy there isn't necessarily great: more things to test and have consensus splits in.
23:47:08bramc:It's a tradeoff of where the complexity is. The existing system hasn't had a great record of allowing new functionality without also having new opcodes to at least help.
23:49:42bramc:I still need to read through coinswap and figure what exactly that needs
23:50:06gmaxwell:same thing as atomic swaps, fortunately. Plus multisig.
23:50:42op_null:Luke-Jr: it's worse than you think :(
23:50:57Luke-Jr:op_null: "worse" means "more legitimate use"
23:51:24op_null:Luke-Jr: I meant javascript crypto,
23:51:27Luke-Jr:o
23:51:37Luke-Jr:not sure it can get any worse than I think
23:54:55gmaxwell:bramc: In any case; ... the basic principle here is that if you create a decenteralized money but to do _anything_ interesting you have to hand it over to a trusted entity you're really not able to realize the value. The more that can be done without that, the more Bitcoin's value can be actualized. In theory. In reality we're not quite living up to that, but to some extent just showing the possibility is enough for now. e.g. people ...
23:55:01gmaxwell:... arn't using it yet, but the value of having a decenteralized currency is more obvious when you realize other things can be done.