Fetch my private key I goal is to understand. I do not want to earn money with mining.
(I have a server without GPU)

Here is what i've done:

I have downloaded, maked and installed bitcoin sourcecode from github.

It seems to work because i can interact with bitcoind with bitcoin-cli command.

I know this is not a good practice but i want to "see" my private key.

I have read several documentation and tutorials and they said i need to generate an address first, then call dumpprivkey method.

Like this:

$ bitcoin-cli getnewaddress
xxxxxxx

$ bitcoin-cli dumpprivkey xxxxxxx

I do not understand but if i repeat twice this operation, i get 2 differents private keys.

So this is not the private key i am looking for... What is those privates keys ?

Thanks

Let's suppose I have lost everything except this extended master key. How can I setup a new fresh computer and retrieve all my bitcoins just with this key?

According to How to get xpub or mpk(bip32) for my bitcoin core wallet?

  you can export the xpriv with dumpwallet

According to https://bitcointalk.org/index.php?topic=3866008.0

  Bitcoin Core does not have a way to directly import [master] private keys.
  You could derive a bunch of private keys in WIF from the xpriv and import them all at once, but you can't import the xprv directly.


Get the slush stratum proxy working on a mac Title says it all - can anyone walk me through setting this up on a mac? I ran the linux python install script but i'm guessing i'm missing a few dependencies as it failed on me.

edit: there are numerous errors, listed here:

Reading http://tmrc.mit.edu/mirror/twisted/Twisted/9.0/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/9.0/: [Errno 61] Connection refused -- Some packages may not be found!
Reading http://tmrc.mit.edu/mirror/twisted/Twisted/10.0/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/10.0/: [Errno 61] Connection refused -- Some packages may not be found!
Reading http://twistedmatrix.com/projects/core/
Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/: [Errno 61] Connection refused -- Some packages may not be found!
Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/: [Errno 61] Connection refused -- Some packages may not be found!

Running Twisted-12.3.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-OQqo5N/Twisted-12.3.0/egg-dist-tmp-9vucfj
unable to execute llvm-gcc-4.2: No such file or directory
unable to execute llvm-gcc-4.2: No such file or directory
unable to execute llvm-gcc-4.2: No such file or directory
error: Setup script exited with error: command 'llvm-gcc-4.2' failed with exit status 1

So, while Mac includes python it does not include gcc by default, even once you've installed Xcode 4.2 or later. For now, grab that, go to preferences, downloads and get the command line tools.

Once a version of Xcode higher than 4.6 is out you'll have to find a new way to install gcc on your mac, as gcc will no longer be included, but I guess that's a question for another stackexchange, and likely a macports or homebrew solution.


How do I find where the BTC are sent to from a blockchain.com address page? I could see a wallet address receiving BTC easily on a blockchain.com
But it seems very hard to find out where he/she spend the BTC.
Does anyone know how to track that?
The screenshot below: the red box is the wallet address. It's always on the receiving end.

Blockchain.com is an explorer, and like most explorers, it will show any transactions that spend from that address as well. If there are no such transactions, then the received coins have not been spent yet.
Note that even if such transactions are visible, it is not guaranteed that you will be able to identify where the coins were sent. Addresses are pseudonymous, and it is not always possible to identify the owner of the addresses the coins are sent to.


Issues connecting a Bitcoin-Qt Wallet to a local node I have a bitcoin-core node running on a Raspberry Pi on my local network.   The node is publically visible and running fine (I can see it on bitnodes.21.co - it has connections and is synced to the latest block).

I have a Windows PC with a Bitcoin-Qt installation that I would like to connect only to the local node, only when I start it up it doesn't seem to connect. I'm starting it from a command line with

bitcoin-qt.exe -connect 192.168.0.6

The GUI just says "Connecting to peers" and Help > Debug shows 0 connections.

I can ping the Pi from the Windows machine and I can telnet to port 8333 on the Pi from the Windows machine, so I believe the network connectivity isn't the issue.

Any advice on how to diagnose what's going on? (RPC commands? Logs?)

Am I using the right command to connect?

It might be you need to add some lines in the bitcoin.conf file on the Raspberry Pi.  This was taken from the github repo example of the bitcoin.conf file

##############################################################
##            Quick Primer on addnode vs connect            ##
##  Let's say for instance you use addnode=4.2.2.4          ##
##  addnode will connect you to and tell you about the      ##
##    nodes connected to 4.2.2.4.  In addition it will tell ##
##    the other nodes connected to it that you exist so     ##
##    they can connect to you.                              ##
##  connect will not do the above when you 'connect' to it. ##
##    It will *only* connect you to 4.2.2.4 and no one else.##
##                                                          ##
##  So if you're behind a firewall, or have other problems  ##
##  finding nodes, add some using 'addnode'.                ##
##                                                          ##
##  If you want to stay private, use 'connect' to only      ##
##  connect to "trusted" nodes.                             ##
##                                                          ##
##  If you run multiple nodes on a LAN, there's no need for ##
##  all of them to open lots of connections.  Instead       ##
##  'connect' them all to one node that is port forwarded   ##
##  and has lots of connections.                            ##
##       Thanks goes to [Noodle] on Freenode.               ##
##############################################################

# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:8333

# Alternatively use as many connect= settings as you like to connect ONLY to specific peers
#connect=69.164.218.197
#connect=10.0.0.1:8333

# Listening mode, enabled by default except when 'connect' is being used
#listen=1

# Maximum number of inbound+outbound connections.
#maxconnections=

#
# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
#

# server=1 tells Bitcoin-Qt and bitcoind to accept JSON-RPC commands
#server=0


Logging Antminer Statuses How does one log all an Antminer's statistics (temperature, hashrate, etc.) to a file?

I can log in to an Antminer via SSH, so I should be able to turn on some option for cgminer to log everything, no?

I looked at /www/pages/cgi-bin/minerStatus.cgi, and it parses

cgminer-api -o
cgminer-api -o pools
cgminer-api -o stats


Is my cgminer (scrypt) working / Mining on middlecoin pool I'm trying to mine on the middlecoin pool using the following command:

  cgminer --scrypt -o stratum+tcp://middlecoin.com:3333 -u
  1C7Ubg5VxvJyXYBT6neNVFgUVdgq1Kiy72 -p asdf

and I do get the screen below, but I'm not seeing my bitcoin address appear on: http://www.middlecoin.com/allusers.html (and I've waited a couple of hours)

 cgminer version 3.7.2 - Started: [2014-01-31 13:03:27]
--------------------------------------------------------------------------------
 (5s):3.725K (avg):3.694Kh/s | A:0  R:0  HW:0  WU:3.4/m
 ST: 2  SS: 0  NB: 398  LW: 1943  GF: 0  RF: 0
 Connected to middlecoin.com diff 1.02K with stratum as user 1C7Ubg5VxvJyXYBT6ne
 Block: 1e7643a6...  Diff:1.17K  Started: [14:56:27]  Best share: 313
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:                | 3.703K/3.694Kh/s | A:0 R:0 HW:0 WU:3.4/m I: 8
--------------------------------------------------------------------------------

 [2014-01-31 14:51:52] Network diff set to 25
 [2014-01-31 14:51:52] Stratum from pool 0 detected new block
 [2014-01-31 14:51:56] Network diff set to 26
 [2014-01-31 14:51:56] Stratum from pool 0 detected new block
 [2014-01-31 14:52:04] Network diff set to 343
 [2014-01-31 14:52:04] Stratum from pool 0 detected new block
 [2014-01-31 14:53:46] Network diff set to 55
 [2014-01-31 14:53:46] Stratum from pool 0 detected new block
 [2014-01-31 14:54:08] Stratum from pool 0 detected new block
 [2014-01-31 14:54:32] Network diff set to 1.17K
 [2014-01-31 14:54:32] Stratum from pool 0 detected new block
 [2014-01-31 14:55:19] Stratum from pool 0 detected new block
 [2014-01-31 14:56:27] Stratum from pool 0 detected new block

When I exited, it showed :

...\cgminer-3.7.2-windows>cgminer --scrypt -o stratum+tcp://middlecoin.com:3333 -u 1C7Ubg5VxvJyXYBT6neNVFgUVdgq1Kiy72 -p asdf
 [2014-01-31 15:49:18]
Summary of runtime statistics:

 [2014-01-31 15:49:18] Started at [2014-01-31 13:03:27]
 [2014-01-31 15:49:18] Pool: stratum+tcp://middlecoin.com:3333

 [2014-01-31 15:49:18] Runtime: 2 hrs : 45 mins : 51 secs
 [2014-01-31 15:49:18] Average hashrate: 3.7 Kilohash/s
 [2014-01-31 15:49:18] Solved blocks: 0
 [2014-01-31 15:49:18] Best share difficulty: 313
 [2014-01-31 15:49:18] Share submissions: 0
 [2014-01-31 15:49:18] Accepted shares: 0
 [2014-01-31 15:49:18] Rejected shares: 0
 [2014-01-31 15:49:18] Accepted difficulty shares: 0
 [2014-01-31 15:49:18] Rejected difficulty shares: 0
 [2014-01-31 15:49:18] Hardware errors: 0
 [2014-01-31 15:49:18] Utility (accepted shares / min): 0.00/min

 [2014-01-31 15:49:18] Work Utility (diff1 shares solved / min): 3.53/min

 [2014-01-31 15:49:18] Stale submissions discarded due to new blocks: 0

 [2014-01-31 15:49:18] Unable to get work from server occasions: 0

 [2014-01-31 15:49:18] Work items generated locally: 2688
 [2014-01-31 15:49:18] Submitting work remotely delay occasions: 0

 [2014-01-31 15:49:18] New blocks detected on network: 545

 [2014-01-31 15:49:18] Summary of per device statistics:

 [2014-01-31 15:49:18] GPU0                | (5s):3.741K (avg):3.703Kh/s | A:0 R:0 HW:0 WU:3.5/m
 [2014-01-31 15:49:18]

I think your main issue is that your hash rate (speed, essentially) is extremely low. You're averaging about 3Kh/s. For comparison, most mid-range miners are running around 5-600Kh/s, and if you run a mining tool on your Google Nexus 7 tablet or Nexus 4 cell phone you can get around 2Kh/s which is very close to what you're getting.

