Nicolas Dorier [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-01-28 to 2020-05-16
💬 Posted a total of 40 messages
📚 Participated in the following categories: bitcoin-dev, BIP-draft, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3

Profile Code

nprofile1qqst7p2gms9dyw0fu8sthg7fd93jmm2q9f5qj8x7rvs6pz27jz7f54ckcs3ya

Author Public Key

npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3

Show more details

Last Notes

2023-06-09 12:47:52

- reply

📅 Original date posted:2017-11-29
📝 Original message:
I noticed the Commitment Transaction Output script is weak to malleability,
this can be used to delay confirmation of the revocation.
Luckily, fixing the situation does not require lots of development.
```
OP_IF
# Penalty transaction
<revocationkey>
OP_ELSE
`to_self_delay`
OP_CSV
OP_DROP
<local_delayedkey>
OP_ENDIF
OP_CHECKSIG
```
An attacker can delay the Penalty Transaction by malleating it. Which can
lead to very bad outcome as Lightning dependant on time locks.
The penalty transaction would have.
```
<revocation_sig> 1
```
Problem is that Eve could malleate OP_1 into a positive, huge number. This
would have for effect to fill the mempool of nodes/miners with the
malleated version which will have an higher fee rate, delaying the
confirmation of the penalty transaction.
Now, there is a policy rule called SCRIPT_VERIFY_MINIMALIF by jl2012 which
was merged into v0.15.1. (
https://github.com/bitcoin/bitcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14
)
I guess that by the time LN is ready, 0.15.1 will be spread enough among
miners, but still I think a 2 bytes overhead is well worth the fix.
```
1 OP_EQUAL OP_IF
# Penalty transaction
<revocationkey>
OP_ELSE
`to_self_delay`
OP_CSV
OP_DROP
<local_delayedkey>
OP_ENDIF
OP_CHECKSIG
```
Nicolas,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171129/50ea31fc/attachment.html>

2023-06-09 12:47:52

- reply

📅 Original date posted:2017-11-29
📝 Original message:
Actually this was merged as policy rules in 0.14, not 0.15.1.
Not as bad as I thought, but still a bit uneasy about someone malleating my
transaction.
Another way to fix the situation which would not require the BOLT to change
is to enable RBF of the Penalty transaction so Eve transaction would be
replaced by the initial one.
Nicolas,
On Wed, Nov 29, 2017 at 4:11 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> I noticed the Commitment Transaction Output script is weak to
> malleability, this can be used to delay confirmation of the revocation.
> Luckily, fixing the situation does not require lots of development.
>
> ```
> OP_IF
> # Penalty transaction
> <revocationkey>
> OP_ELSE
> `to_self_delay`
> OP_CSV
> OP_DROP
> <local_delayedkey>
> OP_ENDIF
> OP_CHECKSIG
> ```
>
> An attacker can delay the Penalty Transaction by malleating it. Which can
> lead to very bad outcome as Lightning dependant on time locks.
>
> The penalty transaction would have.
>
> ```
> <revocation_sig> 1
> ```
>
> Problem is that Eve could malleate OP_1 into a positive, huge number. This
> would have for effect to fill the mempool of nodes/miners with the
> malleated version which will have an higher fee rate, delaying the
> confirmation of the penalty transaction.
>
> Now, there is a policy rule called SCRIPT_VERIFY_MINIMALIF by jl2012 which
> was merged into v0.15.1. (https://github.com/bitcoin/bi
> tcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14)
>
> I guess that by the time LN is ready, 0.15.1 will be spread enough among
> miners, but still I think a 2 bytes overhead is well worth the fix.
>
> ```
> 1 OP_EQUAL OP_IF
> # Penalty transaction
> <revocationkey>
> OP_ELSE
> `to_self_delay`
> OP_CSV
> OP_DROP
> <local_delayedkey>
> OP_ENDIF
> OP_CHECKSIG
> ```
>
> Nicolas,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171129/b09e1ce1/attachment.html>

2023-06-09 12:47:03

- reply

📅 Original date posted:2017-02-10
📝 Original message:
Well two transactions to be confirmed is not too bad. Approximately 30
minutes. Compare that to the time it takes to apply for a prepaid debit
card.
So we have two possibilities so far without segwit: one transaction to be
confirmed but definite channel lifetime.
Or two transactions to be confirmed but indefinite channel lifetime.
Not sure yet what is the best from user perspective as channel renewal can
be done in the background.
On Fri, Feb 10, 2017 at 2:51 AM, "Christopher Jämthagen" <cjamthagen at gmx.com
> wrote:
> Two-layer HTLCs still need a malleability fix or some other workaround to
> avoid excessive timeouts.
>
> /Christopher
>
> *Sent:* Wednesday, February 08, 2017 at 5:16 AM
> *From:* "Nicolas Dorier" <nicolas.dorier at gmail.com>
> *To:* "Tier Nolan" <tier.nolan at gmail.com>
> *Cc:* lightning-dev at lists.linuxfoundation.org
> *Subject:* Re: [Lightning-dev] Anchor transaction for no expiration
> channels without segwit
> With this solution, is there any problem left without Segwit outside no
> third party channel monitoring and channel establishment which need to wait
> Bob bounty expiration ?
>
> On Tue, Feb 7, 2017 at 9:02 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>>
>> On Tue, Feb 7, 2017 at 2:39 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
>> wrote:
>>
>>> Good point, actually, a simpler way to do it, is for TX2 to be
>>> nTimelocked after bounty's expiration.
>>>
>>
>> That works too and keeps the transaction smaller.
>>
>> I think a symmetrically funded channel needs 4 1BTC outputs, so it is
>> pretty much two single funded channels. It would be slightly smaller than
>> 2 transactions to open the channel.
>>
>> TX1
>>
>> Input
>> 2 from Alice
>> 2 from Bob
>>
>> Output
>> 1: (Alice + Bob) OR (Bob + AliceSecret)
>> 1: (Alice + Bob) OR (Alice + BobSecret)
>> 1: (Bob + timeout(now + T)) OR (Alice + AliceSecret)
>> 1: (Alice + timeout(now + T)) OR (Bob + BobSecret)
>>
>> TX2
>> locktime: now + 2T
>>
>> Input
>> TX1/0: signed by (Alice + Bob)
>> TX1/1: signed by (Alice + Bob)
>> Output
>> Initial channel paying Alice & Bob 1BTC each
>>
>> ---------------------------------------
>>
>> Alice and Bob create TX1, sign it and share the result.
>>
>> Alice and Bob create TX2, sign it and share the result.
>>
>> Abort for those 2 steps:
>> * If one signs and the other doesn't then the signer should spend their
>> inputs to be safe.
>> * If TX1 is broadcast, then they can both spend their timeouts to
>> recover their funds, so it is safe.
>>
>> Once they both have signed versions of TX1 and TX2, they should broadcast
>> TX1. This initializes the channel.
>>
>> If TX1 is mutated, then they should both abort and spend their timeouts
>> and recover their funds.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
> _______________________________________________ Lightning-dev mailing
> list Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170210/a5c4bb17/attachment.html>

2023-06-09 12:47:02

- reply

📅 Original date posted:2017-02-08
📝 Original message:
The locktime is basically useless.
The reason for the locktime was to give bob time to reclaim the bounty
before Alice can broadcast TX2.
But with AliceSecret1 in TX2, if alice ever broadcast and take the bounty,
Bob can confiscate TX2:0.
AliceSecret2 is courtesy of Alice, so bob can get the bouncy back. It is
unsafe to Bob to start using the channel before he could reclaim the bounty
with some confirmation.
On Wed, Feb 8, 2017 at 7:25 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
> On Wed, Feb 8, 2017 at 9:32 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
> wrote:
>
>> Tadge had an idea so we do not need any nTimeLock:
>>
>
> I think the nLocktime for TX2 is basically costless. It just prevents
> channel fast initial channel close.
>
> Once an unchanged version of TX1 is in the blockchain, all further updates
> of the channel can exclude the nLocktime..
>
> > 1 BTC Bob+Timeout OR Alice+AliceSecret1 OR Bob+AliceSecret2 (aka the
> bounty)
>
> This is so that Alice can unlock the bounty once the channel is setup, as
> a courtesy?
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170208/e7ea62f6/attachment.html>

2023-06-09 12:47:02

- reply

📅 Original date posted:2017-02-08
📝 Original message:
Tadge had an idea so we do not need any nTimeLock:
TX1
Input:
1 BTC From Alice
1 BTC From Bob
Output:
1 BTC Alice+Bob OR Bob+AliceSecret1
1 BTC Bob+Timeout OR Alice+AliceSecret1 OR Bob+AliceSecret2 (aka the
bounty)
TX2
Input:
TX1:0 using Alice+Bob
Output:
1 BTC Alice+Bob+100 CSV OR Bob+AliceSecret1
So basically, if Alice try to broadcast TX2 and claim TX1:1 with
Alice+AliceSecret1, Bob can claim TX2:0 with Bob+AliceSecret1.
The condition Bob+AliceSecret2 in TX1:1 is useful such that Bob can claim
the bounty without having to wait the Timeout.
Channel establishment will basically take twice more time than a normal
channel with expiration.
On Wed, Feb 8, 2017 at 1:16 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> With this solution, is there any problem left without Segwit outside no
> third party channel monitoring and channel establishment which need to wait
> Bob bounty expiration ?
>
> On Tue, Feb 7, 2017 at 9:02 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>> On Tue, Feb 7, 2017 at 2:39 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
>> wrote:
>>
>>> Good point, actually, a simpler way to do it, is for TX2 to be
>>> nTimelocked after bounty's expiration.
>>>
>>
>> That works too and keeps the transaction smaller.
>>
>> I think a symmetrically funded channel needs 4 1BTC outputs, so it is
>> pretty much two single funded channels. It would be slightly smaller than
>> 2 transactions to open the channel.
>>
>> TX1
>>
>> Input
>> 2 from Alice
>> 2 from Bob
>>
>> Output
>> 1: (Alice + Bob) OR (Bob + AliceSecret)
>> 1: (Alice + Bob) OR (Alice + BobSecret)
>> 1: (Bob + timeout(now + T)) OR (Alice + AliceSecret)
>> 1: (Alice + timeout(now + T)) OR (Bob + BobSecret)
>>
>> TX2
>> locktime: now + 2T
>>
>> Input
>> TX1/0: signed by (Alice + Bob)
>> TX1/1: signed by (Alice + Bob)
>> Output
>> Initial channel paying Alice & Bob 1BTC each
>>
>> ---------------------------------------
>>
>> Alice and Bob create TX1, sign it and share the result.
>>
>> Alice and Bob create TX2, sign it and share the result.
>>
>> Abort for those 2 steps:
>> * If one signs and the other doesn't then the signer should spend their
>> inputs to be safe.
>> * If TX1 is broadcast, then they can both spend their timeouts to
>> recover their funds, so it is safe.
>>
>> Once they both have signed versions of TX1 and TX2, they should broadcast
>> TX1. This initializes the channel.
>>
>> If TX1 is mutated, then they should both abort and spend their timeouts
>> and recover their funds.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170208/16bdb873/attachment.html>

2023-06-09 12:47:01

- reply

📅 Original date posted:2017-02-07
📝 Original message:
Good point, actually, a simpler way to do it, is for TX2 to be nTimelocked
after bounty's expiration.
If Alice see bob not signing it, she can reclaim the bounty fast.
If bob sign it, Alice can't broadcast it immediately.
On Tue, Feb 7, 2017 at 5:02 AM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>
> On Mon, Feb 6, 2017 at 4:32 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
> wrote:
>
>> I think you do not need the second timeout.
>>
>> TX2 would be signed by Bob only once he could get back the second Output
>> of TX1.
>>
>
> Alice must have a fully signed version of TX2 before the timeout finishes.
>
> If she doesn't, then Bob can reclaim TX1/1 once the timeout expires and
> then refuse to sign TX2.
>
> If Alice has a signed version of TX2, then she can broadcast it and
> immediately close the channel (claiming TX1/0).
>
> Once that has been accepted, she can then claim TX1/1.
>
>
>
>> So Bob does not have to worry about Alice closing the channel with TX2.
>>
>> Nicolas,
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170207/d4f959a1/attachment.html>

2023-06-09 12:47:01

- reply

📅 Original date posted:2017-02-06
📝 Original message:
I think you do not need the second timeout.
TX2 would be signed by Bob only once he could get back the second Output of
TX1.
So Bob does not have to worry about Alice closing the channel with TX2.
Nicolas,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170207/29b9367f/attachment.html>

2023-06-09 12:47:01

- reply

📅 Original date posted:2017-02-08
📝 Original message:
With this solution, is there any problem left without Segwit outside no
third party channel monitoring and channel establishment which need to wait
Bob bounty expiration ?
On Tue, Feb 7, 2017 at 9:02 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
> On Tue, Feb 7, 2017 at 2:39 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
> wrote:
>
>> Good point, actually, a simpler way to do it, is for TX2 to be
>> nTimelocked after bounty's expiration.
>>
>
> That works too and keeps the transaction smaller.
>
> I think a symmetrically funded channel needs 4 1BTC outputs, so it is
> pretty much two single funded channels. It would be slightly smaller than
> 2 transactions to open the channel.
>
> TX1
>
> Input
> 2 from Alice
> 2 from Bob
>
> Output
> 1: (Alice + Bob) OR (Bob + AliceSecret)
> 1: (Alice + Bob) OR (Alice + BobSecret)
> 1: (Bob + timeout(now + T)) OR (Alice + AliceSecret)
> 1: (Alice + timeout(now + T)) OR (Bob + BobSecret)
>
> TX2
> locktime: now + 2T
>
> Input
> TX1/0: signed by (Alice + Bob)
> TX1/1: signed by (Alice + Bob)
> Output
> Initial channel paying Alice & Bob 1BTC each
>
> ---------------------------------------
>
> Alice and Bob create TX1, sign it and share the result.
>
> Alice and Bob create TX2, sign it and share the result.
>
> Abort for those 2 steps:
> * If one signs and the other doesn't then the signer should spend their
> inputs to be safe.
> * If TX1 is broadcast, then they can both spend their timeouts to recover
> their funds, so it is safe.
>
> Once they both have signed versions of TX1 and TX2, they should broadcast
> TX1. This initializes the channel.
>
> If TX1 is mutated, then they should both abort and spend their timeouts
> and recover their funds.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170208/7de2d4d4/attachment.html>

2023-06-09 12:47:00

- reply

📅 Original date posted:2017-02-06
📝 Original message:
Alice opening channel of 1BTC
Input:
1 BTC From Alice
1 BTC From Bob
Output:
1 BTC Alice+Bob OR Bob+AliceSecret
1 BTC Bob+Timeout OR Alice+AliceSecret (aka the bounty)
If bob is unresponsive, Alice can get the bounty.
If Alice unresponsive, bob can get the bounty after timeout.
If Alice takes the bounty, Bob can take the escrow .
If Alice responsive, bob wait for getting the bounty. The use of the
channel will start after bob get the bounty back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170206/465ae0f1/attachment.html>

2023-06-09 12:45:57

- reply

📅 Original date posted:2016-03-08
📝 Original message:
That's my fault, I said "R-Value" instead of "Commit Revocation Hash".
I've not yet thought about how the idea of hash chain can be used for HTLC.
On Wed, Mar 9, 2016 at 1:27 AM, Mats Jerratsch <mats at blockchain.com> wrote:
> Hah I see, I didn't knew you weren't talking about HTLCs.
>
> But why would you use R values in the first place then? Maybe I'm a
> little bit confused about what exact use case we are talking here, mind
> elaborating? :)
>
> Am 08/03/2016 um 16:14 schrieb Nicolas Dorier:
> > I don't understand your point, but that may come from me not having
> > deep enough knowledge about the latest great things happening on
> > Lightning.
> >
> > I exposed the case of a simple bipayment channel, without HTLC in the
> > equation, where all payments are sequential.
> >
> > You can't make commitment n+2 before accepting commitment n+1.
> >
> > My mental model might be incomplete as I'm followed only remotely
> > the improvements of lightning until now.
> >
> > On Wed, Mar 9, 2016 at 12:53 AM, Mats Jerratsch <mats at blockchain.com
> > <mailto:mats at blockchain.com>> wrote:
> >
> > I'm not saying they close the channel. Alice could want to receive
> more
> > money and accept other payments, but not a particular one. But by
> doing
> > so, she would automatically disclose R for any old payment.
> >
> > Am 08/03/2016 um 15:51 schrieb Nicolas Dorier:
> > > I'm not sure what you mean Alice don't have to disclose R if she
> does
> > > not want to.
> >
> > --
> > Mats Jerratsch
> > Backend Engineer, Blockchain
> > e: mats at blockchain.com <mailto:mats at blockchain.com>
> > PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
> >
> >
>
> --
> Mats Jerratsch
> Backend Engineer, Blockchain
> e: mats at blockchain.com
> PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160309/a8253fb1/attachment-0001.html>

