ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-08-07 📝 Original message:Good morning Dmitry, Sent ...
📅 Original date posted:2019-08-07
📝 Original message:Good morning Dmitry,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 7, 2019 6:05 PM, Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> These are very creative schemes. At the very least they would stop the
> easy mindless renting TXO method, where someone with coins on a hardware
> wallet simply creates a signature and copypastes it into a website to
> get free money. The workaround scheme with shared ownership of TXOs
> requires brand new wallets to be created and hodlers must trust the
> wallets enough to move their coins and hold them there for a long time.
Possibly not so much?
The wallet need only sign two things:
1. The fidelity bond itself.
2. The backout transaction.
Both can be done in a single session, then the private key involved can be erased permanently from memory.
Only the signature for the backout needs to be stored, and this can be safely stored without encryption by publishing to any cloud service --- others getting a copy of the signature does not let them change the signature to authorize a different transaction.
It would be enough to write the signing code in C and use special OS calls (which most languages higher than C do not expose) to allocate memory that will never be put in swap.
Then generate the private key using that memory, then clear it after usage before deallocating to the OS.
I believe `libsecp256k1` makes this easy.
Unless part of the bond process requires that the taker do a challenge "sign this random nonce for me", but of note is that it would have to impose this on all makers.
But if so, consider again this:
1. There exists two non-spying makers with nearly-equal bond values.
2. These makers need to keep their bond private keys in hot storage.
3. I approach both makers and offer to aggregate their bond values, forming a new bond with 4x the weight of their individual bonds, and split up the increased earnings between us.
This can be made noncustodial by use of smart contracts on Bitcoin.
4. It is no different from the point of view of both makers: they still need to keep their bond private keys in hot storage.
But this way earns them more money than operating as non-spying makers.
5. I earn not only the fees for JoinMarket, I also earn additional fees for spying on CoinJoins.
It still seems to me that adding the V^2 tweak weakens the bond system, not strengthens it.
Regards,
ZmnSCPxj
📝 Original message:Good morning Dmitry,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 7, 2019 6:05 PM, Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> These are very creative schemes. At the very least they would stop the
> easy mindless renting TXO method, where someone with coins on a hardware
> wallet simply creates a signature and copypastes it into a website to
> get free money. The workaround scheme with shared ownership of TXOs
> requires brand new wallets to be created and hodlers must trust the
> wallets enough to move their coins and hold them there for a long time.
Possibly not so much?
The wallet need only sign two things:
1. The fidelity bond itself.
2. The backout transaction.
Both can be done in a single session, then the private key involved can be erased permanently from memory.
Only the signature for the backout needs to be stored, and this can be safely stored without encryption by publishing to any cloud service --- others getting a copy of the signature does not let them change the signature to authorize a different transaction.
It would be enough to write the signing code in C and use special OS calls (which most languages higher than C do not expose) to allocate memory that will never be put in swap.
Then generate the private key using that memory, then clear it after usage before deallocating to the OS.
I believe `libsecp256k1` makes this easy.
Unless part of the bond process requires that the taker do a challenge "sign this random nonce for me", but of note is that it would have to impose this on all makers.
But if so, consider again this:
1. There exists two non-spying makers with nearly-equal bond values.
2. These makers need to keep their bond private keys in hot storage.
3. I approach both makers and offer to aggregate their bond values, forming a new bond with 4x the weight of their individual bonds, and split up the increased earnings between us.
This can be made noncustodial by use of smart contracts on Bitcoin.
4. It is no different from the point of view of both makers: they still need to keep their bond private keys in hot storage.
But this way earns them more money than operating as non-spying makers.
5. I earn not only the fees for JoinMarket, I also earn additional fees for spying on CoinJoins.
It still seems to me that adding the V^2 tweak weakens the bond system, not strengthens it.
Regards,
ZmnSCPxj