Practical Solutions to Save Bitcoins Applied to an Identity System

Proposal

Daniel Augot

1,2,3

, Herv

e Chabanne

4,5

and William George

1,2,3

Inria, France

Laboratoire LIX,

Ecole Polytechnique & CNRS UMR 7161, France

Universit

e Paris-Saclay, France

Idemia, France

ecom ParisTech, France

Keywords:

Bitcoin, Atomic Swaps, Off-chain Payment Channels, Identity System.

Abstract:

In a recent work by Augot et al. (2017), a scheme is proposed to build an identity system on top of the

Bitcoin network. However, this proposal incurs very high costs since Bitcoin transactions require heavy fees.

The current work introduces modiﬁcations to their scheme to make it more cost efﬁcient while preserving its

potential. Namely, we build on features of Bitcoin’s scripting language, which allows swapping coins between

two compatible blockchains, and also on off-chain transactions.

1 INTRODUCTION

In recent years, there has been much discussion of

the possibility of using blockchains for identity man-

agement (Yang et al., 2016). Generally, proposals in

this sense attempt to take advantage of the decentral-

ized space offered by blockchains to provide a less

top-down model of identity management, empower-

ing users to take a greater control over their identity

in the spirit of Person Identity Management Systems

(PIMS) (Abiteboul et al., 2015).

There have been many, varied proposals for how

blockchains can be used in identity management.

Among projects that are currently targeting enterprise

clients, uPort (Lundkvist et al., 2017) has offered

a solution based on Ethereum, while Sovrin (Tobin

et al., 2016) has created a solution based on a permis-

sionned blockchain. Proposals for blockchain based

identity systems in government include that of the e-

Estonia program (Prisco, 2015)

. See (Jacobovitz,

2016; Dunphy and Petitcolas, 2018) for overviews of

projects in this space.

Particularly relevant to our work is a certiﬁcate is-

suing scheme built onto the Bitcoin blockchain pro-

posed by MIT MediaLabs (Nazar

e et al., 2016),

where a certiﬁcate is associated to a Bitcoin transac-

https://e-estonia.com/solutions/security-and-

safety/ksi-blockchain/

https://e-estonia.com/wp-content/uploads/faq-a4-v02-

blockchain.pdf

tion. This system has the interesting property that re-

vocation of a certiﬁcate is done by emitting a Bitcoin

transaction whose input consumes the output of the

certiﬁcate; as such, protection against attacks using

revoked certiﬁcates is inherited from the immutability

and double spend protections of Bitcoin’s blockchain.

These ideas are then further developed in (Augot

et al., 2017a) and (Augot et al., 2017b). Both of these

works integrate the use of Brands selective disclosure

credentials (Brands, 2000), ﬁrst used in the context

of blockchains in (Garman et al., 2016), for user pri-

vacy. These user privacy ideas are then integrated

with the transactional structure of Bitcoin in order to

effectively manage revocation of identity documents,

developing the ideas of (Nazar

e et al., 2016), how-

ever (Augot et al., 2017a) and (Augot et al., 2017b)

achieve this in somewhat different ways.

Principal advantages (Augot et al., 2017a) in-

clude:

• a ﬂexible user experience, particularly allowing

users to coordinate micro-identities from different

issuers;

• security from Bitcoin’s blockchain for

– enabling monitoring (such as by imposing a

limit of uses of the identity), or building repu-

tation, based on the usage history of an identity

record

– checking that a record has not been revoked that

can be performed by a simpliﬁed payment ver-

Augot, D., Chabanne, H. and George, W.

Practical Solutions to Save Bitcoins Applied to an Identity System Proposal.

DOI: 10.5220/0007443905110518

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 511-518

ISBN: 978-989-758-359-9

511

iﬁcation client (SPV), rather than requiring a

full node;

• the Identity Provider (see below), I P , must be on-

line only to issue and revoke identities, and does

not need to continuously manage revocation status

such as, e.g. in the Online Certiﬁcate Status Pro-

tocol. Essentially, I P has outsourced its role of

maintaining a live database of its certiﬁcates (re-

voked or nor) to the miners, the fullnodes, and the

underlying P2P network of Bitcoin.

The downside of the system of (Augot et al., 2017a)

is that the number of required Bitcoin transactions re-

sults in currently non-viable fees. See Sec. 3 for fur-

ther details.

The proposal of (Augot et al., 2017b) is more ﬁ-

nancially viable. In this system, each Bitcoin transac-

tion in the protocol corresponds to the root of an entire

