text:
What exactly is checked at various -checklevel's?
The standard bitcoin-qt/bitcoind client has an option -checklevel which purports to perform various checks on the block data stored on disk.  Is there current documentation (other than the source) describing specifically what is checked at the different levels?
The function VerifyDB in the source has brief comments describing the levels:
// check level 0: read from disk
// check level 1: verify block validity
// check level 2: verify undo validity
// check level 3: check for inconsistencies during memory-only disconnect of tip blocks

It would be nice to see these explained in terms of the Bitcoin protocol.  For example, are block hashes verified?  Do we check that all the blocks in the chain correctly link back to one another?  Are transaction signatures verified?  Et cetera.

The other answer seems to be out of date, even at the time it was answered. The following seems to be a more up to date explanation:
From https://bitcointalk.org/index.php?topic=141200.msg1504768#msg1504768

0: Validate all block headers + compare (by hash) to blocks on disk for the last -checkblocks blocks
1: In addition, verify (standalong) validity of those -checkblocks blocks
2: In addition, verify that undo data matches checksums
3: In addition, check that the current chainstate matches can reasonably be the result of the last N blocks, where N is limited by both -checkblocks and the amount of in-memory cache (-dbcache); typically it's around 150.
4: In addition, for the last N blocks (see above), do full validation (including signature checks).

Note that the new default (3) is in fact a stronger check than the previous highest level (6).

Check comments in this commit
https://gitorious.org/bitcoin/luke-jr-bitcoin/commit/4538e45c46d3829a21aed7685e6fbac7e8aafad3
Add -checklevel and improve -checkblocks

-checkblocks now takes a numeric argument: the number of blocks that must be verified at the end of the chain. Default is 2500, and 0 means all blocks.

-checklevel specifies how thorough the verification must be:

    0: only check whether the block exists on disk
    1: verify block validity (default)
    2: verify transaction index validity
    3: check transaction hashes
    4: check whether spent txouts were spent within the main chain
    5: check whether all prevouts are marked spent
    6: check whether spent txouts were spent by a valid transaction that consumes them


text:
Is it safe to keep a compromised private key in my wallet?
I'm using bitcoin-qt.  Suppose that one of the private keys in my wallet is compromised somehow, and is released to an attacker or the public.  Of course, I can transfer all the coins from the compromised address to a new one (unless the attacker does it first).  However, bitcoin-qt apparently doesn't provide a way to delete or disable a private key from a wallet.   (This is understandable; it would be pretty bad to accidentally delete a private key for an address that had coins in it.)
Is it safe to leave the key in the wallet, assuming I never again intentionally transfer any coins to that address?  (I could label it DONOTUSE or something.)  Or are there situations (e.g. change) where the client might automatically transfer coins there without asking me?

If it is only one private key and you are aware not to use it anymore (and have rerouted any anticipated transactions to a new address), there is nothing harmful that the attacker can do.
Bitcoin-qt sends change from transactions to new unused addresses. Since those are the only transaction outputs that are transmitted to not-explicitly-specified addresses, it is safe to keep the private key in your wallet.
A compromising party could, however, use the private key to sign messages. These messages would appear to be authored by you to recipients that know the respective address to be under your control. Unless the compromising party had additional information about you and the counter-parties of previous transactions the compromised key was used in, this shouldn't be useful to them (nor could you stop it either).

source: Stack Exchange

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

sort: votes


text:
Who accepts Moneybookers/NETELLER?
Because I don't have any rep. and the chargeback issue, no one will buy my Moneybookers(USD) or NETELLER(USD). Is there an exchange that will?

Buying bitcoins with a reversible payment method like PayPal, MoneyBookers, NeTeller, etc, is always going to be difficult.  Cashing out to those methods is much easier though, with a half dozen methods: http://en.bitcoin.it/wiki/Selling_bitcoins

According to the Wiki:

VirVox accepts NETELLER and Moneybookers
Bitcoin.de accepts Moneybookers

You could always approach high-rep users and ask them to do exchange with you at some rate favourable to them, and also letting them send you Bitcoins only after some time after which chargeback would be impossible. This way you risk little (high-rep users can generally be trusted), and you will get your positive reputation started.

VirVox seems to be down and Bitcoin.de is an exchange

@abrkn From the question: "Is there an exchange that will?", both of them are exchanges. VirVox appears to be up at least for me. You can always try doj.me website to verify if a webpage is down or not.

VirWox (note the W) ended support for Neteller on 2014-03-06.

