So I've done some more thinking about this, and I think I've come up with a solution. The contract would be as follows


If Alice wishes to spend before lock date, she publishes a transaction with the input sequence number set as [0x0000, 0xffff]. Bob cannot double spend, as his transaction would not be accepted into the mempool.

If Bob wishes to spend after lock date, he publishes a transaction with the appropriate nLockTime and the input sequence number set as 0xfffffffe, signaling that it is using locktime and is not replaceable.

If Alice publishes a transaction after lock date, then Bob can publish his with a slightly higher fee, which will supersede Alice's due to the higher nSequence. The one potential weakness I can see is if Alice intentionally publishes a version with extremely high fees, essentially destroying some of the funds Bob is owed.

What do you mean by this? Bitcoin script is intentionally not Turing-complete i.e. cannot be a "computer" in the typical sense. Could you give an example of a design?

It's my understanding that all transactions spending an OP_CHECKSEQUENCEVERIFY input will have RBF implicitly enabled (as all valid nSequence locktimes are less than 0xFFFFFF).

I was wondering what the recommended solution for a case where the contract is something like


Where the goal is that Bob can spend the funds only after an escrow period, but Alice can spend them at any time, revoking payment for an ongoing service between the two. As I understand it, the effects of RBF would be such that Alice would be able to spend this output, even after Bob has published it to the network.

My question is essentially: is there any way to make it so that Alice could not spend the output after the relative locktime has passed?

The problem is ultimately that the randomness of a brain wallet is only as good as the randomness of the underlying passphrase i.e. terrible. Humans are not good at making random passphrases, and so the search space for an attacker is massively reduced. Instead of searching through every possibility, using a dictionary to search for common words, etc. would likely lead to cracking the wallet relatively quickly.

Is this better than a single iteration of sha256? Probably. Is this a secure key derivation function in any way? Absolutely not.

Out of curiosity, what is the source of the "Antiviral License?" I can't find any reference to it elsewhere on the internet.

Also of note, while I don't know if you particularly care about this, but what you're describing is not open source software. Per the OSI definition[1], software licenses which restrict against specific fields of endeavor, persons, or groups, are not open source.

Additionally, the restriction on copyleft licenses seems vague--what defines a copyleft license? Is there a distinction between strong (GPL, AGPL) and weak (MPL, LGPL) licenses? IANAL, but I feel like it might be better to just use an established license.

[1]: https://opensource.org/osd-annotated

Wow, I'm an idiot.

P2PKH transactions are not actually smaller than P2PK transactions (I swear to god it was in the wiki somewhere, but I can't find it now for the life of me). While the redeem script is smaller, the full public key now has to be included in the input script, making it much larger. And here I was thinking I made some magical space-saving discovery

Every resource I've looked at seems to suggest that the HTLCs used by LN are roughly of the form


Why was this was chosen instead of a variant based on the hash of the public key, similar to the standard P2PKH script? Something like


I'm sure that this could be expressed more elegantly, but whatever. If my arithmetic is on, doing so would shave off 19 bytes per script (64 bytes for two pubkeys vs 45 bytes for the two hashes and 5 extra opcodes).

So what's the catch? Am I missing something important in the script? Any insight would be appreciated.

Not all transaction scripts are the same! The majority are, but scripting provides for more flexibility. The standard way of using custom scripts is to use a P2SH transaction, in which funds can only be unlocked if a certain script is fulfilled. This is how multisig, time locks, and even puzzles can be added to funds.

As always, the Bitcoin Book (http://chimera.labs.oreilly.com/books/1234000001802/ch05.html) is a great resource if you want to know more.

What do you mean by interoperate? SegWit activation has paved the way for cross-chain atomic swaps, in which some amount of BTC is exchanged for another coin P2P, with no transactions recorded on-chain.

This has been demonstrated with several SegWit coins, such as LTC and VTC.

https://bitcoinmagazine.com/articles/lightning-network-now-supports-transactions-across-blockchains/

By pay to address do you mean P2PKH?

P2PK (pay-to-public-key) is a legacy format that I believe is no longer considered standard. Essentially, the full public key is included in the transaction's output script. The script is thus of the form


With P2PKH, only a hash of the public key is included in the output script. The script is of the form


The hash is only 20 bytes, instead of the key's 32, saving some space. The spender includes the public key and signature, the same as with P2PK, but the sender has saved 9 bytes (20 bytes for the hash and 3 for the extra script ops vs 32 bytes for the full pubkey).

P2SH is a whole separate shebang. The output scripts for these are of the form


where the hash is that of the redeem script (the script specifying the conditions necessary to spend the funds).

A transaction can have inputs signed by multiple keys--this is the concept behind hierarchical deterministic (HD) wallets, among others.

Bitcoin inputs and outputs are not just sent to addresses, they are controlled by scripts. Outputs should generally conform to standard script formats (P2PKH, P2SH, etc.), and inputs contain instructions to unlock them. Saying that value is sent to an address is essentially shorthand for saying, "This transaction has an output with a script that can be unlocked by a signature for this public key."

What I'm getting at is, which transactions are sending funds in which direction is complicated, and you won't be able to find a way to cover all your bases. The scheme you described should cover many cases, but it might be worth it to reevaluate this way of thinking about transactions if it's really that central to your application.

Does the wallet come with an RPC interface? If not, it may be hard to accomplish this.

The newest standard transaction types are P2WPKH (pay-to-witness-public-key-hash) and P2WSH (pay-to-witness-script-hash). Each of these can be expressed in two ways, native SegWit or embedded P2SH. While the former is smaller, it requires that the sending client supports bech32 addresses (see https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki). AFAIK, only Electrum does at this point, so for backwards compatibility, SegWit addresses can be wrapped in a P2SH address--thus making them understandable by essentially all clients. For a more in-depth explanation, see BIP 141 (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).