Pith. sign in

REVIEW 3 major objections 6 minor 1 cited by

Retrofitting a two-way peg between blockchains

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper constructs a forkless two-way Dogecoin-Ethereum peg: Operator ETH collateral backs minted WOW tokens, and disputes over relayed Dogecoin locks are settled by bulletproofs verified through Truebit.

desk verdict A detailed, honest design for a forkless Dogecoin-Ethereum peg whose 'trustless' claim depends on an unstated liveness assumption that someone will always challenge bogus relay submissions. read the letter →

arxiv 1908.03999 v1 pith:HJNTLABE submitted 2019-08-12 cs.CR cs.LOecon.TH

Jason Teutsch , Michael Straka , Dan Boneh This is my paper · ORCID
classification cs.CRcs.LOecon.TH
keywords Dogethereumtwo-waypegcollateralizedcross-chainbridgecryptoeconomicsecuritybulletproofsTruebitparametrizedtokens
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Dogecoin can be moved onto Ethereum without forking either chain: this paper specifies a two-way peg in which an Operator's ETH collateral, held in an Ethereum Bridge Contract, backs newly minted WOW tokens while the corresponding DOGE sits in the Operator's Dogecoin address. Burning WOW later obligates the Operator to release DOGE, and if the Operator defaults, the collateral is forfeited to the token holder. A relay conveys Dogecoin blocks into Ethereum under a unanimous-consensus rule that rejects orphaned chains, and disputes are resolved by succinct bulletproofs of scrypt proof-of-work verified through the Truebit protocol. Parametrized tokens WOW[$y$], indexed by exchange rate, keep the reserve balanced without a price oracle. If the construction is right, Dogecoin gains smart-contract access and the same recipe extends to Bitcoin.

What carries the argument

The load-bearing object is the Bridge Contract, an Ethereum smart contract that escrows Operator ETH collateral, mints and burns parametrized WOW[$y$] tokens, and maintains the relay's history. The core mechanism is the collateralized peg: locked DOGE is not locked in the Dogecoin sense but is held by an Operator whose ETH deposit is forfeitable, so economic incentives substitute for a lock opcode. The relay's valid-extension requirements — Maximality, Validity, and Shallow-fork-free — are enforced through a challenge protocol; a challenged submission must be backed by a bulletproof, a succinct proof that a committed arithmetic circuit is satisfiable, showing that the committed block sequence is a valid, confirmed chain of scrypt proof-of-work, and Truebit verifies that proof on-chain.

What would settle it

Run a testnet where every participant except one malicious Relayer is passive; the Relayer submits a fabricated lock with a valid-looking Merkle commitment and no one challenges. If the Bridge Contract mints WOW[$y$] after the verification timeout even though no DOGE is actually controlled by an Operator, the unanimous-consensus security claim is refuted in exactly the case the invariants depend on.

Watch

Extended reading notes

Core claim

The central claim is that a 'lock' on Dogecoin does not have to be a consensus-level operation. In this design it is a cryptoeconomic fact: an Operator who has posted ETH collateral accepts DOGE into an address she controls, the Bridge Contract treats that transfer as a lock and mints WOW[$y$] to the sender, and if the Operator spends the DOGE before the corresponding WOW[$y$] is burned, she loses her ETH. The relay that carries Dogecoin events into Ethereum accepts only extensions that are maximal, valid, and shallow-fork-free, so orphaned block submissions cannot pollute the history. Disputed extensions are settled by a bulletproof that a committed sequence of scrypt proof-of-work is a confirmed valid extension of the history, with the proof itself checked by Truebit. Under the paper's rational-actor assumptions, two reserve invariants follow: WOW[$y$] in circulation equals $y$ times the ETH collateralized at rate $y$, and, per exchange-rate class, the number of locked DOGE equals the number of WOW[$y$] in circulation.

Load-bearing premise

The load-bearing premise is that Hodlers, Operators, and Crossers will actively monitor Dogecoin and the Bridge Contract and challenge bogus relay submissions before the timeout; the paper also assumes away block-withholding and 51% attacks, so a passive user base can leave a malicious relayer free to mint unbacked WOW.

Editorial extensions

