Hi Gloria, Greg,
> I interpret most of the discussion around limitations as ideas for
> future improvements rather than criticisms of the proposal
As far as I'm concerned, definitely!
My current understanding is that the main change/improvement that would
make sense here is restricting the whole
> Right, good catch, this does require new logic to handle this case.
As Gloria points out, this should be doable, and is definitely worth
adding (those CSV 1 on every other output are really hacky, glad to
find a way to get rid of them).
For the record, it turns out ephemeral anchors + v3 solves
Hi all,
In short, this is yet another way to hand out addresses without interaction
between sender and recipient (Silent Payments, BIP47). The idea here is
that in non-ideal cases where you're already exposing your xpub to a server
(most light clients today, unfortunately), you might as well rely
This new version addresses most (or all) requests made in PR:
. Implements the new scheme suggested by Ruben Somsen that allows multiple
silent addresses per wallet with minimal overhead.
. Implements a new RPC to retrieve silent addresses, which allows users to
assign different labels to differ
Hi Eloy,
Nice idea.
Note I thought about and succinctly described a similar scheme here (which
in turn was derived from work by Kixunil):
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing
I agree with your general assessment that this is a scheme that seems like
a
Hi woltx,
Excellent work.
>Implements the new scheme suggested by Ruben Somsen that allows multiple
silent addresses per wallet with minimal overhead
To expand on this, the scheme basically allows the resulting address to be
recognizably marked (only recognizable by the recipient of course), whi
I'm really happy to see this discussion. I don't have any comments on the spec
because I think I'd have to be more in-the-weeds trying to implement a hww to
understand how well it works for realistic use cases. But a strong concept-ACk
from me and thanks to Salvatore for exploring this!
On Mon, M
Hi Bastien,
>The other change mentioned (making OP_TRUE standard and allowing outputs
that are below dust) can be added later, as those won't be standard until
we start allowing them, so there shouldn't be any backwards-compatibility
issue with postponing this change. But maybe it's still worth ha
Hi Jeremy,
Thanks for bringing back to awareness covenant-based drivechain designs
again!
I'm not super familiar with the thousands shades of sidechains, and
especially how the variants of pegging mechanisms influence the soundness
of the game-theory backing up the functionaries execution. Howeve
