Bytom(比原链)英文白皮书V1.0

Globle Currency：新型数字资产质流通系统摘要：比特币证明了点对点电子货币系统的可行性，以太坊建立了基于智能合约的去中心化应用平台，目前多种公链以及私有链、联盟链的大量共存，形成了数据和价值的孤岛。

Globle Currency通过动态同步索引侧链实现跨链资产映射及交换。

1.简介Globle Currency（以下简称GC）是一种通过动态索引同步侧链实现跨链资产映射及交换的系统，所有业务均以智能合约侧链的方式与父级链通过动态索引实现交互。

2.动态索引主链与侧链直接通过主链的Merkle树交互，主链对不同侧链链的索引会使用不同的索引策略，通常会在侧链区块基本可以确认不是孤块之后进行索引。

3.树形侧链通过GC的主侧链架构，以GC为主链，GC的侧链可以成为自身侧链的主链，因此理论上系统可以映射所有链上数字资产并能够通过智能合约无限扩展数字资产业务。

4.代币产出为致敬BTC ，GC 的理论总产出数量被设定为all GC =21,000,000枚，与BTC 总量相等，GC 地址生成算法也与BTC 相同。

GC 的产出方式有两种，BTC 层级置换及算力产出。

BTC 层级置换即使用BTC 按照层级置换比例换取GC ，该方式产出GC 总量为7,000,000枚，BTC 层级置换保证了GC 的价值与BTC 的对应关系，层级的增加对应了GC 以BTC 计价的升值，当置换产出GC 数量达到7,000,000枚或者层级置换停留在某一层级并维持30天，层级置换停止，即GC 的BTC 层级置换产出方式结束，此时如果置换GC 数量不足7,000,000枚，则剩余部分GC 销毁，GC 理论总产出数量将不足21,000,000枚。

