7. Catena: Efficient Non-equivocation via Bitcoin

[@pezotecom]

This was the hardest lecture I have ever seen in my entire life and also one of the most enlightning ones.

[@makgaiduk]

How do you do equivocation with batched transactions? What is to stop me from putting s and s' in a single merkle root, hiding this fact from everyone who doesn't download the full batch?

[@cauebraga]

I remember Alin from Blockchain & money course. Professor Gensler was always asking his help to explain the hard aspects of Blockchains to the class.

[@shucks18]

Yeah haha

[@bartech101]

Why not force to sign new pub key with private key corresponding to previous pub key. No one can impersonate that. And in case Bob lose his priv key and want to create new key pairs we shouldn't trust them without reaching out to Bob via channel we trust. As shown in lecture best face to face.

[@brainstormingsharing1309]

Absolutely well done and definitely keep it up!!! 👍👍👍👍👍

[@dimianovic7717]

Question: as long as i run my own Bitcoin Node, i dont really need catena Right?

[@randomperson1048]

this hard af

[@tobiisurmaster]

14:30 I'm slightly confused about how blockstack/keybase can issue transactions without some arbitrary reference to a previous transaction output. What exactly are their transaction inputs referencing?

[@shymaaarafat1342]

I was much more confused when I read just this* lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html before hearing the lecture I haven't finished it yet, but what I understand is: - They send probably a very small dust value UTXO to a non existing key because they write their data in place of the signature -This way this UTXO will be burned and will stay in the UTXOS set forever -They probably use a UTXO they have, sacrifice a dust value & send the remaining to a new UTXO as the normal change -He is suggesting, Catena I mean, they use 1 UTXO & keep sending the same money back&forth to themselves (this way no the no of UTXOS remains the same), and then write the msg in the OP_Return part -In fact he said later in the lec, that he can use it for a more than 80 byte msg by putting their the hash of accumulated msg; a Merkle root for example as if he is having like a private block attached to the TX. ....... *written in there --------------------------- For example, timestamping applications often create unspendable outputs due to ease of implementation, and because doing so is an easy way to make sure that the data required to reconstruct the timestamp proof won't get lost - all Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay use-cases like using the UTXO set for key rotation piggyback on the uniquely strong security and decentralization guarantee that Bitcoin provides; it's very difficult - perhaps impossible - to provide these applications with alternatives that are equally secure. These non-btc-value-transfer use-cases can often afford to pay far higher fees per UTXO created than competing btc-value-transfer use-cases; many users could afford to spend $50 to register a new PGP key, yet would rather not spend $50 in fees to create a standard two output transaction. Effective techniques to resist miner censorship exist, so without resorting to whitelists blocking non-btc-value-transfer use-cases as "spam" is not a long-term, incentive compatible, solution.

[@dealwithit7515]

48:40 can't we just have users sign operations like "add Bob's new PK" with his previous PK and make it part of the published statement? then we'd just need to be sure that the first PK belongs to the right person

[@shymaaarafat1342]

u mean the directory keeps a log history of signed requests to change the key???

[@dealwithit7515]

@@shymaaarafat1342 kinda, i mean now Bob only publishes new public key, he could publish new public key + eg pair (previous public key, new public key) signed with his previous private key so Alice can use Bob's previous public key to verify it was really Bob's intention to change keys

[@shymaaarafat1342]

@@dealwithit7515 I think this is the Cryptographic proof he is talking about (under research) ie., Alice is not the one who is going to check it out, she doesn't necessarily know previous public key for Bob, maybe this is the 1st time they exchange msgs. The directory may keep a Cryptographic signature of Bob informing with the new public key, so that when/if they dispute about who changed it either the directory has a proof or not; if not it is the directory responsibility (still could be hacked, I think that what Tadje was talking about the risks of SPV and other models; maybe the recent 600m$ poly network hack involved something like this messing with the public key directory)