SD/SDX GUI wallet currently does not automate the shielding of coinbase funds. Users must figure out or be told to right click on a zaddr to shield funds to it.
We could have a feature where coinbase funds are shielded automatically
SD/SDX GUI wallet currently does not automate the shielding of coinbase funds. Users must figure out or be told to right click on a zaddr to shield funds to it.
We could have a feature where coinbase funds are shielded automatically
Just noting there is a 600 DRGX and 600 HUSH bounty being offered for this from a DRGX user. Unless shielding to a default z-addr automatically after a block is found, I think it could work similar to zsweep where it only needs an enable/disable option and address. Maybe allow setting an interval for how often it runs. Smaller miners don't need to shield as often.
We never added zsweep settings in GUI and settings only live in config so #88 and #90 can probably be done at the same time depending on who ends up working on it.
Just noting there is a 600 DRGX and 600 HUSH bounty being offered for this from a DRGX user. Unless shielding to a default z-addr automatically after a block is found, I think it could work similar to zsweep where it only needs an enable/disable option and address. Maybe allow setting an interval for how often it runs. Smaller miners don't need to shield as often.
We never added zsweep settings in GUI and settings only live in config so https://git.hush.is/hush/SilentDragon/issues/88 and https://git.hush.is/hush/SilentDragon/issues/90 can probably be done at the same time depending on who ends up working on it.
I want to document some details about the privacy implications of shielding coinbase funds, because I don't think I have ever seen them described and documenting them here is better than nothing. They will help us decide how we want to implement this feature.
The current way the Mining tab works is that every new block mined is mined to a new taddr, which is inherited from and exactly how Bitcoin works. This is best for privacy, because if you set -mineraddress to mine all blocks to the same taddr, that leaks metadata. Specifically, it leaks the fact that multiple different blocks were mined by the same person and it also leaks how much hashrate that miner had at the time those blocks were mined. Not the exact hashrate, but a "lower bound" (minimum) hashrate. To understand this, think about a miner mining every block to the same address. Then a 3rd party looks at a block explorer and sees that "this address mined 10 blocks in this 100 block time period". That means the miner had at least 10/100=10% of network hashrate in that time period. It's a lower bound because they simply could have been unlucky in that time period and maybe had a slightly larger % of nethash.
So it is better for privacy to mine every block to a new address and it does not slow down the wallet nor cost any more fees than mining them all to the same address. This is why the mining GUI does not allow mining everything to the same address, it was more code to write and also hurts privacy. Now let us think about what happens when these coinbase funds are shielded.
If a miner has mined all blocks to the same address, then the metadata has already leaked and spending all these coinbase funds and sending them to a zaddr does not leak any metadata. But if a miner has mined every block to a new address, then the transaction that shields them does leak metadata. Specifically, it "links" together the ownership of all the different mining addresses and says "all of these different addresses that mined these different blocks are owned by the same person". That is because all coinbase inputs to a transaction must come from the same wallet.dat . With that information a 3rd party can also estimate how many unique miners are mining, because they can say "all these addresses here are actually the same miner".
So now we can see that shielding coinbase funds which were mined to different addresses does leak metadata and this new autoshieldcoinbase feature has some options to either minimize metadata leakage or minimize transaction fees, but not both at the same time.
Shielding coinbase funds one at a time is the best for privacy (no metadata leakage about different blocks being mined by the same person) but it maximizes fees and also bloats the wallet. The default (and current way the manual shielding in the GUI works) is to shield up to 50 coinbase at once, which means up to 50 addresses are linked together as having the same owner. This is 1/50th (2%) of the fees versus shielding ever coinbase individually and does not bloat the wallet. It is also possible to give z_shieldcoinbase a custom amount of coinbase inputs to shield so you can shield more than 50 at a time. The only thing that limits how many you can shield at one time is maximum transaction size limits. I believe that it's possible to shield a few hundred at a single time before hitting that limit. Shielding the maximum amount at once pays the least fees and bloats the wallet the least, but it leaks the most metadata, potentially leaking the fact that hundreds of addresses are owned by the same miner and also leaking data about that miners hashrate.
@fekt given the above details, do you have ideas or preferences on how we should implement autoshieldcoinbase?
I want to document some details about the privacy implications of shielding coinbase funds, because I don't think I have ever seen them described and documenting them here is better than nothing. They will help us decide how we want to implement this feature.
The current way the Mining tab works is that every new block mined is mined to a new taddr, which is inherited from and exactly how Bitcoin works. This is best for privacy, because if you set `-mineraddress` to mine all blocks to the same taddr, that leaks metadata. Specifically, it leaks the fact that multiple different blocks were mined by the same person *and* it also leaks how much hashrate that miner had at the time those blocks were mined. Not the exact hashrate, but a "lower bound" (minimum) hashrate. To understand this, think about a miner mining every block to the same address. Then a 3rd party looks at a block explorer and sees that "this address mined 10 blocks in this 100 block time period". That means the miner had at least 10/100=10% of network hashrate in that time period. It's a lower bound because they simply could have been unlucky in that time period and maybe had a slightly larger % of nethash.
So it is better for privacy to mine every block to a new address and it does not slow down the wallet nor cost any more fees than mining them all to the same address. This is why the mining GUI does not allow mining everything to the same address, it was more code to write and also hurts privacy. Now let us think about what happens when these coinbase funds are shielded.
If a miner has mined all blocks to the same address, then the metadata has already leaked and spending all these coinbase funds and sending them to a zaddr does not leak any metadata. But if a miner has mined every block to a new address, then the transaction that shields them *does* leak metadata. Specifically, it "links" together the ownership of all the different mining addresses and says "all of these different addresses that mined these different blocks are owned by the same person". That is because all coinbase inputs to a transaction must come from the same wallet.dat . With that information a 3rd party can also estimate how many unique miners are mining, because they can say "all these addresses here are actually the same miner".
So now we can see that shielding coinbase funds which were mined to different addresses *does* leak metadata and this new autoshieldcoinbase feature has some options to either minimize metadata leakage or minimize transaction fees, but not both at the same time.
Shielding coinbase funds one at a time is the best for privacy (no metadata leakage about different blocks being mined by the same person) but it maximizes fees and also bloats the wallet. The default (and current way the manual shielding in the GUI works) is to shield up to 50 coinbase at once, which means up to 50 addresses are linked together as having the same owner. This is 1/50th (2%) of the fees versus shielding ever coinbase individually and does not bloat the wallet. It is also possible to give `z_shieldcoinbase` a custom amount of coinbase inputs to shield so you can shield more than 50 at a time. The only thing that limits how many you can shield at one time is maximum transaction size limits. I believe that it's possible to shield a few hundred at a single time before hitting that limit. Shielding the maximum amount at once pays the least fees and bloats the wallet the least, but it leaks the most metadata, potentially leaking the fact that hundreds of addresses are owned by the same miner and also leaking data about that miners hashrate.
@fekt given the above details, do you have ideas or preferences on how we should implement autoshieldcoinbase?
I would prefer to not leak meta data. For miners finding many blocks quickly, I think it could create problems where a shielding operation is running too frequently if setting limit to 1 utxo. Miners are already leaking meta data currently by shielding default 50 utxos at a time.
Maybe defaulting the limit to 50 as it is now and having an option to allow users to change it to a different value is the best solution?
That way users have control over how many utxos they want to shield at once and how much meta data they want to leak. Would need some tooltip explaining this. It would likely need some upper limit in GUI to prevent ridiculously high values that would fail. I've definitely shielded around 150-200 utxos before as long as it was under max tx size, but even setting upper limit as 50 or 100 would probably be a good idea.
Just thoughts. Not sure what others think.
I would prefer to not leak meta data. For miners finding many blocks quickly, I think it could create problems where a shielding operation is running too frequently if setting limit to 1 utxo. Miners are already leaking meta data currently by shielding default 50 utxos at a time.
Maybe defaulting the limit to 50 as it is now and having an option to allow users to change it to a different value is the best solution?
That way users have control over how many utxos they want to shield at once and how much meta data they want to leak. Would need some tooltip explaining this. It would likely need some upper limit in GUI to prevent ridiculously high values that would fail. I've definitely shielded around 150-200 utxos before as long as it was under max tx size, but even setting upper limit as 50 or 100 would probably be a good idea.
Just thoughts. Not sure what others think.
Related to fees, we could let users set 0 or default fee. We know a custom fee is another form of likability, but 0 is safer than some random custom fee if enough users shield or send with 0 fee.
Related to fees, we could let users set 0 or default fee. We know a custom fee is another form of likability, but 0 is safer than some random custom fee if enough users shield or send with 0 fee.
SD/SDX GUI wallet currently does not automate the shielding of coinbase funds. Users must figure out or be told to right click on a zaddr to shield funds to it.
We could have a feature where coinbase funds are shielded automatically
Just noting there is a 600 DRGX and 600 HUSH bounty being offered for this from a DRGX user. Unless shielding to a default z-addr automatically after a block is found, I think it could work similar to zsweep where it only needs an enable/disable option and address. Maybe allow setting an interval for how often it runs. Smaller miners don't need to shield as often.
We never added zsweep settings in GUI and settings only live in config so #88 and #90 can probably be done at the same time depending on who ends up working on it.
I want to document some details about the privacy implications of shielding coinbase funds, because I don't think I have ever seen them described and documenting them here is better than nothing. They will help us decide how we want to implement this feature.
The current way the Mining tab works is that every new block mined is mined to a new taddr, which is inherited from and exactly how Bitcoin works. This is best for privacy, because if you set
-mineraddressto mine all blocks to the same taddr, that leaks metadata. Specifically, it leaks the fact that multiple different blocks were mined by the same person and it also leaks how much hashrate that miner had at the time those blocks were mined. Not the exact hashrate, but a "lower bound" (minimum) hashrate. To understand this, think about a miner mining every block to the same address. Then a 3rd party looks at a block explorer and sees that "this address mined 10 blocks in this 100 block time period". That means the miner had at least 10/100=10% of network hashrate in that time period. It's a lower bound because they simply could have been unlucky in that time period and maybe had a slightly larger % of nethash.So it is better for privacy to mine every block to a new address and it does not slow down the wallet nor cost any more fees than mining them all to the same address. This is why the mining GUI does not allow mining everything to the same address, it was more code to write and also hurts privacy. Now let us think about what happens when these coinbase funds are shielded.
If a miner has mined all blocks to the same address, then the metadata has already leaked and spending all these coinbase funds and sending them to a zaddr does not leak any metadata. But if a miner has mined every block to a new address, then the transaction that shields them does leak metadata. Specifically, it "links" together the ownership of all the different mining addresses and says "all of these different addresses that mined these different blocks are owned by the same person". That is because all coinbase inputs to a transaction must come from the same wallet.dat . With that information a 3rd party can also estimate how many unique miners are mining, because they can say "all these addresses here are actually the same miner".
So now we can see that shielding coinbase funds which were mined to different addresses does leak metadata and this new autoshieldcoinbase feature has some options to either minimize metadata leakage or minimize transaction fees, but not both at the same time.
Shielding coinbase funds one at a time is the best for privacy (no metadata leakage about different blocks being mined by the same person) but it maximizes fees and also bloats the wallet. The default (and current way the manual shielding in the GUI works) is to shield up to 50 coinbase at once, which means up to 50 addresses are linked together as having the same owner. This is 1/50th (2%) of the fees versus shielding ever coinbase individually and does not bloat the wallet. It is also possible to give
z_shieldcoinbasea custom amount of coinbase inputs to shield so you can shield more than 50 at a time. The only thing that limits how many you can shield at one time is maximum transaction size limits. I believe that it's possible to shield a few hundred at a single time before hitting that limit. Shielding the maximum amount at once pays the least fees and bloats the wallet the least, but it leaks the most metadata, potentially leaking the fact that hundreds of addresses are owned by the same miner and also leaking data about that miners hashrate.@fekt given the above details, do you have ideas or preferences on how we should implement autoshieldcoinbase?
I would prefer to not leak meta data. For miners finding many blocks quickly, I think it could create problems where a shielding operation is running too frequently if setting limit to 1 utxo. Miners are already leaking meta data currently by shielding default 50 utxos at a time.
Maybe defaulting the limit to 50 as it is now and having an option to allow users to change it to a different value is the best solution?
That way users have control over how many utxos they want to shield at once and how much meta data they want to leak. Would need some tooltip explaining this. It would likely need some upper limit in GUI to prevent ridiculously high values that would fail. I've definitely shielded around 150-200 utxos before as long as it was under max tx size, but even setting upper limit as 50 or 100 would probably be a good idea.
Just thoughts. Not sure what others think.
Related to fees, we could let users set 0 or default fee. We know a custom fee is another form of likability, but 0 is safer than some random custom fee if enough users shield or send with 0 fee.