第i 层的BTC 容量)26,2min(1+=-i BTC i i 第i 层BTC 置换GC 比例)055.1,)2(055.02max(/(round 21--=-i Ratio Ratio i i 1000001=Ratio 即第1层初始置换比例为1BTC ：100000GC 。

OmiseGODecentralized Exchange and Payments PlatformJoseph Poon joseph@work OmiseGO Team omg@omise.coJune17,2017AbstractOmiseGO is building a decentralized exchange,liquidity provider mechanism,clear-inghouse messaging network,and asset-backed blockchain gateway.OmiseGO is notowned by any single one party.Instead,it is an open distributed network of validatorswhich enforce behavior of all participants.It uses the mechanism of a protocol tokento create a proof-of-stake blockchain to enable enforcement of market activity amongstparticipants.This high-performant distributed network enforces exchange across as-set classes,fromfiat-backed issuers to fully decentralized blockchain tokens(ERC-20style and native cryptocurrencies).Unlike nearly all other decentralized exchange plat-forms,this allows for decentralized exchange of other blockchains and between multipleblockchains directly without a trusted gateway token.Markets may be able to signifi-cantly reduce spreads and encourage market assurance via decentralizing custody andincreased transparency of market activity.This is achieved using smart contracts,proto-col tokens enforcing correct market behavior of orderbook matching,a new constructionof Ethereum bonded external enforcement of clearinghouse activity,and commitmentsto historical exchange data for use with Ethereum smart contracts.1Introduction and Problem StatementThe primary role of blockchains are to solve coordination problems among multilateral agreements between a network of participants.By ensuring transparency,assurance,and enforcement,we can enable multilateral agreements where they were not previously possible. When all parties are assured that the operations are not only transparent,but also the mechanisms are guaranteed to not change without significant effort,parties are more willing to coordinate.Participants have significantly higher guarantees that a single party has difficulty forcing other parties in the future into usurious rent extraction via a change in business processes or information asymmetry.In other words,any single participant is more willing to use systems where the business processes and mechanisms itself are not owned by any other single participant.There is a fundamental coordination problem amongst payment processors,gateways, andfinancial institutions.For instance,a customer of a bank wishes to pay a merchant onanother network.Traditionally,there have been significant efforts in engineering around payment systems which are compatible across payment networks andfinancial institutions. These are usually constructed by creating a clearinghouse which manages the interchange, usually via a messaging network with either a central counterparty clearinghouse or nos-tro/vostro accounts.Examples include FedWire,CHIPS,SWIFT,consumer card payment networks,NSCC/DTCC,OCC,and ACH.These networks service different roles and func-tions,including local/national payments,international payments,credit,equities/asset ex-change,and derivatives.These centralized networks allow for the controlling entity to arbitrarily change the mechanisms,which result in significant amount of transaction costs via information costs,due diligence,and contractual enforcement between all parties.We believe that there is currently a large emerging market of disruption in digital pay-ments with new payment platforms(e.g.Venmo,Alipay,etc.).These networks have signifi-cant aversion to interchange across networks,as it usually requires significant overhead costs in trust with the interchange facility.Parties are unwilling to use central counterparties,as neither party wishes to defer to the other,and use of nostro/vostro accounts require bespoke contracts between participants.While the larger networks have significant incentive around protection of their network effects,we believe that there is a long-tail of entities wishing to provide eWallet services which require greater coordination amongst multilateral partic-ipants.These mid-size participants will be able to cross value across networks in order to reach sufficient network effects in usability.The infrastructure and reference frontend for these providers will allow for the network effects to be encoded into this network,allowing for emerging eWallet participants to instantly create high network utility.Blockchains allows society to externalize the world’s business processes from single cen-tralized corporations into open,decentralized computing networks.[1][2]OmiseGO(OMG) is a network which decentralizes market liquidity,orderbook matching and execution,clear-inghouse custodianship,and high-scalability payments to help resolve payments across these emerging eWallet payment networks.By shifting these business processes traditionally placed into a single corporation,it is possible to provide eWallet providers an entire interchange process in a decentralized high-performant open network.2Design ApproachThe end-state requirement is a construction of a decentralized mechanism for eWallet plat-forms holdingfiat-backed value(as well as native,opt-in,support for cryptocurrencies). The eWalletfiat tokens will have the ability to use Ether on the decentralized,public Ethereum[3][4]chain(or any other decentralized cryptocurrency)as the interchange/in-termediary cross for maximum efficiency.We believe that this allows for significant more activity and value in decentralized cryptocurrencies,as it will serve as a useful venue for many eWallet platforms.As it’s a core function for this decentralized network to do eWallet interchange,ablockchain ledger on OmiseGO is necessary to hold the general balance of funds per eWallet service(or any user/node).This ledger must be able to hold funds across many assets/com-modities.However,merely holding a ledger is insufficient for interchange.The mechanism must also allow to trade these assets/commodities.In order to perform interchange,it requires an order to be placed across many different pairs on an open public market.This requires a decentralized orderbook and trading engine. The trading engine is built into the OMG blockchain,orders are published and matches are performed as part of every block when a matched order has reached sufficient number of validation confirmations.This results in a non-custodial decentralized exchange held by a single party where the eWallet platforms may exchange onto other eWallet platforms without centralized trust on a single entity.However,direct crosses between eWalletfiat tokens may not be desirable,as there may be too many.It would be necessary to use cryptocurrency for a liquid market without single preference.By bonding Ethereum into a smart contract[5](or Bitcoin-like tokens into bonded clearinghouses),it is possible to lock up Ether onto the activity of the OMG chain to allow for eWallet pairs to occur over Ether or other cryptocurrencies,creating a liquid market(if every pair crosses with ETH,spreads would be much smaller provided low currency volatility).For activity requiring very small spreads,it may emerge that some eWallet tokens will be used as interchange crossing;however,there’s strong incentive to use decentralized tokens for settlement due to coordination/trust advantages related to programmatic adjudication.eWalletfiat tokens may also cross using other eWallet tokens if necessary,but bonding which don’t affect short-term exchange ratefluctuations of smart contract activity will be primarily in ETH(e.g.HTLC clearinghouse,liquidity providing, and OMG chain enforcement).By allowing for cryptocurrencies to be the backing for eWallet platforms,the platforms can be assured of an even playingfield between eWallet interchange activities.This requires a greater degree of liquidity in funds locked up,and the OmiseGO decen-tralized exchange may not be desirable to transact for low-value interchange activity(e.g. for high-volume micropayments).Not every payment between two distinct eWallets must be performed using a trade on the decentralized exchange.There is an expectation,that eWallets will hold some reserve offiat tokens of other eWallets,ready to be used for smaller transfers in popular directions. Constructions such as Lightning Network[6]allow for payments to occur off-chain when eWallets hold balances to facilitate rapid payments.Implementations allow for payments across Bitcoin[7]and Ethereum[8],which can be easily ported to the OMG chain for eWallet balances.The result of the OmiseGO blockchain construction is it allows for eWallet interchange, supported by a decentralized exchange,cryptocurrency(e.g.ETH)matching,orderbook, and clearinghouses without full-custody trust.2.1Decentralized Liquidity Hub for ChannelsThe construction has the additional benefit of allowing for a decentralized liquidity pool to be created for use with payment channels on various cryptocurrencies,such as Bitcoin(and to some extent Ethereum).For individual token payments on blockchains,there is a need to scale the underlying blockchain activity which does not affect the underlying chain to reduce computational pressure of validating/mining nodes.It is therefore necessary to conduct Lightning Net-work activities(or similar constructions using channels).However,Lightning Network faces significant pressure around network effects with capital,it’s desirable to prevent liquidity pools from centralizing to a single trusted entity.By using the same mechanisms of the de-centralized clearinghouse,we can create a Lightning Network hub which is not owned by any single individual on tokens which support more complex smart contracts(e.g.Ethereum, ERC-20-like tokens,etc.).For currencies with simple smart contracts,any node on the network(e.g.Bitcoin network)can act as a gateway into the OMG chain pool and cross back with any other participant.This allows the OmiseGO chain to offload a lot of on-chain activity,while encouraging decentralization.We believe that the natural network effects of liquidity centralization can be mitigated by decentralized stake-chains with deterministic/known consensus rules.For Ethereum in particular(and other full-featured smart-contract scripting blockchains),all participants set up channels into an ETH smart contract operating as a single pool of funds.The chain state of the OMG chain reflects the current balance of participants.This allows for any participant to supply liquidity onto this network which can be allocated in accordance to the OMG-chain consensus rules(limits may be in place early on to prevent this blockchain from sucking up all the spare liquidity from the cryptocurrency space if this construction is successful before robust testing/validation over time).These funds can thereby be used for any liquidity activity on the OMG chain.3Blockchain Overview and MechanismThe above mechanisms require significant volume of activity(with a large amount of state), and is not at this time suitable for all activity to occur on the Ethereum main chain, however the construction would be to bond trading activity in the public Ethereum chain with contract execution input being provided by the OMG chain.We are building a blockchain which hooks into other blockchains to allow for trading across token/asset classes,largely backed by Ether.From the perspective of any individual chain,we are building a scalable blockchain whose contract state is bonded by the activities of the OMG chain itself.Activity on other chains can interlink with this chain via inter-chain committed proofs similar(but constructed differently)to BTC Relay[9]on the OMG chain which can be submitted on Ethereum.The OMG chain validates the activity of the behavior of all participants(including activity on other chains).In other words,the roleof the OMG token is providing computation and enforcement.The token itself acts as a bond for its activity on this blockchain,improper activity results in the token/bond being burned on the OMG chain.By creating a custom chain with deep enforcement,we are able to construct a system where consensus rules optimize for high-performant activity.The design optimizes for rapid execution and clearing,with slower settlement.Future iterations may include sharding of the OMG chain,but the initial iteration will presume high-throughput capacity for block propagation.Owning OMG tokens buys the right to validate this blockchain,within its consensus rules.Transaction fees on the network including(but not limited to)payment,interchange, trading,and clearinghouse use,are given to non-faulty validators who enforce bonded con-tract states.The token will have value derived from the fees derived from this network,with the obligation/cost of providing validation to its users.This token must have value,to prevent low-cost attacks and is necessary to enforce this network.It may be on our roadmap to allow for delegating validation to third-parties,whereby a limited amount can be slashed at a time before re-delegation is required(the exact mecha-nism is not yet specified for security modeling).As this will be designed as a high-performant system,an linked-via-proof blockchain construction is necessary.We expect that this system will be able to handle extremely high volumes of transactions and hence,will only dofinal delivery over Ethereum.Clearing and settlement occurs over the OmiseGO blockchain.Consensus rules are enforced via this proof-of-stake network.As part of the consensus rules of this network,it is required that all OMG(Omise GO)validators also run the Ethereum network to validate in parallel, resulting in Ethereum as afirst-class citizen with regards to inter-blockchain validation.It is assumed for features such as Ethereum/ERC-20bonding and withdrawals that BLS signature schemes(or alternatively Schnorr)will be enabled in Ethereum in the near future.For cryptocurrencies,these tokens are non-custodial and instead locked in smart contracts(unlike other exchange platforms such as Ripple,which requires trusted gateways representing the underlying).It also does not rely on named centralized validation sets(e.g. Ripple).The OMG blockchain manages matching and managing order execution on the Ethereum chain.Activity on the OMG ensures the validator activity also may be enforced on the Ethereum chain via native Ethereum smart contracts.For Bitcoin and Bitcoin-like systems, we allow for trading via a clearinghouse network on the Lightning Network.The blockchain enforces activity on this network via committed proofs.While not as robust as Ethereum’s network,it allows for near-instantaneous clearing and settlement of activity orchestrated on the OMG chain without full-node validation.We expect to do partial validation in the future for nodes which do not allow for blockchain reorgs;naive SPV validation with blockchains that support reorgs are not permitted on this network for security.A detailed description of the consensus mechanism and security properties will be pro-vided by Joseph Poon of Exonumia Labs,Inc in a(currently in-progress)forthcoming paperin Summer2017.The construction of the paper(and subsequently with the implementa-tion used by OmiseGO)will likely be useful for many future open source token protocol blockchain projects,and may provide novel constructions for emerging chains such as cre-ating incentives for distributed data processing,and inter-blockchainfinancial activity.We hope OmiseGO and its distributed exchange will be a critical core in helping to lead the way in providing base-layer technologies/infrastructure which can spark and launch the en-tire protocol token ecosystem.Initial versions of OmiseGO may use aspects of Tendermint consensus.3.1Light Client ValidationWhile OmiseGO is constructed as a high-performance network capable of handling many transactions,it will become necessary to produce light client proofs for partial validation, as well as for external smart contract enforcement.A merkle tree of committed transactions per block will be included,as well as a com-mitment to the recent block state.The current state can be acquired by any node by downloading the recent block state commitment and any blocks between then.As the recent block state includes a tree of the recent state,clients are able to get a view of the recent commitment without downloading the entire chain.Note that this is only possible as there is sufficient economic incentive against reorganization and halting attacks; the OMG chain is designed to heavily disincentive block reorgs via bonded proofs,but does not provide guarantees around the need for block confirmations.Similar to current SPV Bitcoin validation implementations,there is some trust given to fullnodes with regards to censorship risk;we do not expect committed bloom maps to be feasible for the decentralized exchange given the transaction volume.Light clients can validate that a sufficient number of validators have processed the transactions,as well as any partial data acquired from fullnodes.It is heavily recommended for clients to validate activity on the Ethereum chain as well,due the OMG chain smart contract constructions.4eWalletsWhile OmiseGO supports payments,is not designedfirst and foremost a payment processor within a specific eWallet payment providers(EPP).It is our belief that there is no coordi-nation problem within a single EPP,and the coordination problem lies primarily between EPPs.However,due to the need for transactions between EPPs,payment activity may be conducted over a blockchain.This blockchain allows for the EPP to provide token issuance on OmiseGO.This allows forfiat-denominated currencies backed byfiat on the platform, or for any asset class(such as loyalty points).OmiseGO is an open system allowing for anyone to issue assets,but it is up to individual users(or EPPs acting on behalf of the users)to ensure correct issuance/auditing.This is achieved by creating issuance attached to a script(with private keys)which allows for issuance.An alternative approach would。

比特币白皮书一种点对点的电子现金系统1. 简介互联网上的贸易,几乎都需要借助金融机构作为可资信赖的第三方来处理电子支付信息.虽然这类系统在绝大多数情况下都运作良好,但是这类系统仍然内生性地受制于“基于信用的模式”(trust based model)的弱点.我们无法实现完全不可逆的交易,因为金融机构总是不可避免地会出面协调争端.而金融中介的存在,也会增加交易的成本,并且限制了实际可行的最小交易规模,也限制了日常的小额支付交易.并且潜在的损失还在于,很多商品和服务本身是无法退货的,如果缺乏不可逆的支付手段,互联网的贸易就大大受限.因为有潜在的退款的可能,就需要交易双方拥有信任.而商家也必须提防自己的客户,因此会向客户索取完全不必要的个人信息.而实际的商业行为中,一定比例的欺诈性客户也被认为是不可避免的,相关损失视作销售费用处理.而在使用物理现金的情况下,这些销售费用和支付问题上的不确定性却是可以避免的,因为此时没有第三方信用中介的存在.所以,我们非常需要这样一种电子支付系统,它基于密码学原理而不基于信用,使得任何达成一致的双方,能够直接进行支付,从而不需要第三方中介的参与.杜绝回滚(reverse)支付交易的可能,这就可以保护特定的卖家免于欺诈；而对于想要保护买家的人来说,在此环境下设立通常的第三方担保机制也可谓轻松加愉快.在这篇论文中,我们(we)将提出一种通过点对点分布式的时间戳服务器来生成依照时间前后排列并加以记录的电子交易证明,从而解决双重支付问题.只要诚实的节点所控制的计算能力的总和,大于有合作关系的(cooperating)攻击者的计算能力的总和,该系统就是安全的.2. 交易(Transactions)我们定义,一枚电子货币（an electronic coin）是这样的一串数字签名：每一位所有者通过对前一次交易和下一位拥有者的公钥(Public key) 签署一个随机散列的数字签名,并将这个签名附加在这枚电子货币的末尾,电子货币就发送给了下一位所有者.而收款人通过对签名进行检验,就能够验证该链条的所有者.该过程的问题在于,收款人将难以检验,之前的某位所有者,是否对这枚电子货币进行了双重支付.通常的解决方案,就是引入信得过的第三方权威,或者类似于造币厂(mint)的机构,来对每一笔交易进行检验,以防止双重支付.在每一笔交易结束后,这枚电子货币就要被造币厂回收,而造币厂将发行一枚新的电子货币；而只有造币厂直接发行的电子货币,才算作有效,这样就能够防止双重支付.可是该解决方案的问题在于,整个货币系统的命运完全依赖于运作造币厂的公司,因为每一笔交易都要经过该造币厂的确认,而该造币厂就好比是一家银行.我们需要收款人有某种方法,能够确保之前的所有者没有对更早发生的交易实施签名.从逻辑上看,为了达到目的,实际上我们需要关注的只是于本交易之前发生的交易,而不需要关注这笔交易发生之后是否会有双重支付的尝试.为了确保某一次交易是不存在的,那么唯一的方法就是获悉之前发生过的所有交易.在造币厂模型里面,造币厂获悉所有的交易,并且决定了交易完成的先后顺序.如果想要在电子系统中排除第三方中介机构,那么交易信息就应当被公开宣布（publicly announced）[1] ,我们需要整个系统内的所有参与者,都有唯一公认的历史交易序列.收款人需要确保在交易期间绝大多数的节点都认同该交易是首次出现. 3. 时间戳服务器(Timestamp server) 本解决方案首先提出一个“时间戳服务器”.时间戳服务器通过对以区块(block)形式存在的一组数据实施随机散列而加上时间戳,并将该随机散列进行广播,就像在新闻或世界性新闻组网络（Usenet）的发帖一样[2][3][4][5] .显然,该时间戳能够证实特定数据必然于某特定时间是的确存在的,因为只有在该时刻存在了才能获取相应的随机散列值.每个时间戳应当将前一个时间戳纳入其随机散列值中,每一个随后的时间戳都对之前的一个时间戳进行增强(reinforcing),这样就形成了一个链条（Chain）.4. 工作量证明（Proof-of-Work）为了在点对点的基础上构建一组分散化的时间戳服务器,仅仅像报纸或世界性新闻网络组一样工作是不够的,我们还需要一个类似于亚当•柏克（Adam Back）提出的哈希现金（Hashcash）[6] .在进行随机散列运算时,工作量证明机制引入了对某一个特定值的扫描工作,比方说SHA-256下,随机散列值以一个或多个0开始.那么随着0的数目的上升, 找到这个解所需要的工作量将呈指数增长,而对结果进行检验则仅需要一次随机散列运算.我们在区块中补增一个随机数(Nonce),这个随机数要使得该给定区块的随机散列值出现了所需的那么多个0.我们通过反复尝试来找到这个随机数,直到找到为止,这样我们就构建了一个工作量证明机制.只要该CPU耗费的工作量能够满足该工作量证明机制,那么除非重新完成相当的工作量,该区块的信息就不可更改.由于之后的区块是链接在该区块之后的,所以想要更改该区块中的信息,就还需要重新完成之后所有区块的全部工作量.同时,该工作量证明机制还解决了在集体投票表决时,谁是大多数的问题.如果决定大多数的方式是基于IP地址的,一IP地址一票,那么如果有人拥有分配大量IP地址的权力,则该机制就被破坏了.而工作量证明机制的本质则是一CPU一票.“大多数”的决定表达为最长的链,因为最长的链包含了最大的工作量.如果大多数的CPU为诚实的节点控制,那么诚实的链条将以最快的速度延长,并超越其他的竞争链条.如果想要对业已出现的区块进行修改,攻击者必须重新完成该区块的工作量外加该区块之后所有区块的工作量,并最终赶上和超越诚实节点的工作量.我们将在后文证明,设想一个较慢的攻击者试图赶上随后的区块,那么其成功概率将呈指数化递减.另一个问题是,硬件的运算速度在高速增长,而节点参与网络的程度则会有所起伏.为了解决这个问题,工作量证明的难度(the proof-of-work difficulty)将采用移动平均目标的方法来确定,即令难度指向令每小时生成区块的速度为某一个预定的平均数.如果区块生成的速度过快,那么难度就会提高.5. 网络运行该网络的步骤如下：•1) 新的交易向全网进行广播；•2) 每一个节点都将收到的交易信息纳入一个区块中；•3) 每个节点都尝试在自己的区块中找到一个具有足够难度的工作量证明；•4) 当一个节点找到了一个工作量证明,它就向全网进行广播；•5) 当且仅当包含在该区块中的所有交易都是有效的且之前未存在过的,其他节点才认同该区块的有效性；•6) 其他节点表示他们接受该区块,而表示接受的方法,则是在跟随该区块的末尾,制造新的区块以延长该链条,而将被接受区块的随机散列值视为先于新区快的随机散列值.节点始终都将最长的链条视为正确的链条,并持续工作和延长它.如果有两个节点同时广播不同版本的新区块,那么其他节点在接收到该区块的时间上将存在先后差别.当此情形,他们将在率先收到的区块基础上进行工作,但也会保留另外一个链条,以防后者变成最长的链条.该僵局（tie）的打破要等到下一个工作量证明被发现,而其中的一条链条被证实为是较长的一条,那么在另一条分支链条上工作的节点将转换阵营,开始在较长的链条上工作.所谓“新的交易要广播”,实际上不需要抵达全部的节点.只要交易信息能够抵达足够多的节点,那么他们将很快被整合进一个区块中.而区块的广播对被丢弃的信息是具有容错能力的.如果一个节点没有收到某特定区块,那么该节点将会发现自己缺失了某个区块,也就可以提出自己下载该区块的请求.6. 激励我们约定如此：每个区块的第一笔交易进行特殊化处理,该交易产生一枚由该区块创造者拥有的新的电子货币.这样就增加了节点支持该网络的激励,并在没有中央集权机构发行货币的情况下,提供了一种将电子货币分配到流通领域的一种方法.这种将一定数量新货币持续增添到货币系统中的方法,非常类似于耗费资源去挖掘金矿并将黄金注入到流通领域.此时,CPU 的时间和电力消耗就是消耗的资源.另外一个激励的来源则是交易费（transaction fees）.如果某笔交易的输出值小于输入值,那么差额就是交易费,该交易费将被增加到该区块的激励中.只要既定数量的电子货币已经进入流通,那么激励机制就可以逐渐转换为完全依靠交易费,那么本货币系统就能够免于通货膨胀.激励系统也有助于鼓励节点保持诚实.如果有一个贪婪的攻击者能够调集比所有诚实节点加起来还要多的CPU计算力,那么他就面临一个选择：要么将其用于诚实工作产生新的电子货币,或者将其用于进行二次支付攻击.那么他就会发现,按照规则行事、诚实工作是更有利可图的.因为该等规则使得他能够拥有更多的电子货币,而不是破坏这个系统使得其自身财富的有效性受损.7. 回收硬盘空间如果最近的交易已经被纳入了足够多的区块之中,那么就可以丢弃该交易之前的数据,以回收硬盘空间.为了同时确保不损害区块的随机散列值,交易信息被随机散列时,被构建成一种Merkle树（Merkle tree）[7]的形态,使得只有根(root)被纳入了区块的随机散列值.通过将该树（tree）的分支拔除（stubbing）的方法,老区块就能被压缩.而内部的随机散列值是不必保存的.不含交易信息的区块头（Block header）大小仅有80字节.如果我们设定区块生成的速率为每10分钟一个,那么每一年产生的数据位4.2MB.（80 bytes * 6 * 24 * 365 =4.2MB）.2008年,PC系统通常的内存容量为2GB,按照摩尔定律的预言,即使将全部的区块头存储于内存之中都不是问题.8. 简化的支付确认（Simplified Payment Verification）在不运行完整网络节点的情况下,也能够对支付进行检验.一个用户需要保留最长的工作量证明链条的区块头的拷贝,它可以不断向网络发起询问,直到它确信自己拥有最长的链条,并能够通过merkle的分支通向它被加上时间戳并纳入区块的那次交易.节点想要自行检验该交易的有效性原本是不可能的,但通过追溯到链条的某个位置,它就能看到某个节点曾经接受过它,并且于其后追加的区块也进一步证明全网曾经接受了它.当此情形,只要诚实的节点控制了网络,检验机制就是可靠的.但是,当全网被一个计算力占优的攻击者攻击时,将变得较为脆弱.因为网络节点能够自行确认交易的有效性,只要攻击者能够持续地保持计算力优势,简化的机制会被攻击者焊接的（fabricated）交易欺骗.那么一个可行的策略就是,只要他们发现了一个无效的区块,就立刻发出警报,收到警报的用户将立刻开始下载被警告有问题的区块或交易的完整信息,以便对信息的不一致进行判定.对于日常会发生大量收付的商业机构,可能仍会希望运行他们自己的完整节点,以保持较大的独立完全性和检验的快速性.9. 价值的组合与分割（Combining and Splitting Value）虽然可以单个单个地对电子货币进行处理,但是对于每一枚电子货币单独发起一次交易将是一种笨拙的办法.为了使得价值易于组合与分割,交易被设计为可以纳入多个输入和输出.一般而言是某次价值较大的前次交易构成的单一输入,或者由某几个价值较小的前次交易共同构成的并行输入,但是输出最多只有两个：一个用于支付,另一个用于找零（如有）.需要指出的是,当一笔交易依赖于之前的多笔交易时,这些交易又各自依赖于多笔交易,但这并不存在任何问题.因为这个工作机制并不需要展开检验之前发生的所有交易历史. 10. 隐私（Privacy）传统的造币厂模型为交易的参与者提供了一定程度的隐私保护,因为试图向可信任的第三方索取交易信息是严格受限的.但是如果将交易信息向全网进行广播,就意味着这样的方法失效了.但是隐私依然可以得到保护：将公钥保持为匿名.公众得知的信息仅仅是有某个人将一定数量的货币发所给了另外一个人,但是难以将该交易同特定的人联系在一起,也就是说,公众难以确信,这些人究竟是谁.这同股票交易所发布的信息是类似的,股票交易发生的时间、交易量是记录在案且可供查询的,但是交易双方的身份信息却不予透露.作为额外的预防措施,使用者可以让每次交易都生成一个新的地址,以确保这些交易不被追溯到一个共同的所有者.但是由于并行输入的存在,一定程度上的追溯还是不可避免的,因为并行输入表明这些货币都属于同一个所有者.此时的风险在于,如果某个人的某一个公钥被确认属于他,那么就可以追溯出此人的其它很多交易.11. 计算设想如下场景：一个攻击者试图比诚实节点产生链条更快地制造替代性区块链.即便它达到了这一目的,但是整个系统也并非就此完全受制于攻击者的独断意志了,比方说凭空创造价值,或者掠夺本不属于攻击者的货币.这是因为节点将不会接受无效的交易,而诚实的节点永远不会接受一个包含了无效信息的区块.一个攻击者能做的,最多是更改他自己的交易信息,并试图拿回他刚刚付给别人的钱.诚实链条和攻击者链条之间的竞赛,可以用二叉树随机漫步（Binomial Random Walk)来描述.成功事件定义为诚实链条延长了一个区块,使其领先性+1,而失败事件则是攻击者的链条被延长了一个区块,使得差距-1.攻击者成功填补某一既定差距的可能性,可以近似地看做赌徒破产问题（Gambler’s Ruin problem）.假定一个赌徒拥有无限的透支信用,然后开始进行潜在次数为无穷的赌博,试图填补上自己的亏空.那么我们可以计算他填补上亏空的概率,也就是该攻击者赶上诚实链条,如下所示[8]：假定p>q,那么攻击成功的概率就因为区块数的增长而呈现指数化下降.由于概率是攻击者的敌人,如果他不能幸运且快速地获得成功,那么他获得成功的机会随着时间的流逝就变得愈发渺茫.那么我们考虑一个收款人需要等待多长时间,才能足够确信付款人已经难以更改交易了.我们假设付款人是一个支付攻击者,希望让收款人在一段时间内相信他已经付过款了,然后立即将支付的款项重新支付给自己.虽然收款人届时会发现这一点,但为时已晚.收款人生成了新的一对密钥组合,然后只预留一个较短的时间将公钥发送给付款人.这将可以防止以下情况：付款人预先准备好一个区块链然后持续地对此区块进行运算,直到运气让他的区块链超越了诚实链条,方才立即执行支付.当此情形,只要交易一旦发出,攻击者就开始秘密地准备一条包含了该交易替代版本的平行链条.然后收款人将等待交易出现在首个区块中,然后在等到z个区块链接其后.此时,他仍然不能确切知道攻击者已经进展了多少个区块,但是假设诚实区块将耗费平均预期时间以产生一个区块,那么攻击者的潜在进展就是一个泊松分布,分布的期望值为：当此情形,为了计算攻击者追赶上的概率,我们将攻击者取得进展区块数量的泊松分布的概率密度,乘以在该数量下攻击者依然能够追赶上的概率.化为如下形式,避免对无限数列求和：写为如下C语言代码：#include double AttackerSuccessProbability(double q, int z){double p = 1.0 - q;double lambda = z * (q / p);double sum = 1.0;int i, k;for (k = 0; k <= z; k++){double poisson = exp(-lambda);for (i = 1; i <= k; i++)poisson *= lambda / i;sum -= poisson * (1 - pow(q / p, z - k));}return sum;}对其进行运算,我们可以得到如下的概率结果,发现概率对z值呈指数下降. 当q=0.1时z=0 P=1.0000000z=1 P=0.2045873z=2 P=0.0509779z=3 P=0.0131722z=4 P=0.0034552z=5 P=0.0009137z=6 P=0.0002428z=7 P=0.0000647z=8 P=0.0000173z=9 P=0.0000046z=10 P=0.0000012当q=0.3时z=0 P=1.0000000z=5 P=0.1773523z=10 P=0.0416605z=15 P=0.0101008z=20 P=0.0024804z=25 P=0.0006132z=30 P=0.0001522z=35 P=0.0000379z=40 P=0.0000095z=45 P=0.0000024z=50 P=0.0000006求解令P<0.1%的z值：为使P<0.001,则q=0.10 z=5q=0.15 z=8q=0.20 z=11q=0.25 z=15q=0.30 z=24q=0.35 z=41q=0.40 z=89q=0.45 z=34012.结论我们在此提出了一种不需要信用中介的电子支付系统.我们首先讨论了通常的电子货币的电子签名原理,虽然这种系统为所有权提供了强有力的控制,但是不足以防止双重支付.为了解决这个问题,我们提出了一种采用工作量证明机制的点对点网络来记录交易的公开信息,只要诚实的节点能够控制绝大多数的CPU计算能力,就能使得攻击者事实上难以改变交易记录.该网络的强健之处在于它结构上的简洁性.节点之间的工作大部分是彼此独立的,只需要很少的协同.每个节点都不需要明确自己的身份,由于交易信息的流动路径并无任何要求,所以只需要尽其最大努力传播即可.节点可以随时离开网络,而想重新加入网络也非常容易,因为只需要补充接收离开期间的工作量证明链条即可.节点通过自己的CPU计算力进行投票,表决他们对有效区块的确认,他们不断延长有效的区块链来表达自己的确认,并拒绝在无效的区块之后延长区块以表示拒绝.本框架包含了一个P2P电子货币系统所需要的全部规则和激励措施.注释 (↵returns to text)1.W Dai（戴伟）,a scheme for a group of untraceable digital pseudonyms to payeach other with money and to enforce contracts amongst themselves without outside help（一种能够借助电子假名在群体内部相互支付并迫使个体遵守规则且不需要外界协助的电子现金机制）, “B-money”, /bmoney.txt, 1998↵2.H. Massias, X.S. Avila, and J.-J. Quisquater, “Design of a securetimestamping service with minimal trust requirements,”（在最小化信任的基础上设计一种时间戳服务器）In 20th Symposium on Information Theory in the Benelux, May 1999.↵3.S. Haber, W.S. Stornetta, “How to time-stamp a digital document,”（怎样为电子文件添加时间戳）In Journal of Cryptology, vol 3, No.2, pages 99-111, 1991.↵4. D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency and reliability ofdigital time-stamping,”（提升电子时间戳的效率和可靠性）In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.↵5.S. Haber, W.S. Stornetta, “Secure names for bit-strings,”（比特字串的安全命名）In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. on Computer and Communications Security, pages 28-35, April 1997.↵6. A. Back, “Hashcash –a denial of service counter-measure,”（哈希现金——拒绝服务式攻击的克制方法）/papers/hashcash.pdf, 2002.↵7.R.C. Merkle, “Protocols for public key cryptosystems,”（公钥密码系统的协议）In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.S. Haber, W.S. Stornetta, “Secure names for bit-strings,”（比特字串安全命名）In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. on Computer andCommunications Security, pages 28-35, April 1997.H. Massias, X.S. Avila, and J.-J. Quisquater, “Design of a securetimestamping service with minimal trust requirements,”（在最小化信任的条件下设计一种时间戳服务器）In 20th Symposium on Information Theory in the Benelux, May 1999.↵8.W. Feller, “An introduction to probability theory and its applications,”（概率学理论与应用导论）1957↵。

