BFastPay: A Routing-free Protocol For Fast Payment In Bitcoin Network
BFastPay: A Routing-free Protocol for Fast Paymentin Bitcoin NetworkXinyu Lei, Guan-Hua Tu, Tian Xie, Sihan WangDepartment of Computer Science and EngineeringMichigan State UniversityEast Lansing, Michigan, CTBitcoin is the most popular cryptocurrency which supports payment services via the Bitcoin peer-to-peer network. However, Bitcoinsuffers from a fundamental problem. In practice, a secure Bitcointransaction requires the payee to wait for at least 6 block confirmations (one hour) to be validated. Such a long waiting time thwartsthe wide deployment of the Bitcoin payment services because manyusage scenarios require a much shorter waiting time. In this paper,we propose BFastPay to accelerate the Bitcoin payment validation.BFastPay employs a smart contract called BFPayArbitrator to hostthe payer’s security deposit and fulfills the role of a trusted payment arbitrator which guarantees that a payee always receives thepayment even if attacks occur. BFastPay is a routing-free solutionthat eliminates the requirement for payment routing in the traditional payment routing network (e.g., Lightning Network). Thetheoretical and experimental results show that BFastPay is able tosignificantly reduce the Bitcoin payment waiting time (e.g., from60 mins to less than 1 second) with nearly no extra operation cost.CCS CONCEPTS Security and privacy Distributed systems security; Security protocols.KEYWORDSBlockchain; Bitcoin; Smart Contract; Fast PaymentACM Reference Format:Xinyu Lei, Guan-Hua Tu, Tian Xie, Sihan Wang. 2021. BFastPay: A Routingfree Protocol for Fast Payment in Bitcoin Network. In Proceedings of theEleventh ACM Conference on Data and Application Security and Privacy(CODASPY ’21), April 26–28, 2021, Virtual Event, USA. ACM, New York, NY,USA, 11 pages. ONBitcoin as a decentralized payment solution is increasingly gainingrecognition and acceptance. For example, it has been accepted bymany famous retailers and service providers such as Microsoft [10]and Samsung [15]. Nevertheless, Bitcoin suffers from a key problem.Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from permissions@acm.org.CODASPY ’21, April 26–28, 2021, Virtual Event, USA 2021 Association for Computing Machinery.ACM ISBN 978-1-4503-8143-7/21/04. . . 15.00https://doi.org/10.1145/3422337.3447823In practical applications, the payee needs to wait for 6 block confirmations (ave. 60 mins) for validating a Bitcoin transaction to defendagainst the potential double-spending attack launched by the payer.A shorter waiting time increases the risk of the double-spendingattack in which the payer spends the same Bitcoin more than onceand the payee loses the commodities/services without receiving theBitcoin payment. The one-hour waiting time has seriously impededthe wide adoption of Bitcoin payment services because many businesses (e.g., vending machines) expect a much shorter waiting time.This problem is one of the most fundamental open problems of Bitcoin. In the past decade, researchers have devoted great efforts toaddress the problem, but no perfect solutions have been developedyet. We are thus motivated to seek for alternative approaches toaddress this critical problem.In this paper, we aim to develop a new Bitcoin payment protocol that satisfies the following requirements. (1) Mainly usingBitcoin. The solution should enable users to use Bitcoin as themajor payment cryptocurrency instead of requiring users to adoptother cryptocurrencies. (2) Short waiting time. The time requiredfor the payee to validate a Bitcoin payment should be short whilestill defending against the double-spending attacks. (3) Decentralization. The solution should preserve Bitcoin’s decentralizationfeature: no reliance on any centralized trusted third party is required. (4) Low-cost. The extra operation cost should be low.The limitations of the prior art are discussed as follows. (1) NonBitcoin-based. One straightforward solution is to enforce usersto use some other cryptocurrencies with faster transaction validation time. However, since Bitcoin has dominated in practical usage[1], it is desirable to develop solutions to support fast Bitcoin payment while keeping Bitcoin as the major payment currency. (2)Prevention-based. The solutions proposed in [20, 24, 30] deployobservers in the Bitcoin network to detect the conflicting Bitcointransactions (i.e., multiple transactions that spent the same Bitcoin).The prevention-based solutions are not highly reliable since theconflicting Bitcoin transactions detection is probabilistic. (3) Secure wallet-based. Secure wallet-based solutions [22, 35] requireusers to trust the secure wallet, so they cannot ensure decentralization. (4) Escrow-based. The Lightning Network [31] and DuplexMicropayment Channels [21] are escrow-based solutions whichsupport fast payment via payment routing network. Researchershave developed various solutions [29, 32, 34] to improve the routing performance, but the current escrow-based solutions still onlysupport micropayments. Recently, a solution named Snappy is proposed in [26]. Snappy employs a majority-based governance model,which requires a group of payees (i.e., merchant) to serve as statekeepers to prevent double-spending attacks. It is hard to claim that
Snappy preserves decentralization (as it is in Bitcoin) because themajority-based governance model requires coordination betweena group of nodes. However, the concept of decentralization in Bitcoin can be achieved without any coordination between nodes (i.e.,Bitcoin network is a decentralized self-sustainable system).To support fast payment in the Bitcoin network, we proposean inter-blockchain escrow approach (i.e., BFastPay) in this paper. BFastPay is a general approach that can be deployed on anyprogrammable smart contract (PSC)-supported blockchain platform (e.g., Ethereum [7], EOSIO [5]). BFastPay is called an interblockchain (or cross-blockchain) escrow approach since the security deposit (i.e., collateral) is escrowed on another PSC-supportedblockchain. BFastPay is designed based on two key insights. First,BFastPay employs a decentralized smart contract called BFPayArbitrator to host the payer’s security deposit and fulfill the role of atrusted payment arbitrator which guarantees that a payee alwaysreceives the payment even if attacks occur. Note that BFastPay preserves the decentralization feature if the underlying PSC-supportedblockchain employs a decentralized consensus algorithm. Second,BFastPay takes advantage of the fast consensus property of emerging PSC-supported blockchains (e.g., EOSIO blockchain only needsless than 1 second to validate a transaction [5]) to reduce the waitingtime of the Bitcoin transaction. More specifically, BFastPay works as follows. At first, a payer escrows sufficient security depositinto BFPayArbitrator. While the payer submits a Bitcoin transaction to the Bitcoin network, (s)he simultaneously submits a Bitcoinfast payment request (BFPayReq) message to BFPayArbitrator. TheBFPayReq message contains all information that BFPayArbitratorneeds to make the arbitration if a payment dispute arises later.Once the BFPayReq transaction is successfully validated in the PSCsupported blockchain, the payee can deliver commodities/servicesto the payer. Hence, the waiting time is reduced to the time neededto validate a transaction on the PSC-supported blockchain. If thereis a payment dispute later, BFastPay allows both parties to submitevidence to prove that they are the honest parties. If the payeesuccessfully proves that (s)he does not receive Bitcoin payment, BFPayArbitrator pays the payee using the security deposit. Otherwise,the security deposit still belongs to the payer.The major technical challenge is that it is hard for BFPayArbitrator to recognize the dishonest party in a payment arbitrationbecause BFPayArbitrator cannot access Bitcoin blockchain (i.e., theinter-blockchain transaction validation is hard). In a payment arbitration, both the payer and the payee have incentives to upload fakeevidence to BFPayArbitrator. The payer may submit fake evidenceto cheat BFPayArbitrator that the Bitcoin has already paid, whilethe payee may also submit fake evidence to cheat BFPayArbitratorthat no Bitcoin payment is received. However, BFPayArbitrator isunable to distinguish which party is dishonest without accessing thecanonical Bitcoin blockchain to obtain the ground truth. To addressthis challenge, we develop a Bitcoin proof-of-work (PoW)-basedpayment arbitration mechanism for BFPayArbitrator to identifythe dishonest party. The key idea is that our PoW-based arbitrationmechanism enables the honest party (either the payer or the payee)to generate a valid proof from the Bitcoin subchain, whereas thedishonest party cannot. Hence, the Bitcoin miners automaticallyand unconsciously help the honest party to generate a valid proof towin the payment arbitration. The dishonest party has to defeat allBitcoin miners in the mining race to win the payment arbitration,so it is hard for the dishonest party to win the payment arbitration.In summary, this paper has three main contributions.(1) We take the first step forward to study the inter-blockchain escrow protocol, BFastPay, which enables the Bitcoin blockchainto employ the fast consensus property of PSC-supported blockchains (which may adopt more advanced consensus techniques) toreduce its payment waiting time without requiring any modification on the current Bitcoin protocols.(2) We develop a novel PoW-based mechanism for a smart contract BFPayArbitrator without accessing the Bitcoin blockchainto arbitrate whether a Bitcoin transaction has been successfully included into the Bitcoin blockchain or not. Therefore,BFPayArbitrator can ensure payment fairness.(3) Our theoretical analysis and experimental results demonstratethat BFastPay achieves multiple design goals simultaneously.It is a secure, fast, decentralized, low-cost, and routing-freepayment scheme.The rest of the paper is organized as follows. Section 2 introducessome background knowledge. In Section 3, we introduce the adopted threat model and assumptions. Section 4 presents an overviewof BFastPay. The arbitration mechanism used by BFastPay is illustrated in Section 5. Section 6 performs security analysis. Section7 evaluates the operation cost of BFastPay. Section 8 comparesBFastPay with the state-of-the-art solution. Section 9 reviews therelated work. Some conclusions are given in Section 10.2PRELIMINARIESThis section introduces the preliminaries of the Bitcoin blockchainand programmable smart contract (PSC)-supported blockchains.Bitcoin Blockchain. The Bitcoin blockchain [28] is a shared public ledger on which all Bitcoin transactions are recorded. Numerous Bitcoin transactions are put into a new block and appendedto the blockchain in chronological order. When a block that contains a new Bitcoin transaction has been appended to the Bitcoinblockchain, this transaction has one block confirmation. When asubsequent block is appended to the blockchain, the number ofblock confirmation for this transaction is increased by one [4]. Thecurrent practice for accepting a secure Bitcoin transaction is: waiting for such transaction to have 6 block confirmations. Note that 6block confirmations are based on an assumption that adversaries do not control more than 10% of the global hash powerof the Bitcoin network and a double-spending probability ofless than 0.1% is acceptable [28]. Bitcoin network refers to thecollection of nodes (e.g., miners, wallets) running the Bitcoin P2Pprotocol. The Bitcoin network uses a PoW-based method for reaching a consensus between different miners. The miner who can solvethe hash-based PoW puzzle wins the right to produce a new blockfor the blockchain. A Bitcoin block header is 80 bytes containinginformation of (1) previous block hash field, (2) Merkle root field, (3)nonce field, etc. In the mining process, the miners try to find a noncesuch that the mined block header meets the current Bitcoin networkdifficulty target, i.e., Hash(block header) BTC diff target.PSC-Supported Blockchains. Nowadays, blockchain technologyis evolving beyond just supporting a cryptocurrency. Some emerging blockchains (e.g., Ethereum, EOSIO) support rich programmable
Table 1: The consensus mechanisms and transaction validation time of different PSC-supported blockchains.Blockchain typeBlockchainConsensus sed proof-of-work (PoW) protocolEthereumEOSStellar [18]Cardano [25]NEO [11]Modified “Greedy Heaviest Observed Subtree" (GHOST) protocol [7]Asynchronous Byzantine Fault Tolerance (aBFT) protocol [5]Federated Byzantine Agreement (FBA) protocol [18]Ouroboros Proof-of-Stake (PoS) protocol [25]Delegated Byzantine Fault Tolerant (dBFT) protocol [11]PSC-supportedblockchainsmart contract functionalities. A smart contract model typicallyconsists of program code (run on the blockchain), a storage file(stored on the blockchain), and an account balance (recorded onthe blockchain). A user can deploy a smart contract by posting atransaction to the blockchain. A user can send a message (via atransaction) to a smart contract to trigger its function execution.All content of the blockchain, smart contracts, and transactionsis publicly visible. The smart contract can partially fulfill the roleof a trusted third party. After auditing from involved users andvalidating on the PSC-supported blockchain, the smart contractcode is immutable, and all code executes exactly according to howit was programmed. Hence, the smart contract can support theprogram-controlled fund transfer. The fund managed by the smartcontract is represented in the form of token. For example, Ethereumblockchain uses ETH token and EOSIO blockchain uses EOS token.As shown in Table 1, different blockchains exploit different consensus mechanisms, resulting in the different time needed to validatea transaction. Compared with Bitcoin, many recently developedPSC-supported blockchains have a shorter transaction validationtime. For instance, as analyzed in [12], Ethereum needs about 12confirmations (about 3 mins) to achieve a similar degree of securityas 6 confirmations (about 60 mins) on Bitcoin blockchain.3THREAT MODEL AND ASSUMPTIONSThreat Model. The security threat mainly comes from the payeror the payee. (1) Payer. The payer may double-spend the Bitcoinand hence no Bitcoin payment will be received by the payee. Additionally, the payer attempts to win the payment arbitration to avoidreleasing the security deposit to the payee. If the payer successfullydouble-spends the Bitcoin and wins the arbitration, then the payeeloses the commodities/services without receiving any payment.This attack is a double-spending attack. (2) Payee. The payee isconsidered as a semi-benign entity. The payee may still raise a dispute and hope to win the arbitration even if (s)he has received theBitcoin payment. If the payee wins the arbitration, then (s)he canreceive payments twice. This attack is a double-payment attack.We do not consider the risk that the payee refuses to deliver commodities/services to the payer even if the payer correctly finishesthe payment phase required by BFastPay because such risk existsin any payment method. Therefore, handling such risk is out of thescope of this paper. We note that this problem has been studied in[23].Assumptions. We have the following assumptions. (1) Both thepayer and payee are rational and they would defend for their ownAve. tx validation time 60 mins 3 mins 1 second 5 seconds 5 mins 15 secondsinterests (e.g., the payer/payee would take actions to thwart anydouble-payment/double-spending attempt). (2) Both the payer andthe payee can control a portion of the global Bitcoin hash power tolaunch attacks. However, either payer or payee cannot control morethan 50% of the global hash power for Bitcoin mining. We assumethat the remaining hash power is controlled by honest miners, whowork together to extend the longest Bitcoin blockchain as stipulatedby the Bitcoin protocol. (3) The smart contract platforms adoptedby BFastPay are secure. We admit that some existing smart contractplatforms have security vulnerabilities. However, developers havedevoted great efforts to fix the known vulnerabilities and bringthem into real-world applications. (4) Both the payer and payeehave fairly reliable Internet connections during BFastPay service.4BFASTPAY OVERVIEWIn this section, we first briefly describe BFastPay flowchart andthen clarify how to use the security deposit in BFastPay.4.1BFastPay FlowchartFigure 1 depicts BFastPay flowchart, which consists of two phases:the payment phase and the arbitration phase.Payment Phase. There are three steps (steps 1-3 in Figure 1) inthis phase.(1) Before using the BFastPay service, the payer agent should firstescrow sufficient security deposit to BFPayArbitrator which isdeployed on a PSC-supported blockchain. The security depositis added to BFPayArbitrator via a transaction sending from thepayer’s PSC-supported blockchain account address Payer addrto BFPayArbitrator. Then, the payer agent can send a Bitcointransaction to the payee.(2) While the payer agent broadcasts the Bitcoin transaction tothe Bitcoin network, the payer agent simultaneously submits aBFPayReq message to BFPayArbitrator. The BFPayReq messageconsists of (1) the Bitcoin payment information, (2) the Bitcoinblockchain information, (3) the PSC-supported blockchain information, and (4) the transaction amount. Table 2 summariesall of the information carried in the BFPayReq message. Notethat the payer needs to refer to the public sources (e.g., [3])to get the real-time conversion rate between bitcoin and thePSC-supported blockchain token to compute the amount oftoken with a matching value. BFastPay uses the conversionrate when the Bitcoin transaction occurs. Future conversionrate fluctuations do not affect the fairness of the transaction.
Payeragent0. Security depositPayeeagentBFPayArbitrator1. Bitcoin transaction2. Sends BFPayReqPayment phaseRejects the paymentNo dispute5. Sends PaymentChallenge6. ArbitrationIf payer wins, the security depositstill belongs to the payer3. Checks if somerequirements holdNo4. Raises a dispute by sendingNonPaymentProofIf payee wins, pays the payee using the securitydepositTerminatesYes, accepts and deliverscommodities/servicesNo disputeArbitrationphaseTerminatesFigure 1: The flowchart of BFastPay.(3) The payee agent receives the BFPayReq message and checksif the following two requirements hold. (1) Each field of theBFPayReq message is correct1 . (2) The payer’s available security deposit should not be less than the escrowed Bitcointransaction amount2 . If the payee agent finds any field in theBFPayReq message is incorrect or the security deposit is insufficient, the payee rejects the Bitcoin transaction. Otherwise, thepayee waits for BFPayReq to be validated by the PSC-supportedblockchain before accepting the Bitcoin transaction and delivering commodities/services to the payer. The waiting time isthus reduced to be the time needed to validate a transaction onthe PSC-supported blockchain.Arbitration Phase. If the payee agent successfully receives the Bitcoin payment later and does not raise a dispute during a pre-definedarbitration time window, then the BFastPay service life cycle finishes and terminates. Otherwise, BFastPay allows the payee agentto raise a dispute by sending NonPaymentProof to BFPayArbitrator.Then, the BFastPay arbitration phase is activated. Note that thereare no attacks in the vast majority of real-world Bitcoin payment cases, so the arbitration phase is rarely activated. Thereare three steps (steps 4-6 in Figure 1) in the arbitration phase.(1) To raise a dispute, the payee agent needs to generate NonPaymentProof and submits it to BFPayArbitrator for arbitrationwithin a pre-defined arbitration time window.(2) The payer agent examines BFPayArbitrator to check if thereis a NonPaymentProof message received by BFPayArbitratorduring the arbitration time window. If the payer finds that NonPaymentProof message is received, BFPayArbitrator allows the1 To check the correctness of BFPayReq message, the payee can refer to the trustsources and make a field-to-filed comparison. More specifically, the payment information (BTC TxID, BTC Tx time) and blockchain information (BTC diff target,Block hash) is public on the Bitcoin Blockchain. The correct PSC-supportedblockchain information (Payer addr, Payee addr) is also known by the payee. Inaddition, the transaction amount (Token amount) can be computed by the payeebecause the real-time conversion rate is publicly accessible by the payee.2 The adopted check mechanism is exactly the same as the mechanism used in thecash-based payments: after the payer gives cash to the payee, the payee must checkand ensure that (1) it is not the fake cash and (2) the amount of cash is sufficient beforeaccepting it.Table 2: The information in BFPayReq message.Element typeField nameDescriptionPayment infoBTC TxIDBTC Tx timeThe Bitcoin transaction IDThe Bitcoin transaction timeBTC diff targetCurrent Bitcoin networkdifficulty targetThe hash of the latest Bitcoinblock header that does notinclude the escrowed Bitcoin txBlockchain infoBlock hashPayer addrPSC-supportedblockchain infoPayee addrTransaction amountToken amountThe payer’s PSC-supportedblockchain account addressThe payee’s PSC-supportedblockchain account addressThe amount of token needsto transfer to the payee if adouble-spending attack occurspayer to generate PaymentChallenge and to send it to BFPayArbitrator within a pre-defined rebuttal time window.(3) BFPayArbitrator arbitrates the dispute based on the receivedNonPaymentProof and PaymentChallenge. If the payee winsthe dispute, BFPayArbitrator pays the payee using the payer’ssecurity deposit. Otherwise, the security deposit still belongs tothe payer. After the arbitration process, the BFastPay servicefinishes and terminates.The detailed arbitration mechanism is further described in Section 5. Note that no manual operations are needed in using BFastPay. The payer agent and payee agent (e.g., smartphone) runBFastPay software to automatically finish the required operations.The software modules of BFastPay are introduced in Section 7.1.4.2Security Deposit ClarificationThe security deposit in BFPayArbitrator has two states: free andfrozen. Consider that the payer has a security deposit worth 𝑆 1dollars and a BFastPay Bitcoin payment has a transaction amount
worth 𝑆 2 dollars, where 𝑆 1 𝑆 2 . Then, during the service life cycleof BFastPay, BFPayArbitrator freezes 𝑆 2 dollars. The remaining(𝑆 1 𝑆 2 ) dollars are free. After the termination of a BFastPay fastpayment service, if the frozen security deposit does not release tothe payee, then it will be free again. The free deposit can be usedfor concurrent or future BFastPay fast payment services. Therefore,if both parties are honest (the vast majority of cases), the payer canenjoy a one-time deposit and permanent BFastPay fast paymentservices. Note that the payer can withdraw free security deposit tohis own account at any time.5BFASTPAY ARBITRATIONIn this section, we describe (1) how to design NonPaymentProofand PaymentChallenge, (2) how to check the validity of NonPaymentProof and PaymentChallenge, and (3) the detailed PoW-basedarbitration mechanism used in BFPayArbitrator.5.1NonPaymentProof Design and ValidationIn an arbitration, to convince BFPayArbitrator that the escrowedBitcoin transaction is not included in the Bitcoin blockchain, thepayee needs to submit NonPaymentProof to BFPayArbitrator. NonPaymentProof contains a number of linked block headers (namedblock header proof ). The Block header proof here is used to provethat sufficient PoW has been done to extend the Bitcoin blockchain,in which the escrowed Bitcoin transaction is not included. Figure 2illustrates the structure of the block header proof. The number ofthe linked block headers in the block header proof is defined as thelength of NonPaymentProof (denoted as 𝑛 1 ).Block header proofBlock header (No. 1)Previous hash NonceMerkle root. Hash12Block header (No. n 1)Previous hash NonceMerkle root Hash34Hash1Hash2Hash3Hash4tx 1tx2tx3tx4MerkletreeMerkleproofFigure 2: The structures of the block header proof and theMerkle proof.A valid NonPaymentProof should satisfy the following four requirements (R1)-(R4). (R1) The block headers meet the current Bitcoin difficulty target: Hash(block header No. 𝑖) BTC diff target, for 𝑖 1, · · · , 𝑛 1 . (R2) The block headers indeed form a linked blockchain:Hash(block header No. 𝑖) the previous hash field in blockheader No. 𝑖 1, for 𝑖 1, · · · , 𝑛 1 1. (R3) The block header chain indeed extends from the latestBitcoin block when the escrowed Bitcoin transaction occurs: theprevious hash field in the first block header equals Block hash. (R4) The escrowed Bitcoin transaction is not included in thefirst block header in NonPaymentProof.On receipt of NonPaymentProof, BFPayArbitrator can checkwhether the requirements (R1)-(R3) are satisfied or not, but it cannot check whether the fourth requirement (R4) is satisfied or not(it is hard to prove non-inclusion of a transaction. For example, theclassic Merkle proof [28] can prove inclusion but not non-inclusion).To prevent the payee from submitting NonPaymentProof whichdoes not satisfy the requirement (R4), BFastPay allows the payer to reveal such cheating behavior of the payee by submittingPaymentChallenge (by using the Merkle proof) to prove that theescrowed Bitcoin transaction is included in the first block header ofNonPaymentProof. If there is no such PaymentChallenge receivedand the requirements (R1)-(R3) are satisfied, then NonPaymentProof is treated to be valid. Otherwise, it is invalid.5.2PaymentChallenge Design and ValidationOn receipt of NonPaymentProof, BFPayArbitrator checks if oneof the requirements from (R1)-(R3) is not satisfied. If yes, BFPayArbitrator directly lets the payer win the arbitration without anyrequirements for PaymentChallenge. If no, the payer needs to submit PaymentChallenge to BFPayArbitrator. There are two cases asdescribed below.Case 1: NonPaymentProof Satisfies Requirement (R4). In thiscase, PaymentChallenge consists of two components: the blockheader proof and the Merkle proof. (1) Block Header Proof. Theblock header proof in PaymentChallenge is used to prove thatsufficient PoW has been done to extend the Bitcoin blockchain.Figure 2 depicts the structure of a block header proof. The numberof the linked block headers in the block header proof is definedas the length of PaymentChallenge (denoted by 𝑛 2 ). A valid blockheader proof should satisfy the requirements (R1)-(R3) as statedin Section 5.1. (2) Merkle Proof. The Merkle proof is used to provethat the escrowed Bitcoin transaction is indeed included in thefirst block header of the block header proof. The Merkle proof isgenerated from a Merkle tree, as shown in Figure 2. The Merkletree has a number of leaf nodes at the bottom of the tree containinghashes of each transaction in a Bitcoin block. An intermediate nodein the tree is the hash of its two children. Finally, a single root node(called a Merkle root) can be obtained. How to generate and validatethe Merkle proof can be illustrated by the following example. Asshown in Figure 2, in order to validate the inclusion of tx3 , thepayer only needs to provide a Merkle proof, which consists of twoparts: (1) the Merkle branch [Hash4 , Hash12 ], and (2) the branchposition [right, left]. To validate the Merkle proof, BFPayArbitratorcomputesHash3 Hash(tx3 ),Hash34 Hash(Hash3 Hash4 ), (Hash4 on right),Hash1234 Hash(Hash12 hash34 ), (Hash12 on left),where represents concatenation. If Hash1234 equals the Merkleroot of the first block header, then tx3 is indeed included in the blockheader. If the Merkle proof in PaymentChallenge can successfullyprove the inclusion of the escrowed Bitcoin transaction, then it isvalid. Otherwise, the Merkle proof is considered to be invalid. Notethat PaymentChallenge is valid if both its block header proof andMerkle proof are valid. Otherwise, it is invalid.
Case 2: NonPaymentProof Does not Satisfy Requirement (R4).In this case, PaymentChallenge only contains the Merkle proof,which is submitted to BFPayArbitrator to prove that NonPaymentProof does not satisfy requirement (R4). In other words, the Merkleproof is used to prove that the escrowed Bitcoin transaction is indeed included in the first block header of NonPaymentProof. Theinclusion-proof process is exactly the same as described above. Ifthe Merkle proof successfully proves that NonPaymentProof doesnot satisfy the requirement (R4), then PaymentChallenge is valid.Otherwise, it is invalid.5.3PoW-based Arbitration MechanismWe next introduce the arbitration window and rebuttal time windowsettings. Then, we describe the PoW-based arbitration mechanism.Last, the strategy which can ensure the honest party to win isillustrated.Arbitration and Rebuttal Time Window Settings. Let 𝑇𝑐 denote the elapsed time since the Bitcoin transaction is broadcastto the Bitcoin network. The arbitration time window is set to be[𝑇𝑐 𝜖,𝑇𝑐 ] and the rebuttal time window is set to be [𝑇𝑐 ,𝑇𝑐 𝜖].We set 𝜖 to be 5 mins in BFastPay. To simplify our theoreticalanalysis later, we treat that both the payee an
Bitcoin network is a decentralized self-sustainable system). To support fast payment in the Bitcoin network, we propose an inter-blockchain escrow approach (i.e., BFastPay) in this pa-per. BFastPay is a general approach that can be deployed on any programmable smart contract (PSC)-supported blockchain plat-form (e.g., Ethereum [7], EOSIO [5]).
EGP Exterior Gateway Protocol OSPF Open Shortest Path First Protocol IE-IRGP Enhanced Interior Gateway Routing Protocol VRRP Virtual Router Redundancy Protocol PIM-DM Protocol Independent Multicast-Dense Mode PIM-SM Protocol Independent Multicast-Sparse Mode IGRP Interior Gateway Routing Protocol RIPng for IPv6 IPv6 Routing Information Protocol PGM
Enhanced Interior Gateway Routing Protocol (EIGRP) is an example of a balanced hybrid routing protocol. EIGRP has several advantages over Routing Information Protocol (RIP) and Interior Gateway Routing Protocol (IGRP), and even some advantages over Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS).
systems (AS) (a.k.a. "domains") inter-AS routing § routing among AS'es § gateways perform inter-domain routing (as well as intra-domain routing) Internet approach to scalable routing intra-AS routing § routing among hosts, routers in same AS ("network") § all routers in AS must run sameintra-domain protocol § routers in .
Terms IGP (Interior Gateway Protocol) - RIP, IGRP, EIGRP, OSPF Routing protocol used to exchange routing information within an autonomous system. EGP (Exterior Gateway Protocol) - BGP Routing protocol used to exchange routing information between autonomous systems. Autonomous System (From RF 1771) “A set of routers under the single technical administration, using an IGP and .
iv Routing TCP/IP, Volume II About the Author Jeff Doyle, CCIE No. 1919, is vice president of research at Fishtech Labs. Specializing in IP routing protocols, SDN/NFV, data center fabrics, MPLS, and IPv6, Jeff has designed or assisted in the design of large-scale IP service provider and enterprise net-works in 26 countries over 6 continents.File Size: 7MBPage Count: 158Explore furtherRouting TCP/IP Volume 1 PDF Download Free 1578700418ebooks-it.orgDownload [PDF] Routing Tcp Ip Volume 1 2nd . - Usakochanwww.usakochan.netCcie Routing Tcp/ip Vol 1(2nd) And 2 Free . - Ebookeewww.ebookee.netJeff Doyle eBooks Download Free eBooks-IT.orgebooks-it.orgCCIE Professional Development Routing TCP . - Academia.eduwww.academia.eduTcp ip volume 1 jeff doyle pdf - AKZAMKOWY.ORGakzamkowy.orgRecommended to you b
networks including the old ARPANET routing protocol [18] and the NETCHANGE protocol of the MERIT network [26]. Well-known examples of DVP’S implemented in intemetworks are the Routing Information Protocol (RIP) [10], the Gateway-to-Gateway Protocol (GGP) [11], and the Exterior Gateway Protocol (EGP) [20]. All of these DVP’S have used variants
BGP-4 Border gateway protocol, version 4 EGP Exterior gateway protocol IGRP Cisco’s interior gateway routing protocol E-IGRP Cisco’s enhanced - IGRP Routing Domain - collection of routers that speaks the same routing protocol
ANATOMI EXTREMITAS INFERIOR Tim Anatomi (Jaka Sunardi, dkk) FIK Universitas Negeri Yogyakarta. OSTEOLOGI. OS COXAE 1. Linea glutea posterior 2. Ala ossis ilii 3. Linea glutea anterior 4. Cristae illiaca (a) labium externum (b) lab. Intermedia (c) lab. Internum 5. Facies glutea 6. SIAS 7. Linea glutea inferior 8. SIAI 9. Facies lunata 10. Eminentia iliopectinea 11. Fossa acetabuli 12. Incisura .
