Hi
The overhauled version of the former BIP151 has fundamental differences and
deserves (requires?) a new BIP.
Calling it „v2 peer-to-peer message transport protocol“ is more accurate since
it is no longer only about encryption.
The formatted draft proposal can be found here:
I have written up a proposed BIP. It has to do a new cross-chain debt
protocol. It is here:
https://github.com/AtomicLoans/BIP/blob/master/README.md
This BIP was written up for the Atomic Loans protocol specified here:
https://arxiv.org/pdf/1901.05117.pdf
Any feedback would be appreciated.
Good morning,
> >There's certainly some interesting about the idea of "pre-fragmenting" your
> >wallet utxo so you can make (or in payjoin: receive) payments with better
> >privacy aspects.However, it's pretty unlikely to be practical for normal
> >users, as it'll generally result in pretty
Good morning aj,
I understand.
Looks like that makes sense.
It seems possible to use this, then, together with watchtowers.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Friday, March 22, 2019 10:58 AM, Anthony Towns wrote:
> On Fri, Mar 22, 2019
They Payjoin protocol could include the possibility of receive "safe" amounts
(i.e.: 0.025 btc) to several addresses so every user using Payjoin already have
a splitted balance. Only people receiving a regular public transaction should
need the extra splitting transaction.
Regards
>I'm not really sure the problem you're describing, but it sounds like
>something that affects normal bitcoin transactions as well.
Yeah, it affects normal transactions too. But I'm focused in Payjoin because it
should allow private transactions. The problem I see is that Payjoin shouldn't
> On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev
> wrote:
>
> Good morning aj,
>>
>> If you are committing to the script code, though, then each settlement
>> sig is already only usable with the corresponding update tx, so you
>> don't need to roll the keys. But you do need to make it
On Fri, Mar 22, 2019 at 01:59:14AM +, ZmnSCPxj wrote:
> > If codeseparator is too scary, you could probably also just always
> > require the locktime (ie for settlmenet txs as well as update txs), ie:
> > OP_CHECKLOCKTIMEVERIFY OP_DROP
> > OP_CHECKDLSVERIFY OP_CHECKDLS
> > and have update
