There are a bunch of possible reasons for a force close - I will elaborate on the most common ones.
⚠ This is a work in progress and will get expanded.
WHAT HAPPENED?
An HTLC (a lightning transaction) timed out, which means it did neither succeed in arriving at it's
| 1/ About the nature of Payjoin Transactions and Deception Tools | |
| I'm used to describe Payjoin Transactions as Steganographic Transactions but they can also be described more generally as "Deception Tools" (https://medium.com/@laurentmt/hi-ilya-e72ddda60b35). | |
| In my humble opinion, the use of deception tools is a legit and effective strategy for improving on-chain privacy but it's important to keep in mind that the deception game has its own rules and these rules are very different from others approaches (like "privacy backed by maths" tools). | |
| An important principle of this deception game is that it must introduces and preserves some kind of morphism between interpretations. It should be absolutely impossible for an analyst to distinguish between one form and the other. | |
| For instance, we have: |
| #!/usr/bin/env python | |
| from __future__ import print_function | |
| """ | |
| Find/count JM transactions in blocks. | |
| Ensure your joinmarket-clientserver virtualenv (jmvenv) is activated, | |
| make sure your Bitcoin Core node is available and joinmarket.cfg is appropriately set. | |
| Pass start and end block number: | |
| `python jmtxfinder.py 400000 400200`. |
24/02/2019
JoinMarket has a tumbler application which aims to send bitcoins in a way that delinks the origin and destination.
I have some thoughts on how and why to improve the tumbler algorithm.
Feel free to bikeshed some of these parameters (averages, counts, etc), as my important points are about other stuff.
Described here is a variant of what has previously been published under the name "P2EP" or Pay-to-endpoint, in which A pays B but B contributes utxos, i.e. it's a coinjoin-payment.
I'm using the term "payjoin" here to refer to using that idea, but not including a URI/endpoint specific to B, and not allowing (as a merchant would) arbitrary payments, which opens up certain problems around snooping attackers (more on this below). So payjoin just means "A pays B but B actively participates and passes across utxos as extra inputs".
I'll defer a more features-focused and non-tech friendly description of what this means to a later blogpost.
This is a quick sketch of several modifications to zerolink. This document tries to articulate an as of yet unproven intuition is that combined together they can allow unequal input amounts as well as relaxation of the post-mix no linking restriction, while retaining the same conservative assumptions about mixed output indistinguishability.
Disallowing post-mix linking is arguably bad for fungibility, since users are likely to bypass this restriction by transferring to other wallets. Therefore, if I am able to justify this change this seems like a much more substantial contribution to usability and fungibility. That said even if it can't be shown to be reasonable to do so, some of these ideas still have merit on their own, so not all would be lost.
For Educational and Informational Purposes Only. The information contained in this Gist is for educational and informational purposes only, and is made available to you for your own use.
This hypothetical exploit details how a malicious actor could steal goods or services from a merchant using Bitcoin Cash. This exploit takes advantage of the acceptance of unconfirmed transactions in the Bitcoin Cash community.
Imagine you have 4 BCH addresses, with funds on address 1. Just before you pay the merchant, you send 3 transactions in quick succession this order.
Options contracts can be implemented as trust-minimized smart contracts using Bitcoin script. These contracts don't require oracles feeding the price into the blockchain or any other trusted third party. Recipients will only trust miners to mine (and not reverse) transactions paying a reasonable feerate, securing their payouts.
The underlier of these derivatives can be any digital asset available on a blockchain that can do HLTCs.
The buyer of an American-style call binary option pays a premium (eg: 0.1 BTC) for <seller secret> wich gives the right to buy Q units (quantity) of the underlying asset (100 LTC) at a specified strike price (0.016 BTC per LTC) at any time until the expiration date.
| Utxos are grouped by address type (P2PKH, P2SH-P2WPKH, or P2WPKH). | |
| The group with the same address type as the address being spent to is selected if it is >= twice the spend amount. | |
| If the above condition is not met, then a group with a different address type and a total value >= twice the spend amount is selected. | |
| If the above condition is not met, then 2 groups with total amounts >= the spend amount are chosen. | |
| Transaction composition is arranged by “sets”. | |
| For each set: | |
| The utxos are processed in randomised order. |
| from bitmerchant.wallet import Wallet | |
| from mnemonic import Mnemonic | |
| # put in whatever Trezor generates for you here (or backup from this empty/insecure one as a test) | |
| mnemonic = 'clean health food open blood network differ female lion eagle rough upon update zone antique defense venture uncover mobile charge actress film vocal enough' | |
| passphrase = '' # empty string or whatever you actually choose | |
| path = "m/44'/0'/0'/0/0" # whatever shows up on the UI for that account (everything will start with m/44'/0' since it's bip44) | |
| child = Wallet.from_master_secret(Mnemonic('english').to_seed(mnemonic, passphrase)).get_child_for_path(path) | |
| child.to_address() # '18K9axbPpwqZgngB58nuwsYevL2z6ey4YG' (confirm this matches what Trezor is showing you) |