sipa changed the topic of #bitcoin-wizards to: This channel 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
airbreather has quit [Read error: Connection reset by peer]
airbreather has joined #bitcoin-wizards
chjj has quit [Ping timeout: 268 seconds]
_whitelogger has joined #bitcoin-wizards
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
shesek has quit [Ping timeout: 268 seconds]
dnaleor has quit [Quit: Leaving]
str4d has joined #bitcoin-wizards
TheSeven has quit [Remote host closed the connection]
TheSeven has joined #bitcoin-wizards
pro has quit [Quit: Leaving]
belcher_ has quit [Quit: Leaving]
Dyaheon has quit [Ping timeout: 276 seconds]
Dyaheon has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 260 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
mryandao is now known as sleepyhead
sleepyhead is now known as mryandao
echonaut has quit [Remote host closed the connection]
echonaut has joined #bitcoin-wizards
str4d has quit [Ping timeout: 276 seconds]
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #bitcoin-wizards
Transisto2 has joined #bitcoin-wizards
Transisto2 has quit [Ping timeout: 260 seconds]
Transisto2 has joined #bitcoin-wizards
Transisto2 has quit [Client Quit]
Transisto2 has joined #bitcoin-wizards
arowser has quit [Ping timeout: 260 seconds]
Transisto2 has quit [Client Quit]
arowser has joined #bitcoin-wizards
huseby has quit [Ping timeout: 240 seconds]
huseby has joined #bitcoin-wizards
arowser has quit [Remote host closed the connection]
HSF_HIGHFckHed has quit []
arowser has joined #bitcoin-wizards
HSF_HIGHFckHed has joined #bitcoin-wizards
PaulCapestany has quit [Read error: Connection reset by peer]
PaulCape_ has joined #bitcoin-wizards
ivan has quit [Quit: lp0 on fire]
cluckj has quit [Quit: Leaving]
MaxSan has joined #bitcoin-wizards
blackwraith has joined #bitcoin-wizards
rusty has quit [Ping timeout: 260 seconds]
_whitelogger has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 248 seconds]
<jonasschnelli>
sipa: DID == digital identity (web of trust stuff)
<jonasschnelli>
From what I know it could be a more efficient way then just publishing keys to a keyserver
<sipa>
lol!
<sipa>
using a decentralized system that publishes revocations to the entire world is more efficient than a central server?
<sipa>
what are you smoking
<jonasschnelli>
What's wrong with having identity keys and a revocation puzzle on the Blockchain? Everyone could verify the ID (by a given transaction reference) and check if it's revoked or valid. Use the pubkey to authenticate a new secure channel?
<gmaxwell>
jonasschnelli: key expiration is guarenteed to work, revocation otherwise requires a censorship proof channel. Bitcoin doesn't provide one of those. E.g. miners can just block your revocation. Our defense against censorship is anonymity but it doesn't work for an identity because uh. identity is the opposite of anonymity (e.g. the person who stole your key just tells miners to block it)
<jonasschnelli>
Could adam's commited transaction solve that?
<gmaxwell>
no, because none of that stuff works at all.
<gmaxwell>
it's pure handwave.
<jonasschnelli>
Okay.
<jonasschnelli>
But I guess the censorship question applies also to pure payments...
<gmaxwell>
it doesn't though because payments aren't identities, they can be anonymous.(and even when they're not completely anonymous, they're not persistant, they're ephemeral)
<gmaxwell>
There are plenty of very good techniques for dealing with identities that already exist-- both expiration (used by PGP and SSL) and stapled non-revocation-timestamps (used by SSL). They don't make any assumption of an uncensored channel.
<jonasschnelli>
I see
<gmaxwell>
As an extra aside, there is no efficient way in bitcoin for a lite client to read a by given a proof of non-revocation.
<jonasschnelli>
I'm currently interested in reviewing concepts that would allow decentralized multisig setup and sharing of partiallly signed transaction in an easy way. Maybe I'm looking into the wrong direction
<gmaxwell>
O_o so what subproblem are you trying to solve specifically?
<jonasschnelli>
I guess it's pure communication in a secure decentralized way
<jonasschnelli>
Shared pubkeys within a group, shared partially signed blobs
<gmaxwell>
It's unclear to me what you're asking... Can you state it in terms of a user story? Alice wants to X, Bob wants to Y?
<jonasschnelli>
Sometimes like Copay is doing but without the central server
<jonasschnelli>
(Boarding soon, will answer delayed)
PaulCapestany has joined #bitcoin-wizards
PaulCape_ has quit [Read error: Connection reset by peer]
<jonasschnelli>
GAssume Alice wants to create a 2of2 with Bob. Alice needs authenticated pubkey(s) from Bob. Bob needs the same from Alice. Alice later wants a partial signed transaction from Bob to complete a payment
<jonasschnelli>
gmaxwell: It's a pure "secure communication in a complete decentralized way" problem AFAIK.
<jonasschnelli>
Concrete use case: throw away bitpay wallet backend and allow hardware wallet owners to setup a multisig wallet without central servers.
<jonasschnelli>
Because they should not want (I know most don't care) to publish an xpub to Bitpay.
<jonasschnelli>
(Or any other authority)
<gmaxwell>
jonasschnelli: I don't see how you hope to address that by creating identies. AFAIK copay uses the server because it's a lite wallet, like electrum.
<gmaxwell>
(And it doesn't require any authority, AFAIK-- you can run your own server for it, at least if you're willing to deal with the undermaintained hacked up 'bitcore' stuff)
<jonasschnelli>
gmaxwell: running your own BWS is an expert only thing. I'm looking for a solution that could work in a pure p2p way. Maybe I'm looking for utopia.
<jonasschnelli>
gmaxwell: I thought DID could help to create a pure censor ship resistant p2p communication network (that could be used to setup multisig, etc.)
<jonasschnelli>
You need a proof-of-burn (OP_RETURN) to communicate on that network.
<gmaxwell>
... why would you do that rather than just using your ownership of a UTXO in the first place? but moreover-- why the decenteralization theater? ultimately (beyond just having the wallet stuff) it sounds like you're just trying to solve nat traversal.
<jonasschnelli>
gmaxwell: not only nat traversal,... also temp. message storage. Peers should be okay to be offline a couple of days/hours and not loose a message.
<gmaxwell>
so, email? :P
<jonasschnelli>
gmaxwell: yes. I have thought about it.. but email is slow, hard to run a "peer" and not really censorship resistance. Also, there is no real spam protection.
<gmaxwell>
I don't see how spam protection is an issue-- the users already have some communications channel or they wouldn't know who they are. So they would punch in each other's IDs.
<gmaxwell>
and email is one of the most censorship resistant communications methods available; assuming you can get on the internet at all.
<jonasschnelli>
It would be if people would use email. But they are using gmail, or hotmail and maybe the use IMAP
<gmaxwell>
but thats their choice, and if it causes them problems they can move to something else; which is part of why it has perfect censorship resistance.
<jonasschnelli>
Yeah. Maybe. But the current email option has significant downsides over Copay, etc.
<gmaxwell>
I think what you want could just be as simple as a trivial message relay that anyone can easily run that has a nat-hole-punchable net connection, and then a simple URI scheme that when I invite you to share a wallet with me, the URI can include N servers. And if there are problems with any of them, you can simply configure more/different ones in the wallets to reestablish communications.
<jonasschnelli>
Using email in the background in a wallet application seems disastrous.
<gmaxwell>
but ultimately this is just reproducing the service that email and XMPP provide, writ-small.
<gmaxwell>
there is utterly no trust in the relays other than if all your relays go down, you'll stop communicating and need to configure more of them. Making it pretty uninteresting to bother taking any of them offline except by accident.
MaxSan has joined #bitcoin-wizards
prime__ has joined #bitcoin-wizards
prime_ has quit [Read error: Connection reset by peer]
dnaleor has joined #bitcoin-wizards
MaxSan1 has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 268 seconds]
_whitelogger has joined #bitcoin-wizards
marcoagner has quit [Ping timeout: 276 seconds]
blackwraith has joined #bitcoin-wizards
MaxSan1 has quit [Ping timeout: 240 seconds]
PaulCapestany has quit [Ping timeout: 240 seconds]
PaulCapestany has joined #bitcoin-wizards
PaulCapestany has quit [Read error: Connection reset by peer]
PaulCape_ has joined #bitcoin-wizards
marcoagner has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
pro has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
MaxSan has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
daszorz has joined #bitcoin-wizards
dnaleor has quit [Ping timeout: 260 seconds]
str4d has quit [Ping timeout: 248 seconds]
dnaleor has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
priidu has quit [Remote host closed the connection]
Guyver2 has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 248 seconds]
pro has quit [Quit: Leaving]
belcher_ has joined #bitcoin-wizards
daszorz has quit [Ping timeout: 240 seconds]
priidu has joined #bitcoin-wizards
daszorz has joined #bitcoin-wizards
arubi has quit [Remote host closed the connection]
arubi has joined #bitcoin-wizards
pro has joined #bitcoin-wizards
<bsm1175321>
"gmaxwell: jonasschnelli ... key expiration is guarenteed to work, revocation otherwise requires a censorship proof channel. Bitcoin doesn't provide one of those. E.g. miners can just block your revocation."
<bsm1175321>
This ignores the competitive nature of mining. Bribing ALL miners to block your revocation and/or or ALL nodes to not propagate your revocation is a very serious threshold for censorship resistance. Far better than any centralized key publication mechanism I know of.
<bsm1175321>
I can bump the fee on my revocation.
<kanzure>
what was the problem with expiration, again?
<bsm1175321>
Don't know, I was talking about pure revocation, which is not timestamped...but you could put a timelock/CSV on your revocation transaction if you wanted. But it's still up to you to broadcast it, and when.
<bsm1175321>
(IMHO "expiration" is moronic...you want keys to expire when they're lost/stolen and you have no idea when that will be...expiration is a poor man's solution to the problem of not having any revocation channel at all)
<kanzure>
seems like we're going in circles about proof-of-publication
<bsm1175321>
(for authentication/identity keys anyway...RSA encryption keys are another matter because of ciphertext attacks)
<kanzure>
could you pay for revocation proofs with zero-knowledge contingent payments?
<kanzure>
possibly in some kind of payment channel
<bsm1175321>
kanzure: yes and this is why I've been harping on UTXO set commitments. I've been building a system gmaxwell and jonasschenlli are puzzling about above, and you need both proof of presence and proof of absence in the UTXO set.
<bsm1175321>
kanzure: why use a ZKCP? A revocation can be a standard transaction. "spentness" indicates revocation to an observer in the know.
<kanzure>
with revocation via zkcp i think the degenerate case ends up being DoS or "your p2p network peers are lame and the value you are offerig is less than the value of you continuing to think the key is not revoked" or something
<kanzure>
well look, this is fundamentally the same problem as information withholding, you have to pay someone no matter what (whether via block subsidy or some other payment mechanism)
<bsm1175321>
ZKCP reduces to a pay-to-hash-preimage with a fancy offline ZKP program. What does the ZKP program do in this case?
<kanzure>
you would pay them only if they can provide proof of revocation
<bsm1175321>
Yes, you have to pay someone. Revocation transactions have fees.
<bsm1175321>
kanzure: who are you paying for proof of revocation and why?
<kanzure>
some unspecified peer network. not necessarily censorship resistant. you need to find a single node that can provide such a proof, in exchange for your monies.
danrobinson has joined #bitcoin-wizards
<bsm1175321>
FYI I'm re-using your spent bitcoin keys as the key publication mechanism. "Revocation" is an additional spend. So both publication and revocation and proof thereof is all in the UTXO set itself.
jouke has quit [Ping timeout: 258 seconds]
<kanzure>
information withholding is the root problem here. and you want miners (or whoever is publishing information) to have an incentive to do so. the block subsidy provides this in the blockchain model. in a revocation-related zkcp the incentive is the direct payment.
<bsm1175321>
Oh I see, you want to use bitcoin as a payment channel for a separate publication mechanism with a separate key distribution network. Now just to design the rest of that key distribution network... ;-)
<kanzure>
i'm not sure you need global publication of a revocation in the zkcp case. you only need to find a node that can make the proof (and who also wants your proof more than they profit from keeping you in the dark).
bsm1175321 has quit [Remote host closed the connection]
bsm117532 has joined #bitcoin-wizards
<kanzure>
er, i should make that last message less strong
<kanzure>
why do you always need global publication for a revocation..?
<bsm117532>
Well you need publication to the set of people who care. Under the assumption that I'm going to give my identity pubkey to a random set of strangers (Amazon, Paypal, Ebay seller, etc) keeping track of that set of strangers is a big headache.
<kanzure>
i think it's a result of the asynchronous nature of the private channel established by giving out the key; if you can't go back to the originator and say hello then you need access to the updates through a different channel, right?
<bsm117532>
The idea is that you don't have a private channel to the originator. (I mean, you never do in a p2p context)
<kanzure>
well i mean somehow you got the key in the first place. heh.
<kanzure>
s/got/received
<bsm117532>
No you didn't. ;-)
<kanzure>
huh? then why are you looking for a revocation?
<kanzure>
for an unknown key..?
<bsm117532>
Well...I take that back. Yes you always need an initial establishment of the key. If that's compromised you're fucked.
<kanzure>
of course.
<bsm117532>
Maintaining a set of private channels is a big headache.
<kanzure>
it should be more like: publish the key plus 'trackers' (various routes to get updates if you can't find any from your peers) (yes these could all be shutdown), pay the trackers for the revocation proof using zkcp.
<kanzure>
(standard disclaimers apply: the value of keeping you in the dark about a revocation might exceed what you're capable of paying for the revocation proof)
<bsm117532>
Trackers need censorship resistance though, and bitcion/PoW is the best way I know of doing that.
echonaut has quit [Remote host closed the connection]
echonaut has joined #bitcoin-wizards
<bsm117532>
Why pay for a ZKCP revocation proof? This is presumably something you will want to look up often for many communicating parties. I'd rather just keep a UTXO set myself (or something like it) and track the updates I care about. I can look up the revocation by myself.
<kanzure>
i'm not convinced that the only way to get the revocations is from a global universal consensus publish system; i could see that as necessary if your users are incapable of paying (like IoT devices maybe-- as much as i dislike the concept) where the overall value of compromise is high but the devices can't pay for the proofs.
<bsm117532>
You don't want lookups to incur a blockchain payment...the blockchain is rate limited.
<kanzure>
but for you to argue that there's no way for you to have other channels-- other than a global publish system- to get the info, that seems like an extreme situation right? no routing at all from peers over any number of possible channels?
<bsm117532>
This "extreme situation" is called bitcoind. That's *exactly* the way it works.
<kanzure>
bsm117532: i agree re: *lookups*. the requests would be: here is the key, you guys got any revocation proofs? someone responds yes, you setup zero knowledge proof with that peer, they lie then you dosban them. they make a valid proof, you setup the H(revocation) zkcp etc.
<bsm117532>
So you're paying some kind of "identity node"? After that you want to cache it though? This implies a 3rd kind of network?
<kanzure>
you don't need anti-replay for revocation publication..
<kanzure>
"identity node" no idea. "After that you want to cache it though?" locally? i mean once you know the key is revoked, you know not to accept authorizations from that key- you could throw away the proof if you want, or join the network and make money from selling the revocation i guess.
<bsm117532>
How many people need to get this proof of revocation though? There's one blockchain payment for each party...
<kanzure>
i think without a bockchain my proposal requires an extremely high latency network-- if you need to know the revocation in a timely manner after the creation of the revocation, no way to guarantee routing through a highly censored network in a timely manner.
<kanzure>
(other than the payment incentive for nodes to figure out how to deliver the product to their customers. which might not be enough to overcome the effect of censorship attempts.)
<kanzure>
bsm117532: yeah i agree there's a payment per party, that's definitely a problem. i was thinking payment channel, but i don't know if that can work with zkcp without committing to blockchain.
<kanzure>
ALSO there might not be any computationally feasible zero knowledge proof of revocation at the moment
<bsm117532>
BTW I definitely need to rethink my ideas WRT Lightning and what can be done with payment channels...on my TODO...
<bsm117532>
kanzure: I still don't understand the "Zero Knowledge" part of your argument. What does the ZKP program compute?
<kanzure>
i believe you would receive a proof that H(revocation) is the hash of a valid revocation for some key, they give you the proof and the hash and then you make a payment that requires them to reveal the preimage of H(revocation)
<bsm117532>
There is no ZKP program in that statement. It's pay to hash preimage puzzle.
<kanzure>
the program is the one that generates the proof yo
<bsm117532>
Oh you want to encode some conditions for the valid revocation?
<kanzure>
if you don't know the revocation then you certainly don't know H(revocation). they give you H(revocation) and a proof that it is a valid revocation. they are trying to prove to you that they know some value 'j' for H(j) satisfies the proof program.
<bsm117532>
I just did this by using the UTXO set. The condition is that a particular UTXO gets spent...and that is the revocation. Your counterparty knows which UTXO to look for.
<bsm117532>
I don't think you need anything as complicated as a ZKP. Your counterparty DOES have the knowledge of your key and where they got it. So there's nothing to hide with a ZKP.
<kanzure>
i think the payment channel version would be: they give you the proof, you check its validity, you add a transaction to the channel history to pay them for the preimage, they provide you the preimage, then you both agree to excise that transaction from the history and instead just update the total payment channel transfer between the parties anyway. so i guess this doesn't really require a w...
<kanzure>
...ay to make it on to the blockchain (for the purposes of incentivizing the reveal).
<kanzure>
"Your counterparty DOES have the knowledge of your key and where they got it." please elaborate. in my zkcp proposal, i'm assuming that the person paying for the proof is someone who isn't alice but knows alice's key and doesn't know about alice's revocation.
<bsm117532>
Payment channels are private though. The purpose of an identity key is that you give it to multiple people.
leonidaz0r has quit [Ping timeout: 240 seconds]
<bsm117532>
I'm using a 2-stage commit for the revocation. The key is published along with a revocation convention (in my case, a UTXO spend). If all you have is the key, there's no way to know when it is revoked -- the key itself doesn't have this information and anything signed with this key is compromised once the key is compromised.
<bsm117532>
I believe in cert contexts this is done by publishing a separate "revocation key" in the certificate...
<kanzure>
the revocation could include the latest blockhash minus like 100 blocks back, therefore you would know that the revocation was created at least after -100 blocks from that point or whatever. i doubt that's a real problem. :P
<bsm117532>
Which is *different* from the auth key
<kanzure>
oh a key can't just revoke itself? that's lame.
<bsm117532>
Heh no.
<kanzure>
so if the private key gets leaked, a good samaritan can sign subkeys but he can't sign the revocation? who designs this stuff.
<bsm117532>
depends on which system you're talking about.
<kanzure>
i guess the revocation would be "here's the private key yo, is that enough proof for you"
<kanzure>
13:40 < bsm117532> Since blockchain data can be independently validated against the block headers, blockchain data censorship reduces to (a) falsifying PoW headers or (b) isolating the target from contacting non-censoring servers (e.g. DDoS).
<kanzure>
(trying to find a more succint statement about the information withholding problem, its relationship to bandwidth exhaustion, and censorship resistance)
<kanzure>
the way partial block redaction/withholding/censorship is 'solved' is by all the nodes requiring all the content for the block to be known and validated. otherwise you're giving subsidy to withheld block contents-- and consequently your revocations don't get the wide publication you were hoping for.
<kanzure>
"This "extreme situation" is called bitcoind. That's *exactly* the way it works." bitcoin does not provide magical publish-all-the-data-ever properties. it's bandwidth restricted.
<bsm117532>
Bitcoin doesn't report chaintips for blocks it can't validate.
<kanzure>
heh
<bsm117532>
So yeah it can track a branch with censored data though...
danrobinson has quit [Quit: danrobinson]
<bsm117532>
And there's no subsidy for them because they're not in the main chain.
<bsm117532>
Unless you can both censor and later cause a reorg...but that's a standard 51% attack
<kanzure>
also, i think the zkcp payment channel concept should work for certain other publication of other proofs or whatever, as long as it's zkcp then this should work for proof-of-publication ... modulo all my standard disclaimers about providing a payment valuable enough to overcome any attempts at censorship/routing fails/network partitions. (same as the bitcoin subsidy, really.)
<kanzure>
(s/bitcoin subsidy/bitcoin subsidy and fees/)
<kanzure>
bsm117532: yep i hear you. the concern is more that if you want to publish all the data on the blockchain, block size gets cranked up, you can no longer transfer all the data to all the nodes (because they have bandwidth limitations) and as a result it's indistinguishable from information withholding. so the subsidy needs to be continued to be linked to the rate limiting aspect, otherwise yo...
<kanzure>
...u degrade the global publish aspect.
<bsm117532>
The need to provide payment is what drives me to tie this directly to the PoW asset (bitcoin), as well as the notion that your identity needs to be as valuable as the assets you're signing over with it.
<bsm117532>
kanzure: I haven't solved bitcion's scaling problems, no. (yet)
<kanzure>
yes you need to tie it to money (bitcoin, or zkcp payment of bitcoin) to get an attempt at censorship resistance.
<kanzure>
(bitcoin subsidy or fee reveue, i mean.)
<bsm117532>
But by only publishing keys and revocations, this should be a ~once-a-year transaction per entity, and hopefully is small compared to the number of other transactions that entity is making.
<kanzure>
btw in the global publish blockchain revocation scenario, you are bounded on at least two sides: the revocation tx fee needs to be able to outrun the value of a jammer spending fees for many blocks to prevent your transaction from getting into the block (e.g. the value of the client thinking the key isn't revoked), and the other side is like.. uh. sorry, i can't put all these parameters int...
<kanzure>
...o words.
Dyaheon has quit [Ping timeout: 260 seconds]
<bsm117532>
One needs the ability to modify fees at revocation time, since you don't know what the fee market will look like in the future.
Dyaheon has joined #bitcoin-wizards
<kanzure>
i think that in the payment channel zkcp revocation proof scenario, the cost of the proof is (1) beared by the client, and (2) its transmission/protocol is not limited by saturation of the bitcoin blockchain available publish space.
<kanzure>
on a very general level, i think we need a sneakernet with extremely high latency for transmitting not only offers to pay for proofs but also for transmitting the published data. otherwise you end up with global chokepoints if everyone is only exclusively looking at bandwidth-limited global publish system.
<bsm117532>
Yeah but there are many more "proofs of revocation" required than "revocations". it's cheaper overall to just publish revocations than pay for proofs.
<kanzure>
i think that in the blockchain scenario your cost of publishing the revocation is going to be something like: the sum value of an adversary keeping all your clients in the dark about the revocation, so you have to pay to overcome that particular quantity/value of censorship resistance.
<bsm117532>
Basically
prime_ has joined #bitcoin-wizards
daszorz has quit [Read error: Connection reset by peer]
<kanzure>
my revocation zkcp scheme obv. fails in the same case: local client who needs to pay for the revocation proof might not have enough money to overcome the global attempts at censorship of the proof. someone's gotta pay to overcome the value of otherwise withholding.
<bsm117532>
Which comes down to your adversary compromising all miners, or your adversary compromising all your counterparties
bsm117532 has quit [Remote host closed the connection]
<kanzure>
i believe you are right that in the zkcp case that the total cost is going to be greater because the worst case is that every client has to make the proof payment. but is that sum the same in the blockchain case? i mean the cost is certainly beared by different parties, at minimum.
prime__ has quit [Ping timeout: 260 seconds]
bsm117532 has joined #bitcoin-wizards
<bsm117532>
Well it's definitely true that "number of revocation proofs" >= "number of revocations".
<bsm117532>
Unless people are revoking keys they never distributed (which would be dumb)
<bsm117532>
Yes the cost is borne by different parties but in the blockchain case it's the same problem we know and love...how to get more full nodes...
<kanzure>
in the blockchain case, your cost of publication is actually the "either" of between (1) sum value of an adversary keeping all your clients in the dark about the revocation, and (2) the value of all the other publication activity occurring on the blockchain, so you might be flooded out in either case even in not particularly adversarial cases-- opportunistic adversaries might notice that you...
<kanzure>
... can't pay to publish in the global publish system at this time, heh. and in that case the adversary's expenses are way less (they are zero) than the cost of censoring the zkcp peer network or jamming the bitcoin publish system themselves.
daszorz has joined #bitcoin-wizards
<bsm117532>
(1) is not quantifiable in terms of (or fungible with) the blockchain currency.
<kanzure>
what
<bsm117532>
e.g. the adversary can't screw with fees or transactions to make (1) happen
<kanzure>
why not? the adversary has no funding..?
<kanzure>
contrived scenario: a door lock that is looking for the revocation. adversary doesn't have network access. adversary compromises the key, revocation can't make it to the device in time because adversary spends to publish (or: other publication activity is paying higher fee!).
<bsm117532>
Oh...one point...for revocations you really don't care if it gets mined. Getting it in the mempool is enough. You need it to be mined eventually for posterity and validating historical signatures though. But immediate usage of the key can be revoked as fast as the transaction gets in everyone's mempool.
<kanzure>
er, you are claim that mempool is censorship resistant?
<bsm117532>
Well...only in so far as mempool censorship requires a different technique than block censorship.
<bsm117532>
And if I care about a particular transaction (because it's a revocation) I might choose to hold on to it despite mempool flooding.
<kanzure>
if mempool is sufficient then there's your global publish p2p flood network, no need for bloaty mcbloatblocks.
<bsm117532>
Again you still need mining to validate historical signatures (see again petertodd's blog above)
<bsm117532>
I'm describing 2 different uses for the key: validating historical signatures, and immediate authentication.
<kanzure>
one thing i haven't looked at in the zkcp proof payment scheme is that the cost of a payment might on average be quite small, it's not clear to me that the cost beared by all clients would be high or low compared to blockchain publish cost. don't know how to thikn about this right now.
<bsm117532>
BTW have you described this zkcp scheme anywhere? (bitcoin-dev? I've been offline for a while)
<yoleaux>
[bitcoin-dev] The first successful Zero-Knowledge Contingent Payment
<kanzure>
oh, for key revocation. no, i don't think anyone has mentioned it, but it seems sort of obvious, there's probably some fundamental problem with it like "it's computationally infeasible to use zero knowledge to proof knowledge of a valid revocation".
<bsm117532>
You don't need ZK I think. You just need a separate revocation mechanism. Hiding that in mechanism in ZK doesn't buy you anything, I think.
<kanzure>
well the important aspect was the payment
<bsm117532>
Yes you definitely need the payment.
<kanzure>
you have to incentivize the publication
<andytoshi>
the recent "if the buyer makes the CRS then ZKCP is broken" paper dealt with something similar in spirit to this, i didn't fully understand it
<kanzure>
and if you send payment before you have the proof, you're out of luck. symmetrically, same if you publish the proof to the requesting party before you receive payment. so no money passes hands to overcome the cost-resistance of whatever censorship is at play.
<bsm117532>
See it's so much simpler if the payment IS the proof and v/v :-P
<kanzure>
wait what, the buyer can't make the CRS?
<kanzure>
it's a two-peer zero knowledge proof, i thought it's broken if the *seller* can make false proofs by using a manipulated CRS
<kanzure>
paper link plz
<kanzure>
bsm117532: i am suggesting that zkc payment provides incentive for the proof sellers to find ways to route around the censorship. any other revocation publish mechanism will need to overcome the same costs and similarly require payment between untrusting parties.
<bsm117532>
Any payment system has to solve the same problems though.
<bsm117532>
Everything reduces to PoW...
<kanzure>
in the zkc payment channel case, it's just arbitrary payments, and the intermediate steps don't get to the blockchain anyway, not much to censor by the miners. hehe.
<kanzure>
hehe bramc mentioned cert authority stuff just after seeing the zkcp blog post. so uh i guess his throwaway comment is prior art. :P
<kanzure>
16:13 < bramc> Next up: illegitimate cert authorities
<kanzure>
17:00 < bsm117532> bramc: Don't worry, that one is covered. Someone attached this weird "coin" idea to this perfect distributed keyserver I've been working on...
<kanzure>
18:14 < bramc> The 'obvious' applications are fairly black hat, mostly involving paying people for private keys corresponding to important public keys
<kanzure>
18:15 < bramc> Although most of those could be done with simpler techniques as well, particularly public keys of types which are used directly on the blockchain.
<kanzure>
well you could probably do that in a payment channel and not advertise to the whole world that you have the private key
<kanzure>
ah i guess you could publish it post-facto anyway.
<kanzure>
it just wont get into the blockchain, but it's still publishable evidence.
<bsm117532>
grumble grumble haven't been able to publicize what I've been working on grumble grumble
<kanzure>
also: with zkc payment channel method, you don't need to have bonds or collateral posted for each key that you are tracking; istead, when you want to pay for the revocation knowledge, you can use all your funds from your payment channels.
<kanzure>
oh this whole scheme is broken because you can just use the zero knowledge proof as evidence of existence of the revocation key, and therefore not send the actual payment. if you know the proof is valid they either have a backdoor/break in the proof system or they have the key, so they probably have the key if they give you a valid proof. only way to fix this is like dos ban score and an in...
<kanzure>
...itial small upfront payment -- probably mutual escrow of some amount at the initialization of the protocol- and then you get their funds even if they can't generate a proof (so you win if they are lying to you, you get to take their bond).
superkuh has quit [Read error: Connection reset by peer]
danrobinson has joined #bitcoin-wizards
danrobinson has quit [Client Quit]
<kanzure>
i think you could do this without zkcp: if they have the private key then they should be able to sign any number of messages you give them. you could pay for each signature at some nominal rate over a payment channel, they send the signature in cleartext to you, you setup another payment to see if they can generate another one. after a few iterations you should be convinced.
superkuh has joined #bitcoin-wizards
danrobinson has joined #bitcoin-wizards
danrobinson has quit [Client Quit]
<kanzure>
huh. revocation validity is a weird edge case for zkcp. if they give you the zk proof, that's just as good as showing the revocation evidence itself, it's a single bit of data.
<kanzure>
the channel setup would have to be: both parties contribute funds; they mutually sign a payment that burns their coins to neither party; the proof is rendered (zk proof or the revocation evidence); both parties then agree to rewrite the payment to change from burning to paying the correct party.
<kanzure>
ah okay, so if you want to earn money from sharing the proof in the future, you need to do the zkcp to pay for the real evidence. but since you might run away with just the zk proof without making the zkcp to buy the solution, you need to put money into the protocol as a first step to even see the proof of existence of the evidence.
<kanzure>
this first-step lock-up is dos-attackable i think. :(
<kanzure>
if you have a multi-hop network then what you want is for your node to sell the 1-bit zk proof to as many buyers as possible. if you sell the evidence then you're giving up on potential revenue. so you have a hoarding incentive. you need recursive zkcp: you do zk setup, you are paying for all the onion layer intermediaries until you get back to someone who has the actual evidence.
Guest97515 has quit [Remote host closed the connection]
Guest97515 has joined #bitcoin-wizards
harrow has quit [Quit: Leaving]
harrow has joined #bitcoin-wizards
danrobinson has joined #bitcoin-wizards
ivan has joined #bitcoin-wizards
danrobinson has quit [Client Quit]
airbreather has quit [Read error: Connection reset by peer]
airbreather has joined #bitcoin-wizards
PaulCape_ has quit [Quit: .]
Noldorin has quit [Remote host closed the connection]
Noldorin has joined #bitcoin-wizards
thrmo has joined #bitcoin-wizards
pedrovian has joined #bitcoin-wizards
MaxSan has joined #bitcoin-wizards
thrmo has quit [Quit: Waiting for .007]
cyphase has quit [Ping timeout: 240 seconds]
CoinHeavy has joined #bitcoin-wizards
chjj has quit [Ping timeout: 276 seconds]
chjj has joined #bitcoin-wizards
PaulCapestany has joined #bitcoin-wizards
CoinHeavy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
contrapumpkin has joined #bitcoin-wizards
cyphase has joined #bitcoin-wizards
CoinHeavy has joined #bitcoin-wizards
arubi has quit [Remote host closed the connection]
arubi has joined #bitcoin-wizards
goofie has quit [Ping timeout: 248 seconds]
CoinHeavy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
contrapumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Dyaheon has quit [Ping timeout: 240 seconds]
Dyaheon has joined #bitcoin-wizards
mentazoom has joined #bitcoin-wizards
oneeman has joined #bitcoin-wizards
CoinHeavy has joined #bitcoin-wizards
RubenSomsen has joined #bitcoin-wizards
RubenSomsen has quit [Remote host closed the connection]
RubenSomsen has joined #bitcoin-wizards
leonidaz0r has joined #bitcoin-wizards
oneeman has quit [Quit: Leaving]
goofie has joined #bitcoin-wizards
prime_ has quit [Ping timeout: 240 seconds]
PaulCapestany has quit [Read error: Connection reset by peer]
PaulCapestany has joined #bitcoin-wizards
mentazoom has left #bitcoin-wizards [#bitcoin-wizards]
CoinHeavy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arubi has quit [Ping timeout: 248 seconds]
blackwraith has quit [Ping timeout: 248 seconds]
arubi has joined #bitcoin-wizards
AEM has quit [Quit: Ciao!]
MaxSan has quit [Ping timeout: 248 seconds]
AEM has joined #bitcoin-wizards
daszorz has quit [Read error: Connection reset by peer]
PaulCapestany has quit [Ping timeout: 268 seconds]
PaulCape_ has joined #bitcoin-wizards
MaxSan has joined #bitcoin-wizards
cyphase_eviltwin has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 276 seconds]
rmwb has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]