Skip to content

Instantly share code, notes, and snippets.

View markblundeberg's full-sized avatar

Mark B Lundeberg markblundeberg

  • Wet coast, Canada
View GitHub Profile
@markblundeberg
markblundeberg / notification.md
Last active January 7, 2019 17:23
BCH 24-bit public notification addresses

This is a brief specification proposing the use of short anyone-can-spend P2SH addresses. This protocol is already in use with BCHMessage as used in OpenSwap, for the 'public bulletin boards' feature, but may be of use in other protocols.

Rationale

Various protocols like on-chain messaging, payment codes, and so on need SPV-wallet-friendly notifications.

  • In BIP47, notifications are sent to an address owned by the recipient, which means that notifications create UTXO dust. If the UTXO dust is cleaned up, this causes a privacy concern as its destination can be traced. If not cleaned, then the UTXO set will grow and grow over time. BIP47 v2 tried to solve this by using a 1-of-2 multisig so that the sender can also clean up the dust, however this creates SPV unfriendliness for the recipient.
  • In stealth addresses, payments are tagged with an OP_RETURN including a few-byte prefix that can be use
@markblundeberg
markblundeberg / quadsig.md
Last active February 2, 2024 09:09
Quadratic sighash based on scriptCode

Quadratic sighash remains in Segwitv0/BCH/BSV digest algorithms.

Mark Lundeberg 2018 Oct 17

Abstract: Both BCH post-forkday signatures and the BIP143 Segwit signatures are ostensibly designed to remove the 'quadratic hashing problem', however as I will show, they are still vulnerable for long scripts. Back-of-the-envelope calculations show that it will become a serious concern if the existing script limits are relaxed.

Facts

  • Every OP_CHECKSIG requires hashing a potentially large amount of data, limited only by the size of scriptCode. The precise length is 159 + len(scriptCode) for scriptCodes longer than 255 bytes, up to 65535 bytes.
  • Since many OP_CHECKSIG calls are possible within a given script, this means transactions can be made where the required hashing time is quadratic in the length of script. (though, see the non-push opcod
@markblundeberg
markblundeberg / P2I.md
Last active June 1, 2019 15:20
"Pay To Identity" — a proposed use of OP_CHECKDATASIG

"Pay To Identity" — a proposed use of OP_CHECKDATASIG

Dr. Mark B. Lundeberg, 2018 September 6 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

A mechanism where a Bitcoin Cash payment is made to a personally identifying string (real name, email address, social media handle, etc.) instead of directly to a cryptographic key. The payment can only be claimed by the recipient if they generate a public key and get it certified by an identity verifier. This certification signature is confirmed in script via the new opcode OP_CHECKDATASIG.

Characteristics:

  • Pay anyone, right now -- recipient doesn't need to have any cryptographic keys nor do they even need a phone/computer. (They only need these to claim the funds later.)
@markblundeberg
markblundeberg / pgp-checkdatasig.md
Created August 31, 2018 01:23
Using PGP signatures with bitcoin script OP_CHECKDATASIG

Using PGP signatures with bitcoin script OP_CHECKDATASIG

Dr. Mark B. Lundeberg, 2018 August 30 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

Since version 2.1, GnuPG is able to use the very same secp256k1 elliptic curve signature algorithm (ECDSA) as used in bitcoin. Quite soon Bitcoin Cash will add a new script opcode OP_CHECKDATASIG that is able to check signatures not just on the containing transaction, but also on arbitrary data. For fun, let's try to intersect the two signature systems and see what can be done!

Background

OP_CHECKDATASIG signatures

@markblundeberg
markblundeberg / hidden-atomic-swaps.md
Last active November 23, 2023 19:54
SwapChannels: hide your atomic swaps using ordinary payment channels
### Keybase proof
I hereby claim:
* I am markblundeberg on github.
* I am marklundeberg (https://keybase.io/marklundeberg) on keybase.
* I have a public key ASDQpnjba7VyKnEj28AwOYk3TzhbWeUP-KJbFs3XesNWlgo
To claim this, I am signing this object:
@markblundeberg
markblundeberg / instaconf.md
Last active February 22, 2018 07:46
Buy your coffee with InstaConf: nearly trustless zero-confirmation guarantees

Buy your coffee with InstaConf: nearly trustless zero-confirmation guarantees

A proposal by Dr. Mark B Lundeberg, 2018 Feb 21 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

This is a proposal for reducing the risk of accepting unconfirmed (zero-conf) transactions in Bitcoin-like cryptocurrencies. Accepting such transactions is typically safe, however there is always the risk of [double-spending](

@markblundeberg
markblundeberg / atomic-size-attack.md
Created February 16, 2018 05:14
Advisory: secret size attack on cross-chain hash lock smart contracts

Advisory: secret size attack on cross-chain hash lock smart contracts

Dr. Mark B Lundeberg, 2018 Feb 15 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

This security advisory notes a vulnerability in the common construction of cross-chain smart contracts (contracts between distinct cryptocurrencies) through hash locking. I focus on the primary use case in [atomic