Ruben Somsen [ARCHIVE] on Nostr: 📅 Original date posted:2020-11-23 📝 Original message:Hi Adam, That's a tricky ...
📅 Original date posted:2020-11-23
📝 Original message:Hi Adam,
That's a tricky issue you're trying to tackle.
>and/or use the blockchain for that function, but that is too slow and
expensive, usually
While perhaps not the most easy/practical path to take, it IS possible to
create a custom blockchain for this specific purpose to use as a
censorship-resistant data layer via Blind Merged Mining:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017534.html
Note that while it's not described in detail in my post, there is a
(slightly suboptimal) way to do it without a soft fork.
And here are more details about the perpetual one-way peg mechanism (needed
to pay for fees without introducing speculation):
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
Cheers,
Ruben
On Mon, Nov 23, 2020 at 1:59 PM AdamISZ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Canvassing opinions/critiques from those working on bitcoin and related
> protocols.
> >
> > See the attached gist for a write-up of an outline of an idea, which is
> conceived for joinmarket but can apply in other scenarios where there is
> market for liquidity and in which privacy is a very high priority (hence
> 'bitcoin fungibility markets' can certainly include coinswap along with
> coinjoin, but possibly other things):
> >
> > https://gist.github.com/AdamISZ/b52704905cdd914ec9dac9fc52b621d6
>
> Greg Maxwell pointed out to me on IRC that this idea doesn't work: there
> is only a receipt on the commitment to the offer (message) from the maker,
> not on the plaintext version, hence there is nothing stopping the maker
> from falsely claiming censorship after not sending the plaintext.
>
> Reflecting on this a bit more, my intuition is that this problem is much
> more difficult than I had hoped; if there is a solution I suspect it
> involves much more sophisticated ideas. Many solutions just end up begging
> the question by presuming the existence of an uncensorable BB in order to
> create a new one; and/or use the blockchain for that function, but that is
> too slow and expensive, usually. I'd be happy to be proved wrong, though :)
>
> waxwing
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201123/32a9a5c5/attachment.html>;
📝 Original message:Hi Adam,
That's a tricky issue you're trying to tackle.
>and/or use the blockchain for that function, but that is too slow and
expensive, usually
While perhaps not the most easy/practical path to take, it IS possible to
create a custom blockchain for this specific purpose to use as a
censorship-resistant data layer via Blind Merged Mining:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017534.html
Note that while it's not described in detail in my post, there is a
(slightly suboptimal) way to do it without a soft fork.
And here are more details about the perpetual one-way peg mechanism (needed
to pay for fees without introducing speculation):
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
Cheers,
Ruben
On Mon, Nov 23, 2020 at 1:59 PM AdamISZ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Canvassing opinions/critiques from those working on bitcoin and related
> protocols.
> >
> > See the attached gist for a write-up of an outline of an idea, which is
> conceived for joinmarket but can apply in other scenarios where there is
> market for liquidity and in which privacy is a very high priority (hence
> 'bitcoin fungibility markets' can certainly include coinswap along with
> coinjoin, but possibly other things):
> >
> > https://gist.github.com/AdamISZ/b52704905cdd914ec9dac9fc52b621d6
>
> Greg Maxwell pointed out to me on IRC that this idea doesn't work: there
> is only a receipt on the commitment to the offer (message) from the maker,
> not on the plaintext version, hence there is nothing stopping the maker
> from falsely claiming censorship after not sending the plaintext.
>
> Reflecting on this a bit more, my intuition is that this problem is much
> more difficult than I had hoped; if there is a solution I suspect it
> involves much more sophisticated ideas. Many solutions just end up begging
> the question by presuming the existence of an uncensorable BB in order to
> create a new one; and/or use the blockchain for that function, but that is
> too slow and expensive, usually. I'd be happy to be proved wrong, though :)
>
> waxwing
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201123/32a9a5c5/attachment.html>;