比特儿Bter交易平台竞争币大盘点
随着比特币被爆炒，也带火了很多中国国产数字货币，它们在业内被统一称为“山寨币”，比如无限币、量子链、狗狗币等。

一些币种在面市后，交易价格波动幅度起伏较大，引来了不少投机客参与交易。

无疑，数字货币已经受到了越来越多投资客的关注。

那么，目前国内有哪些竞争币呢？
马上进入史上最全的比特儿竞争币大盘点（上）：
比特儿Bter数字货币交易平台，成立于2013年，是国内第四大数字货币交易所，Alexa流量排名位居国内交易平台第一位。

多年致力于为用户提供安全、快捷、公平、公证的数字货币交易平台，以高质量的技术服务保证用户交易信息和资金的安全。

数字货币火热的今天，比特儿Bter扛起了行业大旗，不断对平台进行优化。

目前平台内的国外注册用户占近半数，平台也将以更加国际化的视角开放对ICO创新币的上线，以此来为用户提供更多的选择。

V-by-One® HS StandardVersion 1.3July. 7, 20101Table of ContentsTable of Contents (2)1.Introduction (4)1.1.Objectives (4)1.2.Technical Overview (4)1.2.1.Transmitter (5)1.2.2.Receiver (5)1.2.3.Data Lane (5)1.2.4.HTPDN signal (7)1.2.5.LOCKN signal (7)2.Link Specification (8)2.1.Functional Specification (9)2.1.1.Packer and Unpacker (9)2.1.2.Scrambler and Descrambler (14)2.1.3.Encoder and Decoder (17)2.1.4.Serializer and Deserializer (18)2.1.5.Link status monitor (19)2.2.Operating Specification (20)2.2.1.Transmitter State Diagram (20)2.2.2.Receiver State Diagram (21)2.2.3.Link Start up flow (22)2.2.4.Link Disable flow (23)2.2.5.Trainings (24)3.Electrical Specification (28)3.1.Overview (28)3.2.Transmitter Electrical Specifications (29)3.3.Receiver Electrical Specifications (33)3.4.Eye Diagram Measurement Setting (35)3.5.Power on/off and Power down specification (35)3.6.Optional functions (35)3.6.1.Pre-emphasis (35)3.6.2.Equalizer (35)4.Color Mapping and Lane Stripping (36)4.1.Byte length and Color mapping (36)24.2.Multiple Data Lane combination (38)4.2.1.Allocation of pixel to Data Lane (38)4.2.2.Inter-lane skewing (39)4.2.3.RGB+CMY color mode (39)4.3.3D frame identification (40)4.3.1.3D flag on blanking period (40)4.3.2.3D flag on DE active period (41)5.Connector and Cable (42)5.1.Pin assignments (42)5.1.1. 1 lane connection (HD@60Hz) (42)5.1.2. 2 lane connection (HD@120Hz and F-HD@60Hz) (43)5.1.3. 4 lane connection (HD@240Hz and F-HD@120Hz) (44)5.1.4.8 lane connection (F-HD@240Hz and 4Kx2K@60Hz) (46)5.1.5.16 Lane connection (F-HD@480Hz and 4Kx2K@120Hz) (48)5.1.6.32 Lane connection (4Kx2K@240Hz) (50)5.2.Option pins (50)5.3.Connector Characteristics (51)5.3.1.Electrical (51)5.3.2.Recommended Receptacle Interface Dimensions (51)5.4.PCB Layout Considerations (52)6.Glossary (53)7.Revision history (54)8.Notice and Requires (55)34561.2.3.2.Data lane considerationThis chapter is informative only. It shows the procedure to select the minimum and maximum number of lanes necessary for the target application.As a 1st step, [byte mode] (please refer to 2.1.1.4) is chosen from 3, 4, or 5 depending upon color depth. Literally 3, 4, or 5 byte mode convey nominal 3, 4, or 5byte data. For example, 10bit per color RGB image requires 30 bit data per pixel; therefore, 4 byte mode which conveys 4 byte (32 bit) is enough to carry the data.As a 2nd step, total bit rate which is physically transmitted on V-by-One® HS line should be estimated. Because V-by-One® HS uses 8b10b encoding scheme, encoded data amount which is physically transmitted is 10bit per nominal decoded 8bit (1 byte) of original data. Multiplying [pixel clock] of the target application by encoded data amount per pixel results into [encoded total bit-rate] of V-by-One® HS transmission.[encoded bit-rate per lane] can be calculated as [total bit rate] over [number of lanes][number of lanes] should be chosen properly so that [encoded bit-rate per lane] is above 600Mbps and below 3.75Gbps.[number of lanes] should be selected appropriate to signal handling in applications. For example, in case of video signal transmission, [number of lanes] is recommended to be divisor of Hactive, Hblank, and Htotal pixel number like 1, 2, 4, 8, etc. in order to help signal processing.73637384.2.2.Inter-lane skewingAllowable Inter-lane skew is defined as tRISK. Refer to Section 3.3.V-by-One® HS Transmitter is not required to make any intentional inter-lane skew between lanes.4.2.3.RGB+CMY color modeIf the Transmitter and the Receiver adopt the RGB+CMY (6 color mode) transmission, twice of the lanes are used for the RGB and CMY. In the CMY lanes, the positions of the C data, M data, and Y data are mapped at the positions of the R data, G data, and B data in the Table 11, respectively.394.3.3D frame identification3D display may have identification on every frame. Methods to label 3D information on frame are described. The description of 3D data allocation in this chapter is informative. Actual application may be different.2 possible alternatives are introduced in this chapter; however, to apply both methods at the same time is not recommended. Users have to choose one explicit method for their application.4.3.1.3D flag on blanking periodPacker and Unpacker data mapping in Table 2 and Table 3 show that there is a potential to send arbitrary data on V-by-One® HS during blanking period. One way to carry 3D information is to make use of CTL data mapping.4.3.1.1.CTL data allocation to 3D flagIt is suggested that CTL<0> and CTL<1> be used for 3D signaling. These signals correspond to CTL<1:0> in Table 2 and Table 3.CTL<0> = Left/Right IndicatorCTL<0> = high (1) Î the next frame is the Left ViewCTL<0> = low (0) Î the next frame is the Right ViewCTL<1> = 3D Mode EnableCTL<1> = high (1) Î 3D video is being transmittedCTL<1> = low (0) Î 2D video is being transmitted4.3.1.2.CTL data timing of 3D flagCTL<1:0> should update on the first pixel of the FSBP in the Vertical Blanking Period and remain constant for the remainder of the FSBP in the Vertical Blanking Period. CTL<1:0> should only update during the Vertical Blanking period. The first pixel of the FSBP is recommended to be used for processing.Use of CTL<1:0> is implementation specific. In one case, it may apply to the active video that immediately follows the Vertical Blanking Period. In other applications it may apply to a later frame.404.3.2.3D flag on DE active periodThe color data mapping in Table 11 and Table 12 show that there are unused bits depending on the colors and byte mode used. It is possible (and allowable) to make use of these unused bits to carry the 3D information.4.3.2.1.Color data mapping allocation to 3D flag3D information can be conveyed using the 3DLR and 3DEN bits in Table 11 The 30bpp RGB/CrYCb 4 byte mode and 36bpp RGB/CrYCb 5 byte of Table 11 show the recommended placement of these controls.3DLR = Left/Right Indicator3DLR = high (1) Î the next frame is the Left View3DLR = low (0) Î the next frame is the Right View3DEN = 3D Mode Enable3DEN = high (1) Î 3D video is being transmitted3DEN = low (0) Î 2D video is being transmitted4.3.2.2.Color data mapping timing of 3D flag3DLR and 3DEN of the first pixel in particular frame is recommended to be used for processing.Use of 3DLR and 3DEN is implementation specific. In one case, it may apply to the current frame. In other applications it may apply to a later frame.41424344454647484950(a) Drawings(b) FootprintFigure 28 PCB Mount Receptacle drawings (recommended)Table 21 Form Factor of ReceptacleA B C D E F22.85 20.46 16 10 10 16 1027.85 25.46 21 15 15 21 1532.85 30.46 26 20 20 26 2037.85 35.46 31 25 25 31 25515253548.Notice and Requires1. THIS DOCUMENT AND RELATED MATERIALS AND INFORMATION ARE PROVIDED "AS IS" WITH NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. THINE ASSUMES NO RESPONSIBILITY FOR ANY ERRORS CONTAINED IN THIS DOCUMENT AND HAS NO LIABILITIES OR OBLIGATIONS FOR ANY DAMAGES ARISING FROM OR IN CONNECTION WITH THE USE OF THIS DOCUMENT.2. THine may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights that relate to the presented subject matter. The furnishing of documents and other materials and information does not provide any license, express or implied, by estoppels or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights.3. This material contains our copy right, know-how or other proprietary. Copying without our prior permission is prohibited.4. The specifications described in this material are subject to change without prior notice.5. THine shall have no obligation to provide any support, installation or other assistance with regard to the information or products made in accordance with it.6. THine, V-by-One, THine logo and V-by-One logo are trademarks or registered trademarks of THine or its subsidiaries in JAPAN and other countries.55。