If this is right

  • A DOGE holder can receive WOW[$y$] tokens in Ethereum within minutes of a lock, and can burn them to reclaim DOGE, with no Dogecoin client update.
  • Ethereum smart contracts can read Dogecoin data through the same relay, giving Dogecoin a form of smart-contract functionality.
  • The same construction adapts to Bitcoin, letting Ethereum smart contracts hold tokenized bitcoin and access Bitcoin data.
  • Parametrized WOW tokens keep the peg solvent under exchange-rate moves down to the threshold $y$, without any price oracle.
  • The bridge remains live with any number of participants and is snoozable: it consumes gas only when used.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The passive-participant case is the real stress test: if few users monitor the relay, the unanimous-consensus design degrades toward first-submitter-wins, and a testnet with deliberately passive users would reveal the minimum active-Relayer population needed to keep the invariants.
  • The collateralized peg is a general pattern: pairing any Nakamoto-consensus chain with an expressive smart-contract chain reduces to building an arithmetic circuit for the source chain's hash, and the paper's Bitcoin extension already exhibits this.
  • Parameterized tokens could be reused outside bridges, for example to keep any smart-contract escrow solvent under exchange-rate volatility without an oracle; the paper uses them narrowly but the construction is not peg-specific.
  • The deep-backtracking modes imply a residual liveness gap: a sufficiently long bogus extension can stall the bridge permanently, which the authors accept only because it happens when no one is using the system; a deployment would want a stronger liveness mechanism.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper proposes Dogethereum, a two-way peg between Dogecoin and Ethereum that requires no fork. An Operator posts ETH collateral in a Bridge Contract; a Crosser sends DOGE to the Operator's address; a Relayer relays the lock to Ethereum; the Bridge Contract mints WOW tokens; burning WOW triggers a DOGE unlock or forfeiture of the Operator's ETH collateral. The relay uses Merkle commitments and challenge-based verification, with bulletproofs and Truebit to verify scrypt proofs-of-work in disputes. The paper claims the construction is efficient, trustless, and retrofitting, and it argues via invariants in Section 5.1 that rational agents' monitoring keeps the reserves balanced. The paper also sketches an extension to Bitcoin/Ethereum and reports extrapolated performance estimates for scrypt bulletproof verification.

Significance. If the security claim held, this would be a significant contribution: a forkless, economically collateralized two-way peg with a permissionless relay, plus parametrized tokens to handle exchange-rate variability. The paper gives a detailed module-by-module specification that is useful for comparison with XCLAIM and with superblock relay designs, and it is unusually candid in Section 4.9 and Section 6 about the limits of the analysis and the uncompleted circuit implementation. However, the central 'trustless' claim is not established: the security argument assumes the availability and diligence of challengers, and the paper's own text concedes that an attacker gains when the bridge is actively in use but no one is watching. The protocol may be repairable by stating an explicit liveness assumption and by pairing the design with a formal game-theoretic proof, but as written the main claim overreaches.

major comments (3)
  1. [§4.4–4.6, §4.9] The relay's acceptance path is not secure against an unchallenged bogus submission. Under §4.5, the Bridge Contract appends a submission to its history when no challenge arrives within d−k Dogecoin blocks, without any on-chain validation of the Merkle commitment at that time. §4.6 then mints WOW against any commitment in the history, verifying only that a Merkle proof is consistent with the stored, adversary-chosen root. An attacker can therefore submit a fabricated commitment with a plausible range, wait out the timeout, present a Merkle proof of a fake 'lock' transaction from an attacker-controlled address to an open bridge head, and obtain WOW backed by an Operator's real ETH collateral; burning those WOW in §4.7 transfers the collateral to the attacker. §4.9 explicitly concedes that the attacker gains when 'ETH collateral is staked.' The only defense is a timely challenge, but nothing in the protocol guarantees that a challenger exists: §2.4(C) states that individual Relayers 'need not monitor Dogecoin continuously,' and the rationality assumptions in §2 do not imply continuous monitoring. The abstract's 'trustless' claim therefore depends on an unstated liveness assumption, and the claim as written is unsupported.
  2. [§5.1, Invariant 3] The reserve equilibrium argument assumes the behaviors it is supposed to establish. Invariant 3's hypotheses are that rational Hodlers report missing DOGE, that Operators challenge Relayers who relay bogus locks, and that Crossers challenge bogus relay submissions. These are exactly the vigilance conditions the protocol's incentives are meant to guarantee. The surrounding argument (§2.4, §5.4) only asserts that incentives 'exist'; it does not prove that some rational agent is always online, informed, and willing to bear the cost of challenging within the verification window. Consequently, Invariant 3 does not provide a security proof of the DOGE–WOW bijection; it states a conditional whose antecedent includes the property to be shown.
  3. [§6] The efficiency claim for the Dogecoin relay is not yet supported. The 12, 20, and 80 minute estimates for verifying 1, 10, and 100 Dogecoin proofs-of-work are extrapolations from benchmarks on secp256k1, and the text concedes 'Arithmetic circuits for general proofs have not yet been implemented.' Since the abstract advertises the construction as 'efficient,' the central performance claim for the Dogecoin-specific circuit remains unmeasured; the concrete SHA256 numbers do not validate the scrypt-based Dogecoin relay.