I can't really help you with this without knowing what kind of hardware you have that you're trying to run this on, but take your video card model and search google for "cgminer settings" with your model after that to see what you can find.


running bitcoind for the first time - can't interact. keep getting command not found running ps yields:

31793 pts/0     11:04:46 bitcoind

but commands like bitcoind getblocktemplate

yields:

bash: bitcoind: command not found...

I've attempted to add the src folder to my global path through the following command:

echo " export PATH=$PATH:/home/jpc/Code/WorkingCopies/bitcoin/src" >> ~/.profile

Thanks for any help.

bitcoind is the server, you can interact with it using the command-line utility bitcoin-cli. For example:

bitcoin-cli getblocktemplate

See this question for more info.


Bitcoin rig setup, connecting a Butterfly Labs unit using USB I'm currently running a rig with seven block erupters in a 10 connector powered USB hub. After taking the USB fan into account, I have an additional two USB ports available. The host is an old laptop.

I've just purchased a Butterfly Labs 30 Ghash/s unit. What is the best way to combine this into my rig?

Can I plug it into the USB port, even though the Butterfly Labs 30 Ghash/s unit is self-powered? Otherwise, should I connect the Butterfly Lab unit directly to a USB port on the laptop? Will there be any difference?

I'm mining with CGMiner.

I don't think it will make a difference.  If you are using the Anker 10-port "power bar" style USB hub (that's what it sounds like you have, based on your description of it + the fact that this hub is very commonly used with USB bitcoin miners), that is a pretty robust hub.  One of my mining rigs (which doubles as my media center) has 8 block erupters + USB fan + an external USB hard drive on it, and all devices function without any difficulty.


Unstuck a unconfirmed transaction with Coinomi I sent a Bitcoin transaction with Coinomi android wallet. I selected the default recommended fee option. However, later I saw that it set only 0.01 USD transaction fee. My transaction is stuck in an unconfirmed state. I need the transaction to go through, it's lot of Bitcoins and I need them now. What is a step by step guide to either cancel the transaction or make it through? The address I'm using is BIP 84 Native Segwit. I tried uninstalling and reinstalling Coinomi, but that doesn't change anything after I re-enter the master seed. I didn't have luck with other wallets either. I read about double spending, but I'm not sure how to execute it. Any help?

It's generally not possible to cancel BTC transactions after they are broadcast to the network. If the transaction is valid, it can be held by miners until it's economically interesting for them to confirm the transaction (until there are no other transactions paying higher fees).
When you say "double spending", you are probably referring to a technique called "Child pays for parent" (CPFP). This involves making a new transaction spending the leftover change of the original transaction, but using a high fee. Miners can only confirm the child transaction after confirming the parent. By using high fees for the former, miners will be more incentivized into confirming the latter.
To do this in Coinomi, first check the original transaction on the block explorer. Unless you sent your full balance, you should see 2 destination addresses. One is the real destination, the other is your change. Take note of the change address (if there is no change, you can't do CPFP). Second, open your BTC wallet in Coinomi and at the top right corner of the screen select "... / Show unspent outputs". From the outputs list, select all addresses that are not your change address from the transaction and set them as "do not spend". Back to the BTC wallet in Coinomi, copy your own receive address, and make a transaction sending your full balance to it. Set "high" priority fees, or custom set a fee even higher than that if the transaction is urgent. After the new transaction confirms, reset your outputs back to spendable.
PS: Replace by fee (RBF) is a feature that allows increasing the fees of unconfirmed transactions without making a completely new transaction, and will be available in a future update.
PS2: you can contact support directly via support.coinomi.com


Finding "lost" bitcoins Bitcoins sent from Mt. Gox, but never have appeared in my account. I have the block # of the transfer.

How can I trace the deposit or find them within my account?

To look up the transaction go to blockchain.info or blockexplorer.com and type the transaction number in the search box. You will see the sender address, the destination address, the block number where the transaction was included, among other info.

Please confirm that your bitcoin client has downloaded all the blocks. You can see a number in the bottom right corner, which should match the most recent block (the current number is 153881, you can find this information in the websites I mentioned). See this question for more information.


Problems with CGMiner 4.9.2 I have tried reaching out for assistance in other Bitcoin forums, to no avail as apparently I have bought miner hardware that is not supported by the people who are responsible for CGMiner software.  While I respect that, I am struggling with support on my kit and I would really appreciate some assistance if possible.

I have a WhatsMiner M3 that runs CGMiner 4.9.2.  When it arrived, I switched it on and it had 3 mining pools already configured from the factory.  It looked like CGMiner was running and it was mining.  The device became very hot, 83 degrees I think it was and then the screaming fans seemed to slow down to a crawl.  Within a few minutes the device had cooled down significantly and the fans sped back up to full speed.  I changed the pool settings from factory to the pool information using my chosen pool and worker name for the device.  I then restarted CGMiner but it would not restart.  I then rebooted the box too but that made no difference.  The device does not get hot at all currently.

At that point I only had 1 pool setup, so I added in 3 just to be sure and tried restarting CGMiner but it still didn't work.  The power supply is fine, and the device itself seems fine and I get get into the web interface as well as connect to the device via SSH.  The only visual feedback I have is from the device overview page which gives me the following error:

EventCode: E011
EventCause: Slot-0 Zero HS 4500 Seconds
EventAction: Zero HS Warning
EventCount: 6
LastTime: Thu Dec 7 12:59:42 2017
EventSource: system-monitor

Please see these images, they describe what I am seeing:

1) The device overview where it shows that CGMiner is waiting to start:  https://drive.google.com/open?id=1c6N1YvdUHrC6pYo0L3aaPgZhwes3AP4i

2) The pool settings:  https://drive.google.com/open?id=1m0uYPcc_o-T_I2ZQ8G3M6qDk_wUVgX-2

3) The device status I get when I try start CGMiner vis SSH:  https://drive.google.com/open?id=1OHxwqlqoFGfer6qyv8VuRkrimXWtI7O6

4) The event code error as described above:  https://drive.google.com/open?id=1aYE0-RhxfB-W-eGx2AW0XKh64cvIBReQ

My concern is that the initial run where it got up to 83 degrees has broken the miner, because it doesn't get hot at all currently.  Also, because CGMiner will not start, the device shows no system status information, I cannot see temperature info, I can't see if the hashboards are okay, I can't tell at all where the proble lies.  Please could I ask someone to assist me with figuring out what it wrong with this device?  I have looked at the logs but I cannot make sense of the logs as I do not know what I am looking for.

Thank you for any assistance.

I cannot see from your screenshot, usually, the pool worker name is entered in the format userName.workerName.

Have you tried getting onto WhatsMiner support? Your question didn't say. The error message looks like it is coming from your miner actually and being reported by CGMiner. It looks like the support address for your WhatsMiner is shown in one of your screenshots.


How do virtual size, stripped size and raw size compare between legacy address formats and native segwit? This answer states that SegWit doesn't reduce transaction size.  If this is true, why is it cheaper to send a SegWit transaction?

Let's compare a 2 input and 2 output transaction for variants of pay-to-pubkeyhash. (Full data below.)

P2PKH has no witness, so raw size is equal to stripped size is equal to virtual size. A P2PKH transaction with two inputs and two outputs has 374 bytes (= 374 vBytes).

P2SH-P2WPKH (wrapped segwit) locks funds to a P2SH output in which it redirects to a witness program. A P2SH-P2WPKH transaction with two inputs and two outputs has a raw size of 496 bytes, a stripped size (removing witness data) of 226 bytes and a virtual size of 293.5 vBytes.

P2WPKH (native segwit) does not need the P2SH indirection, but directly resolves a witness program. A P2WPKH transaction with two inputs and two outputs has a raw size of 372 bytes, a stripped size of 154 bytes and a virtual size of 208.5 vBytes.

The raw size corresponds to the data footprint of the transaction on disk or the bandwidth cost to transmit it. We see that P2SH-P2WPKH is actually the biggest in raw size by a margin. P2WPKH and P2PKH are very close in data size with the legacy format P2PKH being slightly smaller in input size, but slightly bigger in output size.
The virtual size corresponds to the blockweight which determines the fees and how many transactions can fit in a block. After applying the weighing that the witness is subject to, P2WPKH has the smallest weight followed by P2SH-P2WPKH and the legacy format P2PKH counts as the heaviest.

P2PKH
TxHeader: 10 bytes, 40 WU/10 vBytes
Input: 148 bytes, 592 WU/148 vBytes
Output: 34 bytes
For legacy formats, the raw size, stripped size and virtual size are all equal.
Tx with 2 inputs and 2 outputs: 374 bytes (raw, stripped and virtual size), 1,496 WU
P2SH-P2WPKH
TxHeader: 12 bytes, 10 bytes stripped size, 2 bytes witness, 42 WU/10.5 vBytes
Input: 210 bytes, 76 bytes stripped size, 134 bytes witness, 438 WU/109.5 vBytes
Output: 32 bytes (outputs have no witness data)
Tx with 2 inputs and 2 outputs: 496 bytes raw size, 226 bytes stripped size, 1,174 WU/294 vBytes virtual size
P2WPKH¹
TxHeader: 12 bytes, 10 bytes stripped size, 2 bytes witness, 42 WU/10.5 vBytes
Input: 149 bytes, 41 bytes stripped size, 108 bytes witness, 272 WU/68 vBytes
Output: 31 bytes
Tx with 2 inputs and 2 outputs: 372 bytes, 154 bytes stripped size, 834 WU/208.5 vBytes

¹ See What is the size and weight of a P2WPKH input? for a fully detailed calculation.


How happens the serealization the data in the file blkxxxx.dat in the bitcoin I'm writing a blockchain parser for bitcoin core with C++ and now I want to enrich the data I read with the raw transaction and the previous and next block hashes.

I used this library to convert the hexadecimal to a double sha256 but now my problem is to bring the data I read into the correct format, for example, the VarInt is serialized as corresponding hexadecimal (for example 77 -> 4d).
But on some things, I don't find myself, for example in the conversion of integers of the type uint32 and int32.

I'll give you an example
The version number of the genesis block is 1 and the serialization to the correct hash is 01000000

or the conversion of the nonce of the genesis block which is 2083236893 but the correct form for the serialization is 7c2bac1d

Similarly for

