Dynamic Address Generation: The approach I've used isn't about static address combinations but dynamically generating addresses through key tweaking. This means the address for each transaction can be unique and created on-the-fly, enhancing privacy beyond what static multisig setups can achieve.
Efficiency and Broad Applicability: By not relying on the multisig structure, Txtailor avoids the added transaction complexity and costs associated with it. This efficiency is inherent and applicable across Bitcoin and other blockchains too( which may not use space saving techniques available via segwit)
you do know that in taproot to spend a TR, you have to reveal the spending conditions leaf hash is part of the merkle root of TR address.
yes cores protocol of cludgy code miscounts witness bytes to appear smaller, but the real BYTE data is not as small as a wallet will tell you
also in old method each TX can customise to a new multisig recipient or change the message, thus changing the hash of send 'key'.. to then cause there to be a new multisig, so not sure what you are on about as static multisig setups
I get you. I guess, what I mean is that the core feature of the client I have here is applicable across any blockchain using compatible cryptographic methods (like secp256k1), not just Bitcoin(and this is a standout property, rather than the fact people embedded messages previously or not). Me defending it being different from Multi-sig doesn't make any sense.. because it does so completely differently. It doesn't require 2 addresses for one. I guess similarly, people could do a hash > address and include this as output in their tx too... But this still doesn't allow them to spend from the address ofc(similar to multisig).
Not discounting there were methods of achieving this before, nor that (when using native Taproot) features it wouldn't be better for a more seasoned user to provide tapscripts or similar conditions for this purpose too.