00:07:25justanotheruser:justanotheruser is now known as just[dead]
00:26:01jgarzik:amiller, it's a static list
00:27:22nsh:good old reliable NSA hosting
00:42:46wallet42:wallet42 is now known as Guest94957
00:42:46wallet421:wallet421 is now known as wallet42
01:02:49just[dead]:just[dead] is now known as justanotheruser
01:44:09justanotheruser:justanotheruser is now known as just[dead]
02:14:54just[dead]:just[dead] is now known as justanotheruser
02:24:58justanotheruser:justanotheruser is now known as just[dead]
02:33:19just[dead]:just[dead] is now known as justanotheruser
03:01:28justanotheruser:justanotheruser is now known as just[dead]
04:34:58andytoshi:tacotime: if you want to write up some -wizards stuff, or setup a wiki/github/whatever, i'd also be happy to review it
04:35:40andytoshi:just[dead]: if you are willing to accept N^2 communication overhead, it's fairly obvious how to do blind p2p CJ.. i don't recall where in the logs this was last suggested, sorry. i recommend you just wget them all then grep..
04:47:14andytoshi:LarsLarsen: kanzure: Ademan: for the love of god lurk moar, i have only so many brain cycles and i will have to leave bitcoin if this channel costs too many just to read
04:54:04andytoshi:gmaxwell: regarding the recent ecdsa 2of2 paper, i proofread that before crowex posted it and i've got a good feeling about it...uses the same tricks oleganza used (users pass each other random affine transformations of their data) and has the same sort of limitations (can't reuse the key, mainly) haven't read the paper TD posted about it yet, have had a crazy week.
05:42:02antephia_:for anyone interested, here are some good lecture notes on ZKPs: https://web.archive.org/web/20090617073205/http://www.cs.jhu.edu/~susan/600.641/scribes/
05:42:11antephia_:antephia_ is now known as antephialtic
05:44:16antephialtic:for anyone interested, here are some good lecture notes on ZKPs: https://web.archive.org/web/20090617073205/http://www.cs.jhu.edu/~susan/600.641/scribes/
05:46:36LarsLarsen:andytoshi: did I say something here recently? I just talked in #bitcoin for a few minutes, for the first time in like 24 hours.
05:55:32ghtdak:ghtdak has left #bitcoin-wizards
06:05:50gmaxwell:andytoshi: could you reuse if you generated more shares for the nonce?
06:09:24jxie:suppose an exchange implements the Merkle approache to prove itself, does it mean the exchange need to do a *real* transfer between user's addresses when a trade happened?
06:10:00jxie:because for a traditional exchange, all coins in user's deposit address will be wiped to the exchange's hot/cold backup address
06:10:46jxie:and when a trade happen the exchange only need to update the coins for corresponding users in database
10:52:26TD:TD is now known as hearn
12:09:3617SAAVH51:17SAAVH51 is now known as HM2
12:42:40andytoshi:gmaxwell: not sure what you mean, the scheme is 2-of-2 so every share needs to be used in the signature
12:44:12gmaxwell:andytoshi: I mean is the k's sharing totally seperable from the rest?
12:44:55andytoshi:ah, no, the keypair is determined (at least) in part by the nonce, so if you reuse the keypair you have to reuse the nonce
12:45:44andytoshi:iirc because neither party knows the full key they cannot cherry-pick their numbers to keep the nonce
12:46:09gmaxwell:got it, hm then indeed that would signficantly reduce the usefulness.
12:46:14andytoshi:except in a some trivial ways which would allow either party to determine the original nonce
12:46:27gmaxwell:the problem is that if anything gets stuck you'll have to do it again and if you do ... anyone can steal it.
12:46:48andytoshi:yeah, exactly. plus your original concerns about people repeatedly sending to old addresses
12:47:08nsh:what scheme/subject are you discussing?
12:47:32gmaxwell:yea, even just crazy dust, will drive people nuts that they can't recover it. I guess you ... yea
12:47:35gmaxwell:here is what you do.
12:47:51gmaxwell:you can do your normal 2-of-2 things for an escrow, and then when its done the parties can share their private state.
12:47:57gmaxwell:then you can sweep up any dust that shows up.
12:48:16gmaxwell:since once the private key is recovered you can use new nonces. :P
12:48:33gmaxwell:and you can avoid getting stuck on the original escrow by using anyone can pay.
12:48:50gmaxwell:oh damn but that breaks any prospect of having a secure refund.
12:48:56gmaxwell:doom, doom I say, all is doomed.
12:49:28andytoshi::P one sec, i'm searching for my notes, but i think i might've written a grocery list on them and thrown them away..
13:06:50andytoshi:ok, rereading the protocol, g^k is a DH shared-secret so neither party has any real knowledge of the nonce k. i don't even see that they can manipulate k in a predictable way without possessing the other's secret key material
13:09:15andytoshi:the keyshares are also derived from DH secrets, neither party knows their actual keyshare. this is extremely inflexible
13:56:54gmaxwell:andytoshi: yo
13:58:11gmaxwell:andytoshi: http://sourceforge.net/p/bitcoin/mailman/message/32107008/
13:59:24andytoshi:gmaxwell: just saw that in my inbox. o.O
14:10:00andytoshi:glad that code is in python at least.. there are a lot of short and nondescriptive variables (eg _r is curve order, r is the checksum in the encrypt function) so it is hard to read
14:15:10gmaxwell:there are probably other weaknesses beyond the ones I see, it looks like an extremely ill advised construction.
14:23:07gmaxwell:andytoshi: has the ECC_YfromX broken your mind yet?
14:24:40HM2:why is the parameter to select Y called "odd"?
14:24:47andytoshi:yes, but i was willing do give him the benefit of the doubt there because i haven't seen a serious impl before
14:25:11andytoshi:this xoffset business seems very shifty, is that standard?
14:25:47gmaxwell:not not all all it's totally fucking psycho
14:26:27gmaxwell:this is code I would consider obvious kleptography if I'd recieved a pull req for it.
14:27:47andytoshi:ok, good, glad i'm not the crazy one :P
14:28:17andytoshi:iirc we covered the quadratic eqn in grade 9..
14:30:40gmaxwell:what he appears to be doing is breaking the message up into 256 bit chunks .. then doing ecdh for each chunk.. then coercing the message data into a point — which usually won't work, thus the offset (and even then there must not always be an unambigous decryption because the group is too small). then he just adds the message chunk to the ecdh derrived point.
14:30:58gmaxwell:and seralizes the nonce pubkey and the point.
14:31:07gmaxwell:I wouldn't be surprised if the offset was leaking message bits.
14:31:20HM2:why is he trying to use ECDSA for encryption anyway
14:31:25gmaxwell:and using an ecdh derrived value directly is a HUGE no no. because of the twist attack I mentioned.
14:32:48andytoshi:ahh, yes, that explains the offset, that "convert the message to a point, char by char" seemed insane
14:33:09gmaxwell:yea actually duh of course it must leak data since it's an operation purely on the plaintext.
14:33:40andytoshi:is the secp256k1 twist insecure? one benefit of curve25519 that we haven't really talked about is that it has a secure twist
14:33:44nsh:where can i read about twist attacks?
14:34:04nsh:* nsh looks http://safecurves.cr.yp.to/twist.html
14:34:44gmaxwell:andytoshi; it is, there is a paper which says it is not, and the paper is wrong. (I've been discussing this in slow motion with the authors)
14:36:47gmaxwell:http://www.di.ens.fr/~fouque/pub/fdtc08.pdf < paper that is wrong. :)
14:37:16gmaxwell:(I went around believing it wasn't for some time until I happened to go calculate the order of the twist myself)
14:37:45andytoshi:thomasv just replied to your email, "i'll see if i can fix the code and get back to you :(" no, how about "i'll see if i can learn cryptography then find some real code written by someone serious who has a paper describing the algebra, without screaming red flags everywhere"
14:38:30andytoshi:ls -l ~/*.pdf | wc -l <--- outputs 46. i'll get to it :)
14:39:53HM2:ECIES seems pretty trivial and obvious
14:40:05gmaxwell:yes. its a fine construction. This is not ECIES.
14:40:08HM2:why would you invent something less obvious
14:40:18nsh:"The quadratic twist of secp256k1 has a 220-bit prime factor and thus can be considered twist secure (e.g. as in [5])." -- http://eprint.iacr.org/2013/734.pdf (Elliptic Curve Cryptography in Practice)
14:40:28gmaxwell:it is like ECIES only in so far as there is an ECDH operation in the middle, the similarity ends there.
14:41:07gmaxwell:nsh: yep, but still no excuse to adopt a gratitiously flaky design.
14:41:26nsh:mmm
14:41:46HM2:my gut would be to just do Ephemeral-Static ECDH and use any authenticated encryption scheme.
14:42:24nsh:-- continues:
14:42:24nsh:A non-laddering implementation (using both x- and y-coordinates) can be compromised by an invalid-curve attack if the implementation does not check whether the point satisfies the correct curve equation [7].
14:42:25nsh:This could lead to a more serious attack on secp256k14 since an attacker might obtain scalar multiples with secret scalars of a point on any curve over Fp with coefficient a = 0, i.e. on any of secp256k1’s twists. The largest prime divisors of the remaining four twists’ group orders are of size 133, 188, 135, and 161 bits, respectively, but there are several other smaller prime factors that offer more choices for an
14:42:27nsh:invalid-curve attack.
14:42:29nsh:--
14:42:56gmaxwell:HM2: sure, you really do want to hash the secret coming out of ecdh however. And the authentication much be ~ compariable in size to the cryptographic key.
14:43:40HM2:yeah
14:45:24HM2:I can't make heads or tails of jeeq
14:59:11gmaxwell:yea, I generated a message which succesfully decrypts to the wrong thing.
15:01:01gmaxwell:I think it'll happen for any data that contains a run of 0xFF at least 43 bytes long.
15:01:30gmaxwell:sorry I should sleep, I'm finding all the fun failures in this thing. I should leave some for you guys.
15:01:51HM2:Input must be valid UTF-8. Fixed!
15:02:54gmaxwell:well there may be other messages which fail, but I think proving that requires saying something about the sparsity of x values on our curve and I don't think we can say too much about them.
16:56:57amiller:where is there any discussion about two-way value pegging?
16:56:59amiller:there are lots of examples of 1-way pegging
16:57:01amiller:and clearly people have been thinking about 2-way a bunch
16:57:03amiller:i can't find a forum post or mailing list post thouhg
16:57:45copumpkin:* copumpkin coughs
16:59:03amiller:copumpkin, are you coughing because "2-way pegging" sounds like innuendo?
16:59:11copumpkin::)
16:59:13copumpkin:no comment
16:59:30copumpkin:what is this pegging of which you speak though? I'm reluctant to google it
16:59:35amiller:innuendo is a self-describing word.
17:00:31amiller:copumpkin, well 1-way peg is already a pretty etsablished idea
17:00:57amiller:it's in the wiki under "proof of burn" https://en.bitcoin.it/wiki/Proof_of_burn#Coin-burning_as_a_tool_for_transition_between_cryptocurrencies
17:01:23amiller:sometimes it's also claled bitcoin staging https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02343.html
17:01:39amiller:and the idea is that you have some altcoin you want to launch, and you create value on the new altcoin by "burning" a bitcoin
17:02:28amiller:this means that the total amount of money is still scarce and that there is a bound in one direction on the trade value of the altcoin
17:02:42amiller:it's never *more* than a bitcoin, because you could always just spend a bitcoin to get one
17:02:57amiller:so the question is, is there a way to make that bi-directional
17:03:05amiller:where you can burn a bitcoin to get an altcoin
17:03:16amiller:but *also* go in the other direction, where you burn one of the altcoins and get a bitcoin back
17:03:32roidster:roidster is now known as Guest76153
17:03:37tacotime:...so that's more like a transaction across two chains?
17:03:45amiller:tacotime, no its very different
17:04:16amiller:because a transaction across two chains doesn't really create or destroy units on either chain
17:04:33amiller:transactions across chains is part of how you might implement it though.
17:05:00amiller:it's not an ordinary transfer transaction across chains is what i mean
17:05:34tacotime:Ah, okay.
17:10:32amiller:gmaxwell, is this the first discussion of 2-way peg? http://pastebin.com/Aefaxfew
17:10:46copumpkin:copumpkin is now known as yoda123
17:10:47amiller:wizards log with you and justanotheruser from january
17:11:33yoda123:yoda123 is now known as copumpkin
17:12:13gmaxwell:no.
17:12:27gmaxwell:there is an older discussion.
17:44:32just[dead]:just[dead] is now known as justanotheruser
17:52:27adam3us:i book marked it very near top of this day http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
18:00:34LarsLarsen1:LarsLarsen1 is now known as larslarsen
18:11:10adam3us:i figured it might be possible when i was talking about 1-way peg, but i had the focus to achieve it without changes to bitcoin, as that was my motivation, to be able to add features that are too high risk to reasonably expect bitcoin to accept, so i considered bitcoin changes being required a catch-22. also in the 2-way peg thought experiment I had not realized how simple it was to still impose a security firewall in
18:17:08adam3us:above i think andytoshi & gmaxwell were talking about the 1-use sig property of i presume 2 of 2 multiparty sig crowex proposed using oleganza blind ecdsa.
18:17:17gmaxwell:yes
18:20:05adam3us:not sure how it works out in relation to the form of those public keys modified in relation to k from R=kG, but one-show also generalizes to multi-show; you commit to a sequence of specific allowed R values (what i see above described as the nonce) and then you can use them one by one (but not reuse). maybe that could allow "reuse" at the macro level, use a different committed R value each time. if you have a generate
18:21:11gmaxwell:thats what I was trying to determine— if you could make it multi-show, sadily I haven't had the mental cycles to read the scheme at all, so I was cheating and query andytoshi instead, it seems he doesn't think you can.
18:21:15adam3us:you dont have to actually send the R values, just commit to a merkle tree of them like Q'=H(merkle-root,Q) where the merkle contains a number of one use R values
18:21:34copumpkin:amiller: I see, that's cool
18:22:15adam3us:he might likely be right. i also did not get around to checking the detail.
18:22:33gmaxwell:The reason I was asking is because a true one show signature is bad news for most applications in bitcoin. e.g. someone decides to send some more funds to your past escrow address, or you need to reform the transactions to increase fees.
18:23:28gmaxwell:but multishow for some small number is fine; I'd say 1 of n multisig but then you blow the indistinguishability advantages
18:24:38gmaxwell:(and efficiency)
18:27:11andytoshi:the reason for 1-use only is that both the public key and R value are derived from both parties' secret data
18:27:34andytoshi:so you cannot change one without changing the other, and the way they are derived in both oleganza and crowex's scheme is basically an elaborate diffie-hellman
18:27:58andytoshi:so you can't even control how you change one eg so if the other side cooperates you can change the nonce without changing the key
18:28:13andytoshi:(unless you just reveal your secret data entirely and let the other party do the whole thing)
18:30:00gmaxwell:sometimes it feels like there is a conservation of brittleness law in cryptosystems.
18:30:12andytoshi:so the R commitment is kinda accidental, i don't think you can adjust it to commit to a series of R values like adam3us wants
18:31:16adam3us:so but you could at a macro-level get the feature maybe. eg create a batch of them, and make a 1 of n multisig
18:31:17andytoshi:gmaxwell: :P that's exactly the feeling i get. and ecdsa has a -lot- of brittleness to preserve..
18:31:42andytoshi:adam3us: yeah, that'd do it
18:32:16gmaxwell:yea 1 of n blows away the advantages I care about however.
18:32:35gmaxwell:(I think the increased efficiency and the indistinguishablity from a boring transaction are interesting)
18:33:57maaku:i'm writing up a short description of compact spv proofs
18:34:24maaku:are there any relevant citations I should include? (wizards logs, private correspondance, forum posts, whatever)
18:34:57gmaxwell:amiller's hashvalue highway post; its basically talking about the same thing but without the merge mining edge lengh constraint that makes it tight.
18:36:29amiller:i don't understand the merge mining edge length constraint yet or why that's necessary.
18:37:14adam3us:andytoshi: speaking of brittleness, check out the paper by vaudenay writing up bleichenbachers discovery of a bias in the original nist/nsa that allowed recovery of the private key https://www.iacr.org/archive/pkc2003/25670309/25670309.pdf that caused a standard revision; plus they never put the deterministic key derivation in the standrd.. its ultra brittle. even known k = k'+c or k'=mk for unknown k,k' an constands c
18:38:02adam3us:andytoshi: section 2.2. i am sure there's another version of that write up that says how many sigs to do it, i think it wasnt that many, and bleichenbacher said he didnt even try to optimize it
18:38:34adam3us:andytoshi: soft-nsa sabotage at work? possibly suspicious i think. possible to make secure, but hard.
18:38:37andytoshi:lol !! thx adam3us
18:44:31gmaxwell:andytoshi: it's much easier understood with a diagram.
18:44:36gmaxwell:er amiller
18:44:44gmaxwell:too many a* in here, we need a better hash
18:48:15gmaxwell:amiller: so say I give you a proof that contains [normal block] -commits to-> [insanely low past block]. This is suggestive that there is a lot of hashing going on somewhere. But perhaps the hashing might have all been in the past off on some other fork. It also doesn't result in computing the same amount of work that bitcoin would compute following the headers linearly.
18:49:02gmaxwell:if instead [normal block] commits to some hashtree of links back to prior blocks, each with it's lengh in work spanned as part of the commitment
18:49:48gmaxwell:then [normal block] happens to get lucky and be insanely low, we consider edges of length up to the degree of insanely lowness valid... like merged mining where each chain can have it's own target.
18:52:29gmaxwell:If you were to try to create a fake block— whole cloth— that had an edge that skipped over a bunch of blocks that didn't actually exist, your expected work in doing so would be equal to the work in the skipped areas. (ignoring that the variance is different in getting 1 diff=NX vs N diff X)
18:53:10amiller:i follow so far just fine
18:54:04just[dead]:just[dead] is now known as justanotheruser
18:54:16gmaxwell:you can select the edges— other than the after the fact length restriction— however you like depending on what you need to optimize for, for total work you'd optimize paths to genesis (e.g. by doing the dynamic programming to find the optimal edges of the permitted lengths to get back to genesis ASAP)
18:57:55gmaxwell:amiller: Is it clear to you why this is useful now?
18:58:39amiller:ok so yes
18:58:52amiller:this is the same as that sequential proof of work construction i mentioned a little while ago then isn't it?
18:59:12amiller:basically you don't really gain anything by selecting based on the post-hash value like i suggested (so most of my post was a waste)
18:59:49amiller:but you do get a good gain by having a log-tree-ish structure of backward links you can follow to quickly evaluate the work proof.
19:00:02gmaxwell:The magic is the merged mining like pre-commit. Your post was close but no cigar. It's probably what got me thinking about hash skiplists.
19:00:28amiller:yeah
19:00:29sipa:i've been doing some simulations on optimal proof sizes with skiplists
19:00:34gmaxwell:hm. I didn't read that sequential proof of work, pretty tired of POW schemes. :-/
19:01:13sipa:for bitcoin, with 80 bytes headers and 32 byte hashes, assuming constant hashrate, 50k block proofs take around 15.6 kB +- 6.4 kB
19:03:30hearn:what proofs are these?
19:04:20gmaxwell:hearn: we can prove that a set of headers is some total work without revealing all the headers. e.g. 15.6 kB instead of ~4mbytes.
19:04:39gmaxwell:using nothing fancier than some extra hash commitments.
19:05:02sipa:as in: could be implemented today in bitcoin, with a soft fork
19:05:17maaku:gmaxwell: sipa's simulations and mine seem to agree that fancy edge selection doesn't gain much
19:05:26gmaxwell:this could help make SPV clients more dos attack resistant— e.g. fetch first from a peer that proves it has a chain with the most total work, but its mostly interesting for other applications.
19:05:46maaku:yesterday we thought it'd get you about 25% less hashes (although smaller gain in serialization size, since that's neglecting block headers)
19:05:55hearn:hmmm. yeah. header fetch time isn't really an issue with today's wallets
19:06:09sipa:hearn: it would avoid the need for checkpoints in SPV clients
19:06:10justanotheruser:Is coinwitness still SPV security if you have both the mainchain and the altchain?
19:06:10maaku:now it seems that committing to all prior blocks is better, although that may not be an apples-to-apples comparison
19:06:26amiller:maaku, what fancy edge selection scheme did you use?
19:06:56hearn:* hearn shrugs
19:06:57amiller:maaku, sipa, did either of you read the expander graphs sequential proof-of-work paper that basically describes a fancy selection routine that gains a lot?
19:07:05hearn:sure. but that system works OK for people today
19:07:07sipa:amiller: the best i found was assign a "level" to each block, depending on its ratio between hash and target
19:07:16maaku:amiller: basically skip lists. sipa looked at classifying blocks into 'levels' based on their aparent pow, and linking back to the most recent block of each level
19:07:22sipa:hearn: this channel isn't about "today's system" :)
19:07:26hearn:that's true :)
19:07:34gmaxwell:hearn: right. Thats why I said 'dos' attack. e.g. someone could be spamming you with diff 1 headers forever at very low cost. But thats not the motivation for the work.
19:07:41sipa:amiller: the best i found was assign a "level" to each block, depending on its ratio between hash and target, with levels around a factor 1.07 apart
19:08:00amiller:sipa, maaku, this is the paper i'm referring to, i haven't figured out how to implement it yet though http://www.cs.virginia.edu/~mohammad/files/papers/15%20TimeStamp.pdf
19:08:20gmaxwell:(the main motivation is to build transaction signatures that prove the existance of transactions in other chains, but nice that it might have other uses too)
19:08:38maaku:i also looked at choosing the best block for a given window, assuming that 'best' means something like 'reduces some average of shortest paths'
19:08:42amiller:it uses "expander graphs" and refers to some other paper i haven't been able to parse, about "zig-zag graph products" and such, which I still think amounts to a pretty simple routine to write down i just haven't figured out what it is
19:08:59maaku:but the general case is a hard problem
19:09:17maaku:thanks amiller, I'll look at it
19:09:33gmaxwell:maaku: did you try my dynamic programming path to genesis? e.g. I expect fancy in the average case is not a huge win, but I would be surprised if the get to genesis case wasn't.
19:11:21gmaxwell:it's very simple. starting at the genesis, for every block store a distance to genesis. To set this value, consider the completed blocks' valid edges and find the prev with the lowest distance, and add one.
19:12:13maaku:gmaxwell: we have not explicitly tested a selection mechanism that would bias path-to-genesis
19:12:43maaku:we were unconvinced that it was a good approach, but getting actual data would be better
19:13:02gmaxwell:for a new block pick lengths like— e.g. sipa was with difficulty steps. and then use as your edges the blocks within the allowed length that has the shortest path. (omitting longer ones that are the same length to genesis as shorter ones)
19:13:06gmaxwell:yea, we should have the data.
19:13:40gmaxwell:if, e.g. it resulted in proofs some huge amount smaller, then it might even be useful to commit to both at a cost of just an extra level in the commitment tree.
19:22:32hearn:gmaxwell: multi-linear maps are moon-math, right? nobody has a real instantiation of them, iiuc
19:26:15gmaxwell:hearn: they're moon of jupiter map rather than just conventional moon math. There are proposed cryptosystems based on things like lattices (learning with errors problem) that apparently yield multilinear maps, there is even a bit of code: https://github.com/tlepoint/multimap
19:26:52justanotheruser:Is coinwitness still SPV security if you have both the mainchain and the altchain?
19:26:55hearn:right, i've seen LWE based crypto. the idea of an encryption having "noise" is rather scary :)
19:27:31maaku:justanotheruser: what are you asking about? coinwitness per se doesn't have anything to do with alt chains
19:28:00maaku:you mean a pegging and/or proof-of-transaction-witness of an off-chain solution, I think?
19:28:08maaku:in that case it depends on your construction
19:28:10gmaxwell:I assume justanotheruser is talking about the 2-way peggyness that I suggested in it. And thats a tricky question. By the consensus rules it would be only SPV security.
19:28:14justanotheruser:maaku: Yes, I thought they were the same
19:28:52gmaxwell:But there are some interesting questions about incentives if you start assuming most miners are verifying both chains.
19:29:18gmaxwell:Because they could be effectively enforcing full security as has soft forking rule on the other chain— even 'undetectably' (until a block get orphaned for violating it)
19:30:21gmaxwell:I don't consider that very virtuious because it creates tight coupling which is bad for reliability and personal autonomy (can't mine safely unless you verify both), but I can certantly imagine situations where it would make sense.
19:30:55maaku:justanotheruser: having a quieting period where people can counter an spv proof with a longer spv proof (a "reorg proof") gives some reasonable assurance that what makes it on the chain is actually the most-work side chain
19:30:59justanotheruser:gmaxwell: I'm a bit confused. If you have both chains, how is it SPV. If you run a full node for both chains, I would have assumed non-SPV.
19:31:22sipa:justanotheruser: that requires one system to be aware of the full node rules of the other
19:31:31maaku:justanotheruser: you have two chains, A and B. people running A may not be running B and vice versa
19:31:31sipa:which makes them very tightly coupled
19:32:05maaku:you can move funds from A -> B by giving the B nodes an SPV proof of what was going on in A, or vice versa
19:32:47justanotheruser:How secure do you think that is then?
19:33:02maaku:as secure as the merged mining hash rate of the side chain
19:33:08gmaxwell:(I think the most useful examples are basically full security one way, SPV the other)
19:33:28maaku:gmaxwell: meh, I don't like spoke architectures
19:34:09justanotheruser:maaku: yes, but with the usual SPV client, you have to figure out who you're going to be attacking and then compromise the oblisk (or whatever software they're running) servers.
19:34:28justanotheruser:Here it seems like you just have to see a bunch of money on an altchain and try to take it
19:34:50justanotheruser:Ofcourse it isn't as trivial as just trying to take it
19:34:56justanotheruser:you still have to expend hash-power
19:35:10gmaxwell:justanotheruser: yes, though thats also true of the altchain in general. Eg. reorg. the whole thing away or doublespend it into oblivion.
19:36:18gmaxwell:Incentive structure is somewhat different but the resources required in an attack are roughly the same. (in the past a popular attack on altcoins is to double spend exchanges and walk with bitcoins)
19:36:19maaku:justanotheruser: as I said, as secure as the (honest) hash power behind the merged mined side chain
19:36:31justanotheruser:gmaxwell: good point. Seems like miners would have fee-based incentives to merged mine like they do with namecoin
19:36:47justanotheruser:And namecoins hashrate is 2/3rd bitcoins last I checked
19:36:48maaku:justanotheruser: but I don't think you understand SPV mode - there are no central servers involved that you can compromise
19:37:07justanotheruser:maaku: I said an average SPV client
19:37:14maaku:those aren't SPV clients
19:37:17gmaxwell:one way to look at it to imagine that the two systems togeather jointly implement a decenteralized exchange with a programed exchange rate as set by the rules that establish the altcoin.
19:37:24justanotheruser:maaku: Electrum isn't?
19:37:28maaku:justanotheruser: no
19:37:50gmaxwell:maaku: well there is a question about what electrum actually it there. It's a SPV verification client that uses servers (now using more than one in parallel, finally!)
19:38:02maaku:it may use SPV validation internally, as a check, but an SPV client of the bitcoin network talks to peers and doesn't need a central server
19:38:33justanotheruser:I see.
19:39:03maaku:gmaxwell: i would recommend people be strict about terminology. SPV *client* (as in client-server) implies somesort of bitcoin protocol compatability, e.g. the peer-to-peer network
19:39:14maaku:Electrum uses SPV validation, but it isn't an SPV client
19:39:35gmaxwell:fine with me, it's just words. I'll adopt whatever convention other people like.
19:40:31justanotheruser:Is uBTC debate discussion allowed here?
19:40:36gmaxwell:(I cringed a bit at saying electrum wasn't spv in part because I bludgoned them quite a bit about needing to implement that, and they've really done a good job at doing a lot of work just because people said it needed to be done, and I feel somewhat guilty about that :) )
19:40:40sipa:justanotheruser: i vote no
19:40:45maaku:or maybe we should invent a new word like "SPV peer" to mean the original definition of a lightweight bitcoin p2p node
19:40:45gmaxwell:I don't think anyone here would find it interesting.
19:40:52justanotheruser:sipa: it is a bit trivial
19:41:34justanotheruser:maaku: centralized SPV client?
19:41:46justanotheruser:for the other meaning
19:41:48wumpus:justanotheruser: NOOOOOOOOOO
19:42:11sipa:wumpus expresses my opinion better than it did myself
19:42:17justanotheruser:Why not?
19:42:28justanotheruser:It is partially centralized
19:43:05gmaxwell:he's responding to the µBTC question.
19:43:52justanotheruser:I see. It's most of the discussion in the mailing list recently though
19:44:37justanotheruser:Anyways, lets not talk about it since it doesn't mean much
19:44:42gmaxwell:justanotheruser: the lines aren't entirely clear, for example with electrum now connecting to multiple servers (note: I've not audited this, so I'm going on extrapolation from what thomasv told me he was doing last time I whined about it) the security model is much closer to the natural network node spv.. but just with special really unscalable network nodes required.
19:45:27gmaxwell:(OTOH, they're actually stronger against some attack models, esp if the ssl cert validation is working)
19:45:54gmaxwell:e.g. a local network attacker who wants to see your transactions.. (though I note the use of tor w/ classical SPV nodes also increases strength here)
19:46:19justanotheruser:gmaxwell: Why? Because they're more trusted than a malicious entity that finds your IP and that you're running SPV and adds you
19:46:30justanotheruser:Oh
19:46:49phantomcircuit:gmaxwell, i dont think the ssl validation stuff works quite right
19:47:15gmaxwell:just the "these few things can attack with 100% success" is sometimes superior to "anyone can attack with small% chance of success per attempt"
19:55:40gmaxwell:Sorry I'm so often so uhh ... oricular here. In reviewing the logs after amillers request... I see that several times I said I knew how to do things {in the pegs space} stuff but didn't elaborate at all. ... and then bluematt asked a direct question, and I basically busted out with a rather large high level description of approach seemingly from nowhere.
19:55:45gmaxwell:It's not my intention to do that.
19:55:52gmaxwell:er of an approach*
19:57:23amiller:hah.
19:57:27gmaxwell:I had mostly considered the idea already published as part of the coinwitness page. I think I sometimes later think my posts also included all the other things that I was thinking about when I wrote them... and just about everything I write up is already much larger than most people's attention spans, so it's usually not actually the case.
20:00:39maaku:sometimes you just have to draw the lines connecting the dots :\
20:00:41maaku:e.g. coinjoin
20:01:55gmaxwell:it's hard too though because I think a lot of things we discuss are piled on complexity deep enough that you'd make no progress to explain it all every time. E.g. if I had to explain a hash tree every time I invoked one.
20:04:43justanotheruser:Does this guy seem like he knows what he's talking about? He claims to have implemented coinjoin with blind signing https://bitcointalk.org/index.php?topic=421615.msg5693650#msg5693650
20:05:06maaku:justanotheruser: who knows; there's no source code
20:05:40justanotheruser:maaku: yeah, I know we can't know if he's right, but I thought you might be able to tell if he's wrong
20:08:16maaku:justanotheruser: the "DarkSend" mixing is not CJ
20:08:33maaku:well, it is
20:08:44maaku:it's just not the same mixing use case discussed in the CJ thread
20:09:12maaku:I'm just not sure if this application actually achieves a large enough anonymity set
20:09:33justanotheruser:maaku: why not?
20:09:36maaku:*and*, unless there's source code I'm not sure if it's implemented correctly
20:09:46justanotheruser:^the most important point
20:09:57maaku:e.g., is he using anonymous channels to do the blind revelation?
20:10:14maaku:if not then you basically are announcing to the other people which outputs are yours, making the mixing irrelevant
20:11:22maaku:justanotheruser: frankly, I just don't understand this diagram: https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2FXMwyU74.png&t=538&c=AM66-UwnhrqMEw
20:29:13gmaxwell:hey ... interesting point
20:29:33sipa:.
20:29:57gmaxwell:the idea I gave for moonmathy improvments to the fractional reserve proofs, where you prove what coins you hold under a zero knoweldge proof by proving that a blinded pubkey's non-blinded version is a member of a set.
20:30:48gmaxwell:That construction is actually a ring signature.
20:31:11gmaxwell:I'm not sure that I've seen any EC ring signatures with log(anonymity set) scaling before.
21:55:23area_:area_ is now known as area
21:55:53area:area is now known as Guest69421
21:56:37Guest69421:Guest69421 is now known as area