Poly--Service bv Hoogevenenweg 83, 2913 LV Nieuwerkerk aan den IJssel, phone +31 180 – 31 47 77, www.polyservice.nl Page 1 van 1 H.J.E. Wenckebachweg 49a, 1096 AK Amsterdam, phone +31 20 – 665 45 69, e-mail *******************DOCUMENTATION, PROCESSING AND OTHER ADVICE ARE ALWAYS PROVIDED WITHOUT OBLIGATION. HOWEVER, WE CANNOT ACCEPT LIABILITY EVEN WITH REGARD TO PATENTS. ALL OUR DELIVERY IS SUBJECT TO THE UNIFORM TERMS AND CONDITIONS OF SALE AND DELIVERY FOR PAINT AND PRINTING INK AND OTHERS, FILED AT THE REGISTRY OF THE DISTRICTCOURT IN AMSTERDAMManualEPOXY REMOVERApplication of Epoxy RemoverEpoxy Remover can be used to remove old layers of epoxy sealant on the inside of your steel petrol or oil tank. First remove all the petrol and rinse the tank with water. Thoroughly dry your tank and let it cool down completely before you put the remover in the tank.Epoxy Remover will damage paint and tank gaskets. Therefore, wrap your tank in a plastic bag and tape around the filling opening. Tightly close the opening of the fuel tap. Make sure you also have a suitable seal for the filling opening of the tank.Ensure good ventilation (outside air), gloves, protective clothing and safety goggles before opening the can of Epoxy Remover. Avoid breathing vapor. Pour the Epoxy Remover into the tank and close the filling opening. Shake the tank gently for a few seconds to ensure the Epoxy Remover spreads throughout the tank. Then open the filling opening briefly to allow any excess pressure to escape. Don't forget your safety goggles and gloves. Never place your tank filled with Epoxy Remover in direct sunlight, but in a cool and well-ventilated place. Leave the Epoxy Remover in the tank for a day, after which you drain the remainder (outside!). The old epoxy coating in your tank will come out in small flakes. Rinse the tank with plenty of water. Before applying a new layer of coating, clean the tank thoroughly with Tank Cure Cleaner and treat it with the Tank Cure Rust Remover. Important instructions for the use of Epoxy Remover:Epoxy Remover may only be used in steel tanks.Definitely do not use in plastic tanks (chemical reaction)Never pour Epoxy Remover into a heated tank.Do not store in the sun or near heat sources.Keep away from heat/sparks/open flames hot surfaces. Do not smoke.Do not use Epoxy Remover in combination with other substances.Do not use Epoxy Remover in tanks with petrol or oil residue.It is recommended to work with Epoxy Remover outdoors.After using the remover ALWAYS rinse the tank thoroughly with water and Tank Cure CleanerOnly use rust remover (acid) after the tank has been rinsed with water and with Tank Cure Cleaner Do not expose tank to high temperatures when using Epoxy Remover.StorageStore in a well closed container in a well-ventilated and cool place. Keep away from sources of ignition.Do not store in the sun or near heat sources.Keep out of reach of children.Dispose of residues as chemical waste. V160223 DisclaimerThe data in this sheet is based on years of product development and practical experience and is correct on the day of issue. Nevertheless, Poly-Service BV cannot accept any liability for the work produced according to this information, as the result is partly determined by factors that are beyond our responsibility and influence. Poly-Service BV reserves the right to make changes to this sheet without notice. This product sheet supersedes all previous editions.。

