US20190172026A1
US20190172026A1
- 700
702
IDENTIFYING A SET OF THE ONE OR MORE
TOKENS FROM A FIRST BLOCK CHAIN
704
LOCKING THE IDENTIFIED SET OF THE ONE
OR MORE TOKENS OF THE FIRST BLOCK CHAIN
100
ETHRUM 106
ETHREUMWALET
118 124
-
108
-
102
(
112
,
102b
DBTCTOKENS
+
NIEUWB19 11 IREIEN
122
VALIDTORN
WDAELUEGT BTCTOKENS 128 BTCLOCKED(P2SHADDR) 1
.
FIG
NTSBCRLEAOKWUSHIRNE CSOMNTARC 102a 114
1
116 1VALIDATOR
110
-
104
BITCOIN -
BITCOINWAL ET
IMPORTING )
DBTC
TO
BTC
(
EXPORTING )
BTC
TO
DBTC
(
Patent Application Publication Jun . 6 , 2019 Sheet 2 of 9 US 2019 /0172026 A1
240
ONTHE"BMITNCOTISN"TEOHKERNUSM (BOE)
CSOMNTARC 238
.'SVTHETRALNSIACTIOYNFEE.ATPRANSAICTDON
VACUEGSRTOINDFAYSL
232
-
2A
.
FIG
ACUGSTEODNIATLSEIRDVER CUSTODIALAGENTS 2B
.
FIG
BUINTCQOUIENAD RES INUBTCISVESRIUFAIELDPBLROCKEHASIN
S
'
USER
TO
BOE
SENDS
230
USERSENDSBITCOIN
236
BDEISTCNO ADRES
W-FCALIENTG BTC CSOMNTARCT BOE
Patent Application Publication Jun . 6 , 2019 Sheet 3 of 9 US 2019 /0172026 A1
330
IMPORT 328
- 332
-
DWAELUEGTDBTCAVILBE
300
CTONKREACNT DMBITNC
334
BTC?
TIMELOCKFORWAIT
-
-
RELASE 320
-
NOTIFY USER
324
-
VALIDTE ?\APROVED
TY
-
VERIFY Tx2
&
Tx1
322
3
.
FIG
|
316
318
7 WAIT
6
BLOCKS
306
314
-
BTCRELAY CONTRAC DPE2OSIHTPAYTOSCRIPT )TX
P2SH
(
HASH IDCREATE
312
(
BTCTODBTC
BTC RELAY
) Tx IDCREATE
BTCSEND)(ADDR,AMOUNT
PCRIEVATE D
W E
A LU GE
T
KEY BTCADDR+ETHAD R HASHPAYTOPUBKEY
(
PSPKH 310
(
304 308
Patent Application Publication Jun . 6 , 2019 Sheet 4 of 9 US 2019 /0172026 A1
EXPORT 426
-
400
- 428
D EL U G EW A L E T RMEIFUNTD DBTCONFAIL NOTIFYUSER
418
-
CONTRACT
N
OF
-
M
422 +
7
BTC
,SIGNONEXPORTID
CSOMNTARC EMULTIS GXVPNEORDT WITHID DELUGEWAL ETBEXPTORCED AVILBE CLAIMER
416 420
?RECOVERY
TX
RAW
SIGNATURES RED EMSCRIPT
-
424
UNK OWN
4
4
.
FIG
RAFT 1 1 1 1 III
?LEADER RAFT
VALIDTE
IIIIIIIII 1 1 1 Itt
Lit 11 11E
ELOGVENTUTXOTORAFTTXESXTPAORT
RAFT
UTXOS SYNC
"
DELUGEWAL ETRMEIFNUTDDBTCONFAIL
BTC
TO
DBTC
WDAELUEGT SDTEBNCD)(TXAMOUNT CTONKREACNT BTOUKRENLOGEVENT
402 404 406 410
408
Patent Application Publication Jun . 6 , 2019 Sheet 5 of 9 US 2019 /0172026 A1
500
512
BITCOND
510
BTCsend allvalidators
SMART CONTRA S 516
- 520
-
TXS
verify
DmBiTnCt 522 xportID)
e,
(
Sig signature 530b)signatur)
eEnxdpEoxrptoirdt
(
504
-
DBuTrCn 524 530a
exportID
(
Sig
,
WAL ET
502
-
.
BTC
/
w
deluge
fund
BTC
i
514 )
m p o r t 518 Ecxaplort 524a
TXConstruct from signatures
USER
Patent Application Publication Jun . 6 , 2019 Sheet 6 of 9 US 2019 /0172026 A1
600
Raft Node Implementation
for Validation
CFSM2002
FSM
602a
FSM
606a
LEADER
FIG . 6
Patent Application Publication Jun . 6 , 2019 Sheet 7 of 9 US 2019 /0172026 A1
700
FIG . 7
Patent Application Publication Jun . 6 , 2019 Sheet 8 of 9 US 2019 /0172026 A1
800
D10EVICE808S
LCOMPUTGAIONCL
822
810
.ICNTOERMFACES 8
.
FIG
MEORY 804
812
LCOMPUTGAIONCL 822
P(RS)OCES OR
802
SMTAORSGE
806
Patent Application Publication Jun . 6 , 2019 Sheet 9 of 9 US 2019 /0172026 A1
900
902
PROGRAMMING INSTRUCTIONS
TO CAUSE A COMPUTER PLATFORM , IN RESPONSE TO EXECUTION OF THE
INSTRUCTIONS BY A PROCESSOR OF THE COMPUTER PLATFORM , TO PRACTICE
ASPECTS OF EMBODIMENTS OF THE PROCESSES OF FIGS. 1 -7
FIG . 9
US 2019 /0172026 A1 Jun. 6 , 2019
richer solutions without rendering existing solutions irrel [0025 ] Embodiments described herein describe two
evant, resulting in a simplified , yet integrated user experi actions: ( 1 ) importing a token from BTC to DBTC and ( 2 )
ence . exporting a token from DBTC back to BTC . As used in
[ 0021] In embodiments , the decentralized transfer of cryp examples herein , DBTC is an Ethereum - resident bitcoin
tocurrencies from one blockchain to another and /or synchro proxy token that mirrors its BTC value , thus allowing users
nization of transactions across blockchains may be referred to navigate the vast ERC20 ecosystem with the confidence
to as a cross-blockchain secure transactions network . Syn that their DBTC can be directly converted back to BTC on
chronization of transactions across blockchains may also be a 1: 1 basis ( or any other basis ) at any time . In some
referred to herein as a “ transfer” , though no cryptographic embodiments , the transaction may incur applicable network
asset may actually be transferred , via replication or other usage and transaction fees .
wise , from a first blockchain to a second blockchain . The [0026 ] In embodiments , importing is the process of lock
cross - blockchain secure transactions network may also be ing BTC in return for generating (or minting) DBTC in place
referred to as Deluge NetworkTM . In embodiments , the of the locked BTC . In embodiments , locking BTC includes
cross- blockchain secure transactions network focuses on securing one or more BTC to an address so that the BTC
transferring assets from and / or synchronizing transactions may not be retrieved , unlocked , or otherwise used unless
between the Bitcoin and Bitcoin derived blockchains to the approved by a majority of a group of validator systems.
Ethereum blockchain . Other embodiments may bridge to Exporting is the process of burning ( e . g., destroying) DBTC
other blockchains. A cross -blockchain secure transactions as it is returned for a BTC .
network achieves cross -chain interoperability by, for [0027 ] Several foundational principles may underpin
example , by transferring and/or synchronizing behavior of a embodiments described herein : ( 1) speed , usability , reliabil
Bitcoin token (BTC ) with behavior of a corresponding ity , and security of the cross blockchain secure transfer
ERC20 token on the Ethereum blockchain (which may be network ; (2 ) the characteristic that users maintain control of
referred to as a DBTC or Bitcoin on Ethereum (BOE )). This the transaction process , in that every transaction and net
cross block chain interoperability may enable users to spend work transmission is initiated by the user; (3 ) corresponding
freely on the Ethereum blockchain , without assuming the Ethereum and Bitcoin addresses are derived using the
risk of using centralized exchanges , paying steep fees, or secp256k1 ECDSA ( Elliptic Curve Digital Signature Algo
completely moving their assets or tokens to another block rithm ) public key (transactions are only validated and
chain ecosystem altogether. executed if the addresses correspond to the same private key
claiming the exchange of funds); and ( 4 ) the blockchain ' s
[0022] In embodiments , the cross-blockchain secure trans number of recommended transaction confirmations is
actions network may liberate Bitcoin by empowering it to observed for finality of transaction . Public keys and private
move as if it is available natively on the Ethereum block keys are a part of asymmetric cryptography, also known as
chain , while mirroring its BTC value and enabling bidirec public key cryptography, that uses public and private keys to
tional transfer of token and other assets . The cross - block encrypt and decrypt data . One key in the pair can be shared
chain secure transactions network will deliver a seamless with everyone ; it is called the public key. The other key in
cross - chain implementation on top of the original block
chain implementation , built on the stability and security the pair is kept secret; it is called the private key .
strengths of both Bitcoin and Ethereum protocols . For [0028 ] The cross- blockchain secure transactions network
example , the strengths may include : ( 1) using the scripting wallet, or Deluge wallet, may function as the user ' s point of
properties of Bitcoin and the smart contract properties of entry for the cross -blockchain secure transactions network .
Ethereum ; ( 2 ) building on the security of the Bitcoin and An advantage of the Deluge wallet may be a seamless and
Ethereum blockchains , following the Proof of Work ( PoW ) intuitive user experience for making cross - chain transac
consensus algorithms of the protocol for transaction valida tions while the process remains solely user- controlled and
tion and conflict resolution ; ( 3 ) using the stack -based script decentralized . With the Deluge wallet, users can indepen
ing language of Bitcoin to satisfy complex redemption dently manage transfers and exchanges of their Bitcoin and
conditions for Pay to Script Hash (P2SH ) transactions; (4 ) Ethereum cryptocurrencies and intuitively engage in the
using cryptographic properties to securely pair a BTC and cross -blockchains secure transactions network Import/Ex
Ethereum address and smart contract properties of Ethereum port processes.
for verifying corresponding bitcoin and Ethereum addresses [00291. In embodiments , the cross -blockchain secure trans
or generating log events to trigger off -chain actions. action network including a plurality of validators provides a
2 -way pegging between BTC and DBTC . As discussed
[0023 ] By bridging the Bitcoin and Ethereum blockchain above, DBTC may be a ERC20 compatible token for the
networks , and ultimately bridging an array of blockchains , Ethereum network . Characteristics of the token transfer may
the cross -blockchain secure transactions network embodi include : ( 1 ) users are always in control every transaction
ments described herein may become an important part of request is initiated by the user; ( 2 ) the user who submits the
rapid , decentralized asset transfer and an extensible foun initial transaction request may be the only user who can
dation for the crypto asset trading ecosystem while remain receive the output of the transaction - transactions are only
ing free of the encumbrances so commonly associated with valid if the addresses correspond to the same private key
cross -chain interoperability. claiming the swap ; (3 ) validators never submit transactions ,
10024 ] It should be noted that these are examples of two they independently construct the transaction and publish
block chains and assets that may reside within those block their signature to the Ethereum blockchain (however, user
chains. In embodiments , any two block chains and assets and the user 's wallet may be responsible for submitting the
residing in these block chains may be exchanged and/or claim request ); and (4 ) Bitcoin protocol is used for the
otherwise transacted using one or more of the embodiments escrow of the funds to P2SH address , which requires a
described herein . majority of the validator keys to unlock .
US 2019 /0172026 A1 Jun. 6 , 2019
[0030 ] In embodiments, the Deluge wallet is a software (0037] The cross -blockchain secure transaction network is
wallet that is controlled by the user. The user runs the wallet a conduit to programmable tokenized Bitcoin on Ethereum
software on the user ' s own computer and the wallet, gen as an ERC20 token DBTC , while mirroring its BTC value.
erates keys, and stores them for the user ' s use . As such , the In embodiments , as discussed above , BTC and DBTC may
user bears the risk of losing keys and control of access to be pegged at 1: 1.
funds . Deluge wallet is a digital file that makes it simple to [0038 ] In the following detailed description , reference is
access addresses and keys that a user owns. In embodiments , made to the accompanying drawings which form a part
if access to the wallet is lost, the contents cannot be hereof wherein like numerals designate like parts through
recovered . out, and in which is shown by way of illustration embodi
[0031] Deluge wallet handles multi - signature (multisig ) ments thatmay be practiced . It is to be understood that other
transactions . Multisig transactions create challenges to pro embodiments may be utilized and structural or logical
tect transaction security , where a minimum of M keys are changes may be made without departing from the scope of
required out of a total of N keys overall to meet the challenge the present disclosure . Therefore , the following detailed
( M -of- N keys ). If the challenge is met, locked bitcoins may description is not to be taken in a limiting sense , and the
then be unlocked , for example during a DBTC export where scope of embodiments is defined by the appended claims
DBTC tokens are exchanged for BTC . The cross-blockchain and their equivalents .
secure transaction network requires multisig for releasing [0039 ] Aspects of the disclosure are disclosed in the
the funds , where the keys are validator keys associated with accompanying description . Alternate embodiments of the
a plurality of validator machines . During and export trans present disclosure and their equivalents may be devised
action , Deluge wallet constructs the multisig transaction without parting from the spirit or scope of the present
values from Ethereum network logs and smart contracts . For disclosure . It should be noted that like elements disclosed
the multisig transaction , the signatures and transaction below are indicated by like reference numbers in the draw
details are constructed by the validator ' s and stored in the ings .
Deluge contract or Ethereum logs. 10040 ] Various operations may be described as multiple
0032] In embodiments, the cross -blockchain secure trans discrete actions or operations in turn , in a manner that is
action network uses multisig bitcoin security for locking most helpful in understanding the claimed subject matter.
Bitcoins . The Bitcoins are sent to a P2SH address by the user However, the order of description should notbe construed as
via the wallet interactions. The P2SH address for locking to imply that these operations are necessarily order depen
Bitcoins is stored in a smart contract and retrieved by the dent. In particular, these operations may not be performed in
Deluge wallet during import (sending BTC for DBTC ). An the order of presentation. Operations described may be
unlock process used to claim BTC requires M - of- N signa performed in a different order than the described embodi
tures from the plurality of independent validators . ment. Various additional operations may be performed and /
[0033] In embodiments , the cross -blockchain secure trans or described operations may be omitted in additional
action network uses a standard multisig bitcoin transaction embodiments .
protocol. Transactions are initiated by the user, orchestrated [0041] For the purposes of the present disclosure, the
via the blockchain , and are only valid if majority of the phrase “ A and/ or B ” means ( A ), (B ), or ( A and B ). For the
independent validator ' s agree . purposes of the present disclosure , the phrase " A , B , and /or
[ 0034 ] During importing (sending BTC for DBTC ), user C ” means (A ), (B ), (C ), ( A and B ), ( A and C ), (B and C ), or
sends the user 's Bitcoins to a P2SH address specified by a ( A , B and C ).
smart contract. The Bitcoins are then locked at this address [0042] The description may use the phrases “ in an
until a future time when a user requests an export ( sending embodiment,” or “ in embodiments ,” which may each refer
DBTC for BTC ). During export, the validator ' s indepen to one or more of the same or different embodiments.
dently construct and sign (with their respective private keys ) Furthermore , the terms " comprising ,” “ including,” “ hav
the raw bitcoin transaction and post the signature to the ing,” and the like , as used with respect to embodiments of
smart contract or Ethereum logs . When enough M - of- N the present disclosure, are synonymous.
signatures from the validator 's are posted , the smart contract [0043] As used herein , the term “module” or “ engine ”
generates an Ethereum event (e .g ., log message ) notifying may refer to , be part of, or include an Application Specific
the wallet. The user, via the wallet, will retrieve the validator Integrated Circuit (ASIC ), a System on a Chip (SOC ), an
signatures, transaction metadata , and a “ Redeemscript" from electronic circuit, a processor (shared , dedicated , or group)
the smart contract. “Redeemscript " is a list of validator and / or memory ( shared , dedicated , or group that execute
public keys required to verify that the transaction was signed one or more software or firmware programs, a combinational
by M -of-N validators. logic circuit, and / or other suitable components that provide
[0035 ] When a user sends BTC contributions to multisig , the described functionality .
P2SH , address , the Bitcoins are locked with M -of- N ( such as [0044 ] FIG . 1 is an example context diagram of a system
2 -of-3 ) multisig challenge statement, where the keys are to facilitate cross blockchain secure token transactions, in
retained by the validator machines . In embodiments, if a accordance with various embodiments. Diagram 100 shows
validator is compromised or key management is required , a Deluge wallet 102 that may receive BTC from or send
the remaining validator' s can move the Bitcoins to a new BTC to a Bitcoin wallet 104 of a user, and may receive
P2SH address (assuming there are enough uncompromised Ethereum tokens from or send Ethereum tokens to an
keys ). In embodiments, this may also be implemented as an Ethereum wallet 106 of the user.
off-chain process . [0045 ] In embodiments, if the user wishes to use the
100361. In embodiments , validators will be employed based cross -blockchain secure transactions network to transition
on brand reputation and interest in the cross -blockchain from BTC tokens to the ERC20 compatible tokens, the user
secure transactions network . installs the Deluge wallet 102. The operation of the Deluge
US 2019 /0172026 A1 Jun. 6 , 2019
wallet 102 may be performed or facilitated by one or more verifications on the Ethereum block chain . In embodiments ,
smart contracts 108 that may operate within the Ethereum BTC Relay , as an Ethereum smart contract, is able to address
blockchain environment . The Deluge wallet 102 may cross -chain interoperability , such as token transactions ,
include a BTC repository 102a for the user 's BTC and a between Bitcoin and Ethereum by using the series of trans
DBTC repository 102b for the user's DBTC . The Deluge actions and validations across the Bitcoin and Ethereum
wallet 102 may include other information as discussed in blockchains . Because Bitcoin cannot verify information
more detail below . from other blockchains, an important step in the transition
[0046 ] In embodiments, when a user wishes to initiate a process is the parallel communication and verification across
transaction , the Deluge wallet 102 creates BTC and the disparate blockchains. BTC Relay facilitates this by
Ethereum (or ERC20 compliant) address pairs that corre functioning as an Ethereum smart contract that enables a
spond to a same public key , and stores it. If a user wishes to trust - free means of certifying that a Bitcoin transaction took
import tokens ( eg . convert and / or synchronize BTC and place . The cross- blockchain secure transactions network
DBTC ), the user may perform a BTC transfer 110 from the utilizes BTC Relay to verify that the given transaction is
Bitcoin wallet 104 to the BTC repository 102a , and initiate recorded on the Bitcoin network .
an import transaction . In embodiments, the import transac [0052] In embodiments, BTC Relay uses Bitcoin 's block
tion may be initiated upon the BTC transfer 110 . In embodi header to create a miniature version of the Bitcoin block
ments, the Deluge wallet will newly mint DBTC and initiate chain implementing Bitcoin Simplified Payment Verifica
a DBTC transfer 112 to the DBTC repository 102 based tion (SPV ) . A BTC Relay smart contract stores the block
upon the BTC within the BTC repository 102a . Prior to headers and uses the underlying Merkle Root, to verify
newly minting the DBTC , an associated number ofBTC will transactions, enabling other smart contracts to verify that the
be transferred 114 into a locked BTC 116 state within a given Bitcoin transaction has been confirmed sufficiently on
multisig address . Once the newly minted DBTC is in the the Bitcoin blockchain . A Merkle Root, is the hash of all the
DBTC repository 102 , the user may perform a DBTC hashes of all the transactions that are part of a block in a
transfer 118 to transfer the ERC20 compliant tokens to the blockchain and serves to encode blockchain data more
user ' s Ethereum wallet 106 to allow transactions to take efficiently and securely.
place on the Ethereum blockchain . In embodiments , the 10053 ] In embodiments, if the user wishes to use the
amount of DBTC minted may be equivalent to the original cross -blockchain secure transactions network to transition
amount of BTC transferred by the user. In other embodi from DBTC used on the Ethereum blockchain to BTC
ments, transaction fees, for example fees incurred during the tokens on the Bitcoin block chain , the user may perform a
validation process as described above , may result in a transfer 120 from the Ethereum wallet 106 to the DBTC
reduced amount of DBTC minted . repository 102b . For example, the user may wish to syn
[ 0047 In embodiments , prior to the DBTC transfer 118 , a chronize tokens between and / or return tokens from the
number of verifications may occur. For example, the user 's Ethereum ERC20 ecosystem and the Bitcoin blockchain ,
BTC transfer 110 to the Deluge wallet 102 and the user 's and convert DBTC back into an equivalent amount of BTC
ownership of the transferred BTC are to be verified , as well by initiating a cross - blockchain secure transaction export
as the locked BTC 116 associated within the multisig transaction .
address. In addition , an Ethereum address generated during 10054 ) In embodiments , the export transaction may create
minting must be verified as produced by the public key that a BTC and Ethereum address pair that corresponds to the
matches a pay to public key hash (P2PKH ) address that same public key, and send DBTC to the repository 102b . A
initiated the multisig transfer. smart contract 108 may be initiated via the Deluge wallet
[0048 ] When and import is triggered by the user, smart 102 to signal a burn (destruction of the DBTC tokens and
contract 108 provides a locked Bitcoin address for the funds to record the burn event on an Ethereum log. In embodi
interchange. This locked Bitcoin address is a P2SH payment ments, this may signal the burn event 122 to a plurality of
address that may require , for example , 80 % of the validators validators 124 .
cooperation before the BTC funds can be released . [0055] In embodiments , the validators 124 may listen for
[0049 ] To verify that the user transferred the BTC , the burn events and trigger the export process upon observing
cross -blockchain secure transaction network may use a the DBTC burn . When the validators 124 observe the DBTC
P2PKH bitcoin address . The smart contract 108 may check burn event, for example on the Ethereum log, and upon
that at least one of the transaction inputs to P2SH is execution of the burn , each validator creates a bitcoin
originated from the user ' s transaction output, thus verifying transaction with the appropriate amount of BTC owed to the
that the user owns the bitcoin that was locked . user consisting of the unspent output from bitcoin transac
[0050 ] BTC Relay , which is an Ethereum smart contract tions (UTXO ) that sent BTC 116 to the multisig address . The
that may communicate with the Bitcoin blockchain , may be validators 124 then send their signature 126 to a smart
used to verify both that user' s BTC contributions are con contract .
firmed to the created BTC address and that the user' s [0056 ] In embodiments , throughout this process , a major
Bitcoins are locked to the P2SH . The BTC Relay is repre ity of validators are required to sign the transaction before
sented by the smart contract 108 of FIG . 1. The smart any BTC can be released to the user' s Deluge wallet 102, in
contract is a decentralized entity , working as a conduit order to prevent mishandling of funds, as described in the
between user requests submitted to the cross -blockchain Validators and Consensus section below .
secure transaction network via wallet and independent vali [0057 ] Finally , the Delugewallet 102 awaits the log events
dator machines . on the blockchain to collect the signatures , construct the
[0051] In embodiments, to perform the verification as Bitcoin transaction , and submits it to the bitcoin blockchain .
described above , a BTC Relay , which may be implemented The user then receives the corresponding BTC amount 128
as a smart contract 108 , may be used to perform the into the Deluge wallet 102 ( less any transaction and mining
US 2019 /0172026 A1 Jun. 6 , 2019
fees incurred during the validation process described above ), for efficient UTXO selection . As discussed above, when a
and the export process is complete . The user may then user requests to export DBTC to BTC , validators 124
transfer BTC 130 to the user' s Bitcoin wallet 104 . In this consensus is responsible forUTXO selection to release BTC
way , in embodiments , behavior of BTC and DBTC may be from the selected UTXOs to the party who exported the
synchronized between the bitcoin and Ethereum block DBTC to BTC .
chains , such that BTC that is transferred to the Ethereum [0064 ] In embodiments, a Raft- based protocol for distrib
blockchain and results in minting of DBTC in the import uted consensus in tracking UTXOs for the given P2SH
process may not be used until such timeas a corresponding addresses may be used . This may ensure that there is an
amount of DBTC is burned in the export process , at which agreed upon pool ofUTXOs for selection at any given time.
time the BTC may then be released to the party who burned [0065 ] In embodiments , in addition to any necessary third
the DBTC . party mining and gas fees ( fees paid to miners for creating
[0058 ] As mentioned above , a robust and distributed net the blocks that make up the blocks on the respective block
work of third -party validators 124 are used to evaluate and chains ) paid to the Bitcoin and Ethereum networks during
come to consensus on the validity of cross -blockchain the user 's transaction processes, the cross -blockchain secure
secure transactions by joining together in consensus proto transaction network may collect a transaction fee , ( e . g .
cols and cryptographically signing valid transactions. In 0 .7 % ) for importing from BTC to DBTC and /or for export
embodiments , Validators 124 play a key role in monitoring ing from DBTC to BTC . In embodiments, all transaction
and approving the DBTC -to -BTC interchange requests and fees may be collected in DBTC , or other networked -backed
maintaining the 1 : 1 BTC - to -DBTC relationship . In order to tokens , and put into a transaction reward pool as incentives
achieve consensus, in embodiments, 80 % of Validators must for users of the system and validators as described further
approve DBTC burns and sign DBTC to BTC transaction with respect to FIG . 6 . The users of the system may be
requests for the cross -blockchain secure transactions net referred to as transactors .
work . [0066 ] Cross -blockchain secure transaction network users
[0059 ] In embodiments, validators 124 may be used to and validators may access the reward pool via D - Tokens and
safeguard the transaction process based on brand reputation the D - Token smart contract. D - Tokens may be both given to
and experience . Validators 124 are to conform to rigorous the Validators as compensation for confirmation of network
operational criteria , including: (1 ) high availability and transactions based on their negotiated contract and may be
uptime; (2 ) expediency with verifications and signatures ; (3 ) awarded to users based on the number of transactions made
secure server and validator key management; and (4 ) they and transaction volume. D -tokens may be burned when the
must self-deploy and /or run the required version of the holder of D - Token withdraws the prorated amount of DBTC
validator service , among other necessary services. in exchange .
10060 ] Validators 124 responsibilities include: ( 1 ) key [0067 ] FIGS . 2A - 2B are example flow diagrams illustrat
management and safekeeping of P2SH addresses; ( 2 ) run ing, respectively, methods for exporting and importing
ning Raft consensus nodes for tracking UTXOs, where Raft tokens between a Bitcoin blockchain and an Ethereum
is a protocol with which a cluster of nodes can maintain a blockchain , in accordance with various embodiments . As
replicated state machine the state machine is kept in sync discussed above , in legacy implementations Bitcoin are not
through the use of a replicated log; (3 ) confirmation of useable on the Ethereum blockchain ; to do so requires using
DBTC burns during the export process and independent a third - party trading desk to trade bitcoin tokens, BTC , for
construction of the BTC transaction script used to spend the Ethereum tokens, ETH . To allow the value ofa Bitcoin to be
desired amount from the DBTC burn ; and ( 4 ) calculating the traded on the Ethereum network , BTC transactions may be
signature and publishing it to the Ethereum blockchain . Raft synchronized with transactions on the Ethereum network ,
is a distributed consensus algorithm to solve the problem of and vice versa . This would create a BTC -backed token on
getting multiple servers to agree on a shared state , ( e . g . Ethereum , which may be also referred to as Bitcoin on
available UTXOs) even in the case of individual server Ethereum (BOE ), also known as “ Bitcoin Tether,” “ BTCT,"
failures . An advantage of consensus algorithms is that they or “ DBTC .”
greatly facilitate reliable distributed systems that can survive 10068 ]. FIG . 2A shows an example flow diagram to convert
failures of some of its members. BTC into BOE tokens. BTC may be sent from a user 's wallet
[ 0061] Efficient and reliable tracking of UTXOs may be 230 , which may be similar to wallet 104 of FIG . 1 , to a
required for accurate UTXO selection and constructing BTC unique Bitcoin address 232 . In embodiments , that may
transactions . Validators 124 may be responsible for tracking trigger minting of ERC223 tokens, for example BOE . In
the available UTXOs using a Raft-based consensus algo other embodiments, the presence of the BTC in the address
rithm (described below with respect to FIG . 6 ) to achieve may trigger a smart contract 234 to mint the BOE . In
multi- system consensus on the availability of the given embodiments one BTC may equal one BOE . BOE may
UTXO . convert back to BTC as shown in FIG . 2B (described below )
[0062 ] With respect to UTXO , Bitcoin transactions are during export from BOE to BTC .
composed of inputs and outputs , and a bitcoin address [0069 ] In embodiments for converting BTC to BOE, a
balance may be the sum of all values of UTXO associated BTC token may be burned (destroyed ), or in other embodi
with a given address . For example , when a user requests a ments may be locked , for example , by sending by BTC relay
transaction to " send X bitcoins to address Y ,” the Deluge the BTC token to a particular address thatmay never be used
wallet 102 is to select one or more UTXOs with an aggregate as a source address . In embodiments, proof of ownership of
value greater- than or equal to the target value plus mining the BTC may be provided , for example , by taking a Bitcoin
fees . private key and turning it into an Ethereum address . In
10063] Validators 124 have the responsibility of tracking embodiments , a hash table may be created for mapping so
the available UTXO addresses and executing an algorithm this needs to only be done once . If the BTC goes to the
US 2019 /0172026 A1 Jun. 6 , 2019
correct address, an amount of BTCT may be minted on the control the burn address. Custodial agents or miners may
Ethereum blockchain by Smart Contract 234 that is equal to subscribe to events or otherwise call out all transactions that
the amount of BTC . In this way , a foundation may be created need to be signed . Verifications can be made to determine if
to issue proof of ownership for security and to put a user 's custodial agents or miners can counter -sign based on set
mind at ease . rules . If they can countersign , the transaction is sent out to
[ 0070 ] The Smart contract 234 on the Ethereum block the Bitcoin network .
chain issues Contract Tokens (CT) and/ or BOE /BTCT [0077 ] Embodiments of the processes shown in FIGS.
tokens , may obtain , confirm , or prove that Bitcoin was sent 2A - 2B may use the same hash to convert a Bitcoin address
to be converted to BOE /BTCT. The Smart Contract 234 may to Ethereum and vice - versa , so no additional information
contain ERC20 functions and specification , such as transfer, may be needed from a user .
as well as ERC223 specification . The Smart Contractmay be [0078 ] In legacy approaches in which BTC and ETH are
able to determine which Bitcoin addresses are approved . The exchanged , by the time a block is mined to confirm the
Smart Contractmay include a burner, for example , a burner transaction , the exchange rate between BTC & ETH has
(to turn DBTC back into Bitcoin ). The Smart Contract may often changed . Customers , as a result, end up getting less
require gas . Gas may be provided by BOE/BTCT, ETH , or than what they were promised at the time of the transaction
the like. and may feel cheated . Converting ETH or any other ERC20
[0071 ] The Smart Contract may comprise an import func token to BTCT, in contrast , may be relatively quick . Since
tion to turn a Bitcoin private key into an Ethereum public BTCT would be tethered to the cost of BTC , this problem of
key . The import function may use , for example , BTC Relay . price spikes and slow transfer rate would not occur.
The import function may verify the Bitcoin transaction and [0079 ] In embodiments statistics about BTCT & BTC
relay the transaction to the Ethereum Smart Contract . The transfers may be displayed to users along with a changing
import function may have a function input comprising the BTC address . This may also include a list of custodial agents
Bitcoin transaction wherein the Bitcoin was sent to the or miners , their status , and how to contact them . It may also
unique Bitcoin address . The import function may have a show the current transaction times to align with customer
functional output that associated the Ethereum public key expectations.
with the received Bitcoin transaction . 10080 ] There may be a Bitcoin wallet software that can
10072 ] The import function may work only once per create an Ethereum address and make programmatic calls on
transaction. A mapped hash table may track all transactions . the Ethereum block chain . This software may be able to talk
BOE may be exchanged for ETH . to Bitcoin and Ethereum using the same private key . In
10073 ] FIG . 2B shows an example flow diagram to convert embodiments , for any Bitcoin address, the wallet may
BOE into BTC . In embodiments , during export from BOE to generate an Ethereum public key . When Bitcoin is sent to the
BTC , an Ethereum smart contract 236 may generate a particular address that may be locked ( or in embodiments
transaction on the Ethereum network , which may be verified may never be used as source address ), the Bitcoin may then
and signed by custodial agents 238 . The custodial agents 238 be converted to BOE . The BOE may be sent to Ethereum
may also be referred to as proof-of- stake or proof-of wallet. The wallet may then be able to make function calls
ownership miners or as “ Miners .” Once verified , the trans on Ethereum , for example via the web3.js library .
action is written to the Bitcoin block chain and the user has [0081 ] In embodiments , custodial agents orminers may be
Bitcoin placed back in his wallet 240 . able to log in to see a listing of their pending transaction
[ 0074 ] Transaction fees of the custodial agents 238, min confirmations. In embodiments, they could be given appli
ers and /or the smart contract (s ) may be paid , for example , in cation programming interfaces (APIs ) to automate their
contract tokens (CT) and /or paid in BOE and distributed to confirmation process . In embodiments, there may be a
CT, which may be held by custodial agents 238 or miners. peer-to -peer (P2P ) network where custodial agents or miners
Transaction fees may be distributed as , for example , divi can interact with each other securely and trade among
dends among CT holders. In the course of verifying trans themselves.
actions or separately, miners may mine a cryptocurrency [0082] Export function for turning BOE back to Bitcoin .
such as CT and / or BOE . Cryptocurrency mined by miners The export function may have a functional input comprising
may be sold or conveyed , such as to parties desiring to a BOE amount (which may be, for example, a BOE token or
perform transactions on or relating to BOE . token amount to transfer plus fees ), a destination Bitcoin
[0075 ] A similar system may be created to work with address , and a hash of a pre - image of the BOE before it is
BitCash® or other cryptocurrencies . In embodiments , the burned that proves identification . The export function may
system may be started without an initial coin offering ( ICO ) . include functional outputs comprising Ethereum events
Contract Tokens (CT) may be distributed to trusted parties (e. g., Ethereum logs).
with no charge . Proceeds may come from tokenized trans 10083] Custodial agents or miners may be parties who
action fees . In embodiments, transaction fees may be on the verify and sign the Ethereum transactions when turning
order of, for example , 1 % to 0 .2 % . BOE into BTC . Once a transaction has enough verifying
[0076 ] In embodiments, in exporting BTCT to BTC , signatures , the transaction may be considered verified and
BTCTmay be burned ( destroyed ), for example , by sending may then be written to the Bitcoin blockchain . In embodi
the BTCT to a particular address that may never be used as ments , custodial agents or miners cannot initiate transac
source . In embodiments, proof of ownership may be accom tions; they can only sign ( provide a signature for ) transac
plished by the user providing hash of a pre- image . In this tions .
way , a foundation may be created to issue proof of owner [0084 ] Custodial agents orminers may monitor or " listen "
ship for transaction security . Fees, such as transaction or to the Ethereum blockchain and see burn of BOE , which
other fees , may be deducted in an Ethereum smart contract constitute requests for providing a signature . In a first
token . In embodiments, 3 -5 counter parties may be used to example , a smart contract may initiate a transaction , mul
US 2019 /0172026 A1 Jun . 6 , 2019
tiple transactions may be bundled together for verification , [0097] At block 322 , the process may cause a smart
and the event may be publicized by being written to the contract to be invoked using the output of the verify block
monitored Ethereum blockchain . In a second example , cus 320 to perform an Ethereum address proof and a P2PKH
todial agents or miners may see a request for signature by address proof.
subscribing to receive Ethereum events . [0098 ) At block 324 , the process may cause verification
[0085 ] Custodial agents or miners may be required to and validation of the transactions to be conducted . If the
provide a security bond . Custodial agents orminers may also verification and validation is not completed within a deter
be rated by users and/or metrics regarding transfers and mined period of time, then the process may proceed to block
requests for transfers to monitor their performance . 326 , to wait for a release of a BTC time lock .
[0099 ] Otherwise , if the verification and validation is
[ 0086 ] Custodial agents or miners may be part of a P2P completed within the determined period of time, then the
network , to allow custodial agents or miners to communi process may proceed to block 328 where a token contract
cate with one another . For each transaction , each custodial may be instantiated .
agent or miner may test the transaction and may decide to [0100 ] Atblock 330 , the process may cause a DBTC to be
append the custodial agent 's or miner ' s signature ( or not). minted ( generated ) .
The transaction may then be passed on to another or next [0101] At block 332 , the process may cause the minted
custodial agent(s ) or miner(s). DBTC to be stored in the Deluge wallet, which may be in the
[0087] Embodiments may include public monitoring web private address on the Ethereum blockchain .
sites that may allow review of statistics of the system . For 10102 ]. At block 334 , the process may cause the user to be
example , the public monitoring website may display all notified that the minted DBTC is available for access in the
completed transfer of BOE , changing unique Bitcoin Deluge wallet .
address , a list of custodial agents or miners thatmay include [0103 ] FIG . 4 is an example detailed flow diagram illus
contact information , and the health or status of the system . trating a method for exporting a token on an Ethereum
[0088 ] FIG . 3 is an example detailed flow diagram illus blockchain to a token on a Bitcoin blockchain , in accordance
trating a method for exporting a token on a Bitcoin block with various embodiments . In embodiments , the method or
chain to a token on an Ethereum blockchain , in accordance portions thereof may be performed at least by the smart
with various embodiments . In embodiments, the method or contract 108, Deluge wallet 102 , validators 124 of FIG . 1,
portions thereof may be performed at least by the smart and module 818 of FIG . 8 . FIG . 400 shows a process 400 ,
contract 108 and Deluge wallet 102 of FIG . 1 , and module with related components, that may start at block 402 .
818 of FIG . 8 . FIG . 300 shows a process 300 , with related [0104 ] Atblock 404 , the process may cause DBTC to be
components, that may start at block 302 . deposited into the Deluge wallet .
[0089] At block 304 , the process may cause a BTC to be [0105 ] At block 406 , the process may cause DBTC to be
sent that includes an address and an amount of the BTC in sent, including the transaction amount, to a token smart
tokens or fractions thereof. In parallel, at block 306 , the contract.
process may cause an Ethereum token to be sent that [0106 ] Atblock 408 , the token smart contractmay receive
includes an address , and gas . the DBTC and transaction amount .
[0090] At block 308 , the process may cause a private key [0107 ] At block 410 , the process may cause a token burn
to be created . In embodiments , the private key may be based of the DBTC tokens to be initiated . In embodiments , the
on the BTC address and the Ethereum address from blocks burn may be recorded as a log event in the Ethereum
304 and 306 , respectively. blockchain .
[0108 ]. At block 412, the process may cause the token burn
[0091] At block 310 , the process may cause the private to be validated . In embodiments , the validation may be
key to be sent to the Deluge wallet, which may be similar to triggered by the log event.
Deluge wallet 102 of FIG . 1 . In embodiments , the Deluge [0109 ] At block 414 , the process may cause the token burn
wallet may pay to a public key hash (P2PKH ) and create an to continue to be validated by waiting on validators, such as
associated transaction identifier. validators 124 of FIG . 1, to agree on the validity of the token
[0092 ] Atblock 312, the process may cause a pay to script burn . In embodiments , if the token burn cannot be validated ,
hash (P2SH ) to be performed and cause an associated then the process may proceed to block 427 , where a DBTC
transaction identifier to be created . refund may be minted and the minted DBTC added back to
10093] At block 314 , the process may cause the result of the Deluge wallet.
blocks 310 and /or 312 to be sent to the BTC relay to provide [0110 ) Otherwise , at block 416 , the process may cause the
cross -blockchain communication via the BTC relay con raw transaction signatures from the validators to be aggre
tract. gated .
10094 ] At block 316 , the BTC relay smart contract may [0111 ] At block 418 , the process may cause a smart
receive information from the BTC relay to facilitate cross contract to be initiated to determine if there are sufficient
blockchain communication . validated signatures from the validators . If there are insuf
ficient validated signatures, then the processmay proceed to
[0095 ] Returning to block 312 , at block 318 the process block 428 where the DBTC is minted and refunded to the
may cause a wait 6 block chain blocks . In embodiments , the Deluge wallet of the user , who then , at block 426 , may be
number of block chain blocks for waiting may be varied . notified of the refund .
[0096 ] Atblock 320 , the process may cause transactions to [0112 ] Otherwise, if there are sufficient validated signa
be verified . In embodiments, the verification may include tures from the validators, then the process may cause a
Merkle Proof, block hash import transaction , P2PKH , Redeem Script to be generated to be used to redeem previ
P2PRH , and/or P2SH verification . ously locked BTC .
US 2019 /0172026 A1 Jun. 6 , 2019
[0113] At block 420 , the process may then cause the wallet 504 , which may be similar to Deluge wallet 102 of
unlocked BTC to be received into the Deluge wallet. FIG . 1 , is a software solution that assists the user in storing
[0114 ] At block 422 , a BTC claimer process may be public and private keys, and aids with constructing transac
initiated . If the BTC claimer process is not successful, then tions. The smart contract 506 may be decentralized and run
at block 424 a recovery process may be initiated . In embodi on the Ethereum network . Multisig 508 represents the mul
ments, the BTC may sent to the address specified at the time tisig transaction and P2SH address on the Bitcoin network .
of the burn . If there was an error, it is lost. Validators 510 , which may be similar to validators 124 of
[0115 ] Otherwise, at block 426 , the process may cause the FIG . 1 , represent independent entities used during the export
user to be notified that exported BTC are available in the verification process. Bitcoin 512 represents a Bitcoin node
Deluge wallet . that exposes a remote procedure call (RPC ) endpoint.
[0116 ] FIG . 5 is an example multiple -entity timing/inter
action diagram for importing Bitcoin tokens to Ethereum [0123 ] Import transactions. At 514 , the user 502 initiates
tokens and exporting Ethereum tokens to Bitcoin tokens, in an import transaction . At 516 , the Deluge wallet 504 auto
accordance with various embodiments . matically creates BTC and Ethereum (or ERC20 compliant)
[0117 ] In order to bridge and / or sychronize transactions address pairs that correspond to the same public key , and
across the Bitcoin and Ethereum networks, the cross - block sends it to the multisig 508 P2SH address on the Bitcoin
chain secure transaction network may include the following : network . At 518 , the user transfers BTC to the Deluge wallet
(1 ) smart contracts deployed on the Ethereum network that 504. During Deluge import (sending BTC for DBTC ), user
may include: (a ) a Deluge Network (DN ) smart contract, (b ) sends BTC to a P2SH address specified by the smart
a token smart contract, and (c ) a D token contract; ( 2 ) BTC contracts 506 . The Bitcoins are locked at this address until
Relay sync services and Relay smart contract; (3 ) Deluge a future time when a user requests Deluge export ( sending
Wallet for sending and constructing Deluge transactions ; (4 ) DBTC for BTC ) and, for example, 80 % of the validators
P2SH address for locking Bitcoins ; and (5 ) validators and a agree .
validator network .
[0118 ] In embodiments , a DN smart contract is respon [0124] At 520 , the Deluge wallet 504 initiates a verify
sible for managing Deluge import/export transactions and transaction ( verifyTx ) with a smart contract 506 , which
transaction verifications, including with a BTC Relay con ultimately triggers DBTC minting at 522 if verification is
tract. A token contract may support DBTC mint and burn successful. The network uses BTC Relay smart contract to
activities . verify on the Ethereum blockchain that the given transaction
[ 0119 ] AD token smart contract manages a reward pool. in fact took place on the bitcoin blockchain . Prior to minting
A reward pool may include all transaction fees in the DBTC for use on the Ethereum blockchain , a smart contract
cross -blockchain secure transaction network collected in verifies both the user's transfer of BTC to the Deluge Wallet
DBTC (or in other network backed tokens ) as incentives for and that user ' s ownership of the same BTC once it has been
users of the system and validators. Other aspects of D tokens locked into the multisig 508 address . In embodiments , to
are discussed below . verify that the user transferred the BTC , a P2PKH bitcoin
[0120 ] The Deluge wallet is a software wallet that is address may be used . The smart contract checks that at least
controlled by the user. The usermay run this software on the one of the transaction inputs to P2SH is originated from the
user ' s computer ; the user generates keys and stores them for user 's transaction output, thus providing the check to the
the user 's use . An import or export transaction creates a condition that the user owns the bitcoin that was locked . A
Bitcoin and Ethereum address pairs derived using the BTC Relay is used to verify both that the user 's BTC
secp256k1 ECDSA ( Elliptic Curve Digital Signature Algo contributions are confirmed to the created BTC address and
rithm ) public key . Transactions may only be validated and that the user ' s Bitcoins are locked to the P2SH . If verifica
executed if the addresses correspond to the sameprivate key tion is successful, a token smart contract 506 mints the
claiming the exchange of funds. DBTCs to user 's Ethereum address in the Deluge wallet 504 .
[0121 ] BTC Relay Smart Contract. Because Bitcoin can [0125 Export transactions . During Deluge export, the
not verify information from other blockchains, it is impor user, via the Deluge Wallet , triggers a token smart contract
tant that parallel communication and verification across the DBTC burn 524a , 524b . Smart contract 506 logs the burn
disparate blockchains occur. BTC Relay facilitates this by event on the Ethereum blockchain , where validators ( or
functioning as an Ethereum smart contract that enables a custodial agents ) listen for burn events and trigger the export
trust- free means of certifying that a Bitcoin transaction took process upon observing the DBTC burn 526 . Validators
place . BTC Relay is used to verify that the given transaction independently construct and sign (with their respective
is recorded on the bitcoin network . Specifically, BTC Relay private keys) the raw bitcoin transaction by selecting
uses Bitcoin ' s block header to create a miniature version of UTXOs that are optimal for the requested transaction
the Bitcoin blockchain implementing Bitcoin SPV . A BTC amount and post the signature to the Deluge smart contract
Relay contract on Ethereum stores the block headers and or Ethereum logs 528a , 528b. When enough M -of-N signa
uses the underlying Merkle Root to verify transactions, tures are posted, the smart contract generates an Ethereum
enabling other smart contracts to verify that the given event (or log message ) notifying the wallet 530a , 530b of
Bitcoin transaction has been confirmed sufficiently on the validation . The user, via the wallet, will retrieve the validator
Bitcoin blockchain . signatures, transaction metadata , and RedeemScript from
[ 0122 ] With respect to diagram 500 , cross -blockchain the Deluge smart contract. RedeemScript is a list of validator
secure transaction network import and export flow may be public keys required to verify the transaction was signed by
diagrammed as shown. Entities in the multiple entity timing M -of-N validators. The wallet constructs the multisig bit
diagram include the user 502 , that represents the individual coin transaction and submits to the Bitcoin blockchain . The
who is submitting the import or export requests . The Deluge user then receives the corresponding BTC amount into the
US 2019 /0172026 A1 Jun. 6 , 2019
Deluge Wallet (less any transaction and mining fees incurred the total supply of D token is 9,800 ,000, and the remaining
during the validation process described above ), and the DBTCs in the transaction fee pool are 98 . Now these
Export process is complete . 9 , 800 , 000 D tokens may represent all the transaction fees
[0126 ] Deluge Import / Export Cycle Times . In one collected and to be collected by the network .
embodiment, the rough cycle time estimate from the start of [0131 ] ( 3 ) Reward Pool: Transaction Reward (Airdrop ).
an import / export process to its completion may be as fol ( 3a ) In embodiments , a daily reward ( airdrop ) of 0 . 1 % of the
lows. Import uses bitcoin protocol and BTC Relay for remainder in reward pool may be given out. For example, if
transaction verification . An estimation of import cycle time the total supply of D token is 1 million , 1000 D tokens may
is ~ 75 minutes which includes the following steps: ( 1 ) send be given out as reward in day 1 , 999 D tokens in day 2,
BTC to Deluge Wallet from another wallet address ( 1 bitcoin 998 .001 D tokens in day 3, and so on . (3b ) In embodiments ,
block time, ~ 10 minutes ); (2 ) send BTC to P2SH address to 30 % of the daily reward (airdrop ) will be used as transaction
lock BTC ( 1 bitcoin block time, ~ 10 minutes ); (3 ) send volume ( # of transactions) reward , 70 % may be used as
import request to smart contract (wait 6 bitcoin blocks for turnover (transaction amount in USD ) reward . For example ,
confirmation , - 60 minutes to ensure BTC Relay picked up the formulas may include: VolumeReward A = Volume A / TO
the P2SH transaction ); and (4 ) mint DBTC and see it tal Volume* Daily Volume Reward ; Turnover Reward
available on the Deluge Wallet (6 Ethereum blocks , ~ 1.5 A = Turnover A / Total Turnover * Daily Turnover Reward . ( 30 )
minutes plus additional time to execute required verification The rewards incentivize the import transactions (BTC to
methods between Deluge smart contract and BTC Relay DBTC conversion ), and daily rewards may be computed at
smart contract. the end of a 24 -hour period . The previous day ' s reward pool
[0127] Export starts on the Ethereum network for process may be published for community transparency.
ing and uses bitcoin protocol for completing the multisig [0132 ] 4 . Reward Pool: Marketing Promotions ( Airdrop ).
transaction . An estimation of export cycle time is - 15 (4a ) Airdrop for marketing promotions may be tied to a
minutes which includes the following steps: ( 1 ) send export marketing campaign . This will be a flexible reserve that will
request to smart contract which triggers the DBTC burn be analytically tracked for the effectiveness of the marketing
event (6 Ethereum block time, - 1 . 5 minutes ); ( 2 ) validators
pick up the burn event, independently construct the raw
campaign . Functionality will be coded into the smart con
tract for execution . Marketing campaigns may be based on :
transaction and sign (transaction time would depend on the whitelisted addresses for D token distribution , D token
network latency for the Raft nodes and network infrastruc distribution over a date /time range to anyone registered , or
ture ); (3 ) smart contract notifies the Deluge Wallet when airdrops for anyone that did imports given a range (beyond
majority of the Validators have signed . Deluge Wallet con what is already distributed as part of the transaction reward
structs the multisig and submits to the bitcoin network to pool).
complete the claim ( 1 bitcoin blocktime - 10 minutes ). [0133 ] FIG . 6 is an example context diagram illustrating
[0128 ] D tokens. In implementation embodiments, D an interaction of validators in a Raft node implementation ,
tokens may be used to claim funds in transaction fee pool. in accordance with various embodiments. Validators are
D tokens will be burned if the holder withdraws a prorated independent entities responsible for independently signing
amountcorresponding to D tokens from the pool. In embodi export requests . In embodiments, validators may be invited
ments , D tokens will be airdropped (awarded ) based on and / or recruited based on their brand reputation . In embodi
number of transactions and transaction volume. D tokens ments, validators will follow a decentralized model with an
may be awarded to transactors . In embodiments , the total open validator participation given the network governance
supply of D token may be limited to 10 ,000 ,000 (10M ) rules (as discussed below ).
tokens . In embodiments , D tokens may be used for gover [0134 ] Validators may : (1) include built-in operational
nance, such as voting for validators , governance changes transparency and metrics for trust ; (2) achieve balance
and such . between maintaining the integrity of transactions and speed
[0129 ] In embodiments , D tokensmay have the following of transactions ; and (3 ) have checks , balances, and incen
characteristics: (1 ) D token distribution : ( la ) a sponsoring tives to ensure validators are honest.
organization may be allocated with 80 % of the total D token
supply . This pool, for example , may be used for future [0135 ] Validator Keys. For the multisig transaction (dis
technology development. ( 1b ) all other validators/ partners cussed above ), the Deluge wallet is required to supply the
together may be allocated with 10 % of the initial D token RedeemScript, which is a list of validator public keys
supply . Each validator may be given tokens based on the required to verify the transaction was signed by the needed
negotiated contract. (1c ) 10 % of the D token pool may be M -of- N validators.
used for rewards: 9 % may be allocated to transaction [0136 ] Validator Fees. In embodiments , in return for the
rewards , 1 % may be reserved for airdrop (award ) promo work performed , validators have a stake in the D token
tions. reward pool. In embodiments, traction fees are pooled and
[0130 ] (2 ) The right to claim transaction fees. (2a ) All the managed in the D token contract based on the specific
transaction fees in the network may be collected in DBTC cryptocurrency operation , DBTC , DBCH , etc ., and a spe
( and / or other backed token such as D tokens ) and put into cific fee percentage collected . For example , fees may start at
the transaction fee pool. (20 ) D token holders have the right around 0 .7 % . When validators sign , they may receive a
to burn D tokens in exchange for prorated amount ofDBTC percent of the D tokens thatmay be contractually agreed .
in the transaction fee pool anytime. For example , if the total [0137 ) Required Minimum and Maximum Number of
D token supply is 10 million , and a holder has 200 ,000 D Validators . In some embodiments , validator design may
tokens (2 % of the total supply ), and there are 100 DBTC in require an odd number of validators for Raft consensus
the transaction pool at that point, the holder can choose to operations . That coupled with the import/ export implemen
burn 200 ,000 D tokens and get 2 DBTC . After the burning, tation that uses the bitcoin multisig (with a hard limit of 16
US 2019 /0172026 A1 Jun. 6 , 2019
10
signatures ), a minimum number of validators is 3 and leader 604 to select a set ofUTXOs that exist for a minimum
maximum number of validators is 15 . required number of validator nodes for the spending trans
[ 0138 ] Validator operation and duties . Validators provide action to succeed .
the needed M -of- N keys required to unlock the multisig [0145 ] The second key/ valuemap stores the setofUTXOs
bitcoin transaction for exporting . For the signing process, for each exportId , sent as a log message from the Deluge
individual validators are to : ( 1 ) maintain a list of UTXOS Token contract, to complete the export. Each validator may
( unspent transaction outputs) to construct the spending use this set to construct the signature necessary to create the
transaction signature ; ( 2 ) listen for an export transaction that spending transaction . Because , in embodiments , a single
includes a token burn event; and (3 ) Independently construct leader is selecting the UTXOs, each validator is guaranteed
and sign a raw transaction and post their signature to the to use the same set, verify that these UTXOs exist and that
smart contract. the exportId is a valid export request.
[0139 ] Given the probabilistic consistency nature of the [0146 ] Raft nodes may implement the following RPCs: ( 1)
bitcoin protocol, network partitions , and potential node UpdateUTXO ( uint blockHeight, bytes blockHash ) — up
failures , in embodiments , each validator is to track to the dates best height/hash for a node ; ( 2 ) StartExport( uint
same set of UTXOs. In embodiments, cross -blockchain exportId ) — requests exports UTXO set, if none exists the
secure transaction network made leverage a Raft consensus leader will create the set based on lowest best height/hash ;
algorithm for UTXO tracking . ( 3 ) EndExport( uint exportId ) - requests removes the
[0140 ] Raft Consensus. Raft is a distributed consensus export_ id mapping from the FSM
algorithm to solve the problem of getting multiple servers to [0147 ] Overview of the flow . In embodiments , (1 ) follow
agree on a shared state , even in the case of individual server ers 602 , 606 make an RPC call to the leader sending in their
failures . In embodiments , a cluster of nodes may maintain a UTXO best block height (with 6 or more confirmations ),
replicated state machine which is kept in sync through the
use of a replicated log . As long as the majority of the nodes blockhash , and node id ; ( la ) leader 604 then sends an
AppendEntry message to all followers 602, 606 with the
are up , system will be fully operational. blockheight/blockhash and follower id ; ( 1b ) leader 604
[0141 ] Turning now to diagram 600, a Raft network sends Apply when enough followers 602, 606 have received
consists of an odd number of 3 or more nodes 602, 604 , 606 , entry ; ( 1c ) followers 602, 606 receive Apply message and
which may be referred to as a cluster, where each node is in update their FSM by updating entries for new blockheight /
one of 3 states: leader, follower or candidate . Raft works blockhash , follower id pairs .
with selecting a leader 604 for the cluster. The leader is [0148 ] (2 ) A validator receives a StartExport log event,
responsible for maintaining a replicated log of commands to
each follower 602 , 606 . Each follower 602, 606 appends to and it first checks if the exportId exists in the FSM ; ( 2a ) if
its log when receiving an AppendEntry command 608 from it does, then the Validator uses the values already replicated
the leader, and applies a message to its finite state machine to construct the signature . ( 2b ) if not, the validator calls the
( FSM ) 602a , 606? when receiving an Apply command 608 StartExport RPC with the exportId and amount and waits for
from the leader . If a Leader becomes unavailable or out-of a response ( timeouts included ) .
date , a follower 602, 606 can transition into the candidate [0149] (3) The leader handles a StartExport by : (3a )
state and start a new leader election process . Candidates checking if the exportId was already Apply to the log and
send out a vote request to all nodes and if it receives a responds; ( 3b ) selecting a set of UTXOs from its listunspent
quorum of votes the candidate nodes sets itself as the new output where none of the UTXOs have a blockheight greater
leader and increments the election term . than the lowest blockheight in the FSM blockheight/block
[ 0142] Raft Node Implementation . Raft consensus proto hash followers set and the value is greater than or equal to
col and etcd library implementation may be leveraged for the export amount+ fees . If the least height UTXO block
validators . Etcd is an open - source distributed key value store does not exist in the leaders wallet the leader will set its state
that provides shared configuration and service discovery for to follower without sending the AppendEntry request; ( 30 )
Container Linux clusters . Etcd runs on each machine in a sending an AppendEntry message containing the UTXO set,
cluster and gracefully handles leader election during net amount, and exportid for the export to all followers blocking
work partitions and the loss of the current leader. In embodi until a quorum of followers reply, once replicated sends an
ments , the usage of the validator consensus uses the standard Apply entry to all followers and responds to the RPC .
Raft for leader election and replication . Validator may [0150 ] (4 ) The followers receive an Apply message for a
implement the RPC 6026 , 6046 , 606b and FSM 602a , 604a , StartExport and add the UTXO set, amount and exportId to
606a on top of the base Raft protocol. Validators can the FSM .
construct bitcoin transactions using the bitcoin , as referred [0151 ] (5 ) A validator receives a EndExport log event,
to in 512 FIG . 5 , and the validator' s local wallet. checks if the export _ id is contained in the FSM and if so
[ 0143] In embodiments , the FSM may include two key / makes an EndExport RPC call. (5a ) Followers forward
value maps for tracking available and exported UTXOs: ( 1) EndExport message to the leader; (5b ) the leader sends
a key /value pair of validator _ id = > (utxo block height, block AppendEntry for EndExport ; (5c ) the leader receives quo
hash ); and ( 2 ) key/value pairs of exportId = > set(utxo ). rum of followers and send Apply message for EndExport;
[0144 ] The first key / file map stores the height and block (5d ) followers Apply EndExport by removing the exportId
hash of the latest ( highest) block that contains a UTXO in > Set (UTXO ) from their FSM .
the given Validator' s replicated log . The leader uses this to [0152 ] Proof of Validation . Each validator may indepen
determine if there are enough nodes that have a particular dently construct and sign (with their respective private keys )
UTXO in follower wallets. Using this the leader can select the raw bitcoin transaction and post their signature to the
UTXOs that have a blockheight less than the lowest block in Deluge smart contract. ExportID (hash value generated by
the FSM and is visible to all Validators . This allows the the token contract on an export ), also recorded on the smart
US 2019 /0172026 A1 Jun . 6 , 2019
contract and Ethereum logs , ensures tracking and transpar on the second blockchain , in accordance with various
ency of Deluge exports as a proof of validation . embodiments . Process 700 and be implemented by, for
[0153] Validator Setup , Installation , and Operational example , smart contracts 108 , Deluge wallet 102 , and vali
Requirements . In embodiments , validators need to ensure dators 124 of FIG . 1 .
support for: ( 1) fast and secure network connection ; (2 ) [0159 ] At block 702 , the process may include identifying
Physical environment and operation is secured with limited a set of tokens from a first block chain . In embodiments, user
access and a firewall ; ( 3 ) (recommended ) Hardware Security may transfer bit coined from the user bitcoin wallet 104 to
Module (HSM ) for secure digital key management; (4 ) the users Deluge wallet 102 .
support staff to deploy and manage the validator service ; (5 ) [0160] Atblock 704 , the process may include locking the
follow code upgrade requirements and ensure to run the identified set of the one or more tokens of the first block
correct version of software . chain . In embodiments , this may include locking BTC stored
[0154 ] Validator Operational Requirements . In embodi in Deluge wallet 102 using a P2SH Address .
ments, the following Service Level Agreements (SLAs) are [0161] At block 706 , the process may include minting,
a part of the validator node agreement: ( 1 ) high availability based upon the locked set of the one or more tokens, a set
and timely response time — to participate in the consensus of one or more tokens of a second block chain , wherein
process, validators need to be highly available with a mini tokens of the second block chain are to be subsequently
mum availability requirement of 99 % ( - downtime of 14 converted to tokens of the first block chain based upon the
minutes/day and 1.7 hrs/week ) to 99 .9 % (~ downtime of 1.4 locked set of tokens from the first block chain . In embodi
minutes/ day and 10 minutes /week ); ( 2 ) time assurance for ments , this may include minting a quantity of DBTC based
validating and signing export requests within the availability upon the locked BTC from the previous block .
requirements ; (3 ) periodically report on validator system f0162 ] FIG . 8 illustrates an example computing device
health and other metadata such as CPU ,memory , traffic , for 800 suitable for use to practice aspects of the present
operational health monitoring; ( 4 ) Run pseudo anonymously disclosure, in accordance with various embodiments.
to prevent malicious attempts, such as a distributed denial of [0163] For example , the example computing device 800
service (DDoS ) attack ; (5 ) provide on -call support to may be suitable to implement the functionalities of the smart
address potential faults, network issues, or illegal activity contracts 108 and /or deluge wallet 102 . In some embodi
with an ability to suspend /resume services ments , the example computing device 800 may be suitable
[ 0155 ] Key Management and Revocation . The key man to implement the functionalities of validators 124 .
agement and revocation process may include sweeping [0164 ] As shown , computing device 800may include one
UTXOs to a new P2SH address , updating contract, wallet or more processors or processor cores 802 , and system
and validators with the new address . This may include : ( 1 ) memory 804 . For the purpose of this application , including
key updates for onboarding new validators and reprocessing the claims, the term “ processor ” refers to a physical proces
existing ones ; (2 ) hacked key situation to invalidate a key on sor, and the terms “processor” and “ processor cores ” may be
a P2SH address ; (3 ) Peers / Sovereigns to suspend or resume considered synonymous , unless the context clearly requires
a validator ; (4 ) use of recovery keys otherwise. The processor 802 may include any type of
[0156 ] Sweep to Licensed Custodial. To mitigate some processors , such as a central processing unit (CPU ) , a
potential issues with lost /stolen private keys, the validators microprocessor, and the like. The processor 802 may be
can have functionality to generate a “ sweep ' transaction that implemented as an integrated circuit having multi-cores ,
spends all the known and confirmed UTXOs into a hard e .g ., a multi- core microprocessor. The computing device 800
coded custodial account . In embodiments , the sweep trans may include mass storage devices 806 ( such as diskette , hard
action would be logged to a non -public location and would drive, volatile memory ( e . g ., dynamic random access
require manual intervention by a trusted party to submit to memory (DRAM )), compact disc read only memory (CD
the bitcoin network after the network is shutdown . ROM ) , digital versatile disk (DVD ) and so forth ). In general,
[0157 ] Governance Control and Policy. In embodiments, system memory 804 and / or mass storage devices 806 may
the cross -blockchain secure transaction network is a trusted be temporal and /or persistent storage of any type , including,
system with Validators who are recruited based on brand but not limited to , volatile and non - volatile memory , optical,
reputation and interest in in cross -blockchain secure trans magnetic , and / or solid state mass storage , and so forth .
actions. Validator coordination , such as software updates , Volatile memory may include, but not be limited to , static
may be managed off- chain . Governance may also include : and /or dynamic random access memory . Non -volatile
(1 ) onboarding and offboarding of validators, where valida memory may include , but not be limited to , electrically
tors are ordered based on a ranking protocol which includes erasable programmable read only memory, phase change
D token staking, community votes, reputation based on past memory , resistive memory, and so forth .
performance , term limits set by governance rules, and the [0165 ] The computing device 800 may further include
like; ( 2 ) on - chain management of validators, including vali input/output (1/0 ) devices 808 such as a display, keyboard ,
dator removal if it fails to meet operational requirements; (3 ) cursor control, remote control, gaming controller, image
cryptographic key distribution and rotation for enhanced capture device, and so forth and communication interfaces
security ; (4 ) social contract to agree on upgrades and ( comm . INTF ) 810 (such as network interface cards,
changes to protocol, contract, and other operating agree modems, infrared receivers , radio receivers ( e . g ., Blu
ments ; ( 5 ) mechanisms for the ecosystem to check on the etooth ), and so forth ). I/ O devices 808 may be suitable for
Validator work , which is an input into validator reputation communicative connections with other systems and/or
and ranking protocol. devices that communicate to facilitate cross -blockchain
[0158] FIG . 7 is an example flow diagram illustrating a secure transactions.
method for exporting or synchronizing the behavior of one [0166 ] The communication interfaces 810 may include
or more tokens on a first blockchain to one or more tokens communication chips ( not shown) that may be configured to
US 2019 /0172026 A1 Jun. 6 , 2019
operate the device 800 in accordance with a Global System 800 , in response to execution of the programming instruc
for Mobile Communication (GSM ), General Packet Radio tions, to perform operations associated with the functions
Service (GPRS ), Universal Mobile Telecommunications and operations described in FIGS . 1 - 7 . In alternate embodi
System (UMTS ), High Speed Packet Access (HSPA ), ments , programming instructions 904 may be disposed on
Evolved HSPA ( E -HSPA ), or Long Term Evolution (LTE ) multiple computer - readable non -transitory storage media
network . The communication chips may also be configured 802 instead . In alternate embodiments , programming
to operate in accordance with Enhanced Data for GSM instructions 904 may be disposed on computer-readable
Evolution (EDGE ) , GSM EDGE Radio Access Network transitory storage media 902 , such as signals.
(GERAN ), Universal Terrestrial Radio Access Network [0171 ] Any combination of one or more computer usable
(UTRAN ), or Evolved UTRAN (E -UTRAN ) . The commu or computer readable medium ( s ) may be utilized . The com
nication chips may be configured to operate in accordance puter - usable or computer - readable medium may be , for
with Code Division Multiple Access (CDMA ), Time Divi example but not limited to , an electronic , magnetic , optical,
sion Multiple Access (TDMA ), Digital Enhanced Cordless electromagnetic , infrared , or semiconductor system , appa
Telecommunications (DECT), Evolution - Data Optimized ratus , device, or propagation medium . More specific
(EV -DO ), derivatives thereof, as well as any other wireless examples (a non -exhaustive list) of the computer-readable
protocols that are designated as 3G , 4G , 5G , and beyond . medium would include the following: an electrical connec
The communication interfaces 810 may operate in accor tion having one or more wires, a portable computer diskette ,
dance with other wireless protocols in other embodiments . a hard disk , a random access memory (RAM ) , a read - only
[0167 ] The above -described computing device 800 ele memory (ROM ), an erasable programmable read -only
ments may be coupled to each other via system bus 812 , memory (EPROM or Flash memory ), an optical fiber, a
which may represent one or more buses . In the case of portable compact disc read - only memory (CD -ROM ), an
multiple buses , they may be bridged by one or more bus optical storage device , a transmission media such as those
bridges (not shown ). Each of these elements may perform its supporting the Internet or an intranet, or a magnetic storage
conventional functions known in the art. In particular, sys device . Note that the computer- usable or computer-readable
tem memory 804 and mass storage devices 806 may be medium could even be paper or another suitable medium
employed to store a working copy and a permanent copy of upon which the program is printed , as the program can be
the programming instructions implementing the operations electronically captured , via , for instance , optical scanning of
associated with cross -blockchain secure transactions, e .g ., the paper or other medium , then compiled , interpreted , or
operations associated with providing cross -blockchain otherwise processed in a suitable manner, if necessary , and
secure transactions 818 with features and /or functions as then stored in a computer memory. In the context of this
described in reference to FIGS . 1 -7 . Computational logic document, a computer- usable or computer-readable medium
822 may be implemented by assembler instructions sup may be any medium that can contain , store, communicate ,
ported by processor (s) 802 or high -level languages that may propagate , or transport the program for use by or in con
be compiled into such instructions . nection with the instruction execution system , apparatus, or
10168 ] The permanent copy of the programming instruc device . The computer - usable medium may include a propa
tions may be placed into mass storage devices 806 in the gated data signal with the computer -usable program code
factory , or in the field , through , for example , a distribution embodied therewith , either in baseband or as part of a carrier
medium ( not shown ), such as a compact disc (CD ), or wave . The computer usable program code may be transmit
through communication interfaces 810 (from a distribution ted using any appropriate medium , including but not limited
server (not shown )). to wireless, wireline , optical fiber cable , RF, etc.
[ 0169 ] FIG . 9 illustrates an example storage medium 10172 ) Computer program code for carrying out opera
having instructions for practicing methods described with tions of the present disclosure may be written in any
references to FIGS. 1 - 7 , in accordance with various embodi combination of one or more programming languages ,
ments . including an object oriented programming language such as
[0170 ] As will be appreciated by one skilled in the art, the Java, Smalltalk , C + + or the like and conventional procedural
present disclosure may be embodied as methods or computer programming languages , such as the “ C ” programming
program products . Accordingly, the present disclosure , in language or similar programming languages . The program
addition to being embodied in hardware as earlier described , code may execute entirely on the user's computer, partly on
may take the form of an entirely software embodiment the user' s computer, as a stand -alone software package ,
( including firmware, resident software, micro -code , etc .) or partly on the user' s computer and partly on a remote
an embodiment combining software and hardware aspects computer or entirely on the remote computer or server. In the
thatmay all generally be referred to as a “ circuit," " module ” latter scenario , the remote computer may be connected to the
or " system .” Furthermore , the present disclosure may take user' s computer through any type of network , including a
the form of a computer program product embodied in any local area network (LAN ) or a wide area network (WAN ), or
tangible or non -transitory medium of expression having the connection may be made to an external computer ( for
computer -usable program code embodied in the medium . example , through the Internet using an Internet Service
FIG . 9 illustrates an example computer - readable non - tran Provider).
sitory storage medium that may be suitable for use to store [0173 ] The present disclosure is described with reference
instructions that cause an apparatus, in response to execution to flowchart illustrations and/ or block diagrams of methods ,
of the instructions by the apparatus , to practice selected apparatus (systems) and computer program products accord
aspects of the present disclosure. As shown, non - transitory ing to embodiments of the disclosure . It will be understood
computer - readable storage medium 902 may include a num that each block of the flowchart illustrations and /or block
ber of programming instructions 904 . Programming instruc diagrams, and combinations of blocks in the flowchart
tions 904 may enable a device , e.g., a computing platform illustrations and/or block diagrams, can be implemented by
US 2019 /0172026 A1 Jun. 6 , 2019
computer program instructions. These computer program storage medium readable by a computer system and encod
instructions may be provided to a processor of a general ing a computer program instructions for executing a com
purpose computer, special purpose computer, or other pro puter process .
grammable data processing apparatus to produce a machine, [0179 ] The corresponding structures, material, acts , and
such that the instructions, which execute via the processor of equivalents of all means or steps plus function elements in
the computer or other programmable data processing appa the claims below are intended to include any structure,
ratus, create means for implementing the functions/acts material or act for performing the function in combination
specified in the flowchart and /or block diagram block or with other claimed elements are specifically claimed . The
blocks. description of the present disclosure has been presented for
10174 ] These computer program instructions may also be purposes of illustration and description , but is not intended
stored in a computer -readable medium that can direct a to be exhaustive or limited to the disclosure in the form
computer or other programmable data processing apparatus disclosed . Many modifications and variations will be appar
to function in a particular manner , such that the instructions ent to those of ordinary skill without departing from the
stored in the computer-readable medium produce an article scope and spirit of the disclosure. The embodiment was
of manufacture including instruction means which imple chosen and described in order to best explain the principles
ment the function / act specified in the flowchart and /or block of the disclosure and the practical application , and to enable
diagram block or blocks. others of ordinary skill in the art to understand the disclosure
10175 ] The computer program instructions may also be for embodiments with various modifications as are suited to
the particular use contemplated .
loaded onto a computer or other programmable data pro [0180] Thus various example embodiments of the present
cessing apparatus to cause a series of operational steps to be disclosure have been described including , but are not limited
performed on the computer or other programmable appara to :
tus to produce a computer implemented process such that the
instructions which execute on the computer or other pro [0181 ] Example 1 is a method , apparatus, and /or system
grammable apparatus provide processes for implementing for cross-blockchain and /or synchronization , wherein a first
the functions /acts specified in the flowchart and /or block cryptocurrency of a first blockchain is sent to a locked
diagram block or blocks . address , an address is created in a second blockchain cor
responding to a private key of the first cryptocurrency, and
[0176 ] The flowchart and block diagrams in the figures a second cryptocurrency of the second blockchain is minted
illustrate the architecture , functionality , and operation of in the second blockchain by a smart contract.
possible implementations of systems,methods and computer [0182 ] Example 2 may include the subject matter of
program products according to various embodiments of the example 1, wherein the second cryptocurrency is burned , a
presentdisclosure . In this regard , each block in the flowchart miner or a custodial agent verifies validity , and wherein first
or block diagrams may represent a module, segment, or cryptocurrency is released from the locked address and is
portion of code, which comprises one or more executable sent to an unlocked address in the first blockchain .
instructions for implementing the specified logical function [0183] Example 3 may be one or more computer-readable
(s ). It should also be noted that, in some alternative imple media comprising instructions that cause a computer device ,
mentations, the functions noted in the block may occur out in response to execution of the instructions by one or more
of the order noted in the figures . For example , two blocks processors of the computer device , to operate a cross block
shown in succession may, in fact, be executed substantially chain secure token transaction engine to : identify a set of one
concurrently , or the blocks may sometimes be executed in
the reverse order, depending upon the functionality or more tokens of a first blockchain ; lock the identified set
involved . It will also be noted that each block of the block
of the one or more tokens of the first blockchain ; and
diagrams and /or flowchart illustration , and combinations of generate , based upon the locked set of the one or more
blocks in the block diagrams and /or flowchart illustration , tokens , a set of one or more tokens of a second blockchain ;
can be implemented by special purpose hardware -based wherein the set of one or more tokens of the second
blockchain are to be subsequently converted to tokens of the
systems that perform the specified functions or acts, or first blockchain based upon the locked set of tokens of the
combinations of special purpose hardware and computer first blockchain .
instructions. [0184 ] Example 4 may include the one or more computer
10177] The terminology used herein is for the purpose of readable media of example 3 , wherein to lock the identified
describing particular embodiments only and is not intended set of tokens of the first blockchain is further to : identify a
to be limiting of the disclosure . As used herein , the singular pays to script hash (P2SH ) address associated with the
forms “ a ," " an ” and “ the” are intended to include plural identified set of the one or more tokens of the first block
forms as well, unless the context clearly indicates otherwise . chain ; and lock the identified set of the one or more tokens
It will be further understood that the terms “ comprises ” of the first blockchain to the identified P2SH address .
and /or " comprising," when used in this specification , spe 101851 Example 5 may include the one or more computer
cific the presence of stated features, integers, steps, opera readable media of example 4 , wherein the P2SH address is
tions , elements , and /or components , but do not preclude the specified by a smart contract.
presence or addition of one or more other features , integers, [0186 ] Example 6 may include the one or more computer
steps, operation, elements, components, and/ or groups readable media of example 4 , wherein to generate one or
thereof. more tokens of the second blockchain is further to : verify
[0178 ] Embodiments may be implemented as a computer ownership of the tokens of the locked identified set of tokens
process, a computing system or as an article of manufacture of the first blockchain by a user; and verify the tokens of the
such as a computer program product of computer readable locked identified group of tokens of the first blockchain have
media . The computer program product may be a computer been stored to a wallet of the user .
US 2019 /0172026 A1 Jun. 6 , 2019
14
[0187 ] Example 7 may include the one ormore computer converted to tokens of the first blockchain based upon the
readable media of example 6 , wherein the wallet is to store locked set of tokens of the first blockchain .
an indication of one or more tokens of the first blockchain [0198 ] Example 18 may include the computer-imple
and of one ormore tokens of the second blockchain owned mented method of example 17 , wherein locking the identi
by a user . fied set of tokens of the first blockchain further includes :
0188 ] Example 8 may include the one or more computer identifying a P2SH address associated with the identified set
readable media of example 6 , wherein the wallet includes of the one or more tokens of the first blockchain , and locking
address pairs corresponding to the first blockchain and the the identified set of the one or more tokens of the first
second blockchain , wherein the address pairs are associated blockchain to the identified P2SH address .
with a public key . [0199 ] Example 19 may include the computer- imple
[ 0189 ] Example 9 may include the one or more computer mented method of example 17 , wherein the address is
readable media of example 3 , wherein the computer device specified by a smart contract.
is further caused to : identify a set of one or more tokens of [0200 ] Example 20 may include the computer -imple
the second blockchain ; based upon the identified set of one mented method of example 17, wherein generating one or
or more tokens of the second blockchain , identify a subset more tokens of the second blockchain further includes :
of tokens of the locked set of tokens of the first blockchain ; verifying ownership of the tokens of the locked identified set
burn the identified set of tokens of the second block chain ; of tokens of the first blockchain by a user; and verifying the
and unlock the subset of the set tokens of the locked group tokens of the locked identified group of tokens of the first
of tokens on the first blockchain , based upon the identified blockchain have been stored to a wallet of the user.
group of tokens of the second blockchain . [0201 ] Example 21 may include the computer- imple
[0190 ] Example 10 may include the one or more com mented method of example 17 , wherein the wallet is to store
puter-readable media of example 9 , the computer device is an indication of one or more tokens of the first blockchain
further caused to store an indication of the unlocked subset and of one or more tokens of the second blockchain owned
of the set of one or more tokens of the first blockchain in a by a user.
wallet . [0202 ] Example 22 may include the computer -imple
[ 0191] Example 11 may include the one or more com mented method of example 17 , wherein the wallet includes
puter-readable media of example 9, wherein to burn the address pairs corresponding to the first blockchain and the
identified set of tokens of the second block chain is further second blockchain , wherein the address pairs are associated
to : receive a plurality of responses, respectively, from a with a public key .
plurality validator nodes , wherein a response includes an [0203 ] Example 23 may include the computer -imple
indication of a verification of a burn event; and based upon mented method of example 17 , further including: identifying
the received plurality of responses, determine whether the a set of one or more tokens of the second blockchain ; based
identified set of tokens of the second block chain are to be upon the identified set of one or more tokens of the second
burned . blockchain , identifying a subset of tokens of the locked set
[ 0192 ] Example 12 may include the one or more com of tokens of the first blockchain ; burning the identified set of
puter - readable media of example 11, wherein a validator tokens of the second block chain ; and unlocking, based upon
node maintains a list of unspent transaction outputs in the the identified group of tokens of the second blockchain , the
first blockchain based upon the set of one or more tokens of subset of the set tokens of the locked group of tokens on the
the second blockchain . first blockchain .
[0193] Example 13 may include the one or more com [0204 ] Example 24 may include the computer- imple
puter-readable media of example 11 , wherein to determine mented method of example 23 , further including storing an
whether the identified set of tokens of the second block chain indication of the unlocked subset of the set of one or more
are to be burned is based upon a Raft consensus algorithm tokens of the first blockchain in the wallet.
for unspent transaction outputs tracking. [0205 ] Example 25 may include the computer -imple
[ 01941 Example 14 may include the one or more com mented of example 23 , wherein burning the identified set of
puter - readable media of example 3, wherein the first block tokens of the second block no chain further includes : receiv
chain is a Bitcoin blockchain , and the second blockchain is ing a plurality of responses, respectively, from a plurality
an Ethereum blockchain . validator nodes , wherein a response includes an indication
[01951. Example 15 may include the one or more com of a verification of a burn event; and based upon the received
puter -readable medium of example 3 , wherein the one or plurality of responses, determining whether the identified set
more tokens of the first blockchain are one or more Bitcoins, of tokens of the second block chain are to be burned .
and wherein the one or more tokens of the second block [0206 ] Example 26 may include the computer- based
chain are ERC20 compatible tokens for the Ethereum block method of example 25 , wherein a validator node is to
chain . maintain a list of unspent transaction outputs based upon the
[0196 ] Example 16 may include the one or more com set of one or more tokens of the second blockchain .
puter-readable media of example 3 , wherein a token includes [0207] Example 27 may include the computer-based
a portion of a token . method of example 26 , wherein determining whether the
[0197 ] Example 17 is a computer - implemented method , identified set of tokens of the second block chain are to be
comprising: identifying a set of one or more tokens of a first burned is based upon a Raft consensus algorithm for unspent
blockchain ; locking the identified set of the one or more transaction outputs tracking .
tokens of the first blockchain ; and generating , based upon [0208 ] Example 28 may include the computer -based
the locked set of the one or more tokens , a set of one or more method of example 17 , wherein the first blockchain is a
tokens of a second blockchain ; wherein the set of one or Bitcoin blockchain , and the second blockchain is an
more tokens of the second blockchain are to be subsequently Ethereum blockchain .
US 2019 /0172026 A1 Jun. 6 , 2019
15
[ 0209] Example 29 may include the computer-based identify a set of one or more tokens of the second
method of example 17 , wherein the one or more tokens of blockchain ;
the first blockchain are one or more Bitcoins , and wherein based upon the identified set of one or more tokens of the
the one or more tokens of the second blockchain are ERC20 second blockchain , identify a subset of tokens of the
compatible tokens for the Ethereum blockchain . locked set of tokens of the first blockchain ;
[0210 ] Example 30 may include the computer-based burn the identified set of tokensof the second block chain ;
method of example 17 , wherein a token includes a portion and
of a token . unlock the subset of the set tokens of the locked group of
[ 0211 ] Example 31 may include the computer -based tokens on the first blockchain , based upon the identified
method of example 17 , wherein the method is performed by group of tokens of the second blockchain .
one or more smart contracts . 8 . The one or more computer-readable media of claim 7 ,
[0212 ] It will be apparent to those skilled in the art that the computer device is further caused to store an indication
various modifications and variations can be made in the of the unlocked subset of the set of one or more tokens of the
disclosed embodiments of the disclosed device and associ first blockchain in a wallet.
ated methods without departing from the spirit or scope of 9 . The one or more computer -readable media of claim 7 ,
the disclosure . Thus, it is intended that the present disclosure wherein to burn the identified set of tokens of the second
covers the modifications and variations of the embodiments block chain is further to :
disclosed above provided that the modifications and varia receive a plurality of responses, respectively, from a
tions come within the scope of any claims and their equiva plurality validator nodes, wherein a response includes
lents . an indication of a verification of a burn event; and
What is claimed is: based upon the received plurality of responses, determine
1. One or more computer -readable media comprising whether the identified set of tokens of the second block
instructions that cause a computer device , in response to chain are to be burned .
execution of the instructions by one or more processors of 10 . The one or more computer -readable media of claim 9 ,
the computer device , to operate a cross blockchain secure wherein a validator node maintains a list of unspent trans
token transaction engine to : action outputs in the first blockchain based upon the set of
identify a set of one or more tokens of a first blockchain ; one or more tokens of the second blockchain .
lock the identified set of the one or more tokens of the first 11 . The one or more computer -readable media of claim 9 ,
blockchain ; and wherein to determine whether the identified set of tokens of
generate , based upon the locked set of the one or more the second block chain are to be burned is based upon a Raft
tokens, a set of one or more tokens of a second consensus algorithm for unspent transaction outputs track
blockchain ; ing.
wherein the set of one or more tokens of the second 12 . The one or more computer- readable media of claim 1 ,
blockchain are to be subsequently converted to tokens wherein the first blockchain is a Bitcoin blockchain , and the
of the first blockchain based upon the locked set of second blockchain is an Ethereum blockchain .
tokens of the first blockchain . 13 . The one or more computer -readable medium of claim
2 . The one or more computer -readable media of claim 1 , 1 , wherein the one or more tokens of the first blockchain are
wherein to lock the identified set of tokens of the first one or more Bitcoins, and wherein the one or more tokens
blockchain is further to : of the second blockchain are ERC20 compatible tokens for
identify a pays to script hash (P2SH ) address associated the Ethereum blockchain .
with the identified set of the one or more tokens of the 14 . The one or more computer - readable media of claim 1 ,
first blockchain ; and wherein a token includes a portion of a token .
lock the identified set of the one ormore tokens of the first 15 . A computer - implemented method , comprising :
blockchain to the identified P2SH address . identifying a set of one or more tokens of a first block
3 . The one or more computer-readable media of claim 2 , chain ;
wherein the P2SH address is specified by a smart contract. locking the identified set of the one or more tokens of the
4 . The one or more computer -readable media of claim 1 , first blockchain ; and
wherein to generate one or more tokens of the second generating, based upon the locked set of the one ormore
blockchain is further to : tokens , a set of one or more tokens of a second
verify ownership of the tokens of the locked identified set blockchain ;
of tokens of the first blockchain by a user; and wherein the set of one or more tokens of the second
verify the tokens of the locked identified group of tokens blockchain are to be subsequently converted to tokens
of the first blockchain have been stored to a wallet of of the first blockchain based upon the locked set of
the user. tokens of the first blockchain .
5. The one or more computer-readablemedia of claim 4 , 16 . The computer- implemented method of claim 15 ,
wherein the wallet is to store an indication of one or more wherein locking the identified set of tokens of the first
tokens of the first blockchain and of one or more tokens of blockchain further includes :
the second blockchain owned by a user. identifying a P2SH address associated with the identified
6 . The one or more computer-readable media of claim 4 , set of the one or more tokens of the first blockchain ;
wherein the wallet includes address pairs corresponding to and
the first blockchain and the second blockchain , wherein the locking the identified set of the one ormore tokens of the
address pairs are associated with a public key . first blockchain to the identified P2SH address.
7 . The one or more computer-readable media of claim 1 , 17 . The computer- implemented method of claim 15 ,
wherein the computer device is further caused to : wherein the address is specified by a smart contract.
US 2019 /0172026 A1 Jun. 6 , 2019
16
18 . The computer- implemented method of claim 15 , 23 . The computer- implemented of claim 21, wherein
wherein generating one or more tokens of the second burning the identified set of tokens of the second block no
blockchain further includes : chain further includes :
verifying ownership of the tokens of the locked identified receiving a plurality of responses, respectively, from a
set of tokens of the first blockchain by a user; and plurality validator nodes , wherein a response includes
verifying the tokens of the locked identified group of an indication of a verification of a burn event; and
tokens of the first blockchain have been stored to a based upon the received plurality of responses, determin
wallet of the user. ing whether the identified set of tokens of the second
19 . The computer-implemented method of claim 15 , block chain are to be burned .
wherein the wallet is to store an indication of one or more 24 . The computer -based method of claim 23 , wherein a
tokens of the first blockchain and of one or more tokens of validator node is to maintain a list of unspent transaction
the second blockchain owned by a user . outputs based upon the set of one or more tokens of the
20 . The computer -implemented method of claim 15 , second blockchain .
wherein the wallet includes address pairs corresponding to 25 . The computer -based method of claim 24 , wherein
the first blockchain and the second blockchain , wherein the determining whether the identified set of tokens of the
address pairs are associated with a public key . second block chain are to be burned is based upon a Raft
21 . The computer - implemented method of claim 15 , fur consensus algorithm for unspent transaction outputs track
ther including : ing.
identifying a set of one or more tokens of the second 26 . The computer- based method of claim 15 , wherein the
blockchain ; first blockchain is a Bitcoin blockchain , and the second
based upon the identified set of one or more tokens of the blockchain is an Ethereum blockchain .
second blockchain , identifying a subset of tokens of the 27 . The computer-based method of claim 15 , wherein the
locked set of tokens of the first blockchain ; one or more tokens of the first blockchain are one or more
burning the identified set of tokens of the second block Bitcoins, and wherein the one or more tokens of the second
chain ; and blockchain are ERC20 compatible tokens for the Ethereum
unlocking , based upon the identified group of tokens of blockchain .
the second blockchain , the subset of the set tokens of 28 . The computer -based method of claim 15 , wherein a
the locked group of tokens on the first blockchain . token includes a portion of a token .
22 . The computer- implemented method of claim 21 , fur 29. The computer -based method of claim 15 , wherein the
ther including storing an indication of the unlocked subset of
the set of one or more tokens of the first blockchain in the method is performed by one or more smart contracts .
wallet.