Funds received still shows pending and unavailable until confirmed in Exodus. Should I be concerned?

I have a transaction I received in my account that has been marked as pending for the last 12 hours (now 16) and counting. The BTC and US equivalent shows in my wallet (Exodus) but the wallet has it pending and states its unavailable until confirmed. This has me a bit worried that I will not receive my funds, even though when I check the transaction ID on BlockChair it shows 77 (now 102) confirmations. This is first time a transaction has taken so long, the most time it took in the past was more or less 30 minutes. Thanks in advance for educating me on the subject.

Help needed with PyWallet and wallet dump using MacOS

Could anyone please give me some guidance on how to perform a wallet dump using PyWallet on a MacBook (macOS 10.12 Sierra)? I’m not very savvy with this stuff at all. Have an old wallet.dat file from 2011 that I want to check all the keys from and was reading that doing a wallet dump would be an efficient way to do it without having to wait for the entire blockchain to sync on Bitcoin Core. Having a really hard time trying to figure out how to do it with almost no computer programming knowledge. So far I have Python 2.7 downloaded but am pretty stuck after that. Any help would be greatly appreciated. Thank you!

What are the reasons to avoid spend-paths that become invalid over time (without a transaction)?

I have been told that a spend-path that expires is something bitcoin designers have explicitly avoided, and that it would cause bad reorg behavior (eg here).

To be clear about what I mean by an expiring spend-path, imagine a script opcode that require that a particular spend-path be executed before a timelock has expired (rather than the usual timelock where the spend-path is only valid after the timelock expires).

Satoshi mentioned this kind of thing here saying that:

“In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn’t be fair to later owners of the coins who weren’t involved in the time limited transaction.”

However, if you wait for 6 confirmations, no transactions should be happening that expect to have actually received the coins if, say, a transaction is sent with only one or two confirmations. If that happened, a reorg after 3 confirmations would invalidate those transactions too. And a reorg after more than 6 confirmations is statistically impossible unless a 51% attack is underway. So I don’t understand satoshi’s point here.

I was also told that during a reorg, nodes don’t have to re-evaluate transactions that have already been validated, but if an expiring spend-path then you would have to re-evaluate transactions. However, don’t’ nodes have to re-evaluate transactions in a reorg anyways currently? Since the re-org could have introduced double-spending transactions, all transactions need to be rechecked in the new UTXO context, don’t they?

I was further told that there are “a whole bunch of other reasons”. I’m curious what they are, but I haven’t been able to find much discussion of these things by searching for “bitcoin monotonic” and “bitcoin context free”. I would very much appreciate links to more information about these issues.

Missing Checksum error when importing multisig wallet via descriptor

I’m trying to import a multisig wallet on regtest, but getting a strange error. What am I doing wrong? I’ve tried it with xpubs, tpubs, and Vpubs (converted here) and get the same error for all.

Command:

bitcoin-cli -regtest importmulti '[{"desc": "wsh(multi(2,tpubDDgGUQsV9M7N5DD3WQmkqkq9UXkSvfHvyefNDx2b7KwmukE6FfuFk3JfncmjCNnG9scWcdz6MEeNPZXHArkGFuTXTsZNr4288ULxuTDjB6u/0/0/*,tpubDCDw2UcGohVP3rK8kPW8g9hwBojpwzYdjLxQ6AnnuRvThH7q1vwGneGAUkfZYqJo9eKFGzuP4WwaKsQkEqqnwLd1eT2CtpAKQispgxadHWB/0/0/*))", "range": [0,10], "watchonly":true, "timestamp":"now"}]'

Error:

[
  {
    "success": false,
    "error": {
      "code": -5,
      "message": "Missing checksum"
    }
  }
]

What happens to transactions in the mempool when their parent transaction expires?

I was just reading the Coin Metrics Newsletter #53, and it included a section about the recent mempool congestion. After mentioning transactions that got evicted due to the network’s queue of unconfirmed transactions exceeding the default mempool limit, it mentions about transactions expiring due to the 14 day limit:

