| 00:57:49 | pigeons: | @ |
| 01:06:37 | just[dead]: | just[dead] is now known as justanotheruser |
| 01:15:51 | warren: | Trying to think of a name for an open source payment processing module we're writing. |
| 01:16:17 | warren: | Someone mentioned "Guantanamo Pay". |
| 01:18:28 | d34th_: | d34th_ is now known as d34th |
| 01:57:55 | Emcy: | hasnt the dogecoin joke gone on long enough |
| 02:00:44 | amiller: | LOL guantanamo pay. |
| 02:18:31 | justanotheruser: | justanotheruser is now known as just[dead] |
| 03:07:00 | just[dead]: | just[dead] is now known as justanotheruser |
| 04:20:04 | jgarzik: | warren, Guano Pay? |
| 04:20:33 | c0rw1n: | we have those. we call them shitcoins. |
| 05:20:42 | Ademan_: | Ademan_ is now known as Ademan |
| 07:02:10 | justanotheruser: | justanotheruser is now known as just[dead] |
| 08:22:44 | just[dead]: | just[dead] is now known as justanotheruser |
| 08:32:54 | justanotheruser: | andytoshi: Can I get the logs where we discuss how a decentralized coinjoin system using blind signatures would work? |
| 09:22:55 | justanotheruser: | justanotheruser is now known as just[dead] |
| 11:07:00 | LarsLarsen: | does LTC have developers here? |
| 11:08:02 | LarsLarsen: | I wanted to know if the source was worth looking at |
| 11:08:13 | LarsLarsen: | to learn about BTC (is it almost the same?) |
| 11:08:24 | LarsLarsen: | or is there some place I could look that has most of the ltc specific changes? |
| 11:09:00 | LarsLarsen: | aside from the obvious tweaks to the obvious bits |
| 11:09:52 | LarsLarsen: | or is it, as I suspect, unmaintained crap with just a few tweaks? |
| 11:09:53 | LarsLarsen: | lol |
| 11:10:28 | LarsLarsen: | I've mostly been looking at feature-coins, and not "actually used by people" coins |
| 11:17:23 | epscy: | LarsLarsen: supposedly LTC source is better than most altcoins |
| 11:17:55 | epscy: | LarsLarsen: apparently small stuff from the LTC source has been incorporated into the bitcoin source, but i don't know the details |
| 11:32:38 | TD: | TD is now known as hearn |
| 12:21:38 | LarsLarsen: | 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:41 | LarsLarsen: | so I'll do that, thanks |
| 12:22:17 | LarsLarsen: | all alts relay invalid transactions... is that a problem? ;) |
| 12:22:41 | LarsLarsen: | where do they keep those again? :) |
| 12:22:56 | LarsLarsen: | dude, if it overflows I'm fucking having a party |
| 12:23:07 | LarsLarsen: | you're all invited |
| 12:31:41 | LarsLarsen: | oooh, dust collection, neat |
| 12:32:49 | LarsLarsen: | 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:59 | LarsLarsen: | so testing |
| 12:33:26 | LarsLarsen: | 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:18 | epscy: | 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:46 | LarsLarsen: | *nods* |
| 12:52:55 | LarsLarsen: | I am going to be WILDLY IRRESPONSIBLE |
| 12:53:37 | LarsLarsen: | 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:53:39 | LarsLarsen: | :) |
| 12:53:40 | LarsLarsen: | lol |
| 12:55:23 | LarsLarsen: | actually I'm just testing it out and stuff... so I can do anything |
| 13:54:05 | nikitab: | nikitab is now known as nikitab__ |
| 14:10:44 | LarsLarsen: | litecoin still has the word bitcoin in FILENAMES. Wow... |
| 14:17:19 | LarsLarsen: | 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:20 | LarsLarsen: | with say, a time-dependent rolling one time pad type hash of universally agreed upon blockchain data |
| 14:18:30 | LarsLarsen: | proving you have it |
| 14:18:42 | LarsLarsen: | or is that wildly insecure? |
| 14:19:46 | LarsLarsen: | 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:02 | LarsLarsen: | (merged mining) |
| 14:20:14 | epscy: | i don't think so |
| 14:20:18 | LarsLarsen: | why not? |
| 14:20:35 | epscy: | to be able to merge mine both chains have to be using the proof of work function |
| 14:20:43 | LarsLarsen: | which? the merged? or the forcing arbitrary nonce data (or really, header data at that point, thats whats hashed right?) |
| 14:20:52 | LarsLarsen: | not for bitcoin, not forltc, for altcoin testing |
| 14:20:55 | epscy: | bitcoin uses SHA256 and ltc uses scrcrypt |
| 14:21:01 | LarsLarsen: | no no no |
| 14:21:01 | epscy: | scrypt |
| 14:21:06 | LarsLarsen: | I mean, does LTC do merge |
| 14:21:09 | LarsLarsen: | with other scrypt |
| 14:21:13 | LarsLarsen: | or do I have to do that |
| 14:21:13 | epscy: | oh |
| 14:21:22 | LarsLarsen: | I know it must be supported by the coin itself |
| 14:21:27 | LarsLarsen: | I can google |
| 14:21:32 | LarsLarsen: | do you know much about it tho? |
| 14:21:36 | epscy: | no |
| 14:21:37 | LarsLarsen: | in general |
| 14:21:54 | epscy: | i would have thought it was possible, but i haven't heard of merged scrypt mining |
| 14:21:55 | LarsLarsen: | ok, do you know anything about verifying arbitrary data in the header? |
| 14:22:01 | epscy: | no sorry |
| 14:22:11 | LarsLarsen: | can we reject any header without a nonce-prefix that doesn't match a criteria? |
| 14:22:16 | LarsLarsen: | lol |
| 14:22:25 | LarsLarsen: | ok, I'll find out :) |
| 14:22:32 | LarsLarsen: | one way to try, break it... |
| 14:23:27 | pigeons: | 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:13 | pigeons: | 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:11 | LarsLarsen: | I want to make a non-currency chain on top of LTC |
| 14:27:23 | LarsLarsen: | that is mined with memory-hard mining by nodes with the full LTC blockchain |
| 14:27:51 | LarsLarsen: | 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:37 | LarsLarsen: | just as an experiment |
| 14:28:48 | LarsLarsen: | so if it cant merge mine, I'm done before I start, so thanks :) |
| 14:29:21 | LarsLarsen: | is it that LTC has to support merge mining? OR that those weird alts have to support it, or both? |
| 14:30:05 | LarsLarsen: | lol, litecoin has just cut and pasted bitcoin-qt as is, didnt even rename anything... |
| 14:30:06 | helo: | LTC is the ~same as BTC in that regard, so just the alts afaik |
| 14:30:14 | LarsLarsen: | now I can understand doing that with BITCOIND |
| 14:30:21 | LarsLarsen: | but your qt client? wtf? |
| 14:30:39 | helo: | with ~no devs, what are they supposed to do? |
| 14:30:47 | LarsLarsen: | I do not know how BTC is as merged mining, I dont mine |
| 14:30:53 | LarsLarsen: | or what merged mining is |
| 14:31:02 | LarsLarsen: | I Asked today in bitcoin but we were in a moment of derp |
| 14:31:09 | LarsLarsen: | cause like, a release or something soon so the brains were gone |
| 14:31:13 | helo: | i used to understand it, but i forgot :/ |
| 14:31:29 | LarsLarsen: | I assume you're still hashingone big thing |
| 14:31:35 | LarsLarsen: | and each is the nonce of the other block |
| 14:31:43 | pigeons: | apparently the way it is done is not how anyone would do it ;) |
| 14:31:52 | LarsLarsen: | lol |
| 14:32:01 | LarsLarsen: | ok I will cross that bridge when I come to it |
| 14:32:06 | helo: | try googling 'how does namecoin merge mining work'? |
| 14:32:14 | helo: | *merged |
| 14:32:17 | LarsLarsen: | now that I have helo here, do you know much about pow? |
| 14:32:29 | helo: | some |
| 14:32:37 | LarsLarsen: | could I use say, an arbitrary nonce header as part of the POW, like zeros plus you have to have this data |
| 14:32:50 | helo: | i know the merged coin has to be mined using the same algo as the parent coin |
| 14:32:56 | LarsLarsen: | as long as the network can agree completely on what that data is (like its a calculation) |
| 14:34:12 | helo: | for example, LTC could not be merge-mined with bitcoin |
| 14:34:38 | LarsLarsen: | 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:44 | helo: | the trick with POW is that it is hard to compute, but easy for everyone to validate |
| 14:35:12 | LarsLarsen: | I understand that |
| 14:35:22 | helo: | 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:31 | helo: | i.e. no SPV mode |
| 14:35:34 | LarsLarsen: | hrm... what I'm asking is... is it trivial in the code to test something about the header in the POW validation? |
| 14:35:43 | LarsLarsen: | other than the final hash and that it matches |
| 14:35:59 | LarsLarsen: | i.e. can I do this in 20 minutes |
| 14:36:44 | helo: | it will probably take many times that to understand how everything works enough to reasonably implement such a thing |
| 14:37:38 | helo: | 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:42 | LarsLarsen: | I understand that and I have a way to make it smaller than yours, so nyeah |
| 14:37:47 | LarsLarsen: | but not now |
| 14:37:48 | LarsLarsen: | lol |
| 14:38:25 | LarsLarsen: | what I want to do is a first step towards transaction as validation |
| 14:38:42 | LarsLarsen: | sorry, validation as pow (I'm up late) |
| 14:38:54 | LarsLarsen: | that first step being, pow that is memory hard |
| 14:39:00 | LarsLarsen: | against the blockchain of LTC |
| 14:39:08 | LarsLarsen: | (or an alt, whatever) |
| 14:40:01 | helo: | why not make it merge-mine-compatible with bitcoin? |
| 14:40:16 | helo: | you'll have the most security against reversal that way |
| 14:40:34 | LarsLarsen: | 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:41 | LarsLarsen: | hashed, as the nonce prefix |
| 14:40:47 | LarsLarsen: | making you do a search for each try |
| 14:40:52 | LarsLarsen: | of it allll |
| 14:41:10 | helo: | that would require all nodes to store the entire blockchain so they could identify valid blocks |
| 14:41:17 | LarsLarsen: | thats the point |
| 14:41:24 | LarsLarsen: | well, I could do this on the pruned tree |
| 14:41:29 | LarsLarsen: | this is a proof of concept |
| 14:41:48 | helo: | that would probably hurt decentralization and completely rule out light nodes |
| 14:41:53 | LarsLarsen: | the relevant data of a full node is what I want it to search against |
| 14:42:01 | LarsLarsen: | dont give me currency practicalitites like no SPV |
| 14:42:07 | LarsLarsen: | this is not a currency, its just a method |
| 14:42:09 | LarsLarsen: | a theory |
| 14:42:49 | LarsLarsen: | 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:42:50 | LarsLarsen: | :) |
| 14:43:02 | LarsLarsen: | so I understand :) I hear yeah... I'm just doing a 20min hack |
| 14:43:40 | LarsLarsen: | it could give incentive to run a node |
| 14:43:43 | LarsLarsen: | what a concept |
| 14:43:58 | LarsLarsen: | gmaxwell: didn't you think this was an idea for an alt? |
| 14:44:19 | LarsLarsen: | gmaxwell: memory-hard against UTXO or against full chain? |
| 14:45:06 | LarsLarsen: | I'm not proposing that anyone use my code... at all |
| 14:45:27 | LarsLarsen: | but it may prove something, consider me a quality assurance test engingeer who's fucking with your codebase ;) |
| 14:46:04 | LarsLarsen: | and it lets me possibly get miners to test my stuff, without having to create an alt |
| 14:46:06 | LarsLarsen: | blech |
| 14:46:59 | LarsLarsen: | 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:24 | LarsLarsen: | what a difference one secured hash makes! |
| 14:48:15 | LarsLarsen: | I'll gladly pay you tuesday for a single hash in the bitcoin block :) |
| 14:49:21 | helo: | 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:36 | helo: | merged-mined and new-proof-of-work are mutually exclusive choices afaict |
| 14:51:37 | wallet421: | wallet421 is now known as wallet42 |
| 14:53:20 | helo: | be warned, my brain is not working well on the two hours of sleep i got last night |
| 14:55:28 | helo: | i stayed up late pretending to be a gunsmith, and the job took a lot longer than i expected :/ |
| 15:07:39 | Kometes: | Kometes has left #bitcoin-wizards |
| 15:40:17 | weex_: | weex_ is now known as weex |
| 16:03:13 | LarsLarsen: | helo: thats why the only practical implementation would be "validation as proof of work" |
| 16:03:17 | LarsLarsen: | not what I am testing now |
| 16:03:46 | LarsLarsen: | the current ideas along these lines are merge mined, which requires a token of value to be created |
| 16:03:59 | LarsLarsen: | which maybe could be spent to get nodes to do things like timestamp or oracle or something |
| 16:04:09 | LarsLarsen: | but thats putting the cart before the horse |
| 16:04:34 | LarsLarsen: | I figure, validation as proof of work is a great idea |
| 16:04:47 | LarsLarsen: | I just have no idea how to even think about it yet |
| 16:04:48 | LarsLarsen: | baby steps |
| 16:06:08 | LarsLarsen: | since nodes already do it, its great... |
| 16:06:24 | LarsLarsen: | and incentive to do it faster, improves bitcoin's ability to scale |
| 16:06:41 | LarsLarsen: | its all about incentive structures and tight feedback loops ;) |
| 16:07:22 | maaku: | just[dead]: you can look at the OP of the CJ thread... |
| 16:10:25 | maaku: | decentralized CJ using blind signatures is how it was originally described |
| 16:23:13 | zooko`: | zooko` is now known as zooko |
| 16:37:07 | BlueMatt: | lol "Satoshi Nakamoto (Resident of California)" key id 7B536415 signed my pgp key.......... |
| 17:01:00 | maaku: | BlueMatt: did you get a retroactive signature from John Titor too? |
| 17:01:14 | BlueMatt: | nope, no john titor here |
| 17:36:42 | LarsLarsen: | I'm from the future, I'm here to warn you. Robots will kill us all. |
| 17:37:58 | sipa: | not here please |
| 17:56:00 | comboy: | * 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:19 | comboy: | I'm sorry, kind of |
| 17:58:47 | zooko: | * zooko successfully resists the urge to follow the link |
| 17:58:51 | maaku: | comboy: Do not worry. I will keep you warm and safe in my people-zoo. https://www.youtube.com/watch?v=-hW2vhkCOFc |
| 17:59:02 | zooko: | * zooko resists again |
| 18:05:02 | comboy: | maaku: :)) thank you, you're a good robot |
| 18:06:51 | zooko: | zooko has left #bitcoin-wizards |
| 18:10:13 | Guest50846: | Guest50846 is now known as kaptah |
| 19:09:16 | maaku: | 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:07 | Emcy: | depends what improving connectivity means? |
| 19:45:36 | tacotime: | 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:24 | tacotime: | err between two vertices and variable length edges |
| 19:47:37 | gmaxwell: | 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:09 | gmaxwell: | Emcy: connectivity probably means minimizing the mean (arithemetic, geometric, or some other metric) of the shortest paths between all pairs of nodes. |
| 19:50:18 | Emcy: | thats a good thing to optimise for |
| 19:50:42 | gmaxwell: | 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:30 | gmaxwell: | maaku: http://www.cs.ucla.edu/~awm/papers/APPROX09-NoC.pdf |
| 19:52:47 | maaku: | thanks gmaxwell |
| 19:54:01 | maaku: | Emcy: the context is adding skiplist back-links that are enforced by soft-fork rules |
| 19:54:15 | maaku: | in order to support compact/compressed SPV-proofs |
| 19:55:57 | Emcy: | i cannot even postulate as to what that means |
| 19:56:32 | gmaxwell: | http://www.optimization-online.org/DB_FILE/2013/01/3752.pdf also has reasonable citations too |
| 19:57:02 | maaku: | 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:57 | maaku: | 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:00 | Emcy: | root hash yes? |
| 19:58:15 | maaku: | the root of the merkle tree, yes |
| 19:58:50 | maaku: | this gets you logorithmic spv proof size |
| 19:59:13 | maaku: | do you follow so far? |
| 19:59:55 | gmaxwell: | 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:58 | maaku: | gmaxwell: thanks, these look to be good papers |
| 20:00:47 | Emcy: | ok thats good enough for me thanks |
| 20:01:39 | Emcy: | this is to make SPVs more trustworthy |
| 20:01:50 | maaku: | eh, same trust level, but less size |
| 20:02:01 | maaku: | you don't have to download all the block headers |
| 20:02:12 | Emcy: | damn |
| 20:02:13 | maaku: | to achieve the same security (for some applications) as if you had |
| 20:02:43 | Emcy: | is the header download req. considered that onerous already? |
| 20:03:14 | gmaxwell: | 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:20 | gmaxwell: | ... 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:40 | maaku: | for some applications. such as two-way pegging, or knowing which purported chain is actually most work before you download it, |
| 20:03:41 | gmaxwell: | Emcy: not for normal spv nodes, but there are dos attacks and other applications where you need a small spv proov. |
| 20:03:54 | gmaxwell: | proof* |
| 20:04:32 | gmaxwell: | 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:56 | gmaxwell: | 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:29 | Emcy: | hmm |
| 20:05:41 | maaku: | 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:44 | gmaxwell: | 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:46 | Emcy: | could this be used to do away with checkpointing? |
| 20:06:10 | Emcy: | or reduce checkpointing frequency or something |
| 20:06:11 | gmaxwell: | Emcy: headers first alone mostly removes the need... but this would make that better still. |
| 20:06:41 | Emcy: | groovy |
| 20:07:55 | ielo: | ielo has left #bitcoin-wizards |
| 20:08:10 | torsthaldo: | torsthaldo has left #bitcoin-wizards |
| 20:18:24 | maaku: | 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:09 | gmaxwell: | 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:39 | gmaxwell: | (sum of values, sum of squares, maximum) |
| 20:29:14 | gmaxwell: | 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:01 | gmaxwell: | 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:26 | maaku: | i see |
| 20:44:48 | kanzure: | 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:58 | kanzure: | gmaxwell: what about having a set of recommended tests from the bitcoin project |
| 20:45:23 | kanzure: | 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:52 | kanzure: | i know it sounds stupid, but people messing up their money data types is even more stupid :) |
| 20:46:25 | maaku: | 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:01 | gmaxwell: | 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:55 | jrmithdobbs: | is it weekly i don't understand floating point time? =/ |
| 20:52:58 | Ademan: | wait, a third party used IEEE floating point numbers for calculations?! hahahahaha |
| 20:53:16 | Ademan: | how many times does this lesson have to be learned?... |
| 20:53:53 | maaku: | Ademan: well, if only there were precise and standards-compliant decimal64 implementations... |
| 20:54:12 | jrmithdobbs: | 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:29 | Ademan: | 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:44 | jrmithdobbs: | Ademan: then you're not qualified to be commenting. |
| 20:54:48 | jrmithdobbs: | no offense |
| 20:55:29 | Ademan: | 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:24 | jrmithdobbs: | Ademan: there's at least 2 representations that are obvious and obviously standard (BE vs LE) ... |
| 20:56:26 | maaku: | Ademan: a signaling decimal64 type would be safe and performant to use in specific ways for financial applications |
| 20:57:22 | maaku: | 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:34 | maaku: | so useless in practice, unfortunately |
| 20:57:57 | tacotime: | kimoto gravity well uses double for difficulty calculations too :) |
| 20:58:05 | tacotime: | fork all of the alts |
| 20:58:45 | maaku: | :sigh: |
| 20:59:50 | maaku: | 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:45 | Ademan: | jrmithdobbs: ? endianness would be the least interesting consideration in specifying a decimal representation, or am I misunderstanding you? |
| 21:04:58 | kanzure: | gmaxwell: okay, understood |
| 21:14:54 | Kometes: | anyone got their hands on the von neumann zk-snarks system yet? |
| 21:18:44 | Ademan: | gmaxwell: is your GPG fingerprint DE47 BC9E 6D2D A6B0 2DC6 10B1 AC85 9362 B041 3BFA ? |
| 21:19:06 | helo: | helo is now known as the_tiger |
| 21:19:14 | LarsLarsen: | I can haz snarks? |
| 21:19:20 | the_tiger: | the_tiger is now known as helo |
| 21:20:58 | helo: | Ademan: that's what i have |
| 21:21:13 | helo: | (the fingerprint, not sharks) |
| 21:21:15 | helo: | *snarks |
| 21:21:21 | Ademan: | haha, also thanks helo |
| 21:25:08 | gmaxwell: | Ademan: yes. |
| 21:29:48 | Ademan: | 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:06 | gmaxwell: | freenode security is lol |
| 21:33:59 | sipa: | now you're just jumping the snark |
| 21:38:18 | Emcy: | nerds |
| 21:40:22 | Emcy: | hrm speaking of nsa specifically targetting nerds and hacker types https://blog.ageispolis.net/foxacid-at-hope9/ |
| 21:40:46 | Emcy: | looks like they probably used bitcoin as bait to target specifically target people at a hacker conf |
| 21:55:16 | nsh: | heh |
| 22:00:26 | nikitab_: | nikitab_ is now known as nikitab__ |
| 22:11:03 | just[dead]: | just[dead] is now known as justanotheruser |
| 22:11:14 | justanotheruser: | It looks like Darkcoin has implemented a coinjoin with blind signatures https://bitcointalk.org/index.php?topic=421615.msg5693650#msg5693650 |
| 22:13:58 | tacotime: | Has the author open sourced it yet? |
| 22:14:27 | justanotheruser: | no idea |
| 22:14:42 | tacotime: | I was trying to look at the code the other day and it didn't exist :/ |
| 22:18:45 | Ademan: | "run our code, trust us!" |
| 22:22:38 | adam3us: | so another idea towards making committed transactions SPV compatible without snarks: |
| 22:23:24 | adam3us: | 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:59 | adam3us: | 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:36 | adam3us: | 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:42 | adam3us: | 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:13 | adam3us: | 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:17 | adam3us: | 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:54 | gmaxwell: | so I commit something and then just never reveal my key. |
| 22:30:00 | adam3us: | 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:06 | justanotheruser: | justanotheruser is now known as just[dead] |
| 22:33:34 | adam3us: | 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:01 | adam3us: | 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:07 | gmaxwell: | 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:14 | gmaxwell: | and the network partitions |
| 22:36:07 | gmaxwell: | 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:50 | just[dead]: | just[dead] is now known as justanotheruser |
| 22:42:04 | adam3us: | 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:28 | adam3us: | 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:55 | gmaxwell: | 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:47 | adam3us: | 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:50 | gmaxwell: | I'm one step ahead of you. |
| 22:54:17 | gmaxwell: | "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:22 | gmaxwell: | lemme try to decode. |
| 22:54:43 | gmaxwell: | Blocks have a score used for tie breaking. The score is based on revealed keys in the block |
| 22:54:58 | gmaxwell: | You compute the score based on how long you've personally known about the particular keys being revealed. |
| 22:55:21 | gmaxwell: | 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:37 | adam3us: | 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:05 | justanotheruser: | justanotheruser is now known as just[dead] |
| 22:59:58 | gmaxwell: | I don't know how they could be not affected though... |
| 23:01:30 | adam3us: | 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:45 | gmaxwell: | yes, well, degress of censorship. |
| 23:17:38 | just[dead]: | just[dead] is now known as justanotheruser |
| 23:32:33 | justanotheruser: | justanotheruser is now known as just[dead] |
| 23:56:21 | luke-jr_: | luke-jr_ is now known as Luke-Jr |