SECURITY AND PRIVACY WHITE PAPERPoly Edge B Series DevicesPart 3833-87725-001Version 03November 2023IntroductionThis white paper addresses security and privacy related information regarding Poly Voice OS-Lite (PVOS-L) for Poly Edge B Series devices.This paper also describes the security features and access controls in HP | Poly’s processing of personally identifiable information or personal data (“personal data”) and customer data in connection with the provisioning and delivery of Poly Edge B Series devices, including the location and transfers of personal and other customer data.HP | Poly will use such data in a manner consistent with the HP Privacy Statement, and this white paper which may be updated from time to time. This white paper is supplemental to the HP Privacy Statement. The most current version of this white paper will be available on HP | Poly’s website.Poly Edge B Series devices use PVOS-L, the telecommunications industry’s most powerful and flexible SIP software for VoIP-enabled devices. HP | Poly’s software and award-winning product design are compatible with the broadest range of call control platforms and support highly robust provisioning and device management solutions, employing the broadest SIP feature set.Optional Integrations AvailableYour device natively supports the optional integrations as listed below. Please note that no data is shared with any other party until your device is configured to do so. Please consult the administrative guide for more detailed information.For security and privacy details related to these optional products and services, please refer to here.Security at HP | PolySecurity is always a critical consideration for all HP | Poly products and services. HP | Poly’s Information Security Management System (ISMS) has achieved ISO 27001:2013 certification. ISO/IEC 27001 is the most widely accepted international standard for information security best practices and you can be reassured that HP | Poly has established and implemented best-practice information security processes.Product security at HP | Poly is managed through the HP | Poly Security Office (PSO), which oversees secure software development standards and guidelines.The HP | Poly Product Security Standards align with NIST Special Publication 800-53, ISO/IEC27001:2013, and OWASP for application security. Guidelines, standards, and policies are implemented to provide our developers with industry-approved methods for adhering to the HP | Poly Product Security Standards.Secure Software Development Life CycleHP | Poly follows a secure software development life cycle (S-SDLC) with an emphasis on security throughout the product development processes. Every phase of the development process ensures security by establishing security requirements alongside functional requirements as part of the initial design. Architecture reviews, code reviews, internal penetration testing and attack surface analysis are performed to verify the implementation.The S-SDLC implemented by HP | Poly also includes a significant emphasis on risk analysis andvulnerability management. To increase the security posture of HP | Poly products, a defense-in-depth model is systematically incorporated through layered defenses. The principle of least privilege is always followed. Access is disabled or restricted to system services nonessential to standard operation.Standards-based Static Application Security Testing (SAST) and patch management are cornerstones of our S-SDLC.Privacy by DesignHP | Poly implements internal policies and measures based on perceived risks which meet the principles of data protection by design and data protection by default. Such measures consist of minimizing the processing of personal data, anonymizing personal data as soon as possible, transparently documenting the functions, and providing features which enable the data subject to exercise any rights they may have.When developing, designing, selecting, and using applications, services and products that are based on the processing of personal data or process personal data to fulfill their task, HP | Poly considers the right to data protection with due regard.Security by DesignHP | Poly follows Security by Design principles throughout our product creation and delivery lifecycle which includes considerations for confidentiality, integrity (data and systems) and availability. These extend to all systems that HP | Poly uses – both on-premises and in the cloud as well as to the development, delivery, and support of HP | Poly products, cloud services and managed services.The foundational principles which serve as the basis of HP | Poly’s security practices include:1. Security is required, not optional2. Secure by default, Secure by design3. Defense-in-depth4. Understand and assess vulnerabilities and threats5. Security testing and validation6. Manage, monitor, and maintain security posture7. End-to-end security: full lifecycle protectionSecurity TestingBoth static and dynamic vulnerability scanning as well as penetration testing are regularly performed for production releases and against our internal corporate network by both internal and external test teams.Patches are evaluated and applied in a timely fashion based on perceived risk as indicated by CVSSv3 scores.Change ManagementA formal change management process is followed by all teams at HP | Poly to minimize any impact on the services provided to the customers. All changes implemented for the Poly EdgeB Series go through vigorous quality assurance testing where all functional and security requirements are verified. Once Quality Assurance approves the changes, the changes are pushed to a staging environment for UAT (User Acceptance Testing). Only after final approval from stakeholders, changes are implemented in production. While emergency changes are processed on a much faster timeline, risk is evaluated, and approvals are obtained from stakeholders prior to applying any changes in production.Data CollectionBy default, no product usage data or identifiable personal data is sent to HP | Poly from Poly Edge B Series devices. However, if certain settings are enabled, HP | Poly automatically collects and analyzes product usage data and device data from your Poly Edge B Series devices. Data collected will be used for the purposes identified in the table following this section. To enable data collection, please see the “Device Analytics Settings” section in the “Privacy Guide for Poly Edge B Series”.If you are an individual user of a Poly Edge B Series device, and your employer has purchased and configured the system on your behalf, all the privacyinformation relating to personal data in this white paper is subject to your employer’s privacy policies as controller of such personal data.Data ProcessingBy default, the following list provides some of the information that is processed and stored locally on Poly Edge B Series devices:•MAC address•Serial number •Line name•IPv4/v6 addresses•SIP username•SIP URI•SIP alias name•Obi number•Local contacts•Admin and usernames •Admin and user passwords•Missed/Placed/Received Call lists•Full Call detail record (CDR)•System log files•Directory entries•Offset GMTThis information is used by the device to provide basic functionality and to enhance the user experience by providing easy access to call history and frequently used contacts.If you elect to enable the use of the Poly Edge B Series devices with the optional Poly Lens cloud service, your device will send information to that system for the purposes of device management, intelligent insights, and cloud-based services. For details about this data processing, please refer to the Security and Privacy White Paper for Poly Lens located here.If you elect to use Poly Edge B Series devices with optional products or services such as an HP | Poly device management solution, you can find security and privacy details related to these optional products and services at HP | Poly’s website located here.Purpose of ProcessingInformation that is processed is used for enhancing the user experience, allowing configuration of settings required for proper delivery of services and easy access to frequently used data.When configured to use an optional HP | Poly device management solution, the on-premises server or cloud service processes configuration files and their overrides to aid the management of the devices in a given deployment. The server or cloud service may also process device network information, media statistics and device asset information to aid in device analytics, which enables device performance validation and visibility into customer quality of experience and service performance. How Customer Data is Stored and ProtectedIn Poly Edge B Series devices, File Based Encryption is supported and by default this feature is enabled. Hence, all the user-created data is encrypted before writing onto the device using the ‘encrypted key’. Please note that the ‘encrypted key’ is derived based on the private key data of the device certificate. If the phone is configured to use an optional HP | Poly device management solution or provisioning server, the local contacts file, the device logs, and the call log will be securely uploaded to the solution for backup. There is also a configurable option for the user to stop uploading of the local contacts and call lists through a menu item accessible from the phone’s LCD interface.HP | Poly supports the use of encryption to protect configuration files and phone calls. For details, please see the Encryption section of the “Privacy Guide for Poly Edge B Series”.For the set of usage data sent to HP | Poly (if enabled), data is stored in a database server that is in an SSAE 16 Type II certified data center in the United States that runs dedicated databases and application servers. When the HP | Poly database server receives data from the customer, it is verified for integrity, processed, and saved in the database.Data PortabilityBy default, data is stored securely on the Poly Edge B Series device and is only accessible via the LCD menu or the device’s web interface.When a Poly Edge B Series device is configured to use an optional HP | Poly device management solution, certain information is uploaded using encrypted protocols to the server for backup and storage. This information can be retrieved by the administrator of a HP | Poly device management solution upon request.Data Deletion and RetentionFor clearing of the contacts, there is an option presented to the user under the Basic settings in phone’s LCD interface. A user can select this option to clear all the local contacts saved in the phone as well as the call lists and directory entries uploaded to the optional HP | Poly device management solution (if used). Additionally, factory reset is available for resetting back to factory default values. For details, please see the “Right to Erasure” section in the “Privacy Guide for Poly Edge B Series”.For the set of usage data sent to HP | Poly, HP | Poly may retain customer data for as long as needed to provide the customer with any HP | Poly cloud services for which they have subscribed and for product improvement purposes. When a customer makes a request for deletion to ******************, HP | Poly will delete all personal data within 30 days. Other unidentifiable data may continue to be processed.HP | Poly may “anonymize” personal data in lieu of deletion. The anonymization process is irreversible and includes but is not limited to searching and sanitizing all customer-specific data (e.g., name, site information and IP address) with randomly generated alphanumeric characters.Secure DeploymentFor enterprise customers, Poly Edge B Series devices are deployed and administered on-premises within the customer’s environment. For ITSPs, devices are deployed on-site but administered and provisioned from the cloud outside of the customer’s environment. Deployment options are available to support a variety of scenarios and work environments.The security of Poly Edge B Series devices is based on optional settings selected during local device setup or when provisioning is configured by the administrator. Please refer to the “Configuring Security Options” and “Recommended Security Settings for Provisioning” sections of the appropriate Poly Edge B Series Administrator Guide for details on best practices for securely deploying the phones. Please refer to the “Privacy Guide for Poly Edge B Series” for configuring privacy-related options.Server Access and Data SecurityAll customer data sent to an HP | Poly device management solution is encrypted both at rest and in transit using strong cryptography including AES-256 and TLS up to v1.2.All customer data sent to an HP | Poly device management solution is backed up daily in digital form. Normal access controls of authorized users and data security policies are followed for all backup data. No physical transport of backup media occurs. The backup data during rest and while in transit is encrypted using AES 256.Servers are in a secure data center, with only authorized staff members having access. The servers are not directly accessible from outside the data center.Cryptographic SecurityIf Poly Edge B Series devices are configured to use an optional HP | Poly device management solution, data transmitted can be encrypted by configuring the device to use TLS protocols as well as strong encryption ciphers for encrypting the packets transmitted over the network.•Device to HP | Poly Cloud Service▪HTTPS (443) using TLS 1.1, TLS 1.2Evaluating services on open TCP/UDPportso Compression: disabledo RFC 5746 renegotiationo Client-initiated: disabledo Ciphers:➢AES 128/256 (CBC, GCM)➢Key Exchange: DHE 2048,ECDHE 256➢SHA, SHA256, SHA384 hashing▪HP | Poly Cloud Service Device Connections (to local on-premises devices)▪HTTPS (443) using TLS 1.1, TLS1.2o Compression: disabledo RFC 5746 renegotiationo Client-initiated: disabledo Ciphers:➢AES 128/256 (CBC, GCM),Camellia 128/256 (CBC)➢Key Exchange: ECDHE 256,RSA➢SHA, SHA256, SHA384 hashingFor data at rest, please see the section “How Customer Data is Stored and Protected” later in this white paper.AuthenticationUser and administrator accounts can be authenticated either locally on the devices or via the customer’s Active Directory. Users can access Poly Edge B Series devices using the phone’s LCD menu display or the device’s web interface. A separate password is required to be entered to access the administrator settings menu. Access to the device’s web interface requires a username and password to be entered via a web browser. Accessing the device through the LCD menu requires an unlock PIN to be entered manually (when the phone lock feature is enabled).Security Incident ResponseThe HP | Poly Security Office (PSO) promptly investigates reported anomalies and suspected security breaches on an enterprise-wide level. You may contact the PSO directly at**************************The PSO team works proactively with customers, independent security researchers, consultants, industry organizations, and other suppliers to identify possible security issues with HP | Poly products and networks. HP | Poly security advisories and bulletins can be found on the HP Customer Support website.SubprocessorsHP | Poly uses certain subprocessors to assist in providing our products and services. A subprocessor is a third-party data processor who, on behalf of HP | Poly, processes customer data. Prior to engaging a subprocessor, HP | Poly executes an agreement with the subprocessor that is in accordance with applicable data protection laws.The subprocessor list here identifies HP | Poly’s authorized subprocessors and includes their name, purpose, location, and website. For questions, please contact ******************.Prior to engagement, suppliers that may process data on behalf of HP | Poly must undergo a privacy and security assessment. The assessment process is designed to identify deficiencies in privacy practices or security gaps and make recommendations for reduction of risk. Suppliers that cannot meet the security requirements are disqualified.Additional ResourcesTo learn more about the Poly Edge B Series, visit our product website.DisclaimerThis white paper is provided for informational purposes only and does not convey any legal rights to any intellectual property in any HP | Poly product. You may copy and use this paper for your internal reference purposes only. HP | POLY MAKES NO WARRANTIES, EXPRESS OR IMPLIED OR STATUTORY AS TO THE INFORMATION IN THIS WHITE PAPER. THIS WHITE PAPER IS PROVIDED “AS IS” AND MAY BE UPDATED BY HP | POLY FROM TIME TO TIME. To review the most current version of this white paper, please visit our website.© 2023 HP, Inc. All rights reserved. Poly and the propeller design are trademarks of HP, Inc. The Bluetooth trademark is owned by Bluetooth SIG, Inc., and any use of the mark by HP, Inc. is under license. All other trademarks are the property of their respective owners.。

