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
weez17_ has quit [Remote host closed the connection]
weez17 has joined #bitcoin-wizards
Murch has quit [Ping timeout: 256 seconds]
hsjoberg has quit [Quit: Leaving]
circ-user-cTpdh has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
Giszmo has quit [Ping timeout: 252 seconds]
AaronvanW has quit [Remote host closed the connection]
meshcollider has joined #bitcoin-wizards
Giszmo has joined #bitcoin-wizards
satwo has joined #bitcoin-wizards
CubicEarths has joined #bitcoin-wizards
jimmysong__ has joined #bitcoin-wizards
jimmysong_ has quit [Read error: Connection reset by peer]
<kanzure>
in this paper ("paralysis proofs") https://eprint.iacr.org/2018/096 the authors propose to use trusted hardware and periodic challenges against multisig members to prove that the authentication set needs to be updated to remove offline/dead/unavailable members. but isn't this going to be vulnerable to DoS attacking a member from submitting a challenge response?
<kanzure>
i guess the idea is that the challenge response size is so small that anyone should be able to upload it through many different means. and assumes no long-term network partitions between any of the mmebers and the challenge server.
<CubicEarths>
"Ultimately, the list of eligible voters is set in a centralized way: it’s produced by the State"
AaronvanW has quit [Ping timeout: 245 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW_ has quit [Ping timeout: 256 seconds]
<CubicEarths>
States, not being efficient markets, seem to have an incentive to exclude participation. Due to the free-market ethos of blockchains, it seems they would benefit from an inclusionary stance.
<kanzure>
stonecoldpat: do you have a good overview link for the numerous ways that secure voting isn't as secure as some folks might expect? your defcon link seems to be about various voting machines, which is a more specific problem but sort of pointless if there's no solution in the first place.
Aaronvan_ has joined #bitcoin-wizards
Aaronvan_ is now known as AaronvanW_
AaronvanW has quit [Ping timeout: 240 seconds]
<CubicEarths>
kanzure: so many different types votes though. A coin-weighted vote could be constructed to be almost perfectly secure... obviously there is no expectation that would represent a count of humans
ne1l has joined #bitcoin-wizards
ne1l is now known as ne1ln
ne1ln has quit [Client Quit]
<sipa>
CubicEarths: miners can censor, if it's about something financially relevant to them
<CubicEarths>
sipa: I think the votes can be cast blindly, and after voting closes, which side the vote was for can re revealed
Murch has joined #bitcoin-wizards
<kanzure>
reveals can also be censored
<CubicEarths>
the reveals can exist off chain
<sipa>
then who gets to reveal?
<CubicEarths>
the people who cast votes
<sipa>
if the chain is a means for censorshio reisstance, then what have you solved if you can't use it for revealing?
<kanzure>
also: separately, i believe it's considered insecure to have a way to reveal a vote because otherwise you get into weirdo coercion scenarios
<sipa>
exactly
<sipa>
good voting schemes have no means to prove what you voted for at any time
<kanzure>
(although i think others have proposed "instead of revealing the content of a vote, the presence of the vote can be guaranteed without revealing the content/valence")
<kanzure>
alsooo for large-scale voting systems, blockchain isn't going to work because of system capacity limitations.
<kanzure>
and the only solution for the voter membership set problem seems to be "everyone knows all members and can independently verify that there's no hidden members in the membership set"
<CubicEarths>
Just because you couldn't use the chain for reveals doesn't mean it was for nothing. The votes themselves need to be secure in a way the reveals do not. There is no double-vote issue with reveals, they can freely disseminated by any means. A more complete set of reveals would always give more information, and two partial sets could easily reconciled
<sipa>
how do you solve coercion?
<CubicEarths>
like a miner demanding a (at least private) reveal before being willing to include the vote?
<CubicEarths>
that kind of coercion?
<sipa>
no, someone that holds a gun to your head and says prove to me you voted for the right thing or i shoot you
<sipa>
paper ballots are secure against this by not allowing others insode the booth
<Alanius>
well, unless they take a picture of the ballot
<Alanius>
the voters I mean
<sipa>
good digital voting schemes also protect against this by only revealing the tally, and not the individual votes
<sipa>
(under some assumptions)
<sipa>
Alanius: make a picture, and go ask for a new paper
<esotericnonsense>
^ i'm not sure this is possible in the UK
<sipa>
or at the very least you can afterwards invalidate your vote by marking two canfidates
<esotericnonsense>
at least you'd have to show them the old paper that's ruined or whatever. otherwise you vote twice right.
<esotericnonsense>
yeah
<sipa>
and it doesn't need to be a gun; it also prevents people from being paid to vote
<esotericnonsense>
i find all digital voting schemes a solution in search of a problem. it would make sense in the context of extremely frequent (relative to now) national votes. otherwise it just seems like automation for the sake of it.
<Alanius>
the big benefit is universal verifiability
<CubicEarths>
sipa: There are so many facets here, I think we are getting too meta, especially jumping right to the gun-to-head scenario. The gun-to-head problem transcends most things in life :(
<esotericnonsense>
it seems to me that the problem of zero-knowledge verifiability in the context of a polling booth is intractable
<esotericnonsense>
so you get a slip which allows you to verify inclusion in the voting set, without being able to prove you voted one way or another
<Alanius>
there are clever attempts that do that
<esotericnonsense>
but you need to prove at least to yourself, that you voted the way you voted (i.e. that the machine did not cheat you)
<esotericnonsense>
how do you do the latter without showing it to everyone else, on hardware that is not your own / untrusted ?
<sipa>
CubicEarths: it's a well established property of existing voting systems
<sipa>
CubicEarths: the whole use a blockchain rah rah seems to ignore that
<esotericnonsense>
basically, in the existing system you have an ephemeral proof to yourself that at least you entered the correct vote to begin with (it could be counted wrongly or ripped up or whatever)
<sipa>
i guess i'm also generally skeptical about electronic voting in the first place
<esotericnonsense>
i don't know how a machine can provide an ephemeral proof that when you press the button 'esotericnonsense' it doesn't behind the scenes substitute it for 'alanius'
<esotericnonsense>
(if it's permanent, coercion)
<sipa>
CubicEarths: as i said, no need for such an extreme context - it mostly prevents being paid to vote a certain way
<sipa>
CubicEarths: though i guess if you want a coin-weighted vote that doesn't really matter
<CubicEarths>
In most places in the US, there are vote-by-mail options...
<esotericnonsense>
CubicEarths: same in the uk. i
<esotericnonsense>
i'd argue this only works because we know it's limited.
<esotericnonsense>
same for proxy votes
<CubicEarths>
In a few US states, such as Washington, the votes are 100% by mail
* esotericnonsense
wat.
<CubicEarths>
okay, 99%
<esotericnonsense>
i mean i can actualy send someone instead of me to vote for me. so buying votes is trivial. but it's trivial in the same way that many illegal things are trivial
<esotericnonsense>
actually*
<Alanius>
esotericnonsense: have a look at Prêt-à-Voter
<CubicEarths>
sipa: There are so many complexities here, I think looking at what it takes to have a secure coin-weighted system is the place to start
<CubicEarths>
Opinion may well differ on what such a system would be good for... and what it is good for will depend on exactly how it is constructed...
Experiencecoin has joined #bitcoin-wizards
<Experiencecoin>
Hey guys, we are looking for a one or two blockchain developers to join our project. http://experiencecoin.org. We are currently a team of 4 people, and we are looking to expand to 6-7. Anyone interested in learning more?
<kanzure>
nobody will ever be interested now that you have spammed.
<esotericnonsense>
Alanius: seems like there's a trusted setup there
<esotericnonsense>
Alanius: it states that the machine does not learn the ordering, but the machine learns the unique code, which is linked to the ordering, so if someone saved all of those it breaks
<Alanius>
I agree with that conclusion, but you didn't say a trust-free setup was a requirement ;)
<esotericnonsense>
haha. sure :P
<sipa>
CubicEarths: but you can do a coin-weighted vote too where the actual voting doesn't use the chain
<Experiencecoin>
join #bitcoin-dev
belcher has joined #bitcoin-wizards
<CubicEarths>
sipa: It is true
<CubicEarths>
socially though, communities are already oriented around their chain as a source of authority
<CubicEarths>
or at least as a source of accurate record keeping
<Alanius>
I think it makes sense to authenticate the bulletin board, so as to guarantee that everyone sees the same set of ballots
<CubicEarths>
voting is interesting because it starts from the premise of being inclusive, of *wanting* to know what people think and prefer.
<CubicEarths>
Absolutely important to have a method to agree on ballot and authenticate ahead of time
<musalbas>
If federated peg based sidechains were implemented on a blockchain that supported smart contracts, could we remove reliance on the federation being honest, by allowing the smart contract managing locked funds to only release funds if no fraud proofs were shown after X blocks?
<musalbas>
That way, if a federation was being malicious by withholding block data availability to thwart fraud proofs, they'd have to maintain the attack for a long period of time
<andytoshi>
the answer is that "X" parameterizes the extent to which majority hashpower is being trusted, so you have to decide whether there are any sensible values for X for which this would be better than a federation .. which then depends on your design goals
<andytoshi>
also, BTW, bitcoin does support smart contracts, just not sufficiently expressive ones that you could check fraud proofs of other chains in them
<andytoshi>
see also line 485 of that paper which discusses SNARKs
nuke_bloodaxe has joined #bitcoin-wizards
<CubicEarths>
andytoshi: Is the idea that 'trusting a majority of hashpower' for sidechains is worse than the trust the is extended in the managing of the regular chain because Bitcoin full nodes validate everything on the main chain, but they wouldn't be holding the miners accountable for sidechain accuracy?
<andytoshi>
CubicEarths: yeah
<andytoshi>
that's essentially what makes a sidechain a sidechain
<andytoshi>
vs an extension block
<musalbas>
Thanks. I was thinking of more than SPV reorganisation proofs though, which assume that the majority of the hashpower is honest, no? I was thinking that if the majority of the hashpower is dishonest, you could have SPV fraud proofs that prove some transaction was invalid (non-existent outputs, etc) - so the security of the sidechain would be extended to somehting similar to a full node
<musalbas>
s/SPV fraud proof/fraud proof/
<andytoshi>
if you're assuming majority hashpower is honest, you don't have anything resembling full-node security
<musalbas>
exactly - so I'm saying if you use fraud proofs, then you don't have to assume that the majority hashpower is honest anymore
<musalbas>
since you can get fraud proofs of transactions being invalid
<andytoshi>
you do because miners have the ability to censor fraud proofs
<andytoshi>
what does "invalid" mean
<musalbas>
e.g. a tx that points to a non-existent transactions inputs (you can efficiently prove that a tx input doesn't exist using sparse merkle trees)
<musalbas>
how can miners censor fraud proofs? whoever has them just submits them to the smart contract during a contestion period
<andytoshi>
…
<andytoshi>
what does "submits them to the smart contract" mean?
<sipa>
miners can just not include the fraud proofs in the chain
<musalbas>
the sidechain miners, or the mainchain miners?
<andytoshi>
whichever blockchain is being used to for proof-of-pub of the fraud proofs
<sipa>
i assume you're talking about the situation where a transfer back from thr sidechain to the main chain is contestable
<musalbas>
yes
<sipa>
so it is mainchain nkdes that need to see the fraud proof that the transfer was invalid
<sipa>
so the mainchain miners can censor that fraud proof
<sipa>
now mainchain nodes can't know it was invalid
<musalbas>
That's assuming that there's a 51% attack on the mainchain?
<sipa>
yes
<musalbas>
that seems reasonable
<sipa>
i don't agree
<musalbas>
you're relying on 51% of mainchain to be honest, but not 51% of sidechain
<andytoshi>
musalbas: the issue is that this 51% attack allows miners to take all of the coins on the sidechain
<sipa>
but i don't want to rely on a hashrate majority to be honest
<sipa>
anywhete
<andytoshi>
which is way different than any existing vulnerability to 51%
<musalbas>
hmm
<sipa>
the reason we assume 51% is honest is exactly because of full node security - which makes it unprofitable to perform such an attack
SopaXorzTaker has quit [Remote host closed the connection]
<sipa>
if you remove full node security, it becomes much harder to argue why 51% is going to be honest
<musalbas>
sure, but if you assume that anyway in the sidechain paper, surely it would be stronger to assume that 51% of the mainchain is honest rather than the sidechain?
circ-user-cTpdh has joined #bitcoin-wizards
<sipa>
i don't think sidechains (with spv proofs) are something people should want or use
<musalbas>
but if people are going to use them anyway... might as well make them stronger? :p
<sipa>
that paper was written in the context of dozens of altcoins popping up that claimed to need a new currency in order to experiment with new technology
<sipa>
our paper showed that a construction was possible that doesn't need that
<sipa>
without full node security i don't think they're something people should use
<sipa>
as a production syste.
<musalbas>
do you agree though that it would be better to assume that 51% of the mainchain is honest rather than the sidechain?
<sipa>
i'm not sure there is much of a difference
<musalbas>
If the mainchain has most of the hashing power, it allows people to create sidechains with very little hashingpower to test new features, while having the security of the mainchain
<andytoshi>
well, in fairness in the sidechain paper you have to assume _both_ sets of miners are honest
<sipa>
stop saying "security of the mainchain"
<musalbas>
what should I say?
<andytoshi>
so yes, eliminating trust in the sidechain miners is strictly an improvement. but i agree with sipa that it's not a useful one
<sipa>
you don't have full node security; you can't argue that it's anyway comparable
<musalbas>
okay, I mean hashing power of the main chain then
circ-user-cTpdh has quit [Ping timeout: 245 seconds]
<andytoshi>
i also think that any future opcodes that'd allow sufficiently strong fraud proof verification could just be used directly to prove the sidechain rules, SNARK style
<sipa>
sure, but that power can be used for good or for bad
<sipa>
yes, things would fundamentally change if we had feasible compact proofs of full sidechain rule validity on the mainchain
roconnor_ has quit [Ping timeout: 260 seconds]
<sipa>
where you had to prove the entire history of the chain you're moving back from was valid - not just its hashrate was good enough
<musalbas>
it could be argue that if you assume that if the data of blocks is always available to the network and not just the headers (*big* assumption), and your SPV node is not eclipsed, and there's at least one honest full node producing fraud proofs, then your SPV node has almost full node security
<musalbas>
but of course, the first assumption doesn't hold
<sipa>
yes, if you rely on strong censorshipfreeness properties, all kinds of things become possible
<sipa>
like not needing a blockchain :)
<CubicEarths>
sipa: are the compact proofs you are referring to, are these what you feel would be needed to effectively implement a plasma like system on Bitcoin?
<musalbas>
well, the issue boils down to proof of block data being available... which the easiest way to do is download and redistribute a copy of the data yourself. That would at least make the scaling bottleneck of the network be network connectivity, rather than CPU/RAM/storage
<kanzure>
musalbas: the problem with fraud proofs is that fraud-makers have no reason to give you enough information to prove fraud (information withholding problem)
<musalbas>
kanzure, yes, that's what I mean by 'if you assume that if the data of blocks is always available to the network and not just the headers (*big* assumption)'
<musalbas>
There's also a weird data availability proof scheme here I don't fully understand
<yoleaux>
A note on data availability and erasure coding · ethereum/research Wiki · GitHub
<kanzure>
my point was that it's not just a question of including fraud proofs into a blockchain
<musalbas>
kanzure, I know, you're talking about miners not publishing the whole block
<kanzure>
yes fraud proofs can be censored but it is bad to assume that fraud proof construction is possible if you do not have a requirement on everyone having all the data
<sipa>
CubicEarths: i mean things like SNARKs or STARKs or Bulletproofs ... i don't know about plasma
<sipa>
(none of these are feasible today to create full chain security proofs)
<kanzure>
full chain security should only require a circuit with, what, 200 gates?
<sipa>
?
<kanzure>
200 gate constructions should fit into bulletproofs reasonably well. but i'm kidding; i know that's not enough.
<sipa>
just SHA256 is 25000 gates :)
<Alanius>
at what point can you bootstrap? I.e., present a proof that you correctly verified another proof and one additional operation
<sipa>
Alanius: recursive proofs :)
<sipa>
give a proof that you know a secret proof which you ran the validation algorithm for
<Alanius>
exactly
<sipa>
downside: proving is hard
<musalbas>
sipa, btw isn't the miners censoring fraud proofs thing also applicable to payment channels? miners can censor transactions to close channels, causing problems
daszorz has quit [Read error: Connection reset by peer]
<andytoshi>
with BPs there is never any benefit to bootstrapping AFAICT
<andytoshi>
it's always faster to verify a BP than to verify a BP of a BP
<sipa>
musalbas: yes, asolutely
<sipa>
payment channels add extra security assumptions
<musalbas>
why would sidechains be bad but not payment channels then? or do you disapprove of payment channels too?
<kanzure>
payment channels do not require miners to validate sidechains...
<andytoshi>
payment channels have only two participants per channel
<sipa>
i disapprove of payment channels being lauded as a solution to everything
<andytoshi>
also with taproot+scriptless script you can make payment channels usually look indistinguishable from other payments
<mryandao>
taproot?
<kanzure>
this seems like a vocabulary problem. it would be nice to have named sidechains as something that made the security model more explicit.
<musalbas>
kanzure, it doesn't matter, it's the same as the relying-on-51%-mainchain-being-honest assumption I described above for sidechain fraud proofs
<sipa>
musalbas: at least one difference is that i don't believe a widespread deployment of sidechains is possible that doesn't effectively require everyone to participate in all chains
<kanzure>
bitcoin full nodes do not make an honesty assumption like that
<kanzure>
the assumption that the software makes is much more restricted
<sipa>
where payment channels effectively move much of the work actually to just the participants
<sipa>
rather than just to another chain
<musalbas>
kanzure, i know, see from 20:29 :)
CubicEarths has quit [Remote host closed the connection]
<andytoshi>
kanzure: i think that a many-party payment channel could sensibly be called a sidechain
<andytoshi>
where every participant has to sign off on each state update
<sipa>
yup, but it's more like a federated chain model than a hashrate-based one
<musalbas>
andytoshi, yeah, we have something like that in a paper we just wrote (https://arxiv.org/abs/1802.07344), and called them 'sidechains' even though there's no chain involved, due to a lack of better vocabulary
<andytoshi>
yep exactly
<sipa>
the participants themselves are the "miners" for this new chain/channel
<sipa>
rather than anonymous parties that just happen to have the right ASICs
<kanzure>
sipa: in practice, i think people are going to call things sidechains that have really wacky/poor security models especially where not all bitcoin participants are validating the sidechain...
ramajama has quit [Ping timeout: 260 seconds]
<sipa>
kanzure: yes, and that was the goal!
<musalbas>
I wanted to called them 'sidechannels', but that sounds to similar to sidechannel attacks.
<musalbas>
too*
<kanzure>
sipa: elaborate?
<sipa>
kanzure: if we expect everyone to verify a particular sidechain, you should do it as an extension block instead
<sipa>
the whole point of a sidechain is that not everyone has to validate
<andytoshi>
kanzure: the word 'sidechain' was deliberately super general, and the goal of sidechains was to allow experimentation with all sorts of things, including shitty trust models
<sipa>
the downsdie of course is that not everyone validates!
<kanzure>
if not everyone has to validate, then why so many "trust the miners to not steal coins" proposals? why not just fedpeg?
<sipa>
what andytoshi just said :)
<andytoshi>
because "trust the miners" is strictly different from "trust the federation" :P
<mryandao>
isnt it also a requirement that coins can safely move from a "shit trust model" to the bitcoin trust model?
<kanzure>
"trust the miners" isn't really what you're doing in bitcoin though. and adding these other things to their 'buden' increases security exposure problem.
<sipa>
and also, sidechains are optional - which is great for experimentation
<sipa>
they insulate the risk from the mainchain
<sipa>
but only when their usage is negligable
<kanzure>
they are optional to bitcoiners but i think some sidechain proposals seem to require bitcoin miners to behave and run some code and watch stuff.
<musalbas>
<andytoshi> payment channels have only two participants per channel < are you saying that's good because that means any damage is limited to two participants?
spinza has quit [Ping timeout: 256 seconds]
<andytoshi>
musalbas: yes, only two participants who both agree on the maximum possible loss under what circumstances (and they can only rob each other, miners can't rob them, at least if neither drops out)
<andytoshi>
err "miners can't rob them except with cooperation of one of the parties"
<musalbas>
well, where do you draw the line? what if we had sidechains with 5 participants, or 10 participants? could be some kind of sidechains that supported trustless tumbling, or something
<andytoshi>
and with 2-party schemes it's way easier to coordinate the cooperative-close case, in which miners can't even distinguish closing txes from any other tx
<sipa>
musalbas: if those participants are known and fixed you can just use a federation
<andytoshi>
where do i draw what line?
<musalbas>
'2' seems like an arbitrary number (except for your latter point about distinguishing closing txes from other txes)
<sipa>
yes, but none of the arguments apply here to federated sidechains
<sipa>
only to those relying on PoW
<andytoshi>
musalbas: 2 is a special number. with 2 participants, every participant is interested in every state change so having a N-of-N threshold does not allow any disinterested parties to cause holdup
<musalbas>
sipa, true re: federation (that's what we basically did in the paper i linked)
<andytoshi>
it also makes things like scriptless scripts possible
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
spinza has joined #bitcoin-wizards
<aj>
andytoshi: "third wheel" should be the technical term for someone with an N-of-N threshold who's not interested in a particular update...
<musalbas>
hmm. perhaps in some use cases it might be OK to take the risk of allowing disinterested parties to cause holdup (shittier security model). Assume a sidechain with 500 participants, but 1 node mining blocks (effectively centralised), with the fraud proofs, the centralised node can cause everyone to lose their funds by holding things up, but not steal money
<andytoshi>
right, in a federated sidechain (unlike a payment channel) the set of custodians does not need to be the same as the set of people signing state updates
Experiencecoin has quit [Quit: Page closed]
Guest59762 is now known as aem
jb55 has joined #bitcoin-wizards
Noldorin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
circ-user-cTpdh has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
harrymm has quit []
DougieBot5000_ is now known as DougieBot5000
Giszmo has joined #bitcoin-wizards
Giszmo has quit [Client Quit]
eklitzke has quit [Quit: bye]
eklitzke has joined #bitcoin-wizards
Noldorin has joined #bitcoin-wizards
Noldorin has quit [Ping timeout: 252 seconds]
Giszmo has joined #bitcoin-wizards
Giszmo has quit [Client Quit]
Giszmo has joined #bitcoin-wizards
Giszmo has quit [Client Quit]
Giszmo has joined #bitcoin-wizards
Giszmo has quit [Client Quit]
jb55 has quit [Ping timeout: 252 seconds]
Giszmo has joined #bitcoin-wizards
belcher has quit [Quit: Leaving]
dnaleor has quit [Quit: Leaving]
AaronvanW_ has quit [Remote host closed the connection]