bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] laanwj merged pull request #24048: build: Improve error message when pkg-config is not installed (master...220112-m4) https://github.com/bitcoin/bitcoin/pull/24048
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
earnestly has joined #bitcoin-core-dev
meshcollider has quit [Changing host]
meshcollider has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
x88x88x has quit [Remote host closed the connection]
x88x88x has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
bomb-on has joined #bitcoin-core-dev
bomb-on has quit [Read error: Connection reset by peer]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] brunoerg opened pull request #24054: test: rest /tx with an invalid/unknown txid (master...2022-01-rest-functional) https://github.com/bitcoin/bitcoin/pull/24054
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
mikehu44 has quit [Ping timeout: 256 seconds]
SpellChecker has quit [Ping timeout: 276 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
orionwl is now known as laanwj
SpellChecker has joined #bitcoin-core-dev
sdfgsdfg has quit [Quit: ZzzZ]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #24057: build: point to latest commit on 1.4.0 branch (master...actually_fix_guix) https://github.com/bitcoin/bitcoin/pull/24057
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
rex4539 has quit [Remote host closed the connection]
rex4539 has joined #bitcoin-core-dev
outfox has quit [Ping timeout: 256 seconds]
outfox has joined #bitcoin-core-dev
Nekorand has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<jeremyrubin>
achow101 if i see a long-chain in the bottom of the mempool, and a some output in that is paying me, does core wallet save those transactions for rebroadcast?
<achow101>
jeremyrubin: I think it will only save the ones that have outputs for it
<achow101>
it won't pick up any ancestors or descendants
<sipa>
the solution of course is making the mempool do the rebroadcasting :)
<MarcoFalke>
sipa: The mempool will drop the txs after two weeks
<jeremyrubin>
i'm writing an email about this. we should save all ancestors (obviously?) because they're required to claim our money
<jeremyrubin>
we should also save all descendants, if they are paying a higher feerate and serve as a CPFP
<jeremyrubin>
it seems odd that we'd save the one we have outputs for but not the unconfirmed parents, that seems like a definite bug
<achow101>
as we add more (unrelated) txs to the wallet, it gets slower
<achow101>
if there are a lot of unconfirmed ancestors and descendants, once they do confirm, that's just going to be junk sitting in the wallet forever
<sipa>
they could be stored in a separate set of transactions, independent from mapwallet
<sipa>
from which confirmed/conflicted things can be pruned
<jeremyrubin>
i think engineering concerns / DoS aside, it's clearly rational to save these
<sipa>
but otherwise don't really participate in wallet reasoning
<sipa>
i agree it makes sense to store them
<jeremyrubin>
i just wanted to check on what existing behavior was
<jeremyrubin>
when we go to spend and the txns exist in the mempool still, does coin-selection allow spending from unconfirmed account for CPFP cost for longchains?
<sipa>
MarcoFalke: That's fair; the issue here isn't so much the rebroadcasting itself, but the forgetting?
<achow101>
no
<jeremyrubin>
so if you have a new wallet with 3 unconfirmeds that have different tx histories (e.g. 3 txs, 5 txs, 10txs) and you generate a spend what cost is used for those inputs?
<MarcoFalke>
I guess the issue is both rebroadcasting and forgetting
<jeremyrubin>
Just the satisfaction cost
<achow101>
just the satisfaction cost
<jeremyrubin>
kk, thanks
<achow101>
iirc there's some consideration for whether we will exceed ancestor/descendant limits
<achow101>
but only insofar as whether the utxo is available for selection
<sipa>
seems reasonable to open an issue for it or so
<sipa>
not sure if this is really ML material
<jeremyrubin>
sipa hopefully im not being seen as spamming the ML
<sipa>
i just don't see how this concerns the ML... it's an issue with Bitcoin Core's wallet, only affecting the users of that wallet
<achow101>
i agree that's not really ML material
<jeremyrubin>
well it's not just an issue for core
<jeremyrubin>
for any rational wallet
<jeremyrubin>
the reason for the post is that one of the critiques of CTV/congestion control is 'look at all the wallet software we'd have to have for it to work well', whereas i think most of the things are rational behaviors (CTV or no) that wallets would implement once mempool gets more backlogged
<jeremyrubin>
so i'm just describing the lifetime of a payment from the perspective of a rational wallet user during congested mempool
<sipa>
Do other wallets even do rebroadcasting?
<achow101>
the problem is that there are a lot of rational behaviors that wallet's should implement, but those are all hard to implement
<achow101>
nevermind the fact that the most basic things are already difficult to do
<jeremyrubin>
hence the email is documenting
<jeremyrubin>
these are also things that aren't you do x and y would be cheaper. these are you don't do X and your wallet will lose payments.
<sipa>
well, in theory, sure
<sipa>
but in practice, if the mempool forgets about an unconfirmed ancestor of yours, with default policy, i think it's very likely the transaction just isn't going to confirm at all, and will probably be RBFed anyway.
<jeremyrubin>
the RBF might e.g. double spend you
<jeremyrubin>
so it'd be rational for you to CPFP from your output to speed up the conf
<jeremyrubin>
depending on the amt of funds received
<achow101>
we never spend external unconfirmed utxos unless the user acknowledges that it is dangerous to do so
<jeremyrubin>
spend-to-self if you can't piggyback an actualpayment
<sipa>
is it even possible to do that (without raw transaction interface), achow101 ?
<jeremyrubin>
achow101: that sounds mildly irrational. spend your bad money first, good money later.
<achow101>
sipa: see include_unsafe
<sipa>
minconf=0 will still only spend your own unconfirmed UTXOs.
<jeremyrubin>
why would i spend money that has ~0% risk when i have something at 100% risk i can derisk by spending?
sebsp73 has joined #bitcoin-core-dev
<achow101>
jeremyrubin: huh? presumably you want your payment to go through
outfox has quit [Ping timeout: 250 seconds]
<achow101>
not potentially get stuck in limbo and maybe need an expert to fix the problem
outfox has joined #bitcoin-core-dev
<jeremyrubin>
achow101: why would CPFP'ing an unconfirmed require an expert to fix it?
<achow101>
if the unconfirmed gets rbf'd
<achow101>
perhaps not need an expert, but results in a confusing situation for your average user
<jeremyrubin>
it's a fair point.
<jeremyrubin>
still, in this case, there are two outcomes: RBF still pays you, now your payment is dead
<jeremyrubin>
if the RBF is still paying you, you can reissue the txn and save on CPFP amount
<achow101>
yeah but the original still shows up as an unconfirmed transaction
<jeremyrubin>
if the RBF isn't paying you, then you should CPFP even more so as not to lose a payment to you
<jeremyrubin>
(glozow hi package relay)
<achow101>
imo we shouldn't do anything that might cause a user to need to reissue a payment. they will feel like they are double paying
<jeremyrubin>
(this is also a good point in favor of txn sponsors / fee accounts, which if your TX spend was inconvenient (e.g. requiring a multisig) that having the ability to add third party fees is great)
<achow101>
or they may not understand that the original payment attempt is dead
<jeremyrubin>
achow101 that seems like a UI problem, not a reason to deviate from rationality
<jeremyrubin>
the rational behavior should be supported, and the UI should simplify what has happened and explain it clearly. Those are largely separate concerns
<jeremyrubin>
much more frustrating would be the case where I see an unconfirmed and i get double spent
<achow101>
that's not a ui problem, that's a problem with time being linear
<jeremyrubin>
...
<achow101>
"I sent the payment 2 days ago, now you're telling me I need to send it again?"
<achow101>
people have memories
<achow101>
regardless of what the ui shows, people will remember that they tried to pay previously
<jeremyrubin>
I would assume that much of this can be automated
<jeremyrubin>
it's not you having to reissue the payment, the wallet can prompt you "this payment failed because X"
<jeremyrubin>
(also it strikes me that APO fixes some of this...)
<jeremyrubin>
and the prompt can give you the tx to sign again.
<jeremyrubin>
(or maybe even do it without permission explicitly)
<jeremyrubin>
in any case it is definitely good to think about the UI concerns about understanding why / if payments get made.
promag has quit [Remote host closed the connection]
<jeremyrubin>
#proposedmeetingtopic release processes / feature freezes / best practice & optionality w.r.t. BIP-119 for non-deployment code
<laanwj>
it's a pretty tough PR to review, but would be good to have more eyes on it
<MarcoFalke>
Maybe we should be holding back on risky stuff until after the branch off?
<jonatack>
yes, agree, i need to go through it fully again
<laanwj>
MarcoFalke: which one do you consider especially risky?
<MarcoFalke>
The allocator stuff?
<MarcoFalke>
(Not a expert on that, maybe it is not risky at all)
<jonatack>
true
<laanwj>
yes, ok, agree it's better to merge that at the beginning of a merge window instead of the end, but don't think it's done reviewing yet anyhow
<_aj_>
we're ~four weeks from freeze, ~six weeks from branching?
<jeremyrubin>
feb 15 feature freeze
<laanwj>
_aj_: yep
<MarcoFalke>
two weeks from translation soft freeze
<jeremyrubin>
i'm curious to know if there is a loss of "optionality" given usual precedent of merging non-activated code in a prior maj release that would motivate merging -- while still being reviewed / discussed for activation -- the CTV code
<jeremyrubin>
if there is no loss of optionality in terms of normal release practices, it doesn't matter much
<jeremyrubin>
(this was a discussion topic output from Tuesday's meeting)
<jeremyrubin>
One of the considerations for doing it is e.g. the ease of backporting the feature to the last major version, for example.
<provoostenator>
I'm not sure about optionality, but increasing complexity of consensus code - even in code paths that aren't hit - always carries some risk.
<michaelfolkson>
I know Jeremy will keep his head in the sand regardless but for the sake of observers
bairen has quit [Ping timeout: 276 seconds]
<provoostenator>
The patch is probably already as short as it gets, but you can always try to split of more stuff into seperate PR's if they have dual use.
<provoostenator>
But after that I think rebase-purgatory is the place to be until there's broad consensus that people want this soft fork.
<jeremyrubin>
provoostenator i think that's reasonable, I just want to ensure that "code wasn't in 0.2x" to contribute to a 6mo-1yr delay on a possible release timeline once that does exist, however it is to be measured (optionality)
<_aj_>
backporting a small patch to older versions seems plausible for CTV compared to taproot or segwit too
<provoostenator>
Backporting isn't necessarily easier; if you get some code in now and then have to dramatically change it later, including in backports, life isn't much easier.
bairen has joined #bitcoin-core-dev
<provoostenator>
You could even maintain a patch with test on earlier branch to demonstrate that it's indeed not a problem.
sipsorcery has quit [Ping timeout: 250 seconds]
<jeremyrubin>
provoostenator that does seem doable I guess? once e.g. the split off happens I could rebase once onto the 0.23 and freeze that even if other branch needs updates
<provoostenator>
I also tend to agree with your point above (before the meeting) that many changes you need for mempool and wallet handling are useful in general.
<provoostenator>
jeremyrubin: at first glance that seems doable, but maybe a waste of time if nobody actually has that concern.
<provoostenator>
And demonstrating CSV in a working and user friendly Core wallet might help increase excitement / decrease worries.
<jeremyrubin>
i think the main negative impact (outside of bug/complexity) would be prematurely impacting the PrecomputedData code path, if it were merged now. It's not a huge overhead though, but it is something.
<provoostenator>
* CTV
<jeremyrubin>
One of the benefits of merging would be having a signet client with CTV validation
<jeremyrubin>
that would aid testing
<provoostenator>
I think Signet users can be expected to know how to compile though.
test_ has joined #bitcoin-core-dev
<jeremyrubin>
fair
<provoostenator>
That would be a good use case for maintaining a release branch
<provoostenator>
So people can test with stable release + patch, rather than master + patch.
<jeremyrubin>
are any maintainers able to weigh in on what advocates of CTV should be doing/aiming for? your input is valauble here too
<jeremyrubin>
if you don't want to talk about CTV in particular, can talk generally about what OP_FOOBAR should do in the future
<achow101>
I agree with provoostenator
sipsorcery has joined #bitcoin-core-dev
<jeremyrubin>
what do we think about doing what provoostenator but actually doing a release build of 23.0+experimental? So then people can just grab a binary
<provoostenator>
jeremyrubin: you can just do that
_flood has quit [Ping timeout: 256 seconds]
<provoostenator>
Should be - if it isn't yet - a matter of maintaining a fork branch and some Guix tweaks
<jeremyrubin>
sure, happy to. but if i'm the only signer i'd not advise people to run it
<_aj_>
jeremyrubin: (i'd consider running out-of-tree code to mine ctv blocks on the real signet, though that would also mean figuring out how to make txs propogate, but there's a bunch of higher priority things on my todo list)
<provoostenator>
So it'll even be reproducable
<jeremyrubin>
_aj_: yeah, this is why when i looked into "can't i just make the signer on signet run the new code" it wasn't a workable option
test__ has joined #bitcoin-core-dev
<provoostenator>
I think it warrants a fresh signet,.
<_aj_>
jeremyrubin: (eh, i've tried code in the past to combine p2p service bits with consensus versionbits so nodes running a new fork can talk to each other; it's just work)
test_ has quit [Ping timeout: 256 seconds]
promag has joined #bitcoin-core-dev
<jeremyrubin>
_aj_: i'd be a bit out of my depth working on that and i don't want to impose on your time to do that; a new signet seems the simplest to make it happen. would be nice if could be done from the latest release without downloading a new thing, but that burden shouldn't be too large...
<provoostenator>
Custom signet would also let you massively constrain block space there, which could be handy for testing.
<provoostenator>
jeremyrubin: afaik you can point bitcoin.conf to arbirary signets
<_aj_>
jeremyrubin: anyone trying to use a new consensus feature needs to be able to build their own wallet etc anyway, compiling their own bitcoind should be the least of their worries
<_aj_>
provoostenator: (not if bitcoind doesn't support the opcode you're trying to test -- it won't be accepted into the mempool)
<jeremyrubin>
_aj_: you can use sapio studio somewhat off the shelf right now
<jeremyrubin>
but i guess that counts as "build" your own, less so "implement" your own
<provoostenator>
_aj_: I'm assuming the signet is used with the custom branch or custom binary.
<_aj_>
provoostenator: if it's a custom branch, you could add a new -chain=ctvsignet option i suppose
<provoostenator>
But the patch itself won't be more complicated for using the custom signet.
promag has quit [Remote host closed the connection]
promag has joined #bitcoin-core-dev
promag has quit [Remote host closed the connection]
<luke-jr>
jeremyrubin: maybe we need to focus more on encouraging people to sign more than Core mainline releases
<luke-jr>
jeremyrubin: I'm still not 100% setup for Guix yet, but I will try to sign yours if you remind me
promag has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
<jeremyrubin>
luke-jr: thanks. i am somewhat ambivalent about signed releases in the first place which is why i've not done it previously. but i dont think theres a better alternative presently :/
yanmaani has quit [Ping timeout: 276 seconds]
<jeremyrubin>
"everyone should compile bitcoin by hand"
promag has quit [Ping timeout: 250 seconds]
<luke-jr>
certainly better than non-reproducible binaries :p
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
<michaelfolkson>
luke-jr: It depends what you think that signature represents. I'm curious actually. Let's say Jeremy releases a fork of Core with OP_CTV in it in an attempt to get it activated (I wouldn't recommend it but say he did)
<michaelfolkson>
Would you want to review the code before signing? Would you want to agree with the consensus change? Would you want to agree that the consensus change had community consensus?
___nick___ has quit [Ping timeout: 256 seconds]
<michaelfolkson>
It sounds like from the above you're willing to sign only on the condition that Jeremy signs yours and nothing else
Talkless has quit [Quit: Konversation terminated!]
<michaelfolkson>
I guess it could be a bit web of trust-y. I know this came from Jeremy hence I'm willing to sign it
<michaelfolkson>
(assuming you trust him of course)
pete_rizzo_33 has joined #bitcoin-core-dev
<sipa>
the guix attestations mean "this source code corresponds to this binary", and if it's for a named release "i agree that this indeed the released source code under that name"
<sipa>
nothing more
FollowTheRabbit has joined #bitcoin-core-dev
<michaelfolkson>
sipa: Like cryptographically?! Or is that just implicitly understood?
<michaelfolkson>
I guess I should look it up
<sipa>
That's what attestations are. They attest that the software was correctly built.
<sipa>
It would be very strange that it would mean "people should run X!" if there wasn't some sort of message signed that states that.
<michaelfolkson>
But are you literally signing a statement like "this source code corresponds to this binary" or can you only sign if you've compiled and so its implicit?
<sipa>
I don't understand your question.
<jeremyrubin>
GUIX tooling can largely be automated to sign releases. Not a good assumption the code has actually been reviewed
<sipa>
The attestation is a signature on a file that contains the hashes of the produced binaries, the source code tarball, and the file name.
<jeremyrubin>
It might be good to layer a signature that says "this code is safe" or "I am running this personally, at least".
<sipa>
It does not sign "I reviewed this code", or "I think people should run this code", or "This software will solve world hunger". If you want that, you can do that, but that's not what the attestations are about.
<michaelfolkson>
Does it need to be generally understood (with communicated words) what that GUIX attestation represents? It sounds like yes it does
<michaelfolkson>
I guess the only alternative would be a zero knowledge-y thing where you can literally only sign if you've generated same binary
flooded is now known as _flood
<sipa>
That still doesn't prevent people from misinterpreting it as something else.
brunoerg has joined #bitcoin-core-dev
promag has joined #bitcoin-core-dev
<michaelfolkson>
I guess but you'd point to the zero knowledge-y process that you followed in this speculative world where such a thing was possible
<sipa>
I can also link to the GUIX process now.
<sipa>
Doesn't mean people will read it or understand its implications.
<michaelfolkson>
I guess. The more that is embedded in that signature it seems the better to me. And a process where it was only possible to sign through a ZK process would be even better
brunoerg has quit [Ping timeout: 256 seconds]
<sipa>
Nor does the process prevent people running it from attaching additional semantics to it (e.g. they might only do guix builds for code they think is safe to run, implicitly attaching a meaning of vouching for it).
<michaelfolkson>
Other than just needing to verbally say "Here is a link to the GUIX process I followed"
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
<michaelfolkson>
But ok, thanks!
<sipa>
Whether that meaning is conveyed is purely a social issue.
<michaelfolkson>
It could be embedded in the signature, that was my point
<michaelfolkson>
So it becomes more of a math issue than a social issue
<sipa>
I think you misunderstand what a ZK system can accomplish. If I copy your compiled binary and sign it, I achieve the same thing.
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<sipa>
Even if I didn't compile it myself.
<sipa>
ZK systems protect secret data. There is nothing secret here.
JimBer110 has quit [Quit: Konversation terminated!]
dviola has quit [Quit: WeeChat 3.4]
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
FollowTheRabbit has quit [Quit: Client closed]
lukedashjr has joined #bitcoin-core-dev
yanmaani has joined #bitcoin-core-dev
<lukedashjr>
michaelfolkson: cryptography has no meaning at all, except what people understand it to mean
luke-jr has quit [Ping timeout: 256 seconds]
lukedashjr is now known as luke-jr
<luke-jr>
michaelfolkson: my Guix signatures explicitly clarify that I am using binary "substitutes" too
<luke-jr>
and while I would certainly appreciate more builds of my releases, Jeremy included, I didn't include it as a condition of my doing so for his
<jeremyrubin>
actually you can do some interesting things if you randomly sample data from a GUIX build on a challenge generated by the hash of your signing key and the files you're compiling, you could "prove" that you at least had access to a transcript of the build maybe... however, auditing that would require someone else to compile it and check the
<jeremyrubin>
transcript over.
<sipa>
Yeah. And also, only meaningful if you're sure nobody else shared their build transcripts.
<jeremyrubin>
luke-jr: i would be more willing to do GUIX builds if I felt it were more clearly communicated that it just meant "I have a computer that ran this"
<jeremyrubin>
maybe i can mitigate that by doing multiple guix builds and having a key-per-machine
<jeremyrubin>
so it's clear the signature is jeremyrubin-build-machine-1, and not jeremyrubin
<sipa>
I don't think that adds anything. The trust is derived from the person administering the machine.
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<luke-jr>
jeremyrubin: I mean, you can always use --sig-notation to add arbitrary disclaimers and such too
<jeremyrubin>
sipa: i think it does? sure trust is from the administration of the machine, but if i can tell people how i set up jeremyrubin-machine-1 and maintain it, it makes more clear what they're trusting me for
<jeremyrubin>
e.g., if i wanted to mitigate supply chain issues i might compile it on 5 different machines for myself *anyways*
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
<jeremyrubin>
provoostenator sipa achow101: i posted my 'transaction lifetime' post btw, thanks for the feedback earlier
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<jeremyrubin>
if you would like i can open GH issues for those topics separately for at least core to DTRT
pete_rizzo_33 has quit [Quit: Client closed]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
lofiel has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 245 seconds]
<michaelfolkson>
[21:10:24] <lukedashjr> michaelfolkson: cryptography has no meaning at all, except what people understand it to mean
<michaelfolkson>
No meaning at all is a bit strong. At the very least you are proving you own a private key. And if you sign a statement with a private key only you own you are indicating you support that statement
<sipa>
I think what luke means is that the interpretation of that statement is up to humans, in this context.
<michaelfolkson>
Right, ok
<sipa>
It's a bit strong to generalize to all cryptography. In particularly, encryption doesn't generally suffer from such interpretation issues.
<sipa>
Though I guess you can come up with scenarios where receiving a message that contains a certain decryption has a certain humam meaning too.
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Alina-ma- has joined #bitcoin-core-dev
Alina-malina has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
Alina-ma- has quit [Quit: !be back soon]
brunoerg has quit [Ping timeout: 268 seconds]
sipsorcery has quit [Ping timeout: 252 seconds]
Guyver2 has quit [Remote host closed the connection]
Nekorand has quit [Ping timeout: 256 seconds]
<jeremyrubin>
sipa: actually encyrption in particular does suffer from this, since in order to be a secure encryption all ciphertexts must be equally likely :p
<jeremyrubin>
so the ciphertext must be completely meaningless :p
<sipa>
That's not true. All that is required is that the attacker cannot learn anything that they do not already know, from the ciphertext, if they don't know the key
<sipa>
Oh, the ciphertext!
<sipa>
Well, that's still not true, because it only needs to hold for an attacker that does not have the key.
<sipa>
And unless you're working with information theoretical security, the criterion isn't that all ciphertexts should be equally likely. Only that a computationally bounded attacker cannot distinguish it from random.
<jeremyrubin>
equally likely up to a negligible based on your computational bound ;)
<jeremyrubin>
but that is the textbook definition iirc.
<jeremyrubin>
but you can't even know that you have 'the key'. e.g., there could be encryptions where you can make different keys decrypt to two different valid (containing a hash commit?) messages
<jeremyrubin>
enc(k1, k2, m1, m2) = c s.t. dec(k1, c) = m1, dec(k2, c) = m2. (perhaps you could prove that's not possible, but it certainly seems something you could describe)
<jeremyrubin>
'deniable encryption'
<sipa>
I don't think even that holds. In particular, for long messages with some mode AES256, if there are only two possible plaintexts, there are only 2^256 (keys) * 2^256 (IVs) * 2 (plaintexts) possible ciphertexts, but the ciphertext may be much longer than 513 bits.
<jeremyrubin>
you're saying there exists an encryption where this property doesn't hold
<jeremyrubin>
which is not a valid counter to
<sipa>
But that can still be semantically secure.
<jeremyrubin>
there may exist an encryption where this is possible
<sipa>
I'm saying this example would still be considered secure, because the distribution is computationally indistinguishable from uniform, despite being very much nonuniform.
<jeremyrubin>
in any case we're at a hugh level of pedantism for #bitcoin-core-dev, we could chat on wizards about it more
sipsorcery has joined #bitcoin-core-dev
Alina-malina has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
promag has quit [Remote host closed the connection]