Merkle tree of user identity documents that are being

issued. This proposal, however, lacks certain good

properties of the system of (Augot et al., 2017a), as

it requires veriﬁers to be a full node for checking the

revocation status, instead of being a light, SPV client,

and that users must place some amount of trust in an

intermediary.

In the present work, we propose a number of mod-

iﬁcations to the architecture of (Augot et al., 2017a)

that are designed to make this system more afford-

able, while preserving as many of its positive features

as possible. These modiﬁcations are based on tools

such as atomic swaps and off-chain protocols, in some

cases inspired by proposals to make the Bitcoin net-

work itself more cost efﬁcient.

We begin in Sec. 2 by introducing some notions

and notations related to Bitcoin. In Sec. 3, we re-

call the system of (Augot et al., 2017a). In Sec. 4,

we present the ﬁrst adaption of (Augot et al., 2017a)

which allows moving the scheme from the Bitcoin

blockchain to Litecoin where lower fees makes the

scheme more economical. In Sec. 5, we show how

identity services can be delivered off-chain. Sec. 6

concludes.

2 BITCOIN AND SOME

NOTATIONS

Types of Transaction Outputs. Bitcoin employs a

limited scripting language whose expressive capac-

ities to determine how an output can be spent we

make use of in this work. Bitcoin transaction out-

puts typically fall into one of the following types (see

(Antonopoulos, 2015)):

• P2PKH: these are the most commonly occurring

Bitcoin transactions. The hash of a public key

is speciﬁed, then to spend the output, a transac-

tion must be signed with the corresponding private

key.

• P2SH: these transactions outputs include the hash

of a script. To spend this output, the script must be

presented, and whatever conditions in that script

must be satisﬁed. P2SH outputs give Bitcoin a

certain ﬂexibility in their scripting language. No-

table uses include

– multisig outputs where the script speciﬁes how

many and among which public keys must be

used to sign the spending transaction

– bounties, where the spender must present some

ﬁxed secret value R

• OP RETURN: these outputs have an amount associ-

ated to them of 0 BTC, hence they are provably

non-spendable. They allow for one to place up to

80 bytes of arbitrary data in the transaction, which

is then recorded in the blockchain.

Fees. The difference between the value of inputs to

a Bitcoin transaction and its outputs is paid in fees to

the miner who ﬁnds the block in which this transac-

tion is included. As each miner chooses which trans-

actions he wants to include in a block and as the total

size of blocks is limited, a market has developed for

what fees need to be paid for a transaction to be in-

cluded in a block in a timely manner

In our work we present several models of trans-

actions, each given a NAME. Also, given a transac-

tion TX

NAME

, we denote by F

NAME

the associated fees

received by the miners

Dust. Non-OP RETURN transaction outputs must have

positive amounts assigned to them. Moreover, in or-

der for a transaction to be considered “standard” by

network participants using the Bitcoin Core software

(Antonopoulos, 2015), each non-OP RETURN output

must have an amount that is at least .000005 bitcoin

In this work, we will generally denote by D the small-

est amount of bitcoin that can be attached to a transac-

tion output so that the transaction is considered stan-

dard. Non-standard transactions will not be circulated

by network participants, although blocks that contain

non-standard yet valid transactions are still accepted.

Full Nodes and Obtaining Network Information.

A full node stores all of the information in every Bit-

coin block. Thus, a full node can verify that the root

of the Merkle tree of transactions in a block corre-

sponds to what is published in the block header. The

https://bitcoinfees.21.co/

https://github.com/bitcoin/bitcoin/blob/0.14/src/

primitives/transaction.h

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

512

downside to operating a full node is that, as the block

chain grows in size, this requires substantially band-

width and storage.

In contrast, the Simpliﬁed Payment Veriﬁcation

protocol (SPV), which was already proposed by

Satoshi (Nakamoto, 2008), allows for one to ver-

ify that a given transaction has been included in the

blockchain without having to operate a full node. This

is particularly important for merchants who want to

see that a given transaction paying them for a service

has processed without having to download the entire

history of the network. An SPV client downloads the

block headers for all blocks, then when they want

to verify a given transaction they communicate with

full nodes and obtain all of hashes along the Merkle

branch of that transaction. As such, they can verify

that the transaction correctly hashes with the hashes

along that branch to the root in the block header.

Timelocks. The most basic type of timelock in Bit-

coin, which uses the ﬁeld nLockTime and has been

present since the original creation of the network,

speciﬁes a time/block before which a transaction can-

not be added to the blockchain