The only current option I could find so far is via LocalBitcoins.com (https://localbitcoins.com/buy-bitcoins-online/neteller/).
The exchanges listed on the official wiki page (VirWox, mercaBit.eu and rugatu.com) that are noted to support Neteller are all down or ended their Neteller support.

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


text:
How does offer creation impact fund requirement of an account?
How much does each offer created increase the XRP requirement on that account?
Does it relate to PayerGets?
Is it cleared once I cancel the offer?

Abrkn, what is PayerGets?

see https://ripple.com/wiki/Transaction_Format under OfferCreate

So you mean TakerGets?

Every entry in the state tree of the ledger requires 12.5 XRP reserve, it doesn't matter if it's a trade offer or a trust-line. When the entry disappears from the ledger (by getting filled or being canceled), the reserves can be moved again.
The only exception is the account entry, which requires 50 XRP instead of 12.5 XRP and is perpetual (because accounts cannot be deleted).
See https://ripple.com/wiki/Reserves for details and the current reserve requirements (they can and have changed).
It is not related with the field TakerGets of the message OfferCreate.

(jed2 on irc) abrkn: 50 xrp. Doesn't matter what the offer is for. It is cleared when the offer is canceled (or fulfilled).

"When the offer is"... what? I guess he meant "either fulfilled or canceled"?

Yes, I believe that was a bad paste. It is cleared when cancelled.


text:
Why Does Bitcoin Core Use Autotools?
Why does Bitcoin Core use Autotools instead of checking a Makefile into source?

Because checking for compiler features, without Automake/CMake/Ninja/Bazel with only Makefile and C++ preprocessor is hard and unelegant.
And C++ preprocessor can't be used to make full-compile feature tests. If the compiler supports AVX256, a relatively new instruction set, that doesn't mean the assembler supports it too. There are "fail if can't compile completely"s in the autoconf file.

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


text:
What RPCs can I use to transform an address to a paying script?
What RPC(s) can I use to transform an address to a paying script (0014<addr>)?

Hi warchantua, could you please describe a little more what you're trying to achieve? What are you starting out with, what should the final outcome look like?

Try validateaddress, note the scriptPubKey in the output of these examples:
$ bitcoin-cli validateaddress bc1q7ckr2hlws6ku4mlaggvmfqwgs42zjm4qf3s7hy
{
  "isvalid": true,
  "address": "bc1q7ckr2hlws6ku4mlaggvmfqwgs42zjm4qf3s7hy",
  "scriptPubKey": "0014f62c355fee86adcaeffd4219b481c88554296ea0",
  "isscript": false,
  "iswitness": true,
  "witness_version": 0,
  "witness_program": "f62c355fee86adcaeffd4219b481c88554296ea0"
}

$ bitcoin-cli validateaddress 1MWrgo4rm1aoPYFjCCMXgr1e564xVyHCqM
{
  "isvalid": true,
  "address": "1MWrgo4rm1aoPYFjCCMXgr1e564xVyHCqM",
  "scriptPubKey": "76a914e1080defe0aa086f1d5f698faf614e8f67af6e3b88ac",
  "isscript": false,
  "iswitness": false
}

Update: RPC getaddressinfo will also return the matching output script.

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


text:
Why do I have a socket.timeout with python-bitcoinlib?
I am using a small script and get a timeout from python. This is my script:
import bitcoin
import bitcoin.rpc
from bitcoin.rpc import RawProxy
p = RawProxy()
hash = '0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4'
infoblock = p.getblock(hash)
print(infoblock['difficulty'])

This is my error:
bitcoin@raspberrypi ~/.bitcoin/BuchSkripte $ python3 49_rpc_example.py
Traceback (most recent call last):
  File "49_rpc_example.py", line 11, in <module>
    infoblock = p.getblock(hash)
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 306, in <lambda>
    f = lambda *args: self._call(name, *args)
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 236, in _call
    response = self._get_response()
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 261, in _get_response
    http_response = self.__conn.getresponse()
  File "/usr/lib/python3.5/http/client.py", line 1198, in getresponse
    response.begin()
  File "/usr/lib/python3.5/http/client.py", line 297, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.5/http/client.py", line 258, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.5/socket.py", line 576, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

When using the same method getblock via bitcoin-cli it takes 120 seconds to finish on my Raspberry. If the timeout is related to this duration, can I increase it in the script?
I read that the socket timeout can be set but I wonder if I can do this if I use a library for the connection.

Change the timeout inside the file bitcoin.conf or when you start the bitcoind,
This is an example
##
## bitcoin.conf configuration file. Lines beginning with # are comments.
##
# On client-side, you add the normal user/password pair to send commands:
rpcuser=alice
rpcpassword=bob
rpcclienttimeout=200

or you can run the bitcoind with this command bitcoind -rpcuser=alice -rpcpassword=bob -rpcclienttimeout=200
Or you can change the setting lib to the code, try this example
from bitcoin.rpc import RawProxy

# Create a connection to local Bitcoin Core node
p = RawProxy(None, None, None, 120)

# Run the getblockchaininfo command, store the resulting data in info
info = p.getblockchaininfo()

# Retrieve the 'blocks' element from the info
print(info['blocks'])

Unfortunately, this does not work. I think it is because there is another timeout happening before, the one which is defined for the HTTP inside the library.

update the answer

I had to change the timeout variable that is used inside the method of the library by giving a value to it when calling the method.


text:
XPRIV/XPUB type for P2TR
As far as I understand, there is a standard that describes what address types an extended private key or extended public key is intended to derive and it works as such:

xpriv/xpub => Legacy address (1...)
ypriv/ypub => nested SegWit address (3...)
zpriv/zpub => native SegWit address (bc1q...)

So regarding this, I have 2 questions:

What is the name or BIP number of this standard?
What does an extended public key look like, that is intended to be used for P2TR addresses (bc1p...)?

There is no ypub/zpub similar thing for Taproot. The recommendation is to use xpriv/xpub along with some extra information indicating that the script to create is Taproot, (e.g. with a tr() descriptor).
This is because it is a layer violation to have the extended keypair indicate the script type to create. The keys should not and do not care about what scripts to create. Additionally, xprv and xpub are not supposed to indicate legacy addresses - they are for BIP 32 extended keys which are script agnostic. To use them to indicate legacy addresses is incorrect.
In general, there is a move towards encouraging and using more complicated scripts where having extended keypairs indicate script type doesn't really make sense.

The concept of an xpub originates from BIP32, where it denotes an extended public key, from which multiple child keys can be derived.
At the time of BIP32, there was really only one address type commonly used, pay-to-pubkey-hash (P2PKH). Thus, BIP32 were commonly understood to imply a sequence of derived P2PKH addresses.
After segwit, when other address types came in common use, like P2SH-P2WPKH and P2WPKH, people needed a way to convey "a BIP32 extended public key, but the derived addresses are P2SH-P2WPKH". This became the ypub scheme defined in BIP49 for P2SH-P2WPKH, and later the zpub scheme in BIP84 for P2WPKH. They contain the exact same information as a BIP32 extended public key, but with a different prefix to denote the corresponding address type. Various other variants were defined and adopted by some software, e.g. Zpub for P2WSH, but not standardized through the BIP process as far as I know.
Other software never adopted ypub/zpub/Zpub/..., as the continuing need for new prefixes does not scale well, and the notion of trying to pack all address derivation information into a single key string also just doesn't work for more complex constructions like multisig. For example, in the newer output descriptors (BIP380) standard, xpub is always used, but one would use wpkh(xpub...) to indicate a P2WPKH address type.
As far as I know, there is no *pub-like standard for P2TR yet, and in my opinion there should not be. It is much clearer to convey address type information outside of key strings.
Disclaimer: I'm the author of BIP32, and co-author of BIP380.


text:
Qualitative anatonomy of a transaction that uses ANYPREVOUT
I am entered the world of bitcoin recently and currently I am studying the broad area of covenants (that are gaining more attention from the community, see 1). In this context, certainly the BIP-0118 is relevant.
Assume hypothetically that BIP-118 is active, suppose that a payee wants to precompile a transaction tx with ANYPREVOUT. The transaction tx makes no explicit reference to any input to be spent and will be presented later to the payer to be signed. Assume that tx is built to consume an unspent output of the payer and the amount is completely transferred to the payee, without change. So, tx will have one input and one output. I would like to understand how this transaction tx should look like and how this should be used in practice. I discuss below my idea about, hope to find someone that corrects me or improve my understanding. In the following, we assume that the fees are zero.
As I understood, tx produces a P2TR output that is spendable only via the script-path (see taproot BIPs 3, 4 and 5 or 6 for a brief anatomy of P2TR outputs or inputs). The receiver address is a new type of address, that has this two possible forms:

0x01 or
0x01A
where A is a 32-bytes string. I think that A is a Schnorr tweaked public key, namely the x-axis component of the point Q=P+hash(P||h)⋅P, where P is a Schnorr public key (see 7 for a description on tweaked key) and h is the hash of some script s (in general, h is the Merkle root of some Merkle tree, but I guess that in our case the Merkle tree consists in just one point/leaf, is this correct?). Call x the private key, so xG=P, where G is a generator of the elliptic curve.

Suppose for now that we deal with addresses of the form as in 2. So the payee address is version 1 segwit, and the witness program (the output of tx) has more or less the following form:
<h1> <h2> 0x01 <h3>

where h1 (int 64) is the amount in sat, h2 (var int) is the length of the following item and h3 is a 32-bytes string that represents the x-axis of the tweaked pubkey Q.
For spending the tx output is necessary to present a witness, that, by construction, has (strictly) more than 2 elements, see 8. In particular, the witness has the form:
<n> <d> <s> <c>

where n is the number of witness elements, d is the data for the following item s, that is the script (such hashed gives the h used to tweak the the pubkey) and c is the control block. The control block is of the form
0xc0 <p> <b>

where 0xc0 is the leaf version (didn't really understand it, has something to do with the idea "leave possibility to future upgrades", like the version byte of segwit?), p is the internal pub key, namely the x-axis of P and b should be a sequence of hashes that are used to reconstruct the merkel tree. So, in our case, b=h?
So far, hasn't appeared yet anything that tells us that the part of the transaction that is signed (by x, the internal private key of the payee?) does not include any reference to a previous input (even though it should include the  input amount, the function that calculates this part of the message signed should be SigMsg118(hash_type,ext_flag) ). So, I suppose that the script s does the ANYPREVOUT-job in the following way.

A signature (R,s) (made by internal private key x that corresponds to p) appears in the part d above. This signature commits to all outputs, to all inputs' amounts but not to any reference to the previous inputs; the hash_type of the signature should be 0xc0, that corresponds to SIGHASH_ANYPREVOUTANYSCRIPT (actually, SIGHASH_ANYPREVOUT commits to the inputs' references, as I understood; see 9).
Now, in the script s should appear a sort of OP_CHECKSIG, that checks the signature (R,s) against the internal pubkey p.

Nevertheless, p appears in the control block c, that is after s, and actually the pubkey p is a data for the script and should appear also in d. There is something that I am missing in the logic.
So far, I discussed how to spend the output of the transaction tx that uses ANYPREVOUT. But before this, tx has to be validated and for doing so, it must consume some input. As mentioned in the beginning of the question, once tx is created as above, it is sent to the the payer, that puts the inputs's missing data. So, he adds to tx the following:

the inputs' reference, namely a previous transaction hash and the index of the unspent output that it is going to be consumed;
the signature of the input with sighash-type SIGHASH_NONE|ANYONECANPAY. For instance, the unlocking script with a signature SIGHASH_NONE|ANYONECANPAY in the case that the input is P2PKH, or the witness, if the input is segwit, that should contain again some SIGHASH_NONE|ANYONECANPAY-part (actually it can be any king of input, not just P2PKH or P2WPKH)

Now, there is one more problem, namely that the payer is supposed to have an unspent output of the exact value of the funds he wants to send to the payee. Suppose that this is not the case and the payer has only unspent outputs of larger amounts. So, a change is needed and the transaction tx will have two outputs as before. The change is an output as before, that requires the machinery of BIP-118 to be spent. So, it is correct to say that the payer signs the transaction only if his wallet is BIP-118-aware?
One last question. In 10, Michael Folkson kindly explained me how BIP-118 deals with public keys of the form 0x01. But how they are supposed to work in this context? How all the machinery I discussed above works with BIP-118 1-byte public keys?

I'll make some edits later but where you say "address" you should be saying "public key". BIP118 defines a new public key type but doesn't make any changes to the address format (bech32m).

I think you misunderstand sighash flags too. "The transaction tx makes no explicit reference to any input to be spent and will be presented later to the payer to be signed." The signer will choose to use a sighash flag like ANYPREVOUT (or SIGHASH_SINGLE, SIGHASH_ANYONECANPAY etc) at signing time and that will determine what the signer needs to sign. The transaction isn't constructed to be an ANYPREVOUT transaction and then presented to the signer. A transaction always needs inputs to spend but whether the signer signs those specific inputs is the question here.

The functionality we want for protocols like eltoo is for that signature to be reused in a new transaction with different inputs without requiring a new signature.

Well actually I misunderstood the logic. The signature is done by the payee. But I still don't understand where in the witness appears this signature. ANYPREVOUT only supports spending a P2TR via the script path, so a P2TR output with an invalid script can't be spent using ANYPREVOUT. This is strange!

There can only be an ANYPREVOUT signature spending via the script path not the key path, yes. But there can be a non-ANYPREVOUT signature spending via the key path still. So in the unlikely scenario that the script path implementation was botched you could still spend from the key path with a non-ANYPREVOUT signature (assuming that a spendable key path had been encoded into the address)

ok but, still, suppose that someone, say Alice, is making a transaction tx1 that spends the output of a transaction tx0 made by Bob, that hasn't appeared yet. So, Alice precompiles the transaction tx1 with anyprevout, that can spend the tx0 output only using the script of tx0. But Alice may not be aware of this script, that is made by Bob and so may not be able to precompile tx1... Is this a problem? I mean, this seems to require communication between Alice and Bob...

Right in protocols like Lightning and eltoo'd Lightning they require communication between Alice and Bob. In your example Alice needs to know the script that Bob encoded into the outputs of tx0 to be able to construct a transaction that spends those outputs.

ok thank you! this is very helpful!


text:
how to get the private key in Bitcoin Core 26.0.0 and how to create a legacy wallet
i had tried many methods but nothing help me
,
by using bitcoind -deprecatedrpc=create_bdb

i think i had installed the Berkeley DB
please help me to solve the problem

Do you need to create a wallet using Berkeley DB? Why not install sqlite3 as a dependency, build Bitcoin Core again and use the DB that the non-legacy wallet supports? Assuming you don't have any mainnet funds in a legacy Berkeley DB wallet that is.

but the legacy wallet can be created by using only the bdb , i need the legacy wallet to find the private key in the regtest

You are creating a new wallet? Regtest is supported in the non-legacy sqlite3 wallet.

is there is a way to find the private key for the newly created wallet

dumpprivkey doesn't work for non-legacy but there is an alternative to using dumpprivkey https://bitcoin.stackexchange.com/questions/113834/why-can-i-not-dump-private-keys-from-a-descriptor-wallet

still i don't get the private key !!

"You can get the master private keys by using listdescriptors true. This will output all of the descriptors stored in the wallet along with their corresponding private keys." If you aren't sure what the private key is here post a different question

if i use listdescriptors true i only get pkh,sh,tr,wpkh

What is the actual problem you are trying to solve that you are trying to the get the private key for?


text:
How to regularly restart bitcoind after some period of time on Linux
If, like me you wish to automatically restart bitcoind after some period of time, or if it crashes at least it will restart sometime on it's own you know that it can take a long time on Linux before process cache finishes writing to disk and then you can restart without the dreaded message Error: Cannot obtain a lock on data directory /media/drive2/.bitcoin/. Bitcoin Core is probably already running.
How to restart bitcoind automatically using a script without error message and failure to start?
This question is specifically to allow bitcoind to exit cleanly as it can take an inordinate amount of time to exit cleanly even though you cannot see the process with ps -ae | grep bitcoind you can still see it with htop until it finishes committing the process cache to disk and finally "Shutdown: done" is written to disk. If configured as  daemon it is possible to have thousands of failures starting before the process finally exists.

Does this answer your question? Ubuntu Linux -- How do I start bitcoind as a service to run automatically?

@RedGrittyBrick It would be part answer but it does not safely exit and then restart the process like a process cache flush.

Actually I have not checked, I presume that if I configure bitcoind as a service and run systemctl stop bitcoind.service that it returns immediately?

The operating system has features designed to do what you want, specifically the respawn  or restart`directive is intended to ensure that a service which dies gets restarted ASAP. Where this can be used I think it is often likely to be better than a homebrew solution as probably more time has been spent on the feature by a greater number of people over a much longer period in which bugs and wrinkles have been ironed out.

@RedGrittyBrick Oh I agree it is just if systemd understands the difference between exiting clearing application cache and process exited. Let me know if you check I can update my answer.

The bitcoind process exits almost immediately when you run bitcoind-cli stop so you cannot simply detect the bitcoind process. Even though you can possibly see bitcoind with htop after running bitcoin-cli stop you cannot see it with ps because it has exited.
The answer is to find a way to reliably wait for the process cache to finish writing to disk. bitcoind nicely writes to debug log with the following message as the last thing it sends to disk, Shutdown: done so it is possible to detect this way.
The following script is available on GitHub on the MIT Licence and is republished here with permission under the additional licences of.
I Hope it is useful for you.
#!/bin/bash
# Exit and restart bitcoind after some time period
# Willtech ©2022

# How often to restart in seconds
timeout=3600

# BAT / CMD goto function
# Source: https://www.codegrepper.com/code-examples/shell/bash+jump+to
function goto
{
    label=$1
    cmd=$(sed -n "/^:[[:blank:]][[:blank:]]*${label}/{:a;n;p;ba};" $0 |
          grep -v ':$')
    eval "$cmd"
    exit
}
# Just for the heck of it: how to create a variable where to jump to:
start=${1:-"start"}
goto "$start"

: start

#Start bitcoind
bitcoind -daemon

#Run until timout
sleep $timeout

#Stop bitcoind
bitcoin-cli stop

#Tries for ten minutes to see if exit is detected.
until timeout 600s tail -f /media/drive2/.bitcoin/debug.log | grep -m 1 "Shutdown: done"
  do
    sleep 2
  done

#Log again
echo again

#Loop to : start
goto "start"

echo bar

# Ref >>>
## https://askubuntu.com/a/1070296
## https://www.delftstack.com/howto/linux/bash-goto/

Anecdotally, it used to take maybe a month with 1TB USB3 platter disk to do initial sync even with swap as larger than 100GB but now it takes only about three days restarting every one hour until it is up to date. That is in blocks download mode on a blank disk so that data is written near to where it is found.

Note you need to set your location of debug.log.


text:
Is it always necessary to be in the pool with the most miners joining to have the most profitable mining pool?
I realise that opinion on a specific pool is subjective and prone to change.
My question: If I am in pool A and additional miners join then my share in the pool is reduced proportionately. Additionally, the pool received more block find rewards proportionately. Similarly, the reverse if users leave the pool. My mining reward in the pool is largely unchanged.
If miners join pool B then pool A finds lees blocks proportionately and my mining reward is also reduced. The reverse is also true.
It seems that the most profitable pool, with all other things being equal, is always the pool with the most miners joining? Both because they are not joining pool B I do not suffer any loss (or, they are leaving pool C) and, because the new miners are joining pool A I do not suffer any loss.
It seems like the ideal scenario is for pool A to syphon all users from all other pools and become a conglomerated 'Mining Central'? Or rather, for all other miners in pool B and C to quit.
Please correct my assumptions if they are wrong.

This isn't correct.  Your reward is reduced (in the long run) by the same amount whenever a new miner joins, regardless of whether they choose your pool or a different one.
If they choose your pool, it's true that your share of the pool decreases, and the pool's share of the total rewards increases, but these changes don't completely cancel out.  The net effect is a decrease in your reward.
Let's try an example with small numbers.  Suppose there are 10 miners in the world, all having equal hash power.  6 of them, including you, belong to Pool A, and the other 4 belong to Pool B.  So Pool A collects 6/10 of all rewards, and you get 1/6 of those, so you are getting 1/10 of all rewards.
Now suppose a new miner joins Pool A.  Pool A will now get 7/11 of all rewards, and you get 1/7 of those, so you are now getting 1/11 of all rewards - less than before.  If you work out the numbers, the pool's fraction of the total got multiplied by 1.06, and your fraction of the pool got divided by 1.16.
If the new miner joins Pool B instead, Pool A now gets 6/11 of all rewards, and you get 1/6 of those, so your share of the total is again 1/11.
As such, ignoring differences in pool administration fees and such, you get rewarded the same whether you are in a large pool or a small one.  The only difference is that in a large pool, your rewards will be paid out more steadily as frequent small payments, while in a small pool, you will tend to see infrequent large payments instead.


text:
Trying to find an efficient method to process all transactions directed to my BTC address
I am building a website which involves in the processing of transactions of BTC. My current and most efficient plan to complete this would be to call these bitcoin-cli commands and process the data accordingly:
getblockcount - get block height
getblockhash blockheight-5 - get the block hash for the last 5 blocks
listsinceblock blockhash - list all transactions since then
I would run this order of commands every 5-10 seconds. I would like to know if this method wont screw me over at all (skipping transactions, etc). I might just be too paranoid about clients not getting what they paid for and just want a guaranteed method that no transactions slip by. I was hoping to call a method that can list all transactions since a certain time but that wasn't available. Now to the question:
Is this method CPU/Network intensive?
Is it a safe method?
What are my alternatives?

If you are getting the last 5 blocks and logging all transactions since then, why would you run this every 5-10 seconds?
I think you'd be safe running it every N minutes.
Are you storing this in a database?

It's possible, though unlikely, that more than 5 blocks could be mined in those 5-10 seconds.

Despite that probability, I'd rather not take that risk.

Please edit the title to summarize your question's topic.

I have found the answer to my own question
To make sure every transaction goes through my script I have decided to use walletnotify. This is a feature of bitcoind and will run a bash script every time there is a new transaction with the transaction id. I was able to place this in my .bitcoin/bitcoin.conf file with the parameters like so:
walletnotify=/bin/echo %s | /bin/nc -U /root/nodejs.sock
I used netcat to bridge my requests from bash to NodeJS however you can use your %s transaction data any way you like.


text:
Is magicbytes sequence a valid delimiter for blocks in blockchains?
For a blockchain parser, is it correct to say that "for X magicbytes sequences, we have X blocks in blockchain" ?
In other words, may blocks in blockchain accidentally contain magicbytes sequences ?

A blockchain is an abstract datastructure that contains a chain of blocks, consisting of hash-linked he headers and transactions.
If you're talking about a parser, I assume you're talking about files on disk... perhaps the blk*.dat files in Bitcoin Core's data directory. Those are just one way to represent the blockchain, and it's an implementation specific one that can change between releases.
Assuming you're indeed asking about the disk representation of blocks in Bitcoin Core (or similar software):

Every valid block starts with the magic sequence plus the size.
The magic sequence is allowed to appear inside the middle of blocks.
There may be gaps between blocks that are filled with garbage, including byte sequences from block data, which may in fact also contain the magic sequence.

Furthermore, the term 'blockchain' is often interchangably used for both the tree of all blocks produced/known, or for the longest path through it. The block files on disk contain all blocks Bitcoin Core has ever seen, including blocks that are not part of the main chain ("orphan blocks") and were stale or reorganized out.

Sorry that my question was unclear. You guessed well, I'm talking about disk representation of blocks in bitcoin core. Thank you for your detailed answer.


text:
How to get balance of tens of thousands of addresses?
What is the best way to get balance of large amount of addresses?
I tried to use APIs from different providers, but they are limiting the requests. Is there any APIs that give premium service without limiting requests?
Or maybe should I run full node, and use it?
If yes, how I'm using the full node to get the addresses balances? I'm using Ruby on Rails.
Thanks.

Possible duplicate of How to index the UTXO set efficiently?

I think your should consider that using an API could result in fakes, wrongly-validated data. Using an API means you fully trust the API service,... which is kind-of against bitcoin no-trust model.
I recommend you to run a full node (Bitcoin Core 0.13.2 during time of writing).
There is no address-index (there is a patch you can manually compile into Core).
Simplest way with standard Bitcoin-Core 0.13.2 is to import all your addresses as watch-only into a wallet.
import addresses
Use the RPC call importaddress <address> "" false to import a watch only address.
The 3rd argument false is required to not rescan the blockchain for each import (can take serval hours).
Once you have imported all addresses, stop bitcoind/qt and restart it with the startup argument -rescan.
The rescan may take a couple of minutes/hours (depending on your Disk/RAM/CPU). Once done, you can call getreceivedbyaddress <addr> for each address to get the balance.
This result in authentic, self-validated data.
Note: If you are using Bitcoin Core 0.14, consider importing multiple addresses with importmulti

Hi, thanks for your answer, but this method is not very effective if the addresses list change every run, because each run I need to go through this process that can take some time. If I'm running full node, I should have access to all data on the blockchain, no? No convenient way to access this data?

Then you need an address index. Either look at the existing Core patches (There is a pull request for Bitcoin Core) or try to use existing alternatives (Bitpays Insight [based on Bitcoin Core])

Have you tried blockonomics api . Their free plans allow 50 addresses at once and paid one upto 8000
If you want to run your own node. I would recommend running abe blockexplorer along with your node. Core wallet and other SPV wallets like electrum have known to become sluggish with large number of addresses


text:
Is it legal to use bitcoin in a domain name?
Is it legal to use bitcoin in a domain name? Not a sub domain, but in the main domain name.

What do you mean 'in' a domain name? A domain name which contains the substring 'bitcoin'? Buying a domain name with bitcoin? Putting a bitcoin address on a website?

@PieterWuille like bitcoinShop.com so the main domain name has the word bitcoin in it not a subdomain like bitcoin.example.com

Why would that be illegal? Is is not allowed to have a website with the name dollar in it?

@PieterWuille just wanted to make sure cause its based on MIT license and opensource but the name it self might be registered for some reason. Thanks for your help Pieter :))

To date, no entity has trademarked word "Bitcoin" in the US. This means that it's highly unlikely that any US entity would file against your domains under the ICANN Uniform Domain-Name Dispute-Resolution Policy.
There was a servicemark application for Bitcoin, but it was abandoned in July 2011.
Related trademark applications

Bitpay applied for Merchant Solutions for the bitcoin currency and Bitcoin Merchant Solutions, both also abandoned.
There is one for Bitcoin appliance, also abandoned.
Bitcoin Magazine applied for a trademark, and it's still in processing.

Mt. Gox registered it. https://mtgox.com/press_release_20111014.html http://bitcointalk.org/index.php?topic=128254.msg1365911#msg1365911


text:
Does a new private key is generated at each transaction?
So, imagine I bought 1 BTC, so I have my private key generated by my online wallet and also my public key that I can give to people/friends.
My question is, if I spend 0.5 to buy Apples on a website?
How does that work?
1) Only 0.5 BTC is sent to the website, I still have 0.5 BTC on private key A
2) 1 BTC total is sent through the protocol, thus the change is sent back to me.
On which key?
Key A where I had 1 BTC ? Or a new one generated? (Key B)
Thank you :)

Since you're using blockchain.info as your wallet provider, it is probably best if you ask them how are your keys managed or read their FAQ

I'm really not sure what this question is supposed to be about. 1) Are you asking whether blockchain.info reuses addresses for change outputs? 2) Are you asking whether there can be more than one address per private key? 3) Are you generally asking about wallets managing multiple addresses?

Hi, I am asking: I have 1 BTC I buy something at 0.5 BTC. Where is the 0.5 change going to go on my wallet?

Someone else told me there is no change, so if you have 1 BTC on address A you want to spend 0.5, well you spend it and you still have 0.5 BTC on address A.

Every private key has exactly one corresponding public key, and every public key has one address. Whenever a new address is generated, internally that means a new private key and public key are generated. Note that with BIP32 and BIP44, private keys can be generated deterministically from a master key or a seed, in which case these new private keys do not necessary need to be saved - they can just be regenerated from the seed or master whenever needed.
A new keypair is used for each change in most wallets, but that's done internally - it won't show you the address for those, as there is no need for anyone else to send you money to that.
Creating addresses is very cheap. A modern CPU can generate 1000s per second. It also does not require any interaction with the network. All that is needed is generating 32 bytes of random data, and computing its corresponding elliptic curve point.

Ok thank you but it means that I still keep my FIRST (same) private key of my wallet with the change I received? (internally they should've sent it back to my first adress) right?

I don't understand your comment.

"A new key is used for each change in most wallets, but that's done internally" which key? a new private one? or public?

Edited to keypair. Every private key has one public key (ignoring encoding), and the other way around.

If all the 1BTC was in one Unspent Transaction Output (UTXO) then you'd indeed send all of the 1BTC as an input in a transaction and assign this to two new outputs: 0.5BTC to make your payment and 0.5BTC to return your change to yourself.
If the 1BTC was split up into several Unspent Transaction Outputs, then you may have a combination that amounts exactly to 0.5BTC, e.g. you could use 0.1BTC+0.2BTC+0.2BTC. Then no change output would be created.
Whether you send change to the same address as before, or to a new address is up to the creator of the transaction. Most wallets avoid reusing the same address by default though, so the change output is sent to a new address.

related: How does change work in a bitcoin transaction?

Ok thank you! But either way, everything is done automatically by the wallet right? I don't need to care about wether or not the BTC was in one Unspent Transaction Output (UTXO) ? However, when is it truly useful to know that?

Yes, this sort of managing is exactly the purpose of wallet software. It may be interesting for you to know about your UTXO if you're micromanaging your privacy.


text:
Electrum Holding Bitcoin Long Term Seed
I am sure this has been asked before but I want to be absolutely sure before I start:
Using the Electrum Software I have created a basic default wallet on my desktop. I have a good deal of money stored in it and I plan to leave it there for a year, hoping the price of bitcoin will rise.
My question: If after a year, my computer hard drive fries, I forget the public and private key, I don't remember my Electrum password and I hardly even rememeber what Bitcoin is, will I be able to recover everything with only the 12 word seed I have?
I could even delete my wallet and unistall Electrum, move to Mars and if I had an internet connection and the seed gain all my bitcoin back correct?
EDIT: I just want to add, that I don't wan't to use a paper wallet just in case I decide to temporarily use some of the money although I don't plan on using it I want to have the option.

Or do I also need the Public Key and wallet.dat?

Yes, you can do all of that. To use your money, you need your private keys. Those are generated by Electrum using your seed. The password only protects the data stored on your computer by Electrum so not everyone who has access to your computer can spend your money. Spending your money without knowing your password is possible if one has your seed.
To sum it up:
Things you need to recover your wallet

Electrum (not even that much of a requirement itself but it's the easiest option)
your seed
some data (which can automatically be retrieved from the internet by Electrum (easiest way; Internet access on the computer you make the transaction on is not a requirement but nice to have.))

Things you don't need to recover your wallet*

the computer you generated the wallet on
any data Electrum stored on that computer
the same operating system you used before
the same version of Electrum you used before
the same kind of device you used before
your addresses
your public keys
your master public key
your private keys
your master private key
your wallet password
an imaginary wallet.dat (because there is no wallet.dat with Electrum ;-) )
 * Of course, some of those or a combination of some of them can be used to spend your money or to determine your wallet's seed, but that's not what you need to care about, here.

You probably still should write your seed onto a piece of paper. This – of course – doesn't mean you can't spend your money in the mean time or have to update the seed afterwards. Your wallet's seed doesn't change.

You should store your information on a USB drive or external hard drive just to be safe. I have my keystore file and pass (for ETH) on 2 different computers and a USB drive just to be safe.

But all I need to store in multiple places is the seed right? I don't need to know the address: public or private, the password or anything else right?

I agree with your advice but I don't think this answers my question.


text:
Deleting and restoring wallet
Is it safe to delete my bitcoin wallet (coinomi) and restore it from 24 words phrase when ever i need it (once a year)

Yes. It is safe if you don't forget the seed.
You could also create a new wallet and send 1$ for example to one of its adresses, delete that wallet but keep the seed in mind and try to restore it. If you make a mistake, it's only 1$. If it works, you have the experience and don't need to worry.

By delete your wallet do you mean delete your account and .dat file? Thanks to BIP32 the seed/recovery phrase allows a user to back up and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the private key.
In other words your recovery phrase is equivalent to the private key so if you had a lost/deleted/stolen wallet then you would be able to recover it with the recovery phrase/seed.


text:
ModuleNotFoundError: No module named 'bitcoin'
Here's my code:
from bitcoin.rpc import RawProxy
# Create a connection to local Bitcoin Core node
p = RawProxy()
# Run the getinfo command, store the resulting data in info
info = p.getinfo()
# Retrieve the 'blocks' element from the info
print(info['blocks'])

I could execute the RPC using curl:
➜  bitcoin git:(master) curl --user glaksmono --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getwalletinfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332
Enter host password for user 'glaksmono':
{"result":{"walletname":"wallet.dat","walletversion":159900,"balance":0.00000000,"unconfirmed_balance":0.00000000,"immature_balance":0.00000000,"txcount":0,"keypoololdest":1523932637,"keypoolsize":999,"keypoolsize_hd_internal":1000,"paytxfee":0.00000000,"hdmasterkeyid":"6e64f10c7c94532b597feaec70369df40ae84023"},"error":null,"id":"curltest"}

I've also installed python-bitcoinlib successfully:
➜  Sandbox pip install python-bitcoinlib
Collecting python-bitcoinlib
  Downloading https://files.pythonhosted.org/packages/30/03/fb7df95fe89baede202cf3fe65e65bea4bf863061b5e8f59b12dab538240/python_bitcoinlib-0.10.1-py2.py3-none-any.whl (88kB)
    100% |████████████████████████████████| 92kB 1.5MB/s
Installing collected packages: python-bitcoinlib

Ideas how should I execute the RPC through the Python code?

The result of my script and the python and pip versions are below:
➜  Sandbox pip --version
pip 10.0.0 from /Library/Python/2.7/site-packages/pip (python 2.7)
➜  Sandbox python --version
Python 3.6.4

➜  Sandbox python rpc_example.py
Traceback (most recent call last):
  File "rpc_example.py", line 1, in <module>
    from bitcoin.rpc import RawProxy
ModuleNotFoundError: No module named 'bitcoin'

How are you running the script? Can you post the full output of it? Can you also post the output of python --version and pip --version?

@AndrewChow here's what I'm getting: https://gist.github.com/glaksmono/df45548521901b89c5fc662c2a837e03

You are using a version of pip with a different version of Python. You are using Python 3 but your pip is for Python 2. Thus anything that pip installs will not be available to your Python which is why it cannot find the correct library. You will need to do pip3 install python-bitcoinlib in order to install the library for your python version.

Shouldn't we use python 2?


text:
Electrum is not listing "unconfirmed transcation" in History tab after 4 days. Can I send new transactions?
I am using Electrum(2.6.4) and has an unconfirmed transaction from last 4 days. I tried viaBtc accelerator as well in these days. Yesterday, I stopped my Electrum wallet in my PC and restarted after several hours. It connected to the network and hurray... I don't see the unconfirmed transaction listed. I thought it was removed from memory pool and bitcoins deposited back to my wallet. But today morning when I started Electrum wallet it shows the unconfirmed transaction again :(
So, I believe I can't depend on Electrum to confirm if the transaction is removed from the memory pool. Hence, can someone please confirm how can we check if the transaction has been forgotten from blockchain memory pools?
Transaction ID - https://tradeblock.com/bitcoin/tx/1bd51d7aad1635001799918144c9dedeb6e71b56bef65c4e975cd8a5eb306632
Thanks!

Hope someone helps:(

Bitcoin transactions never expire. Because of this, anyone on the network can store your transaction and rebroadcast it any time they like.
Bitcoin Core will remove unconfirmed transactions that have been around for more than 48 hours, but anyone on the network can re-add it.
To answer your second question, you can send another transaction.

You can try an online Bitcoin blockchain explorer, such as:

https://blockchain.info/unconfirmed-transactions
https://tradeblock.com/bitcoin/explorer/

search your transaction and see if you can find it there!

I checked these blockchain explorers and I see 1st one shows it https://blockchain.info/tx/1bd51d7aad1635001799918144c9dedeb6e71b56bef65c4e975cd8a5eb306632 and the second one says "This transaction is unknown" https://btc.blockr.io/tx/info/1bd51d7aad1635001799918144c9dedeb6e71b56bef65c4e975cd8a5eb306632.

And my Electrum wallet doesn't list this transaction after restarting it after some hours..

your tx is still unconfirmed and in the mempool. You chose a very low tx fee, so that's why.

As my Electrum is not listing this unconfirmed transaction now, is it safe to send new transactions with higher fees? Will it end up making things more complicated?

the wallet records may not be up-to-date for various reasons, popular online explorers are almost always reliable. here's your tx on tradeblock : https://tradeblock.com/bitcoin/tx/1bd51d7aad1635001799918144c9dedeb6e71b56bef65c4e975cd8a5eb306632

sure, send with higher transaction fee and it will get to the next block way sooner. so you're set to go. choose a reasonable  tx fee from here : https://bitcoinfees.21.co/

Are you sure?? Sorry, am really afraid of these bitcoins transactions and am a newbee to this. So, as this particular trnasaction is still shown in explorers, is it safe to send new ones from Electrum?

Let us continue this discussion in chat.


text:
How is a locking script reliably detected as a P2PKH script?
I've taken this example from a p2pkh guide:
1976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac

This is broken down into:
19 - byte length of the following unlocking script
76 - OP_DUP: Duplicates the top stack item.
a9 - OP_HASH160: The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
14 - (20 bytes) length of the following public key hash
5fb0e9755a3424efd2ba0587d20b1e98ee29814a - public key hash of funds receiver
88 - OP_EQUALVERIFY: Returns 1 if the inputs are exactly equal, 0 otherwise. Then runs OP_VERIFY which fails and marks the transaction as invalid of the top stack value is false
ac - OP_CHECKSIG: The entire transaction's outputs, inputs, and script are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise

How does Bitcoin determine that 0x14 is the length of the following public key hash, rather than interpreting this byte as an opcode with the value 0x14 (20 decimal)? Is 0x14 special and will never be assigned to any opcode? I don't see any special handling of this value in the CScript::HasValidOps() and GetScriptOp() routines here.
Is there a magic marker to detect P2PKH scripts?

The secret is that it is being interpreted as an opcode.
Opcodes 0x01 through 0x4b (decimal 1 to 75) are opcodes that specify the length of the data being pushed after them, as their own numerical value. That is to say, 0x01 means it is followed by 1 byte of data, 0x02 means 2 bytes, and so on.
This lets you push up to 75 bytes of data using a single op code to specify the length.
Additionally, we also have 0x4c, 0x4d, and 0x4e. These specify:
0x4c - The next byte specifies the length of the data
0x4d - The next two bytes specify the length of the data in little endian order
0x4e - The next four bytes specify the length of the data in little endian order
Between these opcodes, you can push up to 4294967296 bytes of data via 0x4e. Unfortunately, you'll run out of block space a little bit before that, so I would advise against it.

The OP codes are there for bigger data sizes but you can't push anything bigger then 520 bytes to the stack.

Ah I see. So if we need more than 75 bytes we can use one of the OP_PUSHDATA1, OP_PUSHDATA2, or OP_PUSHDATA3 opcodes. Thanks a lot!


text:
RPC Batch call abruptly stopped working
I've had this code that was working less than a week ago. No changes at all on my PC or in the code and it just abruptly stopped working
normal (single) RPC calls work fine but batch does not.
All firewalls are off, no virus protection so can rule those out. Nothing changed w/ port forwarding and I see both inbound/outbound traffic on my node. I've restarted the PC, restarted bitcoin core (as admin too)
commands = [["getblockhash", height] for height in range(0, 100000)]
            block_hashes = rpc_connection.batch_(commands)

I don't understand why the single RPC calls are working fine but the batch is not

Ok, so after some very painful debugging, I've figured out the problem. I don't quite understand why but I've resolved it for now.
There's an upper limit to the number of rpc batch requests you can make through AuthProxy.batch_(). The exact number (at least for getblockhash) is 420819. What the significance of this number is, I'm not really sure. Maybe it's a bitcoinlib issue, maybe it's a bitcoin core issue, it might be a networking sockets issue.
I'll figure out the root cause eventually but I'll have to rewrite my code to get around this limitation.


text:
How to find the secp256k1 api?
I want to use the secp256k1 library https://github.com/bitcoin-core/secp256k1 (or, more specifically I want to use the python wrapper https://github.com/electrumsv/electrumsv-secp256k1).
I have a pretty basic question - how do I find the api for secp256k1? I wanted to reimplement generating a public key using the library.

The API for libsecp256k1, including documentation can be found in its include/ directory, see this link.
The Python wrapper you link to I have no idea about.


text:
Is there a way to create a timelocked mulstisig wallet from bitcoin-cli
So, I read that with the new taproot upgrade, now there is a possibility to reduce the number of signatures necessary to create a valid transaction in a multisig wallet.
For example, create a 3-5 wallet that after 100,000 blocks "downgrades" to a 2-5.
Is this possible to do with bitcoin-cli now? Or do we have to wait until November?
If it is, how can I do it.
Thanks a lot and sorry for the noob question

So, I read that with the new taproot upgrade, now there is a possibility to reduce the number of signatures necessary to create a valid transaction in a multisig wallet.

That would be using MuSig, a multisignature protocol that uses Schnorr signatures (included within the Taproot upgrade). MuSig2 still needs to be standardized and probably won't be supported in Bitcoin Core in November 2021 when Taproot activates.

For example, create a 3-5 wallet that after 100,000 blocks "downgrades" to a 2-5. Is this possible to do with bitcoin-cli now? Or do we have to wait until November?

You cannot create arbitrary scripts with bitcoin-cli today and won't be able to in November (I suspect). You can create the script yourself and import it into a wallet using importmulti. See Kalle Alm's btcdeb project or Miniscript for constructing arbitrary scripts.

Even if you manage to create such a script and import it, you cannot do more than watch fixed addresses. Derivation of addresses and (cooperation on) signing with them requires actual wallet support, which will likely only appear if and when Miniscript gets integrated into Bitcoin Core.


text:
What are main advantages of Bitcoin over Monero?
In the world of full spectrum surveillance, since some time it has become more than evident that Bitcoin isn’t that anonymous at all. All transactions can be traced on the blockchain. There is a certain probability that this data can be handed over to big brother governments upon request, and your commercial connections with certain people, products or online services -- would be easily revealed.
Some of the bitcoin blockchain monitoring companies do deanonymize bitcoin users and their commercial activities.
So, what would be the main advantage of Bitcoin over Monero?

So, what would be the main advantage of Bitcoin over Monero?

Bitcoin is more scalable. Monero inherently requires every full node to maintain an ever-growing database of spent outputs, and is many times slower to validate transactions for. Bitcoin uses a UTXO set whose size is proportional to the number of coins currently in circulation, not its history. Longer term, I believe this means Monero's technology wouldn't be able to sustain the amount of usage Bitcoin sees without seriously hurting its decentralized properties.
Bitcoin has a larger ecosystem. Currencies - especially worldwide currencies - show a strong network effect: nobody wants a currency that nobody wants/uses. In the long term, I expect that this will result in just one or a few cryptocurrencies, and Bitcoin has a much better change being one of those.
Bitcoin is less of an experiment. Monero has planned hard forks twice a year, determined by a rather centralized group of developers. This allows them to evolve much faster, but also means it's hard to consider it a decentralized currency (AFAIK even their developers will say this). For example, a government would likely have far less difficulty to force certain changes into Monero than in Bitcoin due to an ecosystem that is just much less eager to follow one group.
Bitcoin has more hashpower. Bitcoin is less vulnerable to a 51% attack than any other (decentralized) cryptocurrency.

In general, I see Monero as a research project to experiment with better privacy technology, not as a currency in its own right. However, that does not mean the  technology being developed there can't benefit Bitcoin or its users.
Bitcoin absolutely needs better privacy. And I believe it will get it too - partially due to better technology, and partially due to better practices.
Bitcoin is naturally slow to adopt changes, but improvements are continuously being worked on (search for things like MAST, TumbleBit, Layer-2 payments, Taproot, signature aggregation, scriptless scripts, confidential transactions, ...). Do I expect Bitcoin to one day have better privacy than what is possible with Monero's technology today? Probably. Do I expect Bitcoin to have better privacy than what is possible with research technology at the time? Probably not. And that is fine.

No personally identifiable information is stored on the Bitcoin blockchain. It is true that there are some speculative methods that may identify the originating IP of a Bitcoin transaction but, those use an educated guess method and are unreliable - particularly if a node connects to the Bitcoin network using Tor then the educated guess method is unusable in determining the originating IP.
In a broad sense, the issue of privacy is universal. If you purchase goods or services online you must ordinarily provide a name and often a delivery address. If you purchase in store this may not be necessary. If the merchant shares the information that they have about a transaction (or is forced to hand it over to a government) then with payment details the details can be mapped to a set of utxo's on the blockchain which funded your purchase transaction, and any change address. This is terrible for privacy.
As I understand it this situation is improved with Monero by the use of stealth addresses, nonetheless, the details that are retained can still be handed over.
For myself, I see the privacy concerns of Bitcoin as a non-issue - just use Tor. You cannot avoid informing a merchant of information necessary to complete a purchase. Pieter Wuille has a more academic view and states:

Tor does not hide account linkage or amounts. Without very proactive measures anyone you interact with can probably make a reasonable guess how much money is in your wallet (by distinguishing change from payments), what software you are using, and with further analyses what sites you interact with. All of these are terrible properties for a currency, threatening its fungibility. Note that privacy is always optional - even when using stealth addresses or confidential transactions, you can prove to anyone what your balance or transactions are. It just becomes opt-in rather than opt-out. – Pieter Wuille

Whilst I can appreciate how such linkages are mapped, it is beyond my comprehension how such linkages are useful if Tor is utilised since without an originating IP it seems speculative to link further transactions over those immediately attached to a particular transaction into the available information set, I do not think it is useful, nonetheless, I will take Pieter at his word.
This answer has been edited in view of the discussion by Pieter Wuille in the comments.

I disagree with everything you're stating here. Bitcoin has advantages due to better scalability, larger ecosystem, more conservative security, and better long-term prospects as a result. However, its privacy properties are suboptimal, and they need and hopefully will be improved over time. There is no need to downplay these issues.

@PieterWuille I do not disagree with anything that you comment, the question is about surveillance (and intelligence gathering). Do you not agree that the answer is accurate for that as it currently stands?

Your answer seems to argue that Bitcoin's weaker privacy is a good thing. I think that is completely wrong.. Bitcoin has advantages, but the things you list aren't.

@PieterWuille I am not ashamed to admit that you know the cryptocurrency ecosystem and the applications far better than I do. I see the current privacy question as a non-issue (just use Tor), everything else is public knowledge on the blockchain apart from what a merchant may share, and whatever you make of it you do not have the individual any more than that without their IP. Albeit that there is still room for significant future improvements - many of which, as you noted in your answer, are in the pipeline. Future enhancements, I presume, move to obfuscate the record on the blockchain?

Tor does not hide account linkage or amounts. Without very proactive measures anyone you interact with can probably make a reasonable guess how much money is in your wallet (by distinguishing change from payments), what software you are using, and with further analyses what sites you interact with. All of these are terrible properties for a currency, threatening its fungibility. Note that privacy is always optional - even when using stealth addresses or confidential transactions, you can prove to anyone what your balance or transactions are. It just becomes opt-in rather than opt-out.


text:
How to make cryptocurrency easier for law enforcement?
I am researching the topic of cryptocurrency and its impact on society.
It's often said that cryptocurrency is equivalent to cash, but that is clearly not true since cash is very difficult to transport in large quantities over borders and usually requires physical presence to conduct a trade. It is also said that Bitcoin is not anonymous since the transactions can be tracked. However, in reality, its pseudo-anonymity can easily translate to true anonymity when a good laundry service is employed. Thus, cryptocurrency can and does open new avenues for criminals, such as making it much easier to transport and launder the proceeds of crime, facilitating bribery and blackmail by reducing their risks, and many of the bad things cash is associated with since money has always been a central element in crime.
Regardless of what you think of this from a political point of view (and I expect that many in this community don't see a problem with it), I think there is an interesting technical question here:
Is it possible to design a cryptocurrency that achieves a compromise between the relatively strong pseudo-anonymity of Bitcoin and the classic banking system that is disastrous to personal privacy?
Ideally, we should design a system that keeps as much as possible of Bitcoin's strong privacy protection and other desirable features such as decentralization, but at the same time, allows law enforcement to track anti-social actors like the classic banking system allows.
So, I'm asking for ideas of about how to get the best of both worlds. The network should work in a high privacy mode by default, and when the need arises, law enforcement should be able to reduce the privacy in a very visible way, for example by requesting the collaboration of other users. There should be no backdoor, no way to deanonymize the whole network in a surreptitious way like the NSA is doing by tapping all SWIFT traffic.
Therefore, the definition of "law enforcement" is not a magic attribute or key stored by the network, rather it's implicit: the party who can convince nodes to collaborate to deanonymize other nodes.
Additionally, it would be desirable to prevent anonymous laundry services while keeping the network open to join like Bitcoin, without the classic KYC routine of banks. This seems like a contradiction (Sybil attack) but maybe some compromise exists, so your thoughts are much appreciated.

At the moment I have the impression that the market isn't deep enough for serious money laundering, but that aside excellent question. Also, law enforcement could already ask for collaboration to identify transactions. I'm certain this is already happening at a web wallet and exchange level, but obviously cannot be enforced on a user level. With further developments, police could publish "addresses and transactions of interest" similar to putting out mug shots requesting information about the depicted. I'm curious what answers this will get!

It is possible to mitigate criminal elements in existing cryptocurrency networks within the current regulation framework.

Addresses of results of criminal actions are well known. Think stolen Bitstamp funds. Eventually these are written to police reports somewhere.
Exchanges, and other respected corporations, should act as a gatekeepers in this community off their own interest. Authorities of financial institutions have a duty to report crime (Misprision of felony).
If any exchange process transaction that has gone through a blacklisted address, the transaction should be stopped and the actor should go through anti-money laundering process, because they have somehow got criminal assets in their hands. There should be a paper trail to follow. If exchanges do not do this then they should be themselves subject to money laundering investigation due to breaking local AML and KYC regulation.
Tracking back Bitcoin transactions to blacklisted addresses is technically very feasible, because all transactions are public and it is just matter of maintaining a tree of transactions in computer memory. It doesn't matter how many times you tumble your coins, because you simply can't eliminate the trace of transactions from blockchain.
This assumes there is a party (Interpol, FBI) who maintains and enforces a known black list of addresses. The list should be publicly available for anybody. The list contains addresses compiled from police reports world wide. Currently no no such party exist. All parties in global trusted police consortium should be able to add addresses on this list with reference back to a local police report.
Fungibility, as promoted by some Bitcoin advocates, does not exist. You simply can't say "I don't know where my money is coming from." to government officials. Banks and financial institutions like PayPal are already subject to this regulation.

This way the system would be opaque to every day transactions (think a transaction of hiring divorce lawyer, medical bills) but still having a mechanism to track down criminals.

If such a list would exist, there would be an inevitable administrative and technical delay in adding addresses on it. An anonymous launder service can  sever the link between the source and the destination in a few minutes or hours. So the coins would turn black while in the possession of another user of the laundry service who might in turn have spent them in a store. Law enforcement needs to traverse this graph back to the launderer who is likely a clandestine operation that will not have any information about the original owner of the coins.

So the whole scheme is predicated on the idea that people would avoid laundry services, or maybe that it was highly illegal to use one - such a restriction does not exist in the current framework, the second user can simply say he used the service for privacy and was not aware he would receive illegal funds. It's a good answer but I would like something more efficient than changing the laws of all countries.

Your comment seems to be missing something. ". So the coins would turn black while in the possession of another user of the laundry service who might in turn have spent them in a store." <-- Then we have a paper trail back how this person got hold of the coins. Also I am pretty sure no change of regulation is required which I tried to highlight in the answer.

Furthermore, whether some action is criminal or not is always decided retroactively, so you are right we need to traverse back.

Also saying he was not aware that he/she will receive illegal funds when laundering coins is not a defense if the amount of money involved exceeds a certain threshold (notably sums). The fact that you are not aware of money laundering laws doesn't mean you can break them. Trying to obfuscate the source of money might be interpreted as money laundering, though it is not this by definition!

Also if you are running "clandestine operation" where you lose the information of the original owner of coins then you are breaking anti money laundering regulation.

What you describe is a great success from the perspective of the original criminal: diverting the paper trail to hundreds of individuals spread all over the world who will all claim innocence, with the burden on LEO to prove they even used a laundry service and are not simple bystanders. Of course, the laundry is illegal (and untraceable) but it's users will not get more than a slap on the wrist for using it because law enforcement will only be able to prove small sums were received, if any. This is insufficient from dissuading them to use such services, thus allowing them to operate.

@Brainwallet: You are right. Currently there is unlikely that you get caught. Furthermore as long as dollars and euros flow in and back to Easter European exchanges like BTC-E, I am not sure if anything can be done.


text:
Python code error : Hash greater than Target
While trying to run a reference code from GitHUb i am getting an error "Cannot Mine-Hash is greater than Target". As i am just a beginner with coding i am not able to figure this out. Kindly help me to fix this
The code is here.
Any help regarding the same is highly appreciated. Thank you

This is entirely expected. The code you link to performs exactly 1 hash attempt. In case the obtained hash does not satsisfy the miner's share difficulty, you will get this error.

Python code error : Hash greater than Target

It's not an error, it is a genuine result from a piece of educational or artistic software. It isn't intended to be a useful piece of software for actual mining.

According to https://github.com/muimota/miniminer

The objetive of this projects is to write the simplest miner ever to be embeded in different art projects.

So this is art, not really a serious project for any other purpose. Although I guess it does provide an educational example of how to interact with a mining pool.
As Pieter Wuille noted in a comment, It chooses just one random nonce and calculates a hash and tests to see if it succeeded in finding a hash lower than the target set by the mining pool.
Normally, for real mining, you'd maybe need to run the inner part of this (excluding pool communication) trillions of times every second so that trillions of different nonce values are tested every second. Obviously you can't achieve that rate using python, especially when using only standard PC hardware.
(community wiki, since this answer doesn't add much to the existing comments)

Thank you for flashing light on the issue RedGrittyBrick. As i am just a beginner with Python and Blockchain need to educate myself more. I am so glad you guys are taking even small issues on a serious note. Thank you. @Pieter Wuille


text:
Why is block 679115 empty?
This block is completely empty (except the coinbase transaction). Why would a miner want to discard the fees it can take from transactions? I know it's possible that a miner mine an empty block. But I can't understand the rational behind it. Like this question was asked before here. But that does not answer my question.
The only possible scenario that I can think of, is that miner was trying to update it's UTXO set and mempool and it can take a few seconds, and miner conservatively choose to mine an empty block (because if he choose conflicting transaction, and succeed to mine, all his efforts are wasted). Is it right? Or there's any other scenario that can cause a miner forcibly mine empty blocks?

Without speaking to the mining pool we are entirely in the realm of speculation so there isn't much to add on top of the linked question. If I had to guess it is just incompetence. Even if you started trying to mine an empty block there's no reason not to switch to mining a non-empty block once you've verified a set of fee paying transactions. The memoryless property of Poisson processes ensures that continuing on the empty block is no more advantageous than switching and starting from scratch on a non-empty block that offers a greater total block reward (including transaction fees).

Note that it's mined just 19 seconds after the previous block is mined. So there may be not adequate time to create a non-empty block.

@AmirrezaRiahi: That should be enough time to add some high fee transactions and start mining a block with those transactions in. The longest time for verifying a transaction afaik is 25 seconds though so maybe not :) https://rusty.ozlabs.org/?p=522

The longest time to verify a transaction is 25 seconds, but doesn't updating mempool and UTXO set take more time in some special cases?

@AmirrezaRiahi: A negligible time, yes. Not comparable to verification time though, that takes up the lion share of time. Maybe it would even make sense to include an outlier high fee transaction in a block when mining before you've fully verified it, take the punt on it being a valid transaction and remove it if it turns out not be a valid transaction. Depends on how commonly you'd encounter invalid transactions with very high fees.

From a miner's perspective, if you solve a first then secondary block solution before you have any transactions in that second one it is probably more profitable for you to submit both of the block solutions you have. If you take the chance and add more transactions after finding a solution, you would need to throw the empty block solution away there is no guarantee that you will be able to solve and propagate it in time.

@Amir When calculating 19 seconds since prior transactions are you assuming that block timestamps are more accurate than 1-2 hours?


text:
Is the contest period really necessary for cross-chain transactions in 2-way-peg sidechains?
According to the first sidechain article (Link), the cross chain transaction process can be briefly describe as follows:

Alice has a wallet on sidechain S1. She wants to send some coins to sidechain S2. So she makes a transaction containing some coins, send it to a certain locked-output on S1.
Wait for confirmation period to end.
After the transaction is confirmed, she submits a SPV proof to S2.
Again, she has to wait for a contest period.
After the contest period ends, an equivalent amount of coins is created and sent to her wallet on S2.

I assume that both the sidechains are secure, otherwise there is not much left to discuss. If they are secure,  then after the confirmation period in step 2 above, the sidechain S2 already knows that the transaction is confirmed on sidechain S1. For example, if Alice purchases something using Bitcoins, step 3 is where she can get the product she purchased from a normal store.
In my opinion, after the confirmation period, the transaction is already in a stable part of S1. Thus, there cannot be any valid SPV proof that contradicts the SPV proof Alice sent, unless S1 does not satisfy the persistence property.
Therfore, I would like to ask, why is the contest period necessary? Is there something I am missing in my argument? Thank you.

she submits a SPV proof to S2.

The way this worked in the first implementation of the sidechains paper by the same authors (called Elements Alpha, now elements) is as follows: The genesis block of the sidechain S2 creates a bunch of outputs with a new opcode OP_WPV that can be spent with an SPV proof showing that some amount on S1 has been "sent to a certain-locked output". Note that S2 follows the UTXO model of Bitcoin and there's no global state that OP_WPV could look up. That means that it's possible to provide exactly the same SPV proof to another OP_WPV locked output and effectively transfer your coins from S1 twice. That's why there needs to be a contest period where honest nodes have the opportunity to provide a fraud proof and lock the coins back into the OP_WPV.

Now if there needs to be a contest period anyway, we can make the confirmation period shorter than what we would assume to be secure against reorgs. Instead, the contest period is used to provide a window for reorganization proofs.
You can find more information about how this mechanism worked in this article: https://github.com/jonasnick/elementsproject.github.io/blob/master/source/_posts/The-Federated-Peg-in-Elements-Alpha.md.


text:
persistence of the RBF bit in post-fullrbf chain
In case consensus decided to ignore pro-zeroconf nodes (in case that is or can be a thing),
then what's the point of having the RBF bit in a transaction, if everything in the system is enforcing RBF (either explicitly or implicitly)?
Would the RBF bit be then set for removal in a subsequent soft fork?
And if that were the case, why not remove it the first moment pro-zeroconf nodes are ignored?
I'm using "ignore" instead of "ban" because I suppose pro-zeroconf would be policy instead of consensus.

What is a "pro-zeroconf" node? A node that implements the BIP125 relay policy? A node that does not permit any transaction to be replaced? Something else?

I can't tell, after rereading BIP 125. RBF-FSS is still a thing, I guess. Then I tried thinking about nodes banning blocks because mempool features instead of because consensus, and I can't figure how could this be done without risking censorship resistance.

RBF-FSS is something else, much older, and unrelated to fullrbf or BIP125. You're inventing the term "pro-zeroconf" here; I'm just asking what you mean by that.

I don't know anymore.

From BIP 125:

A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).

The nSequence in a transaction is used for other things including locktimes so it is unlikely to ever be removed entirely.

In case consensus decided to ignore pro-zeroconf nodes (in case that is or can be a thing),
then what's the point of having the RBF bit in a transaction, if everything in the system is enforcing RBF (either explicitly or implicitly)?

"Ignoring pro zeroconf nodes" doesn't make much sense unless they are attempting to change the consensus rules or seeking to reject blocks with replace-by-fee transactions in them. In that case we would be in consensus rule "war" territory like with the block size wars but that would be a very strange route to take given altcoins like BCH already exist which aren't seeking to scale off-chain and are perhaps more open to prioritizing the zero conf use case. It is possible full nodes could preferentially peer with other nodes who have the -mempoolfullrbf option turned on in future. However, in the Bitcoin Core 24.0 release it is off by default and there is no preferential peering based on this issue.

Would the RBF bit be then set for removal in a subsequent soft fork?

It wouldn't need a soft fork or a consensus change to simply ignore the transaction signaling for RBF by default in a Bitcoin implementation like Bitcoin Core. I very much doubt Bitcoin Core would ever make RBF a consensus issue, it is a mempool policy issue. It is possible Bitcoin Core could change policy defaults and policy options available to users in future. This is pure speculation of course though, I don't know what will happen in the future and no one can speak for Bitcoin Core, certainly not me.

And if that were the case, why not remove it the first moment pro-zeroconf nodes are ignored?

It is possible the default for the -mempoolfullrbf option could be changed in future and it is also possible the -mempoolfullrbf option could be removed in future. As I said, we're moving into speculating future changes in Bitcoin Core releases. Any future change would need to have a pull request opened, reviewed, merged and included in a release. As you stated this is in the realm of policy and not consensus so I highly doubt this would be relevant to a future soft fork but I guess there is a speculative element to that too as I can't envisage every possible future soft fork design.

Good answer. I think that one thing that would align well with the question post would be to get into what the default value for nSequence could be if fullrbf is widely adopted on the network.

@Murch: Good question. I'd say the default nSequence wouldn't change if Core changed the default to -mempoolfullrbf=1 or even if Core did that and got rid of the option entirely. At least theoretically some other implementation(s) might still require RBF signaling to accept a transaction into their mempool. So unless there was a reason to change the default nSequence you'd leave it as is so those theoretical implementations also accepted the transaction into their mempool? Agree?


text:
E-commerce invoice in USD & receive payment in Bitcoin
Is there an e-commerce plug-in or payment processing platform that facilitates the sequence detailed below?

Merchant accepts customer's online order
Customer's credit card is charged accordingly
The dollar amount of credit card charge is:

Converted into bitcoin; *or*
Used to purchase the equivalent amount of bitcoins;

Value of customer's order (in bitcoin) posts to Merchant account
The customer receives the invoice in USD

credit card payments are reversible and bitcoins aren't. So any such service, if exists, would die very soon from fraud.

Coinvoice lets you invoice in USD and get paid in bitcoin. Sorry if you need the exact workflow described above. I'm not aware of many services that sell bitcoin and take credit card for payment.

Blockonomics lets you invoice in any currency get paid in bitcoin. No signups and directly into your wallet.

Lamium is a first decentralized bitcoin invoice payment service which allows you:

Merchant accepts customer's online order
Customer's credit card is charged accordingly
The dollar amount of credit card charge is converted into bit coin
The charge is used to purchase the equivalent in bit coins
Value of customer's order (in bit coin) posts to Merchant account
Customer receives invoice in USD


text:
explore sqlite wallet
I created an sqlite wallet, tried to browse it from the sqlite3 program, but had to reset (tset) the terminal after querying the main table garbled the console characters. How to query the main table while protecting the terminal?

The data stored is binary data, which is why it comes out garbled. It is not text. So you will have to convert the data to something human readable. One such method is to convert it to hex. One such query to do that is:
select hex(key), hex(value) from main;


text:
What's not standard in these descriptors?
In here, about these (indentation is mine):
sh(wsh(multi(2, abcdef01/1'/1'/0/*, 23456789/1'/1'/0/*)))#abcdefgh
sh(wsh(multi(2, abcdef01/1'/1'/1/*, 23456789/1'/1'/1/*)))#ijklmnop
   wsh(multi(2, abcdef01/1'/1'/0/*, 23456789/1'/1'/0/*)) #qrstuvwx
   wsh(multi(2, abcdef01/1'/1'/1/*, 23456789/1'/1'/1/*)) #yz012345
       tr(musig(abcdef01/1'/1'/0/*, 23456789/1'/1'/0/*)) #67890abc
       tr(musig(abcdef01/1'/1'/1/*, 23456789/1'/1'/1/*)) #defghijk

WALLET tells:

Output descriptors are part of a developing standard for Recovery that WALLET_PROVIDER intends to support and is helping grow. Since the standard is in a very early stage, the list above includes some non-standard elements.
When descriptors reach a more mature stage, youʼll be able to take your funds from one wallet to another with complete independence. WALLET_PROVIDER believes this freedom is at the core of Bitcoinʼs promise, and is working towards that goal.

The "musig" descriptor function has not been standardized.
These descriptors also don't seem to contain valid key expressions (which need to be hex pubkeys, hex x-only pubkeys, xpubs, xprvs, or WIF keys, possibly combined with origin information or derivation paths).
Also, descriptors currently don't permit spaces inside.

I also know a secret passphrase and have a couple very large public strings (printed in the same instructions). Maybe they combine those small strings with the former to create the actual key expressions.

I suspect these small strings are just key fingerprints, which the application uses to look up in a database for actual keys.


text:
Why can't Core CLI query wallet balance when loading block index or verifying blocks?
Why can't Core CLI query wallet balance until having loaded block index and verified blocks? It takes a few moments when running the test and sig nets, but when running the main net it is tough for my ages ancient hardware and takes many seconds. Sometimes it is a bit inconvenient. Shouldn't both loads be parallel?

The wallet needs access to the chainstate for normal operation, and that needs access to the block index. So the wallet requires a chainstate in its constructor, and the object managing the chainstate is not available until after the block index has been loaded and the sanity checks completed. There are several places within the wallet which assume that the chainstate is available.
Additionally, there are many RPCs which need access to the chainstate and other node objects, and the general assumption with these RPCs is that those objects are available (they tend to be globals). So to avoid any issues with objects not being initialized yet, the RPC server will block all RPC calls until initialization is complete so that those objects are guaranteed to be initialized.
This probably could be changed to not block, however such a project would be likely be pretty big and require significant changes to the assumptions around global objects. As with all open source projects, the reason this has not been done is because no one has bothered to do it.


text:
Check if multiple signatures match a specific public key
Suppose you have a company which has three main leaders called A, B and C also the company have 5 shareholders called S1 to S5. The decision rule for spending any coin from company's address is to either we present 1 of the main leaders signature and three other signature from shareholders.
For example following unlocking script works (since it contains one of the leaders):
<sig_S1> <sig_A> <sig_S2> <sig_S5>

but not this one:
<sig_S1> <sig_S4> <sig_S3> <sig_S5>

How I can check if amongst multi signatures there exist a signature which corresponds to a specific public key, in this case, I will learn that a leader's signature surely exists. for example, if we find out from 5 signatures provided the signature of A exists, and the locking code will look like follows:
(3 times duplicate of all signatures provided)
(check for the existence of A in signatures)
OP_IF
   4 <pub_A> <pub_S1> <pub_S2> ... <pub_S5> 5 OP_CHECKMULTISIG
OP_ENDIF
(the same as above for B)
(the same as above for C)

I believe it could work with a RedeemScript like this (haven't tested the scripts):
OP_IF
  3 <pub_A><pub_B><pub_C> 3 OP_CheckMultiSig
OP_ELSE
  1 <pub_A><pub_B><pub_C> 3 OP_CheckMultiSigVerify
  4 <pub_S1><pub_S2><pub_S3><pub_S4><pub_S5> 5 OP_CheckMultiSig

Explanation: The redeem script has two parts:
- OP_IF: this part could be removed, it is there to allow the "leaders" to spend the funds without needing the "shareholders" signatures. Depending on the purpose it could be removed (remove first 3 lines of RedeemScript and signature doesn't require OP_TRUE/OP_FALSE in it).
- OP_ELSE: this provides what you need with 2 multi-signature operations. The first one requires at least one signature out of 3 "leaders" signatures and performs a OP_CheckMultiSigVerify (there is no true/false remaining on the stack after the execution) and the second one requires 4 of 5 signatures from "shareholders".
To spend, either one of these signature scripts should be provided (OP_0 is mandatory due to the bug in CheckMultiSig OPs):
OP_0 <sig_A><sig_B><sig_C> OP_TRUE <RedeemScript>

or
OP_0 <sig_S1><sig_S2><sig_S4><sig_S5> OP_0 <sig_A or B or C> OP_FALSE <RedeemScript>

How about first checking with  all the public key of shareholders with checkmultisig, if the result was true we know that in signatures provided there is not exist either of leaders, if that was not true we could check for 4 s1, s2, .. ,s5, a, b, c 8 checkmultisig.

That would require each shareholder to sign the transaction twice, it also increases the size of the signature (and transaction) by a lot.

Instead of twice signature, we could duplicate it in the lucking script.


text:
Security risks with running bitcoin core, and how to protect yourself
I'm new to bitcoin and want to help the network by running a full node. I plan to download bitcoin core from the bitcoin.org website, and run it on a spare laptop, by my concern is how do I protect my machine from attack? As I understand it, my IP address will be visible to see. Do I install specific security software or are there other practical steps for me to take?
I would appreciate it if answers can be made in simple, and if possible not overtly technical terms as I'm new to all of this.
Many thanks.

How do I protect my machine from attack?

The most important thing is to download Bitcoin Core from the correct destination. You can download it from bitcoincore.org or the source code can be found on the Bitcoin Core GitHub repo. If you download it from a malicious party's destination you could have serious problems. Luke Dashjr has a blog post on the extra precautions you could follow to make sure you are installing the correct software but this may be a challenge for you if you aren't technical.

Do I install specific security software?

No there is no specific security software to install. Depending on your operating system some may recommend an antivirus software but that is general security hygiene not specific to Bitcoin.

As I understand it, my IP address will be visible to see.

Yes your IP address will be visible to peers that you connect to unless you use Tor. (Tor is recommended if privacy is especially important to you.) However, if you choose to use a clearnet node and you don't want your IP address to show up on sites like bitnodes.io you can run a non-listening node by disabling listening. You do this by configuring with the -listen=0 flag or putting listen=0 in your config file. This way you can't be contacted by nodes you aren't directly connected to. The downside to this is that you aren't helping the network as much and you will typically have fewer connections.

If you are using Ubuntu or Debian (or any derivative) then I highly recommend the bitcoin standup scripts from blockchain commons. If you can't read shell scripts then maybe its not the best option but you can certainly learn from it and type the commands one-by-one.
I use them and they work pretty well.
You can google "github blockchaincommons bitcoin standup" and you'll find a github repository where you can download a bash script that bootstraps a bitcoin core behind tor.


text:
Do all private keys that are resolved to the same address give access to the bitcoins on this address?
The algorithm to get the public key and the address from a private key consists of a few steps.
Which of the intermediate keys is used to sign transactions with?
Ultimately, there can exist two different private keys that resolve to the same address or public key. Can both be used for signing transactions spending outputs assigned to that address?

Yes. And it's pretty easy to understand why, without even mentioning anything about the underlying technologies.
A bitcoin: URL only contains the address of the recipient. The address does not need any previous transactions in the blockchain to resolve to a public key, so we can deduct that a bitcoin URL has the full public key.
When you spend bitcoins from an address, all that is publicly known is the public key for that address. And since we just established that the address is basically the public key, we can conclude that any private key that resolves to a certain public key will have access to that address.

In other words: when you send BTC to an address, all the client knows is the address where it's going, which means that it cannot store anything else about the recipient (since it doesn't know anything else). Since only the address is stored, any private key that resolves to that address will have access to the bitcoins.

It should be pointed out that not all transactions are sent directly to an address, and there are exceptions to my logic here. But for 99% of all transactions the above applies

After a second look, I noticed that the private key -> public key translation is only a single step. Thanks for the answer anyways!