比特币：一种点对点的电子现金系统中本聪【2008年】著摘要.一个完全的点对点版本的电子现金将允许一方不通过金融机构直接在线支付给另一方。

电子签名提供了部分解决方案，但是如果还需要一个可信任的第三方来防止双花，那么这个最大的好处也就没有意义。

我们提出一个用点对点网络来解决双花的方案。

这个网络给每笔交易打上时间戳，并进行哈希计算，放进一条基于哈希工作量证明的链，这形成了一个不可改变的记录，除非重做这些工作量。

最长的链不仅是见证序列的证明，还证明了它来自最大的CPU算力池。

因为大部分的算力由诚实的节点控制，他们将会产生一条比攻击者要长的链。

网络本身需要极小化结构。

消息被尽力广播，并且节点可以随意离开或重新加入网络，接受最长的工作量证明的链作为它离开这段时间发生事情的证明。

1．介绍互联网上的商业几乎完全依赖信任的第三方金融机构来处理电子支付。

对于大多数交易来说，这套系统工作的足够好了，但是依然受到了基于信任模型的天然缺点的困扰。

完全不能撤销的交易是不可能的，因为第三方金融机构不可避免的要调解纠纷。

调解的代价增加了交易的成本，限制了最小实际交易的大小，切断了临时交易的可能性，丧失了对不可撤销服务提供不可撤销支付的可能性，这又是一个广义成本。