There are other, newer, more exotic types of time-

locks, such as those that control when a single trans-

action output can be spent

, but we will only require

nLockTime in our work.

Notations. For the Bitcoin transaction described in

this paper, we use the following notations: “a for an

amount: x” means that x coins are sent to address a,

and “MSIGi j(a

(1)

, . . . , a

( j)

)” means that i valid signa-

tures are required from the addresses a

(1)

. . . ,a

( j)

For more complex output scripts encoded with a

P2SH output, we use simple Boolean logic with “and”

and “or”, and occasionally, the notation “needs(R)”

means that, for the cryptographic hash function H,

h = H(R) for a random R has been included in the

output script, and that R must be provided in the re-

deeming transaction.

3 IDENTITY MANAGEMENT

SCHEME OF AUGOT ET AL.

We are building our work upon the model of (Augot

et al., 2017a). In particular, we imagine similar use

cases and have mostly the same actors that participate

in our system.

Actors. The actors in the work of (Augot et al.,

2017a) are:

https://en:bitcoin:it/wiki/Timelock

• Users – USR – are people that obtain and use

identity documents through this system.

• Identity Providers – I P – are entities, such as

banks and utility companies, or governments,

which play some role in issuing documents for use

in identity. Typically, I P will physically verify

the documents of a user (passport, etc) and issue a

record on the blockchain.

• Service Providers – S P – are entities to whom a

user needs to prove facts about her identity, on the

basis of a document issued by I P . An example of

a service provider is a library that requires proof

of address through a utility bill.

These participants will each have a Bitcoin ad-

dress: a

USR

, a

I P

, a

S P

. The addresses of I P , S P ,

should be well-known, while USR may wish to have

several addresses a

(i)

USR

which should not be linked to

addresses the user has in Bitcoin for other purposes,

for instance moving bitcoins around, in order to avoid

de-anonymization of these addresses. The user’s ad-

dresses may be used with different identity providers.

Transaction Structure. First, US R presents real-

life proofs of her identity to I P , and a Bitcoin ad-

dress a

(i)

USR

that she controls. I P then constructs a

Brands commitment h

(i)

USR

that blindly encodes the

user’s identity information (see (Augot et al., 2017a)

for details). Then, I P publishes an identity record

containing this information via a Bitcoin transaction

PUBLISH

of the following form:

PUBLISH

(Fees: F

PUBLISH

)

Input Address:

I P

for an Amount: V+D + F

PUBLISH

Output Addresses:

(i)

USR

for an Amount: D

MSIG1 2(a

(i)

USR

, a

I P

) for an Amount: V

RETURN



(i)

USR



This transaction uses an input that belongs to the

address a

I P

. Hence, it is signed by I P ’s private key,

and as a

I P

is well-known, anyone in the system can

verify that this transaction is from I P . The transac-

tion output MSIG1 2(a

(i)

USR

, a

I P

) serves doubly as an

authentication token and a revocation token. As this

output is a 1 of 2 multisignature, either US R or I P

can spend it. USR will spend this output to use her

identity (see below), whereas I P will spend it to re-

voke US R ’s identity. There is also an output to the

address of a

(i)

USR

, with only a symbolic “dust” amount

Practical Solutions to Save Bitcoins Applied to an Identity System Proposal

513

D (See Sec. 2), to link this record to a

(i)

USR

. Finally

the OP RETURN(h

(i)

USR

) contains the Brands commit-

ment.

Then when USR wants to use her identity record

to convince an SP of an aspect of her identity (for

example to prove that she is over 18 to a bar, or to

prove that she has a valid driver’s license to a traf-

ﬁc policeman, without revealing here name), she cre-

ates a Brands proof of the statement SP requires, and

communicates it to S P . Then she issues a Bitcoin

transaction of the form TX

REQUEST

below. US R may

also wish to have the proof archived. To archive in

Bitcoin’s blockchain, the OP RETURN ﬁeld is generally

not large enough to contain the proof, so if there is a

need to attest to it on-chain, USR may provide a link

to an external storage service (cloud or P2P network)

where the proof is stored and a hash of the proof. We

refer to such a reference as “proof-ref” in the follow-

ing TX

REQUEST

(Fees: F

REQUEST

)

Input Address:

MSIG1 2(a

(i)

USR

, a

I P

) for an Amount: V

Output Addresses:

S P

for an Amount: F

+ D

MSIG1 2(a

(i)

USR

, a

I P

) for an Amount:

V − (F

REQUEST

+ F

+ D)