minor comments (6)
  1. [Fig. 4] The suggested value for 'maximum extension length' reads '10,0000 Dogecoin blocks,' which appears to have an extra zero; presumably it should be 10,000.
  2. [§4.5] The sentence 'If no challenges occurs within d-k Dogecoin blocks' mixes singular and plural; it should read 'If no challenge occurs' or 'If no challenges occur.'
  3. [§4.6] There is a doubled article in 'the the Merkle proof' in condition 1(a); the duplicate 'the' should be removed.
  4. [§4.7] There is a duplicated 'the' in 'the the y-bridge queue's first element,' and the spelling 'Holder' appears alongside 'Hodler' throughout; the terminology should be unified.
  5. [§5.1] The phrase 'Thus we obtain the the following' contains a duplicated 'the'; it should read 'the following.'
  6. [§1.3 and §6] The claims about extending the construction to Bitcoin are speculative: Section 1.3 mentions 'a similar technique adds Ethereum-based smart contracts to Bitcoin,' but the paper only provides SHA256 benchmarks and does not describe a Bitcoin-side locking mechanism; the abstract's wording should be softened or the construction specified.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the Dogethereum construction is a protocol specification whose security invariants are either accounting identities or explicitly conditional on stated agent-behavior assumptions, not reductions to the paper's own conclusions.

full rationale

The paper does not fit any parameter to data and then rename the fit as a prediction; there is no empirical fitting anywhere in the text, and the central claims are protocol-level structural guarantees. Invariant 1 is explicitly an accounting identity enforced by the Bridge Contract's mint and burn rules: the contract only mints WOW[y] after ETH collateral is deposited and only releases collateral when WOW[y] is burned, so the equality between circulating WOW and collateralized ETH is true by construction and is presented as such rather than as an empirical discovery. Invariant 3 is a conditional security statement: it assumes rational Hodlers, Operators, and Crossers perform specified monitoring, reporting, and challenging actions, and then concludes that locked DOGE equals circulating WOW. The conclusion does not appear among the hypotheses by construction, so this is an unproven liveness and participation assumption, not circular reasoning; the paper's own Section 4.9 concedes the practical gap when no agents are watching and collateral is staked, which is a security limitation rather than a circular derivation. The reliance on Truebit and bulletproofs is supported by citations to prior work, including work by the present authors (Truebit is co-created by Teutsch), but these are external primitives with stated assumptions that do not include the Dogethereum result, and Truebit is treated as a black box with implementations and public demos cited; accordingly, the self-citation is not load-bearing in the sense of reducing the present claim to an unverified assertion. There is no imported uniqueness theorem, no ansatz smuggled in via citation, and no renaming of a known result: the collateralized-peg idea is explicitly credited to earlier discussions and to Habibian's unpublished manuscript, and the relay requirements of Maximality, Validity, and Shallow-fork-free are design requirements argued from Nakamoto consensus. Overall, the derivation chain is internally non-circular; the main caveats are unproven liveness and participation assumptions, which belong to correctness risk rather than circularity.

Assumptions & free parameters 9 free parameters · 5 assumptions · 2 invented entities

The protocol introduces no fitted constants in the sense of data fitting, but many parameters are chosen by hand and directly influence the efficiency and security claims. The central design depends on strong rationality and threat-model assumptions that are stated but not formally proven.

free parameters (9)
  • confirmation depth c = ≈ 10 Dogecoin blocks
    Suggested in Figure 4; determines how many blocks must follow before a Dogecoin block is considered confirmed.
  • recently confirmed threshold d = ≈ 20 Dogecoin blocks
    Suggested in Figure 4; controls the maximality window for relay submissions.
  • security parameter k = ≈ 2 Dogecoin blocks
    Suggested in Section 4.5; protects against challenges based on future knowledge.
  • maximum extension length = ≈ 10,000 Dogecoin blocks (paper text says '10,0000')
    Suggested in Figure 4; bounds relay deposit size and bulletproof cost.
  • relayer deposit = maximum of 5 USD, or cost to verify a 10,000-block extension
    Suggested in Section 5.3; must cover Truebit task cost and challenge penalties.
  • registration void fee = ≈ 1% of crossing value in ETH
    Suggested in Figure 4; discourages denial-of-service registrations.
  • penalty for non-maximal extension = ≈ 10% of ETH deposit
    Suggested in Figure 4; deters submissions that are not maximal.
  • reward for correct challenge = ≈ 1% of verification cost
    Suggested in Figure 4; incentivizes relayers to challenge bad submissions.
  • bridge exchange rate y = chosen by each Operator per bridge
    Section 4.2; determines the collateralization ratio and token tier WOW[y].
