wumpus changed the topic of #bitcoin-wizards to: This channel is is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
<gmaxwell>
Somewhat analogous to the ring-ct stuff that Shen and Adam Back had written about in the past.
<gmaxwell>
Scheme in the paper describes a pederson commitment + range proof which is about half as efficient as CT, but the replacement is a drop in.
<gmaxwell>
One requirement is that the anonymity set for assets is limited to those txouts where the scrippubkey is known.
belcher has joined #bitcoin-wizards
<gmaxwell>
Expecting exchanges to reuse addresses to accomplish this is bad mojo, plus expecting participants to trawl the whole 50+GB blockchain to extract all keys is sort of annoying; I'd suggest instead someone just run a service where anyone can submit pubkeys to for inclusion in this.
<MRL-Relay>
[tacotime] You could encourage P2PK.
<maaku>
tacotime: why? that has its own disadvantages
<gmaxwell>
Makes me want to go write a two party ZK millionares problem (x<y test) implementation for pederson commitments so that people can use the assets proof from this find out who has more bitcoins without revealing which coins or how much. :P
<gmaxwell>
maaku: read above.
<MRL-Relay>
[shen] interesting
<maaku>
gmaxwell: i know, but I mean solving one problem by introducing other problems isn't very satisfactory
<gmaxwell>
belcher: this could be used to do "proof I have coins" without revealing which ones for JM, but I think it's too computationally expensive.
<MRL-Relay>
[tacotime] maaku: I don't know if they're catastrophic. 33 bytes versus 20. And you could use the public key outputs for ring signature systems that enable anonymous voting on threads/whatever based on the outputs you own on the blockchain.
<gmaxwell>
maaku: P2PK doesn't really introduce any problems certantly not over and above reuse.
<maaku>
tacotime: quantum hardness
<belcher>
cc waxwing @ JM comment
<belcher>
ty gmax
<MRL-Relay>
[tacotime] maaku: Monero hasn't had any issues yet. The pubkeys have to be published for the ring signatures.
<gmaxwell>
tacotime: <blinks>
<MRL-Relay>
[tacotime] Er... don't they? For outputs?
<MRL-Relay>
[tacotime] We don't P2PKH.
<maaku>
tacotime: ... you don't see a quantum crypto break coming
<MRL-Relay>
[tacotime] Well, not in the short term. But anything is possible.
<gmaxwell>
tacotime: no, thats not my blinking reason. Maaku is talking about weaknesses to future attacks which are presumed to not be in the wild (yet), ... absence of problems so far is seldom a good metric for security, in any case!
<MRL-Relay>
[tacotime] Right.
<maaku>
tacotime: to expand, in the event of a quantum computer large enough to break secp256k1, any revealed public key could be broken at leasure and then all coins stolen at once, en masse
rusty has joined #bitcoin-wizards
<sipa>
TIL: on a quantum computer, hash collisions can be generated in n^(1/3) time
<maaku>
whereas with P2PKH and no key reuse you only have a brief 10-minute window to break and RBF public keys in the mempool
<MRL-Relay>
[tacotime] maaku: Yes, certainly Monero would be a popular target in the even that Ed25519 was QC killed. And yeah, sipa, so the security of RIPEMD160 is down quite a bit.
<MRL-Relay>
[tacotime] 160-bit hashes may also fail to be secure.
<MRL-Relay>
[tacotime] Though you can always OP_HASH256 instead... or add bigger hash functions.
<gmaxwell>
sipa: IIRC DJB has a complaint about that number, owing to the fact that it disregards communication costs.
<gmaxwell>
tacotime: for normal p2pkh collission security is not interesting.
DougieBot5000 has quit [Quit: Leaving]
<gmaxwell>
second preimage security is.
ThomasV has quit [Ping timeout: 240 seconds]
<MRL-Relay>
[tacotime] Yeah, I can't find much of anything on QC and second preimage resistance.
<gmaxwell>
tacotime: its n^(1/2) via the grover algorithim, which is a proven tight bound, at least in the single target case.
<gmaxwell>
(tight for generic functions of course, some specific hashfunction could be specially weak. :) )
<MRL-Relay>
[tacotime] Oh, okay. So, I guess you just double the hash sizes for comparable security. Whereas the issue with the DLP and factoring is way more severe.
<gmaxwell>
maybe. it's hard to say, a lot of costs end up ignored in these asymtopic analysis.
<gmaxwell>
zmanian: Thanks! (esp for the blog link, I haven't seen it yet)-- I linked the paper above at 15:28, and was just talking about it some.
<zmanian>
I went to Joe's practice presentation of the paper at Stanford. Glad to have the paper to clarify some of things I understood only incompletely. It is unfortunate that HSM hardware doesn't support generating the commitments to private keys needed for the second half of the proof.
orik has joined #bitcoin-wizards
snthsnth has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 255 seconds]
snthsnth has quit [Ping timeout: 250 seconds]
archobserver has quit [Quit: Leaving]
gill3s has quit [Read error: Connection reset by peer]
orik has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
orik has joined #bitcoin-wizards
orik has quit [Client Quit]
DougieBot5000 has joined #bitcoin-wizards
giel__ has joined #bitcoin-wizards
mrkent has joined #bitcoin-wizards
moa has quit [Quit: Leaving.]
gielbier has quit [Read error: Connection reset by peer]
giel__ is now known as gielbier
gielbier has quit [Changing host]
gielbier has joined #bitcoin-wizards
orik has joined #bitcoin-wizards
Yoghur114 has quit [Remote host closed the connection]