an optional OP RETURN(“proof-ref”)

Finally, when convinced by the proof, S P grants

access to service, and in order to enable a user to

build a reputation, S P sends a transaction of the form

to I P acknowledging that the user’s identity

from I P has been used.

(Fees: F

)

Input Address: a

S P

for an Amount: F

+ D

Output Address: a

I P

for an Amount: D

Note that in TX

REQUEST

, the input is the authentica-

tion token, and one of the outputs is again of the same

form MSIG1 2(a

(i)

USR

, a

I P

). Thus, this output can be

used as the input for a subsequent TX

REQUEST

. The trace

of this sequence of linked outputs of the same form

ties all of the user’s authentication request together,

and SP can trace back a received TX

REQUEST

all the

way to the TX

PUBLISH

to ﬁnd h

(i)

USR

Whenever I P wants to revoke the user’s iden-

tity, he can trace forward the linked list of spent out-

puts to the most recent TX

REQUEST

and spend the out-

put MSIG1 2(a

(i)

USR

, a

I P

) to himself. An advantage

of using the same output to authenticate and to re-

voke (in contrast to (Nazar

e et al., 2016) where revo-

cation is controlled by its own output) is that seeing

that TX

REQUEST

has been included by miners in a re-

cent block can be sufﬁcient to convince S P that that

output has not been previously spent and hence that a

document has not been revoked (up to that block).

The amounts attached to the various outputs in

these transactions are calibrated so that sufﬁcient fees

are paid and outputs all surpass the dust limit. Oth-

erwise, the rest of the value is passed on with the

authentication token, and the value is calibrated for

a number of uses of the token. Alas, (Augot et al.,

2017a) estimates that the cost of establishing an iden-

tity for N uses in this manner to be approximately

(5.2N + 2.6) USD, based on Bitcoin fees and prices

as of September 2017. This high cost is essentially

due to the high cost of Bitcoin transaction fees and

has in fact gotten worse with the rising price of Bit-

coin. At peak (December 2017) estimates of cost for

this system are near (38.73N + 19.71) USD.

4 CHAINED IDENTITIES

ACROSS ATOMIC SWAPS

A ﬁrst idea to modify the scheme of (Augot et al.,

2017a) to reduce costs is to take advantage of lower

transaction costs on the blockchain of some other

cryptocurrency, and to “migrate” the authentication

token from Bitcoin to the blockchain of the other

currency. There are several other cryptocurrencies

whose transactional structures have the necessary ele-

ments and support scripts similar to Bitcoin (recalled

in Sec. 2). For example, this is the case of Lite-

coin

, and Bitcoin Cash

. These currencies have

substantially lower fees

; at the time of writing, the

maximum average fees of Bitcoin (resp. Litecoin,

resp. Bitcoin Cash) was reached in December 2017 at

$55.16 USD (resp. $1.505, $.904). However, the total

hash power of these blockchains also varies greatly:

Bitcoin has a hash rate of 13.4 EH/s, Litecoin 90

TH/s, and Bitcoin Cash 950 PH/s. Thus, in light of the

dependence of the security of our identity scheme on

the resistance of the blockchain to 51% attacks, appli-

cations with higher security requirements may want to

remain on Bitcoin despite the high fees, while lower

security requirements can use the token migrated to

Litecoin.

The identity authentication token can be passed

from one blockchain to another, using an atomic swap

https://www.coindesk.com/information/comparing-

litecoin-bitcoin/

https://www.cryptopia.co.nz/Forum/Thread/981

https://www.bitcoin.com/info/differences-between-

bitcoin-cash-bcc-and-bitcoin-btc

https://bitinfocharts.com/

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

514

with a chain switcher service C S . For simplicity, we

exemplify the concept with Bitcoin (BTC) and Lite-

coin (LTC). In the following, the identity provider I P

has a well-known address a

I P

on the BTC blockchain

and a

I P

on the LTC blockchain (the same holds

for C S , and for some US R ’s addresses a

(i)

USR

and

( j)

USR

). In particular, this gives I P the power to limit

on which chains issued identities can migrate, since

the protocol needs I P to also have an address on the

second chain.

In the following, we let R be a random value and

h = H(R) for a given hash function H(.).

BTC-SWAP

(Fees: F

BTC-SWAP

in BTC)

Input Address: MSIG1 2(a

(i)

USR

, a

I P

) for an

Amount: V

Output Addresses:

C S

for an Amount: D

P2SH(needs(R) and signed by a

C S

OR signed by a

(i)

USR

and a

C S

OR signed by a

I P

)