assumptions (5)
  • domain assumption Rational actors monitor exchange rates and challenge bad relay submissions
    Section 2 and Invariant 3 in Section 5.1; without this, the relay can be attacked and unbacked WOW can be minted.
  • domain assumption No block withholding attacks on Dogecoin
    Explicit security assumption 1 in Section 2; block withholding could bias relay consensus.
  • domain assumption Attackers cannot execute double spends or 51% attacks on Dogecoin
    Security assumption 2 in Section 2; small chains are realistically vulnerable to such attacks.
  • domain assumption No profitable denial-of-service attacks on the Bridge Contract or Ethereum, and no censorship of smart contract transactions
    Security assumption 4 in Section 2; the protocol does not model adversarial gas or censorship.
  • domain assumption Ethereum block time gives an approximately well-defined global clock
    Definition of Ethereum time e in Section 4; used to time challenge windows and block validation.
invented entities (2)
  • WOW token (parametrized token)
    purpose: Represents locked DOGE on Ethereum with exchange-rate-specific tiers WOW[y] to keep collateral sufficient without a price oracle.
    The token is a new smart-contract ledger entry; no implementation is shipped, so there is no external falsifiable handle.
  • Bridge Contract
    purpose: Central Ethereum smart contract that escrows ETH collateral, mints and burns WOW, maintains the Dogecoin relay history, and resolves challenges.
    A new system component; no code or deployment is provided, so it cannot be independently verified.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Retrofitting a two-way peg between blockchains." pith.science (2026). https://pith.science/paper/HJNTLABE

@misc{pith2026190803999,
  author       = {Pith},
  title        = {Pith review of: Retrofitting a two-way peg between blockchains},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HJNTLABE}},
  note         = {Machine review of arXiv:1908.03999}
}
read the original abstract

In December 2015, a bounty emerged to establish both reliable communication and secure transfer of value between the Dogecoin and Ethereum blockchains. This prized "Dogethereum bridge" would allow parties to "lock" a DOGE coin on Dogecoin and in exchange receive a newly minted WOW token in Ethereum. Any subsequent owner of the WOW token could burn it and, in exchange, earn the right to "unlock" a DOGE on Dogecoin. We describe an efficient, trustless, and retrofitting Dogethereum construction which requires no fork but rather employs economic collateral to achieve a "lock" operation in Dogecoin. The protocol relies on bulletproofs, Truebit, and parametrized tokens to efficiently and trustlessly relay events from the "true" Dogecoin blockchain into Ethereum. The present construction not only enables cross-platform exchange but also allows Ethereum smart contracts to trustlessly access Dogecoin. A similar technique adds Ethereum-based smart contracts to Bitcoin and Bitcoin data to Ethereum smart contracts.

Figures

Figures reproduced from arXiv: 1908.03999 by the authors.

