You may want to look into the 2-of-3 escrow with timeout defined in BIP 112.
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawi...
You want 'the blockchain' to verify payment between parties; these parties will be in charge of verifying satisfactory delivery and releasing funds.
In Ask HN: Can a blockchain do this?bitcoin
bips
Wikitext2013–2026
bitcoin / bips
bips
Bitcoin Improvement Proposals
104Distinct people
124Mentions
0Explicit recommenders
11KGitHub stars
What to know before exploring
What it is
Bitcoin Improvement Proposals
GitHub
Where it is used
- Ledger Wallet (Ledger Live) — Ledger Wallet uses the BIP32, BIP39 and BIP44 standards to manage seeds and derivation paths for generating keys and addresses. Source
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- bcoin-org/bcoin · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:23:53 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year124 dated mentions
Observed mentions: 2013-12-10 19:15:46 UTC to 2026-09-13 15:23:25 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 1 | 11 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 17 | 0 | 17 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 1 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
People wishing to submit a BIP should first describe their idea to the bitcoindev@googlegroups.com
mailing list to gather feedback on viability and community interest before working on a
formal description. Please open a pull request to this repository only when substantial progress on the draft has been
made, preferably when the draft is nearing completion. Authors do not assign a number to their own proposal.
After a proposal meets the editorial criteria, a BIP Editor will assign a number to it and publish the proposal by
merging the pull request to the repository. Please see BIP 3: Updated BIP Process for the full process.
The BIPs repository serves as a publication medium and archive. Having a BIP published here indicates that the proposal
is in scope and has met other formal criteria for this repository, but does not indicate that it is a good idea, has
community consensus, or that it is about to be adopted. The BIP Editors are expected to be liberal with publishing BIPs
and to try not to be too involved in decision-making on behalf of the community. Beyond the formal criteria, evaluation of
the proposals is left to the audience of the repository. When a proposal is controversial and it cannot be agreed upon
whether it should be published, the conservative option will always be preferred: the proposal will be closed.
Those proposing and opposing changes should consider that ultimately acceptance and adoption rests with the Bitcoin
users (see also: economic majority).
Number
Layer
Title
Owner
Type
Status
1
BIP Purpose and Guidelines
Amir Taaki
Process
Closed
2
BIP process, revised
Luke Dashjr
Process
Closed
3
Updated BIP Process
Murch
Process
Deployed
8
Version bits with lock-in by height
Shaolin Fry, Luke Dashjr
Informational
Complete
9
Version bits with timeout and delay
Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell
Informational
Deployed
10
Applications
Multi-Sig Transaction Distribution
Alan Reiner
Informational
Closed
11
Applications
M-of-N Standard Transactions
Gavin Andresen
Specification
Deployed
12
Consensus (soft fork)
OP_EVAL
Gavin Andresen
Specification
Closed
13
Applications
Address Format for pay-to-script-hash
Gavin Andresen
Specification
Deployed
14
Peer Services
Protocol Version and User Agent
Amir Taaki, Patrick Strateman
Specification
Deployed
15
Applications
Aliases
Amir Taaki
Specification
Closed
16
Consensus (soft fork)
Pay to Script Hash
Gavin Andresen
Specification
Deployed
17
Consensus (soft fork)
OP_CHECKHASHVERIFY (CHV)
Luke Dashjr
Specification
Closed
18
Consensus (soft fork)
hashScriptCheck
Luke Dashjr
Specification
Complete
19
Applications
M-of-N Standard Transactions (Low SigOp)
Luke Dashjr
Specification
Closed
20
Applications
URI Scheme
Luke Dashjr
Specification
Closed
21
Applications
URI Scheme
Nils Schneider, Matt Corallo
Specification
Closed
22
API/RPC
getblocktemplate - Fundamentals
Luke Dashjr
Specification
Deployed
23
API/RPC
getblocktemplate - Pooled Mining
Luke Dashjr
Specification
Deployed
30
Consensus (soft fork)
Duplicate transactions
Pieter Wuille
Specification
Deployed
31
Peer Services
Pong message
Mike Hearn
Specification
Deployed
32
Applications
Hierarchical Deterministic Wallets
Pieter Wuille
Informational
Deployed
33
Peer Services
Stratized Nodes
Amir Taaki
Specification
Closed
34
Consensus (soft fork)
Block v2, Height in Coinbase
Gavin Andresen
Specification
Deployed
35
Peer Services
mempool message
Jeff Garzik
Specification
Deployed
36
Peer Services
Custom Services
Stefan Thomas
Specification
Closed
37
Peer Services
Connection Bloom filtering
Mike Hearn, Matt Corallo
Specification
Deployed
38
Applications
Passphrase-protected private key
Mike Caldwell, Aaron Voisine
Specification
Deployed
39
Applications
Mnemonic code for generating deterministic keys
Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe
Specification
Deployed
40
API/RPC
Stratum wire protocol
Marek Palatinus
Standard
BIP number allocated
41
API/RPC
Stratum mining protocol
Marek Palatinus
Standard
BIP number allocated
42
Consensus (soft fork)
A finite monetary supply for Bitcoin
Pieter Wuille
Specification
Deployed
43
Applications
Purpose Field for Deterministic Wallets
Marek Palatinus, Pavol Rusnak
Specification
Deployed
44
Applications
Multi-Account Hierarchy for Deterministic Wallets
Marek Palatinus, Pavol Rusnak
Specification
Deployed
45
Applications
Structure for Deterministic P2SH Multisignature Wallets
Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia
Specification
Complete
46
Applications
Address Scheme for Timelocked Fidelity Bonds
Chris Belcher, Thebora Kompanioni
Specification
Draft
47
Applications
Reusable Payment Codes for Hierarchical Deterministic Wallets
Justus Ranvier
Specification
Deployed
48
Applications
Multi-Script Hierarchy for Multi-Sig Wallets
Fontaine
Specification
Deployed
49
Applications
Derivation scheme for P2WPKH-nested-in-P2SH based accounts
Daniel Weigl
Specification
Deployed
50
March 2013 Chain Fork Post-Mortem
Gavin Andresen
Informational
Deployed
52
Consensus (hard fork)
Durable, Low Energy Bitcoin PoW
Michael Dubrovsky, Bogdan Penkovsky
Specification
Closed
53
Consensus (soft fork)
Disallow 64-byte transactions
Chris Stewart
Specification
Draft
54
Consensus (soft fork)
Consensus Cleanup
Antoine Poinsot, Matt Corallo
Specification
Complete
60
Peer Services
Fixed Length "version" Message (Relay-Transactions Field)
Amir Taaki
Specification
Closed
61
Peer Services
Reject P2P message
Gavin Andresen
Specification
Deployed
62
Consensus (soft fork)
Dealing with malleability
Pieter Wuille
Specification
Closed
63
Applications
Stealth Addresses
Peter Todd
Standard
BIP number allocated
64
Peer Services
getutxo message
Mike Hearn
Specifi
Read the full README on GitHubWhat Hacker News says
9 sourcesI've mentioned an idea in Phoronix forums[1] yesterday:
Since most users won't bother comparing the entire signature (also applies to comparing md5/sha*/etc. hashes), it might be a good idea to map & display blocks of the sig as English words to the user.
Care must be taken to avoid similar-looking and similar-sounding (homophonic) words, but since there are >150k words in Oxford English Dictionary, so it should be possible to get 65k usable ones.
In fact, someone pointed out something like this already exists to a degree: [2]
A contrived visual example (suppose someone matches first two and last two segments!):
Fake Linus Torvalds: ABAF 11C6 32D8 69AE E438 F74B 6211 AA3B 0041 1886
Real Linus Torvalds: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886
With a word salad approach:
Fake Linus Torvalds: lopsided crate threatening hydra
Read the rest
nt peep bumpy art work earth spurious
Real Linus Torvalds: lopsided crate symptomatic equal kaput chunky kettle include earth spurious
Even with an even-spaced font, it's hard to confuse the two
(random words from [3])
[1] https://www.phoronix.com/forums/forum/phoronix/latest-phoron...
[2] https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi...
[3] https://www.randomlists.com/random-words
Hardware wallets use the BIP32[1] spec to implement "Hierarchical Deterministic" (HD) addresses. Using a single seed phrase (stored internally on the device, and also written down external to the device, neither copy should ever be online), you can generate an infinite number of addresses for your wallet. Every time you request a payment, you get a different address to send to, there is no address reuse (unless you or someone else chooses to send funds to an address that has already been spent from).
[1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...
In “I must, sadly, withdraw my endorsement of Yubikey 4 devices”I have the same thought running through my head while perusing each Rust announcement. Python has the Python Enhancement Proposal[1], and Bitcoin has their Bitcoin Improvement Proposal[2]. On the flip side, this does have the side effect of forcing me to click through to each Rust RFC linked in the announcements just to be sure.
[1] https://www.python.org/dev/peps/
[2] https://github.com/bitcoin/bips
In Announcing Rust 1.8Except they're not being conservative. Core's approach has been to introduce new complexities such as replace-by-fee[1] and segregated witness[2]. These are much bigger changes to Bitcoin than a one-time increase of the max block size.
1. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawi...
2. https://github.com/bitcoin/bips/blob/master/bip-0144.mediawi...
In Bitcoin transaction processing takes up to 10 hoursSeveral times in the past?
AFAIK there's only been one hard fork, https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...
That was accidental, and was reverted as soon as people realized. Someone pushed through a $10,000 double-spend in the meantime.
Other than that, I don't think any hardforks have taken place.
In My view on the current situation of Bitcoin and the Blockchain> rapidly coalescing around an effort to increase the maximum allowed blocksize to 2MB as soon as possible
I have a small nitpick to offer. Any hard-forking change is one for a new network and a new chain, by the very definition of hard-fork. The original Bitcoin blockchain and network will still exist, no matter how many times some of its users employ a hard-fork. A hard-fork cannot "turn off" Bitcoin for everyone else. This is no different than the way that an altcoin, like Litecoin, cannot "turn off" Bitcoin merely by the deployment and launch of Litecoin.
Since their proposal is a backwards-incompatible change (hard-fork), it should be obvious that it does not increase the capacity of the current system, but rather a new system. I find myself wondering how anyone can think it is increasing the capacity of the previous network, given t
Read the rest
he definition of an (intentional!) hard-fork?
Maybe if we all just wish hard enough, IPv4 will spontaneously transform into IPv6..... Bitcoin will continue to function even in the presence of yet-another hard-fork.
Anyone is welcome to do as they please, including whatever hard-forks they might want to participate in, just as anyone is welcome to use Bitcoin or how they are welcome to abandon Bitcoin if they find that they don't like its offering. However, anyone who wants to participate in a hard-fork should do so in a safe and responsible way, such as by using a new name for the new system, using a new address identifier to avoid cross-chain contamination accidents, etc.
What is Bitcoin Core's role in all of this? https://bitcoin.org/en/bitcoin-core/2016-01-07-statement
Soft-forks and hard-forks? https://petertodd.org/2016/soft-forks-are-safer-than-hard-fo...
bip99 has some more details: https://github.com/bitcoin/bips/blob/master/bip-0099.mediawi...
Bitcoin Core published a capacity increases roadmap: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-...
... and a FAQ about their capacity increases roadmap: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq...
> and [theymos] has strongly censored and perverted all discussion of changes
That's not really true, just search "site:reddit.com/r/bitcoin" for XT or classic or whatever. His lynch mob is waving the banner of censorship but meanwhile actual content shows up on the subreddit. Theymos even acknowledges this, but for some reason refuses to use moderation to eliminate the false allegations of censorship in his subreddit.
> The idea that hard forks are dangerous or irresponsible is a belief that is not well supported
bip99 - https://github.com/bitcoin/bips/blob/master/bip-0099.mediawi...
https://www.reddit.com/r/bitcoinxt/comments/3t21dh/dangerous...
https://www.reddit.com/r/Bitcoin/comments/3griiv/on_consensu...
> scare people away from doing what's necessary
Most block size hard-forks can be deployed as a soft-fork. "It's necessary" is highly contentious and you have failed to cite any of the arguments you disagree with- you're wasting everyone's time.
In The resolution of the Bitcoin experimentYeah, the questions in regard to post-hardfork haven't been definitively answered yet because Bitcoin has never intentionally hardforked before. It has done once in the past due to a software error [1], and it was nearly a disaster but luckily all the right people were online and quickly decided which fork to keep.
[1] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...
In The resolution of the Bitcoin experiment