NBits = 486604799 -> serialization = 1d00ffff
timestamp = 1231469665 -> serialization = 495fab29

Sorry for my terrible English but I'm learning.

______ Solution ______

Bitcoin core to use the method for serializing block, into file blk and sending data into the network, to create the hash.

Then, the hash block do create with all data into little endian form.

You are being confused three ways.

First, you need to be careful that some of your numbers in decimal, others are in hexadecimal: 77 decimal -> 4d hexadecimal (so: 77d -> 0x4d)

Second, you need to be careful that most numbers are stored in little endian notation, so 0x00000001 -> 0x01000000. Theymos' discussion why little endian is used.

Third, you have mixed up numbers from the Genesis Block and those from block 125552:

The Genesis block nonce 2083236893d converts to 0x7c2bac1d as hexadecimal not 0x42a14695.

0x42a14695 is the nonce mentioned at https://en.bitcoin.it/wiki/Block_hashing_algorithm for Block 125552, not for the Genesis block.

Similarly, Nbits 486604799d is for the Genesis block, 0xf2b9441a is for block 125552. Timestamp 1231469665d is for the Genesis block, 0xc7f5d74d is for block 125552.


Troubleshooting "access is denied" error when running cgminer I am trying to run cgminer on Windows 7.  However every time I execute the command:

cgminer --scrypt -o http://coinotron.com:3334 -u username -p pass  --thread-concurrency 8192 -I 10 -g 1 -w 256

It says access is denied.

What am I doing wrong?

You have to replace the part "-u username -p pass" with the actual username and password of your worker.
Log into coinotron and create a new worker in the "Add Worker" section. The worker will appear in the table below. Use the displayed name and password of your worker in the command and you should be fine.


How do you create a transaction from a UTXO in BitcoinJ? Is there a way to construct and send a transaction in BitcoinJ without a wallet? I just want to build my transaction from a utxo and broadcast it.

Sort of. Here's some code to get you started. It creates a transaction with one input and two outputs. One output sends some coins, another one commits some data. However, it still uses Wallet::sendCoinsOffline to complete and commit the TX, but I think you could get rid of it if you understand what Wallet::completeTx and Wallet::commitTx do.

public class App extends WalletAppKit {
    public void commitStatement(String statement) throws InsufficientMoneyException {
        Address addr = getSomeAddress();
        TransactionOutput prevLink = getSomeUtxo();
        NetworkParameters params = RegTestParams.get(); // regtest mode

        byte[] data = statement.getBytes();
        if(data.length > 80) {
            throw new RuntimeException("OP_RETURN data cannot exceed 80 bytes");
        }

        Transaction tx = new Transaction(params);

        log.trace("prevLink TX for '" + statement + "': " + prevLink.getParentTransaction());

        tx.addInput(prevLink);

        Coin feeAmt = Transaction.REFERENCE_DEFAULT_MIN_TX_FEE;
        Coin opRetAmt = Transaction.MIN_NONDUST_OUTPUT;
        Coin changeAmt = prevLink.getValue().minus(opRetAmt).minus(feeAmt);

        // 1st output: send coins
        tx.addOutput(changeAmt, addr);
        // 2nd output: commit some data
        tx.addOutput(opRetAmt, ScriptBuilder.createOpReturnScript(data));

        log.trace("TX for '" + statement + "' before SendRequest: " + tx);
        SendRequest req = SendRequest.forTx(tx);
        // Want inputs and outputs to keep their order
        req.shuffleOutputs = false;
        req.ensureMinRequiredFee = true;

        log.trace("SendRequest for '" + statement + "' before completeTx: " + req);
        wallet().sendCoinsOffline(req);

        // NOTE: At this point, the TX is saved in the wallet!
    }
}

Later edit: So here's an example of how you can modify completeTx and sendCoinsOffline. I actually had to do this today for my own purposes by subclassing the Wallet class. You probably need to take a different route than subclassing Wallet but this should give you an idea of what you need to do.

Warning: This modified code takes care of signing and paying the fee only for these special-kind of transactions with one input and two outputs. Seems to work so far as I've tested it.

public class MyWallet extends Wallet {
    private boolean payFee(Transaction tx, Coin feePerKb, boolean ensureMinRequiredFee) {
        final int size = tx.unsafeBitcoinSerialize().length;
        Coin fee = feePerKb.multiply(size).divide(1000);

        if (ensureMinRequiredFee && fee.compareTo(Transaction.REFERENCE_DEFAULT_MIN_TX_FEE) < 0)
            fee = Transaction.REFERENCE_DEFAULT_MIN_TX_FEE;

        TransactionOutput output = tx.getOutput(0);
        output.setValue(output.getValue().subtract(fee));

        return !output.isDust();
    }

    public void myCompleteTx(SendRequest req) throws InsufficientMoneyException {
        lock.lock();
        try {
            // Print the output value
            Coin value = Coin.ZERO;
            for (TransactionOutput output : req.tx.getOutputs()) {
                value = value.add(output.getValue());
            }

            log.debug("Completing send tx with {} outputs totalling {} (not including fees)",
                    req.tx.getOutputs().size(), value.toFriendlyString());

            // Check for dusty sends and the OP_RETURN limit.
            if (req.ensureMinRequiredFee && !req.emptyWallet) { // Min fee checking is handled later for emptyWallet.
                int opReturnCount = 0;
                for (TransactionOutput output : req.tx.getOutputs()) {
                    if (output.isDust())
                        throw new DustySendRequested();
                    if (output.getScriptPubKey().isOpReturn())
                        ++opReturnCount;
                }
                if (opReturnCount > 1) // Only 1 OP_RETURN per transaction allowed.
                    throw new MultipleOpReturnRequested();
            }

            // Pay for the TX fee, depending on the TX size.
            Coin feePerKb = req.feePerKb == null ? Coin.ZERO : req.feePerKb;
            if (!payFee(req.tx, feePerKb, req.ensureMinRequiredFee))
                throw new CouldNotAdjustDownwards();

            // Now sign the inputs, thus proving that we are entitled to redeem the connected outputs.
            if (req.signInputs)
                signTransaction(req);

            // Check size.
            final int size = req.tx.unsafeBitcoinSerialize().length;
            if (size > Transaction.MAX_STANDARD_TX_SIZE)
                throw new ExceededMaxTransactionSize();

            final Coin calculatedFee = req.tx.getFee();
            if (calculatedFee != null)
                log.debug("  with a fee of {}/kB, {} for {} bytes",
                        calculatedFee.multiply(1000).divide(size).toFriendlyString(), calculatedFee.toFriendlyString(),
                        size);

            // Label the transaction as being self created. We can use this later to spend its change output even before
            // the transaction is confirmed. We deliberately won't bother notifying listeners here as there's not much
            // point - the user isn't interested in a confidence transition they made themselves.
            req.tx.getConfidence().setSource(TransactionConfidence.Source.SELF);
            // Label the transaction as being a user requested payment. This can be used to render GUI wallet
            // transaction lists more appropriately, especially when the wallet starts to generate transactions itself
            // for internal purposes.
            req.tx.setPurpose(Transaction.Purpose.USER_PAYMENT);
            // Record the exchange rate that was valid when the transaction was completed.
            req.tx.setExchangeRate(req.exchangeRate);
            req.tx.setMemo(req.memo);
            //req.completed = true; // FIXME: ALIN: This field is private, can't set it to true, but thankfully this is just for debugging.
            log.debug("  completed: {}", req.tx);
        } finally {
            lock.unlock();
        }
    }

    public Transaction mySendCoinsOffline(SendRequest request) throws InsufficientMoneyException {
        lock.lock();
        try {
            myCompleteTx(request);
            commitTx(request.tx);
            return request.tx;
        } finally {
            lock.unlock();
        }
    }
}


How can I create 50,000+ bitcoin addresses in my wallet? How can I create 50,000+ bitcoin addresses in my wallet?

I will need more than 50,000+ addresses in my main wallet. I use Bitcoin Armory, Bitcoin-Qt and I'm just trying out Blockchain.info.

Is it possible to generate 50,000+ addresses in my wallet? If I use bBitcoin-Qt  or Armory I can create addresses manually, but I need something to automate this system.

Is it possible? Is there some API for this?

You can have Bitcoin-Qt generate 50k addresses by starting it with the parameter -keypool=50000.

They will not all be visible in the client interface, most will be just hidden as unused backup addresses, but they will all be stored in your wallet.dat.


What are some forks of Bitcoin that ultimately failed? Being as many of the popular cryptos today were forked from Bitcoin at some point, I'm curious which past forks seemed promising, but ultimately failed at some point..

Sort of a history lesson if you will, so what past coins failed and why?

It kinda depends on your definition of "failed".
See http://mapofcoins.com/bitcoin for a list of maybe not the whole tree, but a fairly large one. You can select "defunct" coins at the top, to mark those. Click on the symbols at the right to get info on that coin.

Now, defunct on that site seems a hard bar to reach, despite the high number of those. For just "failed", you can probably add a whole lot more,

