01:06:37just[dead]:just[dead] is now known as justanotheruser
01:15:51warren:Trying to think of a name for an open source payment processing module we're writing.
01:16:17warren:Someone mentioned "Guantanamo Pay".
01:18:28d34th_:d34th_ is now known as d34th
01:57:55Emcy:hasnt the dogecoin joke gone on long enough
02:00:44amiller:LOL guantanamo pay.
02:18:31justanotheruser:justanotheruser is now known as just[dead]
03:07:00just[dead]:just[dead] is now known as justanotheruser
04:20:04jgarzik:warren, Guano Pay?
04:20:33c0rw1n:we have those. we call them shitcoins.
05:20:42Ademan_:Ademan_ is now known as Ademan
07:02:10justanotheruser:justanotheruser is now known as just[dead]
08:22:44just[dead]:just[dead] is now known as justanotheruser
08:32:54justanotheruser:andytoshi: Can I get the logs where we discuss how a decentralized coinjoin system using blind signatures would work?
09:22:55justanotheruser:justanotheruser is now known as just[dead]
11:07:00LarsLarsen:does LTC have developers here?
11:08:02LarsLarsen:I wanted to know if the source was worth looking at
11:08:13LarsLarsen:to learn about BTC (is it almost the same?)
11:08:24LarsLarsen:or is there some place I could look that has most of the ltc specific changes?
11:09:00LarsLarsen:aside from the obvious tweaks to the obvious bits
11:09:52LarsLarsen:or is it, as I suspect, unmaintained crap with just a few tweaks?
11:10:28LarsLarsen:I've mostly been looking at feature-coins, and not "actually used by people" coins
11:17:23epscy:LarsLarsen: supposedly LTC source is better than most altcoins
11:17:55epscy:LarsLarsen: apparently small stuff from the LTC source has been incorporated into the bitcoin source, but i don't know the details
11:32:38TD:TD is now known as hearn
12:21:38LarsLarsen:epscy: I need an abitrary non-bitcoin chain to test stuff with, so I figure I should use the SHITTY coin everyone cloned (a fork of litecoin from 12 months ago) just so my fixes can be patched against all the alts, but like... I dont care if they get pwned... so... maybe I should just do it for LTC since they seem to care about maintaining their shit
12:21:41LarsLarsen:so I'll do that, thanks
12:22:17LarsLarsen:all alts relay invalid transactions... is that a problem? ;)
12:22:41LarsLarsen:where do they keep those again? :)
12:22:56LarsLarsen:dude, if it overflows I'm fucking having a party
12:23:07LarsLarsen:you're all invited
12:31:41LarsLarsen:oooh, dust collection, neat
12:32:49LarsLarsen:epscy: it makes sense that LTC stuff would go into bitcoin, because this looks like he stole every innovation (implemented or not) intended for bitcoin, PLUS, he's fast and loose with updates
12:32:59LarsLarsen:so testing
12:33:26LarsLarsen:so everything he does probably drops into bitcoin with a simple merge and a headscratch
12:42:11[BNC]dansmith:[BNC]dansmith is now known as dansmith_btc
12:47:18epscy:yeah people have commented that because LTC is less valuable than BTC the LTC developers can be less conservative than the BTC developers (and the BTC developers are pretty conservative)
12:52:55LarsLarsen:I am going to be WILDLY IRRESPONSIBLE
12:53:37LarsLarsen:I'm playing out gmaxwell's idea of the producers, where a trader and a developer have to make a coin worth as little as possible because of some crazy futures contract, and they keep making it scammier and scammier, but the price keeps going up!
12:55:23LarsLarsen:actually I'm just testing it out and stuff... so I can do anything
13:54:05nikitab:nikitab is now known as nikitab__
14:10:44LarsLarsen:litecoin still has the word bitcoin in FILENAMES. Wow...
14:17:19LarsLarsen:I would like to do something with it, is there a way I can make it memory hard, and still secure the blocks? Like a forced nonce header?
14:18:20LarsLarsen:with say, a time-dependent rolling one time pad type hash of universally agreed upon blockchain data
14:18:30LarsLarsen:proving you have it
14:18:42LarsLarsen:or is that wildly insecure?
14:19:46LarsLarsen:also, is LTC compatable with parallel mining, and if not can I do parallel and force arbitrary memory hard searches to be included with the block (perhaps depending on the nonce itself as they twiddle it?)
14:20:02LarsLarsen:(merged mining)
14:20:14epscy:i don't think so
14:20:18LarsLarsen:why not?
14:20:35epscy:to be able to merge mine both chains have to be using the proof of work function
14:20:43LarsLarsen:which? the merged? or the forcing arbitrary nonce data (or really, header data at that point, thats whats hashed right?)
14:20:52LarsLarsen:not for bitcoin, not forltc, for altcoin testing
14:20:55epscy:bitcoin uses SHA256 and ltc uses scrcrypt
14:21:01LarsLarsen:no no no
14:21:06LarsLarsen:I mean, does LTC do merge
14:21:09LarsLarsen:with other scrypt
14:21:13LarsLarsen:or do I have to do that
14:21:22LarsLarsen:I know it must be supported by the coin itself
14:21:27LarsLarsen:I can google
14:21:32LarsLarsen:do you know much about it tho?
14:21:37LarsLarsen:in general
14:21:54epscy:i would have thought it was possible, but i haven't heard of merged scrypt mining
14:21:55LarsLarsen:ok, do you know anything about verifying arbitrary data in the header?
14:22:01epscy:no sorry
14:22:11LarsLarsen:can we reject any header without a nonce-prefix that doesn't match a criteria?
14:22:25LarsLarsen:ok, I'll find out :)
14:22:32LarsLarsen:one way to try, break it...
14:23:27pigeons:you can mine litecoin as the "parent" chain, and one or more of the few nasty scrypt clones that have the merged mine patch from namecoin as the "children"
14:25:13pigeons:they call some of the scrypt ones you can merged mine "united scrypt coin" and another is "orgcoin" if you want to test. they are ugly
14:27:11LarsLarsen:I want to make a non-currency chain on top of LTC
14:27:23LarsLarsen:that is mined with memory-hard mining by nodes with the full LTC blockchain
14:27:51LarsLarsen:and all it secures is stuff that nodes would find useful, databases and UTXO trees in all shapes and colors (I like btrees)
14:28:37LarsLarsen:just as an experiment
14:28:48LarsLarsen:so if it cant merge mine, I'm done before I start, so thanks :)
14:29:21LarsLarsen:is it that LTC has to support merge mining? OR that those weird alts have to support it, or both?
14:30:05LarsLarsen:lol, litecoin has just cut and pasted bitcoin-qt as is, didnt even rename anything...
14:30:06helo:LTC is the ~same as BTC in that regard, so just the alts afaik
14:30:14LarsLarsen:now I can understand doing that with BITCOIND
14:30:21LarsLarsen:but your qt client? wtf?
14:30:39helo:with ~no devs, what are they supposed to do?
14:30:47LarsLarsen:I do not know how BTC is as merged mining, I dont mine
14:30:53LarsLarsen:or what merged mining is
14:31:02LarsLarsen:I Asked today in bitcoin but we were in a moment of derp
14:31:09LarsLarsen:cause like, a release or something soon so the brains were gone
14:31:13helo:i used to understand it, but i forgot :/
14:31:29LarsLarsen:I assume you're still hashingone big thing
14:31:35LarsLarsen:and each is the nonce of the other block
14:31:43pigeons:apparently the way it is done is not how anyone would do it ;)
14:32:01LarsLarsen:ok I will cross that bridge when I come to it
14:32:06helo:try googling 'how does namecoin merge mining work'?
14:32:17LarsLarsen:now that I have helo here, do you know much about pow?
14:32:37LarsLarsen:could I use say, an arbitrary nonce header as part of the POW, like zeros plus you have to have this data
14:32:50helo:i know the merged coin has to be mined using the same algo as the parent coin
14:32:56LarsLarsen:as long as the network can agree completely on what that data is (like its a calculation)
14:34:12helo:for example, LTC could not be merge-mined with bitcoin
14:34:38LarsLarsen:so like, if you don't have the right difficulty, fuck you, if you ALSO dont have this data in the header, you're out (say, the current block number, or anything)
14:34:44helo:the trick with POW is that it is hard to compute, but easy for everyone to validate
14:35:12LarsLarsen:I understand that
14:35:22helo:so if you have a requirement that you include some data in a big database, all nodes would have to keep that database around to be able to validate the blocks
14:35:31helo:i.e. no SPV mode
14:35:34LarsLarsen:hrm... what I'm asking is... is it trivial in the code to test something about the header in the POW validation?
14:35:43LarsLarsen:other than the final hash and that it matches
14:35:59LarsLarsen:i.e. can I do this in 20 minutes
14:36:44helo:it will probably take many times that to understand how everything works enough to reasonably implement such a thing
14:37:38helo:the problem with most altcoins is that they didn't take the time to understand exactly why bitcoin does everything the way it does, so they open themselves up to big problems later on
14:37:42LarsLarsen:I understand that and I have a way to make it smaller than yours, so nyeah
14:37:47LarsLarsen:but not now
14:38:25LarsLarsen:what I want to do is a first step towards transaction as validation
14:38:42LarsLarsen:sorry, validation as pow (I'm up late)
14:38:54LarsLarsen:that first step being, pow that is memory hard
14:39:00LarsLarsen:against the blockchain of LTC
14:39:08LarsLarsen:(or an alt, whatever)
14:40:01helo:why not make it merge-mine-compatible with bitcoin?
14:40:16helo:you'll have the most security against reversal that way
14:40:34LarsLarsen:so, you'd have to grab a certain part of the blockchain, hash it, and include that with your nonce, so like, say I use block(mod(nonce))
14:40:41LarsLarsen:hashed, as the nonce prefix
14:40:47LarsLarsen:making you do a search for each try
14:40:52LarsLarsen:of it allll
14:41:10helo:that would require all nodes to store the entire blockchain so they could identify valid blocks
14:41:17LarsLarsen:thats the point
14:41:24LarsLarsen:well, I could do this on the pruned tree
14:41:29LarsLarsen:this is a proof of concept
14:41:48helo:that would probably hurt decentralization and completely rule out light nodes
14:41:53LarsLarsen:the relevant data of a full node is what I want it to search against
14:42:01LarsLarsen:dont give me currency practicalitites like no SPV
14:42:07LarsLarsen:this is not a currency, its just a method
14:42:09LarsLarsen:a theory
14:42:49LarsLarsen:like, you could mine against it to secure it so you can store big UTXO merkle's semi-secure so SPV nodes are fast as shit at querying ANY ADDRESS
14:43:02LarsLarsen:so I understand :) I hear yeah... I'm just doing a 20min hack
14:43:40LarsLarsen:it could give incentive to run a node
14:43:43LarsLarsen:what a concept
14:43:58LarsLarsen:gmaxwell: didn't you think this was an idea for an alt?
14:44:19LarsLarsen:gmaxwell: memory-hard against UTXO or against full chain?
14:45:06LarsLarsen:I'm not proposing that anyone use my code... at all
14:45:27LarsLarsen:but it may prove something, consider me a quality assurance test engingeer who's fucking with your codebase ;)
14:46:04LarsLarsen:and it lets me possibly get miners to test my stuff, without having to create an alt
14:46:59LarsLarsen:and may become a merge-mined chain with bitcoin for utility purposes for large businesses and people who want to do accounting who need that stuff anyway
14:47:24LarsLarsen:what a difference one secured hash makes!
14:48:15LarsLarsen:I'll gladly pay you tuesday for a single hash in the bitcoin block :)
14:49:21helo:the problem with merge-mining something with an alterntative proof-of-work is that the bitcoin nodes would have to do extra (presumably expensive) work to validate as 'dbcoin' blocks.
14:51:36helo:merged-mined and new-proof-of-work are mutually exclusive choices afaict
14:51:37wallet421:wallet421 is now known as wallet42
14:53:20helo:be warned, my brain is not working well on the two hours of sleep i got last night
14:55:28helo:i stayed up late pretending to be a gunsmith, and the job took a lot longer than i expected :/
15:07:39Kometes:Kometes has left #bitcoin-wizards
15:40:17weex_:weex_ is now known as weex
16:03:13LarsLarsen:helo: thats why the only practical implementation would be "validation as proof of work"
16:03:17LarsLarsen:not what I am testing now
16:03:46LarsLarsen:the current ideas along these lines are merge mined, which requires a token of value to be created
16:03:59LarsLarsen:which maybe could be spent to get nodes to do things like timestamp or oracle or something
16:04:09LarsLarsen:but thats putting the cart before the horse
16:04:34LarsLarsen:I figure, validation as proof of work is a great idea
16:04:47LarsLarsen:I just have no idea how to even think about it yet
16:04:48LarsLarsen:baby steps
16:06:08LarsLarsen:since nodes already do it, its great...
16:06:24LarsLarsen:and incentive to do it faster, improves bitcoin's ability to scale
16:06:41LarsLarsen:its all about incentive structures and tight feedback loops ;)
16:07:22maaku:just[dead]: you can look at the OP of the CJ thread...
16:10:25maaku:decentralized CJ using blind signatures is how it was originally described
16:23:13zooko`:zooko` is now known as zooko
16:37:07BlueMatt:lol "Satoshi Nakamoto (Resident of California)" key id 7B536415 signed my pgp key..........
17:01:00maaku:BlueMatt: did you get a retroactive signature from John Titor too?
17:01:14BlueMatt:nope, no john titor here
17:36:42LarsLarsen:I'm from the future, I'm here to warn you. Robots will kill us all.
17:37:58sipa:not here please
17:56:00comboy:* comboy resists for a few minutes but the urge to share the link is too strong http://www.youtube.com/watch?v=WGoi1MSGu64
17:56:19comboy:I'm sorry, kind of
17:58:47zooko:* zooko successfully resists the urge to follow the link
17:58:51maaku:comboy: Do not worry. I will keep you warm and safe in my people-zoo. https://www.youtube.com/watch?v=-hW2vhkCOFc
17:59:02zooko:* zooko resists again
18:05:02comboy:maaku: :)) thank you, you're a good robot
18:06:51zooko:zooko has left #bitcoin-wizards
18:10:13Guest50846:Guest50846 is now known as kaptah
19:09:16maaku:wizards, anyone versed in graph theory know an efficient algorithm for choosing the best connection to make, in the interest of improving connectivity?
19:43:07Emcy:depends what improving connectivity means?
19:45:36tacotime:yeah, that's what i was gonna ask; obviously it's easy to find the shortest path given a graphs and two nodes with variable distance vertices, but i'm guessing setting up the metric for distance is the difficult part.
19:46:24tacotime:err between two vertices and variable length edges
19:47:37gmaxwell:tacotime: just assume all edges have weight 1. The greedy thing to do is to add an edge to the furthest point, but I'm reasonably confident that this isn't the globally optimal thing to do.
19:49:09gmaxwell:Emcy: connectivity probably means minimizing the mean (arithemetic, geometric, or some other metric) of the shortest paths between all pairs of nodes.
19:50:18Emcy:thats a good thing to optimise for
19:50:42gmaxwell:maaku also, I assume, wants an incremental algorithim, where nodes will be added later. I think this bounds how optimal you can be.
19:52:30gmaxwell:maaku: http://www.cs.ucla.edu/~awm/papers/APPROX09-NoC.pdf
19:52:47maaku:thanks gmaxwell
19:54:01maaku:Emcy: the context is adding skiplist back-links that are enforced by soft-fork rules
19:54:15maaku:in order to support compact/compressed SPV-proofs
19:55:57Emcy:i cannot even postulate as to what that means
19:56:32gmaxwell:http://www.optimization-online.org/DB_FILE/2013/01/3752.pdf also has reasonable citations too
19:57:02maaku:Emcy: ok, imagine for a moment that we commit to the coinbase a merkle root of every single block header, all the way back to genesis
19:57:57maaku:then when a block gets particularly lucky (say, pow <= nTarget/4), we can use those back links in an SPV proof without loss of security (in this case, we can skip back 4 blocks)
19:58:00Emcy:root hash yes?
19:58:15maaku:the root of the merkle tree, yes
19:58:50maaku:this gets you logorithmic spv proof size
19:59:13maaku:do you follow so far?
19:59:55gmaxwell:Emcy: it means someone can show you a small amount of data ending in a particular block, what the total expected work of that chain is, precisely, without you having to inspect all the block headers yourself.
19:59:58maaku:gmaxwell: thanks, these look to be good papers
20:00:47Emcy:ok thats good enough for me thanks
20:01:39Emcy:this is to make SPVs more trustworthy
20:01:50maaku:eh, same trust level, but less size
20:02:01maaku:you don't have to download all the block headers
20:02:13maaku:to achieve the same security (for some applications) as if you had
20:02:43Emcy:is the header download req. considered that onerous already?
20:03:14gmaxwell:maaku: a general structure I was thinking about— the idea before where I only cared about reaching the genesis was that I'd select edges by considering a number of window sizes (number of blocks back I look), and for each window size I pick the block back with the shortest path to the genesis. If the result at this window is no better than the result at the smallest window, I leave it out. ... instead, I could replace it with a ...
20:03:20gmaxwell:... shortcut to a difficult to reach block, but I didn't have an efficient algorithim for selecting one. I believe that 'determinstic-random' is not terrible however.
20:03:40maaku:for some applications. such as two-way pegging, or knowing which purported chain is actually most work before you download it,
20:03:41gmaxwell:Emcy: not for normal spv nodes, but there are dos attacks and other applications where you need a small spv proov.
20:04:32gmaxwell:e.g. if there are many malicious nodes on the network, and you connect to them to download headers, and they just send you an infinite sea of difficulty 1 headers that never ends, you'll never sync up (true for SPV or full nodes)
20:04:56gmaxwell:if instead the give you a compact proof that the chain they're talking about has a specified amount of work, they can't perform that attack.
20:05:41maaku:gmaxwell: yeah, i want to try a perfectly optimal solution at least to see if that gives insight into what the tradeoffs are of a more performant solution
20:05:44gmaxwell:Or say you want to create a transaction that proves something exists in another blockchain. You really don't want your transaction to have to contain 290462 80-byte headers.
20:05:46Emcy:could this be used to do away with checkpointing?
20:06:10Emcy:or reduce checkpointing frequency or something
20:06:11gmaxwell:Emcy: headers first alone mostly removes the need... but this would make that better still.
20:07:55ielo:ielo has left #bitcoin-wizards
20:08:10torsthaldo:torsthaldo has left #bitcoin-wizards
20:18:24maaku:gmaxwell: to confirm, the idealized metric would be to minimize the number of hops from the current most-work block to every past block, correct?
20:28:09gmaxwell:There is a question of what mean you use. E.g. are costs [8,12,3,7], [9,8,7,7], [8,8,8,8] better? Each of these is the best for l_1 norm, l_2 norm, and l_infinity norm respectively.
20:28:39gmaxwell:(sum of values, sum of squares, maximum)
20:29:14gmaxwell:I think for most things we think about, l_infinity is actually the most interesting "minimize the worst case proof". Sometimes it results in easier computation too.
20:30:01gmaxwell:e.g. because adding an edge can't increase lengths, so adding an edge to the current worst case is always the l_infinity decreasing solution (ignoring ties).
20:39:26maaku:i see
20:44:48kanzure:gmaxwell: re: #3862 microbtc unitizing and "other downside is that by keeping the point you guarantee that people will continue to write financial software using radix-2 floating point and getting bad and or surprising results";
20:44:58kanzure:gmaxwell: what about having a set of recommended tests from the bitcoin project
20:45:23kanzure:gmaxwell: just basic math that should be obvious to anyone with a brain, maybe a provided text file of test data for people to check against, etc.
20:45:52kanzure:i know it sounds stupid, but people messing up their money data types is even more stupid :)
20:46:25maaku:kanzure: using floating point for accounting has been a bad idea since floating point was invented. that hasn't stopped people from doing so
20:51:01gmaxwell:kanzure: dude, never again mention that issue in this channel if you want to stay in the channel. jesus. If you have some way to suggest creating tests for unspecified user applications go create them. Sounds fine.
20:52:55jrmithdobbs:is it weekly i don't understand floating point time? =/
20:52:58Ademan:wait, a third party used IEEE floating point numbers for calculations?! hahahahaha
20:53:16Ademan:how many times does this lesson have to be learned?...
20:53:53maaku:Ademan: well, if only there were precise and standards-compliant decimal64 implementations...
20:54:12jrmithdobbs:it's fine to do if you understand the limitations (eg, while annoying bitcoin putting them in ieee fp numbers for the json-rpc is a-ok)
20:54:29Ademan:maaku: I don't know if you're being sarcastic or not because I don't know if there's any standard fixed point formats heh
20:54:44jrmithdobbs:Ademan: then you're not qualified to be commenting.
20:54:48jrmithdobbs:no offense
20:55:29Ademan:jrmithdobbs: I understand the behavior of IEEE floating point numbers, and am familiar with fixed point implementations, I'm not sure how specific knowledge of a standard is relevant
20:56:24jrmithdobbs:Ademan: there's at least 2 representations that are obvious and obviously standard (BE vs LE) ...
20:56:26maaku:Ademan: a signaling decimal64 type would be safe and performant to use in specific ways for financial applications
20:57:22maaku:unfortunately (1) standards-compliant hardware implementations do not exist, and (2) you're taking an unsafe gamble that the OS, compiler, and software stack aren't undoing various mode sets you need to stay safe
20:57:34maaku:so useless in practice, unfortunately
20:57:57tacotime:kimoto gravity well uses double for difficulty calculations too :)
20:58:05tacotime:fork all of the alts
20:59:50maaku:it's probably fine because of the truncation of nBits, but eventually something will round differently on different platforms resulting in a consensus fork
21:02:45Ademan:jrmithdobbs: ? endianness would be the least interesting consideration in specifying a decimal representation, or am I misunderstanding you?
21:04:58kanzure:gmaxwell: okay, understood
21:14:54Kometes:anyone got their hands on the von neumann zk-snarks system yet?
21:18:44Ademan:gmaxwell: is your GPG fingerprint DE47 BC9E 6D2D A6B0 2DC6 10B1 AC85 9362 B041 3BFA ?
21:19:06helo:helo is now known as the_tiger
21:19:14LarsLarsen:I can haz snarks?
21:19:20the_tiger:the_tiger is now known as helo
21:20:58helo:Ademan: that's what i have
21:21:13helo:(the fingerprint, not sharks)
21:21:21Ademan:haha, also thanks helo
21:25:08gmaxwell:Ademan: yes.
21:29:48Ademan:now I just have to make sure you're not being coerced by the NSA to give out the wrong key and that your connection to freenode hasn't been MITMed /s
21:30:06gmaxwell:freenode security is lol
21:33:59sipa:now you're just jumping the snark
21:40:22Emcy:hrm speaking of nsa specifically targetting nerds and hacker types https://blog.ageispolis.net/foxacid-at-hope9/
21:40:46Emcy:looks like they probably used bitcoin as bait to target specifically target people at a hacker conf
22:00:26nikitab_:nikitab_ is now known as nikitab__
22:11:03just[dead]:just[dead] is now known as justanotheruser
22:11:14justanotheruser:It looks like Darkcoin has implemented a coinjoin with blind signatures https://bitcointalk.org/index.php?topic=421615.msg5693650#msg5693650
22:13:58tacotime:Has the author open sourced it yet?
22:14:27justanotheruser:no idea
22:14:42tacotime:I was trying to look at the code the other day and it didn't exist :/
22:18:45Ademan:"run our code, trust us!"
22:22:38adam3us:so another idea towards making committed transactions SPV compatible without snarks:
22:23:24adam3us:you commit (encrypt a transaction with a key chosen in such a way that it can be assured to be non-double-spent in relation to the not yet publicly disclosed input)
22:23:59adam3us:then you decommit (publish the key in a reliable way so that it is relatively implausible that you didnt not receive it or could not obtain it).
22:24:36adam3us:actually first step the miners mine the committed transaction with limited validation (just asserting that it has not been double spent). there is a clear text fee, but the input, output and amount is hidden)
22:25:42adam3us:then its decommitted, then miners do a second validation (that the input exists (they already know the input is not double spent), and that inputs addup to the outputs) and publish the key k if they agree in a later block
22:27:13adam3us:now before it had been supposed that a miner would simply refuse to mine the key if they wish to censor the tx. so the new rule which maybe prevents that: miners are free to not mine keys for invalid txes, and full nodes can validate that (or the miner can prove the tx is invalid.. ie publish the key but with a statement that the tx is invalid).
22:28:17adam3us:the miners are given a deadline by which to either approve the tx or disapprove it; but they are not allowed to disapprove it if it is valid. and if they decline to do either past the deadline, then their blocks are considered invalid.
22:28:54gmaxwell:so I commit something and then just never reveal my key.
22:30:00adam3us:then the final thing is miners want to apply policy. so then we can say each block includes a serialization for some miner policy (an encoding of isStandard) and someone mining a decommitted version must apply the same policy as that chosen by the person who mined the committed form.
22:30:06justanotheruser:justanotheruser is now known as just[dead]
22:33:34adam3us:well if the key is broadcast to full nodes, they know the key exists or not. the clock on must publish by block #n doesnt start from their perspective until they have seen the key.
22:35:01adam3us:in that way (if that last bit actually works for game theory or can be tweaked to work) you get fungibility / irrevocability improvement independent from privacy
22:35:07gmaxwell:now say I publish the key at time deadline minus 1ms. Now some fraction of the nodes know the key exists, the rest do not.
22:35:14gmaxwell:and the network partitions
22:36:07gmaxwell:maybe you can make it work with a block tiebreaker though, e.g. prefer the block with the most coin days destroyed revelations with the age of a revelation based on how long you knew the key yourself?
22:38:50just[dead]:just[dead] is now known as justanotheruser
22:42:04adam3us:its hard to prove the network should reasonably have known the key because its widely available without having hashrate yourself. already the original block is a commitment to the key (as well as the transaction) and the key can be validated against it. but its hard to prevent second stage censorship. they know the key, have the majority of hash rate and what they decrypt is a transaction they want to censor. unless
22:44:28adam3us:gmaxwell: oh maybe you meant you bury a committed version of the key in subsequent blocks, then people who dont know what you burried mine on top, and then you have a high work factor proving a time stamp where the key was known by someone. but i guess you can do that already with respect to the original commitment.
22:47:55gmaxwell:well thats why I suggested it as a consensus tiebreaker. basically you give miners who include proofs you've known about for a long time an advantage. Though this can't help if the censors have >50% hashpower.
22:52:47adam3us:if there's much definitional mining advantage from knowing the key, a miner could publish his own committed tx, and commitment to the key, and keep the key secret to game the incentive to acknowledge the existence of the key
22:53:50gmaxwell:I'm one step ahead of you.
22:54:17gmaxwell:"prefer the block with the most coin days destroyed revelations with the age of a revelation based on how long you knew the key yourself"
22:54:22gmaxwell:lemme try to decode.
22:54:43gmaxwell:Blocks have a score used for tie breaking. The score is based on revealed keys in the block
22:54:58gmaxwell:You compute the score based on how long you've personally known about the particular keys being revealed.
22:55:21gmaxwell:e.g. 1 point for 1 day, 2 points for 2 days.. etc. So if the miner hides them, he gets hardly any points at all.
22:58:37adam3us:ok. how about if valid decommitted transactions are not affected by reorgs so the mining majority cant disavow them by reorging them when the non censoring 25% reveals the key
22:59:05justanotheruser:justanotheruser is now known as just[dead]
22:59:58gmaxwell:I don't know how they could be not affected though...
23:01:30adam3us:so tiebreaking presumaby that has to be by miners. no one else's views affect consensus. so that only works for < 50% censors. which already is uncensorable
23:02:45gmaxwell:yes, well, degress of censorship.
23:17:38just[dead]:just[dead] is now known as justanotheruser
23:32:33justanotheruser:justanotheruser is now known as just[dead]
23:56:21luke-jr_:luke-jr_ is now known as Luke-Jr