for an Amount: V−D − F

BTC-SWAP

(in BTC)

OP RETURN(h, txid of TX

LTC-SWAP

)

LTC-SWAP

(Fees: F

LTC-SWAP

in LTC)

Input Address: a

C S

for an Amount: W

Output Addresses:

P2SH(needs(R) and signed by a

( j)

USR

OR signed by a

( j)

USR

and a

C S

)

for an Amount: W −F

LTC-SWAP

(in LTC)

OP RETURN(txid of last TX

REQUEST

issued

on BTC).

Before signing their respective swap transactions,

US R and C S have each other signed backout trans-

actions of the form:

BTC-BACKOUT

(Timelock: t, Fees: F

BTC-BACKOUT

BTC)

Input Address:

P2SH(needs(R) and signed by a

C S

OR signed by a

(i)

USR

and a

C S

OR signed by a

I P

)

for an Amount: V−D − F

BTC-SWAP

Output Address:

MSIG1 2(a

(i)

USR

, a

I P

)

for an Amount: V−D − F

BTC-SWAP

−

BTC-BACKOUT

(in BTC)

LTC-BACKOUT

(Timelock: t

, Fees: F

LTC-BACKOUT

LTC)

Input Address:

P2SH( needs(R) and signed by a

( j)

USR

OR signed by a

( j)

USR

and a

C S

for an Amount: W−F

LTC-SWAP

Output Address:

C S

for an Amount: W − F

LTC-SWAP

− F

LTC-BACKOUT

(in LTC)

Here, as the LTC swap transaction must be cre-

ated ﬁrst, C S should choose R, and communicate

h = H(R) to US R . In particular, the timelock t

should be longer than the timelock t. Then, once R has

been made public and the two swap transactions are

accepted to their respective blockchains, to establish

a usable authentication token as in Section 3, USR

issues herself a transaction of the form:

CREATE-LTC-TOKEN

(Fees: F

CREAT- LTC-TOKEN

)

Input Address:

P2SH(needs(R) and signed by a

C S

OR signed by a

( j)

USR

and a

C S

)

for an Amount: W−F

LTC-SWAP

Output Address:

MSIG1 2(a

( j)

USR

, a

I P

)

for an Amount: W−F

LTC-SWAP

−

CREAT- LTC-TOKEN

US R can now continue to use her identity on the

LTC blockchain exactly as in (Augot et al., 2017a)

to authenticate to service providers. It is essential

that the path of the authentication token from one

blockchain to the other is not broken, to trace forward

(for revocation) and backward (for usage) the authen-

tication token. To preserve the link, the txid of the

LTC-SWAP

transaction is included in the OP RETURN

of the TX

BTC-SWAP

transaction. As such, a veriﬁer fol-

lowing US R ’s transaction history can trace the to-

ken in either direction through the swap. A ser-

vice provider who receives a TX

REQUEST

on chain LTC

can ﬁnd the last transaction of this identity on chain

BTC, and the corresponding TX

PUBLISH

on BTC. Simi-

larly, I P can revoke the identity, by tracing the au-

thentication token to the new chain and spend the

MSIG1 2(a

( j)

USR

, a

I P

). Again, as in (Augot et al.,

2017a), albeit on a different blockchain, an SP that

wants to verify that an identity has not been revoked

again only needs to run an SPV client on the LTC

chain, see Section 3.

Recall that, in a P2SH output, only the hash is

placed in the output and the script is not revealed until

the output is spent. Thus, in order for I P to be able

to revoke US R ’s identity after TX

BTC-SWAP

and before

the TX

CREATE-LTC-TOKEN

transaction is issued, I P needs

to be able to present the script for the P2SH output for

BTC-SWAP

. Ideally, it would be enough to just include

the script in the OP RETURN of this transaction so that

Practical Solutions to Save Bitcoins Applied to an Identity System Proposal

515

it would be available to I P . However, this script must

include: a) h = H(R), b) the three 32-byte public keys

of US R , I P , and C S , c) the txid of the transaction

on the other chain. This is too large for the 80 bytes

limit of the OP RETURN. So, as a workaround, as I P

already knows a

I P

and a

(i)

USR

, we propose to include

only the part of the script that I P does not know,

namely the necessary txid and h should be placed in

the OP RETURN. Meanwhile, an output with a minimal

amount of D is paid to a

C S

so that I P has this address

as well.

We have proposed that C S serves the role of pro-

viding coins on the new chain in exchange for the old.

