You might be interested in https://eprint.iacr.org/2017/1066.pdf which
claims that you can make CT computationally hiding and binding, see section
4.6.
with respect to utreexo, you might review
https://github.com/mit-dci/utreexo/discussions/249?sort=new which discusses
tradeoffs between different
fromGood morning Zac,
With some work, what you want can be implemented, to some extent, today,
without changes to consensus.
The point you want, I believe, is to have two sets of keys:
* A long-term-storage keyset, in "cold" storage.
* A short-term-spending keyset, in "warm" storage,
Hi Chris,
Thanks for your detailed answer. So, as you answered there is an
uncertainty about this case. For me, even this uncertainty would be a
good point to start. Because if the miners realize the potentiality for
increasing revenue under Sabu protocol, very soon they will want to
update their
Hi s7r,
I already answered to ZmnSCPxj's comments.
Let’s go to yours.
> If it is a child transaction of the Main Transaction
Sorry for my shortcoming in English, because it caused the
misunderstanding of proposal.
There is not any relation between Main Transaction and Guarantee
transaction. when
I'm pretty conservative about increasing the standard dust limit in any
way. This would convert a higher percentage of LN channels capacity into
dust, which is coming with a lowering of funds safety [0]. Of course, we
can adjust the LN security model around dust handling to mitigate the
safety
Why would removing the dust limit impact decentralisation of mining if
miners can reconfigure the dust limit for their mined blocks?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
> As feerates have gone up over time, and as we expect them to go up further,
>we should be considering drastically increasing the 3 sat/vByte basis to
>something more like 20 sat/vB.
I have no opinion on changing or removing dust limit. However, fee rates are
not going up. Yes, we expect them