因为撤销的可能性，信任的需要不断蔓延开来。

商户必须堤防他们的客户，越来越多的他们本不该需要的信息困扰着他们。

不得不接受一定比例的骗子。

这些成本和支付的不确定问题可以用面对面使用现金避免，但是还没有机制存在使得通过通信信道支付而不需要信任的第三方。

2008年11月1日，一个化名为中本聪（Satoshi Nakamoto）的神秘密码学极客在网络上发布了这部比特币白皮书。

中本聪在2010年底离开该项目，以后关于他的身世、国籍、去向都成为谜团。

摘要中总结了比特币的要点：定位：一个完全点对占的电子现金系统。

核心价值：允许一方不通过金融机构直接在线支付给另一方。

核心技术：电子签名、交易时间戳、基于哈希工作量证明的链（也就是区块链）等。

白皮书White Paper原链——让世界没有难做的链官网：Yuan Chain-An Easy Way to Build Blockchain目录1.前言 (3)2.原链 (4)2.1原链简介 (4)2.2优势 (5)2.3应用场景 (10)3.原链代币YCC (15)3.1YCC简介 (15)3.2YCC分配和使用 (16)3.3ICO细则 (17)4.团队核心成员介绍 (19)4.1核心成员 (19)4.2顾问成员 (20)4.3早期投资人 (21)5.开发实施计划 (21)5.1技术开发 (21)6.基金会与管理 (21)6.1原链基金会的设立 (21)6.2原链基金会治理架构 (22)6.3联席代表委员会 (22)1.前言区块链作为基于价值的新一代互联网，在不需要中间人的情况下，使没有信任关系的用户之间完成无风险交易。

