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

nprofile1qqst7p2gms9dyw0fu8sthg7fd93jmm2q9f5qj8x7rvs6pz27jz7f54cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsj6ylh5

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3

Show more details

Last Notes

2023-06-09 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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 14: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-07 20: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 20: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 19: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 19: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 19: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:48:22

- reply

2023-06-07 17:48:21

- reply