However, a user does not need to depend on any spe-

ciﬁc C S for this role. Indeed, I P could also perform

this role, or in a more decentralized and trustless way,

the user herself can play this role, assuming she al-

ready possesses some coins on the new chain in an

address a

( j)

USR

, that she is willing to publicly tie to her

identity address a

(i)

USR

. Due to the symmetry of this

protocol, the user can go back to the chain on which

her identity was originally issued at some later time

via the same transfer mechanism.

We leverage on the security of (Augot et al.,

2017a) for this proposal. Namely, the system depends

on properties of an ideal blockchain: consistency of

the chain of transactions inputs and outputs, and the

global availability of the data, as BTC and LTC in our

example, and immutability of the associated ledgers.

5 AUTHENTICATION TOKENS

USED IN OFF-CHAIN

CHANNELS

As we saw in Section 3, the central problem in the

protocol of (Augot et al., 2017a) is the bandwidth it

required in the Bitcoin network and the associated

transaction costs. So we are inspired by the Lightning

Network (Joseph Poon and Thaddeus Dryja, 2016)

and its proposals to allow secure, off-chain transac-

tions in the Bitcoin network.

A new actor is introduced, the service enabler,

S E , whose role is to play as an intermediary between

US R and S P . US R will only need to open a chan-

nel with S E, without needing to open many channels

with different S P . In our mind, these service en-

ablers, SE , are seen as well-established, trusted com-

panies that have a reputation to preserve and might pe-

riodically be subject to audits. Our proposal relies on

their integrity to resist certain attacks that involve col-

lusion with US R (see below). Nonetheless, USR is

not required to place an absolute trust in SE as we en-

vision several competing service enablers, and US R

will be able to shift an identity document from one to

another.

We will see in this section that using such off-

chain transactions in an identity management scheme

is possible, preserving some (but not all) of the ad-

vantages and protections provided by the Bitcoin net-

work in (Augot et al., 2017a). For instance, as USR

can use different S E while keeping her identity, some

kind of decentralization is preserved.

US R will dedicate a “part” of her identity to

off-chain authentication by opening a payment chan-

nel with SE . Note that as this channel will serve

for authentication tokens and not real life payments,

all “payments” will be unidirectional, and there will

never be a need for US R to receive payments back

through this channel.

When the channel is opened, the authentication to-

ken (which again is also used for revocation by I P )

normally of the form MSIG1 2(a

(i)

USR

, a

I P

) becomes