区块链可以记录每个用户不可篡改的信息或交易记录，形成用户的信用，比如个人信息资料、企业合同、商品仓单、产权、事件等，用户可以使用区块链来证明自己的信用，无需依赖第三方，有信用的个人和企业更容易获得低成本的融资及其他社会经济资源。

但是,个人和企业在区块链真正的落地面临三难:应用场景难找,懂区块链技术的开发团队难找，区块链安全难实现。

原链的愿景是提供SaaS（软件即服务）解决这三个区块链落地的难题。

个人和企业不需要支付昂贵的开发费用，只需要按照需求支付软件使用的费用,就可以享受安全的区块链服务。

原链区块链就是一个紧密的公链、联盟链、私链的生态圈，个人、企业、政府都可以深度参与其中。

原链是由多层次的链组成，每一层次可以包括多条链。

链与链之间能够通过主链互通信息和交换价值，用户拥有自己信息的所有权，在提供尽量少的隐私信息的情况下，可与他人合作。

这避免了中心化系统大量个人信息被盗的可能性。

原链的主链是稳定、易用、易连接。

高并发的公链，联盟链是专业的标准化的链，私链是个性化和私密性强的链，还有很多中介链、统计链。

目录修订记录Revision record .............................................................. E rror! Bookmark not defined.同步以太技术白皮书 .. (iv)1 背景 (1)2 同步以太的同步原理 (2)3 同步以太的SSM功能 (5)3.1 同步以太的SSM质量等级定义 (5)3.2 同步以太如何传递SSM信息 (6)3.3 同步以太的SSM协议如何工作 (8)3.4 在什么情况下会成环 (10)4 同步以太的设备模型 (13)5 同步以太的组网要求 (14)6 同步以太技术的总结 (15)7 参考标准 (16)插图目录图2-1 同步以太示意图 (2)图3-1 SyncE中的SSM信息传递 (8)图3-2 SSM协议工作原理 (9)图3-3 SSM协议状态机 (10)图3-4 无SSM的场景 (11)图3-5 有SSM的场景 (11)图5-1 G.803推荐的物理层同步组网要求 (14)表格目录表2-1 以太接口的同步以太支持能力 (3)表3-1 表－ESMC报文格式 (6)表3-2 表：QL TLV格式 (7)同步以太技术白皮书同步以太技术白皮书同步以太技术白皮书关键词：同步以太,SyncE、SSM摘要：本文主要介绍同步以太和NTR技术，包括同步以太和NTR的同步原理、SSM保护倒换原理以及相关的标准体系等内容。

缩略语：同步以太技术白皮书 1 背景1 背景全IP化是未来网络和业务发展的趋势，这已被业界公认，移动网络也是如此。

在移动网络向全IP逐步推进的过程中，也对如何实现时钟同步提出了新的需求和挑战。

众所周知，分组交换网络用于突发性数据通信的传输，其中信息在源处封装成分组，这些分组通过网络节点(如交换机和路由器)以存储转发的方式传输，直至到达目的地。

因此分组网络和原来的电路交换网络有着很大不同，在本质上是异步的。