text:
Electrum-personal-server isn't seeing any historical transactions; using a Trezor
I followed the instructions in the Electrum Personal Server guide. I know that the transactions are there because I checked wallet.trezor.io. But none are showing up in Electrum. I have run --rescan. I have bitcoind running in the background as a full node.
The instructions are here: https://github.com/chris-belcher/electrum-personal-server

It's the wallet type. There are three address types: legacy, p2sh-segwit and segwit. Choose the right one or your transaction history will be empty.


text:
Watch-only addresses inside segwit transactions
I'm using bitcoin core (via rpc api).
I've generated one 2of2 multisig address on electrum wallet, and after that, I've imported that address into bitcoin core by using importaddress rpc method. When I want to create a transaction by using createrawtransaction, that method returns non-segwit encoded transaction. How can I force creation of segwit transaction (inputs are only from watch only multisig addresses), and is this even possible? I'm using bitcoin core 17.0
For multisig addresses generated inside that wallet, it creates segwit transaction.
I want to use bitcoin core only with watch-only multisig addresses, and when I want to spend some output, I use rpc method signrawtransactionwithkey to sign transaction. And that works. The problem is that I don't know if it's even possible to use segwit in that case. Multisig addresses are generated from p2wpkh addresses (on Electrum wallet).
Here are the steps (testnet):
1. Inside the Electrum wallet's console, I've generated a multisig addresses, by using these commands:
addresses = list()
addresses.append(createnewaddress())
addresses.append(createnewaddress())
pubKeys = getpubkeys(addresses[0])
pubKeys.append(getpubkeys(addresses[1])[0])
privateKeys = getprivatekeys(addresses)
multisigAddress = createmultisig(2, pubKeys)

I've got address 2NGAAYNVCrzmNJHoTfQMuiDYtAwsHTmMQ1m, pk1, pk2, and  redeemScript (prefix before private keys says that those two addresses used for multisig creation process are p2wpkh).

2. Importing address as watch-only in bitcoin-core:
bitcoin-cli importaddress 2NGAAYNVCrzmNJHoTfQMuiDYtAwsHTmMQ1m false

3. I've sent a small amount of BTCs to this multisig address.

4. Create raw transaction:
bitcoin-cli createrawtransaction '[{"txid":"44e42d229d94161debe4dc644bce4f669feb11a6107b2ffa4236df0420d72ccd", "vout":1}]' '{"2MwbQRMJDvaGBTB3dpLhwus5nwmLfUWm2cD":0.11000999}'
result: 0200000001cd2cd72004df3642fa2f7b10a611eb9f664fce4b64dce4eb1d16949d222de4440100000000ffffffff01a7dca7000000000017a9142fb187dd5e402c645aeda05394ff3d8c70d5d1bb8700000000

5. Transaction signing
bitcoin-cli signrawtransactionwithkey 0200000001cd2cd72004df3642fa2f7b10a611eb9f664fce4b64dce4eb1d16949d222de4440100000000ffffffff01a7dca7000000000017a9142fb187dd5e402c645aeda05394ff3d8c70d5d1bb8700000000 '["{pk1}", "{pk2}"]' '[{"txid":"44e42d229d94161debe4dc644bce4f669feb11a6107b2ffa4236df0420d72ccd", "vout":1, "scriptPubKey":"a914fb55ef9d9ffac793832ada2b63e747f94a630b9e87", "redeemScript":"{redeemScript}", "amount":0.111}]'
result: 0200000001cd2cd72004df3642fa2f7b10a611eb9f664fce4b64dce4eb1d16949d222de44401000000d90047304402205e90adeca33e882813bc2a03aa2b631e895853961058f7bad98a86410dc26e5d02204d40d6ee562ae07dd2b75c058e0cc8ae79b1ee6f9a244c50bf713b0ec3b45dba0147304402200193c7d676b70ec3de6f53baf07a6c1498c86253dcca686eda05def58dda0b090220290d23f332a592dce1485256200f98c24b48166671b72da937ea45da7f53782f0147522102591616129c718dd806042cafea42ddcba88657a745f7e6c79df51919dbf0cea721025b014c62165a7465efbca3780e499363ec8ee8f8b0ed577d8d8297a53f3098b152aeffffffff01a7dca7000000000017a9142fb187dd5e402c645aeda05394ff3d8c70d5d1bb8700000000

As you can see, this isn't a segwit transaction.
Decoded:
{
  "txid": "26d32452f0897d6bb6663619667826b952e2dd4a19df6518c015f662a0f8333e",
  "hash": "26d32452f0897d6bb6663619667826b952e2dd4a19df6518c015f662a0f8333e",
  "version": 2,
  "size": 300,
  "vsize": 300,
  "weight": 1200,
  "locktime": 0,
  "vin": [
    {
      "txid": "44e42d229d94161debe4dc644bce4f669feb11a6107b2ffa4236df0420d72ccd",
      "vout": 1,
      "scriptSig": {
        "asm": "0 304402205e90adeca33e882813bc2a03aa2b631e895853961058f7bad98a86410dc26e5d02204d40d6ee562ae07dd2b75c058e0cc8ae79b1ee6f9a244c50bf713b0ec3b45dba[ALL] 304402200193c7d676b70ec3de6f53baf07a6c1498c86253dcca686eda05def58dda0b090220290d23f332a592dce1485256200f98c24b48166671b72da937ea45da7f53782f[ALL] 522102591616129c718dd806042cafea42ddcba88657a745f7e6c79df51919dbf0cea721025b014c62165a7465efbca3780e499363ec8ee8f8b0ed577d8d8297a53f3098b152ae",
        "hex": "0047304402205e90adeca33e882813bc2a03aa2b631e895853961058f7bad98a86410dc26e5d02204d40d6ee562ae07dd2b75c058e0cc8ae79b1ee6f9a244c50bf713b0ec3b45dba0147304402200193c7d676b70ec3de6f53baf07a6c1498c86253dcca686eda05def58dda0b090220290d23f332a592dce1485256200f98c24b48166671b72da937ea45da7f53782f0147522102591616129c718dd806042cafea42ddcba88657a745f7e6c79df51919dbf0cea721025b014c62165a7465efbca3780e499363ec8ee8f8b0ed577d8d8297a53f3098b152ae"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.11000999,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 2fb187dd5e402c645aeda05394ff3d8c70d5d1bb OP_EQUAL",
        "hex": "a9142fb187dd5e402c645aeda05394ff3d8c70d5d1bb87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2MwbQRMJDvaGBTB3dpLhwus5nwmLfUWm2cD"
        ]
      }
    }
  ]
}

The fact that createrawtransaction does not give you a segwit-encoded output is completely expected, as it has no witness. That's not a problem; signrawtransaction will happily take it, and add a witness if needed, and return a transaction in segwit format in that case.

The problem is that signrawtransactionwithkey also returns a non-segwit transaction (flag for segwit in encoded transaction is not active).

Please describe in details all the steps and RPCs you are using. The raw transaction API certainly supports creating segwit spends, but can be annoying to use.

I've added all the steps into my first post.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
TimeoutError: [WinError 10060] when trying to connect to bitcoin rpc from a pc on the same local area network
I have a laptop with win10 installed. It is now running a full bitcoin node perfectly. I am already able to make rpc requests from the laptop using python and get valid responses. The laptop is connected to the Internet using a LAN port on a Router that also has WiFi option. Now the question is: is that possible to make bitcoin rpc requests from another PC that is connected to the same router but through Wifi? When I try to do that I get a timeout error which I cannot recognize why. I tried to add a line to my bitcoin.conf to possibly increase the timeout parameter as rpcclienttimeout=200 but it doesn't seem to work. The whole content of my configuration file is as following:
server=1
daemon=1
txindex=1
rpcuser=***
rpcpassword=******
rpcallowip=192.168.1.0/24
rpcclienttimeout=200
#rpcallowip=127.0.0.1
#rpcconnect=127.0.0.1

Am I missing something? PC#1's IP which is running the bitcoin node is 192.168.1.104 and PC#2's IP which is supposed to get rpc access is 192.168.1.102.
When I run the following python code from PC#1 I get my supposed responses perfectly, But when I run the second python script from PC#2 I get timeout error.
The Code run from PC#1:
from time import time_ns as time
import csv
import numpy as np
import matplotlib.pyplot as plt
from rpcreq import *
import json
import os

def avg(L):
    return sum(L, 0.0) / len(L)

rpcPort     = "8332"
rpcHost     = "127.0.0.1"
rpcUser     = "******"
rpcPassword = "******"

serverURL = ("http://{user}:{password}@{host}:{port}").format(
        user=rpcUser,
        password=rpcPassword,
        host=rpcHost,
        port=rpcPort
    )

method = 'getblockcount'
params = []
resp   = rpcreq(method, params, serverURL)
nBlock = resp['result']
iters  = nBlock
iters  = 100
print(nBlock)

BlockHash = [0]*(iters)
method1   = 'getblockhash'

start = time()
for pj in range(0, iters):
    params          = [pj]
    resp            = rpcreq(method1, params, serverURL)
    BlockHash[pj]  = [resp['result']]
    print(pj)

end = time()
endtns = (end-start)/(iters+1)
endts = endtns / 1000000000
print('Each Reading Will Take: ', endts, 'Seconds.')
print('Reading All Block Hashes Will Take: ', endts*nBlock/3600, 'hours.')

x      = np.arange(0.0, iters, 1)
y      = BlockHash

x = [*x]
List = [
            ['Height']            + x,
            ['BlockHash']         + y,
        ]

with open("BlockHashFirst{}.csv".format(iters), 'w', newline='') as rF:
    wr = csv.writer(rF, dialect='excel')
    for i in range(len(x)+1):
        wr.writerow([r[i] for r in List])

The Code run from PC#2:
from time import time_ns as time
import csv
import numpy as np
import matplotlib.pyplot as plt
from rpcreq import *
import json
import os

def avg(L):
    return sum(L, 0.0) / len(L)

rpcPort     = "8332"
rpcHost     = "192.168.1.104"
rpcUser     = "******"
rpcPassword = "******"

serverURL = ("http://{user}:{password}@{host}:{port}").format(
        user=rpcUser,
        password=rpcPassword,
        host=rpcHost,
        port=rpcPort
    )

method = 'getblockcount'
params = []
resp   = rpcreq(method, params, serverURL)
nBlock = resp['result']
iters  = nBlock
iters  = 100
print(nBlock)

BlockHash = [0]*(iters)
method1   = 'getblockhash'