Maybe the most notable failed/defunct one (not because it's known, but by its descendents) could be Tenebrix, which begat Litecoin.


I have lost my blockchain.info wallet identifier and used a fake email, does anybody know if its recoverable still? I have the password and mnemonic phase, thanks so much for any help

Yes you can as long as you have the mnemonic phrase.

Enter it here for recovery:  https://blockchain.info/wallet/forgot-password

If you don't have the access to the email address then you will need to contact support at: https://blockchain.info/support-desk

Here's the info straight from Blockchain.info

A mnemonic is the passphrase seed of your Blockchain Wallet provided to you when you sign up for a new wallet. The purpose of this is in case you need to recover your wallet at a later date, if you lose your login information. When you recover your wallet with your mnemonic, your password and identifier will be displayed to you. Your main password can not be changed once it is set, therefore your mnemonic will always remain the same for each wallet. - See more at: http://blog.blockchain.com/2015/03/17/whats-the-difference-a-comparison-between-key-blockchain-wallet-terms-and-features/#sthash.kRhvW9CM.dpuf


What is the difference between wallet balance, local balance and remote balance in the Lighting Network? I am having a hard time understanding the difference between the different "balances" in the Lighting Network. For example, I am running an LND node and I have the following balances:
$ lncli walletbalance
{
    "total_balance": "13841305",
    "confirmed_balance": "13841305",
    "unconfirmed_balance": "0"
}

$ lncli listchannels | jq -r '.channels[].local_balance' | awk '{sum+=$1} END {print sum}'
4201392

$ lncli listchannels | jq -r '.channels[].remote_balance' | awk '{sum+=$1} END {print sum}'
23804004

What is the difference between the local balance and the wallet balance?
If my node forwards a transaction, where do the fees go, in the wallet, or in local?

In each of your channels, you have a local balance. This is the balance that is yours in that channel. The counterparty of the channel has the remote balance. All lightning transactions change these balances with each one resulting in their sum being the same and matching the channel capacity. As all transactions in that channel just end up changing the balances, routing fees paid to you go into your local balance.
Your wallet balance is the total amount of funds that you control that are not in a channel. It's the sum of the UTXOs that you control.


difference between litecoin and bitcoin transaction id format i will be storing litecoin and bitcoin transaction ids in the same table in my database, and i want to make the transaction id into a primary key. if litecoin and bitcoin transaction ids overlap then i can work around this by appending a BTC or LTC to each transaction id. can someone tell me if they do overlap?

They do not overlap. A transaction is always unique. a cryptographic hash algorithm is designed in such a way that they do not collide. This is one main requirement  of a hash function.

The inputs to create the transaction ID is partially based on the inputs which are being used to create the actual spend request in the chain, thus you will never have a collision between Bitcoin and Litecoin.


When generate WIF private key , base58check('80'.decode('hex')) not prefix as '5' i try to generate WIF private key with python.

import base58
import hashlib

def b58(hex):
    return base58.b58encode(hex)

def sha256(hex):
    return hashlib.sha256(hex).digest()

def main():
    k = sha256('private_key')
    extend = '80' + k.encode('hex')
    sha1 = sha256(extend.decode('hex'))
    sha2 = sha256(sha1)
    print b58(extend.decode('hex') + sha2[:8])

if __name__ == '__main__':
    main()

the result's prefix is not '5' but 'V'

i try to just base58encode 0x80 and the result is 3D ???

where is mistake in this code?

By comparing all variables with this tool, I've found that the mistake is in this line:

print b58(extend.decode('hex') + sha2[:8])

Remember that sha2 is a byte array and not a hex string. You can replace the 8 with a 4 to make your code work.

You can also simplify the code even further to:

def b58(hex):
    return base58.b58encode_check(hex)

def sha256(hex):
    return hashlib.sha256(hex).digest()

def main():
    k = sha256('private_key')
    extend = '80'.decode('hex') + k
    print b58(extend)


How can bitcoins be stolen? I read about Mt. Gox and how 850,000 bitcoins has been "stolen" from it. I do not understand how someone can steal bitcoins: if MtGox has bitcoins, and MrThief wants to use this bitcoins, then MrThief must show a transaction moving bitcoins from MtGox's accout to MrThief's account. But such a tranasaction must be signed by the private key of MtGox. Does it mean that, in order to steal bitcoins, MrThief must somehow find the private key of MtGox and sign transactions in its name? Or is there another way by which bitcoins can be stolen?

As you described, a valid transaction must be submitted to the network to change ownership of funds. Mt.Gox P2PKH addresses, so spending the funds indeed required a signature of the corresponding private key to move the funds.
As Nate Eldredge commented above, this can be achieved either through gaining control of the key, or by causing the owner to use the key in the attacker's favor. Both occurred in the context of MtGox.
First, MtGox got hacked in 2011 where the attacker attained a copy of the service's hot wallet. Not only did they take the funds available at the time, but Mt.Gox continued to get deposits to tho addresses the attacker had keys for, which the attacker immediately redirected for the next two years.
Later, MtGox described losing funds due to attackers malleating withdrawal transactions. In such an attack, one or multiple signatures on a transaction get modified which results in an equivalent transaction with a different transaction id (txid). MtGox was tracking withdrawals by txid. Since the original transaction never confirmed, MtGox misinterpreted the corresponding withrdrawals to have failed and reissued the same withdrawal again, paying out the withdrawal twice. Later research showed that this caused a much smaller portion of the losses than initially suspected.
If you are interested in reading more about the MtGox saga specifically, I would recommend the corresponding article series on the WizSec blog.


Do all outputs have an address associated with them? I guess more specifically, a decodable address?
I have seen transactions on blockchain.info where the address was "unable to decode"
Is there a way to count these?
Also do they stay in the UTXO set forever (since they cant be spent)? Or is there a way to drop these from the UTXO? Are they currently being dropped?

Not every UTXO has an associated address.

An address is really just a shorthand notation for a particular Bitcoin Script. There exist many interesting scripts which do not correspond to an address, but are still spendable under some conditions.

Note that every P2SH output does have associated address, and almost all interestong scripts these days use P2SH.


How are mining pools authenticated to clients? Hijacking the connection between a powerful mining cluster and its mining pool, then impersonating the pool and claiming the mining results seems to be a likely attack.

How are mining pools authenticated to clients to avoid such attacks?

The mining pools do not authenticate themselves to the miners in any special way beyond what is used in their communication protocol. If the pool takes calls on a non-encrypted socket, the communication can be intercepted and changed - a normal man-in-the-middle attack. If a pool uses a SSH certificate, that is something that can't be mimicked by an attacker and would make such an attack impossible. The mining protocol itself does not add any extra security.

The person running the mining operation can always tell that something is fishy if they pay close attention to their miners' productivity and downtime, but that is not part of the protocol.


SHA256 * 2 on header - what am I doing wrong? I've been experimenting with the php code here: https://en.bitcoin.it/wiki/Block_hashing_algorithm  (after correcting the small bug of $x=; to $x=""; )

With these blocks 0 and 125552 (for example) it works fine and I get the expected hash.

With blocks 225552 and 300000, I get:

7a7bb195e8bcc8e73205df7906eb68f26144c6fbc577d59dd4e8a0cfdb8b90df (rather than 00000000000001f4f14b09019b23d71c222a2c1245ef3df52875d79ff4488709)

and

178d6fe6cbf696311e7f46263067eeb688797e4c790060c1f6edf6daec76c59e (rather than 000000000000000082ccf8f1557c5d40b21edabb18d2d691cfbf87118bac7254)

...respectively - which doesn't match the hash of either block.

What am I missing or doing incorrectly?

Additional note - I confirmed these results using "openssl dgst -sha256 -binary test-input.bin |openssl dgst -sha256"...

Further to this, using the python code from the same page:

>>> import hashlib
>>> header_hex = ("01000000" +
...     "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
...     "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
...     "c7f5d74d" +
...     "f2b9441a" +
...      "42a14695")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'

...works fine... but:

>>> import hashlib
>>> header_hex = ("01000000" +
...     "7ef055e1674d2e6551dba41cd214debbee34aeb544c7ec670000000000000000" +
...     "d3998963f80c5bab43fe8c26228e98d030edf4dcbe48a666f5c39e2d7a885c91" +
...     "02c86d53" +
...     "6c890019" +
...     "593a470d")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'9ec576ecdaf6edf6c16000794c7e7988b6ee673026467f1e3196f6cbe66f8d17'
>>> hash[::-1].encode('hex_codec')
'178d6fe6cbf696311e7f46263067eeb688797e4c790060c1f6edf6daec76c59e'

...gets the same erroneous result as the php code.

You have the wrong block version number.  Block 300000 is a version 2 block, whereas 125552 was version 1.  So the first word in the block header should be "02000000" not "01000000".


Problem with my bitcoin wallet In the distant 2013 I tried to deal with mining. At that time it was much easier than it is now.
I downloaded the official program (the version I did not remember), installed it on my computer with a powerful, at that time, videocard and mined.
When I decided to stop I had a bit less than 1 btc. Without having any possibility to cash it out I just saved it to my wallet.dat. I did it with the thought in mind that in some time I would restore mining on its base.
Currently, it is already 2 months that I can not restore my wallet. I installed different versions of the software from bitcoin.org, synchronized them, but the balance writes 0.

Can you help me find out the reason of the fact that in 2013 I had some money there (the rate was $ 130) but 0 at the moment?

P.S. The only person who had access to the wallet was me. I even have the exact date I used it for the last time.

First be very careful seeking help online, don't give the wallet.dat file or its contents to anyone, and don't screen share to get help.

Also, backup the wallet.dat file securely to make sure if you accidentally change the contents, you don't lose the money.

I don't use bitcoin core myself, so the following is just what I have been able to find out quickly.

So from here I can see some information about the wallet.dat file format. I believe it to be plain text, so you can just open in a text editor.

It contains - keypairs for each of your addresses that's what you want.

First, step enter each of the public addresses e.g. 1GwV7fPX97hmavc6iNrUZUogmjpLPrPFoE into a site like https://bitref.com/ to see if they have unspent outputs sent to them, i.e. a positive "balance". Only post the public addresses into a browser, they are the shorter strings, like the example I gave.

Now you know which addresses your money was sent to and that your wallet does indeed contain bitcoins and you can relax a little knowing you have all the private keys required to spend those coins.

There are several options going forward past this point, so I think you should check this first. It's safe if you don't modify the file and, again, only post the public addresses into a browser.


Can two crypto currencies have the same name? I noted today that coingen.io makes it easy to make crypto currencies.
I was wondering if it makes sense to register currencies named after countries, gods and companies to hoard them. AFAIK there is nothing that ensures uniqueness of the names of the crypto currencies, right ? there is nothing in the block-chain that critically depends on the name of the currency.

What keeps coins distinguished is primarily the protocol and secondarily the genesis block.

If someone tries to copy bitcoin exactly using the exact same source only with a different name, all of the users will simply be part of the bitcoin blockchain.

If someone tries to use the same protocol but with a different genesis block then a new bitcoin ripoff has begun.

If someone tries to use the same genesis but with a different source code, the results will depend on the protocol, but most likely it will simply be a fork.

All of the 1st generation alts use variations on the bitcoin source code and have new genesis blocks.

A new protocol and a new genesis block are the best ways to ensure a new coin.


How to sign a transaction using only an offline computer? I think it is possible to generate keys on an offline computer and sign. To create a transaction I need to input transactions detail, and somehow I have to transfer signed transaction from offline computer to a online computer to relay the transaction.

Is it possible to do this without using USB storage? I can use a keyboard, or barcode reader to transfer the input transaction hash to an offline computer and the signed transaction back to the online computer. So that private key stays with the offline computer.

What are step-by-step instructions to do this, with any required error check / correction?

You're correct that the offline node needs to how to claim its funds, so it can't be totally isolated.

Currently, the most mature offline wallet solution is through a client called Bitcoin Armory. Here's what your workflow looks like with offline wallets:

  Online node creates transaction -> USB key -> Offline computer signs transaction -> USB key -> Online node broadcasts transaction

You can use Windows, Linux, or Mac for your offline wallet, but I'd recommend Linux, as it's difficult to disable AutoRun/AutoPlay on Windows.

Download:

Windows/Linux
Mac - Beta

This page explains offline transactions in greater detail.


How to reduce number of inputs in bitcoin transaction? We have a bitcoin node running on a server which we use to generate addresses to receive small payments from the users. We receive tons of small payments daily right now and then we are using the same bitcoin wallet to send payouts to our users using the sendmany rpc call.

This results in lots of inputs to cover the amount in outputs. Each new input increases the size of transaction by around 150 bytes and so we are loosing too much in fee.

Is there any way to reduce the number of inputs?

Suggestions would be really appreciated.

Thank you.

This is a common issue for any service with BTC incomings/outgoings.

The answer is simply to consolidate all your inputs in a large transaction all at once, so you remove possibly hundreds of small outputs, and get one big at the end.

Usually people do this semi-regularly, though you also see people waiting until mempool fees are super low.

One reason you can afford to pay a relatively low fee for consolidation transactions, is because you're planning ahead in your consolidation transactions. You don't need it confirmed immediately (like you would for outgoings, perhaps), so it's OK if it takes a few hours, once your wallet has enough to keep paying customers.

Just pick a moment when the mempool looks super empty, and it'll work really well. If it's not super empty, you can still try low-balling the fee and waiting longer.


BTC Exchanges and Counterparty Risk I'm doing research on the above topic, but so far haven't found any or at the most only limitedly valuable articles/data published in recent time (past 6 months).

What I'm interested in is how users are protected against counter-party risks when using an exchange to trade BTC for fiat currency, and if there is any data available as to how often this protection has been necessary and did or didn't work.

In addition, I'm curious if there are any post-trade security issues (albeit I don't imagine there could be any, asides from the classics like losing your pw, wallet or credentials to the nether or a third party) and general post-trade procedures which alter from the usual bitcoin trade sans exchange service.

