idk how people can be so dumb to think recursive covenants matter for on chain KYC
there is a simpler and cheaper solution: 2-of-2 multisig nostr:note146cfs86faacvn03n93ypu4vdmvyw6k2w48llsmqfydjcjhcny5cq6rgsrw
Discussion
also if you get sent coins with a covenant attached, that is a different address
you just don’t accept them like you wouldn’t accept coins sent to a 2-of-2 with you as a participant instead of the singlesig key you requested
There's 2 types of people who make this argument about KYC and covenants: the poor misled retarded ones and theones that know and understand exactly what you just explain yet they insist on pushing this FUD over and over again.
IDK about kycing the whole chain. My example is that you need everyone using Bitcoin to know the difference between address types. Like imagine I swap bitcoin for cash, wait a few days before reversing the transaction cause my trade partner doesn't know the difference between bc1q and bc1x.
that is a wallet defect.
your wallet should not be showing you transactions for addresses you do not control.
any payments with covenants is a new address
the end
Well, the example people like to give is the $5 wrench attack. They force you to send them sats to their address, and later on you can reverse the transaction by changing to an output address that you control.
yeah, but they will probably hold you hostage until 6 confirmations happen, which makes it very economically expensive and usually near impossible to reverse
I only knew about 'reversing' by rising the tx fee
how does it work with bc1x (taproot?) ?
and it depends on the address type from where the utxo is sent from?
and makes no difference if I use legacy 1.. type?
bc1x doesn’t exist yet, it’s bc1p
reversing transactions is impossible unless unconfirmed
most info about covenants is misinformation
for example, if someone sends coins to you with a covenant attached, that actually becomes a different address
think of it like someone sending you sats, but with a 2-of-2 instead of the address you specified
it’s a different address, so your wallet will say “this isn’t my sats” and will ignore it
Are you saying there is no difference in terms of implementation, usability and functionality between an on-chain KYC deployment through multisig vs recursive covenants? I’ll admit that I don’t know the subject well enough to list them but my understanding is that there are some differences.
Yes. On chain covenants are still way more limited than what you can achieve with a multisig (you can’t update them later, for example)
Does this mean that if A sends some bitcoins to B under a KYC multisig then B could update the KYC rules before sending to C? But those rules couldn’t be updated by B under KYC implementation through recursive covenants?
Basically which partie(s) have the authorization to update the rules under a multisig implementation?
In the case of A sending to B, the KYCing party in the 2-of-2 can update the rules by just changing when they sign and when they don’t.
But those rules cannot be updated by the KYCing party with covenants and also can do way less