| 00:35:21 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
| 01:42:55 | nOgAnOo: | nOgAnOo is now known as n0gAn0o |
| 01:44:39 | n0gAn0o: | n0gAn0o is now known as nOgAnOo |
| 01:58:02 | phantomcircuit: | gmaxwell, so i think there is some miscommunication in that issue, it seems like mark is talking about transactions where the outputs the transaction is spending have already been spent by another transaction |
| 01:58:25 | phantomcircuit: | in that case it would be safe to reissue with different inputs as long as the other transaction was confirmed |
| 01:58:45 | phantomcircuit: | im thinking he's trying to avoid manually reviewing all the transactions to fix the accounts |
| 02:36:51 | gmaxwell: | phantomcircuit: well careful there, it's not very safe if it's just 1 confirmed. In any case, I'm not even going to look. I'm not interested in that pull. |
| 02:49:45 | phantomcircuit: | gmaxwell, right it should be > 6 confirmations |
| 02:49:49 | phantomcircuit: | >= |
| 02:51:19 | gmaxwell: | well whatever number you consider sufficiently safe relative to your risk analysis... same critera you use for accepting deposits probably. |
| 02:51:56 | gmaxwell: | (6 is not a magic number you know, for high value, no recourse, ... ghash gets 6 in a row not unoften, if you do 6 you're saying anyone who 'hacks' ghash can exploit you) |
| 03:09:55 | luke-jr_: | luke-jr_ is now known as Luke-Jr |
| 04:15:01 | PanicSellBTC: | why don't services just hash the transactions outputs only and use that as a txid? |
| 04:15:53 | PanicSellBTC: | I dont see how making more transactions non-standard is a good thing. Before long, we'll be removing script! |
| 04:16:01 | andytoshi: | PanicSellBTC: way off-topic here, this channel is for research only |
| 04:16:28 | PanicSellBTC: | fair enough |
| 04:17:09 | gmaxwell: | meh, not that offtopic. |
| 04:18:06 | gmaxwell: | PanicSellBTC: they're being made non-standard in preparation for denying them completely on specified transactions. Most of the malleability comes from being overly tolerant from invalid encodings. |
| 04:18:23 | gmaxwell: | PanicSellBTC: And rather than reducing functionality, fixing malleability enhances functionality greatly. |
| 04:19:04 | gmaxwell: | Because currently transaction protocols which require a precomputed refund for a non-announced transaction are either unsafe, impossible, or made greatly more complicated by workarounds. |
| 04:19:53 | gmaxwell: | (this last point being the connection with this channel) |
| 04:20:13 | PanicSellBTC: | PanicSellBTC is now known as randombtc |
| 04:20:58 | randombtc: | gmaxwell: sorry i dont follow you entirely there. can you give an example of a precomputed refund for a non-announced transaction? |
| 04:22:21 | randombtc: | gmaxwell: would it too inefficient to have a 'txid2' that was just the hash of outputX:amountX , where X is 0...n for all the outputs |
| 04:22:29 | gmaxwell: | that doesn't help anything. |
| 04:22:32 | gmaxwell: | randombtc: a simple one say that I know want to pay you some amount of coin later, instantly, but not yet (e.g. I'm going to buy your car, but only when you hand over the keys, and we don't want to wait for confirms)— and perhaps the exact price isn't set yet. |
| 04:22:39 | randombtc: | and be able to lookup transactions that way |
| 04:23:08 | gmaxwell: | So I author a transaction the sends enough coins for the car to a 2 of 2 multisig {me + you}. |
| 04:23:51 | gmaxwell: | If I announce that transaction, however, I'm at risk of you, after it confirms, saying "Ha ha! fuck you. If you want any of your coins left sign over half now, or you get _nothing_" |
| 04:24:39 | gmaxwell: | So instead, before announcing, I tell you the scriptpubkey and txid of this 2of2 multisig and say "Please sign this, nlocktimed 48 hours from now, to refund all the funds to me." |
| 04:24:56 | gmaxwell: | You do. and happy that I can get my funds back in 48 hours, I announce the payment into the escrow. |
| 04:25:53 | gmaxwell: | then we can go trade the car— when you go to give me the keys you first ask for me to sign a release of the escrow to you. I sign it, you sign it and broadcast. You're sure I can't double spend it, and you let me ride off with the car. |
| 04:26:08 | gmaxwell: | If you try to screw me, I don't sign and get my funds back. |
| 04:26:52 | gmaxwell: | the wrinkle in this is if— when the payment into the escrow is announced, you or someone else mutates the transaction, the precomputed refund is then no longer valid and you can extort me again. |
| 04:27:18 | randombtc: | seems like this a use-case that will be used very rarely, compared to other transaction types |
| 04:27:30 | andytoshi: | other simple examples are at https://en.bitcoin.it/wiki/Contracts (i think everything on that page breaks because of malleability) |
| 04:27:42 | gmaxwell: | randombtc: ... |
| 04:27:58 | andytoshi: | randombtc: if not for malleability, i suspect we would have been pushing these sorts of things heavily for the last several years |
| 04:28:31 | gmaxwell: | randombtc: once automated by software its the sort of trivial thing that should be a best practice. This class of transaction can give you properties like instant irreversability that people complain that bitcoin lacks. |
| 04:29:33 | gmaxwell: | replace the counterparty with a weakly trusted third party that many people trust to not double sign (but don't need to trust beyond that), you can make instant payments to anyone of of a pool of funds set aside for that purpose. |
| 04:30:29 | gmaxwell: | The the same structure is necessary for constructing fair decenteralized lottery transactions. (e.g. two parties put in funds, one party gets paid) |
| 04:30:33 | gmaxwell: | And so on. |
| 04:31:22 | gmaxwell: | Its really for these advanced applications that its was generally though most important to bother fixing it for. ... for regular transactions the only really big pain is people invalidating change, being unable to spend your own change with 0 confirms is a major UI bummer. |
| 04:32:36 | randombtc: | right. though i suspect in the future most contracts will be done on ethereum, and bitcoin will act more as a store of value. perhaps trying to make bitcoin into an all-encompassing contracts tool will be to difficult given its underlying design headaches |
| 04:32:47 | gmaxwell: | not likely. lol |
| 04:35:22 | randombtc: | gmaxwell: you're not bullish on ethereum i take it? |
| 04:38:20 | randombtc: | it seems they will have a lot of resources (30k btc) to pay developers. their higher-level scripting language also seems like it will be useful for developers who aren't comfortable coding stack based contracts. and they also claim their gui-client will have a built-in 'app store' that runs webkit/V8 so developers can code ethereum contracts and apps in HTML5/javascript |
| 04:39:56 | randombtc: | anyway, thanks for the info above... i see the issue now... |
| 04:43:31 | andytoshi: | randombtc: does any of that seem consistent with 'distributed consensus time-ordering system' to you? we have had several-day-long fights about the consequences of introducing individual opcodes here, not to mention the difficulties with loops (incentivewise and consensuswise), and that's not even close to the consequences of turing completeness. |
| 04:43:38 | andytoshi: | http://download.wpsoftware.net/bitcoin/wizards/2014-01-09.txt covers a bunch of this, search for 'turing' and 'redcode' |
| 04:51:40 | randombtc: | andy: i'll take a read. unfortunately i'm not entirely familiar with GHOST, but It seems like ethereum's concept of fees-per-opcode solves a bunch of incentive/looping issues. they'll just have to have the best sandboxed bytecode machine in the world, since a single malicious script gaining access to memory could throw malware on all nodes in the network and rm -rf the blockchain |
| 05:08:56 | gmaxwell: | phantomcircuit: do you have any gunked up wallets with lots of double spends in it that you test https://github.com/bitcoin/bitcoin/pull/3669 on? |
| 05:09:07 | gmaxwell: | I only have one double spend in my wallet. |
| 05:10:45 | phantomcircuit: | gmaxwell, i dont think so |
| 05:10:48 | phantomcircuit: | let me see |
| 05:12:08 | phantomcircuit: | gmaxwell, nope |
| 05:13:27 | gmaxwell: | k, I have simulated ones, but the real deal is more fun. |
| 05:14:18 | gmaxwell: | bitcoind listtransactions "*" 100000 | grep 'confirmations" : 0' is a good test |
| 05:14:28 | gmaxwell: | unless you're running that patch in which case it's bitcoind listtransactions "*" 100000 | grep 'confirmations" : -1' |
| 05:15:14 | phantomcircuit: | gmaxwell, not a single one |
| 05:15:30 | phantomcircuit: | the node is very well connected so im guessing the mutated tx's dont stand a chance in the race |
| 05:15:51 | andytoshi: | gmaxwell: i have sixteen zero-conf transactions, some of them are double-spends i think |
| 05:16:24 | gmaxwell: | andytoshi: can you test that patch and observe that nothing catches fire and that they become -1 (except for ones that still have a chance)? |
| 05:16:42 | andytoshi: | sure, gimme fifteen.. |
| 05:18:00 | gmaxwell: | phantomcircuit: the cointerra hashrate sure isn't very stable. |
| 05:20:07 | phantomcircuit: | gmaxwell, really? i haven't seen more than +-3% between machines |
| 05:20:35 | gmaxwell: | maybe a temp sensitivity. |
| 05:20:45 | phantomcircuit: | blargh one of these is only running on one board |
| 05:20:46 | phantomcircuit: | >.> |
| 05:22:17 | phantomcircuit: | gmaxwell, it's kind of hard for me to tell other than polling cgminer |
| 05:22:28 | phantomcircuit: | i have the difficulty set to 8192 |
| 05:23:10 | gmaxwell: | ah, I see substantial variation on the like ... 1 hour timescale. it might not be obvious with diff 8192 shares. |
| 05:23:23 | gmaxwell: | hm actually it should be. |
| 05:24:37 | phantomcircuit: | gmaxwell, on a 1 hour scale i see stuff like 1601, 1677, 1535, 1589 |
| 05:24:59 | phantomcircuit: | which averages to exactly 1600 Gh/s |
| 08:35:50 | fanquake: | fanquake has left #bitcoin-wizards |
| 09:17:22 | Muis_: | Muis_ is now known as Muis |
| 10:08:35 | austinhill: | austinhill has left #bitcoin-wizards |
| 10:25:00 | nsh_: | nsh_ is now known as nsh |
| 15:13:27 | [\\\]_r: | [\\\]_r is now known as [\\\] |
| 16:54:21 | andytoshi: | * andytoshi finally looked up how ecdsa verification works ... wtf. |
| 16:54:45 | HM_: | it's a straight line |
| 16:54:53 | HM_: | y = mx + c. |
| 16:55:17 | HM_: | sig = key * messagehash + random |
| 16:55:46 | HM_: | random gets point multiplied so it cannot be determined without solving the EC DLP |
| 16:56:08 | HM_: | actually i'm probably thinking of another signature scheme |
| 16:56:15 | HM_: | same principle though, DSA is just weird |
| 16:56:22 | andytoshi: | that's roughly right, there is EC linear algebra |
| 16:56:31 | andytoshi: | DSA is much less weird |
| 16:57:03 | andytoshi: | here you take your 'epheremal pubkey', publish only the x value, then the verifier has to reconstruct the whole point |
| 16:57:20 | HM_: | yes |
| 16:57:36 | HM_: | schnorr signatures are actually simpler imho |
| 16:57:39 | andytoshi: | normal signatures have an epheremal pubkey and it's public, you don't worry about how it's constructed in your specific group, just that you can't get the privkey from it |
| 17:00:06 | HM_: | andytoshi, there's a digital cash scheme based on "shadow lines" that provides payer and payee anonmity unless a double spend occurs |
| 17:00:33 | HM_: | i never actually grokked how it worked because there's no good simple high level explanations online |
| 17:00:35 | andytoshi: | that's true, i guess there are uses for this kind of rube-goldbergery |
| 17:01:05 | HM_: | but basically it takes the payers identity as the gradient to a line and uses EC algebra to move it to a new secret line |
| 17:01:12 | HM_: | that the bank cannot know |
| 17:01:24 | HM_: | when you double spend, 2 points make a line and the double spender is revealed |
| 17:02:20 | HM_: | the name escapes me but i'm pretty sure the OpenTransactions guys have implemented it |
| 17:04:36 | nsh: | what are ye talking about? |
| 17:04:44 | maaku: | well, you have to jump through some hoops to make a signature scheme that has subtle vulnerabilities to RNG backdoors... |
| 17:06:23 | HM_: | It's a shame digital cash schemes that provide strong anonymity for traditional banking models havent' taken off |
| 17:06:33 | HM_: | i guess there's a strong regulatory disincentive to allow that |
| 17:07:05 | HM_: | and nobody is ever going to trust a bitcoin bank when exchanges are flakey |
| 17:09:02 | HM_: | i guess a more obvious problem is double spend detection rather than prevention relies upon a line of credit, like an overdraft |
| 17:24:36 | austinhill: | Dr. Stefan Brands blinded credentials & eCash system has payor & payee anonymity with identity being revealed with double spends |
| 17:25:08 | austinhill: | http://www.credentica.com/the_mit_pressbook.html on Brands private eCash & Credentials |
| 17:25:24 | sipa: | oh, hi austin :) |
| 17:25:30 | austinhill: | Hey Sipa :) |
| 17:25:43 | zooko: | Oh, hi austinhill. ☺ |
| 17:25:47 | sipa: | didn't see you here before |
| 17:25:59 | austinhill: | Been lurking since I saw you in Malta :) |
| 17:26:42 | austinhill: | Hey zooko - been awhile, can't wait to catch up….been seeing your S4 and some interesting variations on naming in the blockchain based on your ideas |
| 17:27:32 | zooko: | Yeah, exciting times! |
| 17:33:00 | zooko: | zooko has left #bitcoin-wizards |
| 17:42:20 | tromp: | hi, zooko:) |
| 18:00:43 | HM_: | austinhill, that's the one |
| 18:01:12 | ironzorg: | ironzorg has left #bitcoin-wizards |
| 18:01:34 | HM_: | austinhill, i couldn't reconstruct the high level algebraic concepts from the equations sadly |
| 18:01:40 | austinhill: | HM_ we invested $4 million into the Brands technology when I ran Zero-Knowledge Systems (adam back was with us at the time) - tough technology to deploy at the time. Now MSFT owns it but have an extremely open license |
| 18:04:09 | HM_: | well, I was only interested in understanding work presented in his thesis (I think it was his thesis?), not a production ready system. |
| 18:04:22 | austinhill: | Here are a few whitepapers that have mostly disappeared from the 'Net that explain both the technical math of his use of zkproofs of knowledge around eCash & private credentials https://www.dropbox.com/sh/v0oj6a8i2b58e95/5glO0UNLUv |
| 18:06:33 | austinhill: | hope that helps - |
| 18:07:07 | tromp: | any1 here ahve access to a 20+ threaded cpu? |
| 18:10:26 | tromp: | (or multi-cpu) |
| 18:11:14 | HM_: | austinhill, yeah, i'm going to have to try and have another stab at following the algebraic construction at least |
| 18:11:25 | HM_: | sometime... |
| 18:14:51 | HM_: | protocols come and go but the essence of an idea is worth learning |
| 18:15:51 | austinhill: | yeah, adam3us and I think there are some interesting opportunities to see some of Brands techniques used in a blockchain type system - |
| 18:25:05 | zooko: | adam3us: hi there. |
| 18:51:25 | HM_: | austinhill, interesting |
| 18:51:43 | HM_: | austinhill, won't you get reamed on patents? |
| 18:53:49 | zooko: | I'm very interested in related ideas, austinhill. |
| 18:57:01 | maaku: | HM_: patents expired recently IIRC |
| 18:59:35 | austinhill: | zooko, let's chat - I'm 'austinhill' on skype |
| 19:01:38 | zooko: | austinhill: I just sent you IRC privmsgs, but sometimes those don't go through if freenode server thinks I haven't authenticated or something... |
| 19:03:43 | gmaxwell: | maaku: regardless of what happens with the ntxid stuff, I think your error corrected strings will be useful for something. |
| 19:04:13 | austinhill: | @Hm_ lot's of Brands patents are expiring, but MSFT also has a very open license for those patents that haven't expired yet |
| 19:06:16 | maaku: | gmaxwell: yeah, honest admission: I pulled the basic design out of a colored coin exchange jtimon and I are working on, where the encoding format was used for internal identifiers reported to the user |
| 19:06:57 | maaku: | so these helpdesk-related issues are a problem space I've thought about ... ECC coded strings probably have other uses too |
| 19:08:19 | maaku: | btw I was very surprised to find that CRCs can be used for error correction.. why don't they cover that in school? |
| 19:09:19 | lnovy: | i've heard something about shanoon at school, but not much... |
| 19:11:15 | gmaxwell: | maaku: they do, see. e.g. MIT 16.36 opencourseware stuff. |
| 19:11:49 | gmaxwell: | Same stuff that SECDED ECC ram stuff does, but over a bigger field. |
| 19:13:02 | gmaxwell: | maaku: I haven't looked— does your stuff have tidy properties line being able to recover from any single character change? |
| 19:20:48 | maaku: | gmaxwell: yes, and to be sure the verification program I uploaded exhaustively tests this (takes about 15min on a core i7) |
| 19:21:50 | maaku: | it handles up to one error per 31 digit chunk |
| 19:22:19 | maaku: | and detects larger errors very reliably -- I need to work out exactly how well |
| 19:22:42 | maaku: | but it should be comparable to a 4-byte hash checksum |
| 19:22:55 | gmaxwell: | are the chunks 31 payload 32 output? |
| 19:23:12 | maaku: | 26 payload, 31 output |
| 19:23:25 | maaku: | 256 bits (really, 260) is fully encoded in 62 bits of output |
| 19:23:43 | maaku: | so i prefix "tx" for the ntxids to make it an even 64 |
| 19:24:05 | gmaxwell: | hm. you _should_ be able to correct (output-payload)/2 errors without knowing their locations and output-payload errors with knowing their locations, with an information theortically optimal code. |
| 19:24:28 | maaku: | yes, it's less optimal than reed solomon (which hits the theoretical limits) |
| 19:24:49 | maaku: | but crc is a lot easier to get right than solving linear systems over finite fields... |
| 19:25:16 | maaku: | ultimately i decided ease of implementation and speed was worth a few percentage points space inefficiency |
| 19:25:23 | gmaxwell: | the encoder for a 6 bit RS code can just use a little table. |
| 19:25:32 | gmaxwell: | er 5 bit. |
| 19:25:49 | gmaxwell: | the decode with errors code is a little more complicated. |
| 19:27:03 | maaku: | gmaxwell: yeah, when I crossed 1000 lines of code in the file containing the RS decoder, I realized chances of it getting adopted were getting proportionally smaller for each added LOC |
| 19:27:33 | maaku: | the first version was a RS coder |
| 19:27:42 | gmaxwell: | maaku: oh it shouldn't be that long. :-/ esp since the code is syndromic so you can have a non-error handling code without any complexity at all. |
| 19:28:35 | gmaxwell: | though I can agree that the extra protection is probably that that important, since it still won't handle things like dropping a charcter gracefully. |
| 20:58:06 | jgarzik: | "On Subversive Mining Strategies and Block Withholding Attacks in Bitcoin", http://arxiv.org/pdf/1402.1718.pdf |
| 20:58:13 | jgarzik: | is this old or new? |
| 21:05:32 | phantomcircuit: | sipa, Luke-Jr i hear you're both keeping track of bitcoin node version numbers |
| 21:06:03 | andytoshi: | jgarzik: it's from dec, was updated a few days ago...i don't recall seeing it before. this time around i read the abstract and binned it |
| 21:06:42 | andytoshi: | it's not the selfish mining paper, that one was much more well-written |