Are there numbers declaring these risks? Statistics that are freely accessible, which I might have missed? I've been looking for data the past hour but so far have come up short. Keep in mind, the data should be as fresh as possible.

Of course I do take all kinds of other statements as well - articles, news, reviews. But a neat statistic or similar would quite simply save me the hassle of constructing one myself.

Thanks for your help!

To engage in trading on an exchange, you have to make a deposit of either fiat or Bitcoin. As the balances are then managed by the exchange until paid out, there is no counterparty risk to your trading partner: You can only submit buy and sell orders that are funded. Once your order is matched, the exchange can atomically update the balances of the two users in their database:

When Alice wants to sell one Bitcoin for two hundred dollars, and gets matched to your buy order for one Bitcoin at the same price, your USD balance gets decreased by $200 and hers increased by $200, while her BTC balance gets reduced by 1 BTC, and yours increased by one.

However, there is a counterparty risk to the exchange. The exchange may be e.g.
a) running faulty software
b) misappropriate funds
or c) go bankrupt,
resulting in failure to perform payouts. This has happened in the past, most notably in the case of MtGox. Currently, I know of reports suggesting that two more exchanges might be unable to honor their liabilities to their users.

To this end, some exchanges get themselves audited and publish proof of their balances.

It is therefore advisable to keep informed about exchanges that you entrust with your money, and not to keep money on exchanges that you are not using to trade with.

Unfortunately, I cannot serve with a neat statistic on this topic.


How would advancement in ASIC manufacturing process affect mining? What's the expected performance improvement with the advanced ASICs? When advanced semiconductor manufacturing processes provide high hash rates by consuming low power, and older processes makes mass production cheaper, I'd like to know when approximately, newer ASICs will be able to make older ASICs obsolete.

Following is the semiconductor manufacturing process timeline, from wiki.

  45 nm — 2008 32 nm — 2010 22 nm — 2012 14 nm — est. 2015 10 nm — est.
  2017

http://en.m.wikipedia.org/wiki/14_nanometer

I would beg to disagree - we will see a similar effect when v2, v3, v4....vn rendentions of ASIC come around.  We will see 10X gains in Hashpower and roughly a 40% drop in power consumption.  This is all pure guesswork and speculation based on other responses I've seen and following the developments of KNC, BitFury, BFL, Avalon, and AsicMiner.

It could be said for that matter that we are already seeing the development of v2 hardware with the advancement of the 28 nm class of ASIC Chips.

There will likely be a cascading effect of shifting retired hardware onto other Alt-chains as difficulty increases on the other off color alt-coins such as PPC, FRC, and TRC.

Right now using cyrptocurrency as a medium of exchange is very new...the ecosystem to spend them does not yet exist...if perhaps other services such as internet providers, mobile phone providers, insurance carriers, and other recurring cost structures will willing to adopt btc as a medium of exchange we would see the increases in usage and thus value (price)

Smaller transistors both allow more transistors to be packed on each asic chip and also require less power overall to perform the same level of hashing compared to the larger obsolete transistor size.  I have read that underclocking allows power consumption to be reduced even further - it could be that these devices see between a 30 to 65% increase in GH rates as implied by the jump between Avalon to BFL to Bitfury to KNC.


Do you pay verification fees in an exchange? In an exchange of cryptocurrencies (say an exchange of ETH to BTC on poloniex or kraken), do you still pay a fee to the miners to verify the transaction(s) or is it included in the exchange fees?

That exchange takes place entirely on the exchange's books. Miners don't verify those transactions. Someone will pay transaction fees when you deposit or withdraw to and from the exchange.


Is GPU mining viable with any Cryptocurrency mining variations? I have a GTX 960 2GB, and wouldn't mind some cash. I know mining bitcoin with it would maybe produce a few pennies a year, but someone told me there are other mining networks that aren't as inflated as Bitcoin. Also, I'm thinking about upgrading to a 1060 soon (for gaming) and use that for mining overnight/during school, if viable. Thanks.

You'll want to keep your eye on a cryptocurrency mining profitability website such as this:

http://www.coinwarz.com/cryptocurrency

Please note that much of the mining software for a lot of these coins contain malware, so be very, very careful before installing such things.


Where can I sell things for bitcoins? I have old items that I want to sell for bitcoins. This includes digital content and physical objects.

What websites can I use to sell them?

You can find an extensive list on page Trade at Bitcoin Wiki.

A short list of some auction sites that use Bitcoins:

Bid Bitcoins
Bidding Pond
Bitmit

If you want to sell digital files per download, go here: http://bitcoinservice.co.uk/ .

And as with anything, you can just post on an online classified ad websites, such as craigslist (thanks Thilo for the suggestion).


Do local nodes work across crypto types? Newbie to all of this, hoping you can help with what is probably a "duh" question. I'll keep it brief, though: if I download the blockchain using the instructions given for the Bitcoin GUI, will I be able to use it as a local node for my Monero GUI wallet, as well?

Thanks so much! :)

No, while there are some wallets that support multiple coins, the full nodes of each cryptocurrency network generally have their own distinct node software. In particular Monero and Bitcoin will require separate software.


Litecoind answers "getnewaddress" RPC request with "Method not found" After having compiled the Litecoin daemon found at:

https://github.com/litecoin-project/litecoin.git

and set up a username and password, calling

litecoin-cli -rpcuser=<username> -rpcpassword=<password> getnewaddress

returns the error "method not found" from the litecoin daemon litecoind.

The answer is to recompile the Litecoin daemon, making sure to call the configure script with the --enable-wallet option:

./configure --enable-wallet

From there, make and make-install will give you a binary that has the getnewaddress RPC method available.

This reason behind this is that - instead of just disabling the methods around using the daemon as a wallet, or throwing an error in the case they're used without the --enable-wallet compilation option - the methods themselves are not compiled into the binary at all. This is likely due to the use of litecoind as a wallet requiring an extra library - the Berkeley DB library - and the path of least resistance being to not try to compile that section of the code at all in order to avoid issues with referencing the library, but that's conjecture.

This should also solve similar issues in other coins forked from the bitcoin source, and for bitcoin itself.


What is stopping a Taproot spend following old Taproot rules (initially treated as anyone-can-spend) pre-activation creating a re-org post activation? This question is similar to this Signet question on Signet nodes enforcing different Taproot rules (old and new) pre mainnet activation. Instead it is regarding how a valid Taproot spend on mainnet according to old Taproot rules (that were never enforced on mainnet) initially treated as anyone-can-spend by the network, doesn't create a massive re-org when new Taproot rules are activated on mainnet.
For example, let's say I created a UTXO encumbered by Taproot rules as they were specified in July 2020 (before the Taproot BIPs were changed from a squaredness tiebreaker for the R point to an evenness tiebreaker). I managed to spend from this UTXO by following the Taproot rules as they were specified in July 2020. Of course Taproot isn't activated at all so all nodes would have treated my transaction as an anyone-can-spend and my transaction would easily have made it into a block. Now let's say in June 2021 Taproot is activated on mainnet with the new rules as they were specified post August 2020 (with the evenness tiebreaker). What is stopping my transaction from failing verification against the new Taproot rules and creating a massive re-org back to the block that contains my transaction?

When the soft fork (e.g. Taproot) is activated (assuming it is at some stage) all nodes agree to only verify transactions according to Taproot rules from the point of Taproot activation onwards. No nodes will verify transactions pre-activation according to rules specified at activation. Hence the network will always agree that your transaction following the old Taproot rules was an anyone-can-spend even if a valid or invalid SegWit v1 witness is available.
In contrast, post activation there will be some nodes on the network enforcing the new Taproot rules (running the latest version of Bitcoin Core) and some treating them as anyone-can-spend (running older versions of Bitcoin Core). A transaction broadcast post activation following old Taproot rules (never activated on the network) will be rejected by the nodes enforcing the new Taproot rules. Even though some nodes will treat transactions following the old Taproot rules or the new Taproot rules as anyone-can-spend, only transactions following the new Taproot rules will make it into a mined block accepted by all nodes on the network.