2023-06-09 12:45:56

- reply

📅 Original date posted:2016-03-08
📝 Original message:
I don't understand your point, but that may come from me not having
deep enough knowledge about the latest great things happening on
Lightning.
I exposed the case of a simple bipayment channel, without HTLC in the
equation, where all payments are sequential.
You can't make commitment n+2 before accepting commitment n+1.
My mental model might be incomplete as I'm followed only remotely
the improvements of lightning until now.
On Wed, Mar 9, 2016 at 12:53 AM, Mats Jerratsch <mats at blockchain.com> wrote:
> I'm not saying they close the channel. Alice could want to receive more
> money and accept other payments, but not a particular one. But by doing
> so, she would automatically disclose R for any old payment.
>
> Am 08/03/2016 um 15:51 schrieb Nicolas Dorier:
> > I'm not sure what you mean Alice don't have to disclose R if she does
> > not want to.
>
> --
> Mats Jerratsch
> Backend Engineer, Blockchain
> e: mats at blockchain.com
> PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160309/da779a3b/attachment-0001.html>

2023-06-09 12:45:55

- reply

📅 Original date posted:2016-03-08
📝 Original message:
I'm not sure what you mean Alice don't have to disclose R if she does not
want to.
Bob can't know the next R because R(n+1) = PreImage(R(n))
On Wed, Mar 9, 2016 at 12:16 AM, Mats Jerratsch <mats at blockchain.com> wrote:
> What about if Alice does not want to disclose R? Bob could have taken
> too much fee and Alice does not agree to accept a payment too small.
>
> While there is technically not really a security problem in disclosing
> the R values when the payment isn't in the current commitment, the whole
> idea of 'proof-of-payment'/'pay-to-contract' relies on only revealing R
> for an accepted payment.
>
> Otherwise, knowing R is no longer proof of having made a payment.
>
> Am 08/03/2016 um 07:19 schrieb CJP:
> > I was wondering: how does deriving R values from a tree structure work
> > for larger Lightning networks? I guess it could work between two nodes,
> > if they keep track of the same tree, but if different transactions
> > follow different routes, does that mean the tree structure somehow has
> > to be shared across all nodes? The alternative is that intermediate
> > nodes still have to remember old R values.
> >
> > CJP
> >
> >
> > Nicolas Dorier schreef op di 08-03-2016 om 13:53 [+0900]:
> >> Great, indeed we had same idea, I don't see how it solve the hashes in
> >> advance.
> >> As Alice knows
> >> H(1000000) = <random secret seed>).
> >> If she need the hash to the first commitment she need to hash the
> random secret
> >> seed 1000000 times. I think it is exactly the same problem as it is the
> exact
> >> same idea said differently.
> >>
> >> On Tue, Mar 8, 2016 at 8:31 AM, Rusty Russell <rusty at rustcorp.com.au>
> >> wrote:
> >> Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> >> > One way deterministic RValue Generation
> >>
> >> Hi Nicolas,
> >>
> >> Yes, in fact shachain is a variant of this which
> >> avoids
> >> generating several million hashes in advance. Interesting, I
> >> suggested
> >> using hashing in the Deployable Lightning paper but didn't
> >> actually
> >> spell out the idea. Hmm....
> >>
> >> Seems like it orignated from Adam Back:
> >>
> >>
> https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html
> >>
> >> Cheers,
> >> Rusty.
> >>
> >>
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
> --
> Mats Jerratsch
> Backend Engineer, Blockchain
> e: mats at blockchain.com
> PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160309/1419e43d/attachment-0001.html>

2023-06-09 12:45:55

- reply

📅 Original date posted:2016-03-08
📝 Original message:
Great, indeed we had same idea, I don't see how it solve the hashes in
advance.
As Alice knows
H(1000000) = <random secret seed>).
If she need the hash to the first commitment she need to hash the random secret
seed 1000000 times. I think it is exactly the same problem as it is the exact
same idea said differently.
On Tue, Mar 8, 2016 at 8:31 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> > One way deterministic RValue Generation
>
> Hi Nicolas,
>
> Yes, in fact shachain is a variant of this which avoids
> generating several million hashes in advance. Interesting, I suggested
> using hashing in the Deployable Lightning paper but didn't actually
> spell out the idea. Hmm....
>
> Seems like it orignated from Adam Back:
>
> https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/a4994ce6/attachment-0001.html>

2023-06-09 12:45:54

- reply

📅 Original date posted:2016-03-07
📝 Original message:
One way deterministic RValue Generation
My previous proposal, while saving space on chain, does not
solve the fact that we need to save offchain one signature per
commitment.
I have another proposal, so you don't need any data to store for
each commitment.
Keep the actual HTLC/Payment channel contracts, but make
the "RValues" backward deterministic.
Choose RValue such that:
RValue(n+1) = PreImage(RValue(n))
Where n is the commitment index.
Imagine Alice cheats Bob at commitment 100, by sending revocated
commitment 50.
Bob only have to remember RValue(99) from the 99th revocation, and
then hash this value 49 times to find out RValue(50)
However, Bob does not know RValue(100) because
RValue(100) = PreImage(99)
For Alice, she only have to generate a random number, then generate let's
say, 1000 hashes. Then she use hashes 1000 for RValue(0), hashes 999 for
RValue(1)
etc...
Commitment Revocation is only accepted by the party if RValue(n+1) =
PreImage(RValue(n))
The only downside is that Alice need to regenerate all hashes everytimes
she need
a new commitment. This can be mitigated by her storing some pre computed
values
along the path.
Nicolas,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/92040252/attachment.html>

2023-06-09 12:45:51

- reply

📅 Original date posted:2016-03-08
📝 Original message:
I am catching up with the latest dev of lightning.
I thought you wanted SIGHASH_NOPINPUT in order
to fix the problem of storage requirement.
I have not thought about using private key on HD.
However, I think the index (also used for derivation)
of the commitment would need to be stored in the
transaction.
So if Bob notice old commitment, he does not have
to bruteforce what was the key he used.
I re-read slowly your post on bitcoin-dev about
SIGHASH_NOINPUT, and noticed the problem it
was to fix was for third party monitoring.
But that the linear storage of the channel participant
was a problem already solved. I'm synching. :)
On Tue, Mar 8, 2016 at 11:56 AM, Joseph Poon <joseph at lightning.network>
wrote:
> Hi Nicolas,
>
> Yes, I do think exploring using signatures as a method of revocation is
> interesting! For revoking Commitments, I believe if you did disclosure
> of the private-key as a method of revocation, then it's possible to
> achieve this compactness without using OP_CODESEPARATOR.
>
> Side note: It's necessary to disclose temporary private keys (instead of
> signatures) under this mechanism, since it's possible to compactly store
> the keys by making it derived from a tree or chain of hash functions.
>
> A compact revocable example for Bob to broadcast could be:
> <PubkeyAlice> OP_CHECKSIG
> OP_NOTIF
> <CSVDelay> OP_DROP OP_CSV
> OP_ENDIF
> <PubkeyBob>
> OP_CHECKSIG
>
> On the other hand, if Alice broadcasted it, her script could be:
> <PubkeyBob> OP_CHECKSIG
> OP_NOTIF
> <CSVDelay> OP_DROP OP_CSV
> OP_ENDIF
> <PubkeyAlice>
> OP_CHECKSIG
>
> Alice successful redemption of her broadcast would be:
> (after one week)
> <AliceSig> <0>
>
> Bob's penalty transaction on Alice's broadcast would be:
> <AliceSig> <BobSig>
>
> If Alice did not broadcast the correct Commitment, Bob can take the
> money immediately because she disclosed her private key when creating
> the new Commitment transaction, so Bob has both PrivkeyBob and
> PrivkeyAlice. If Alice correctly broadcast the most recent Commitment,
> Bob does not have PrivkeyAlice so he cannot take the funds, but Alice
> does not have PrivkeyBob so she has to wait for the CSV delay.
>
> If the goal is to save space, it saves a little in the
> timeout/non-penalty case, but the transactions are larger for penalty
> cases (although they may be less frequent).
>
> It's also possible to make it just a multisig output with the child
> transaction spending from it pre-signed as well using nSequence, but
> that requires more storage and more on-chain transactions (while saving
> in the script output size), this design is not necessary for this
> particular instance if there's OP_CSV.
>
> As a side note, OP_CODESEPARATOR may become useful if there is
> SIGHASH_NOINPUT inside segregated witness in the future, by being able
> to have one signature be able to apply towards multiple types of
> transactions (e.g. different redeemScript/scriptPubKey r-values or
> pubkeys).
>
> --
> Joseph Poon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/27be3571/attachment-0001.html>

2023-06-09 12:45:51

- reply

📅 Original date posted:2016-03-08
📝 Original message:
Yes they do,
But I did not thought you had a way not to store one R value per
commitment.
If you store one R Value per commitment, then the solution with
OP_CODESEPARATOR is strictly better as it saves space on
blockchain.
So indeed if old commit tx are published, they need to fetch the
signatures.
Nicolas,
On Tue, Mar 8, 2016 at 4:09 AM, Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:
> Hi,
> I may have misunderstood something, but with this scheme instead of R
> + shachain/elkrem, then how do nodes react when old commit tx are
> published ? It seems that they would have to store lots of signatures
> ?
>
>
> On 7 March 2016 at 08:28, Nicolas Dorier <nicolas.dorier at gmail.com> wrote:
> > I managed to adapt the payment channel script to use less space.
> >
> > This version is winning around 32 bytes in the scriptpubkey (for the R
> > value) as well as 70 bytes in the signature when Alice close the channel.
> >
> > Alice closing the channel:
> >
> http://n.bitcoin.ninja/checkscript?savedScript=51225750-f245-45b5-a86c-6ca1e87dcafb
> >
> > Bob using revocation:
> >
> http://n.bitcoin.ninja/checkscript?savedScript=c4d7ebaa-5a79-4c03-ab55-c499854f1e94
> >
> > This amount to 100 bytes saved between the anchor transaction +
> commitment
> > broadcasted.
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/f7b0831e/attachment-0001.html>

2023-06-09 12:45:50

- reply

