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
RC-3004 has quit []
Aesthetic has quit [Remote host closed the connection]
Logicwax has joined #bitcoin-wizards
captjakk has quit [Remote host closed the connection]
captjakk_ has joined #bitcoin-wizards
captjakk_ has quit [Remote host closed the connection]
marcoagner has quit [Ping timeout: 252 seconds]
mdunnio has joined #bitcoin-wizards
luke-jr has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
tromp_ has quit [Ping timeout: 248 seconds]
vtnerd_ has quit [Ping timeout: 245 seconds]
vtnerd has joined #bitcoin-wizards
emilsedgh has joined #bitcoin-wizards
mdunnio has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
mdunnio has quit [Read error: Connection reset by peer]
_whitelogger has joined #bitcoin-wizards
Guest69260 has quit [Quit: restart]
Madars has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
Dizzle has joined #bitcoin-wizards
Dizzle has quit [Quit: Leaving...]
othe1 has quit []
_whitelogger has joined #bitcoin-wizards
jb55 has quit [Ping timeout: 260 seconds]
jb55 has joined #bitcoin-wizards
ccdle12 has joined #bitcoin-wizards
ccdle12 has quit [Remote host closed the connection]
lugosi1 has joined #bitcoin-wizards
jonatack has quit [Ping timeout: 264 seconds]
CubicEarth has quit [Quit: %Gone to become more spherical%]
queip has quit [Ping timeout: 244 seconds]
queip has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
CubicEarth has quit [Client Quit]
Giszmo has joined #bitcoin-wizards
jonatack has joined #bitcoin-wizards
jonatack_ has joined #bitcoin-wizards
jonatack_ has quit [Client Quit]
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-wizards
jonatack has quit [Client Quit]
jonatack has joined #bitcoin-wizards
nehan has quit [Remote host closed the connection]
ppisati has quit [Ping timeout: 245 seconds]
lugosi1 has quit []
ppisati has joined #bitcoin-wizards
Toflar has joined #bitcoin-wizards
marcoagner has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
Aaronvan_ has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 245 seconds]
Giszmo has quit [Quit: Leaving.]
reallll has joined #bitcoin-wizards
belcher has quit [Ping timeout: 258 seconds]
TheoStorm has joined #bitcoin-wizards
markus-k has quit [Ping timeout: 245 seconds]
jonatack has quit [Ping timeout: 245 seconds]
Toflar has quit []
jb55 has quit [Remote host closed the connection]
jb55 has joined #bitcoin-wizards
jb55 has quit [Remote host closed the connection]
jonatack has joined #bitcoin-wizards
jb55 has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
Raccoon has joined #bitcoin-wizards
queip has quit [Ping timeout: 258 seconds]
queip has joined #bitcoin-wizards
kenshi84 has quit [Read error: Connection reset by peer]
CubicEarth has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
starsoccer has quit [Ping timeout: 245 seconds]
Raccoon has quit []
CubicEarth has joined #bitcoin-wizards
Aaronvan_ is now known as AaronvanW
CubicEarth has quit [Client Quit]
CubicEarth has joined #bitcoin-wizards
CubicEarth has quit [Quit: %Gone to become more spherical%]
starsoccer has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
queip has quit [Ping timeout: 244 seconds]
queip has joined #bitcoin-wizards
MacYET2 has joined #bitcoin-wizards
a5m0 has quit [Ping timeout: 245 seconds]
a5m0 has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 244 seconds]
scottmatheina has quit [Ping timeout: 245 seconds]
TheoStorm has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
CubicEarth has joined #bitcoin-wizards
<CubicEarth>
Regarding quantum vulnerabilities in Bitcoin, if ECDSA is not secure, my understanding is that there is a risk where a key can be broken between when a tx is published and before it is confirmed in a block
<sipa>
yes, depending on how fast this hypothetical machine works
<CubicEarth>
wouldn't a solution be a rule that first a hash of the transaction needs to published, and "confirmed" in a block, and then after, the tx itself can be safely broadcast?
<sipa>
no, because that just moves the problem to confirming the tx itself
<CubicEarth>
The rule would be that the only way any transaction is accepted as valid is if a hash of that tx had already been included in a block...
<CubicEarth>
so the quantum attacker couldn't redirect the funds... or at least a large time window could be enforced before they could
<sipa>
miners can see the real tx which reveals the pubkey, censor it, and in the mean time include a tx commitment to a double spend that sends the money to themselves
<sipa>
and when that double spend commitment is sufficiently buried, steal the coins
<CubicEarth>
agreed, it wouldn't not be secure against miners censoring. although with a long time windows (100 blocks?), it should be long enough to publicly expose / shame the miners and their cartelish ways
<sipa>
there are also other issues with this; how do you pay for including a tx precommitment in the chain?
<sipa>
as you can't use a transaction to do so
<sipa>
and you can't rely on tx precommitments to be unique for a given output, as you don't know if they're even valid
<CubicEarth>
payments - yes, that's an issue
<CubicEarth>
why would they need to be unique or valid? I could submit many... but at least on them would need to match the tx I finally broadcast
<sipa>
sure, but you'd need to pay for all of them
<sipa>
my point is you can't skip paying for them (if you knew there was going to be only one per output, you could make them free instead, but because you don't know if they're valid, there can be many and you need to pay for them or you have a DoS sink)
<sipa>
also, don't forget that right now around 5-6 M BTC are stored in outputs with known pubkeys
<sipa>
and probably even more in outputs that private parties know the pubkeys of (due to xpubs being shared, wallet services, things entered in block explorers, revealed as part of other protocols like lightning, ...)
<CubicEarth>
are the 5-6 M from before SHA265 was put in the address path? Or address reuse??!
<sipa>
P2PK outputs, bare multisig outputs, address reuse
<sipa>
also some of it is from spending coins on fork chains
<CubicEarth>
wow
<sipa>
it doesn't really matter
<sipa>
everything in the bitcoin ecosystem already relies on treating public keys as public
<sipa>
even without address reuse or P2PK this would be an issue; just less blatantly obvious
<sipa>
the only solution to QC is introducing a PQC signature scheme, and then at some point softforking out the ability to spend using EC based schemes
<CubicEarth>
I agree with the idea of having a cut-off date by which coins would need to be moved to secure addresses (if that's what you are suggesting). It will be a catastrophe for people who didn't move their coins by then, but otherwise, it would still be a catastrophe for them when their coins get stolen, and a catastrophe for everyone when ALL the old coins enter the economy
<CubicEarth>
It's not exactly "payment", but the anti-dos mechanism for the commitment could be POW
<sipa>
unfortunately, miners have that in abundance, and everyone else has basically none
<sipa>
so this would make anyone who doesn't have equivalently-efficient hardware as miners effectively prevented from participating
<CubicEarth>
although the cost to DOS in a POW context is the opportunity cost of not mining...
<CubicEarth>
but still, it's not really a solution. The miners need to be paid
MacYET2 has quit []
<CubicEarth>
I was going to say the miners could be paid via lightning channels, but LN is probably riddled with QC vulnerabilities
scottmatheina has joined #bitcoin-wizards
<sipa>
my simple view is that bitcoin today relies on ECDLP security
<sipa>
that may change in the long term, but trying to patch up just the holes we see isn't a solution
<CubicEarth>
That makes sense. My fear is that QC get powerful before good solutions emerge. I believe that proper solutions would eventually be designed, but I was thinking along the lines of stop-gap measures, to hopefully enable Bitcoin's survival, even if in a reduced or even ham-strung capacity in the meantime
<CubicEarth>
they'd be the 'dark ages'
<sipa>
i don't think there are really any solutions
<CubicEarth>
:(
<sipa>
we'd need to outlaw most higher level protocols, bip32 derivation, ...