Ability to Send Bitcoins to an Address over a duration of time Is there a service or upcoming feature which lets you send Bitcoins to an address over a duration of time? I can write a script myself to send 1mbtc every day to an address and leave it running on my computer/server. But I was wondering if there was a service that does this already? Or can smart contracts do this, if so which one?

Seems like you're looking for an automated billing solution, or something along those lines. There may be others, but I know Coinbase has support for this. This is a screen shot from their online interface:

If it was a recurring payment in small amounts, you might also consider Micropayment Channels, so that the feels were not prohibitive. For larger, monthly or yearly transactions, though, the fees paid to the miners may not be as noticeable.


fundrawtransaction - what is it? I find on Internet interested article.
How I understand the raw transaction can be created simpler without fundrawtransaction.

bitcoin-cli listunspent [misconf=1] [max_number_confirmation=99999999] '''["<wallet_address>"]'''
bitcoin-cli createrawtransaction
'[{
"txid" : "<txid_of_selected_block>",
"vout" :
}]'
'{"<recipient_address>": <amount_to_send>, "<sender_address>": <amount_change>}'
bitcoin-cli signrawtransaction <hex_createrawtransaction>
bitcoin-cli sendrawtransaction <hex_signrawtransaction>

That's all and without fundrawtransaction.
And I don't understand why fundrawtransaction do need? And what is the difference between "with" and "without"?
I'm a newbie and I not sure I right understand what do mean inputs and outputs and possibly so I can't understand what mean fundrawtransaction?
Please, more examples and more simple speech. Thanks.

Just to give a little background first: Bitcoin uses a so-called UTXO model. You own UTXOs (or "coins", to give an analogy). Every coin has a value (which can be any number of satoshis) and has an owner (script) "stamped" into it. Every transactions "melts down" a number of existing coins, and "forges" new coins. The value of the new coins cannot exceed the value of the melted coins. The difference between the amount melted down and the amount forged is the fee of a transaction.
This means that the protocol really no concept of a "balance". There are just coins. You can have 3 BTC in your wallet, consisting of a 1 BTC coin X and a 2 BTC coin Y. These can be stamped with the same script (address) or not. It doesn't really matter - a wallet can consist of many addresses.
So say you want to pay 1.5 BTC to someone else, who has given you address A. Your end goal is creating a transaction that consumes the 2 BTC coin, and produces a 1.5 BTC coin (to the payee) and a 0.5 BTC coin (minus fee) back to a new address of your own wallet (called a change address). It's also possible to consume both the 1 BTC and 2 BTC coins, and outputs 2x a 1.5 BTC coin. Let's assume that's what you're doing.
How would you do this using the Bitcoin Core RPC? There are a number of ways:
The most automatic way
If you're using Bitcoin Core's built-in wallet (i.e. the Bitcoin Core wallet is what created the addresses involved, and it manages your coins), you can make it do everything. Just do:
bitcoin-cli sendtoaddress <A> 1.5

Where <A> is the recipient address. It will automatically determine which of your UTXOs to use, and create a transaction that spends those, pays <A> and creates change, then sign the result, and broadcast it on the network.
Manually but using the wallet still
If you want more control, you can perform the things sendtoaddress is doing one by one yourself, allowing you to observe the intermediary results.
The first you do is create a raw transaction that pays <A>, and nothing else:
bitcoin-cli createrawtransaction '[]' '[{"<A>": 1.5}]'

It will report a hex raw partial transaction with just that one output, and no inputs. Next you want to add inputs and change. You could do that manually (see further), but you can let the wallet do this for you. This is what fundrawtransaction is for.
bitcoin-cli fundrawtransaction '"<output from CRT>"'