📅 Original date posted:2016-03-07
📝 Original message:
I'm amazed as I found a useful case for OP_CODESEPARATOR.
I think the script can be improved to take less byte for removing the
duplication of <KeyA>, will take a look later.
Let's change escape redeem:
OP_HASH160 <RHashA> OP_EQUAL
OP_IF
<KeyB>
OP_ELSE
<Delay> OP_CSV OP_DROP
<KeyA>
OP_ENDIF
OP_CHECKSIG
To
<KeyA> OP_CHECKSIG
OP_IF
<KeyB>
OP_ELSE
<Delay> OP_CSV OP_DROP
OP_CODESEPARATOR <KeyA>
OP_ENDIF
OP_CHECKSIG
The Escape output would be
<SIG-B> <SIGA-Revocation> {<ESCAPE-REDEEM>}
Where SIGA-Revocation is the signature of KeyA computed with the
ScriptCode=<ESCAPE-REDEEM>
The second escape would be
<SIG-A> 0 {<ESCAPE-REDEEMSCRIPT>}
where <SIG-A> script equals to
<KeyA>
OP_ENDIF
OP_CHECKSIG
You would revoke a commitment by revealing <SIGA-Revocation>
Btw, you can play with http://n.bitcoin.ninja/checkscript to test such
script (I'm checking it myself)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/20fd0605/attachment.html>

2023-06-09 12:45:50

- reply

📅 Original date posted:2016-03-07
📝 Original message:
I managed to adapt the payment channel script to use less space.
This version is winning around 32 bytes in the scriptpubkey (for the R
value) as well as 70 bytes in the signature when Alice close the channel.
Alice closing the channel:
http://n.bitcoin.ninja/checkscript?savedScript=51225750-f245-45b5-a86c-6ca1e87dcafb
Bob using revocation:
http://n.bitcoin.ninja/checkscript?savedScript=c4d7ebaa-5a79-4c03-ab55-c499854f1e94
This amount to 100 bytes saved between the anchor transaction + commitment
broadcasted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/adaf7917/attachment.html>

2023-06-09 12:45:19

- reply

📅 Original date posted:2015-11-27
📝 Original message:
> But B won't be able to guess what the <revoke> hash is, so won't be
> able to correlate with potential anchor transactions at all, afaics,
> even if pubkeys <A> and <B> are both known to B?
Did not thought about that, yes you are right.
> Yeah, it's 99% of the way there; I just worry about random vandalism,
> personally.
Yes, I was worrying about B pro actively malleating everything.
But since A controls broadcast time, he can choose to delay the broadcast
when a vast malleability attack happens.
On Sat, Nov 28, 2015 at 5:11 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:
> > > A also passes the original unsigned commitment to B, who verifies that
> > > it's in the right format (ie, can be revoked), and hashes to the hash
> > > that he signed.
> > No, if A pass the unsigned commitment to B then B can malleate the
> anchor.
>
> Sorry, I meant the above needs to happen after the anchor's confirmed
> in the blockchain (and A's told B about the anchor).
>
> > > B can't reuse pubkeys between different channels with this protocol
> > > either, but that's good practice anyway.
> > Right, neither A should. If A reuse a key, then B can guess the redeem
> > hash, then would identify the transaction to malleate at broadcast time,
> > before A's announcement.
>
> B will be providing a signature for a tx that:
>
> - has the anchor as input
> - has a single refund output payable to
> (A && OP_CSV) | (B && OP_HASH <revoke> OP_EQUALVERIFY)
>
> But B won't be able to guess what the <revoke> hash is, so won't be
> able to correlate with potential anchor transactions at all, afaics,
> even if pubkeys <A> and <B> are both known to B?
>
> > I'd prefer seggregated witness to fix the problem cleanly, but I think
> that
> > opening the channel as I said is a good enough workaround until it
> happen.
>
> Yeah, it's 99% of the way there; I just worry about random vandalism,
> personally.
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/ea994660/attachment-0001.html>

2023-06-09 12:45:18

- reply

📅 Original date posted:2015-11-27
📝 Original message:
By adapting an idea from gmaxwell (
https://bitcointalk.org/index.php?topic=303088.0) it is possible to open a
channel without suffering from malleability attack.
The process for A to open channel with B is the following:
* A asks B pubkey
* A create the first commitment transaction
* A extract the hash that B needs to sign to be able to broadcast the
commitment
* A asks B to sign the hash, but do not disclose the commitment
* A broadcast the anchor
* After confirmation, A announce the anchor to B.
B can't identify A's anchor before announcement because he does not know
the P2SH of the multisig.
Am I missing something ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151127/f2d6361b/attachment.html>

2023-06-09 12:45:18

- reply

📅 Original date posted:2015-11-27
📝 Original message:
> A also passes the original unsigned commitment to B, who verifies that
> it's in the right format (ie, can be revoked), and hashes to the hash
> that he signed.
No, if A pass the unsigned commitment to B then B can malleate the anchor.
(because B would know the txid of the anchor at broadcast time)
B does not have to verify it is in right format, because he does not have
anything to loose by signing a random hash.
B can verify he signed the hash of the first commitment after A announce
his already confirmed anchor.
> Someone other than B (ie a third party) could malleate the anchor between
> broadcast and confirmation just for their own amusement.
Yes, actually the only malleability vector which B can use to his advantage
is HighS, not all BIP62 vectors.
Knowing miners will most likely run at least 0.11.2 (if CLTV is acceepted)
HighS should be more likely rejected.
> B can't reuse pubkeys between different channels with this protocol
> either, but that's good practice anyway.
Right, neither A should. If A reuse a key, then B can guess the redeem
hash, then would identify the transaction to malleate at broadcast time,
before A's announcement.
I'd prefer seggregated witness to fix the problem cleanly, but I think that
opening the channel as I said is a good enough workaround until it happen.
The only attack B can try is malleate all transaction to HighS.
When CLTV will pass, there is not lot of probability of such attack to
succeed, because bitcoind should block HighS.
> 'without timeout' is only possible with OP_CSV - not naturally
with what we have currently. ;)
The anchor does not have to use OP_CSV at all. But yes, for commitment, I'm
assuming OP_CSV passed.
> To be able to build a valid payment channel on top of the anchor,
B has to be sure that A cannot get her money back at any point in the
future. Given just a hash that B should sign, B has no clue what is
the output of the transaction he just signed.
Actually B do not care about it. Remember I am separating "A's anchor
broadcast" from "A's announcement of anchor to B".
When A announce the anchor, then B can check if he really signed the first
commitment or something else, but he can't malleate anything since the
anchor is already confirmed.
B does not have anything to loose by signing unknown hash. (if he use a non
reusable key)
Again, yes, a network-wide HighS attack would be the only way to malleate
the anchor.
If CLTV fork pass, then it is fair to consider that the odd of such attack
succeeding is very low. HighS should be blocked from 0.11.1 if I remember
well.
On Fri, Nov 27, 2015 at 6:09 PM, Anthony Towns <aj at erisian.com.au> wrote:
> On Fri, Nov 27, 2015 at 04:37:04PM +0900, Nicolas Dorier wrote:
> > By adapting an idea from gmaxwell (
> > https://bitcointalk.org/index.php?topic=303088.0) it is possible to
> open a
> > channel without suffering from malleability attack.
> > The process for A to open channel with B is the following:
> > * A asks B pubkey
> > * A create the first commitment transaction
> > * A extract the hash that B needs to sign to be able to broadcast the
> > commitment
> > * A asks B to sign the hash, but do not disclose the commitment
> > * A broadcast the anchor
> > * After confirmation, A announce the anchor to B.
>
> A also passes the original unsigned commitment to B, who verifies that
> it's in the right format (ie, can be revoked), and hashes to the hash
> that he signed.
>
> > B can't identify A's anchor before announcement because he does not know
> > the P2SH of the multisig.
> > Am I missing something ?
>
> Someone other than B (ie a third party) could malleate the anchor between
> broadcast and confirmation just for their own amusement.
>
> B can't reuse pubkeys between different channels with this protocol
> either, but that's good practice anyway.
>
> From the same forum post, using child-pays-for-parent seems plausible.
> Doing:
>
> txA: spend 6 BTC to
> 5 BTC to A&B
> 1 BTC to A
>
> txB: spend 1 BTC from txA:1 to
> 0.999 BTC to A
>
> should be pretty safe: either someone malleates txA and mines it for
> 0 fee; or they mine both txA+txB for 0.001 BTC fee, and txA can't be
> malleated. But CPFP doesn't work yet, and segregated witness seems like
> it'll happen sooner anyway?
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/454bf694/attachment.html>

2023-06-09 12:45:17

- reply

📅 Original date posted:2015-11-27
📝 Original message:
As I documented on https://github.com/ElementsProject/lightning/issues/14 the
problem is not easily solved because the dust amount is not constant. It
depends on minTxRelayFee which itself depends on the mempool state of each
node.
A way to decouple mintxrelayfee from dust is needed. I proposed to tie the
dust definition to transaction's fee. But had problem during implementation
because of some circular dependency.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151127/660ad76e/attachment.html>

2023-06-09 12:45:12

- reply

📅 Original date posted:2015-11-24
📝 Original message:
I am still learrning about Lightning Network, slowly but surely.
As I was reviewing bip 112 (
https://github.com/btcdrak/bips/blob/bip112sync/bip-0112.mediawiki) I
noticed that HLTC seems to have a potential attack.
When both parties want to revoke a commitment, they need to send one to
another the revocation preimage.
However, if not done atomically, Alice intentionally not send her
revocation after receiving Bob's thus preventing Bob to withdraw his funds.
Am I missing something ?
The only way I see of fixing as is, is to require a third party expecting
he does not collude, but this defeat the whole purpose.
Nicolas,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151124/9ee4f363/attachment.html>

2023-06-07 18:24:46

- reply

📅 Original date posted:2020-05-16
📝 Original message:I am requesting a BIP number to be allocated for this simple payjoin proposal.
This proposal is already being implemented by several service and
wallets and incorporate the feedback of the community at
https://github.com/NicolasDorier/bips/pull/3
I opened a pull request at: https://github.com/bitcoin/bips/pull/923
I am not checking my mail very often, so I suggest give me feedback
directly on the opened pull request.
<pre>
BIP: ?
Layer: Applications
Title: A Simple Payjoin Proposal
Author: Nicolas Dorier <nicolas.dorier at gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-X
Status: Draft
Type: Standards Track
Created: 2019-05-01
License: BSD-2-Clause
</pre>
==Introduction==
===Abstract===
This document proposes a protocol for two parties
to negotiate a coinjoin transaction during a payment between them.
===Copyright===
This BIP is licensed under the 2-clause BSD license.
===Motivation===
When two parties (later referred to as sender and receiver) want to transact,
most of the time, the sender creates a transaction spending their own
Unspent Transaction Outputs (UTXOs), signs
it and broadcasts it on the network.
This simple model gave birth to several heuristics impacting the
privacy of the parties and of the network as a whole.
* Common input ownership heuristic: In most transactions, all the
inputs belong to the same party.
* Change identification from scriptPubKey type: If all inputs are
spending UTXOs of a certain scriptPubKey type, then the change output
is likely to have the same scriptPubKey type, too.
* Change identification from round amount: If an output in the
transaction has a round amount, it is likely an output belonging to
the receiver.
We will designate these three heuristics as <code>common-input</code>,
<code>change-scriptpubkey</code>, <code>change-round-amount</code>.
The problems we aim to solve are:
* For the receiver, there is a missed opportunity to consolidate their
own UTXOs or making payment in the sender's transaction.
* For the sender, there are privacy leaks regarding their wallet that
happen when someone applies the heuristics detailed above to their
transaction.
Our proposal gives an opportunity for the receiver to consolidate
their UTXOs while also batching their own payments, without creating a
new transaction. (Saving fees in the process)
For the sender, it allows them to invalidate the three heuristics
above. With the receiver's involvement, the heuristics can even be
poisoned. (ie, using the heuristics to intentionally mislead
blockchain analysis)
Note that the existence of this proposal is also improving the privacy
of parties who are not using it by making the three heuristics
unreliable to the network as a whole.
=== Relation to BIP79 (Bustapay) ===
Another implementation proposal has been written:
[[https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki|BIP79
Bustapay]].
We decided to deviate from it for several reasons:
* It was not using PSBT, so if the receiver wanted to bump the fee,
they would need the full UTXO set.
* The receiver was responsible to pay the additional fee, not the sender.
* It was requiring at least one input to be contributed by the receiver.
* Inability to change the payment output to match scriptPubKey type.
* Lack of basic versioning negotiation if the protocol evolves.
* No standardization of error condition for proper feedback to the sender.
Other than that, our proposal is very similar.
==Specification==
===Protocol===
In a payjoin payment, the following steps happen:
* The receiver of the payment, presents a [[bip-021.mediawiki|BIP 21
URI]] to the sender with a parameter <code>pj</code> describing an
https (or http if it is a Tor hidden service) link to the payjoin
endpoint.
* The sender creates a signed, finalized PSBT with witness UTXO or
previous transactions of the inputs. We call this PSBT the
<code>original</code>.
* The receiver replies back with a signed PSBT containing his own
signed inputs/outputs and those of the sender. We call this PSBT
<code>Payjoin proposal</code>.
* The sender verifies the proposal, re-signs his inputs and broadcasts
the transaction to the Bitcoin network. We call this transaction
<code>Payjoin transaction</code>.
<pre>
+----------+ +--------+ +-----------------+
| Receiver | | Sender | | Bitcoin Network |
+----+-----+ +---+----+ +-------+---------+
| +-----------------+ | |
+-------+ BIP21 with ?pj= +------->+ |
| +-----------------+ | |
| | |
| +---------------+ | |
+<-------+ Original PSBT +---------+ |
| +---------------+ | |
| | |
| +------------------+ | |
| | Payjoin Proposal | | |
+-------+ PSBT +------>+ |
| +------------------+ | |
| | +--------------+ |
| |---+ Payjoin | |
| | | transaction +-->+
| | +--------------+ |
+ + +
</pre>
The original PSBT is sent in the HTTP POST request body, base64
serialized, with <code>text/plain</code> in the
<code>Content-Type</code> HTTP header and <code>Content-Length</code>
set correctly.
The payjoin proposal PSBT is sent in the HTTP response body, base64
serialized with HTTP code 200.
To ensure compatibility with web-wallets and browser-based-tools, all
responses (including errors) must contain the HTTP header
<code>Access-Control-Allow-Origin: *</code>.
The sender must ensure that the url refers to a scheme or protocol
using authenticated encryption, for example TLS with certificate
validation, or a .onion link to a hidden service whose public key
identifier has already been communicated via a TLS connection. Senders
MUST NOT accept a url representing an unencrypted or unauthenticated
connection.
===Receiver's well known errors===
If for some reason the receiver is unable to create a payjoin
proposal, it will reply with a HTTP code different than 200.
The receiver is not constrained to specific set of errors, some are
specified in this proposal.
The errors have the following format:
<pre>
{
"errorCode": "leaking-data",
"message": "Key path information or GlobalXPubs should not be
included in the original PSBT."
}
</pre>
The well-known error codes are:
{| class="wikitable"
!Error code
!Meaning
|-
|leaking-data
|Key path information or GlobalXPubs should not be included in the
original PSBT.
|-
|psbt-not-finalized
|The original PSBT must be finalized.
|-
|unavailable
|The payjoin endpoint is not available for now.
|-
|out-of-utxos
|The receiver does not have any UTXO to contribute in a payjoin proposal.
|-
|not-enough-money
|The receiver added some inputs but could not bump the fee of the
payjoin proposal.
|-
|insane-psbt
|Some consistency check on the PSBT failed.
|-
|version-unsupported
|This version of payjoin is not supported.
|-
|need-utxo-information
|The witness UTXO or non witness UTXO is missing
|-
|invalid-transaction
|The original transaction is invalid for payjoin
|}
The receiver is allowed to return implementation specific errors which
may assist the sender to diagnose any issue.
However, it is important that error codes that are not well-known and
that the message do not appear on the sender's software user
interface.
Such error codes or messages could be used maliciously to phish a non
technical user.
Instead those errors or messages can only appear in debug logs.
It is advised to hard code the description of the error codes into the
sender's software.
===Receiver's original PSBT checklist===
The receiver needs to do some check on the original PSBT before proceeding:
* Non-interactive receivers (like a payment processor) need to check
that the original PSBT is broadcastable. <code>*</code>
* If the sender included inputs in the original PSBT owned by the
receiver, the receiver must either return error
<code>invalid-transaction</code> or make sure they do not sign those
inputs in the payjoin proposal.
* If the sender's inputs are all from the same scriptPubKey type, the
receiver must match the same type. If the receiver can't match the
type, they must return error <code>out-of-utxos</code>.
<code>*</code>: Interactive receivers are not required to validate the
original PSBT because they are not exposed to probing attacks.
===Sender's payjoin proposal checklist===
The sender should check the payjoin proposal before signing it to
prevent a malicious receiver from stealing money.
* Check that all the spent outpoints in the original PSBT still exist
in the coinjoin PSBT.
* Check that all the spent outpoints in the original PSBT do not have
any partial signature.
* If the sender is not using inputs with mixed types, check that the
receiver inputs type match the inputs type of the sender. (ie. both
using P2SH-P2WPKH or both using P2WPKH)
* Check that any inputs added by the receiver are finalized.
* Check that the transaction version, and nLockTime are unchanged.
* Check that the sender's inputs' sequence numbers are unchanged.
* If the sender's inputs' sequence numbers the homogenous, check that
the receiver's contributed inputs match those.
* Check that the sender's outputs have not been modified (but
potentially shuffled), except for paying increased fee
* If sender specified <code>feebumpindex=</code> (see later), the fee
should have been subtracted from the output at the same index in the
original PSBT.
* Check that the sent amount in the payjoin proposal is less than or
equal to the sent amount of the original transaction.
If the sent amount in the payjoin proposal is above the amount sent in
the original PSBT
* Check that the additional paid amount has been add paid to the fee.
* Check that the estimated fee rate of the payjoin proposal is not
more than the fee rate of the original PSBT. (fee estimation is hard,
so we should allow ~2 satoshi per inputs as margin of error)
* If <code>maxfeebumpcontribution=</code> was specified, check the
additional paid amount is less than or equal to this amount.
* If <code>maxfeebumpcontribution=</code> was not specified, the
sender's software should ask an interactive confirmation to the user.
The sender must be careful to only sign the inputs that were present
in the original PSBT and nothing else.
Note:
* The sender should allow the payment output to be modified by the
receiver (The receiver may substitute a P2WPKH payment to P2SH payment
to increase privacy)
* The sender must allow the receiver to add outputs.
* The sender must allow the receiver to not add any input. Useful for
the receiver to change the paymout output scriptPubKey type.
* If no input has been added, the sender's wallet should accept the
payjoin proposal, but should not mark the transaction as an actual
payjoin in the user interface.
Our method of checking the fee allows the receiver and the sender to
batch payments in the payjoin transaction.
It also allows the receiver to pay the fee for batching adding his own outputs.
===Optional parameters===
When the payjoin sender posts the original PSBT to the receiver, he
can optionally specify the following HTTP query string parameters:
* <code>v=</code>, the version number of the payjoin protocol that the
sender is using. The current version is <code>1</code>.
This can be used in the future so the receiver can reject a payjoin if
the sender is using a version which is not supported via an error HTTP
400, <code>version-unsupported</code>.
If not specified, the receiver will assume the sender is <code>v=1</code>.
If the receiver does not support the version of the sender, they
should send an error with the list of supported versions:
<pre>
{
"errorCode": "version-unsupported",
"supported" : [ 2, 3, 4 ],
"message": "The version is not supported anymore"
}
</pre>
* <code>feebumpindex=</code>, the preferred output from which to
increase the fee for the added inputs. (default: <code>-1</code>)
If the <code>feebumpindex</code> is out of bounds or pointing to the
payment ouptut meant for the receiver, the receiver should ignore the
parameter.
* <code>maxfeebumpcontribution=</code>, an integer defining the
maximum amount in satoshis that the sender is willing to contribute
towards fees for the additional inputs.
<code>maxfeebumpcontribution</code> must be ignored if set to less
than zero. (default: -1)
Note that if <code>maxfeebumpcontribution</code> is too low, the
sender should create a transaction with RBF disabled, as the original
transaction could replace the payjoin transaction.
==Rationale==
There is several consequences of our proposal:
* The receiver can bump the fee of the original transaction.
* The receiver can modify the outputs of the original PSBT.
* The sender must provide the UTXO information (Witness or previous
transaction) in the PSBT.
===Respecting the minimum relay fee policy===
To be properly relayed, a Bitcoin transaction needs to pay at least 1
satoshi per virtual byte.
When fees are low, the original transaction is already 1 satoshi per
virtual byte, so if the receiver adds their own input, they need to
make sure the fee is increased such that the rate does not drop below
1 satoshi per virtual byte.
===Preventing mempool replacement===
A safe way to implement payjoin, is for both the sender and receiver
to try broadcasting the original transaction at some fixed interval
period regardless of the state of the payjoin.
If the receiver was not properly adding fees to the payjoin
transaction, the original transaction would end up replacing the
payjoin transaction in the mempool.
===Defeating heuristics based on the fee calculation===
Most wallets are creating a round fee rate (like 2 sat/b).
If the payjoin transaction's fee was not increased by the added size,
then those payjoin transactions could easily be identifiable on the
blockchain.
Not only would those transactions stand out by not having a round fee
(like 1.87 sat/b), but any suspicion of payjoin could be confirmed by
checking if removing one input would create a round fee rate.
===Receiver does not need to be a full node===
Because the receiver needs to bump the fee to keep the same fee rate
as the original PSBT, it needs the input's UTXO information to know
what is the original fee rate. Without PSBT, light wallets like Wasabi
Wallet would not be able to receive a payjoin transaction.
The validation (policy and consensus) of the original transaction is
optional: a receiver without a full node can decide to create the
payjoin transaction and automatically broadcast the original
transaction after a timeout of 1 minute, and only verify that it has
been propagated in the network.
However, non-interactive receivers (like a payment processor) need to
verify the transaction to prevent UTXO probing attacks.
This is not a concern for interactive receivers like Wasabi Wallet,
because those receivers can just limit the number of original PSBT
proposals of a specific address to one. With such wallets, the
attacker has no way to generate new deposit addresses to probe the
UTXOs.
===Spare change donation===
Small change inside wallets are detrimental to privacy. Mixers like
Wasabi wallet, because of its protocol, eventually generate such
[[https://docs.wasabiwallet.io/using-wasabi/ChangeCoins.html#first-round-coinjoin-change|small
change]].
A common way to protect your privacy is to donate those spare changes,
to deposit them in an exchange or on your favorite merchant's store
account. Those kind of transactions can easily be spotted on the
blockchain: There is only one output.
However, if you donate via payjoin, it will look like a normal transaction.
On top of this the receiver can poison analysis by randomly faking a
round amount of satoshi for the additional output.
===Payment output substitution===
The receiver is free to change the output paying to himself.
For example, if the sender's scriptPubKey type is P2WPKH while the
receiver's payment output in the original PSBT is P2SH, then the
receiver can substitute the payment output to be P2WPKH to match the
sender's scriptPubKey type.
===Impacted heuristics===
Our proposal of payjoin is breaking the following blockchain heuristics:
* Common inputs heuristics.
Because payjoin is mixing the inputs of the sender and receiver, this
heuristic becomes unreliable.
* Change identification from scriptPubKey type heuristics
When Alice pays Bob, if Alice is using P2SH but Bob's deposit address
is P2WPKH, the heuristic would assume that the P2SH output is the
change address of Alice.
This is now however a broken assumption, as the payjoin receiver has
the freedom to mislead analytics by purposefully changing the
invoice's address in the payjoin transaction.
Alternatively, if the original address of Bob is P2WPKH and Alice's
address is also P2WPKH, Bob can change the receiving address in the
payjoin to P2SH. The heuristic would wrongfully identify the payjoin's
receiving address as the change address of the transaction.
See payment output substitution above.
* Change identification from round change amount
If Alice pays Bob, she might be tempted to pay him a round amount,
like <code>1.23000000 BTC</code>. When this happens, blockchain
analysis often identifies the output without the round amount as the
change of the transaction.
For this reason, during a [spare
change](Payjoin-spec.md#spare-change-donation) situation, we randomly
round the amount in the output added by the receiver to the payjoin
transaction.
==Attack vectors==
===On the receiver side: UTXO probing attack===
When the receiver creates a payjoin proposal, they expose one or more
inputs belonging to them.
An attacker could create multiple original transactions in order to
learn the UTXOs of the receiver, while not broadcasting the payjoin
proposal.
While we cannot prevent this type of attack entirely, we implemented
the following mitigations:
* When the receiver detects an original transaction being broadcast,
or if the receiver detects that the original transaction has been
double spent, then they will reuse the UTXO that was exposed for the
next payjoin.
* While the exposed UTXO will be reused in priority to not leak other
UTXOs, there is no strong guarantee about it. This prevents the
attacker from detecting with certainty the next payjoin of the
merchant to another peer.
Note that probing attacks are only a problem for automated payment
systems such as BTCPay Server. End-user wallets with payjoin
capabilities are not affected, as the attacker can't create multiple
invoices to force the receiver to expose their UTXOs.
===On the sender side: Double payment risk for hardware wallets===
For a successful payjoin to happen, the sender needs to sign two
transactions double spending each other: The original transaction and
the payjoin proposal.
The sender's software wallet can verify that the payjoin proposal is
legitimate by the sender's checklist.
However, a hardware wallet can't verify that this is indeed the case.
This means that the security guarantee of the hardware wallet is
decreased. If the sender's software is compromised, the hardware
wallet would sign two valid transactions, thus sending two payments.
Without payjoin, the maximum amount of money that could be lost by a
compromised software is equal to one payment (via address
substitution).
With payjoin, the maximum amount of money that can be lost is equal to
two payments.
==Implementations==
* [[https://github.com/BlueWallet/BlueWallet|BlueWallet]] is in the
process of implementing the protocol.
* [[https://github.com/btcpayserver/btcpayserver|BTCPay Server]] has
implemented sender and receiver side of this protocol.
* [[https://github.com/zkSNACKs/WalletWasabi/|Wasabi Wallet]] has
merged sender's support.
* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join
Market]] is in the process of implementing the protocol.
* [[https://github.com/junderw/payjoin-client-js|JavaScript sender
implementation]].
==Special thanks==
Special thanks to Kukks for developing the initial support to BTCPay
Server, to junderw, AdamISZ, lukechilds, ncoelho, nopara73, yahiheb
for all the feedback we received since our first implementation.
Thanks also to RHavar who wrote the
[[https://github.com/bitcoin/bips/blob/master/bip-0079.mediawiki|BIP79
Bustapay]] proposal, this gave a good starting point for our proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200517/b8701197/attachment-0001.html>

2023-06-07 18:17:31

- reply

📅 Original date posted:2019-04-03
📝 Original message:James,
You might be interested by my work which is currently used in production,
without any change to bitcoin core.
I properly explain how to verify the utxoset independently.
https://github.com/btcpayserver/btcpayserver-docker/blob/master/contrib/FastSync/README.md
People are using it, since I get around 10 download a day.
What can be done to help at Bitcoin Core level is actually very minimal.
First, instead of asking signers of by UTXOSet to sign the utxoset hash
from gettxoutsetinfo, I ask them to sign the hash of the tarball of my UTXO
Set.
The reason is that it is currently impossible to stop BitcoinD on a
specific block then asking the serialized hash of the UTXO Set.
So instead, a verifier download the tarball (300 blocks + utxoset at
specific height), sync to the latest block, then compare the
gettxoutsetinfo of the newly synched node with another trusted node. If it
match, the verifier sign the tarball.
I create a new utxoset snapshot every 6 months, so people have time to
verify it and add their signatures. (Approximately once every bitcoin core
release)
The easiest thing that could be done at Bitcoin Core level does not require
any code change, but a change in the release process.
The new process would be to ask to the gitian signers to not only build the
source themselves, but also verify a tarball following the procedure I
explain in the link above.
More complicated solution like signing the serialized utxoset itself, while
possible, would require bothersome code changes.
Nicolas,
On Wed, Apr 3, 2019 at 9:25 AM <
bitcoin-dev-request at lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. BIP: Bitcoin Integrated Address Feature? (nathanw at tutanota.com)
> 2. Re: BIP: Bitcoin Integrated Address Feature? (htimSxelA)
> 3. assumeutxo and UTXO snapshots (James O'Beirne)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Apr 2019 18:53:11 +0200 (CEST)
> From: <nathanw at tutanota.com>
> To: <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?
> Message-ID: <LbTxyE4--3-1 at tutanota.com>
> Content-Type: text/plain; charset="utf-8"
>
> To whom it may concern,
>
> I believe a missing feature in Bitcoin is the ability to have an
> "integrated address", where the address resolves into a Bitcoin address,
> and also a transaction message or some other kind of identifier.
>
> By having this feature we could enhance the security of exchange
> cold-wallet systems, by allowing them to easily receive all payments to a
> single address from an infinite number of customers. We would also greatly
> simplify the process of setting up and managing exchange cold-wallet
> systems, because we would eliminate the "sweeping" step required to move
> multiple customer deposits from a hot address into a single cold address.
>
> Although it would be nice to have all customers deposit directly into cold
> addresses, this quickly becomes impractical when large amounts of customers
> begin to use exchange wallets as their personal web-wallet, frequently
> depositing and withdrawing without trading action. You end up needing to
> have a staff member moving funds away from cold deposit addresses as a full
> time job - if you wish to handle customer funds in a completely secure
> manner.
>
> Thus we see that most exchanges now use the hot-deposit system, where
> customers deposit into a hot address that is then automatically swept into
> a singular cold address, by a service which holds customers private keys
> online. You can observe this service at work simply by making a deposit to
> most major exchanges (including the largest exchange Binance), as you will
> see the funds quickly being "swept" to their cold wallet address in a
> manner which heavily suggests automation by a program which possesses
> private keys to the address you are sending funds to. This means there is
> always the danger of a sophisticated hacker being able to capture private
> keys to customer deposit addresses (as they are clearly being held online).
> An integrated address would allow all exchanges using this automated
> hot-deposit service to easily switch to a far more secure alternative of
> having all customers depositing directly into their singular cold wallet
> address.
>
> There are several other more minor advantages such a feature would have,
> including:
> - Lower fees for exchanges (which could be passed onto customers), by
> reducing a transaction step out of the deposit-to-withdrawal flow.
> - Less need for large rescans after loading huge amounts of customer
> addresses into client software.
> - Exchanges can more easily provision deposit addresses to new customers
> in a secure manner, by simply generating a hex or other value, creating an
> integrated address from the cold wallet address, and then providing this to
> the customer.
> - By providing a singular cold address for exchanges publicly, customers
> can more easily verify that no man-in-the-middle has given them an
> incorrect address to deposit to.
> The integrated address could work by combining the Bitcoin address
> together with some kind of hex or other value, allowing users to choose the
> amount they wish to deposit themselves, but ensuring their deposits are
> uniquely trackable.
>
> I'm not sure if some kind of functionality already exists in BTC, as I
> haven't been able to find it. If not, can I submit a proposal to implement
> this? This feature would be a godsend to all exchange developers if it was
> widely accepted.
>
> Thanks for your time.
> Regards,
>
> Nathan Worsley
> CTO - LocalCoinSwap.Com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/400c1e1b/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 02 Apr 2019 20:01:34 +0000
> From: htimSxelA <htimsxela at protonmail.com>
> To: "nathanw at tutanota.com" <nathanw at tutanota.com>, Bitcoin Protocol
> Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?
> Message-ID:
>
> <wtbAF1FAGePDAkY3xkqANuFJtAhEXvz0JeGWnc_OZcGEyFQb-1B590I3IbwtW2FBivur0yONbSQtxaWqiQTJeoDdadivtbGkWwJnLnnzQQE=@
> protonmail.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> I see two immediate issues with this:
> 1. Increased resource requirements per transaction
> 2. Embedding identifying information into the blockchain is generally bad
> for privacy
>
> It may help your case to provide some technical details of how you'd like
> to see this implemented, but without overcoming the issues mentioned above
> I think this proposal will be a very tough sell.
>
> > ...this quickly becomes impractical when large amounts of customers
> begin to use exchange wallets as their personal web-wallet, frequently
> depositing and withdrawing without trading action. You end up needing to
> have a staff member moving funds away from cold deposit addresses as a full
> time job - if you wish to handle customer funds in a completely secure
> manner.
>
> I am not sure if I see how this issue is solved by your proposal.
> Assumedly, a human will still need to manually approve cold-wallet
> withdrawals in order to maintain security. So it seems to me that removing
> the 'hot-wallet' component of the backend would only amplify the need for
> human interaction.
>
> I assume you are familiar with hierarchical deterministic wallets? They
> can allow an exchange to assign/identify user deposits based on address
> derivation path. Keys for deposit addresses can be kept offline if wanted,
> and a proper implementation of an HD wallet system should also remove the
> need for rescans of user deposit addresses.
>
> There is also a functionality built into Bitcoin that allows a user to
> prove that they own the private keys to some address: signing an agreed
> upon message using the private key that controls that address.
> Unfortunately I don't think this is a workable solution for you, since the
> majority of modern wallet software does not include this feature-- but
> perhaps worth mentioning nonetheless.
>
> Best,
> Alex
>
> ??????? Original Message ???????
> On Tuesday, April 2, 2019 9:53 AM, Nathan Worsley via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > To whom it may concern,
> >
> > I believe a missing feature in Bitcoin is the ability to have an
> "integrated address", where the address resolves into a Bitcoin address,
> and also a transaction message or some other kind of identifier.
> >
> > By having this feature we could enhance the security of exchange
> cold-wallet systems, by allowing them to easily receive all payments to a
> single address from an infinite number of customers. We would also greatly
> simplify the process of setting up and managing exchange cold-wallet
> systems, because we would eliminate the "sweeping" step required to move
> multiple customer deposits from a hot address into a single cold address.
> >
> > Although it would be nice to have all customers deposit directly into
> cold addresses, this quickly becomes impractical when large amounts of
> customers begin to use exchange wallets as their personal web-wallet,
> frequently depositing and withdrawing without trading action. You end up
> needing to have a staff member moving funds away from cold deposit
> addresses as a full time job - if you wish to handle customer funds in a
> completely secure manner.
> >
> > Thus we see that most exchanges now use the hot-deposit system, where
> customers deposit into a hot address that is then automatically swept into
> a singular cold address, by a service which holds customers private keys
> online. You can observe this service at work simply by making a deposit to
> most major exchanges (including the largest exchange Binance), as you will
> see the funds quickly being "swept" to their cold wallet address in a
> manner which heavily suggests automation by a program which possesses
> private keys to the address you are sending funds to. This means there is
> always the danger of a sophisticated hacker being able to capture private
> keys to customer deposit addresses (as they are clearly being held online).
> An integrated address would allow all exchanges using this automated
> hot-deposit service to easily switch to a far more secure alternative of
> having all customers depositing directly into their singular cold wallet
> address.
> >
> > There are several other more minor advantages such a feature would have,
> including:
> > - Lower fees for exchanges (which could be passed onto customers), by
> reducing a transaction step out of the deposit-to-withdrawal flow.
> > - Less need for large rescans after loading huge amounts of customer
> addresses into client software.
> > - Exchanges can more easily provision deposit addresses to new customers
> in a secure manner, by simply generating a hex or other value, creating an
> integrated address from the cold wallet address, and then providing this to
> the customer.
> > - By providing a singular cold address for exchanges publicly, customers
> can more easily verify that no man-in-the-middle has given them an
> incorrect address to deposit to.
> >
> > The integrated address could work by combining the Bitcoin address
> together with some kind of hex or other value, allowing users to choose the
> amount they wish to deposit themselves, but ensuring their deposits are
> uniquely trackable.
> >
> > I'm not sure if some kind of functionality already exists in BTC, as I
> haven't been able to find it. If not, can I submit a proposal to implement
> this? This feature would be a godsend to all exchange developers if it was
> widely accepted.
> >
> > Thanks for your time.
> >
> > Regards,
> >
> > Nathan Worsley
> > CTO - LocalCoinSwap.Com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/ade34235/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Apr 2019 16:43:11 -0400
> From: "James O'Beirne" <james.obeirne at gmail.com>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] assumeutxo and UTXO snapshots
> Message-ID:
> <CAPfvXf+JS6ZhXUieWVxiaNa4uhhWwafCk3odMKy5F_yi=
> XwngA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I'd like to discuss assumeutxo, which is an appealing and simple
> optimization in the spirit of assumevalid[0].
>
> # Motivation
>
> To start a fully validating bitcoin client from scratch, that client
> currently
> needs to perform an initial block download. To the surprise of no one, IBD
> takes a linear amount time based on the length of the chain's history. For
> clients running on modest hardware under limited bandwidth constraints,
> say a mobile device, completing IBD takes a considerable amount of time
> and thus poses serious usability challenges.
>
> As a result, having fully validating clients run on such hardware is rare
> and
> basically unrealistic. Clients with even moderate resource constraints
> are encouraged to rely on the SPV trust model. Though we have promising
> improvements to existing SPV modes pending deployment[1], it's worth
> thinking about a mechanism that would allow such clients to use trust
> models closer to full validation.
>
> The subject of this mail is a proposal for a complementary alternative to
> SPV
> modes, and which is in the spirit of an existing default, `assumevalid`. It
> may
> help modest clients transact under a security model that closely resembles
> full validation within minutes instead of hours or days.
>
> # assumeutxo
>
> The basic idea is to allow nodes to initialize using a serialized version
> of the
> UTXO set rendered by another node at some predetermined height. The
> initializing node syncs the headers chain from the network, then obtains
> and
> loads one of these UTXO snapshots (i.e. a serialized version of the UTXO
> set
> bundled with the block header indicating its "base" and some other
> metadata).
>
> Based upon the snapshot, the node is able to quickly reconstruct its
> chainstate,
> and compares a hash of the resulting UTXO set to a preordained hash
> hard-coded
> in the software a la assumevalid. This all takes ~23 minutes, not
> accounting for
> download of the 3.2GB snapshot[2].
>
> The node then syncs to the network tip and afterwards begins a simultaneous
> background validation (i.e., a conventional IBD) up to the base height of
> the
> snapshot in order to achieve full validation. Crucially, even while the
> background validation is happening the node can validate incoming blocks
> and
> transact with the benefit of the full (assumed-valid) UTXO set.
>
> Snapshots could be obtained from multiple separate peers in the same manner
> as
> block download, but I haven't put much thought into this. In concept it
> doesn't
> matter too much where the snapshots come from since their validity is
> determined via content hash.
>
> # Security
>
> Obviously there are some security implications due consideration. While
> this
> proposal is in the spirit of assumevalid, practical attacks may become
> easier.
> Under assumevalid, a user can be tricked into transacting under a false
> history
> if an attacker convinces them to start bitcoind with a malicious
> `-assumevalid`
> parameter, sybils their node, and then feeds them a bogus chain
> encompassing
> all of the hard-coded checkpoints[3].
>
> The same attack is made easier in assumeutxo because, unlike in
> assumevalid,
> the attacker need not construct a valid PoW chain to get the victim's node
> into
> a false state; they simply need to get the user to accept a bad
> `-assumeutxo`
> parameter and then supply them an easily made UTXO snapshot containing,
> say, a
> false coin assignment.
>
> For this reason, I recommend that if we were to implement assumeutxo, we
> not
> allow its specification via commandline argument[4].
>
> Beyond this risk, I can't think of material differences in security
> relative to
> assumevalid, though I appeal to the list for help with this.
>
> # More fully validating clients
>
> A particularly exciting use-case for assumeutxo is the possibility of
> mobile
> devices functioning as fully validating nodes with access to the complete
> UTXO
> set (as an alternative to SPV models). The total resource burden needed to
> start a node
> from scratch based on a snapshot is, at time of writing, a ~(3.2GB
> + blocks_to_tip * 4MB) download and a few minutes of processing time, which
> sounds
> manageable for many mobile devices currently in use.
>
> A mobile user could initialize an assumed-valid bitcoin node within an
> hour,
> transact immediately, and complete a pruned full validation of their
> assumed-valid chain over the next few days, perhaps only doing the
> background
> IBD when their device has access to suitable high-bandwidth connections.
>
> If we end up implementing an accumulator-based UTXO scaling design[5][6]
> down
> the road, it's easy to imagine an analogous process that would allow very
> fast
> startup using an accumulator of a few kilobytes in lieu of a multi-GB
> snapshot.
>
> ---
>
> I've created a related issue at our Github repository here:
> https://github.com/bitcoin/bitcoin/issues/15605
>
> and have submitted a draft implementation of snapshot usage via RPC here:
> https://github.com/bitcoin/bitcoin/pull/15606
>
> I'd like to discuss here whether this is a good fit for Bitcoin
> conceptually. Concrete
> plans for deployment steps should be discussed in the Github issue, and
> after all
> that my implementation may be reviewed as a sketch of the specific software
> changes necessary.
>
> Regards,
> James
>
>
> [0]:
> https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
> [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
> [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @
> 2.10GHz
> [3]:
>
> https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161
> [4]: Marco Falke is due credit for this point
> [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
> [6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/46b25dd8/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 47, Issue 6
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/7a1cb47c/attachment-0001.html>

2023-06-07 18:08:56

- reply

📅 Original date posted:2017-12-21
📝 Original message:Thanks a lot for the feedback
> I think this could be quite useful, although I don’t know if it will get
adopted.
The good part is that it does not have to be adopted by exchanges. If
popular exchanges do not adopt it, it is trivial to make an adapter service
which translate COX to whatever proprietary API of the exchange.
Collaboration with the exchange is only needed if the exchange wants to
provide a service for taking the risk of volatility.
> I have personally been integrating BitPay into a website for payments in
BTC and like what you are trying to do. One of the biggest hurdle’s I see
for merchants to adopt BitCoin today is the transaction fee.
This BIP supports alternatives currencies.
> Can you refer to the kind of best practices Stripe and PayPal recommend?
Should some additional shared-secret or cookie / macaroon based
authentication be added?
Yes, I must add guidelines (SSL and how to manage the addresses). I don't
think authentication is needed as the merchant is the only one having
access to the source URI. This can be considered as a shared secret.
Even if this secret leaks, no funds are in danger.
> Can you clarify if this integration can run in a browser, or due to
security / privacy constraints must be server-to-server?
Thanks, I need to clarify the scope. But indeed, this is not meant to be
used by a browser, as merchants will not host their payment processors on
their mobile or browser.
> Though it’s important to remain future-proof by being flexible, leaving
the above details to individual implementers is probably going to result in
bad things.
Thanks, I think you are right I should add more recommendations for
implementers.
> What are your thoughts on rate limiting vs. privacy? Should a payment
source never return the same address even if nothing is paid to it?
Otherwise someone could just crawl webshops to create an inventory of
payment addresses. A new address every page reload could be a DDOS vector.
It also wouldn't be compatible with BIP44 because of its gap limit,
although I don’t think that’s a huge problem for exchanges.
You are right, I must introduce a sort of "order id" so that one order map
to exactly one address response.
The DDOS vector will then be on the shoulder of the ecommerce website by
preventing users to create too much orders. (they certainly already do)
> Can this be combined with an invoice mechanism similar to Lightning, e.g.
where the exchange sends a pre-image to the users wallet (relayed via and
retained by the web shop) upon receipt of the funds, which they can then
present to the merchant in case something went wrong. Exchanges might be
happy to support this protocol, but they don’t want the burden of dealing
with user support requests, so having signed invoices could help with that.
This protocol can be expanded later for lightning trivially, where the call
to the address source uri also returns a lightning payment request. (BOLT11)
> Speaking of Bisq, it would be neat if merchants can rely on random peer
to peer counterparties to convert to fiat, so their customer information
and revenue figures aren’t in the hands of a single counter party.
Obviously that’s a can of worms today, but it would be nice if the protocol
was able to support that if one day someone figures out the fraud,
compliance and bookkeeping stuff.
Conversion to fiat always need trust, so we must rule out anonymous
parties. If you want to spread on several trusted party, this can be done
transparently at the payment processor level, and does not requires change
to the protocol.
> Finally, why only exchanges? It could make sense fo shopping cart
software to talk to a Bitcoin wallet that’s hosted somewhere else for
similar reasons. Right now the best these plugins can do is hold on to an
XPUB, and I’ve even seen solutions that just send the customers coins to
their own backend wallet and then forward it.
Because BIP70/XPUB already solves the problem. (Which I already use in
BTCPay)
BIP70 is a pain in the ass to implement and does not provide any benefits,
and it does not define a way for the exchange to communicate a rate
attached to the bitcoin address, nor define a way to communicate to the
payment processor the conditions under which they can bear volatility risk.
I will revisit the BIP based on your feedback.
Nicolas,
On Wed, Dec 20, 2017 at 5:49 PM, Sjors Provoost <sjors at sprovoost.nl> wrote:
>
>
> I think this could be quite useful, although I don’t know if it will get
> adopted. If any such small local exchanges want to weigh in on this
> proposal, that would help. Same goes for shopping cart integrators, e.g.
> the folks writing WooCommerce and Shopify plugins.
>
> Consider adding some requirements around the use of SSL and certificate
> pinning. Can you refer to the kind of best practices Stripe and PayPal
> recommend? Should some additional shared-secret or cookie / macaroon based
> authentication be added?
>
> Can you clarify if this integration can run in a browser, or due to
> security / privacy constraints must be server-to-server?
>
> Though it’s important to remain future-proof by being flexible, leaving
> the above details to individual implementers is probably going to result in
> bad things.
>
> What are your thoughts on rate limiting vs. privacy? Should a payment
> source never return the same address even if nothing is paid to it?
> Otherwise someone could just crawl webshops to create an inventory of
> payment addresses. A new address every page reload could be a DDOS vector.
> It also wouldn't be compatible with BIP44 because of its gap limit,
> although I don’t think that’s a huge problem for exchanges.
>
> Can this be combined with an invoice mechanism similar to Lightning, e.g.
> where the exchange sends a pre-image to the users wallet (relayed via and
> retained by the web shop) upon receipt of the funds, which they can then
> present to the merchant in case something went wrong. Exchanges might be
> happy to support this protocol, but they don’t want the burden of dealing
> with user support requests, so having signed invoices could help with that.
>
> I would consider a more specific name like Delegated UTXO or something.
> “Exchange” suggests is more like 0X or Bisq.
>
> Speaking of Bisq, it would be neat if merchants can rely on random peer to
> peer counterparties to convert to fiat, so their customer information and
> revenue figures aren’t in the hands of a single counter party. Obviously
> that’s a can of worms today, but it would be nice if the protocol was able
> to support that if one day someone figures out the fraud, compliance and
> bookkeeping stuff.
>
> Finally, why only exchanges? It could make sense fo shopping cart software
> to talk to a Bitcoin wallet that’s hosted somewhere else for similar
> reasons. Right now the best these plugins can do is hold on to an XPUB, and
> I’ve even seen solutions that just send the customers coins to their own
> backend wallet and then forward it.
>
> Sjors
>
> Op 20 dec. 2017, om 07:28 heeft Nicolas Dorier via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> Hi everyone,
>
> As some of you know, I am working on a complete open source replacement of
> Bitpay for allowing merchant to accept cryptocurrency payments while having
> a way to sell automatically.
>
> A crucial, missing part, is fiat conversion. And I figured out a simple
> protocol that exchanges (or adapters) can implement to allow any merchant
> to cash out BTC in fiat while giving them the freedom to choose their own
> payment processor solution.
>
> This also have positive impact on scalability: Before, a merchant would
> receive the bitcoin from the customer then would send to the exchange,
> resulting in two transactions.
> With this specification, it would be one transaction.
>
> Special thanks to anditto and kallewoof for reviewing. I am waiting for
> your feedback:
>
> Github link: https://github.com/NicolasDorier/bips/blob/
> master/bip-xxx.mediawiki
>
> <pre>
> BIP: XXX
> Layer: Applications
> Title: Crypto Open Exchange Protocol (COX)
> Author: Nicolas Dorier <nicolas.dorier at gmail.com>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
> Status: Draft
> Type: Standards Track
> Created: 2017-12-20
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> A simple protocol for decoupling payment processor solutions from
> exchanges.
>
> ==Motivation==
>
> Cryptocurrency merchant adoption is mainly driven by availability, ease of
> use and means of acceptance.
> We call such solutions `Payment Processors`.
>
> Until now, payment processing solutions fall into one of the two following
> categories:
>
> # Self-hosted with the customer paying in cryptocurrency and the merchant
> receiving it directly.
> # Centralized, coupled with an exchange feature, with the customer paying
> in cryptocurrency to the merchant, and receiving fiat or cryptocurrency on
> his exchange account.
>
> The self-hosted solution has two issues:
>
> # The merchant becomes vulnerable to the wild volatility of
> cryptocurrencies.
> # It is wasteful of blockchain space, if the merchant does not pay
> suppliers in crypto, as they need a second transaction to change to his
> exchange,
>
> The centralized solution has two issues:
>
> # It locks-in the merchant to a particular payment processor whose
> intentions might not be aligned (e.g. Bitpay who tried to redefine Bitcoin
> as being a different chain, without merchant approval)
> # It has to deal with local regulations (e.g. Bitpay does not provide fiat
> CAD to canadian merchants)
>
> The goal of this BIP is to specify a simple protocol which makes possible
> decoupling of payment processors from exchanges.
>
> We believe this BIP will gather a lot of interest among local exchanges
> which do not have the resources to develop their own payment solutions.
>
> Their customers can decide which payment processor solution they prefer,
> while the exchanges give them a way to protect against cryptocurrency
> volatility.
>
> ==Summary==
>
> The merchant log in to its exchange website, go into "Address sources"
> section of it, an click on "Create a new address source".
>
> The address source creation wizard asks him questions about what to do
> when crypto currency is sent to this the address source. (Cryptocurrency,
> Market sell order, limit order of past day average etc...)
>
> The merchant receives an "address source URI" which they can input inside
> the payment processor.
>
> An exchange compatible with the Crypto Open Exchange Protocol would reply
> to any HTTP POST request to this "address source URI" returning the
> following information (more details in the Specification part)
>
> # A deposit address for accepting a payment
> # The current rate
> # Optional: If the exchange is willing to take the risk of rate
> fluctuation, until when this rate is guaranteed and under which conditions.
>
> <img src="bip-xxx/overview.png"></img>
>
> ===Interaction===
>
> * Manny (the "merchant") wants to accept Bitcoin payments on his
> e-commerce website.
> * Manny chooses the payment processor "PROCCO" which has a powerful plugin
> for his e-commerce website.
> * Manny is based in Canada and already has an account on the exchange
> "MYCOIN" which supports the Crypto Open Exchange Protocol.
> * Manny connects to the exchange website, and creates a new address source.
> * In the configuration screen of the address source, for each payment sent
> to this address source, Manny decides to keep 30% in Bitcoin and place a
> market sell order for the remaining 70% of the amount.
> * "MYCOIN" creates the address source, and gives the "address source URI"
> to the merchant. (e.g. https://example.com/addresssources/abd29ddn92)
> * Manny copies the address source URI and goes inside "PROCCO" settings,
> and configures his store to use this address source URI.
>
> Now a customer, Carol, wants to order a brand new phone for 0.01 BTC on
> Manny's store and decides to pay in Bitcoin.
>
> * The E-Commerce website plugin requests the creation of an invoice from
> PROCCO.
> * PROCCO queries the "address source URI" and retrieves the rate, the
> expiration of this rate and conditions.
> * PROCCO can now show the Bitcoin Payment Checkout page.
> * Carla pays.
> * PROCCO marks the payment as paid and redirects to the e-commerce website.
> * MYCOIN, under its own policy (typically after 6 confirmations), credits
> Manny's account of 0.01 BTC and simultaneously creates a market sell order
> of 0.007 BTC on behalf of Manny.
>
> ==Specification==
>
> The payment processor sends a POST request to the "address source URI",
> the response from a Crypto Open Exchange Protocol exchange would be:
>
> If the exchange does not guarantee the rate:
>
> {
> "depositAddress" : "13....abd",
> "currencyCode" : "CAD",
> "cryptoCurrencyCode" : "BTC",
> "rate" : "15600",
> # When the merchant account get credited on the exchange
> "requiredConfirmations" : blockcount
> }
>
>
> If the exchange guarantee the rate:
>
> {
> "depositAddress" : "13....abd",
> "currencyCode" : "CAD",
> "cryptoCurrencyCode" : "BTC",
> "rate" : "15600",
> "requiredConfirmations" : blockcount
> "conditions" :
> {
> # When the transaction should be seen on the blockchain to
> guarantee the rate
> "receivedBefore" : timestamp,
> # When the transaction should be confirmed on the blockchain
> to guarantee the rate
> "confirmedBefore" : timestamp
> }
> }
>
>
> The payment processor is responsible for giving feedback to the customer
> if the fees of the received transaction are not enough to guarantee the
> rate.
>
> ==Note on adoption==
>
> While local exchanges have incentives to implement this simple protocol,
> it is not strictly needed.
>
> An alternative is to develop an adapter server which expose Crypto Open
> Exchange Protocol endpoint and connect to underlying exchange's API.
>
> The only downside is that the rate can't be guaranteed.
>
> ==Copyright==
>
> This document is dual licensed as BSD 3-clause, and Creative Commons CC0
> 1.0 Universal.
>
>
> Nicolas,
> _______________________________________________
> 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/20171221/d6e0ce81/attachment-0001.html>

2023-06-07 18:08:55

- reply

📅 Original date posted:2017-12-20
📝 Original message:Hi everyone,
As some of you know, I am working on a complete open source replacement of
Bitpay for allowing merchant to accept cryptocurrency payments while having
a way to sell automatically.
A crucial, missing part, is fiat conversion. And I figured out a simple
protocol that exchanges (or adapters) can implement to allow any merchant
to cash out BTC in fiat while giving them the freedom to choose their own
payment processor solution.
This also have positive impact on scalability: Before, a merchant would
receive the bitcoin from the customer then would send to the exchange,
resulting in two transactions.
With this specification, it would be one transaction.
Special thanks to anditto and kallewoof for reviewing. I am waiting for
your feedback:
Github link:
https://github.com/NicolasDorier/bips/blob/master/bip-xxx.mediawiki
<pre>
BIP: XXX
Layer: Applications
Title: Crypto Open Exchange Protocol (COX)
Author: Nicolas Dorier <nicolas.dorier at gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
Status: Draft
Type: Standards Track
Created: 2017-12-20
License: BSD-3-Clause
CC0-1.0
</pre>
==Abstract==
A simple protocol for decoupling payment processor solutions from exchanges.
==Motivation==
Cryptocurrency merchant adoption is mainly driven by availability, ease of
use and means of acceptance.
We call such solutions `Payment Processors`.
Until now, payment processing solutions fall into one of the two following
categories:
# Self-hosted with the customer paying in cryptocurrency and the merchant
receiving it directly.
# Centralized, coupled with an exchange feature, with the customer paying
in cryptocurrency to the merchant, and receiving fiat or cryptocurrency on
his exchange account.
The self-hosted solution has two issues:
# The merchant becomes vulnerable to the wild volatility of
cryptocurrencies.
# It is wasteful of blockchain space, if the merchant does not pay
suppliers in crypto, as they need a second transaction to change to his
exchange,
The centralized solution has two issues:
# It locks-in the merchant to a particular payment processor whose
intentions might not be aligned (e.g. Bitpay who tried to redefine Bitcoin
as being a different chain, without merchant approval)
# It has to deal with local regulations (e.g. Bitpay does not provide fiat
CAD to canadian merchants)
The goal of this BIP is to specify a simple protocol which makes possible
decoupling of payment processors from exchanges.
We believe this BIP will gather a lot of interest among local exchanges
which do not have the resources to develop their own payment solutions.
Their customers can decide which payment processor solution they prefer,
while the exchanges give them a way to protect against cryptocurrency
volatility.
==Summary==
The merchant log in to its exchange website, go into "Address sources"
section of it, an click on "Create a new address source".
The address source creation wizard asks him questions about what to do when
crypto currency is sent to this the address source. (Cryptocurrency, Market
sell order, limit order of past day average etc...)
The merchant receives an "address source URI" which they can input inside
the payment processor.
An exchange compatible with the Crypto Open Exchange Protocol would reply
to any HTTP POST request to this "address source URI" returning the
following information (more details in the Specification part)
# A deposit address for accepting a payment
# The current rate
# Optional: If the exchange is willing to take the risk of rate
fluctuation, until when this rate is guaranteed and under which conditions.
<img src="bip-xxx/overview.png"></img>
===Interaction===
* Manny (the "merchant") wants to accept Bitcoin payments on his e-commerce
website.
* Manny chooses the payment processor "PROCCO" which has a powerful plugin
for his e-commerce website.
* Manny is based in Canada and already has an account on the exchange
"MYCOIN" which supports the Crypto Open Exchange Protocol.
* Manny connects to the exchange website, and creates a new address source.
* In the configuration screen of the address source, for each payment sent
to this address source, Manny decides to keep 30% in Bitcoin and place a
market sell order for the remaining 70% of the amount.
* "MYCOIN" creates the address source, and gives the "address source URI"
to the merchant. (e.g. https://example.com/addresssources/abd29ddn92)
* Manny copies the address source URI and goes inside "PROCCO" settings,
and configures his store to use this address source URI.
Now a customer, Carol, wants to order a brand new phone for 0.01 BTC on
Manny's store and decides to pay in Bitcoin.
* The E-Commerce website plugin requests the creation of an invoice from
PROCCO.
* PROCCO queries the "address source URI" and retrieves the rate, the
expiration of this rate and conditions.
* PROCCO can now show the Bitcoin Payment Checkout page.
* Carla pays.
* PROCCO marks the payment as paid and redirects to the e-commerce website.
* MYCOIN, under its own policy (typically after 6 confirmations), credits
Manny's account of 0.01 BTC and simultaneously creates a market sell order
of 0.007 BTC on behalf of Manny.
==Specification==
The payment processor sends a POST request to the "address source URI", the
response from a Crypto Open Exchange Protocol exchange would be:
If the exchange does not guarantee the rate:
{
"depositAddress" : "13....abd",
"currencyCode" : "CAD",
"cryptoCurrencyCode" : "BTC",
"rate" : "15600",
# When the merchant account get credited on the exchange
"requiredConfirmations" : blockcount
}
If the exchange guarantee the rate:
{
"depositAddress" : "13....abd",
"currencyCode" : "CAD",
"cryptoCurrencyCode" : "BTC",
"rate" : "15600",
"requiredConfirmations" : blockcount
"conditions" :
{
# When the transaction should be seen on the blockchain to
guarantee the rate
"receivedBefore" : timestamp,
# When the transaction should be confirmed on the blockchain to
guarantee the rate
"confirmedBefore" : timestamp
}
}
The payment processor is responsible for giving feedback to the customer if
the fees of the received transaction are not enough to guarantee the rate.
==Note on adoption==
While local exchanges have incentives to implement this simple protocol, it
is not strictly needed.
An alternative is to develop an adapter server which expose Crypto Open
Exchange Protocol endpoint and connect to underlying exchange's API.
The only downside is that the rate can't be guaranteed.
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0
1.0 Universal.
Nicolas,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171220/d0b0422b/attachment-0001.html>

2023-06-07 17:52:08

- reply

📅 Original date posted:2016-08-12
📝 Original message:I think that regardless of merits protocol or limitations of protocols,
once they become used and stable they merit their place as a BIP.
I'd like to submit OA as is on flavien's repository, and update or reword
things once it is there. (so he can ACK easily and we can keep track of
changes instead of using mails back and forth)
It would be useful to have other colored coin protocols as well. (EPOBC and
Colu)
On Thu, Aug 4, 2016 at 9:37 PM, Flavien Charlon <
flavien.charlon at coinprism.com> wrote:
> Hi,
>
> > I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>
> Alex summarizes the situation well. Efforts to come up with a
> "multiple-colored-coin-protocol" have failed since the different
> protocols take different assumptions and different tradeoffs and are built
> for different use cases. In the end, we ended up exactly in the same
> situation as the well known XKCD comic strip about standards (
> https://xkcd.com/927/).
>
> > You can, however, provide a new OA2.0 protocol that improves upon these
> issues, and assure that upgraded wallets maintain support for both versions.
>
> I don't think there is a point in doing that. This would just result in
> having yet another "standard", which nobody uses. Open Assets 1.0 took 3
> years to get where it is today, and is used by many companies across the
> industry. It has well over 20 different implementations, some open source,
> some proprietary.
>
> The goal of this process is to have OA 1.0 becoming the BIP since this is
> the one people are using.
>
> > I was waiting for clarification on the Author thing, but Nicholas hasn't
> responded yet. I am unaware of any reason NOT to assign it, and there
> appear to be no objections, so let's call it BIP 160.
>
> Nicolas is proposing the BIP on my behalf. I'll ACK as needed but he can
> drive the discussions.
>
> Best,
> Flavien
>
> On Tue, Aug 2, 2016 at 6:25 PM, Alex Mizrahi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
>>> written by reps from all of the major protocols and that meta-merges the
>>> features of these implementations
>>>
>>
>> We actually tried to do that in 2014-2015, but that effort have failed...
>> Nobody was really interested in collaboration, each company only cared
>> about it's own product.
>> Especially Colu, they asked everyone for requirements, and then developed
>> a new protocol completely on their own without taking anyone's input.
>>
>> I'm not sure that merging the protocols makes sense, as some protocols
>> value simplicity, and a combined protocol cannot have this feature.
>>
>> I don't think there is much interest in a merged colored coin protocol
>> now.
>> Colu is moving away from colored coins, as far as I can tell.
>> CoinSpark is now doing MultiChain closed-source private blockchain.
>> CoinPrism also seems to be largely disinterested in colored coins.
>>
>> We (ChromaWay) won't mind replacing EPOBC with something better, our
>> software could always support multiple different kernels so adding a new
>> protocol isn't a big deal for us.
>>
>> So if somebody is interested in a new protocol please ping me.
>>
>> One of ideas I have is to decouple input-output mapping/multiplexing from
>> coloring.
>> So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into
>> outputs 0, 1 and 2".
>> In this case it will be possible to create more advanced protocols (e.g.
>> with support for 'smart contracts' and whatnot) while also keeping them
>> compatible with old ones to some extent, e.g. a wallet can safely engage in
>> p2ptrade or CoinJoin transactions without understanding all protocols used
>> in a transaction.
>>
>>
>>> - in collaboration with feedback from core developers that understand
>>> the direction the protocol will be taking and the issues to avoid.
>>>
>>
>> Core developers generally dislike things like colored coins, so I doubt
>> they are going to help.
>>
>> Blockstream is developing a sidechain with user-defined assets, so I
>> guess they see it as the preferred way of doing things:
>> https://elementsproject.org/elements/asset-issuance/
>>
>>
>>> As it stands, investors have to install multiple wallets to deal with
>>> these varying implementations.
>>>
>>
>> Actually this can be solved without making a new "merged protocol": one
>> can just implement a wallet which supports multiple protocols.
>>
>>
>>
>> _______________________________________________
>> 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/20160813/41706ad9/attachment.html>

2023-06-07 17:52:07

- reply

📅 Original date posted:2016-08-02
📝 Original message:Sorry, I completely forgot about having submitted the BIP as I was busy at
this time.
Thanks for the review.
Open Asset is actually not an abandoned project and is a protocol already
used in production with multiple implementation.
Wallet: https://www.coinprism.com/
Implementation C#: https://github.com/NicolasDorier/NBitcoin with heavy
documentation (
https://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_asset/colored_coins.html
)
Implementation Ruby: https://github.com/haw-itn/openassets-ruby/
Usage stats: http://opreturn.org/
Concerning whether or not we can put my name in the BIP, I'll ask the
original author that I know personally.
> Quite a bit ugly, giving a meaning to an input's pubkey script like that.
> But more problematically: how can this work with other pubkey scripts?
> Particularly relevant now that this old script format is being deprecated.
> Another possible problem is that I don't see a way to provably guarantee
an
> asset issuance is final.
Yes, with open asset it is not possible to do provably limited issuance.
The scriptPubKey can be anything, not necessarily P2PK.
If you can spend the scriptPubkey, then you are the issuer.
> And the assets attached to its inputs are destroyed? Or?
Correct, if you spend a colored output incorrectly, it is effectively
destroyed.
> Is it intentional that the first case is "parsable", and the second
"valid"?
> I think these need to be better specified; for example, it is not so
clear how
> to reach if the OAP version number is something other than 1: is that
> parsable? valid?
The terminology is correct we are parsing PUSHDATA, if there is a parsable
pushdata, the output is considered valid.
If there is multiple valid output, then we take the first one.
> What determines the asset id? How would one issue and/or transfer multiple
> asset ids in the same transaction?
You can't issue more than one asset type in a transaction. (as the asset
issued is defined by the scriptPubKey of the first input)
For multiple transfer it is possible, imagine a transaction with the
following 3 inputs and 6 outputs:
Inputs: {0, 10a, 20b}
Outputs: {5, OP_RETURN; 7; 3; 11; 9)
Inputs1: 0
Inputs2: Enqueue 10a in the queue ( {10a} )
Input3: Enqueue 20b in the queue ( { 20b, 10a} )
Output1: Before OP_RETURN, so is issuance whose color is defined by the
scriptPubKey of Input1. (say c)
Output2: No color (marker)
Output3: Dequeue 7a ( {20b, 3a} ), color output with a.
Output4: Dequeue 3a ( {20b} ), color output with a
Output5: Dequeue 11b ( {9b} ), color output with b
Output5: Dequeue 9b ( {0} ), color output with b
Finally, outputs color are
Outputs: {5c, OP_RETURN; 7a; 3a; 11b; 9b)
> What if I have a transaction with 5 outputs, the marker output at
position 3,
> and all 4 other outputs are to receive assets? Does the marker output get
> skipped in the list (ie, the list is 4 elements long) or must it be set to
> zero quantity (ie, the list is 5 elements long)?
Marker output is skipped (explained in the example)
> Addresses are not used for spending bitcoins, only for receiving them.
The way
> this BIP uses inputs' pubkey script is extremely unusual and probably a
bad
> idea.
Actually there is no "issuance address", just the AssetId is defined by the
scriptPubKey of the issuer.
> As I understand it, this would require address reuse to setup, which is
not
> supported behaviour and insecure.
Yes, it requires address reuse for issuing.
> Won't an older client then accidentally destroy assets?
Correct. Actually we prevent users sending asset to wallet which does not
support OA via another address scheme described in another document (
https://github.com/OpenAssets/open-assets-protocol/blob/master/address-format.mediawiki
)
As said, Open Asset is not a draft proposal and is already used in the wild
since 2014. We can't easily modify the protocol by now for improving it.
PS:
https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki
is
more readable than a mail.
Nicolas,
On Tue, Jul 5, 2016 at 7:14 PM, James MacWhyte <macwhyte at gmail.com> wrote:
> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of, but there's no reason it
> can't get a number as a work-in-progress.
>
> I hope it does continue to get worked on, though. The lack of response or
> discussion worries me that it might become an abandoned project.
>
> On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
>> > On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev
>> wrote:
>> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
>> wrote:
>> > > > Author: Flavien Charlon <flavien at charlon.net>
>> >
>> > What's the status of this BIP? Will it be assigned?
>>
>> I was waiting for clarification on the Author thing, but Nicholas hasn't
>> responded yet. I am unaware of any reason NOT to assign it, and there
>> appear
>> to be no objections, so let's call it BIP 160.
>>
>> Luke
>> _______________________________________________
>> 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/20160801/7028265d/attachment.html>

2023-06-07 17:50:57

- reply

📅 Original date posted:2016-05-25
📝 Original message:Open Asset is a simple and well known colored coin protocol made by Flavien
Charlon, which has been around for more than two years ago.
Open Asset is OP_RETURN to store coin's color. Since then, the only
modification to the protocol has been for allowing OA data to be into any
push into an OP_RETURN.
The protocol is here:
https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki
I asked to Flavien Charlon if he was OK if I submit the protocol to the
mailing list before posting.
Additional BIP number might be required to cover for example the "colored
address" format:
https://github.com/OpenAssets/open-assets-protocol/blob/master/address-format.mediawiki
But I will do it in a separate request.
Here is the core of the Open Asset specification:
<pre>
Title: Open Assets Protocol (OAP/1.0)
Author: Flavien Charlon <flavien at charlon.net>
Created: 2013-12-12
</pre>
==Abstract==
This document describes a protocol used for storing and transferring
custom, non-native assets on the Blockchain. Assets are represented by
tokens called colored coins.
An issuer would first issue colored coins and associate them with a
formal or informal promise that he will redeem the coins according to
terms he has defined. Colored coins can then be transferred using
transactions that preserve the quantity of every asset.
==Motivation==
In the current Bitcoin implementation, outputs represent a quantity of
Bitcoin, secured by an output script. With the Open Assets Protocol,
outputs can encapsulate a quantity of a user-defined asset on top of
that Bitcoin amount.
There are many applications:
* A company could issue colored coins representing shares. The shares
could then be traded frictionlessly through the Bitcoin
infrastructure.
* A bank could issue colored coins backed by a cash reserve. People
could withdraw and deposit money in colored coins, and trade those, or
use them to pay for goods and services. The Blockchain becomes a
system allowing to transact not only in Bitcoin, but in any currency.
* Locks on cars or houses could be associated with a particular type
of colored coins. The door would only open when presented with a
wallet containing that specific coin.
==Protocol Overview==
Outputs using the Open Assets Protocol to store an asset have two new
characteristics:
* The '''asset ID''' is a 160 bits hash, used to uniquely identify the
asset stored on the output.
* The '''asset quantity''' is an unsigned integer representing how
many units of that asset are stored on the output.
This document describes how the asset ID and asset quantity of an
output are calculated.
Each output in the Blockchain can be either colored or uncolored:
* Uncolored outputs have no asset ID and no asset quantity (they are
both undefined).
* Colored outputs have a strictly positive asset quantity, and a
non-null asset ID.
The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the
output script referenced by the first input of the transaction that
initially issued that asset (<code>script_hash =
RIPEMD160(SHA256(script))</code>). An issuer can reissue more of an
already existing asset as long as they retain the private key for that
asset ID. Assets on two different outputs can only be mixed together
if they have the same asset ID.
Like addresses, asset IDs can be represented in base 58. They must use
version byte 23 (115 in TestNet3) when represented in base 58. The
base 58 representation of an asset ID therefore starts with the
character 'A' in MainNet.
The process to generate an asset ID and the matching private key is
described in the following example:
# The issuer first generates a private key:
<code>18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725</code>.
# He calculates the corresponding address:
<code>16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM</code>.
# Next, he builds the Pay-to-PubKey-Hash script associated to that
address: <code>OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY
OP_CHECKSIG</code>.
# The script is hashed: <code>36e0ea8e93eaa0285d641305f4c81e563aa570a2</code>
# Finally, the hash is converted to a base 58 string with checksum
using version byte 23:
<code>ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC</code>.
The private key from the first step is required to issue assets
identified by the asset ID
<code>ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC</code>. This acts as a
digital signature, and gives the guarantee that nobody else but the
original issuer is able to issue assets identified by this specific
asset ID.
==Open Assets Transactions==
Transactions relevant to the Open Assets Protocol must have a special
output called the marker output. This allows clients to recognize such
transactions. Open Assets transactions can be used to issue new
assets, or transfer ownership of assets.
Transactions that are not recognized as an Open Assets transaction are
considered as having all their outputs uncolored.
===Marker output===
The marker output can have a zero or non-zero value. The marker output
starts with the OP_RETURN opcode, and can be followed by any sequence
of opcodes, but it must contain a PUSHDATA opcode containing a
parsable Open Assets marker payload. If multiple parsable PUSHDATA
opcodes exist in the same output, the first one is used, and the other
ones are ignored.
If multiple valid marker outputs exist in the same transaction, the
first one is used and the other ones are considered as regular
outputs. If no valid marker output exists in the transaction, all
outputs are considered uncolored.
The payload as defined by the Open Assets protocol has the following format:
{|
! Field !! Description !! Size
|-
! OAP Marker || A tag indicating that this transaction is an
Open Assets transaction. It is always 0x4f41. || 2 bytes
|-
! Version number || The major revision number of the Open Assets
Protocol. For this version, it is 1 (0x0100). || 2 bytes
|-
! Asset quantity count || A
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] representing the number of items in the <code>asset
quantity list</code> field. || 1-9 bytes
|-
! Asset quantity list || A list of zero or more
[http://en.wikipedia.org/wiki/LEB128 LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
|-
! Metadata length || The
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] encoded length of the <code>metadata</code> field. || 1-9
bytes
|-
! Metadata || Arbitrary metadata to be associated with
this transaction. This can be empty. || Variable
|}
Possible formats for the <code>metadata</code> field are outside of
scope of this protocol, and may be described in separate protocol
specifications building on top of this one.
The <code>asset quantity list</code> field is used to determine the
asset quantity of each output. Each integer is encoded using variable
length [http://en.wikipedia.org/wiki/LEB128 LEB128] encoding (also
used in [https://developers.google.com/protocol-buffers/docs/encoding#varints
Google Protocol Buffers]). If the LEB128-encoded asset quantity of any
output exceeds 9 bytes, the marker output is deemed invalid. The
maximum valid asset quantity for an output is 2<sup>63</sup> - 1
units.
If the marker output is malformed, it is considered non-parsable.
Coinbase transactions and transactions with zero inputs cannot have a
valid marker output, even if it would be otherwise considered valid.
If there are less items in the <code>asset quantity list</code> than
the number of colorable outputs (all the outputs except the marker
output), the outputs in excess receive an asset quantity of zero. If
there are more items in the <code>asset quantity list</code> than the
number of colorable outputs, the marker output is deemed invalid. The
marker output is always uncolored.
After the <code>asset quantity list</code> has been used to assign an
asset quantity to every output, asset IDs are assigned to outputs.
Outputs before the marker output are used for asset issuance, and
outputs after the marker output are used for asset transfer.
====Example====
This example illustrates how a marker output is decoded. Assuming the
marker output is output 1:
Data in the marker output Description
-----------------------------
-------------------------------------------------------------------
0x6a The OP_RETURN opcode.
0x10 The PUSHDATA opcode for a 16 bytes payload.
0x4f 0x41 The Open Assets Protocol tag.
0x01 0x00 Version 1 of the protocol.
0x03 There are 3 items in the asset quantity list.
0xac 0x02 0x00 0xe5 0x8e 0x26 The asset quantity list:
- '0xac 0x02' means output 0 has an
asset quantity of 300.
- Output 1 is skipped and has an
asset quantity of 0
because it is the marker output.
- '0x00' means output 2 has an
asset quantity of 0.
- '0xe5 0x8e 0x26' means output 3
has an asset quantity of 624,485.
- Outputs after output 3 (if any)
have an asset quantity of 0.
0x04 The metadata is 4 bytes long.
0x12 0x34 0x56 0x78 Some arbitrary metadata.
===Asset issuance outputs===
All the outputs before the marker output are used for asset issuance.
All outputs preceding the marker output and with a non-zero asset
quantity get assigned the asset ID defined as the RIPEMD-160 hash of
the SHA-256 hash of the output script referenced by the first input of
the transaction. Outputs that have an asset quantity of zero are
uncolored.
===Asset transfer outputs===
All the outputs after the marker output are used for asset transfer.
The asset IDs of those outputs are determined using a method called
order-based coloring.
Inputs are seen as a sequence of asset units, each having an asset ID.
Similarly, outputs are seen as a sequence of asset units to be
assigned an asset ID. These two sequences are built by taking each
input or output in order, each of them adding a number of asset units
equal to their asset quantity. The process starts with the first input
of the transaction and the first output after the marker output.
After the sequences have been built, the asset ID of every asset unit
in the input sequence is assigned to the asset unit at the same
position in the output sequence until all the asset units in the
output sequence have received an asset ID. If there are less asset
units in the input sequence than in the output sequence, the marker
output is considered invalid.
Finally, for each transfer output, if the asset units forming that
output all have the same asset ID, the output gets assigned that asset
ID. If any output is mixing units with more than one distinct asset
ID, the marker output is considered invalid. Outputs with an asset
quantity of zero are always considered uncolored.
===Example===
This is an example of an Open Assets transaction.
The coloring process starts by retrieving the asset quantities and
asset IDs of the outputs referenced by each input of the transaction.
Then, the marker output is identified. In this example, it is output
2, and the <code>asset quantity list</code> field contains the
following values:
0, 10, 6, 0, 7, 3
This list is used to assign asset quantities to outputs.
Inputs Outputs - Initial state
Outputs - Final result
============================= =============================
=============================
Input 0 Output 0 (Issuance)
Output 0 (Issuance)
Asset quantity: 3 Asset quantity: 0
Asset quantity: <NULL>
Asset ID: A1 Asset ID:
Asset ID: <NULL>
----------------------------- -----------------------------
-----------------------------
Input 1 Output 1 (Issuance)
Output 1 (Issuance)
Asset quantity: 2 Asset quantity: 10
Asset quantity: 10
Asset ID: A1 Asset ID:
Asset ID: H
----------------------------- -----------------------------
-----------------------------
Input 2 Output 2 (Marker)
Output 2 (Marker)
Asset quantity: <NULL> Asset quantity: <NULL>
Asset quantity: <NULL>
Asset ID: <NULL> Asset ID: <NULL>
Asset ID: <NULL>
----------------------------- -----------------------------
-----------------------------
Input 3 Output 3 (Transfer)
Output 3 (Transfer)
Asset quantity: 5 Asset quantity: 6
Asset quantity: 6
Asset ID: A1 Asset ID:
Asset ID: A1
----------------------------- -----------------------------
-----------------------------
Input 4 Output 4 (Transfer)
Output 4 (Transfer)
Asset quantity: 3 Asset quantity: 0
Asset quantity: <NULL>
Asset ID: A1 Asset ID:
Asset ID: <NULL>
----------------------------- -----------------------------
-----------------------------
Input 5 Output 5 (Transfer)
Output 5 (Transfer)
Asset quantity: 9 Asset quantity: 7
Asset quantity: 7
Asset ID: A2 Asset ID:
Asset ID: A1
============================= -----------------------------
-----------------------------
Output 6 (Transfer)
Output 6 (Transfer)
Asset quantity: 3
Asset quantity: 3
Asset ID:
Asset ID: A2
=============================
=============================
Outputs are colored from the first to the last. Outputs before the
marker output are issuance outputs:
* Output 0 has an asset quantity of zero, so it is considered uncolored.
* Output 1 gets assigned the asset ID defined by <code>H =
RIPEMD160(SHA256((S))</code> where <code>S</code> is the output script
referenced by the first input of the transaction (input 0).
Output 2 is the marker output, separating issuance outputs from
transfer outputs. The marker output is always uncolored.
Transfer outputs are then colored:
* Output 3 receives 3 units from input 0, 2 units from input 1, 0 unit
from input 2 and 1 unit from input 3. All the 6 units have the same
asset ID <code>A1</code>, so the asset ID <code>A1</code> is assigned
to output 3.
* Output 4 has an asset quantity of zero, so it is considered uncolored.
* Output 5 receives the remaining 4 units of input 3, and 3 units from
input 4. All the 7 units have the same asset ID <code>A1</code>, so
the asset ID <code>A1</code> is assigned to output 5.
* Output 6 receives the first 3 units of input 5. Input 5 has the
asset ID <code>A2</code> so the asset ID <code>A2</code> is assigned
to output 6.
==Rationale==
This approach offers a number of desirable characteristics:
# Economical: The cost of issuing or transferring an asset is
completely independent from the quantity issued or transferred.
# Clients have a way to identify colored outputs simply by traversing
the Blockchain, without needing to be fed external data. Transactions
relevant to the Open Assets Protocol are identified by the special
marker output.
# It is possible to determine the asset ID and asset quantity of an
output by traversing only a limited number of transactions.
# Assets are pseudonymous. They are represented by an asset ID, which
is enough to identify each asset uniquely, while still providing an
adequate level of anonymity for both the issuer and users of the
asset.
# This approach uses the recommended way to embed data in the
Blockchain (OP_RETURN), and therefore does not pollute the UTXO.
# The whole cryptographic infrastructure that Bitcoin provides for
securing the spending of outputs is reused for securing the ability to
issue assets. There is a symmetry between ''an address + private key''
as a way to spend Bitcoins, and ''an address + private key'' as a way
to issue assets.
# Generating a new type of asset is as simple as generating an
address, can be done offline, and for free.
# Reissuing more of an existing asset is easy and can be done quickly
and at no cost (except for the transaction fee) as long as the issuer
retains the private key for the asset ID.
# Single-issuance assets can be achieved by destroying the private key
used to issue the asset immediately after issuing it.
# Since issuance is based on standard Bitcoin output scripts, it is
possible to create an asset that requires multiple signatures for
issuance.
==Compatibility==
For backward compatibility reasons, we consider than an older client
is allowed to see a colored output as uncolored.
===Backward compatibility with existing Bitcoin protocol===
The Open Assets Protocol sits on top of the Bitcoin protocol. It does
not require any change to the existing Bitcoin protocol. Existing
clients that don't support the Open Assets Protocol will see all
outputs as uncolored, and will not be able to perform transfer
transactions.
===Compatibility between different versions of OAP===
New versions with the same major version number (e.g. 1.1) should be
backwards compatible. New versions with a different major version
number (e.g. 2.0) can introduce breaking changes, but transactions
created by newer clients will be identifiable by a different version
number in the output 0 of genesis and transfer transactions.
==Copyright==
This document has been placed in the public domain.
Nicolas Dorier,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160526/7b874290/attachment-0001.html>

2023-06-07 17:50:23

- reply

📅 Original date posted:2016-05-08
📝 Original message:Interesting, can you provide some historical context around it so I
understand better ?
Actually I know that your relay's protocol (and about what I see in
abstract) was about optimizing propagation time and not bandwidth.
And I agree that bandwidth is what need to be optimized for nodes.
So far there was two other proposal that I know only from name and theory
which is xthin block and ILBT which would also have decreased bandwidth.
Can you quickly describe how does it compares to them ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160508/eaaba9dc/attachment.html>

2023-06-07 17:48:59

- reply

📅 Original date posted:2016-02-09
📝 Original message:> 2) In order to prevent significant blowups in the cost to validate
> [...] and transactions are only allowed to contain
> up to 20 non-segwit inputs. [...]
There is two kind of hard fork, the one who breaks things, and the one who
does not.
Restricting the non-segwit inputs would disrupt lots of services, and
potentially invalidating
hash time locked transactions, which is a very bad precedent.
So I'm strongly against this particular point.
> scriptPubKeys are now limited to 100 bytes in
> size and may not contain OP_CODESEPARATOR, scriptSigs must be push-only
> (ie no non-push opcodes)
Same problem for native multisig, however potentially less important than
the previous point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160209/a04a4478/attachment.html>

2023-06-07 17:37:28

- reply

📅 Original date posted:2015-08-21
📝 Original message:> A visualization I would like to see would include:
> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP sipa
etc) based on what's published in blocks.
If such a vote existed, I would gladly show the pie on BIPxDevs.
However there is no standard way for miners to vote informally BIP they
support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/3a6b34e7/attachment.html>

2023-06-07 17:36:55

- reply

📅 Original date posted:2015-08-21
📝 Original message:I'm not against it (mostly active committers as you are), my challenge is
getting the PGP keys scattered all over the place.
If you want put your thoughts, then let me know you pgp.
On Fri, Aug 21, 2015 at 12:45 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> I think everyone who has contributed any commits to the Bitcoin Core
> project should have a say in this.
>
>
> On Aug 20, 2015, at 8:38 PM, Nicolas Dorier via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Thanks, btcdrak, I just added the column and you in the list. (looks nicer)
>
> What I am calling "core devs" in the website is only "commit access
> people", should I rename this group ?
> I just want a way to improve readability of the website by grouping, I am
> open to all subjection on different way of grouping.
>
> I'm good for adding Mike Hearn, Adam Back, Mark Friedenback, Jorge Timons,
> Nick Szabo, Meni Rosenfeld, Charlee Lee.
>
> If some of you are reading this list, please send me your PGP public key.
> For the others, any idea where I can hunt their PGP public keys ?
>
> On Fri, Aug 21, 2015 at 12:10 PM, Btc Drak <btcdrak at gmail.com> wrote:
>
>> I was looking at this site recently and it's not very clear that by
>> clicking the name you get their opinion. I would make that a separate
>> column stated, Technical Opinion.
>>
>> I think you need to include more of the developers/technical people,
>> Adam Back, Mark Friedenback, Jorge Timons, (all of who are core
>> developers). You need
>> Peter Todd is a core dev btw, as is thebluematt.
>>
>> You need other experts, I would include Nick Szabo, Meni Rosenfeld,
>> Charlie Lee might be a good one. You should get the pools on there
>> too.
>>
>> You're missing Mike Hearn of course.
>>
>> My key is 0xE5D138F5E73A1AF2
>>
>>
>> On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > I created a small website which show a chart of your approvals about
>> various
>> > BIPs (which you must fill by yourself with a signed pgp message)
>> >
>> > For each BIP, you can fill if you approve or not, and give comments.
>> (HTML
>> > accepted, so you can link stuff you your posts)
>> >
>> > It would help the community a lot, so I hope you will do it !
>> > I'm open to add other important devs, big miners, or other proposal
>> that I
>> > missed.
>> >
>> > Please, respond on BTC Talk or github. (I don't read the mailing anymore
>> > because of the spam :( )
>> >
>> > Link : http://bipsxdevs.azurewebsites.net/
>> > BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164
>> > Github : https://github.com/NicolasDorier/BIPxDevs
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>
> _______________________________________________
> 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/20150821/8528f3eb/attachment.html>

2023-06-07 17:36:55

- reply

📅 Original date posted:2015-08-21
📝 Original message:Thanks, btcdrak, I just added the column and you in the list. (looks nicer)
What I am calling "core devs" in the website is only "commit access
people", should I rename this group ?
I just want a way to improve readability of the website by grouping, I am
open to all subjection on different way of grouping.
I'm good for adding Mike Hearn, Adam Back, Mark Friedenback, Jorge Timons,
Nick Szabo, Meni Rosenfeld, Charlee Lee.
If some of you are reading this list, please send me your PGP public key.
For the others, any idea where I can hunt their PGP public keys ?
On Fri, Aug 21, 2015 at 12:10 PM, Btc Drak <btcdrak at gmail.com> wrote:
> I was looking at this site recently and it's not very clear that by
> clicking the name you get their opinion. I would make that a separate
> column stated, Technical Opinion.
>
> I think you need to include more of the developers/technical people,
> Adam Back, Mark Friedenback, Jorge Timons, (all of who are core
> developers). You need
> Peter Todd is a core dev btw, as is thebluematt.
>
> You need other experts, I would include Nick Szabo, Meni Rosenfeld,
> Charlie Lee might be a good one. You should get the pools on there
> too.
>
> You're missing Mike Hearn of course.
>
> My key is 0xE5D138F5E73A1AF2
>
>
> On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I created a small website which show a chart of your approvals about
> various
> > BIPs (which you must fill by yourself with a signed pgp message)
> >
> > For each BIP, you can fill if you approve or not, and give comments.
> (HTML
> > accepted, so you can link stuff you your posts)
> >
> > It would help the community a lot, so I hope you will do it !
> > I'm open to add other important devs, big miners, or other proposal that
> I
> > missed.
> >
> > Please, respond on BTC Talk or github. (I don't read the mailing anymore
> > because of the spam :( )
> >
> > Link : http://bipsxdevs.azurewebsites.net/
> > BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164
> > Github : https://github.com/NicolasDorier/BIPxDevs
> >
> > _______________________________________________
> > 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/20150821/0aaf53d6/attachment-0001.html>

2023-06-07 17:36:54

- reply

📅 Original date posted:2015-08-21
📝 Original message:My UX skills are lacking a bit. You can edit all your thoughts about each
BIP, HTML is accepted, so you can link to other posts you made somewhere
else.
When you click on a cell in the grid, it forward you to the page that the
dev edited for this BIP.
This website is not only to say "approve", "disapprove", nor is it about a
formal process for reaching agreement.
This is a tool, a portal, which educates people, and permit you to link all
of your thoughts about the various BIP and show it to others.
With the opinions browse able from the same website, you will notice in a
gleam as soon as one of those proposal reach consensus. (I think SIPA's BIP
has a chance to do so, but nobody knows it yet)
Sadly, the most controversial is a BIP, the noisier it is, at the expense
of those which are not. (like sipa's one).
It irritates me a lot that the debate in public mind is "XT or not" /
"Bigger blocks or not", when in reality there is lots of different
proposals that might also reach consensus but are lost in the noise.
I will add any BIP that at least one voter approve and want to push forward.
I plan to add merchants/wallet providers/mining pools later.
On Fri, Aug 21, 2015 at 6:35 PM, Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 21 August 2015 02:31:51 GMT-07:00, Btc Drak <btcdrak at gmail.com> wrote:
> >On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
> ><bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> What might be valuable is to ask devs to explain what their threat
> >models are, what should be at the root of their thinking about the
> >blocksize.
> >
> >That's exactly what the "Technical Opinion" column is for.
>
> What if could be used for; theres value in being more explicit.
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vDG
> AAoJEMCF8hzn9Lncz4MIAIMtLLA4q7KJiwrYrpjFWme1ys9iyPZiADJGQWG3qKlH
> Q4pEcwWt69jfTUCjLYfegsDW4eEMarejs568iSF70hvGB4OPWrYK3YiM1cWlWtDD
> seN3G/4dJjehL7h1Nz+/OTjTlePkguHctRlJTavel8sI7fg356iMJc1Ggm5Q1ZFl
> CLrivr/CEO7Qk9Uo5ewhnwConKjLygSyv67SSaMJW7pZB06uTX6M3lk11c/RB/C6
> JKPqxkvOmNIX9U8S/G3Y2pYf3/up72IhP0Ugp31iOsz629B2WvEsDYu/0SP61+oZ
> za9HrP2g8OsxVq6SUD3MukmbRVKklvcnro4vk5sOlYI=
> =Jfl+
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/e8603b17/attachment.html>

2023-06-07 17:36:50

- reply

📅 Original date posted:2015-08-21
📝 Original message:Decision making is not the goal of this site, it is only a way to see
various pros and cons of various devs on various proposals in a single
place.
This is for the community to have a coherent view about what you are
talking about now spread into reddit/mailing/forums.
If you did not analyzed a proposal yet, you don't have to fill out your
opinion veto or approval.
It is only to show what you would you "approve" and what you would "veto",
after your analysis.
Then point out all the discussions in the opinion section that lead you to
your conclusion.
You can change edit your position as you progress into your analysis and as
new BIP get redacted.
I'm eager to include the new proposals.
On Fri, Aug 21, 2015 at 1:45 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Aug 19, 2015 at 4:57 AM, Nicolas Dorier via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I created a small website which show a chart of your approvals about
> various
> > BIPs (which you must fill by yourself with a signed pgp message)
> > For each BIP, you can fill if you approve or not, and give comments.
> (HTML
> > accepted, so you can link stuff you your posts)
> > It would help the community a lot, so I hope you will do it !
> > I'm open to add other important devs, big miners, or other proposal that
> I
> > missed.
>
>
> I think this is a bit well, sad, at the moment-- a basic principle in
> sound decision making is that one should try to withhold judgement
> until after the analysis and options are laid out to avoid prematurely
> laying down "battle lines" which then they're socially and politically
> committed to a particular answer.
>
>
> There are several other BIPs in the works right now that aren't out
> there yet, as well (as presumably) new insight from the workshop. It
> would be a shame if these things would be for naught because of being
> decided prematurely.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/82dc4ac7/attachment.html>

2023-06-07 17:36:49

- reply

📅 Original date posted:2015-08-19
📝 Original message:I created a small website which show a chart of your approvals about
various BIPs (which you must fill by yourself with a signed pgp message)
For each BIP, you can fill if you approve or not, and give comments. (HTML
accepted, so you can link stuff you your posts)
It would help the community a lot, so I hope you will do it !
I'm open to add other important devs, big miners, or other proposal that I
missed.
Please, respond on BTC Talk or github. (I don't read the mailing anymore
because of the spam :( )
Link : http://bipsxdevs.azurewebsites.net/
BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164
Github : https://github.com/NicolasDorier/BIPxDevs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/247efaba/attachment.html>

2023-06-07 17:35:03

- reply

📅 Original date posted:2015-08-13
📝 Original message:Would be wonderful to have this pushed together with CLTV and BIP68.
If BIP68 get pushed in the next fork, this CSV is a no brainer.
Was there a competing RCLTV implementation somewhere that did not depend on
BIP68 for information ? I don't manage to find it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/01a2b714/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-01-28
📝 Original message:Mike, I am not denying it is impossible to do all of that.
Just that it is not a trivial stuff to do to make it works everywhere, and
I think that it is not a good thing for a client side technology.
BIP70 has its use, and I understand why there is case where it is good to
ship the certs in the message and not depends on the transport.
But a standard that just use JSON and HTTPS, even if less flexible that
BIP70, would make it easier and sufficient for today's use case.
On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn <mike at plan99.net> wrote:
> My point is not that there is a limitation in BIP70. My point is that you
>> put the burden of certificate verification on developer's shoulder when we
>> can just leverage built in HTTPS support of the platform.
>>
>
> Platforms that support HTTPS but not certificate handling are rare - I
> know HTML5 is such a platform but such apps are inherently dependent on the
> server anyway and the server can just do the parsing and validation work
> itself. If WinRT is such a platform, OK, too bad.
>
> The embedding of the certificates is not arbitrary or pointless, by the
> way. It's there for a very good reason - it makes the signed payment
> request verifiable by third parties. Effectively you can store the signed
> message and present it later to someone else, it's undeniable. Combined
> with the transactions and merkle branches linking them to the block chain,
> what you have is a form of digital receipt ... a proof of purchase that can
> be automatically verified as legitimate. This has all kinds of use cases.
>
> Because of how HTTPS works, you can't easily prove to a third party that a
> server gave you a piece of data. Doing so requires staggeringly complex
> hacks (see tls notary) and when we designed BIP70, those hacks didn't even
> exist. So we'd lose the benefit of having a digitally signed request.
>
> Additionally, doing things this way means BIP70 requests can be signed by
> things which are not HTTPS servers. For example you can sign with an email
> address cert, an EV certificate i.e. a company, a certificate issued by
> some user forum, whatever else we end up wanting. Not every payment
> recipient can be identified by a domain name + dynamic session.
>
>
>> However, if you want to use your plateform's store, then you are toasted
>>
>
> That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
> Windows and Mac certificate stores all using the same code or very minor
> variants on it (e.g. on Mac you have to specify you want the system store
> but it's a one-liner).
>
> Yes, that's not *every* platform. Some will require custom binding glue
> and it depends what abstractions and languages you are using.
>
>
>> Have you tried to do that on windows RT and IOS ? I tried, and I quickly
>> stopped doing that since it is not worth the effort. (Frankly I am not even
>> sure you can on win rt, since the API is a stripped down version of windows)
>>
>
> There is code to do iOS using the Apple APIs here:
>
>
> https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391
>
>
>> Why have you not heard about the problem ? (until now, because I have
>> this problem because I need to have the same codebase on
>> winrt/win/android/ios/tablets)
>>
>
> WinRT is a minority platform in the extreme, and all the other platforms
> you mentioned have the necessary APIs. Java abstracts you from them. So I
> think you are encountering this problem because you desire to target WinRT
> and other platforms with a single codebase. That's an unusual constraint.
>
> AFAIK the only other people who encountered this are BitPay, because they
> want to do everything in Javascript which doesn't really provide any major
> APIs.
>
>
>> Also, you bundle mozilla's store in bitcoinj, what happen when the store
>> change and your customer have not intent to use bitcoinj new version ? by
>> leveraging the plateform you benefit from automatic updates.
>>
>
> Yes, there are pros and cons to bundling a custom root store.
>
>
>> Also, does java stores deals with certificate revocations ? sure you can
>> theorically code that too... or just let the plateform deals with it.
>>
>
> It can do OCSP checks, yes, although I believe no wallets currently do so.
> A better solution would be to implement an OCSP stapling extension to BIP70
> though.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/0b7e5cdf/attachment.html>