P2SH(signed by 2 of 2 of a

(i)

USR

and a

S E

OR by a

I P

As such, this output can be spent by both USR

and S E together, but it can also be spent at any time

by I P revoking the identity and rendering what has

passed in the channel moot.

We now detail the sequence of transactions to

open, use, and close such channel while preserving

identity information. We begin with the last TX

REQUEST

that the user issued ((Augot et al., 2017a), see Sec-

tion 3).

REQUEST

(Fees: F

REQUEST

)

Input Address:

MSIG1 2(a

(i)

USR

, a

I P

)

for an Amount: V

Output Addresses:

MSIG1 2(a

(i)

USR

, a

I P

)

for an Amount: V−F

REQUEST

OP RETURN(“proof-ref”)

The user takes the authentication token output from

this address and uses it as the input to following trans-

action TX

OPEN

, which US R does not yet publish.

OPEN

(Fees: F

OPEN

)

Input Address:

MSIG1 2(a

(i)

USR

, a

I P

)

for an Amount: V−F

REQUEST

Output Addresses:

P2SH(signed by 2 of 2 of a

(i)

USR

and a

S E

OR a

I P

)

for an Amount:

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

516

V−F

REQUEST

− F

OPEN

OP RETURN(a

S E

formatting, other info)

Before publishing TX

OPEN

, US R creates a backout

transaction that spends the multisig output of TX

OPEN

back to herself (with a timelock), and has S E sign

this transaction. This way, if S E does not close the

channel, US R can close it and recover her input, by

signing and sending TX

BACKOUT

to the blockchain.

BACKOUT

(Timelock, Fees: F

BACKOUT

)

Input Address: P2SH(

signed by 2 of 2 of a

(i)

USR

and a

S E

OR by a

I P

)

for an Amount: V−F

REQUEST

− F

OPEN

Output Address:

MSIG1 2(a

(i)

USR

, a

I P

)

for an Amount: V−F

REQUEST

− F

OPEN

− F

BACKOUT

Thus, a payment channel from USR to S E has been

opened. When using her identity to obtain a service

from S P :

1. USR communicates to S E the identity of SP

2. S E asks S P what US R needs to prove about her

identity to use the service

3. USR makes a Brands proof interacting with S E

against the h

(i)

USR

provided in TX

PUBLISH

(see Sec-

tion 3) to prove the required property

4. USR issues to S E a transaction of the following

form:

USE-CHANNEL

(Fees: F

FIRST-USE

)

Input Address:

P2SH(signed by 2 of 2 of a

(i)

USR

and a

S E

, OR by a

I P

)

for an Amount: V−F

REQUEST

− F

OPEN

Output Addresses:

MSIG1 2(a

(i)

USR

, a

I P

)

for an Amount: V−F

REQUEST

− F

OPEN

−

FIRST-USE

OP RETURN(k) with k = 1

5. S E conﬁrms to S P that US R ’s identity has the

required property

6. Each time US R uses this channel to authenticate

to maybe another S P , a counter k is incremented.

At the k-th use of the channel, a transaction is is-

sued of the following form using the same UTXO

from the above TX

OPEN

USE-CHANNEL

(Fees: F

kth-USE

)

Input Address:

P2SH(signed by 2 of 2 of a

(i)

USR

and a

S E

OR by a

I P

)

for an Amount: V−F

REQUEST

− F

OPEN

Output Address:

MSIG1 2(a

(i)

USR

, a

I P

)

for : V−F

REQUEST

− F

OPEN

− F

kth-USE

OP RETURN(k)

Whenever S E wants to close the channel, he signs

and publishes TX

OPEN

and TX

USE-CHANNEL

, with the high-

est index k. S E can then spend the last P2SH out-

put. US R is then left with an authentication token

(marked in red in the above diagrams) that she can

use for future authentications which will be chained to

her usage history. In addition, if SE becomes hostile,

and does not close the channel, US R can recover her

funds using the TX

BACKOUT

transaction when the time-

lock is reached.

Any observer, such as a service provider, can

check the highest index k when the channel is closed,

and learn how many times US R used her identity

during the off-chain portion of the history. Further-

more, privacy is gained, since these observers can-

not see on-chain to which service providers US R au-

thenticated. This proposal thus requires a heavy de-

pendence on S E to conﬁrm to S P that the protocol

has been correctly executed, and to properly close the

channel with the highest k. This places this protocol

in the style of (Augot et al., 2017b), where a service

enabler plays a crucial role. But here the dependency

is lighter, since S E plays its role only in this off-chain

mode: USR also has the possibility to close the chan-

nel and use her identity purely on-chain, without de-

pending anymore on SE.

We have similar issues as in Section 4 concerning

the requirement that I P must have the script in the

P2SH output in order to be able to revoke an identity

after TX

OPEN

and before the channel is closed. Again,

with three 32-byte public keys the script is too big

for the 80 bytes limit of an OP RETURN. Thus, we

again include in the OP RETURN a

S E

and the format

of script with the other public keys removed as I P

already knows a

I P

and a

(i)

USR

While the channel is open, it is the responsibility

of S E to check that a user’s identity has not been re-

voked. In order to do this, SE must be capable of de-

termining that the P2SH transaction output in TX

OPEN

has not yet been spent. Thus, S E must be a full node.

This is consistent with the fact that, in the Lightning

Network in general the intermediaries need to be full

nodes (Gulbrandsen, 2016) to check for broadcasting

of obsolete transactions. Moreover, after the chan-

nel is closed, either by SE using with TX

OPEN

and

USE-CHANNEL

, or US R using TX

BACKOUT

, the authen-

tication token, which was on the channel

Practical Solutions to Save Bitcoins Applied to an Identity System Proposal

517

P2SH(signed by 2 of 2 of a

(i)

USR

and a

S E

OR by a

I P

)

becomes again MSIG1 2(a

(i)

USR

, a

I P

) and, back on the

blockchain, can be used either by USR who can re-

sume using her identity, or I P who can revoke it.

Trust is put into S E, in particular to properly per-

form the veriﬁcation of whether an identity is revoked

or not, and properly close channel with the highest in-

dex k. (Note USR will refuse to sign a TX

USE-CHANNEL

with a higher index that what is justiﬁed, so S E can-

not cheat US R out of uses.) Furthermore, a hos-

tile S E may collude with USR , and not publish the

OPEN

and TX

kth-USE

transactions TX

: US R can

then claim the reimbursement transaction from the

BACKOUT

after the timelock. This would allow a user

to continue using her identity as if the transactions

that took place off-chain had never happened. In the

Lightning Network, this would cost S E the money

that had been transacted on the channel; here, as the

amounts are mostly symbolic, this attack has a low

cost. This is similar to (Augot et al., 2017a) where ex-

ists the risk that S P might accept a user identity with-

out demanding a TX

REQUEST

. Thus, the trust model ser-

vice providers have towards a group of S E’s is sim-

ilar to how web browsers trust certiﬁcate authorities

in PKIs; the system is only as secure (against SE -

US R collusion) as the least trustworthy S E.

6 CONCLUSION

Taking back existing mechanisms to our advantage –

atomic swaps and off-chain payments – we have pre-

sented two methods to reduce the costs of the pro-

posal of (Augot et al., 2017a) to the point of render-

ing it ﬁnancially viable while nonetheless preserving

its advantages in terms of ﬂexible user experience and

identity provider controls, particularly for revocation,

which can only be violated by an attacker capable of

committing Bitcoin double spending attacks. We be-

lieve that our ideas can be reused in other contexts.

REFERENCES

Abiteboul, S., Andr

e, B., and Kaplan, D. (2015). Managing

your digital life. Commun. ACM, 58(5):32–35.

Antonopoulos, A. M. (2015). Mastering Bitcoin. O’Reilly

Media, Sebastopol, California.

Augot, D., Chabanne, H., Chenevier, T., George, W., and

Lambert, L. (2017a). A user-centric system for veri-

ﬁed identities on the bitcoin blockchain. In Data Pri-

vacy Management, Cryptocurrencies and Blockchain

Technology - ESORICS 2017 International Workshop,

CBT 2017, pages 390–407.

Augot, D., Chabanne, H., Cl

emot, O., and George, W.

(2017b). Transforming face-to-face identity proof-

ing into anonymous digital identity using the Bit-

coin blockchain. In PST2017 - International Con-

ference on Privacy, Security and Trust. See also

arxiv.org/abs/1710.02951.

Brands, S. (2000). Rethinking Public Key Infrastructures

and Digital Certiﬁcates (Building in Privacy). MIT

Press, Cambridge, MA, USA.

Dunphy, P. and Petitcolas, F. A. P. (2018). A ﬁrst look

at identity management schemes on the blockchain.

CoRR, abs/1801.03294.

Garman, C., Green, M., and Miers, I. (2016). Account-

able privacy for decentralized anonymous payments.

In Financial Cryptography and Data Security - 20th

International Conference, FC 2016, pages 81–98.

Gulbrandsen, A. (2016). Bitcoin Lightning Network FAQ.

Online, https://medium.com/@AudunGulbrands1/

lightning-faq-67bd2b957d70.

Jacobovitz, O. (2016). Blockchain for identity manage-

ment. Technical Report 16-02, Lynne and William

Frankel Center for Computer Science (Ben Gurion

University). https://www.cs.bgu.ac.il/%7Efrankel/

TechnicalReports/2016/16-02.pdf.

Joseph Poon and Thaddeus Dryja (2016). The Bitcoin

Lightning Network: Scalable off-chain instant pay-

ments. Online, https://lightning.network/lightning-

network-paper.pdf.

Lundkvist, C., Heck, R., Torstensson, J., Mitton, Z.,

and Sena, M. (2017). uPort: A platform for self-

sovereign identity. https://whitepaper.uport.me/uPort

whitepaper DRAFT20170221.pdf.

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic

cash system. Online, http://bitcoin.org/bitcoin.pdf.

Nazar

e, J., Hamilton, K., and Schmidt, P. (2016). Dig-

ital certiﬁcates project. online, source code avail-

able at https://github.com/digital-certiﬁcates. http:

//certiﬁcates.media.mit.edu.

Prisco, G. (2015). Estonian government partnerts with

bitnation to offer blockchain notarization services

to e-residents. https://bitcoinmagazine.com/articles/

estonian-government-partners-with-bitnation-

to-offer-blockchain-notarization-services-to-e-

residents-1448915243/.

Tobin, A., Reed, D., and Windley, P. J. (2016). The

inevitable rise of self-sovereign identity. On-

line, https://sovrin.org/wp-content/uploads/2017/07/

The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf.

Yang, D., Gavigan, J., and Wilcox-O’Hearn, Z. (2016).

Survey of conﬁdentiality and privacy preserving tech-

nologies for blockchains. https://z.cash/static/R3

Conﬁdentiality and Privacy Report.pdf.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

518