Figure 1
Figure 1. Artist rendering of Dogethereum [2]. and possibly even Litecoin miners who incidentally mine Dogecoin as well. Indeed, any change in consensus procedure requires a so-called “fork” wherein miners each voluntarily update their local clients. By 2017, the stars had aligned on Items 2 and 3 above. In order to gain the attention of these parties, Truebit introduced the #ArtProject [2] to cre￾ate a physical manifestation… view at source ↗
Figure 2
Figure 2. Laconic timeline of Dogethereum. construction avoids dependencies on politics and distinguished nodes and in￾stead assumes only rational actors (Section 2) atop a simple relay (Section 3). We argue that the construction (Section 4) is sufficiently secure (Section 5) and efficient (Section 6) to support practical use. 1.1 In a nutshell Let us explore the basic operations and applications of our present two-way peg. A… view at source ↗
Figure 3
Figure 3. Arrows indicate module sequences over the course of a [PITH_FULL_IMAGE:figures/full_fig_p024_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Protocol parameters and suggested values. [PITH_FULL_IMAGE:figures/full_fig_p035_4.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Enhancing Blockchain Cross Chain Interoperability: A Comprehensive Survey

    cs.CR 2025-05 conditional novelty 3.0 of 10

    A systematic survey that organizes blockchain cross-chain interoperability techniques into a classification and compares them with industry practice, while identifying open challenges.

Reference graph

Works this paper leans on

90 extracted references · 79 canonical work pages · cited by 1 Pith paper

  1. [1]

    https://www.algorand.com/

    Algorand. https://www.algorand.com/

  2. [2]

    http://artproject.io/

    #ArtProject. http://artproject.io/

  3. [3]

    https://www

    BigChainDB 2.0: The blockchain database. https://www. bigchaindb.com/whitepaper/

  4. [4]

    http://btcrelay.org/

    BTC Relay. http://btcrelay.org/

  5. [5]

    https://github.com/dalek-cryptography/ bulletproofs

    Bulletproofs. https://github.com/dalek-cryptography/ bulletproofs

  6. [6]

    https://crypto.stanford.edu/bulletproofs/

    Bulletproofs: Short proofs for confidential transactions and more. https://crypto.stanford.edu/bulletproofs/

  7. [7]

    https://www.commonwealthcrypto.com/

    Commonwealth Crypto. https://www.commonwealthcrypto.com/

  8. [8]

    https://dfinity.org/

    DFINITY - The Decentralized Cloud. https://dfinity.org/

Show all 90 references
  1. [9]

    https://etherscan.io/address/ 0xdbf03b407c01e7cd3cbea99509d93f8dddc8c6fb

    Doge-Eth-Bounty. https://etherscan.io/address/ 0xdbf03b407c01e7cd3cbea99509d93f8dddc8c6fb

  2. [10]

    https://dogecoin.com/

    Dogecoin. https://dogecoin.com/

  3. [11]

    https://bitinfocharts.com/ comparison/dogecoin-confirmationtime.html

    Dogecoin block time historical chart. https://bitinfocharts.com/ comparison/dogecoin-confirmationtime.html

  4. [12]

    https://github.com/dogecoin/dogecoin/ commits/master

    Dogecoin commits. https://github.com/dogecoin/dogecoin/ commits/master

  5. [13]

    https://github.com/dogecoin/ dogecoin

    Dogecoin Core [DOGE, D]. https://github.com/dogecoin/ dogecoin

  6. [14]

    https://www.reddit.com/r/dogecoin/comments/1xdl18/ dogecoin_hype_video_competition_all_9_winners_and/

    Dogecoin hype video competition: All 9 winners and final re- marks. https://www.reddit.com/r/dogecoin/comments/1xdl18/ dogecoin_hype_video_competition_all_9_winners_and/. 42

  7. [15]

    https://dogesontrial.dog/

    Doges on Trial. https://dogesontrial.dog/

  8. [16]

    https://en.wikipedia.org/wiki/ERC-20

    ERC-20. https://en.wikipedia.org/wiki/ERC-20

  9. [17]

    https://etherscan.io/chart/ blocktime

    Ethereum Average BlockTime Chart. https://etherscan.io/chart/ blocktime

  10. [18]

    https://ethereum.org/

    Ethereum project. https://ethereum.org/

  11. [19]

    https:// funfair.io/

    Game-changing blockchain casino technology — FunFair. https:// funfair.io/

  12. [20]

    https://github.com/apoelstra/secp256k1-mw/tree/ bulletproofs

    libsecp256k1. https://github.com/apoelstra/secp256k1-mw/tree/ bulletproofs

  13. [21]

    https://github.com/ scipr-lab/libsnark

    libsnark: a C++ library for zkSNARK proofs. https://github.com/ scipr-lab/libsnark

  14. [22]

    https://getmonero.org/

    Monero, a digital currency that is secure, private, and untraceable. https://getmonero.org/

  15. [23]

    https://github.com/ethereum/wiki/wiki/White-Paper

    A next-generation smart contract and decentralized application plat- form. https://github.com/ethereum/wiki/wiki/White-Paper

  16. [24]

    https://nipopows.com/

    Non-interactive proofs of proof-of-work. https://nipopows.com/

  17. [25]

    https://polkadot.network

    Polkadot. https://polkadot.network

  18. [26]

    https://raiden.network/

    The Raiden Network. https://raiden.network/

  19. [27]

    https://www.rsk

    Sidechains, drivechains, and RSK 2-way peg design. https://www.rsk. co/blog/sidechains-drivechains-and-rsk-2-way-peg-design

  20. [28]

    starkware.co/

    Starkware industries — We are not conducting an ICO! https://www. starkware.co/

  21. [29]

    https://tezos.com/

    Tezos. https://tezos.com/

  22. [30]

    https://www

    Thundercore — Scalable blockchain delivered. https://www. thundercore.com/

  23. [31]

    https://truebit.io

    TrueBit. https://truebit.io

  24. [32]

    https://github.com/TrueBitFoundation/

    TrueBit GitHub. https://github.com/TrueBitFoundation/

  25. [33]

    https://github.com/akosba/xjsnark

    xJsnark. https://github.com/akosba/xjsnark. 43

  26. [34]

    https://z.cash/

    Zcash - all coins are created equal. https://z.cash/

  27. [35]

    https://zilliqa.com/

    Zilliqa. https://zilliqa.com/

  28. [36]

    https://github.com/TrueBitFoundation/ scrypt-interactive, February 2018

    GitHub - TrueBitFoundation/scrypt-interactive: Truebit Verifi- cation for Scrypt. https://github.com/TrueBitFoundation/ scrypt-interactive, February 2018

    2018

  29. [37]

    https://github

    Too large or otherwise inaccessible IPFS files #65. https://github. com/TrueBitFoundation/webasm-solidity/issues/65, March 2018

    2018

  30. [38]

    Scrypt is maximally memory-hard

    Jo¨ el Alwen, Binyi Chen, Krzysztof Pietrzak, Leonid Reyzin, and Ste- fano Tessaro. Scrypt is maximally memory-hard. In Jean-S´ ebastien Coron and Jesper Buus Nielsen, editors, Advances in Cryptology – EUROCRYPT 2017, pages 33–62, Cham, 2017. Springer International Publishing

    2017

  31. [39]

    Enabling blockchain innovations with pegged sidechains

    Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gre- gory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Tim´ on, and Pieter Wuille. Enabling blockchain innovations with pegged sidechains. https://blockstream.com/sidechains.pdf, October 2014

    2014

  32. [40]

    Using superblocks to bridge Dogecoin to Ethereum

    Ismael Bejarano and Oscar Guindzberg. Using superblocks to bridge Dogecoin to Ethereum. https://github.com/dogethereum/docs/ blob/master/superblocks/superblocks-white-paper.pdf, 2018

    2018

  33. [41]

    Dogecoin <–> Ethereum bridge docs

    Ismael Bejarano, Catalina Juarros, Pablo Yabo, and Oscar Guindzberg. Dogecoin <–> Ethereum bridge docs. https://github.com/ dogethereum/docs

  34. [42]

    Scalable, transparent, and post-quantum secure computational in- tegrity

    Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev. Scalable, transparent, and post-quantum secure computational in- tegrity. https://eprint.iacr.org/2018/046, 2018. Cryptology ePrint Archive, Report 2018/046

    2018

  35. [43]

    SNARKs for C: Verifying program executions succinctly and in zero knowledge

    Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran Tromer, and Madars Virza. SNARKs for C: Verifying program executions succinctly and in zero knowledge. In Ran Canetti and Juan A. Garay, editors, Advances in Cryptology – CRYPTO 2013: 33rd Annual Cryptology Conference, San...

    2013

  36. [44]

    Efficient zero-knowledge arguments for arithmetic circuits in the discrete log setting

    Jonathan Bootle, Andrea Cerulli, Pyrros Chaidos, Jens Groth, and Christophe Petit. Efficient zero-knowledge arguments for arithmetic circuits in the discrete log setting. In Marc Fischlin and Jean-S´ ebastien Coron, editors, Advances in Cryptology – EUROCRYPT 2016 , pages 327–35...

    2016

  37. [45]

    Bulletproofs: Short proofs for confidential transactions and more

    Benedikt B¨ unz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Greg Maxwell. Bulletproofs: Short proofs for confidential transactions and more. https://eprint.iacr.org/2017/1066, 2017. Cryptology ePrint Archive, Report 2017/1066

    2017

  38. [46]

    (Doge/Ethereum two-way peg) I wrote up an im- plementation of scrypt in EVM for use in verifying dogecoin block headers

    Vitalik Buterin. (Doge/Ethereum two-way peg) I wrote up an im- plementation of scrypt in EVM for use in verifying dogecoin block headers. https://www.reddit.com/r/dogecoin/comments/3xc0co/ dogeethereum_twoway_peg_i_wrote_up_an/, December 2015

    2015

  39. [47]

    Online donors send Jamaican bobsled team to Sochi

    Bill Chappell. Online donors send Jamaican bobsled team to Sochi. https://www.npr. org/sections/thetwo-way/2014/01/22/265060754/ wow-dogecoin-other-donors-send-jamaican-bobsled-team-to-sochi , January 2014

    2014

  40. [48]

    Usman W. Chohan. A history of Dogecoin. http://dx.doi.org/10. 2139/ssrn.3091219, 2017

    2017

  41. [49]

    Counterfactual: Generalized state channels

    Jeff Coleman, Liam Horne, and Li Xuanji. Counterfactual: Generalized state channels. https://l4.ventures/papers/statechannels.pdf

  42. [50]

    Ristretto bullet- proofs

    Henry de Valence, Cathie Yun, and Oleg Andreev. Ristretto bullet- proofs. https://github.com/dalek-cryptography/bulletproofs

  43. [51]

    Majority is not enough: Bitcoin mining is vulnerable

    Ittay Eyal and Emin G¨ un Sirer. Majority is not enough: Bitcoin mining is vulnerable. Communications of the ACM , 61(7):95–102, July 2018

    2018

  44. [52]

    Dogethereum bridge live demo for judges

    Ethereum Foundation. Dogethereum bridge live demo for judges. https://www.youtube.com/watch?v=gdTd9Djt9gA, February 2018

    2018

  45. [53]

    The Doge-Ethereum bridge: a cryptoeconomic two-way peg

    Sina Habibian. The Doge-Ethereum bridge: a cryptoeconomic two-way peg. Manuscript, January 2018

    2018

  46. [54]

    Dogecoin community celebrates as merge mining with Litecoin begins

    Stan Higgins. Dogecoin community celebrates as merge mining with Litecoin begins. https://www.coindesk.com/ dogecoin-celebrates-litecoin-merge-mining/ , September 2014. 45

    2014

  47. [55]

    Moelius III

    Samuel E. Moelius III. Ethereum input bus (alpha). https://github. com/smoelius/ethereum_input_bus

  48. [56]

    Non-interactive proofs of proof-of-work

    Aggelos Kiayias, Andrew Miller, and Dionysis Zindros. Non-interactive proofs of proof-of-work. https://eprint.iacr.org/2017/963, 2017. Cryptology ePrint Archive, Report 2017/963

    2017

  49. [57]

    Cosmos: the Hub and Zones

    Jae Kwon and Ethan Buchman. Cosmos: the Hub and Zones. https://cosmos.network/docs/resources/whitepaper. html#the-hub-and-zones

  50. [58]

    Drivechains, sidechains and hybrid 2-way peg designs

    Sergio Demian Lerner. Drivechains, sidechains and hybrid 2-way peg designs. https://uploads.strikinglycdn.com/ files/27311e59-0832-49b5-ab0e-2b0a73899561/Drivechains_ Sidechains_and_Hybrid_2-way_peg_Designs_R9.pdf

  51. [59]

    PeaceRelay: Connecting the many Ether- eum blockchains

    Loi Luu. PeaceRelay: Connecting the many Ether- eum blockchains. https://medium.com/@loiluu/ peacerelay-connecting-the-many-ethereum-blockchains-22605c300ad3 , July 2017

    2017

  52. [60]

    Demys- tifying incentives in the consensus computer

    Loi Luu, Jason Teutsch, Raghav Kulkarni, and Prateek Saxena. Demys- tifying incentives in the consensus computer. Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security - CCS ’15 , 2015

    2015

  53. [61]

    Smart- pool: Practical decentralized pooled mining

    Loi Luu, Yaron Velner, Jason Teutsch, and Prateek Saxena. Smart- pool: Practical decentralized pooled mining. In 26th USENIX Security Symposium (USENIX Security 17) , pages 1409–1426, Vancouver, BC,

  54. [62]

    How to speak Doge

    Tessa Marshall. How to speak Doge. https://blogs.unimelb.edu. au/sciencecommunication/2016/10/22/how-to-speak-doge/, Oc- tober 2016

    2016

  55. [63]

    Pisa: Arbitration outsourcing for state channels

    Patrick McCorry, Surya Bakshi, Iddo Bentov, Andrew Miller, and Sarah Meiklejohn. Pisa: Arbitration outsourcing for state channels. https:// eprint.iacr.org/2018/582, 2018. Cryptology ePrint Archive, Report 2018/582

    2018

  56. [64]

    The High-Value-Hash Highway

    Andrew Miller. The High-Value-Hash Highway. https:// bitcointalk.org/index.php?topic=98986.0, August 2012. 46

    2012

  57. [65]

    Bitcoin P2P e-cash paper

    Satoshi Nakamoto. Bitcoin P2P e-cash paper. http://www. mail-archive.com/cryptography@metzdowd.com/msg09959.html, November 2008

    2008

  58. [66]

    Bitcoin: A peer-to-peer electronic cash system

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf, November 2018

    2018

  59. [67]

    The anatomy of ERC721: Understanding non- fungible Ethereum tokens

    Gerald Nash. The anatomy of ERC721: Understanding non- fungible Ethereum tokens. https://medium.com/crypto-currently/ the-anatomy-of-erc721-e9db77abfc24 , December 2017

    2017

  60. [68]

    The rise and rise of the Dogecoin and internet tipping culture

    Will Ockenden. The rise and rise of the Dogecoin and internet tipping culture. TheriseandriseoftheDogecoinandinternettippingculture, Jan- uary 2014

    2014

  61. [69]

    Doge-Eth second demo

    Oscar Channel. Doge-Eth second demo. https://www.youtube.com/ watch?v=zOCdtJmCruc, September 2018

    2018

  62. [70]

    Pinoc- chio: Nearly practical verifiable computation

    Bryan Parno, Craig Gentry, Jon Howell, and Mariana Raykova. Pinoc- chio: Nearly practical verifiable computation. https://eprint.iacr. org/2013/279, 2013. Cryptology ePrint Archive, Report 2013/279

    2013

  63. [71]

    Stronger key derivation via sequential memory-hard functions

    Colin Percival. Stronger key derivation via sequential memory-hard functions. https://www.tarsnap.com/scrypt/scrypt.pdf

  64. [72]

    Bulletproofs: Faster rangeproofs and much more

    Andrew Poelstra. Bulletproofs: Faster rangeproofs and much more. https://blockstream.com/2018/02/21/ bulletproofs-faster-rangeproofs-and-much-more.html , Febru- ary 2018

    2018

  65. [73]

    PHANTOM: A Scalable BlockDAG Protocol

    Yonatan Sompolinsky and Aviv Zohar. PHANTOM: A Scalable BlockDAG Protocol. https://eprint.iacr.org/2018/104, 2018. Cryptology ePrint Archive, Report 2018/104

    2018

  66. [74]

    The idea of smart contracts

    Nick Szabo. The idea of smart contracts. http://szabo.best.vwh. net/smart_contracts_idea.html, 1997

    1997

  67. [75]

    The Zilliqa technical whitepaper

    The Zilliqa team. The Zilliqa technical whitepaper. https://docs. zilliqa.com/whitepaper.pdf

  68. [76]

    DOGETHEREUM: We can do this Do- gether! https://www.reddit.com/r/dogecoin/comments/61vg5k/ dogethereum_we_can_do_this_dogether/, March 2017

    Jason Teutsch. DOGETHEREUM: We can do this Do- gether! https://www.reddit.com/r/dogecoin/comments/61vg5k/ dogethereum_we_can_do_this_dogether/, March 2017. 47

    2017

  69. [77]

    On decentralized oracles for data availabil- ity

    Jason Teutsch. On decentralized oracles for data availabil- ity. https://people.cs.uchicago.edu/~teutsch/papers/ decentralized_oracles.pdf, December 2017

    2017

  70. [78]

    When cryptocurren- cies mine their own business

    Jason Teutsch, Sanjay Jain, and Prateek Saxena. When cryptocurren- cies mine their own business. In Jens Grossklags and Bart Preneel, edi- tors, Financial Cryptography and Data Security, pages 499–514, Berlin, Heidelberg, 2017. Springer Berlin Heidelberg

    2017

  71. [79]

    A scalable verification so- lution for blockchains

    Jason Teutsch and Christian Reitwießner. A scalable verification so- lution for blockchains. http://people.cs.uchicago.edu/~teutsch/ papers/truebit.pdf, 2017

    2017

  72. [80]

    Re: Alt chains and atomic transfers

    TierNolan. Re: Alt chains and atomic transfers. https: //bitcointalk.org/index.php?topic=193281.msg2224949# msg2224949, May 2013

    2013

  73. [81]

    Truebit verification for Scrypt on the Rinkeby testnet

    Truebit. Truebit verification for Scrypt on the Rinkeby testnet. https: //www.youtube.com/watch?v=8VLg3RuvYNI, February 2018

    2018

  74. [82]

    ANNOUNMENT: Dogecoin complete integration with ethereum

    /u/42points. ANNOUNMENT: Dogecoin complete integration with ethereum. https://www.reddit.com/r/dogecoin/comments/ 62p3b8/announment_dogecoin_complete_integration_with/, April 2017

    2017

  75. [83]

    The Doge connection Bounty Dao is live and work- ing

    Alex van de Sande. The Doge connection Bounty Dao is live and work- ing. https://www.reddit.com/r/ethereum/comments/41ohhr/the_ doge_connection_bounty_dao_is_live_and_working/, 2016

    2016

  76. [84]

    Wahby, Ioanna Tzialla, abhi shelat, Justin Thaler, and Michael Walfish

    Riad S. Wahby, Ioanna Tzialla, abhi shelat, Justin Thaler, and Michael Walfish. Doubly-efficient zkSNARKs without trusted setup. https: //eprint.iacr.org/2017/1132, 2017. Cryptology ePrint Archive, Re- port 2017/1132

    2017

  77. [85]

    How to generate SNARK parameters securely

    Zooko Wilcox. How to generate SNARK parameters securely. https: //blog.z.cash/snark-parameters/, February 2016

    2016

  78. [86]

    Polkadot: vision for a heterogeneous multi-chain frame- work

    Gavin Wood. Polkadot: vision for a heterogeneous multi-chain frame- work. https://polkadot.network/PolkaDotPaper.pdf, 2016

    2016

  79. [87]

    Knottenbelt

    Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais, and William J. Knottenbelt. XCLAIM: Trustless, in- teroperable, cryptocurrency-backed assets. In 2019 IEEE Symposium 48 on Security and Privacy (S&P) , pages 1254–1271, Los Alamitos, CA, USA, Ma...

    2019

  80. [88]

    Zcash Ceremony

    Zcash. Zcash Ceremony. https://www.youtube.com/watch?v= D6dY-3x3teM, January 2017

    2017

  81. [89]

    D is for Dogecoin

    ZimoNitrome. D is for Dogecoin. https://www.youtube.com/watch? v=000al7ru3ms, 2014. 49

    2014

  82. [2017]

    USENIX Association, https://www.usenix.org/conference/ usenixsecurity17/technical-sessions/presentation/luu

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.