Secondly, transactions residing in the mempool for over two weeks expired. By default, Bitcoin Core nodes remove transactions from their mempool if no miner found transaction fees to be attractive enough to include them in a block over the last 336 hours (two weeks).

In total 1,627 transactions expired between May 25th, and May 30th. Only 35% of these resided in the mempool for two weeks. The remaining 65% likely spent unconfirmed parent transactions and became invalid as their parents expired.

In the last sentence (highlight added), the newsletter describes that transactions chained from expired transactions would get dropped from the mempool as well. Is that an accurate description of the mempool behavior?

If yes, let’s say txA was in the mempool for two weeks and got dropped, and txB was a CPFP transaction spending an output of txA which therefore got invalidated and dropped as well.

What would happen if the original sender rebroadcast txB? Given that txB inputs would appear to not exist without the context of txA, would the peers of the sender request the preceding transaction txA or just reject txB? Would then the two transactions repropagate as a unit?

How Crypto Payment Processors Handle Wallet Balance Privacy?

If an online store accepts crypto payments directly into its wallet there is a problem:

“Anyone can make a small transfer to any BTC address derived from the MPK so they can watch the store’s and its client’s funds as soon as the owner transfers funds from her wallet. I suppose possibly that the person who did this wanted to know if cracking the store worth the effort.”

In a previous question a user replied that a solution to this is to use a crypto payment processor like BitPay but:

  • How they handle wallet privacy? Isn’t it the same? The BTC only gets
    to make a higher number of transactions between different addresses
    but still, they can be traced to the store owner’s wallet and her
    client’s afaik.

  • Or if the transaction is too small to match the price of the
    purchase, BitPay returns the transaction to the originating address
    and the BitPay address that accepted the transaction gets dumped so
    it can’t be used to trace BitPay’s customer real address?

  • Another way I think this could be avoided as well is if BitPay
    converts the payment to fiat, then to BTC again and then transfer the
    funds to the customer wallet.

  • Wouldn’t it be easier just to avoid payment processors and convert
    the BTC to a privacy coin like Monero? For example using a
    transitional wallet in the store to accept payments, making smaller
    transactions to an exchange, converting to Monero and back to BTC and
    then transfer to the owner’s real wallet?

  • Could this method conceal the store owner and her client’s wallet
    balance to any potential hacker who makes a small transaction to any
    store wallet MPK derived address?

  • Or the only way is to use a payment processor? If so, then how they
    conceal their customer’s wallet balance?

Thanks for your attention, it’s a confusing subject for me and I hope to have written my questions as succinctly & understandably as possible.

Reuse of payment hash in Lightning Network

Suppose there exist two such payment transfer request: A transfers 1 msat to R via A->B->C->R and S transfers 5 msat to R via S->B->C->R. Let the two HTLCs be formed across both the paths simultaneously and let both the payment use the same payment hash say H. Now channels B-C and CR has two HTLC using the same payment hash. As mentioned in https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages it is stated that “An intermediate hop MUST NOT, but the final node: if the payment hash has already been paid: MAY treat the payment hash as unknown or MAY succeed in accepting the HTLC.” It seems that R can release the preimage of H and settle both the payment if R has received both the HTLC request at the same time. However, is it so that R will settle one payment and fail the other so as not to encourage the reuse of hash?

C.Pay card programme announcement

We’ve been working towards this moment for a long time, and it has finally come. C.Pay cards are back! First available only to residents of the UK, we will be launching the programme in the rest of the EEA shortly. Find out what you should expect from the new card in this article. Archive shot of the … Read more

How does having a large mempool and allowing a greater transaction ancestry set change the interaction with your peers?

Bitcoin Core by default allows up to 300 MiB of mempool data, and restricts unconfirmed transaction trees to an ancestry set of at most 25 transactions and 101 kvB of transaction data. Since these are config values, you can obviously use other values than these. How does this change your node’s interaction with its peers? Do peers send data that exceeds your node’s preferences and your node drops that data upon arrival or does your node inform its peers what to send? Is this the same for mempool data generally and unconfirmed chains specifically? If you allow more data via higher values, does your node forward previously unacceptable data to its peers once their backlog clears enough for the data to be accepted by them?