start = time()
for pj in range(0, iters):
    params          = [pj]
    resp            = rpcreq(method1, params, serverURL)
    BlockHash[pj]  = [resp['result']]
    print(pj)

end = time()
endtns = (end-start)/(iters+1)
endts = endtns / 1000000000
print('Each Reading Will Take: ', endts, 'Seconds.')
print('Reading All Block Hashes Will Take: ', endts*nBlock/3600, 'hours.')

x      = np.arange(0.0, iters, 1)
y      = BlockHash

x = [*x]
List = [
            ['Height']            + x,
            ['BlockHash']         + y,
        ]

with open("BlockHashFirst{}.csv".format(iters), 'w', newline='') as rF:
    wr = csv.writer(rF, dialect='excel')
    for i in range(len(x)+1):
        wr.writerow([r[i] for r in List])

The second code is only different on the parameter rpcHost.
When running the second code I get a full error as:
TimeoutError: [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

Any tips on where I am mistaking the concept?

rpcbind answer length too short

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Adding C library to Makefile
I am developing an altcoin using a new PoW algorithm which is written in C to test the algorithm. I get compilation errors related to compiling the C code when trying to compile. How can I properly add the C code to the Makefile?
My fork is based of Bitcoin Core 0.12.1
I am compiling on Ubuntu 16.04
Here is the compilation error:
  CXXLD    bitcoind
  /usr/bin/ld: crypto/libbitcoin_crypto.a(crypto_libbitcoin_crypto_a-
  rainforest.o): relocation R_X86_64_32S against `rf_crc32_table' can not be
  used when making a shared object; recompile with -fPIC
  crypto/libbitcoin_crypto.a: error adding symbols: Bad value

Here is how I added the files to src/Makefile.am:
# crypto primitives library
crypto_libbitcoin_crypto_a_CPPFLAGS = $(AM_CPPFLAGS)
$(BITCOIN_CONFIG_INCLUDES)
crypto_libbitcoin_crypto_a_CXXFLAGS = $(AM_CXXFLAGS) $(PIE_FLAGS)
crypto_libbitcoin_crypto_a_SOURCES = \
   crypto/common.h \
   crypto/hmac_sha256.cpp \
   crypto/hmac_sha256.h \
   crypto/hmac_sha512.cpp \
   crypto/hmac_sha512.h \
   crypto/ripemd160.cpp \
   crypto/ripemd160.h \
   crypto/sha1.cpp \
   crypto/sha1.h \
   crypto/sha256.cpp \
   crypto/sha256.h \
   crypto/sha512.cpp \
   crypto/sha512.h \
   crypto/rainforest/rainforest.c \
   crypto/rainforest/rainforest.h

The files are rainforest.c and rainforest.h
Sorry for this question, I am a newbie in C and C++ developing, I come from Java and Python
EDIT: I didn't mention before that I linked rainforest.h by doing this:
extern "C"{
#include "crypto/rainforest/rainforest.h"
}

What/of which type is rf_crc32_tabl?

@MCCCS It is declared as const uint32_t rf_crc32_table[256]

If you include the functions with extern "C", then you should also declare them with extern "C" in the source file. Although your file is a c file, keep in mind that it'll be compiled by the cpp compiler.

@MCCCS Tried that, got the same error, not sure what to do but I think there may be a way to change the makefile so the compiler properly compiles

I was able to solve this by compiling using make -j2 CFLAGS="-fPIC"
That solution isn't that convenient, I would rather modify the configure.ac or Makefile but it works.

One last guess: renaming the rainforest.c to rainforest.cpp might work.


text:
Decentralized product inventory (instead of simple orderbook)
I am thinking of creating a decentralized market place with public bidding. AS far as I have researched all cryptocurrencies and such only offer public ledgers with simple orderbooks. The only data about the item you are exchanging is value like BTC->USD or USD->BTC.
I was hoping to have a decentralized public market for more complex products which have many properties (let's call them CPU, memory, bandwidth, storage and lease time). In this case, you would not bid against a single value (price), but define the acceptable parameter ranger for your bid e.g. 30x units with > 512 MB memory, 1 MBit/s bandwith at the price of 1 USD/unit.
Then the ledger would go through the offers and match ones available on the market. Then trade parties would exchange private keys, so that the buyer would get the access to the item. I have no idea yet how, but probably the buyer would have an encryption key in the bid and if the bid goes through then the seller would encrypt a reply to the buyer using this key (the buyer can only decrypt).
As I am still in early phases of my research, I was wondering is there any prior art in this kind of crypto markets? Preferably the ledger data and the orders are public in consensus or blockchain, so that the there is no single point of failure in the system.
Thus far I have researched

NXT
Stellar
Bitshares X
OpenBazaar (this looks promising but orders and inventories are not decentralized ATM)
Ethereum (well this one is still much in baking)

'cryptocurrencies and such only offer public ledgers with simple orderbooks' ledgers are not order books. Crypt I currencies don't offer order books. Exchanges do.

Here is one example of a cryptocurrency offering a ledger and orderbook https://www.stellar.org/api/#api-book_offers

Another example: http://wiki.bitshares.org/index.php/Bitshares_X#Claim_by_Bid

Looks like an API to a centralized exchange server. Just like any bitcoin exchange. But I might be wrong, I don't care for altcoins. Bitcoin and most (all?) forks do not provide order books. They may have exchange built around them but those are not part of the coin and usually (always) centralized. For an orderbook to be part of the coin it would need to be done in a p2p network where there is no central party taking matching decisions. So matching would need to be done via a blockchain consensus mechanism.

Thank you for your comment. If you find anything which contributes to the answer and which you think I am not aware of yet, please let me know.

I think Ethereum is ideal for this.  As you say, it's not ready for prime time yet. But I think it offers the most flexible toolkit for managing orders in a truly decentralized way. You can create and manage arbitrary database structures that are secured on the blockchain.
I wrote a toy digital artwork market using Ethereum -
http://robmyers.org/2014/07/24/ethereum-art-market/

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Bitcoind with -txindex=1 still no mempool transactions
I'm reading through Mastering Bitcoin and trying to follow along the examples.
When I first initialized bitcoind, I set txindex=1 in my bitcoin.conf file. In a later example I was unable to getrawtransaction which failed with the error No such mempool transaction. I re-ran bitcoind with the -txindex=1 and -reindex flags, which took a few hours.
However I'm still unable to getrawtransaction, which again fails with the same error.
Have anyone experienced the same issues? Perhaps there is something else that needs to be done for this to work in v0.16.0?
Any advice would be appreciated. Thanks.
Edit 1:
~/Library/Application Support/Bitcoin/bitcoin.conf:
txindex=1

~/Library/Application Support/Bitcoin/debug.log:
Dropbox link

Can you give an example of a txid that fails like this?

@NateEldredge any transaction without an unspent output really, just as expected if txindex was set to 0. For an example, the below transactions give me that error:
3fd3431462b46b4adc8e3da663582993ecbfebf62ef7de4d81115b235a5020de
331dd436aebeb22c9b629d6a769fd3f679e18ca4c6c34b15d6b3ab9ce936cd05
45ea0a3f6016d2bb90ab92c34a7aac9767671a8a84b9bcce6c019e60197c134b

Is bitcoind fully reindexed? Can you post the contents of your bitcoin.conf and debug.log files?

@AndrewChow added to the original question

According to your debug.log file, txindex is not enabled:
2018-04-22 20:40:34 LoadBlockIndexDB: transaction index disabled

This indicates that your bitcoin.conf is incorrect. Make sure that your bitcoin.conf file's full filename is actually bitcoin.conf (not bitcoin.conf.txt or with some other extension).

You're right, it seems as though the paths confused me a little. I specified ~/Library/Application Support/Bitcoin/bitcoin.conf instead of ~/Library/Application\ Support/Bitcoin/bitcoin.conf which ended up saving the file as ~/Library/Application. However I'm still a little confused as to what went down during the almost full day it spent reindexing when I ran bitcoind -txindex=1 and subsequently bitcoind -reindex. I have however created the correct bitcoin.conf file now and will reindex and try again.

Whenever you start with -reindex, the blockchain will be read off disk and all of the block and chainstate databases will be rebuilt. This will happen for all -reindexs regardless of -txindex. With -txindex, the reindex will do the same but include more data in the databases it builds. Specifying -reindex will reindex even if one is not required.

Great, thank you so much for that information. It was very helpful!

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How to do a 51% attack on my own altcoin
recently I have been curious about 51% attacks so I created a fork of litecoin and want to do a 51% attack on the coin but don't know how to. please can you tell me how to do it.
Thanks,

This question is somewhat like asking, "how can I steal money from myself?"
Since you are the only person participating in the consensus of your altcoin, you control 100% of the hashpower. A 51% attack creates an alternative ledger, breaking consensus on which coins have been transferred, allowing the attacker to create a double spend.
First mine two competing chains, Chain A and Chain B.
In chain A, mine a block with a transaction that sends your coins to an address.
In chain B, mine a block with a similar but different transaction that uses the same transaction inputs as the first transaction but sends the coins to a different address.
There two transactions claim to transfer the same UTXO to two different addresses. There are two incompatible versions of the ledger, only one will be accepted. Eventually the one will with the most hashpower will have more work, and the other will be rejected (See chain reogranization).
A merchant or exchange should wait for sufficient block confirmations before accepting a payment, such that it is more profitable for a attacker to mine honestly, rather than investing the vast effort usually required to create an alternate version of the ledger in which the exchange/merchant has been defrauded. (See confirmations)


text:
Blockchain.info confirmation misunderstanding
I have some misunderstanding regarding how confirmation work on blockchain.info. If we go to payment history we can see info about confirmation in two places. First in history of all transactions. Like this

And second place is on the transaction info page

Could someone explain me please what's the difference between this to fields?
Why in one place they show Pending status and zero confirmations while in the other one they show 230K confirmations?

It would be easier to answer if you didn't black out the received time and included in blocks field in the image. Are you sure they are the same transaction? If yes, then probably 232181 confirmations refers to how many confirmations the input used for the transaction has and not the transaction itself. Can you share the txID or the uncensored image?

@Pedro I'm sure this is the same transaction. In my wallet all transactions look like this. A lot of confirmations in details, but zero in wallet history

@Pedro do you have confirmations in first screenshot in your wallet?

I never used blockchain.info but I suppose 232181 refers to how confirmations the input of the transaction you made had...

@Pedro could you please explain what does it mean? Maybe you have link to some information regarding this?

Would be easier to confirm it if you shared the txID. If you send money from A > B in block 1000, and try to send B > C at a blockchain height of 1500. While the B > C transaction is pending and has 0 confirmations, the input B has already 500 confirmations (1500 - 1000 = 500).

@Pedro oh, I got it. Thank you. So if I have enough blocks that has my transaction I can be sure that it is valid and confirmed? Okay, but what blockchain.info confirmations mean then

0 confirmations means that the transaction is waiting to be included in a block by a miner, 1 confirmation means that the transaction was included the the last block of blockchain, 2 confirmations means that the transaction was in the second to last block of the blockchain, and so on...

@Pedro ok, lets take a look at this example tx https://www.blockchain.com/btc/tx/a2e4a1624eab2aff0c41a00e58eed94bb9aa4f5df19889aa1ef99d58f50426cb this is confirmed transaction. But! In the blockchain.info site on the wallet history tab I see Pending: 0/3 Confirmations. They explain it like this https://support.blockchain.com/hc/en-us/articles/217116406-Why-hasn-t-my-transaction-confirmed-yet-

Well, you can always try a bunch of blockchain explorers and see what they say about your transaction: https://www.smartbit.com.au/tx/a2e4a1624eab2aff0c41a00e58eed94bb9aa4f5df19889aa1ef99d58f50426cb , https://blockstream.info/tx/a2e4a1624eab2aff0c41a00e58eed94bb9aa4f5df19889aa1ef99d58f50426cb
if they all say 10+ confirmations but blockchain.info says 0, blockchain.info is wrong. Blockchain.info has been losing its reputation since 2011 from what I heard.

@Pedro oh I don't know that, what wallet do you think the best?

I never tried them but I think Bitgo is better, although less well known.


text:
Bitcoin RPC. How to close wallet files opened by bitcoin?
Bitcoin RPC unloadwallet command does not close files opened by bitcoind process.
I want to generate addresses for multiple wallets (over 1000) and get 'Too many opened files error'.
Is there a way to close files, associated with unloaded wallet?
.bitcoin/testnet3/wallets/3f7b93e26b498be43235a9beda796d8d/.walletlock
.bitcoin/testnet3/wallets/3f7b93e26b498be43235a9beda796d8d/db.log
.bitcoin/testnet3/wallets/3f7b93e26b498be43235a9beda796d8d/database/log.0000000001

To begin with, why on earth do you want to do that?

For my project. I generate wallets for customers

That’s generally not how people go about this. At the very least the software isn’t designed to handle tens or hundreds of wallets. Generally speaking if you’re handling customer money it’ll just end up all in one wallet.

Thank you for comments. But why money would end up in one wallet? I have multiple folders under wallets directory. And Bitcoin RPC allows to create and switch between wallets

Why would you want them in separate wallets?

To separate users funds safely

This is a known bug and has been fixed for 0.18 which will be released in the coming weeks.

Yes, thank you a lot. Already found that
Soooo glad it is fixed :) I'm the happiest person today!


text:
how to transmit commitment transaction (unilateral close) from lightning network channel
How would you transmit a commitment transaction from a lightning network channel instead of closing the channel? I am working on implementing a watchtower and I first need to simulate a double spend attempt. When I close a channel with $ lncli closechannel, both nodes have the bitcoin available and neither has to wait for the time lock. Is there a command to get the node to submit a unilateral close commitment transaction where one of them has to wait for the time lock?

LND has an option to close a channel unilaterally as following command,
$lncli closechannel --force funding_txid output_index

I have transmitted a commitment transaction to answer this question. It might be another useful resource of your work.

Generally it is preferable to collaboratively close a channel as it is faster for both sides and saves onchain fees and space. As far as I know implementations do not provide an api to the close command by which you can enforce a certain type of close. In order to achieve what you want you have 2 options:

You Patch your lightning node to provide that api yourself
You run two lightning nodes with a channel between them. Then you turn off one node and run the close command on the other. As the first node is not peered the nodes can't close collaboratively so there will happen a force close.


text:
19 out of 24 words of BIP39 passphrase (brute-force last 5?)
I have managed to lose 5 words of my 24 word Ledger Nano S recovery phrase. I have words 1-19 but I am missing words 20-24. I have significant holdings on the wallet so would very much like to recover it if possible. The passphrase is a BIP39 mnemonic (see https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). I have the bitcoin and ethereum public addresses for this mnemonic. I am wondering if it's feasible to brute force the passphrase.
Each word is 11 bits (2^11 = 2048 possible words). The last (24th) word of the passphrase is of the following form [3 random bits][8 bit checksum]. Therefore I only have to check 2^(55 - 8) = 2^47 = 1.4x10^14 combinations. I would have to compute SHA-512-HMAC with an iteration count of 2048. As far as I understand, that means I'd have to compute 1.4*10^14 * 2048 = 2.87*10^17 hashes in total.
Is there any hardware out there designed for this? I am aware of ASICs that compute sha-256 hashes but not sha-512 hashes. Perhaps I could tweak one to work with sha-512 since they are very similar.
Assuming a fairly typical ASIC hashrate of 1TH/s (10^12 hashes per second), I could exhaust the search space in 2.87*10^5 = 287000 seconds = 3.3 days. I'd probably get there sooner, of course (expected 1.65 days). Time is not something I am worried about. Even if I have to wait months, I don't mind - so if I can get 10GH/s at a reasonable price, that would be great.
I would really appreciate any help/information you could provide to help me out and make sure I haven't missed anything. I could also use GPUs for this (I calculate I can run them at roughly $1/10TH - so it would cost me $28.7k to exhaust the search space, which I will do if there are no cheaper options).
Many thanks, James

This seems to be a duplicate of https://bitcoin.stackexchange.com/q/87326/208


text:
Is there a way to participate in bitcoin consensus (tx, block, mining, etc.) verification without downloading the ledger?
It seems like theoretically new blocks could be determined from the list of addresses and the amounts possessed by each address, where maintaining the blockchain would be optional and mostly for scanning for errors, etc.
address amount
address amount
...
address amount

(If an address possessed zero coins, it wouldn't be included in the db)
Do any wallets currently implement anything like that?
Or do tx verification proofs require summing all the txs of an address?
--
Additionally, if not possible with BTC, is there a crypto network where it's possible to participate in consensus verification without the ledger, and mostly a db of addresses and amounts possessed?

Hey Bryan, after seeing your two questions, I’m wondering whether you are falling into the XY problem. Is it possible that you are asking about the attempted solutions for your problem, rather than your actual problem? What are you trying to do?

@Murchisonstrike, aspirationally, I'm searching for a climate friendly online monetary network (with offline tx signing) that has nearly zero possibility of immutable bad (or illegal) media being inscribed and distributed.

A worthy endeavor, although one that seems to still elude us—at least if we wish to retain censorship resistance and a flexible scripting system.

In case it isn’t obvious to you yet, I think it’s also fair to point out that a fair bit of work is going towards leveraging the on-chain Bitcoin transactions to facilitate a multitude of payments in trust-minimized distributed higher layer systems which use the base layer for arbitration and contract enforcement. As that scales up, perhaps the energy investment at the base layer becomes more palatable.

This is approximately how Bitcoin full nodes already work, though with one important change.

Bitcoin, at the protocol level, has no notion of addresses, and doesn't work in an "account" based fashion, for privacy reasons. Instead, it uses a "UTXO model" (unspent transaction output). The idea that the state of ledger is a set of UTXOs, which you can think of as "coins". Every transaction consumes certain specific, referenced coins in their entirety, and then creates new coins whose combined value does not exceed the consumed coins' value. Each coin has an identifier, an amount, and a locking script which determines the conditions under which it can be spent (as a simplification, you can think of locking scripts and addresses as the same thing). However, coins all have their own identity, and are not identified by their script/address. In order to create a transaction, you have to specify exactly which coins you're spending. The address just controls what signature is expected to sign for it, but there is no balance per address at the protocol level, just coins.
The reason for this UTXO model is privacy: account based models (where the rule is that sending accounts have sufficient funds available) encourage reuse, because reusing the same account is cheaper (both economically and computationally) than creating new accounts for each receipt. Such reuse is horrible for privacy, as it makes it trivial to link transactions of the same user together. In general, we want a system where acting in a more private manner is not more expensive than not doing so. In a UTXO model, reusing addresses is just as costly as using a new address for each receipt, satisfying that property (there are of course other privacy leaks too, not covered by address reuse).

So, with that out of the way, the equivalent of the "address: balance" list you imagine, is actually a "coin: value, script" list, and it is called the "UTXO set".
Bitcoin full nodes actually do not use the blockchain for anything during validation. They download all blocks, check them against the UTXO set (e.g. checking that all coins consumed by the transactions in the block still exist), then update the UTXO set (removing spent coins, and adding newly created coins), and then move on to the next block. Some nodes do keep the block after processing around, but it's just so that they can provide to other nodes who ask for it; they don't use it for validation of future blocks, that just needs the UTXO set. So-called pruned nodes don't keep blocks around after validation.
The current UTXO set is a few GB when stored on disk, and that is the minimum needed to run a node. It is far lower than storing the whole blockchain, which is a few hundred GB.
Now, in order to fully validate without trusting their peers, nodes do need to download and process all blocks, so that they can build up the UTXO set. It's in theory possible to just get the UTXO set from another node, but that does involve trusting that that UTXO set is correct. There is no P2P protocol for doing so, though there is ongoing work (called "assumeutxo") to permit something along these lines.


text:
Getting Error while trying to decode psbt base64 to json using bitcoinjs/bip174 library
const base64PSBT = 'base_64';

// Decode the base64 PSBT to a Buffer
const psbtBuffer = Buffer.from(base64PSBT, 'base64');

// Parse the PSBT
const psbt = bip174.Psbt.fromBuffer(psbtBuffer);

// Convert the PSBT to a JSON object
const psbtJSON = psbt.data;

console.log(JSON.stringify(psbtJSON, null, 2));

error:
const unsignedTx = txGetter(unsignedTxMaps[0].value);                      ^
TypeError: txGetter is not a function

The problem is that in addition to the buffer (denoted as psbtBuffer in the code you provided), it is necessary to pass the txGetter function as a second parameter to the fromBuffer function. If you don't do this, javaScript considers the second parameter as undefined so that later calls to the given function (const unsignedTx = txGetter(unsignedTxMaps[0].value);) will not be possible.
The README says the following:

// This will parse the PSBT, and use the function you pass to parse the Transaction part
// the function should throw if the scriptSig section is not empty
const psbt = Psbt.fromBuffer(somePsbtBuffer, pTxFromBuffer)


text:
non-mandatory-script-verify-flag (Invalid Schnorr signature) when trying to reveal a TR output
I'm building a Bitcoin wallet, and I'm trying to spend a Taproot output via a script spend path, but I keep running into this "Invalid Schnorr signature" error from my RPC node:
{
    "result": null,
    "error": {
        "code": -26,
        "message": "non-mandatory-script-verify-flag (Invalid Schnorr signature)"
    },
    "id": null
}

The Taproot script I'm trying to spend is fairly straight-forward. It looks something like:
OP_PUSHBYTES_32 f24c112b21c9712042a0ba081261b2f447ac8e927230665417d0929a243e8fda
OP_CHECKSIG
OP_0
OP_IF
OP_PUSHBYTES_3 ...
OP_PUSHBYTES_1 ...
OP_PUSHBYTES_24 ...
OP_0
OP_PUSHBYTES_54 ...
OP_ENDIF

I've triple checked that the private key I'm using to sign with is associated with the public key f24c112b21c9712042a0ba081261b2f447ac8e927230665417d0929a243e8fda. I've also looked at Bitcoin Core and see that its failing the Schnorr verification, but the Schnorr verification passes locally. (I use scure/btc-signer for signing).
I'm not sure what additional information I can provide that would help debug. I can provide the commit tx id that creates the script spend output:
f3bab70b18ed3bef960d7df2a7b35839077c764c8d7791ffa8f8ec6c06d28102

whose transaction hex looks like:
020000000001012a1187fd23fa30932ec9dba59ec0e8d9032c6820d4bd20c860eb1c5c4c0545fc0100000000fdffffff0274670000000000002251201b09ce3a37ee16dbcb0a8dbf262a362996254af51d69a47379de9f3548d719a9bb030100000000002251208dace6f04076ca1ea4eb168dcdad6ad61f695ca1c16a3df6b9586cdca1c71db80140c16f410d7f98dc3ba17991ce61e5329350ae98e68dd8d3994afb6e44076e5c6c28185fd1934a0ff2d345dc755fb27aaa6a4b55381d29482b910941e46cb1a9dc00000000

And the reveal transaction hex that I'm trying to broadcast that is rejected with the "Invalid Schnorr signature" looks like:
02000000000102927d72fed0a50c351f0cd7c0d3a35714835ca6f133b8a4b311f9eb830d418f0a0100000000fdffffff65fb61cb2ecfad91c1c681b99dafcb221d6cb4fe577c8f60b67f069e9edaeebc0000000000fdffffff0274670000000000002251201c573b23ee8b7661095cad641f1f898d126794fc25cfbf61c8d9cbcaf529fd32a1a60100000000002251208dace6f04076ca1ea4eb168dcdad6ad61f695ca1c16a3df6b9586cdca1c71db80140b722450ec2fcb97dcd64f288b1b880d3a87bb72bb40563ddb3f7bad2a7267f694f2a427df52a91996c518d90848849cce6b204df71ee9c1126939ad57d35eb630140d4bbdf0a1ae79a96a90c48d34816ef29e69220faa292da04b682c7c9cc962184337cce55ea745cdc105744c0b8cfa5999551ca68623193136b247d524c615ca500000000

Any thoughts or help would be immensely appreciated. Thank you in advance!

Your transaction is a key path spend, not a script path spend (it only has one witness item, the signature). Perhaps you've calculated the sighash for a script path spend but then only included the signature in the witness stack, you also need to include the script and the control block.


text:
Proving the address belongs to a shared wallet where one can control some deposits and withdrawals
A bitcoin exchange is using a shared web wallet where its users deposits and withdraw bitcoins. The withdrawal transactions are merged, so that the pending transactions of several users are grouped together to save tx fees. The shared wallet is backed by a normal bitcoind installation.
Let's imagine we want to confirm that particular address X belongs to the shared wallet. The address X has received Bitcoins and then some of those Bitcoins have been withdrew through other unrelated transactions.
Because we are the users of the same shared web wallet, we can send in and out Bitcoins from this shared wallet and we gain knowledge of some receiving and change addresses and transactions related to the shared wallet.
Thus, is it possible to

To prove address X belongs to the shared wallet by analyzing the other transactions we know to belong to this shared wallet
Are there any tools or scripts to do this kind of blockchain analysis yet

If I correctly understand what you are tying to do (I'm not sure!) then the usual way to approach this would be to move all deposits to common addresses which are used to process withdrawals. That way you are combining all coins and processing withdrawals all together using the combined coins (perhaps taking advantage of coin maturity too). You would then keep your own database of deposits/withdrawals to keep track. I'll post this as an answer if I have understood you correctly.

You mean like actually proove that an address/addresses belongs to an instance on the servers where bitcoind is running? The only way to prove that is capture unecnrytped traffic from these servers but if you can do that then you have more access to do other things. the same address can be synchronised across multiple instances so, no, there is no way to analyse that kind of data from the blockchain.

@George: No, this is being done as a third party and not being the service owner.

@ppumkin: I was more thinking of this: you know receiving address and change addresses of the shared wallet when you do transactions there yourself. Then you run through blockchain and find other transactions which have been using the same addresses.

Yes, clever, very clever. If the guy who implemented the "security" didn't divide bitcoind into separate servers, then yes, potentially you can start to find out allot about what's happening on that node. At least these transactions should be distributed between allot of wallets locally, there is a way to transact with 0 fees locally for security reasons like this.


text:
BlockChain.info testnet wallet and API
Does blockchain.info provide wallets and API service for testnet? This information is quite hard to find from their site.

possible duplicate of Is there a blockchain.info for testnet?

Not a duplicate: I am not looking for an testnet explorer, but wallet service with API

Testnet ewallet, also these guys have an API for both mainnet and testnet

It may be a bit late, but for others coming to this question, Blocktrail have a data and wallet API that supports both Bitcoin mainnet and testnet.
The API provides HD wallets with multi-signature transactions (allowing for full control over your coins should anything ever happen to Blocktrail), and there are currently SDKs for PHP, NodeJS and Python, with more coming soon.
There are also simple examples included in the SDKs to help you get started, a comprehensive API documentation, and a couple of working example projects:
 1. Simple Bitcoin Wallet App
 2. Simple Block Explorer
Disclaimer
I am currently one of the core developers for this API

Blocktrail is pretty much useless. It requires a complex MD5-hash/signature. Thanks but ... no thanks! Did you forget https provides integrity?

not a big fan of how u need an API key: not needed for calls to the blockchain.info API(which doesn't cover the testnet).

If you want to know all steps from create a wallet to broadcast a transaction in test net you can use of my step by step tutorial about this:
step-by-step-create-and-broadcast-a-bitcoin-transaction-on-testnet

Link only answers are generally discouraged on StackExchange sites. Please include the main points of the answer in the answer text as well.

authors: Игорь Саматов


text:
Single address wallets - no change addresses
Is it legal for Bitcoin transaction to spend output back to one of the input addresses? Namely, to create a single address wallet (paper wallet), so that change addresses do not need to be generated.
Looks like all popular wallets create change addresses for privacy reasons, but I'd like to know if this is also a limitation of protocol. Also asking this question separately from deterministic address generation.


text:
Energy backed cryptocurrency?
Would it be possible to create energy backed cryptocurrency?
There are some earlier theories of creating energy backed money. However the instant challenges I see are

Energy (as an electricity) is globally not transferable, storeable, and must be consumed immediately. It would only work if buyer and seller are connected to the same grid.
The value of energy varies highly depending on the location. E.g. 1 kWh in Africa is much more worth than 1 kWh in New York. The problem of unified exchange rate, e.g. like with gold, would make it very hard to the medium for exchange of value.

Thus, energy backed money may not work in a sense that "1 kWh = 1 coin", because energy lacks the properties to become a transfer of value? But are there other aspects one could use cryptocurrency to bind it to the value of energy?

Well, in a certain sense, electricity can be stored, if you're generating it via coal, natural gas, hydro, or nuclear power plants. (You store it by not generating it in the first place.)
You could define a unit of currency as being a note issued by a power company saying, "IOU one megajoule." Cross region commerce would be handled by finding a middleman to exchange, for example, an Xcel IOU for a GDF Suez IOU.
There would be some problems with this approach. First, Bitcoin has a reliability of 99% to 99.99%, depending on how you define it. That's not reliable enough in a lot of contexts. For example, imagine if a hospital was unable to buy power for an hour each year.
Second, the exchange rates between the various IOUs will change based on speculation and changes in the fuel markets, so what you can buy with your money wouldn't stay stable week-to-week. For example, imagine if you were paid in Delmarva IOU's because you worked for a corporation headquartered in Delaware, but you lived somewhere where you needed to pay your bills in Xcel IOU's.
Theoretically, you could do this. I'm not sure that you'd want to, though.


text:
Meaning of confirmation within n blocks?
I have a hard time understanding the meaning of below sentence:
"To confirm within 48 blocks, a transaction fee of 1 satoshi/byte is required."
I have 2 questions here:
1) Does this mean that the first confirmation of the transaction will probably happen within attachment of the next 48 blocks?
2) As soon as the first confirmation is received, is it guaranteed that this confirmation will increment with all future block attachment (which is every 10 mins)?

Not sure where you are quoting that statement from. Seems to be a promise on something that is probabilistic.
1.) From that statement yes the first confirmation with happen within 48 blocks.
In practice, it depends on the current mempool size (how many transactions are waiting to be confirmed) and the transaction fee (miners are incentivised to choose the transactions with the highest fee) relative to the other transactions in the mempool. I would not go as far as to say with fee of x you will receive a confirmation in y time because at the time of adding the transaction to the mempool you might see that your transaction should be in the mempool (due to your fee) but every 10 minutes there are a block load of new transaction that are added to the mempool with higher fees.
2.) Yes, after the first confirmation the next confirmations will tick at an average of 10 minutes each (slight correction from your statement, not every 10 minutes but rather 10 minutes on average).
To elaborate, if there is x hash power in the network AND the network sets the difficulty to find a block then probability dictates 1 block every 10 minutes. However, if there is additional computing power that joins the next then the time (on average) to find the next block will be <10 minutes... at least until the network readjusts the mining difficulty.


text:
One Code, Two Different Compilations (One Dirty Version of BitCoin)
Right now i'm developing an AltCoin based on BitCoin Cash.
I have one code, which i compiled in two different servers (A and B).
The A server, compiles the Bitcoin as "Bitcoin ABC version v0.16.3.0--g2vdf00a68", but the B server compiles the Bitcoin as "Bitcoin ABC version v0.16.3.0--dirty".

Right now the nodes are visible as peers, between the servers.
But the mining has been impossible.
I think it may be related with the difference between versions, on the compilation of the SAME CODE.
Here it's the compilation output of the dirty version:
https://pastebin.com/P8A2Ydk3

Dirty means that the compiled binary includes code that is not committed in git. You can use the git diff command to see what the uncommitted code is and use git show to see what the  most recent commit is for each of your code trees. There's a good chance that what you think is the same code is not actually the same code.


text:
What if two public keys have the same hash？
What if two public keys have the same hash? Although the chance is very very small, I am still interested in what would happen.
Suppose that Alice makes a transaction to Bob using Pay To Public Key Hash (P2PKH) style signature script.
But Carmen has another public key, and the hash of Carmen's public key and Bob's are the same.
When Carmen turns on the Bitcoin wallet software, is there any extra balance?
Can Carmen spend the balance?

In your scenario, Carmen can simply see and spend the money as if it was theirs.
The network does not have any way of distinguishing this event.

Spending a P2PKH script has the following conditions:

The public key must hash to the expected hash
The signature must be valid when verified with that public key.

So yes, Carmen would see extra balance and would be able to spend it.
However, that's really impractical


text:
What would happened if two transactions have the same hash?
What would happened if two transactions have the same hash?
Would it make the Unspent Transaction Outputs(UTXO) in the old transaction not spendable?
I think it would make the outputs in the new transaction spendable and the outputs in the old transaction not spendable.

As eponymous's comment:"All blocks after 2012 contain the height in the block's coinbase transaction". It is difficult to create a new coinbase transaction with duplicate hashes because the height is included in the coinbase transaction.

Also read:Can the outputs of transactions with duplicate hashes be spent? and Two blocks, two transactions, same hash

Per BIP 30, transactions are not allowed to have the same TXID as another transaction which has unspent outputs.
This means that there can be transactions that have the same TXID, but only after the first transaction's outputs are already spent. So in this case, the duplicate TXID does not matter.
For transactions that do have duplicated TXIDs (there are a few of them), only the most recent of those transactions can have its outputs spent. The earlier transactions with the same TXID cannot be spent from and their Bitcoin are lost forever.

I was about to answer the question, but I was not sure about some details. Does that means that if the old transaction has unspent outputs, all will be evicted from the UTXO set, and the new ones will be included?

Moreover, will that getrawtransaction will return more than one result?

No, the new transaction will be rejected entirely for having a duplicate txid. There are just special cases for the few duplicate txid transactions that occurred before BIP 30's introduction.

getrawtransaction will return the same thing because the duplicate txid transactions are literally the same transaction (everything about them is the same except for the block that they are a part of). it will only return data for the most recent of the duplicates.

Note that disckjet's examples predate BIP30's activation. In the current consensus rules, such a duplicate txid wouldn't be permitted anymore. Also note that it isn't a case of an actual collision; just the same transaction issued twice.


text:
How can I get my LND node to make connections over Tor, IPv4, and IPv6?
I followed this guide (https://github.com/lightningnetwork/lnd/blob/master/docs/configuring_tor.md) to setup Tor on my LND node, but this forced all my traffic through Tor, and I was no longer reachable over Clearnet. I've looked through some issues on the LND github page, and it seems there is a way to have my node listen over Tor, IPv4, and IPv6, but I'm not sure how to set it up that way. Also, they mentioned there are risks to doing this, what are those risks? I don't mind if people can correlate my IP address to my onion address (I'm just running servers in the cloud anyway). I just want to be able to connect and route payments with Tor nodes and clearnet nodes. How can I get my LND node to make connections over Tor, IPv4, and IPv6? What configuration options must I set?

The guide you linked is a good start.
The next step is to broadcast these IPs using the externalip flag in the lnd.conf file. A sample lnd.conf file that enables connections (using default port 9735) via Tor, IPv4, and IPv6 should include the following:
(replace the 3 fake addresses with your own):
tor.active=1
tor.v3=1
tor.privatekeypath=~/.lnd/v3_onion_private_key
externalip=32.260.201.72
externalip=2001:0db8:85a3:0000:0000:8a2e:0370:7334
externalip=rvaslfkj2blahblahbalhdfsfjdflxcmnvxcvxvkfdsxcvxcvxcv.onion

How do you get the onion externalip? do you first run it with tor.active and check the logs for the address? Stop it and add it back to the config? Or is there an easier way?

the risk is, Port 8333 is open and stays open.
Its like an open Backdoor.
A Bad gguy could just check all nodes wich he can see on the earn.com Page ( and there are ALL Nodes listed) how secure their Network is.
I say, secure your home network with a strong password, do not allow guest entry and if you dont use your home network simply switch it of, dont set Folder or Files free in your network, especially sensitive ones.
And dont backup your Wallet on the same PC as you run your node from, never ever.

thanks but this does not answer my question. i'm running my LND node on a cloud server, not my home network. i will edit the question so its more clear


text:
Claiming liquid peg-in: „The txoutproof must contain bitcoinTx and only bitcoinTX“
I‘m trying to do a liquid pegin. Generated the pegin address and sent funds to it, waited < 102 blocks. When trying to claim them with
liquid-cli claimpegin “rawtransaction“ “txoutproof“

The result is
    Error code: -8
Error message: The txoutproof must contain bitcoinTx and only bitcoinTX

The txoutproof looks longer than in the example of bitcoin-cli help page and was done on a -txindex enabled full node gettxoutproof “[\“txid\“]“
00008020f2e6bcdb...

I‘m thankful for any clues what could be wrong. Am I doing something wrong with the claimpegin input parameter format?
Thanks in advance and kind regards.

This is really a service question.

The proof length is variable in size based on the number of transactions in the block it is a proof for, so that isn’t unusual.

The raw transaction and txoutproof didn‘t match due to a copy/paste error.


text:
Identifying change addresses by locktime?
I know that Blocksci is no longer being actively developed but I was reading through some of the documentation about identifying change addresses and came across this:
change.locktime = <blocksci.heuristics.change.ChangeHeuristic object>

    Bitcoin Core sets the locktime to the current block height to prevent fee sniping.
    If an output has been spent and it matches this transaction’s locktime behavior, it is
    possibly the change output. (This heuristic will return unspent outputs as potential
    candidates.)

source: https://citp.github.io/BlockSci/reference/heuristics/change.html#blocksci.heuristics.change.power_of_ten_value
My understanding is that locktime is usually set to the current block + 1 in order to prevent a fee sniping attack conducted by miners where they remine the current block but with higher fee transactions.
However, I am struggling to understand how Blocksci makes the connection between locktime and whether an output is change. Is it saying that if the transaction locktime is say 100,000 and one particular output also has a locktime of 100,000 then it may be the change output? But why? If I have a change output I might not necessarily want to spend it straight away so why would the locktime be the same as for the initial transaction?

The locktime field is on the transaction, not on a specific output.

I assume that the Blocksci documentation is referring to Check Lock Time Verify (CLTV) which is a per output time lock. Or are they referring to the locktime of the transaction and then the locktime of the next transaction that spends the output in question.

At least the quoted code comment appears to be referring to Bitcoin Core’s anti-fee sniping behavior which makes use of the locktime field on the transaction.

Looking only at what you quote and describe, it seems to me that BlockSci is inspecting the locktime field of transactions.
They appear to be inferring that an output may be a change output, if both the transaction that created an output and the transaction that spent the output use anti-fee sniping. This seems somewhat silly to me, since anti-fee sniping is implemented by more than one wallet and this would also count e.g. if a user sends from Bitcoin Core to Electrum or if one Bitcoin Core user sent to another.
In a way, this is a primitive form of trying to recognize the wallet type and use that for change detection. There are however much stronger indicators for change outputs on Bitcoin Core.

Given the rest of the heuristics they use are more sensible, this heuristic seems as you put it "silly". Is there any other interpretation you can think of regarding the "output has been spent and it matches this transaction’s locktime behavior"? Because if it is like you suggest, even relatively unreliable heuristics like "the change address is always the last output" seem more sensible.

Well, in combination with the other outputs having different behavior that would work, but just by itself it’s a bit thin. There is a bunch of heuristics to describe change outputs here: https://en.bitcoin.it/wiki/Privacy#Change_address_detection, the anti-fee sniping behavior would be an example for wallet fingerprinting.

I see, so it is saying that if my wallet implements anit-fee sniping but yours does not, then the output that is in future involved in a transaction that has anti-fee sniping must be from my wallet (therefore change). But if we both implement anit-fee sniping then this heuristic fails, right?


text:
Wasabi coinjoin and the "Chainalysis demixing"
Learning more about how coinjoin works I came across the tale of how Chainalysis "demixed" a 50 BTC transaction that went through Wasabi (TXID aa8d7407f88dca9b1779880c3d2e3245e02217f7366972d617f812c8dd73a96a). If we ignore all of Chainalysis's PR about being able to crack Wasabi and look at how it actually happened it appears that it was due to address re-use (addresses bc1qxp8k4un9tzkm2phsvs22r26l6l2ny93tnts7nq and bc1qq2cp2swuhkd9serh5h4vhnn00l89e2wjfwyarr) by Wasabi which in turn lead to the identification of a cluster.
Was this just a case of bad practice/a bug in the code on Wasabi's part? Or is there something more to this?
I realise the user did some less than sensible things in the big picture, but I'm more wanting to focus on the technical side in relation to Wasabi.


text:
confirm bitcoin node on bitnodes.io
The Bitcoin Core 25 App has just finished syncing 100% on the Umbrel node. Within the App I confirm seeing new Bitcoin blocks arrive. Not sure why bitnodes.io shows the following message:
{IP Address} is unreachable.
Additional info:

Connected to Nord VPN service at my home router
Ports 8333 are open at my home router
Port forwarding is enabled for 8333

Nord VPN does not support port forwarding: https://support.nordvpn.com/FAQ/1047408432/Do-you-offer-port-forwarding.htm

Besides bitnodes is there another service that can help confirm a functioning node outside of the Umbrel Bitcoin app?


text:
Do we need a taproot commit for multisignatures if there is no script path, but we are using the MuSig2 protocol?
I read in some article for Taproot that if there is no need for a script path spending and a number of participant (multisignature with key aggregation) create together a taproot output key (key for a segWit 1 witness program), the key shouldn't just be the sum of their public keys (A+B+C+D). Reason comes from the fact that some participant (either A, B, C or D) can create a "hidden" script that can later be used to steal coins through script path without knowledge of other participant. So when the taproot output key is the sum of public keys, then it is necessary to also tweak that key with "something" additional. However, what if we use MuSig2 protocol (and its key aggregation) instead of just basic sum of the public keys?
Is there any need for addition key tweaking if we use MuSig2 protocol for multisignature?

Is there any need for addition key tweaking if we use MuSig2 protocol for multisignature?

Citing BIP341:

Why should the output key always have a taproot commitment, even if there is no script path?
If the taproot output key is an aggregate of keys, there is the possibility for a malicious party to add a script path without being noticed by the other parties. This allows to bypass the multiparty policy and to steal the coin. MuSig key aggregation does not have this issue because it already causes the internal key to be randomized. The attack works as follows: Assume Alice and Mallory want to aggregate their keys into a taproot output key without a script path. In order to prevent key cancellation and related attacks they use MSDL-pop instead of MuSig. The MSDL-pop protocol requires all parties to provide a proof of possession of their corresponding secret key and the aggregated key is just the sum of the individual keys. After Mallory receives Alice's key A, Mallory creates M = M0 + int(t)G where M0 is Mallory's original key and t allows a script path spend with internal key P = A + M0 and a script that only contains Mallory's key. Mallory sends a proof of possession of M to Alice and both parties compute output key Q = A + M = P + int(t)G. Alice will not be able to notice the script path, but Mallory can unilaterally spend any coin with output key Q.

(emphasis mine)
BIP341 recommends always tweaking, even without a script path, because it is the conservative option. Explaining, or even just reasoning about when it is or isn't okay not to tweak is complicated when multiple protocols are in use, so it is just a safe default. In the case of just MuSig2 as internal key, I am relatively confident there is no means of attacking that. My recommendation is still to always tweak.


text:
Can the hash of UTXO set be part of the bitcoin block header and consensus rules and in which cases?
This question doesn't have much logic in "reality", it's more theoretical about whether something can or cannot be part of consensus rules and in which cases.
I know that the consensus rule can only be something that all nodes see the same way. In other words, at all points in time all nodes must come to the same conclusion about some chain (whether its valid or invalid).
I wonder if the hash of some set of UTXOs can be part of the header and consensus rule? I have two questions related to it:

Can we set as a consensus rule that some hash from the header block must be equal to the hash of strictly node's current UTXO set?
Can we set as a consensus rule that some hash from the header block must be equal to the hash of UTXO set that exists in current point in chain (the set of unspent outputs that currently exists in the chain from the previous block to genesis)?
Can we set as a consensus rule that some hash from the header block must be equal to the hash of some UTXO set (does not need to be nodes current UTXO set (case 1) nor UTXO set that exist in current point of chain (case 2))? I literally mean some "random" set of UTXOs that we would get, for example, within a block (like we get transactions) or not even within a block but some that we must find then by ourselves.

Since the content of the block is already selected by the time the block header is constructed, yes, theoretically a cryptocurrency could commit to the UTXO set in its block header. For Bitcoin, it would be more realistic to put such a commitment in an output on the coinbase transaction where it would not require a hardfork. As long as there are clear rules how to create and validate such a commitment, this commitment could also just cover a subset of the UTXOs, although I don’t see an advantage to committing to less than the whole UTXO set.


text:
What is fee sniping?
What is a fee sniping attack? In several places I came across a mention of this type of attack, however, it is not clear to me what it represents.
They also say that today it is not so common and profitable, but that it can become when the reward from the collected fees starts to be greater than the reward for the mined block.

Fee sniping refers to the process of re-mining the last block in the chain to claim the fees of both the transactions mined in this block and the new transactions that came in since it was mined.
In an environment with low or no block subsidy and high fees it might be more profitable for a miner to re-mine the last block rather than to mine a new block on top.
Most wallets nowadays create transactions with the nLockTime field set to the next block. This is such as the transaction can only be mined in the next block: it's only available to a miner mining on top of the last block. In a low-subsidy and high-fee environment this means a fee sniping miner would have to give up on a large share of revenue, making this strategy much less attractive (if it ever was in the first place).
Side note: BIP326 suggests using the transaction input's nSequence field instead of nLockTime to achieve the same in Taproot transaction.


text:
Why do we have "circular behavior" when working with EC over finite field and what makes some point a "turning point"?
Thank you all very much in advance!
I will explain best with an example what is not clear to me.
Consider the elliptic curve a = 1, b = 2, p = 11 of order 16.

Also let's consider the "opposite" (negations of each other) two points of this elliptic curve (2, 1) and (2, 10) = (2, -1) as starting points. These are the points for which we will do the multiplication.
For both of these two points, the order is 8 (we can only get 8 out of 16 points if we multiply them). I took this example arbitrarily just to make it as small as possible.
By multiplying (2, 1) we get the following points (next to the points are numbers that indicate the number by which (2, 1) must be multiplied to get it):

By multiplying (2, -1) we get the following points (next to the points are numbers that indicate the number by which (2, -1) must be multiplied to get it):

Until multiplying by 4 (in both cases) everything is as I expect. Multiplication just gives opposite points (the negation of each other) since we are working with the opposite points. For example, 2 * (2, 1) gives (8, 4) and 2 * (2, -1) gives (8, -4) = (8, 7) since it is the opposite (negation) of (8, 4). Same for multiplying by 3. This works literally the same as in case of working with an elliptic curve over real numbers. So everything is clear.
However, what confuses me is that after multiplying with 4 we're starting to sort of go backwards.
For example, multiplying (2, 1) by 5, we get (5, 2), which is also the 3rd point when multiplying (2, -1) (that is, 3 * (2, -1) = (5, 2)). This also applies in the opposite way. Multiplying (2, -1) by 5, we get (5, -2), which is also 3rd point when multiplying by (2, 1).
It turns out that we are actually going backwards, which is different from the case when we work with the real numbers where we would just keep going by the principle before multiplying by 4 forever, so that there would be no such "repetition" of points
Also, it looks like multiplying by 4, i.e. the point (10, 0) actually represents that TURNING POINT. Better said, up to that point everything goes like with real numbers, however, from there, we start going backwards.
So it goes as expected until some points. After that points, it starts to go backwards until we reach the beginning, that is, (2, 1)/(2, -1) point in our example. In other words, until we make the whole circle, when everything starts from the beginning.

Why is this happening? Why do we have this circular behavior?
What must be specific about a point (in this example (10, 0)) for it to be a turning point? I thought that, in this example, 4 * (2, 1) and 4 * (2, -1) must give the same lambda for the point to be a turning point (since that's the only difference between working on a finite field and on real numbers), but that's not the case , that is, the same lambda is not obtained.

This elliptic curve is not a cyclic group, meaning it's not possible to write every point on it as some multiple of a generator. Things will work much more naturally when you do use a cyclic group (like a=1 b=3, over the same field), and even better when using a prime-ordered group (like a=1 b=5, over the same field). This explains why you're not reaching all points on the curve, though isn't really an answer to your question. I suggest retrying with a=1 b=5 and see if the result is still unexpected to you. However, I suspect there will not be much more to say than "it just is".

In this case, the order of the point you started with is 8 (as there are only 8 points reachable as multiples of your starting point). Multiplying with 3 and multiplying by 5 is not the same thing; they're each others negation. So you observe that 3G = -(5G). That is entirely expected, as 3 = -5 mod 8, so 3*G = (-5)G = -(5G). On a prime-ordered curve this will be modulo the curve order (as on such curves the order of every non-infinite element is equal to the curve order).

Perhaps the answer to your question is just that once you're past half the starting point's order, you'll start to see the same X coordinates (but opposite Y coordinates), as you're effectively going through their negations ([1,2,3,4,5,6,7] mod 8 = [1,2,3,4,-3,-2,-1] mod 8). This is true for every cyclic group (not just elliptic curve groups). Even though the curve itself isn't cyclic in this case, the subgroup generated by the multiples of your starting point are.

In case the point order is even (as is the case here), it holds that 4 = -4 mod 8, so 4G = -4G. Thus, in such groups, it must hold that the halfway point (starting point times half its order) is its own negation. That implies its Y coordinate must be 0, as (X,Y) = (X,-Y) implies Y=-Y, or Y=0. And you can indeed see that is the case here!

@PieterWuille I think I did not explain (asked) it well. I do not want to reach all 16 points. 8 points was enough for me to show what's confusing me (even though it looks like I did not show it well). What confuses me is that after some point (in the example (10, 0)) we are starting to get points that we already got by multiplying the opposite one. For example, 2*(2,1) = (8,4); 3*(2,1) = (4,9); 4*(10,0); 2*(2,-1) = (8,7); 3*(2,-1) = (4,2); 4*(2,-1) = (10, 0). So, I am getting the opposite points (as expected).

After multiplying with 4, I will still get the the opposite points, but not some "random" points (not like in case of multiplying before 4), but the same points as its opposite has before multiplying with 4 in that direction. For example, 5*(2,1) won't be some (randomX, randomY), but the 3rd point for (2, -1) and that's (4,2). Also, 5*(2,-1) won't be some (opposite_to_randomX, opposite_to_randomY), but the 3rd point for (2, 1) and that's (4,9). So I am still getting the opposite points, but it looks like it goes backward.

I noticed the rule that the sum of the points (in the context of order/ point ordinal) must be equal to the order of point G. In the example 1+7 = 8, 2+6 = 8... 4+3 = 8.. . Where the first number in the equation represents the ordinal number of the point obtained when multiplied by the positive version of G, and the second represents the ordinal number of the point obtained when multiplied by the negative version of G.

@PieterWuille If we were working with real numbers, this would not be the case. In the same way (like multiplying before 4 in the example) we would go to "infinity". By multiplying G and multiplying -G, we would always get mutually negative numbers, but we would never have this repetition of points, i.e. going backward like this.

I think I gave the explanation above: [1,2,3,4,5,6,7] mod 8 = [1,2,3,4,-3,-2,-1] mod 8. So multiply by G and you get [1G, 2G, 3G, 4G, 5G, 6G, 7G] = [1G, 2G, 3G, 4G, -3G, -2G, -1G]. This is a general property of any cyclic group, including the one formed by multiples of G. If considered over the real numbers the result doesn't have a finite order, so there is no "hapfway point" ever. As for why elliptic curves over finite fields form cyclic groups... I suggest taking a algebraic geometry course or so.

@PieterWuille Actually, you did. The problem was that it did not load all the comments (I did not refresh the page) before I post my comments. Just what does create in this case (EC over finite field) a cyclic group, since elliptic curve over R does not create cyclic group and only difference is that in calculating lambda we are using mod inverse?

I do not think I can explain that. Actually it's a cyclic group too over R, just one with infinite order, so there is no halfway point.

@PieterWuille Okay, thanks anyway.

@PieterWuille Just one question. You wrote above Perhaps the answer to your question is just that once you're past half the starting point's order, you'll start to see the same X coordinates (but opposite Y coordinates), as you're effectively going through their negations ([1,2,3,4,5,6,7] mod 8 = [1,2,3,4,-3,-2,-1] mod 8). I have understood everything expect why are we going through their negations after half, that is why do we go -3,-2,-1 and not 5 6 7 8?

You do both. 5 equals -3, 6 equals -2, 7 equals -1, when operating modulo 8 (as happens in a cyclic group of order 8). If you'd actually compute say 45G you'll end up with the same point as 5G or -3*G, because modulo 8, all these numbers are the same.

The points on an elliptic curve, combined with the point at infinity, and the point addition operation, define a group. I consider explaining why that is outside of the scope of this site, but it follows from a number of properies this set and operation has, such as associativity and every element having a negation.
The subset of a group of elements obtained by repeatedly adding a specific element (called the generator) to itself, also forms a group. This group is always cyclic (meaning that every element can be written as a multiple of some specific element - this is obviously true if the group itself is the subset of elements generated that way).
It is a standard result in group theory that every cyclic group is either infinite (in which case it behaves like addition over the integers) or finite (in which case it behaves like additions over the intergers modulo the size of the group).
Since we're working over a finite field, there can only be a finite number of elements our group has. Thus, inevitably, the group obtained by repeatedly adding a particular curve point to itself must be a finite cyclic group. In your example, the one of order 8. If we'd be working over the reals instead, then depending on the starting point it could be an infinite cyclic group too (but not necessarily; e.g. (1,2) on y2 = x3 + x + 2 over the reals defines a cyclic group of order 4, consisting of [(1,2), (-1,0), (1,-2), infinity]).
Since our group is a finite cyclic group of order 8, it must behave identical to the integers modulo 8. In other words, 5G is the same as (-3)G, which is -(3G), which is the negation of 3G, which has the same X coordinate as 3G. This holds for all points, so [1G, 2G, 3G, 4G, 5G, 6G, 7G, 8G] = [1G, 2G, 3G, 4G, -3G, -2G, -1G, 0G]. But it's also equal to [-7G, -6G, -5G, -4G, -3G, -2G, -1G, 0G], or anything else that is equal modulo 8. You can say that it "reverses" after 4G, but all that's happening is that 5G and -3G necessarily have the same X coordinate.
Overall, the bottom line is that when working over a finite cyclic group, as this must be, the second half of group elements obtained are the same as the first half, but negated and in reverse order.

Literally everything is clear to me. I understand (and know from earlier) the concepts of groups, cyclic subgroups etc. I also understand that in context of integers mod n (let's say 8), for example: ... -3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, it would correspond to the ... 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4 ... and it is cyclic group since it repeats. In context of EC I also understand it all if we look at things in the following way.

If we consider that this: ... -3*(2,1), -2*(2,1), -1*(2,1), 0*(2,1), 1*(2,1), 2*(2,1), 3*(2,1), 4*(2,1), 5*(2,1), 6*(2,1), 7*(2,1), 8*(2,1), 9*(2,1), 10*(2,1), 11*(2,1) ... is equal to this (which it is): ... 5*(2,1), 6*(2,1), 7*(2,1), 0*(2,1), 1*(2,1), 2*(2,1), 3*(2,1), 4*(2,1), 5*(2,1), 6*(2,1), 7*(2,1), 0*(2,1), 1*(2,1), 2*(2,1), 3*(2,1) .... Thus, again cyclic group. However, what confuses me is that -a*G is also a*(Gx, -Gy), so -3*(2, 1) is not just 5*(2, 1) but also 3*(2, -1). Therefore, we are working (in some way) with a completely different point and that confuses me.

I hope I have now explained what is confusing me. It seems completely ridiculous, but for some reason I can't understand it, even though it all seems completely logical... I don't know how to get it over my head.

-a*(Gx, Gy) = a*-(Gx, Gy) = a*(Gx, -Gy). This all follows from the fact that negating a point is multiplying the point with -1.

Yes, I know that too. However, the negation of integers means that you literally just add - (more accurate to say multiply with -1), so 5 is negated -5, i.e. according to mod8 it is 3. What confuses me is that in the context of integers -3mod8 represents literally 5, while in EC it can be -3* (2, 1) = 5*(2, 1) as with integers, but it can also be 3*(2, -1). So, we literally work with different point, multiplying it 3 times (instead of 5) and get the same thing. I just can't figure it out for some reason. I'm not sure how much you can help me at all, but anyway thanks for the effort :)

If you have another "crazy" way for me to get it, I would appreciate it, otherwise, it doesn't matter, thanks for this too :)

-3 * P = (3 * -1) * P = 3 * -1 * P = 3 * (-1 * P) = 3 * (-P). Multiplying P by -3 is the same as multiplying the negation of P (which means negating its Y coordinate) with 3.

Just to let you know that I finally got it


text:
What is the lowest possible value for target?
Similar question was asked here but the answer doesn't really provide an answer.

This answer says that the lowest possible value for target is "all zeros plus a one". Pieter Wuille in the comment denied it and  wrote that the target can even be 0.
However, can it be 0 given the way the target is encoded in nBits? Since the smallest legal value for the lower 24 bits is 0x008000 and if we take into account that the minimal exponent is only 3, it look like the lowest possible value for target is 0x008000, that is for nBits 0x03008000.
Therefore, what is the lowest possible target value, ie for nBits?

However, can it be 0 given the way the target is encoded in nBits?

Yes. The encoding in nBits for target 0 is 0x00000000.

Since the smallest legal value for the lower 24 bits is 0x008000 and if we take into account that the minimal exponent is only 3, it look like the lowest possible value for target is 0x008000, that is for nBits 0x03008000.

The rule about the mantissa needing to be at least 0x008000 only applies when the value is nonzero. It's there to make sure numbers have a unique encoding, but as this example point out, it would preclude encoding 0 if applied the same way for it.
So, the values are:

0x00000000 (0),
0x01010000 (1),
0x01020000 ... 0x017F0000 (2 - 127)
0x02008000 (128)
0x02008100 (129)
0x02008200 ... 0x027FFF00 (130 - 32767)
0x03008000 (32768) and so on...

I thought that the smallest possible value for the exponent is 0x03. What is then the correct nBits for the number 500 (in base 256 = 01F4) or the number 154 (in base 256 = 9A)? 0x020001F4 and 0x0100009A?

Shouldn't base 256 have 256 possible distinct symbols for each digit?

The encoding for 500 would be 0x0201F400 and the encoding of 154 would be 0x02009A00. The encoding of the number 5 would be 0x01050000. I realized I made a mistake in my answer above; the mantissa will actually always be between 0x008000 and 0x7FFFFF inclusive, except when encoding 0. I've amended my answer.

@RedGrittyBrick Indeed. In the encoding of 500 (0x0201F400), the exponent is the 0x02 up front (shifted by 3, so the actual exponent is -1), and the mantissa is 0x01F400 (ignoring that its top bit is actually a sign bit), whose "digits" are 0x01, 0xF4, and 0x00. So the encoded number is (0x00 + 0xF4 * 256 + 0x01 * 256^2) * 256^(0x02 - 3) = 500.

@PieterWuille Did you make a mistake for 154, isn't it 0x019A0000 instead of 0x02009A00?

No, 0x019A0000 represents -26 (the high bit of the mantissa is the sign).

Thanks, I added some numbers. I think it can be useful. I hope everything is correct in written.


text:
What is the leaf version in Taproot and how is it used?
I asked a few questions within this one. They are all related to the leaf version, so I didn't find it necessary to split them into multiple separate questions as they can all be answered in 1/2 a sentence (at least I assume).
Thanks to all in advance.

What is leaf version?

In BIP341 they say that leaf represents a logical AND between the first byte of the control block and 0xfe.

I quote: "Let v = c[0] & 0xfe and call it the leaf version"

Pieter Wuille said in his answer that only the top 7 bits of the first byte of the control block (11111110) represent leaf version while the first (bottom) bit (00000001) of the same byte is a sign.

I quote: "Its first byte stores the leaf version (#3) (top 7 bits) and the sign bit (#6) (bottom bit)."

In some answers/articles I also read that the leaf version represents entire first byte of the control block.

What is the purpose of leaf version?

As I understand it, it is a way to indicate which type of script is used, i.e. that some special opcodes can be found within that script or that the existing ones have a different meaning, or that the content of that script has some totally new special meaning. Therefore, each leaf (script), has its version that defines the way in which we observe its content (something similar to the witness version in segWit). So, when we use a script from MAST, we must also specify its version in order to know how its content is treated (but also to correctly calculate the complete tree). Am I right?

What is the leaf version value for using the normal (standard) Bitcoin scripts if its even possible to use them inside taproot? (with normal script I mean on scripts used in non-segwit outputs or in P2SH etc.)
What are the all possible values for the leaf version?

BIP341[7] and Pieter Wuille gave some answers, but I still do not understand. I understand why it cannot be 0x50 (so as not to be confused with the annex) and why it can be only even value (because logical AND is done with 11111110), but it is not clear to me why there must be only those values listed there in the BIP341[7]/Pieter Wuille's answer.

By the definition in BIP341, the leaf version is the first byte of the control block, after masking out its bottom bit. It is certainly not the entire first byte.

Yes, exactly.

Currently only one leaf version is defined, namely 0xc0, in BIP342. Using any other leaf version is non-standard, and has no associated semantics (meaning that any spend of it is valid, as long as it's properly revealed as described in BIP341). Thus wallets absolutely shouldn't use any other leaf versions (until more are defined, and their consensus rules deployed).

The leaf version can be any even byte value, except 0x50 (because that would make it conflict with the annex). So it's not illegal for wallets to construct transactions that use any leaf version but 0x50 (but see the previous point why they shouldn't).
It is advisable for future consensus changes to Bitcoin to pick leaf versions from that list in BIP341, because that permits certain kinds of contextless analysis: the ability to recognize what leaf version a transaction input uses without knowing the output. This ability may or may not turn out to be useful, but because adding leaf versions is probably very rare, it's unlikely to be burdensome to stick to this list. This is a suggestion for future protocol changes, but has no bearing on wallet software (before such changes happen).

So the leaf version actually, as you said, represents just the top 7 bits of the first byte within control block since the content of that byte is masked with the 11111110 and by that the first (bottom) bit is not important. 3) Does it mean that we can make some script with the leaf version of, for example, 0xc4, create MAST with such a script and thereby make one of the paths of the three (MAST) as anyone-can-spend?

Right, if someone were to reveal the script path with leaf 0xc4, then the script and script inputs don't matter.

You also mentioned that the other leaf versions are "not-standard". Do you, by saying "non-standard", refer to the rules for "relaying" transactions or in this case "non-standard" has some other context? So transactions with leaf version other than 0xc0 (or sometimes 0xc1 if you look at the entire first byte within control block) won't be relayed, but will be consensus acceptable?

That's correct. BIP341 only controls the consensus rules, and according to those, any leaf version is fine. By the standard relay policy implemented in Bitcoin Core today, only leaf version 0xc0 is relayed.


text:
What happens to the blocks that do not pass the acceptance rules?
One of the acceptance rule for the blocks is that the block timestamp cannot be more than 2 hours in the future. What happens to blocks whose timestamp does not meet this rule, i.e. blocks that generally do not meet the acceptance rules (not consensus rules)? Are they rejected as if they had never been seen?

A block with a timestamp too far in the future is invalid. This seems to be discovered during ProcessNewBlockHeaders when learning about the block header. The node discards the invalid block header.
// Check timestamp
if (block.Time() > now + std::chrono::seconds{MAX_FUTURE_BLOCK_TIME}) {
    return state.Invalid(BlockValidationResult::BLOCK_TIME_FUTURE, "time-too-new", "block timestamp too far in the future");
}

via src/validation.cpp


text:
What was the first original purpose of the nLocktime? Was it only the time bound to nSequence?
Pieter Wuille gave an amazing answer related to the connection between nSequence and nLocktime in the early days of Bitcoin.
However, based on his answer it looks like the nLocktime was NOT really originally intended just for the absolute time lock in sense you cannot include this transaction in the blockchain before the UTC timestamp/block height defined in nLocktime pass.
As I understood, nLocktime was more intended to work together with the nSequence as a time bound in sense how much time we will wait in mempool for the transaction to become final in context of replacing, than to be just absolute time lock. If we want our transaction to immediately become "final" (ready for the blockchain) then we just need to set all nSequence to 0xffffffff. Since there will be no replacement, there is no need to wait for anything, so the nLocktime value is ignored. Also, we can set nLocktime to zero and since we don't wait any time for the replacement, in this case the transaction also becomes immediately "final" regardless of the value of nSequence.
So I would say that the nLocktime is originally intended to be the time in which we will wait for a replacement. However, as we can set the nSequence to, for example, 0xfffffffe and never increase it and set the nLocktime to some time (UTC timestamp/block height), then the nLocktime indirectly becomes, and can be used, as the absolute timelock.
As addition. It doesn't work that way today. This relationship between the nSequence value and the nLocktime value still remained as a consensus rule (would require hard fork to change), so if all nSequences are 0xffffffff, then the nLocktime value is not considered, and otherwise nLocktime can be used as an absolute timelock. However, replacement today has nothing to do with nSequence (it just must be less than 0xffffffff-1 and that is all), nor wait for nLocktime time.
What do you think? What was the first original purpose of the nLocktime? Am I right?

See https://bitcoin.stackexchange.com/q/116706/13866 re Nakamoto email on this subject in 2011

Based on RedGrittyBrick's answer and an email Satoshi sent to  Mike Hearn, it appears that the original purpose of nLocktime was indeed as a time bound for replacement and was not intended to be absolute time lock. Since it was never properly implemented, nLocktime is now used as absolute time lock with any nSequence set to a value less than 0xffffffff.
So I confirm what I wrote in the question.
I thank RedGrittyBrick once again for his help.


text:
What does a digital signature scheme need to have in order to be used (indirectly) in Bitcoin?
Here (see the comments) Pieter Wuille described digital scheme as a collection of three algorithms:
(key generation, signing, verification)
Since Bitcoin uses ECDSA (pre-Taproot outputs) and Schnorr (Taproot outputs) digital schemes, my question is what does some digital scheme must to have, that is what is the requirement, to be used indirectly in Bitcoin? When I say indirectly, I mean that it does not replace existing schemes (that would require a hard fork or a new segwit version), but is used to create signatures and keys (in order to multi-party signature or something more advanced). Is the requirement just to have the same verification algorithm, i.e. to ensure that the signature and public key match when the network would use normal ECDSA/Schnorr to verify the validity of the transaction and that's it, or something more?

At a technical level, all that matters is the verification equation. If your scheme ends up with keys and signatures on-chain that verify using ECDSA (or BIP340 for Taproot outputs), the transaction is valid. The consensus rules don't know or care how you ended up with that signature.
And perhaps more generally, Bitcoin Script supports more things than just signatures. You can create a transaction output that can be spent without signature at all. Of course, this would be insecure, but nothing prevents you from using this.
So just because any scheme that results in scripts that execute successfully is in theory usable, doesn't mean any of those should be used. What should be used is a much harder question, because it involves concerns like security, practicality (e.g. 2P-ECDSA for ECDSA multisignatures exist, but is fairly complicated), features (e.g. thresholds and multisignatures, ...), standardization/implementation status (just because someone wrote a paper about a particular scheme doesn't mean there is a usable implementation with sufficient review, ...).

So, Bitcoin and its consensus only involve the verification algorithm from the (key generation, sing, verification) digital signature scheme (specifically the verification algorithm for ECDSA and Schnorr)? Algorithms for key generation and signature generation are not important and are not even part of the consensus rules, that is, part of Bitcoin?

I disagree that key generation and signing are unimportant - they're standardized, and individual wallet security very much depends on doing it right. They're just aspects of the wallet side of things, and not part of the consensus rules.

I wanted to say that they are not important to Bitcoin in the context of the consensus because they are not part of it. However, they are important from the security aspect, as you said, for wallets, creating the transaction in a secure way, etc.


text:
How to install Berkeley DB 4.8 on Linux?
The Unix build notes do not show how to install version 4.8 apart from saying

BerkeleyDB is required for the wallet. Ubuntu and Debian have their
      own libdb-dev and libdb++-dev packages, but these will install
      BerkeleyDB 5.1 or later. This will break binary wallet compatibility
      with the distributed executables, which are based on BerkeleyDB 4.8.If you do not care about wallet compatibility, pass --with-incompatible-bdb to configure. Otherwise, you can build from self-compiled depends (see above).

The referenced README.md from the quoted

Now, you can either build from self-compiled depends or install the
  required dependencies:

does not discuss BerkeleyDB 4.8.
I know there is ./contrib/install_db4.sh in the source for installing BerkeleyDB 4.8 but it abords on my Ubuntu with curl: (7) Failed to connect to git.savannah.gnu.org port 443: No route to host.

I found a solution here with:
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install libdb4.8-dev libdb4.8++-dev

Also, this says:

The newer libdb should work on most coin daemons, the issue you might find is that the database files (wallet.dat in particular) isn't compatible with all other systems if they're built on an older libdb.

That corresponds to the following line from the bitcoin core github:

This will break binary wallet compatibility with the distributed executables, which are based on BerkeleyDB 4.8.

So, having a newer BerkeleyDB is only a problem, if you want to use your wallet.dat on another system and this other system happens to use BerkeleyDB 4.8 - which is the case for the bitcoind executables which are downloadable from the project itself.
But if you only use the wallet on your own system or, if you migrate it, you use a system with the newer BerkeleyDB also, then there should be no problems.

You can compile it using this script in the Bitcoin Core repository:
https://github.com/bitcoin/bitcoin/blob/master/contrib/install_db4.sh . It will give you instructions about how to then ./configure with this compiled version in order to build the project.
Instructions about building Bitcoin Core are available in the /doc folder, for Unix systems it is at
https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md

The script install_db4.sh was removed from v25.
But you can find it in v24:
https://github.com/bitcoin/bitcoin/blob/24.x/contrib/install_db4.sh

this fixed my problem in kali
i used
sudo apt install libdb
and then pip install bsddb3 and it was able to find the local berkely installation and complete the install
thanks soo much

brew install berkeley-db@4 worked for me


text:
Lightning - why are commitment transactions supposed to use different keys
In the paper BIP32 and deterministic key derivation are mentioned. But why given that two peers directly exchange messages (i.e., there is no need to obscure anything)? Alice always exchanges state with Bob and that commitment transactions usually don't land on the blockchain.
Punishments for transmitting an old state can be done by attaching to the previous "breach-remedy" transaction using a valid preimage (that was exchanged while getting the new "commitment"). This means the script has to check the signature and invoke the hash function. An optimization is to use elliptic curve trickery and thus construct something similar to pay2contract scheme. I believe this way you still have to store all old values or am I mistaken? I've heard about ELKREM and optimizations in that part. But my question here is more basic, why did Poon and Dryja even consider BIP32? I understand the need for different settlement keys in Eltoo or the additional privacy for on-chain transactions, but what about Lightning?

I can come up just with one hypothetic case. Suppose Bob is cheating and publishes an old "commitment". Then Alice punishes him, but in a way that people monitoring the blockchain cannot see that Alice who gets money immediately and the Alice that gets the "punishment reward" is the same entity. So in some sense you hide from the public that Bob was cheating.

An optimization is to use elliptic curve trickery and thus construct something similar to pay2contract scheme. I believe this way you still have to store all old values or am I mistaken?

The elliptic curve trickery you mentioned is elliptic-curve multiplication. And yes, you need to store all old values.
In BOLT-03, under Key Derivation, it gives three reasons why the keys are changed(localpubkey, remotepubkey, local_delayedpubkey and revocationpubkey), and one of them is related to your question,

Changing the localpubkey every time ensures that commitment transaction ID cannot be guessed except in the trivial case where there is no to_local output, as every commitment transaction uses an ID in its output script.

I think the reason is that the authors had watchtower services in mind. Which I guess people agree are needed in the poon dryja channel construction. When you use the same keys for commitment transaction watchtower services can basically learn which payments in which amounts go through the channels. And start an attack on the privacy of people making and receiving payments. However if the keys change the channels get obfuscated for the watchtower since the state gets decorolated.

But aren't watchtowers completely blind in this regard? Yeah, they need to get that there was a new commitment immediately. But they don't actually see the stuff itself. You kind of just give them first half of the txid and tell them if you see something like this use the other half to unlock my prepared punishment and send it out. And they will see then if there is something in for them and do it. Or do you somehow need to prove to them that it is worth storing the data beforehand?

I don't think that's the case. As @fiction was commenting the towers are blind in this regard except when there's a channel breach. To my understanding, the main reason behind using different keys is to obfuscate the state in case of a breach, independently of whether there is any tower or not.

Might be related: https://bitcoin.stackexchange.com/questions/91437/if-a-user-recovered-data-directory-of-ln-node-software-with-an-old-backup-what/