Renumbered BSIPs due to removal of old bsip-1203. Updated links.
This commit is contained in:
Christopher Sanborn
parent
07af9adbf6
commit
d039e475b4
6 changed files with 62 additions and 62 deletions
|
|
@ -48,6 +48,6 @@ Number | Title |
|
|||
[1200](bsip-1200.md) | Stealth development, Phase II | Chris Sanborn | Informational | Draft
|
||||
[1201](bsip-1201.md) | New operations for Confidential Asset (CA) transactions | Chris Sanborn | Protocol | Draft
|
||||
[1202](bsip-1202.md) | Ring signatures for untraceability of Stealth transactions | Chris Sanborn | Protocol | Draft
|
||||
[1204](bsip-1204.md) | Blockchain scanning for inbound Stealth transactions | Chris Sanborn | Protocol | Draft
|
||||
[1205](bsip-1205.md) | Deterministic addresses for Stealth wallets | Chris Sanborn | Informational | Draft
|
||||
[1206](bsip-1206.md) | Metadata hiding via Garlic Routing and other means | Chris Sanborn | Informational | Draft
|
||||
[1203](bsip-1203.md) | Blockchain scanning for inbound Stealth transactions | Chris Sanborn | Protocol | Draft
|
||||
[1204](bsip-1204.md) | Deterministic addresses for Stealth wallets | Chris Sanborn | Informational | Draft
|
||||
[1205](bsip-1205.md) | Metadata hiding via Garlic Routing and other means | Chris Sanborn | Informational | Draft
|
||||
|
|
|
|||
16
bsip-1200.md
16
bsip-1200.md
|
|
@ -10,8 +10,8 @@
|
|||
|
||||
## Abstract
|
||||
|
||||
To discuss the continued development of Stealth functionality and provide an overview of the following six BSIPs which define components of that development.
|
||||
|
||||
To discuss the continued development of Stealth functionality and provide an overview of the following BSIPs which define components of that development.
|
||||
|
||||
Component BSIPs: _(Works in progress!!)_
|
||||
|
||||
Number | Title | Type | Status
|
||||
|
|
@ -19,9 +19,9 @@ Number | Title
|
|||
[1200](bsip-1200.md) | Stealth development, Phase II — _(this document)_ | Informational | Draft
|
||||
[1201](bsip-1201.md) | New operations for Confidential Asset (CA) transactions | Protocol | Draft
|
||||
[1202](bsip-1202.md) | Ring signatures for untraceability of Stealth transactions | Protocol | Draft
|
||||
[1204](bsip-1204.md) | Blockchain scanning for inbound Stealth transactions | Protocol | Draft
|
||||
[1205](bsip-1205.md) | Deterministic addresses for Stealth wallets | Informational | Draft
|
||||
[1206](bsip-1206.md) | Metadata hiding via Garlic Routing and other means | Informational | Draft
|
||||
[1203](bsip-1203.md) | Blockchain scanning for inbound Stealth transactions | Protocol | Draft
|
||||
[1204](bsip-1204.md) | Deterministic addresses for Stealth wallets | Informational | Draft
|
||||
[1205](bsip-1205.md) | Metadata hiding via Garlic Routing and other means | Informational | Draft
|
||||
|
||||
## Motivation
|
||||
|
||||
|
|
@ -61,15 +61,15 @@ We propose and discuss the implementation of ring signatures for Stealth transac
|
|||
|
||||
The current implementation of CT requires that a sender must comunicate to the recipient a "transaction receipt" that contains, in encrypted form, data that the recipient needs in order to take posession of a transaction output. This is burdensome, and implies a high risk of lost funds as a result of lost or uncommunicated receipts.
|
||||
|
||||
We propose automated, privacy-preserving methods of scanning for inbound transactions in [BSIP-1203](bsip-1203.md) and [BSIP-1204](bsip-1204.md).
|
||||
We propose automated, privacy-preserving methods of scanning for inbound transactions in [BSIP-1203](bsip-1203.md).
|
||||
|
||||
#### Backups of Stealth Balances
|
||||
|
||||
In [BSIP-1205](bsip-1205.md) we propose standardized derivation of Stealth addresses to enable backup seeds or brain keys to be used to securely back up a Stealth account prior to first use, enabling recovery in the event of a lost or corrupted hot wallet.
|
||||
In [BSIP-1204](bsip-1204.md) we propose standardized derivation of Stealth addresses to enable backup seeds or brain keys to be used to securely back up a Stealth account prior to first use, enabling recovery in the event of a lost or corrupted hot wallet.
|
||||
|
||||
#### Metadata Hiding
|
||||
|
||||
Lastly, in [BSIP-1206](bsip-1206.md), we propose methods of hardening wallets against eavesdropping and timing attacks, so that usage patterns and the method used to communicate with the peer-to-peer network do not compromise user privacy. (As an example, a naive wallet might check a users balance by querying the status of a set UTXOs under the user's control, revealing immediately to the network that a given set of UTXOs are "of interest" to a single party.)
|
||||
Lastly, in [BSIP-1205](bsip-1205.md), we propose methods of hardening wallets against eavesdropping and timing attacks, so that usage patterns and the method used to communicate with the peer-to-peer network do not compromise user privacy. (As an example, a naive wallet might check a users balance by querying the status of a set UTXOs under the user's control, revealing immediately to the network that a given set of UTXOs are "of interest" to a single party.)
|
||||
|
||||
## Specifications
|
||||
## Discussion
|
||||
|
|
|
|||
36
bsip-1203.md
Normal file
36
bsip-1203.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
BSIP: 1204 (unassigned)
|
||||
Title: Blockchain scanning for inbound Stealth transactions
|
||||
Authors: Christopher J. Sanborn
|
||||
Status: Draft
|
||||
Type: Protocol
|
||||
Created: 2018-01-29
|
||||
Discussion: <url>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
The existing Stealth implementation ([BSIP-0008](bsip-0008.md)) requires the sender to manually communicate *transaction receipts* to the recipients of each transaction to alert them to the presence of an inbound balance transfer, creating a danger of lost funds due to miscommunicated or lost receipts. This BSIP explores options for automated discovery of inbound transactions while still preserving fundamental privacy features of unlinkability and anonymity.
|
||||
|
||||
## Motivation
|
||||
|
||||
A confidential transaction (cTX) does not identify the recipient. As such, there is no direct way for a wallet to use only its Stealth address to query the p2p network for inbound transactions. In the current "phase one" implementation of Stealth ([BSIP-0008](bsip-0008.md)), inbound discovery is a manual process requiring the sender to communicate "transaction receipts" to the intended recipients of each transaction output in order to alert each recipient of their incoming balance. Transaction reciepts are encrypted data structures that embed the Pedersen commitment of the transaction output (TXO) and a one-time-use key-offset which the recipient uses to derive the private key needed to spend the incoming coin. The need to communicate transaction receipts is burdensome and introduces substantial risk of lost funds due to failure to communicate or retain receipts.
|
||||
|
||||
Automated discovery could be enabled if the receipt were embedded within the transaction data structure and if an aspect of that data structure supported a challenge condition which the recipient could recognize. (As one simple option, the ability to decrypt the receipt could be viewed as the challenge condition, although it may not be the most performant.)
|
||||
|
||||
The current implementation already allows, but does not require, receipts to be embedded in the transactions. Additionally, an existing cleartext field allows (but does not require) the recipient to be identified via their blind address, which could serve to alert the recipient, but at the steep expense of sacrificing unlinkability and anonymity.
|
||||
|
||||
It is proposed to repurpose and perhaps extend the cleartext fields to contain a challenge condition, rather than cleartext address, which recipients can efficiently use to flag inbound transactions while still maintaining unlinkability and anonymity.
|
||||
|
||||
To support this, a wallet will need to either (a) inspect all cTX activity on the network and test the challenge conditions on each transaction, or (b) transmit to the API node some kernel of the challenge so that the API node can select an inclusive cTXO set on behalf of the wallet. (The latter option likely undermines unlinkability, although it would lessen the burden on the receiving wallet.)
|
||||
|
||||
Additionally, the WS/RPC API offered by network nodes will need to be extended to support returning ranges of cTXOs occuring within specified block ranges, so that wallets can scan them. (Currently, cTXOs can *only* be looked up by Pedersen commitment, which for a new inbound transaction, would not yet be known to the wallet.)
|
||||
|
||||
## Rationale
|
||||
## Specifications
|
||||
## Discussion
|
||||
## Summary for Shareholders
|
||||
## Copyright
|
||||
|
||||
This document is placed in the public domain.
|
||||
|
||||
## See Also
|
||||
20
bsip-1204.md
20
bsip-1204.md
|
|
@ -1,29 +1,27 @@
|
|||
BSIP: 1204 (unassigned)
|
||||
Title: Blockchain scanning for inbound Stealth transactions
|
||||
BSIP: 1205 (unassigned)
|
||||
Title: Deterministic addresses for Stealth wallets
|
||||
Authors: Christopher J. Sanborn
|
||||
Status: Draft
|
||||
Type: Protocol
|
||||
Type: Informational
|
||||
Created: 2018-01-29
|
||||
Discussion: <url>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
The existing Stealth implementation ([BSIP-0008](bsip-0008.md)) requires the sender to manually communicate *transaction receipts* to the recipients of each transaction to alert them to the presence of an inbound balance transfer, creating a danger of lost funds due to miscommunicated or lost receipts. This BSIP explores options for automated discovery of inbound transactions while still preserving fundamental privacy features of unlinkability and anonymity.
|
||||
To simplify a wallet owner's backup burden by documenting and standardizing key derivation for Stealth balances from the same backup seeds used to generate the user's regular account keys.
|
||||
|
||||
## Motivation
|
||||
|
||||
A confidential transaction (cTX) does not identify the recipient. As such, there is no direct way for a wallet to use only its Stealth address to query the p2p network for inbound transactions. In the current "phase one" implementation of Stealth ([BSIP-0008](bsip-0008.md)), inbound discovery is a manual process requiring the sender to communicate "transaction receipts" to the intended recipients of each transaction output in order to alert each recipient of their incoming balance. Transaction reciepts are encrypted data structures that embed the Pedersen commitment of the transaction output (TXO) and a one-time-use key-offset which the recipient uses to derive the private key needed to spend the incoming coin. The need to communicate transaction receipts is burdensome and introduces substantial risk of lost funds due to failure to communicate or retain receipts.
|
||||
Current wallet implementations (e.g. the CLI wallet and Agorise's extensions to the UI wallet) generate a new Brain Key for each Stealth "account" (defined as a confidential balance under the control of a single private key). Since creating a confidential account is a purely client-side activity, (in contrast with a regular account which is registered on the blockchain), there is no automatic association between a confidential balance and a regular account that ostensibly "owns" it, and a backup burden is created for each new confidential balance.
|
||||
|
||||
Automated discovery could be enabled if the receipt were embedded within the transaction data structure and if an aspect of that data structure supported a challenge condition which the recipient could recognize. (As one simple option, the ability to decrypt the receipt could be viewed as the challenge condition, although it may not be the most performant.)
|
||||
It would be desireable to give the user the ability to maintain all of her accounts and balances under the control of a single backup key seed or brain key, so that the backup burden can be satisfied just once, at the creation of the user's first regular account. The derivation schemes defined under Bitcoin's BIP-44 provide a natural mechanism for this, and Satoshi Lab's SLIP-48 already define derivation paths for owner, active, and memo keys on BitShares and similar networks.
|
||||
|
||||
The current implementation already allows, but does not require, receipts to be embedded in the transactions. Additionally, an existing cleartext field allows (but does not require) the recipient to be identified via their blind address, which could serve to alert the recipient, but at the steep expense of sacrificing unlinkability and anonymity.
|
||||
We propose here:
|
||||
|
||||
It is proposed to repurpose and perhaps extend the cleartext fields to contain a challenge condition, rather than cleartext address, which recipients can efficiently use to flag inbound transactions while still maintaining unlinkability and anonymity.
|
||||
(1) To define additional derivation paths for Stealth accounts, and,
|
||||
|
||||
To support this, a wallet will need to either (a) inspect all cTX activity on the network and test the challenge conditions on each transaction, or (b) transmit to the API node some kernel of the challenge so that the API node can select an inclusive cTXO set on behalf of the wallet. (The latter option likely undermines unlinkability, although it would lessen the burden on the receiving wallet.)
|
||||
|
||||
Additionally, the WS/RPC API offered by network nodes will need to be extended to support returning ranges of cTXOs occuring within specified block ranges, so that wallets can scan them. (Currently, cTXOs can *only* be looked up by Pedersen commitment, which for a new inbound transaction, would not yet be known to the wallet.)
|
||||
(2) For backwards compatibility with existing accounts secured by Brain Key, to standardise and document a distinct procedure for deriving Stealth keys from Brain Keys so that the same Brain Key that secures a user's regular account can also be used to secure their confidential balances, if the user desires.
|
||||
|
||||
## Rationale
|
||||
## Specifications
|
||||
|
|
|
|||
16
bsip-1205.md
16
bsip-1205.md
|
|
@ -1,5 +1,5 @@
|
|||
BSIP: 1205 (unassigned)
|
||||
Title: Deterministic addresses for Stealth wallets
|
||||
BSIP: 1206 (unassigned)
|
||||
Title: Metadata hiding via Garlic Routing and other means
|
||||
Authors: Christopher J. Sanborn
|
||||
Status: Draft
|
||||
Type: Informational
|
||||
|
|
@ -9,19 +9,15 @@
|
|||
|
||||
## Abstract
|
||||
|
||||
To simplify a wallet owner's backup burden by documenting and standardizing key derivation for Stealth balances from the same backup seeds used to generate the user's regular account keys.
|
||||
To provide an overview of strategies that can be used by wallets to prevent leaking of sensitive metadata, e.g. your interest in particular balances on the blockchain, to third parties that may be monitoring network traffic, or to potentially compromised nodes on the BitShares p2p network.
|
||||
|
||||
## Motivation
|
||||
|
||||
Current wallet implementations (e.g. the CLI wallet and Agorise's extensions to the UI wallet) generate a new Brain Key for each Stealth "account" (defined as a confidential balance under the control of a single private key). Since creating a confidential account is a purely client-side activity, (in contrast with a regular account which is registered on the blockchain), there is no automatic association between a confidential balance and a regular account that ostensibly "owns" it, and a backup burden is created for each new confidential balance.
|
||||
Querying a p2p node to check your confidential balances reveals your interest in particular commitments and threatens anonymity by establishing a link between an IP address and a commitment set. New anonymity technologies such as Garlic routing and i2p can be used to ensure that neither network monitoring nor a compromised p2p node can determine the origin of a request regarding a particular set of commitments, thus protecting anonymity.
|
||||
|
||||
It would be desireable to give the user the ability to maintain all of her accounts and balances under the control of a single backup key seed or brain key, so that the backup burden can be satisfied just once, at the creation of the user's first regular account. The derivation schemes defined under Bitcoin's BIP-44 provide a natural mechanism for this, and Satoshi Lab's SLIP-48 already define derivation paths for owner, active, and memo keys on BitShares and similar networks.
|
||||
Additionally, querying a discrete set of commitments undermines confidential unlinkability. Unlinkability is the inability to determine that multiple independent commitments are controlled by the same party. Although not perfect, a partial solution to this is to use Bloom filters to query a superset of commitments, so that the p2p node will return a mix of linked commitments as well as random commitments, making it difficult for an external observer to establish which commitments are actually of interest to the querying party and which are included by the filter serendipitously.
|
||||
|
||||
We propose here:
|
||||
|
||||
(1) To define additional derivation paths for Stealth accounts, and,
|
||||
|
||||
(2) For backwards compatibility with existing accounts secured by Brain Key, to standardise and document a distinct procedure for deriving Stealth keys from Brain Keys so that the same Brain Key that secures a user's regular account can also be used to secure their confidential balances, if the user desires.
|
||||
There may also exist other strategies of merit to protect unlinkability and privacy generally.
|
||||
|
||||
## Rationale
|
||||
## Specifications
|
||||
|
|
|
|||
30
bsip-1206.md
30
bsip-1206.md
|
|
@ -1,30 +0,0 @@
|
|||
BSIP: 1206 (unassigned)
|
||||
Title: Metadata hiding via Garlic Routing and other means
|
||||
Authors: Christopher J. Sanborn
|
||||
Status: Draft
|
||||
Type: Informational
|
||||
Created: 2018-01-29
|
||||
Discussion: <url>
|
||||
|
||||
|
||||
## Abstract
|
||||
|
||||
To provide an overview of strategies that can be used by wallets to prevent leaking of sensitive metadata, e.g. your interest in particular balances on the blockchain, to third parties that may be monitoring network traffic, or to potentially compromised nodes on the BitShares p2p network.
|
||||
|
||||
## Motivation
|
||||
|
||||
Querying a p2p node to check your confidential balances reveals your interest in particular commitments and threatens anonymity by establishing a link between an IP address and a commitment set. New anonymity technologies such as Garlic routing and i2p can be used to ensure that neither network monitoring nor a compromised p2p node can determine the origin of a request regarding a particular set of commitments, thus protecting anonymity.
|
||||
|
||||
Additionally, querying a discrete set of commitments undermines confidential unlinkability. Unlinkability is the inability to determine that multiple independent commitments are controlled by the same party. Although not perfect, a partial solution to this is to use Bloom filters to query a superset of commitments, so that the p2p node will return a mix of linked commitments as well as random commitments, making it difficult for an external observer to establish which commitments are actually of interest to the querying party and which are included by the filter serendipitously.
|
||||
|
||||
There may also exist other strategies of merit to protect unlinkability and privacy generally.
|
||||
|
||||
## Rationale
|
||||
## Specifications
|
||||
## Discussion
|
||||
## Summary for Shareholders
|
||||
## Copyright
|
||||
|
||||
This document is placed in the public domain.
|
||||
|
||||
## See Also
|
||||
Loading…
Reference in a new issue