This will give you another unsigned raw transaction, but now one that includes inputs (sufficient to cover the 1.5 BTC you're trying to send) and change (for whatever is left of the inputs spent after subtracting 1.5 BTC, plus a reasonable fee based on network estimation, and estimation of how big the transaction will be after signing).
Then you sign it, and broadcast it.
bitcoin-cli signrawtransactionwithwallet '"<output from FRT>"'
bitcoin-cli sendrawtransaction '"<output from SRTWW>"'

The advantage of this approach is that you can inspect the intermediary results at every stage (using decoderawtransaction amongst others), or make many changes to the process. Perhaps you have a multisig wallet with another device - and you need to make a pass by there doing another signrawtransactionwithwallet (or whatever equivalent that other device/software has for working with raw transactions).
Fully manual
If you want the most control, you can do everything manually - including the ability to include inputs that don't belong to your own wallet. This is the example you gave in the question, but if that's all you plan to do, you're much better off using one of the previous two methods.
As you pointed out, you first need to gather a list of UTXOs that can be spent. This can be done with listunspent, but you can also include other UTXOs - including ones from other people if you're participating in a CoinJoin transaction for example.
bitcoin-cli listunspent

Then you have to construct the (full) raw transaction, including the inputs you want to use from before, the output to the recipient, and including a change output back to yourself. If you want that change to go to you own wallet, you can use getrawchangeaddress (which is like getnewaddress, but will treat outputs to it as change rather than an incoming payment). You also need to manually estimate the vsize of the transaction will be after signing, determine a fee to use based on that (the block space market prioritizes transactions based on fee per vsize), and subtract that fee from the change you're creating. This is a bunch of work, and mistakes are easily made.
Next you'll need to sign the transaction. If you have the private key in your own wallet, you can use signrawtransactionwithwallet like before (note that signrawtransaction from your example no longer exists; it has been split up into signrawtransactionwithkey and signrawtransactionwithwallet). If not, you can either use signrawtransactionwithkey if you have the private key, or you could transfer the raw transaction to other devices/people, and sign there too.
Finally you'd use sendrawtransaction just like before.
Using PSBT
At this point I need to point out that all the raw transaction based transaction APIs have been superseded by the PSBT-based RPCs (see BIP 174). If you try to use the RPCs above you'll notice they really only work with simple scripts, and you need to pass a lot of information along everywhere. In particular, signrawtransactionwithkey will need information about the UTXOs again, the scripts used in those, what type of scripts they are. This is pretty painful, and easy to screw up.
PSBT is an interchange format for transferring/storing partially signed transactions, along with any information signers or other participants may need to be able to sign. It'll convey UTXOs, script information, information about the keys in it, ...
The equivalent of "manually but using the wallet still" would be:

walletcreatefundedpsbt instead of createrawtransaction + fundrawtransaction
walletprocesspsbt instead of signrawtransactionwithwallet
finalizepsbt to convert a fully-signed PSBT to a raw transaction
sendrawtransaction like before to broadcast the result.

The equivalent of "Fully manual" would be:

createpsbt instead of createrawtransaction
walletprocesspsbt instead of signrawtransactionwithwallet. There currently is no equivalent for signrawtransactionwithkey, but PSBT is supported by various other pieces of software (most notably, HWI which allows PSBT signing and other operations with hardware wallets.
Again, finalizepsbt and sendrawtransaction like before.

PSBT has a lot more utility functions, such as combinepsbt (mostly for multisig), joinpsbts (for doing CoinJoin-like things), decodepsbt and analyzepsbt that can tell you what to do next, utxoupdatepsbt to gather information from the UTXO set and add it to a PSBT file (which works even if your Bitcoin Core wallet is not involved), etc.
TL;DR
You can use a workflow with or without fundrawtransaction. If you don't use it, you have more manual control and aren't forced to use the Bitcoin Core wallet itself.


Are there any bitcoin node that are running the original Satoshi codebase? I was taking a look at all the different kinds of nodes running bitcoin. Are there any nodes that are verfiably running the original Satoshi client so that we can confirm backwards compatibility?

If not, what is the oldest operational bitcoin node?

If you mean truly unmodified, the answer is almost certainly no.

Version v0.2.9, released on May 26 2010, introduced checksums in the protocol. During a transition phase until Feb 20 2012, checksums were only used after a version negotiation, making sure both parties understand checksum. After Feb 20 2012, all new initial connections would start using checksums everywhere. This transition period was designed by Satoshi, and took effect on the planned date without any issues.

However, it means that no Bitcoin software from before May 2010 is currently compatible with the existing protocol. It is however possible to write protocol adaptors, or make small patches to old code to make it function. With such changes, version 0.1.0 should accept the current blockchain.


Gaming the "off-by-one" bug (difficulty re-target based on 2015 instead of 2016 block time span)? In this forum post from Gavin Andresen he writes:

  Second: I've written 'discourage blocks' infrastructure:
    https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks
    (code reviews welcome)

  ... which should give us the ability to nudge miners to Do The Right
  Thing.  Discouraging blocks that appear to be gaming the off-by-one
  bug should be enough incentive to prevent 50+% cartels from forming,
  without requiring a blockchain-splitting change.

I believe the off-by-one bug refers to the difficulty re-target being based on the time taken for the previous 2015 blocks instead of 2016 blocks - please correct me if I'm wrong.

What I want to know is how can this bug be gamed by miners? What can they do and what advantage does it give them?

The attack allows a group of miners with more than 50% of the network's computational power to change difficulty arbitrarily.

When difficulty is adjusted, only the times of the first and last blocks in a retarget period (i.e., the first and last blocks with a certain difficulty) are considered. This attack works by manipulating the timestamp of one of these two blocks.

Blocks are considered valid if their time is greater than the median of the last 11 blocks and less than currentTime + 2 hours, so it's legal for an attacker to create a new version of an old block with a time far in the future. If this is the first block in a retarget period, then the difficulty will quadruple after that period. If it's the last block, then the difficulty will be divided by four. (Difficulty adjustments are limited to *4 or /4.)

Note that it is not possible to do these major changes with recent blocks because the time would be more than two hours in the future. It needs to be done with historical blocks, and then the attacker needs to re-do all blocks that come after that block. So this attack is only possible when you have a lot more computational power than the legitimate network.

This would not be as big of a problem if there was a block of overlap between the retarget periods. Instead of using the first and last block in a retarget period, use the last block of the old difficulty and the last block of the new difficulty. Then the attacker will still be able to mess with one retarget period, but it will be corrected in the next retarget period.

I think a better solution would be to look at every block in a retarget period plus maybe some blocks before the period. It just seems like a bad idea to give certain blocks "special powers".

A discouraged block is considered valid (it adds confirmations to transactions, blocks after it will also be valid, etc.), but your node refuses to relay it or build future blocks onto it. If most of the network is discouraging a block, then it will almost certainly be replaced. Even a minority discouraging a block will hurt the block's chances. It is very unprofitable for a miner to discourage a block when most of the network is not, though.

(Thanks to gmaxwell for explaining this attack to me.)


Can I send/receive payments but prevent forwarding payments in Lightning Network? Say I am using a very computationally constrained device (eg. a sensor) and it uses Lightning Network to send/receive payments. However, being computationally constrained it doesn't want to forward incoming payments that are actually meant for other nodes. The reasons could be that forwarding a payment will require it to forward the htlc, fulfill it as well as compute the onion for routing to the next node which might be computationally draining. However, sending an error would be just one operation after parsing the onion.

Every time the sensor node parses the onion and sees that the payment is not meant for it, it will send a temporary_node_failure or temporary_channel_failure error message. In situations where the lightning software uses some data analysis tools like autopilot, other nodes might completely eschew this sensor node out from forwarding the payments due to its high failure rate.

Is this something that can be implemented with a slight tweak to the current lightning implementations (like LND or c-lightning)? If the failure rate is too high, is there something like a banscore that is being kept by other nodes that might prevent this sensor node from receiving/sending payments in the future?

Yes, there are basically two ways to avoid becoming a forwarding node:

Do not announce your channels, and keep them private
Reject any incoming HTLC that is not destined for you

The first is supported by the protocol itself, and is a proactive measure against forwarding any payment that is not destined for you, while the latter is a reactive measure and would allow you to decide on a per-HTLC basis whether you want to forward it or now.

The protocol allows channels to remain private and not be announced in the wider network:

  Only the least-significant bit of channel_flags is currently defined: announce_channel. This indicates whether the initiator of the funding flow wishes to advertise this channel publicly to the network, as detailed within BOLT #7.

This means that the channel is not going to be included in the gossip, and nodes won't learn about the channel's existence. In order then to receive payments, which requires the sender to compute a route to you through that unannounced channel, you selectively tell the sender about the channel in the invoice using route hints, i.e., the r field in the invoice.

The second method mentioned above involves instrumenting the node such that it accepts HTLCs, but immediately rejects any HTLCs for which you are not the destination. This is has several downsides, among which the fact that you are announcing channels that are fundamentally not operational for forwarding, and you still have to process all HTLCs since you can't filter them out ahead of time. This corresponds to the scenarion that Rene Pickhardt mentioned. The computational overhead consists of:

More messages to process, including the wire encryption/decryption, potentially waking your CPU up if you run on a low-powered device
Decrypting the onion, which is a really expensive operation since it decrypts/encrypts 2600 bytes of data by generating a pseudorandom stream. In addition the onion gets prepared for an eventual next hop.
Need to process the HTLC itself (DB lookups, ...)

Both methods are implemented in some implementations: the mobile version of eclair does not announce its channels by default, lnd is planning to implement a bias against (though not a complete exclusion) channels and nodes that have proven to be unreliable and c-lightning allows you to implement any forwarding policy you'd like as a plugin using the htlc_accepted hook. Furthermore it is trivial to modify lnd and c-lightning to make the announcement of channels configurable.

(Disclaimer: I am one of the spec authors and work on c-lightning)


Can I damage my computer by mining bitcoin? I have been mining Bitcoin for a while on a few systems, some CPU mining (which has proved to be basically useless) and some GPU mining. The GPU miners are workstations, which have midrange graphics cards built in. I have not done any modifications or built high-end mining/gaming systems. One is an Apple iMac with an AMD Radeon HD 6770M 512 MB built in. I typically mine with the Phoenix miner and AGGRESSION=3 for at least 12 hours a day.

Can the GPU handle this load, or is it possible I will damage my computer by mining bitcoins without a dedicated high-end GPU?

It is possible to damage your computer by mining in the following ways:

the computer will degrade more, as it is used more (you will have to replace it sooner than normally)
the computer will overheat and some components will fail because of that (if for example, the computer is dusty. If the parts are well-maintained and the computer is not boxed in, this shouldn't be the issue)
you will overload some part of your computer with the mining and it will short circuit or blow a fuse (mostly relevant if your power supply is weak, this happened to me once)

Number 3 you should notice quite fast if you run your miner at top speed, full load. If you are already mining, this probably won't happen unless you increase your load, or are operating close to the limit of your hardware. If something flashes, smokes, or the computer doesn't turn on any more, this was probably the cause. Replace hardware.

Number 2 you should notice if you run your miner for about an hour, once everything heats up well. Again, if you are already mining and this doesn't happen, it probably won't if you keep your computer clean and give it some air. If your computer turns off suddenly, but runs fine after cooling down, this probably was the cause. Clean your computer chassis, possibly add some fans or replace hardware.

Number 1 you won't notice for months or years.

Mining with lower-end GPU should be fine in all the regards, asides maybe 1 (leaving your computer on for longer to mine will ear it down more). Usually it means you won't use as much power and generate as much heat, so you should be fine.


What is the smallest fee you can pay for an on chain transaction? From what I understand, the smallest fee you can pay to miners per transaction is 1 Sat/byte.

With a basic Bitcoin transaction being roughly 250 bytes that would obviously mean the fee is 250 sats. Would there be a way to pay 1 sat for the entire transaction? Or anything less than 1 sat/byte?

Here is a list of what it would cost for a 1 sat/byte transaction at different bitcoin prices:

Price: $7,500 --- Trans Fee: $0.0187 ≈ $0.02
Price: $100,000 --- Trans Fee: $0.25
Price: $1,000,000 --- Trans Fee: $2.50
Price: $10,000,000 --- Trans Fee: $25.00

If you cannot pay less than 1 sat/byte then, it would effectively make on chain scaling uneconomical (Bitcoin Cash). Let alone the technical implications.

From what I understand, the smallest fee you can pay to miners per transaction is 1 Sat/byte.

It's not true.  A transaction can contain a fee of any amount.  There is nothing to stop you from creating a 250-byte transaction with a fee of 1 satoshi, or 17 satoshis, or even 0 satoshis (no fee at all).  Of course, it will depend on market forces as to whether miners would actually decide to include such transactions in a block.

Many wallets ask you to choose a transaction fee in satoshis per byte, but that's just a convenience for the user (since most miners look at the ratio of fee to transaction size in deciding what to confirm).  It's not an inherent feature of the blockchain.  Under the hood the wallet just multiplies this number by the transaction size to determine the absolute transaction fee.  You could patch the software to set an absolute transaction fee directly, or perhaps even just enter a fractional number of satoshis per byte.

(There are currently rules preventing low- or no-fee transactions from being relayed over the peer-to-peer network, but that's not the only way to get your transaction to a miner; also, those rules are not part of the blockchain consensus rules, so they can be changed without a fork.)

It's true that if we ever get to a point where 1 satoshi is worth a lot of money, then a transaction would have to have either a large fee (>= 1 satoshi) or no fee (0 satoshi).  The former would be expensive, and miners have no incentive to confirm the latter (though they can if they feel like it).

There's been lots of discussion about what will happen if 1 satoshi ceases to be small enough.   One possibility is a lot more use of off-chain transactions.  Another is a hard fork to add more decimal places, which would presumably be uncontroversial.  See Will we ever need smaller amounts of Bitcoin than a Satoshi?


Bech32 encoding, apart from the checksum, is a simple matter of converting base-256 (8-bits) to base-32 (5-bits). Base-256 is the byte array (octet string) that you get from a hash function. Only focusing on first 3 bytes of the hash:

as hex    = 0x18     0x63     0x14
as bytes  = 24       99       20
as binary = 00011000 01100011 00010100

In order to convert the above base-256 (8-bits) input to base-32 (5-bits) we start from the most significant bit and select 5 bits at a time until we run out.

12345123 45123451 23451234 ...
00011000 01100011 00010100
(00011) (00001) (10001) (10001) (0100 ...

For a bech-32 address there is an extra step here after the base conversion is done. That step is to append of the "witness version" to the beginning of this group as an already converted value in base-32 (since witness version is defined from 0 to 16 inclusive it is already in range).

[00000] (00011) (00001) (10001) (10001) (0100 ...

This final result can be converted to an array of numbers that are between 0 and 31

0, 3, 1, 17, 17

To convert this "number" array to human readable format we print the corresponding character from the bech32 charset (qpzry9x8gf2tvdw0s3jn54khce6mua7l)

0->q, 3->r, 1->p, 17->3, 17->3 ...

P.S. There is a checksum calculation that I skipped to keep it simple but it is just another appended set of 5-bit values at the end of what we have in last step.


How to getreceivedbyaddress() with the python-bitcoinlib? I'm trying to use the python-bitcoinlib in my bitcoin project. I now understand how I can send a payment, but I can't find anything similar to the getreceivedbyaddress() command I normally used.

Isn't it present in the python-bitcoinlib, is there a workaround, or am I simply overlooking something? All tips are welcome!

It's probably not in there right now; look at the code in bitcoin/rpc.py and add it! Basically you just need to follow the same pattern as other RPC calls. When you're done send me a pull-req on github.


How many transactions will be created in a Lightning Network channel In a typical Lightning Network channel, how many Bitcoin transactions will be created per state of the channel that may end up on-chain ?

The number of transaction per Lightning Network channel may change depending on two main
factors:

The type of channel used.
As a protocol in development, the Lightning Network specifications may change. This
includes the specification of the transactions used for each channel state. For instance,
the "Anchor Outputs" proposal which was merged in 2020 included a complete rewrite of the
transaction tree.
The number of payments being currently routed through the channel (HTLCs in flight).

The following description is for a non-"anchor outputs" channel.
Without any in-flight HTLC
The channel begins with:

The funding transaction (onchain)
Two commitment transactions (one for each participant)

So we are at 3 transactions. But there is a quirk (there is always a quirk!), each of
the transaction pays to:

The remote party
The local party after a delay OR the remote party with the revocation key.

Since i want the count to showcase the complexity of the client implementation, i'm going
to include the special transactions in the counter.
Note that the specifications call the "simple outputs" (basic P2WPKH, as an onchain
payment) as being resolved, and the "contract outputs"[*] to not be resolved until a
"special transaction" spending it is confirmed.
It therefore brings us to 7 transactions:

1 revocation transaction per party
1 delayed transaction per party

Now, let's add some real complexity.
Adding the HTLCs
Lightning Network channels are bi-directional, therefore both parties can offer or
receive an HTLC. Intuitively.. HTLCs are translated into outputs than can be in both
these states (offered or received) in both the commitment transactions.
So you can have:

An HTLC offered by the local party
An HTLC received by the local party
An HTLC offered by the remote party
An HTLC received by the remote party

As well as any combination of the above.
For an HTLC offered by the local party, an "offered-htlc" output is added to the local
party's commitment transaction and a "received-htlc" output is added to the remote party's
commitment transaction.
Each of these outputs are the first stage of the onchain HTLC resolution, they are later
finalized in a second-stage pre-signed "HTLC transaction", and finally sweeped by a
"special transaction" (the same kind as those in the first section: delayed or revocation).
An offered HTLC output in the local party's commitment transaction may be spent by:

A "preimage transaction" (to the remote party -- ie "successful-but-quite-long payment")
A revocation transaction (to the remote party -- you need to prevent cheating at each step of the process)
A pre-signed "timeout transaction" which may then be spent by either:

A delayed transaction (to the local party -- ie "cancelled payment")
A revocation transaction (to the remote party -- we can still cheat at this point!)

A received HTLC output in the local party's commitment transaction may be spent by:

A timeout transaction (to the local party -- that's the cltv_delta configuration on your node)
A revocation transaction (to the remote party -- as usual)
A pre-signed "success transaction", which may then be spent by either:

A delayed transaction (to the local party -- ie "successful-but-quite-long payment")
A revocation transaction (to the remote party, -- still to decincentivize cheating)

This brings us to 10 new transactions per commitment transaction for two HTLCs in flight
(one in both direction).
Summing it up
For the example i've showcased above it brings us to:
7 # Nuked channel
+ 10 # htlc offered on one side, received on the other one
+ 10 # htlc received on one side, offered on the other one
= 27

That's for one channel state (the next one will use new keys!) for the common scenario of
being currently forwarding a payment in both directions.
To answer your question precisely, the number of transactions per state may vary between
7 (no HTLC) and 7 + 483 * 5 * 2 = 4837 (maximum number of HTLCs in both directions).
Note that the latter is unrealistic as the maximum number of in-flight HTLCs is currently
bounded on implementations in order to avoid DOS.

More resources:

The BOLTs if you want all the nitty-gritty details:
#5
(onchain) and
#3
(transactions) cover this.
This post by Rusty Russell -- outdated but still
gives the intuition. Touchs also the challenge of managing the keys.

[*] Terminology mine on this one


What can a pool operator do with their miners' hashpower? This issue came up in this question - Are the miners concerned with what the pool operators do with their hashpower?. What can a pool operator do with their miners' hashpower?

Commit double-spends, either themselves or for hire. If the transactions reversed are accepted with 0 confirmations, they don't need a very high hashrate to do this with some effectiveness.
DoS attack on Bitcoin, by including no transactions in blocks and rejecting all other blocks. This requires ~50% to be done effectively.
Similar attacks on alternative blockchain-based currencies, which is easier since they are usually smaller.
Merged mining - not nefarious in itself, but should be done only at the agreement of miners.
Coin mixing - paying generated coins to people in need of fresh coins, receiving from them independent funds to be paid to miners. (Illegal if done for the purpose of money laundering)
Include too few transactions, making it harder for people to have their transaction accepted.
Include too many transactions in a possible future scenario where a transaction fee equilibrium is obtained by a gentleman's agreement not to include transactions too cheaply.
Things unrelated to Bitcoin, such as password cracking (generally possible only with custom mining software).


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.


getbalance says 0 for incoming TX even though 0-conf is allowed > $bitcoin_rpc.getnewaddress("myaddress", "bech32")
 => "bc1q9kvfyjxtk9tvkzgpkf4x8zs42sddwlyanz3z6z"
> $bitcoin_rpc.getbalance
 => 0.0
> $bitcoin_rpc.getbalance("*", 0)
 => 0.0
> $bitcoin_rpc.listtransactions
 => [{"address"=>"bc1q9kvfyjxtk9tvkzgpkf4x8zs42sddwlyanz3z6z", "category"=>"receive", "amount"=>0.00025, "label"=>"myaddress", "vout"=>1, "confirmations"=>0, "trusted"=>false, "txid"=>"ad922349668c17c3ab47081f6dbc6e7e8f68473840146bfdd18f35f7d0bca216", "walletconflicts"=>[], "time"=>1574217056, "timereceived"=>1574217056, "bip125-replaceable"=>"yes"}]
> Time.now.to_i
 => 1574217344

What's the magic behind it? Since confirmation=0 is default, I would expect a return value of 0.00025.

getbalance returns the balance that your node currently considers spendable. According to your console output, the transaction that sent you the output was flagged as "bip125-replaceable"=>"yes". Since a transaction flagged as replaceable can be amended or retracted by the sender until it gets confirmed, an output from such a transaction will not be considered reliable and not used as an input until confirmed.


what's CCoinsViewDB::GetHeadBlocks for? I have google a lot, there exists little information, confused with the code comments

Retrieve the range of blocks that may have been only partially written. If the database is in a consistent state, the result is the empty vector. Otherwise, a two-element vector is returned consisting of the new and the old block hash, in that order.

why there exists old & new block, their function?

Bitcoin Core does this thing called non-atomic flushing. What that means is that the database, instead of being updated atomically (i.e. everything is written at the same time, or nothing is written), has data written to it over time. If the database crashes, with non-atomic flushing, there will be some data written, and some data that is not written. This is different from atomic flushing where either all of the data was written, or none of it was.

Non-atomic flushing allows Bitcoin Core to skip validation of things it has already validated and then just flush things to the database later after a crash or unclean shutdown. But in order to know where it has validated up to, it has to store that block hash (where it has validated up to and where it is flushing up to). It also has to store the block it started at (the block the database knew up to when flushing began).

This is where GetHeadBlocks() comes in. When Bitcoin Core begins flushing, it first writes those two blocks, the old one where the database head was at, and the new one, where the database head will be once flushing finishes. In the event of an unclean shutdown or database crash, these values are already written to the database so it can pull those out of the database, know where its last known good database state was at, and know where it has validated up to so it can skip full validation and just build the database data and flush it. If there was no unclean shutdown or crash, GetHeadBlocks() would return an empty vector.

For example, suppose the database was at block 50, and it is flushing to block 60. When it begins flushing, the hashes of blocks 50 and 60 are written to the database. Suppose that the computer suddenly loses power when it has only flushed up to block 55. When the node comes back on, it will call GetHeadBlocks() and get the hashes of blocks 50 and 60. Now it knows that it was mid-flush when it uncleanly shutdown. So it then rebuilds what the database would be from blocks 50 to 60 but does not perform full validation. It then flushes the remaining data and removes the hashes of blocks 50 and 60 from where they were written.


Current bitcointalk.org probation period and rules I see this, but don't understand and is a bit old Can't post on bitcointalk.org.

What are bitcointalk.org current probation rules/period?

Is it true that you have to pay to participate on that forum?

Don't see any restrictions here: https://bitcointalk.org/index.php?topic=1689727.0 but maybe I didn't notice.

What are bitcointalk.org current probation rules/period?

Each rank has certain restrictions that are removed as your rank increases. Newbies have the most restrictions. They can only post once every 360 seconds (6 minutes), can only have plain text in their signatures, PMs will have a warning saying that the person is a newbie and potentially a scammer, and a few other things. The restrictions for each rank are listed here: https://bitcointalk.org/index.php?topic=178608.0

Newbies can post in any part of the forum though. The newbie jail has been removed.

  Is it true that you have to pay to participate on that forum?

For the majority of users, no, you do not have to pay to participate on Bitcointalk. The only people who have to pay are those who are registering from "evil" IP addresses. "Evil" IP addresses are IP addresses which many "evil" things have been done from. "Evil" things means that multiple accounts were registered from an IP address and were later banned from the forum. Accounts can be banned for many reasons, usually spamming. In order to register a new account from an IP address with evil points, you will need to pay a small fee. This is an anti-spam and anti-DoS mechanism.

Most evil points end up being assigned to proxies, VPNs, and TOR exit nodes as those are what spammers use to register their accounts to hide their identities. If you are not registering using one of those things, then you likely will not need to pay any fee to register.


Which iPhone bitcoin wallets let you scan a watch only address and sweep addresses? Currently Mycelium on Android lets you create watch only addresses by scanning the public key QR code and import paper wallet private keys. But the iPhone  iOS version doesn't. What apps are there for iOS that lets you do watch only and import from a paper wallet?

There are other wallets on iOS but these additionally support xpub import, so you can generate addresses for recieving, without private keys:

BitWallet
ArcBit


What's the best practice for creating and maintaining an address index? I am working on a Blockchain.info-like block explorer, and I have some questions regarding best practice for data retrieval. Bitcoin Core stores and serves all blocks and, if txindex is set to 1, all transactions too. It doesn't, however, have an option where you can tell it to maintain an index of all addresses.

I wrote a script that iterates through all blocks and inserts the address/txId key pairs into a MySQL table indexed on address. It maintains the index by polling for new blocks. The program doesn't yet take into account unconfirmed transactions, and chain reorganizations can result in invalid data. Is there a better way to do it?

I'm not sure that your question matches your title, but anyway:

Regarding polling the blockchain, you should take a look at the '-blocknotify' option available in the 0.8.2 daemon.  This will send you a block hash every time that the latest block changes.  You will need to handle the situation where the valid chain changes for any reason within whatever script you write (check block height and go from there).

Unconfirmed transactions are another matter; there's nothing right now in the official daemon which will help you here so if you do want these you don't have much choice other than to poll or to patch the official daemon to send you details of unconfirmed transactions.  What you do with them is very much dependent on what you are trying to achieve, however.