00:35:21luke-jr_:luke-jr_ is now known as Luke-Jr
01:42:55nOgAnOo:nOgAnOo is now known as n0gAn0o
01:44:39n0gAn0o:n0gAn0o is now known as nOgAnOo
01:58:02phantomcircuit: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:25phantomcircuit:in that case it would be safe to reissue with different inputs as long as the other transaction was confirmed
01:58:45phantomcircuit:im thinking he's trying to avoid manually reviewing all the transactions to fix the accounts
02:36:51gmaxwell: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:45phantomcircuit:gmaxwell, right it should be > 6 confirmations
02:51:19gmaxwell:well whatever number you consider sufficiently safe relative to your risk analysis... same critera you use for accepting deposits probably.
02:51:56gmaxwell:(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:55luke-jr_:luke-jr_ is now known as Luke-Jr
04:15:01PanicSellBTC:why don't services just hash the transactions outputs only and use that as a txid?
04:15:53PanicSellBTC:I dont see how making more transactions non-standard is a good thing. Before long, we'll be removing script!
04:16:01andytoshi:PanicSellBTC: way off-topic here, this channel is for research only
04:16:28PanicSellBTC:fair enough
04:17:09gmaxwell:meh, not that offtopic.
04:18:06gmaxwell: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:23gmaxwell:PanicSellBTC: And rather than reducing functionality, fixing malleability enhances functionality greatly.
04:19:04gmaxwell: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:53gmaxwell:(this last point being the connection with this channel)
04:20:13PanicSellBTC:PanicSellBTC is now known as randombtc
04:20:58randombtc:gmaxwell: sorry i dont follow you entirely there. can you give an example of a precomputed refund for a non-announced transaction?
04:22:21randombtc: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:29gmaxwell:that doesn't help anything.
04:22:32gmaxwell: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:39randombtc:and be able to lookup transactions that way
04:23:08gmaxwell:So I author a transaction the sends enough coins for the car to a 2 of 2 multisig {me + you}.
04:23:51gmaxwell: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:39gmaxwell: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:56gmaxwell:You do. and happy that I can get my funds back in 48 hours, I announce the payment into the escrow.
04:25:53gmaxwell: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:08gmaxwell:If you try to screw me, I don't sign and get my funds back.
04:26:52gmaxwell: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:18randombtc:seems like this a use-case that will be used very rarely, compared to other transaction types
04:27:30andytoshi:other simple examples are at https://en.bitcoin.it/wiki/Contracts (i think everything on that page breaks because of malleability)
04:27:42gmaxwell:randombtc: ...
04:27:58andytoshi:randombtc: if not for malleability, i suspect we would have been pushing these sorts of things heavily for the last several years
04:28:31gmaxwell: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:33gmaxwell: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:29gmaxwell: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:33gmaxwell:And so on.
04:31:22gmaxwell: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:36randombtc: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:47gmaxwell:not likely. lol
04:35:22randombtc:gmaxwell: you're not bullish on ethereum i take it?
04:38:20randombtc: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:56randombtc:anyway, thanks for the info above... i see the issue now...
04:43:31andytoshi: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:38andytoshi:http://download.wpsoftware.net/bitcoin/wizards/2014-01-09.txt covers a bunch of this, search for 'turing' and 'redcode'
04:51:40randombtc: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:56gmaxwell: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:07gmaxwell:I only have one double spend in my wallet.
05:10:45phantomcircuit:gmaxwell, i dont think so
05:10:48phantomcircuit:let me see
05:12:08phantomcircuit:gmaxwell, nope
05:13:27gmaxwell:k, I have simulated ones, but the real deal is more fun.
05:14:18gmaxwell:bitcoind listtransactions "*" 100000 | grep 'confirmations" : 0' is a good test
05:14:28gmaxwell:unless you're running that patch in which case it's bitcoind listtransactions "*" 100000 | grep 'confirmations" : -1'
05:15:14phantomcircuit:gmaxwell, not a single one
05:15:30phantomcircuit:the node is very well connected so im guessing the mutated tx's dont stand a chance in the race
05:15:51andytoshi:gmaxwell: i have sixteen zero-conf transactions, some of them are double-spends i think
05:16:24gmaxwell: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:42andytoshi:sure, gimme fifteen..
05:18:00gmaxwell:phantomcircuit: the cointerra hashrate sure isn't very stable.
05:20:07phantomcircuit:gmaxwell, really? i haven't seen more than +-3% between machines
05:20:35gmaxwell:maybe a temp sensitivity.
05:20:45phantomcircuit:blargh one of these is only running on one board
05:22:17phantomcircuit:gmaxwell, it's kind of hard for me to tell other than polling cgminer
05:22:28phantomcircuit:i have the difficulty set to 8192
05:23:10gmaxwell:ah, I see substantial variation on the like ... 1 hour timescale. it might not be obvious with diff 8192 shares.
05:23:23gmaxwell:hm actually it should be.
05:24:37phantomcircuit:gmaxwell, on a 1 hour scale i see stuff like 1601, 1677, 1535, 1589
05:24:59phantomcircuit:which averages to exactly 1600 Gh/s
08:35:50fanquake:fanquake has left #bitcoin-wizards
09:17:22Muis_:Muis_ is now known as Muis
10:08:35austinhill:austinhill has left #bitcoin-wizards
10:25:00nsh_:nsh_ is now known as nsh
15:13:27[\\\]_r:[\\\]_r is now known as [\\\]
16:54:21andytoshi:* andytoshi finally looked up how ecdsa verification works ... wtf.
16:54:45HM_:it's a straight line
16:54:53HM_:y = mx + c.
16:55:17HM_:sig = key * messagehash + random
16:55:46HM_:random gets point multiplied so it cannot be determined without solving the EC DLP
16:56:08HM_:actually i'm probably thinking of another signature scheme
16:56:15HM_:same principle though, DSA is just weird
16:56:22andytoshi:that's roughly right, there is EC linear algebra
16:56:31andytoshi:DSA is much less weird
16:57:03andytoshi:here you take your 'epheremal pubkey', publish only the x value, then the verifier has to reconstruct the whole point
16:57:36HM_:schnorr signatures are actually simpler imho
16:57:39andytoshi: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:06HM_:andytoshi, there's a digital cash scheme based on "shadow lines" that provides payer and payee anonmity unless a double spend occurs
17:00:33HM_:i never actually grokked how it worked because there's no good simple high level explanations online
17:00:35andytoshi:that's true, i guess there are uses for this kind of rube-goldbergery
17:01:05HM_: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:12HM_:that the bank cannot know
17:01:24HM_:when you double spend, 2 points make a line and the double spender is revealed
17:02:20HM_:the name escapes me but i'm pretty sure the OpenTransactions guys have implemented it
17:04:36nsh:what are ye talking about?
17:04:44maaku:well, you have to jump through some hoops to make a signature scheme that has subtle vulnerabilities to RNG backdoors...
17:06:23HM_:It's a shame digital cash schemes that provide strong anonymity for traditional banking models havent' taken off
17:06:33HM_:i guess there's a strong regulatory disincentive to allow that
17:07:05HM_:and nobody is ever going to trust a bitcoin bank when exchanges are flakey
17:09:02HM_:i guess a more obvious problem is double spend detection rather than prevention relies upon a line of credit, like an overdraft
17:24:36austinhill:Dr. Stefan Brands blinded credentials & eCash system has payor & payee anonymity with identity being revealed with double spends
17:25:08austinhill:http://www.credentica.com/the_mit_pressbook.html on Brands private eCash & Credentials
17:25:24sipa:oh, hi austin :)
17:25:30austinhill:Hey Sipa :)
17:25:43zooko:Oh, hi austinhill. ☺
17:25:47sipa:didn't see you here before
17:25:59austinhill:Been lurking since I saw you in Malta :)
17:26:42austinhill: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:32zooko:Yeah, exciting times!
17:33:00zooko:zooko has left #bitcoin-wizards
17:42:20tromp:hi, zooko:)
18:00:43HM_:austinhill, that's the one
18:01:12ironzorg:ironzorg has left #bitcoin-wizards
18:01:34HM_:austinhill, i couldn't reconstruct the high level algebraic concepts from the equations sadly
18:01:40austinhill: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:09HM_: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:22austinhill: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:33austinhill:hope that helps -
18:07:07tromp:any1 here ahve access to a 20+ threaded cpu?
18:10:26tromp:(or multi-cpu)
18:11:14HM_:austinhill, yeah, i'm going to have to try and have another stab at following the algebraic construction at least
18:14:51HM_:protocols come and go but the essence of an idea is worth learning
18:15:51austinhill:yeah, adam3us and I think there are some interesting opportunities to see some of Brands techniques used in a blockchain type system -
18:25:05zooko:adam3us: hi there.
18:51:25HM_:austinhill, interesting
18:51:43HM_:austinhill, won't you get reamed on patents?
18:53:49zooko:I'm very interested in related ideas, austinhill.
18:57:01maaku:HM_: patents expired recently IIRC
18:59:35austinhill:zooko, let's chat - I'm 'austinhill' on skype
19:01:38zooko: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:43gmaxwell:maaku: regardless of what happens with the ntxid stuff, I think your error corrected strings will be useful for something.
19:04:13austinhill:@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:16maaku: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:57maaku:so these helpdesk-related issues are a problem space I've thought about ... ECC coded strings probably have other uses too
19:08:19maaku: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:19lnovy:i've heard something about shanoon at school, but not much...
19:11:15gmaxwell:maaku: they do, see. e.g. MIT 16.36 opencourseware stuff.
19:11:49gmaxwell:Same stuff that SECDED ECC ram stuff does, but over a bigger field.
19:13:02gmaxwell:maaku: I haven't looked— does your stuff have tidy properties line being able to recover from any single character change?
19:20:48maaku:gmaxwell: yes, and to be sure the verification program I uploaded exhaustively tests this (takes about 15min on a core i7)
19:21:50maaku:it handles up to one error per 31 digit chunk
19:22:19maaku:and detects larger errors very reliably -- I need to work out exactly how well
19:22:42maaku:but it should be comparable to a 4-byte hash checksum
19:22:55gmaxwell:are the chunks 31 payload 32 output?
19:23:12maaku:26 payload, 31 output
19:23:25maaku:256 bits (really, 260) is fully encoded in 62 bits of output
19:23:43maaku:so i prefix "tx" for the ntxids to make it an even 64
19:24:05gmaxwell: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:28maaku:yes, it's less optimal than reed solomon (which hits the theoretical limits)
19:24:49maaku:but crc is a lot easier to get right than solving linear systems over finite fields...
19:25:16maaku:ultimately i decided ease of implementation and speed was worth a few percentage points space inefficiency
19:25:23gmaxwell:the encoder for a 6 bit RS code can just use a little table.
19:25:32gmaxwell:er 5 bit.
19:25:49gmaxwell:the decode with errors code is a little more complicated.
19:27:03maaku: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:33maaku:the first version was a RS coder
19:27:42gmaxwell: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:35gmaxwell: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:06jgarzik:"On Subversive Mining Strategies and Block Withholding Attacks in Bitcoin", http://arxiv.org/pdf/1402.1718.pdf
20:58:13jgarzik:is this old or new?
21:05:32phantomcircuit:sipa, Luke-Jr i hear you're both keeping track of bitcoin node version numbers
21:06:03andytoshi: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:42andytoshi:it's not the selfish mining paper, that one was much more well-written