Nostr notes by

📅 Original date posted:2017-11-29 📝 Original message: I ...

2023-06-09T12:47:52Z

In reply to nevent1q…72fp
_________________________

📅 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>;

📅 Original date posted:2017-02-07 📝 Original message: Good ...

2023-06-09T12:47:01Z

In reply to nevent1q…kwxq
_________________________

📅 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>;

📅 Original date posted:2017-02-06 📝 Original message: I ...

2023-06-09T12:47:01Z

In reply to nevent1q…h7l3
_________________________

📅 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>;

📅 Original date posted:2017-02-06 📝 Original message: Alice ...

2023-06-09T12:47:00Z

In reply to nevent1q…sefv
_________________________

📅 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>;

📅 Original date posted:2016-03-08 📝 Original message: I ...

2023-06-09T12:45:56Z

In reply to nevent1q…h7vp
_________________________

📅 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>;

📅 Original date posted:2016-03-08 📝 Original message: ...

2023-06-09T12:45:55Z

In reply to nevent1q…mcy7
_________________________

📅 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>;

📅 Original date posted:2016-03-08 📝 Original message: ...

2023-06-09T12:45:55Z

In reply to nevent1q…j9cq
_________________________

📅 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>;

📅 Original date posted:2016-03-07 📝 Original message: One ...

2023-06-09T12:45:54Z

In reply to nevent1q…zwgu
_________________________

📅 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>;

📅 Original date posted:2015-11-27 📝 Original message: By ...

2023-06-09T12:45:18Z

In reply to nevent1q…9qpc
_________________________

📅 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>;

📅 Original date posted:2015-11-27 📝 Original message: > ...

2023-06-09T12:45:18Z

In reply to nevent1q…9npc
_________________________

📅 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>;

📅 Original date posted:2020-05-16 📝 Original message:I am ...

2023-06-07T18:24:46Z

In reply to nevent1q…f88d
_________________________

📅 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>;

📅 Original date posted:2019-04-03 📝 Original message:James, ...

2023-06-07T18:17:31Z

In reply to nevent1q…ux5j
_________________________

📅 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>;

📅 Original date posted:2017-12-20 📝 Original message:Hi ...

2023-06-07T18:08:55Z

In reply to nevent1q…sekj
_________________________

📅 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>;

📅 Original date posted:2016-05-25 📝 Original message:Open ...

2023-06-07T17:50:57Z

In reply to nevent1q…c8dp
_________________________

📅 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>;

📅 Original date posted:2016-05-08 📝 Original ...

2023-06-07T17:50:23Z

In reply to nevent1q…nfeu
_________________________

📅 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>;

📅 Original date posted:2015-08-21 📝 Original ...

2023-06-07T17:36:50Z

In reply to nevent1q…xkmc
_________________________

📅 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>;

📅 Original date posted:2015-08-19 📝 Original message:I ...

2023-06-07T17:36:49Z

In reply to nevent1q…nfzh
_________________________

📅 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>;

📅 Original date posted:2015-08-21 📝 Original ...

2023-06-07T15:48:26Z

In reply to nevent1q…ec34
_________________________

📅 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>;

📅 Original date posted:2015-08-21 📝 Original message:My UX ...

2023-06-07T15:48:26Z

In reply to nevent1q…j52y
_________________________

📅 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>;

📅 Original date posted:2015-08-21 📝 Original ...

2023-06-07T15:48:22Z

In reply to nevent1q…93e2
_________________________

📅 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>;

📅 Original date posted:2015-08-19 📝 Original message:I ...

2023-06-07T15:48:21Z

In reply to nevent1q…k840
_________________________

📅 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>;

📅 Original date posted:2015-01-28 📝 Original message:Mike, ...

2023-06-07T15:28:44Z

In reply to nevent1q…zuer
_________________________

📅 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>;