text:
HD wallet attack
I've been reading about HD wallet derivation key mechanism.
I understood that if an attacker gets somehow a child's private key plus the chaincode used to derive that child' key, then he could calculate the parent's private key.
How could that be possible? Through a sort of brute force attack?
Furthermore, how can the hardened derivation scheme neutralize this problem by using the parent's private key instead of his public key as input for the
HMAC-SHA512 functions?

Here is a solid answer by Andrew Chow. Can we derive parent’s private key using child’s private key?
As for the specific questions:

How could that be possible?

Once again, Andrew Chow: Derivation of parent private key from non-hardened child

Furthermore, how can the hardened derivation scheme neutralize this problem by using the parent's private key instead of his public key as input for the HMAC-SHA512 functions?

(From the linked post above) Hardened derivation protects against this because it generates the child private key by hashing the parent private key. However this also means that you cannot generate the child public key from the parent public key.

So...the hardened derivation solve the problems because an attacker with just a child's private key plus the chaincode can't perform the HMAC-SHA512 (he should also have the parent's private key). Correct?

To the best of my knowledge and understanding (knowing i'm not an expert) that is correct. I don't think many people could answer with absolute certainty on here outside of Andrew Chow. There needs to be a third component to reliably crack the hardened wallet. My suggestion, it you require an expert answer would be to pose this question within the "Derivation of parent private key from non-hardened child" post above and hope that Andrew responds. (Forgive me if this is not how this forum is designed to work and i'm providing poor guidance on getting the attention of an expert. Still new here!)


text:
c-lightning channel announcement/establishment issue
I've been running a c-lightning node over Tor with 2 open channel for a few months and it still hasn't forwarded any payment. Maybe it's normal due to the low amount of liquidity provided by my node, but I noticed my channels status shows this log:
CHANNELD_NORMAL:Funding transaction locked. They need our announcement signatures.

To me it appears like my channels haven't been publicly announced yet.
This is my config file:
network=bitcoin
alias=******
rgb=******
bitcoin-rpcuser=bitcoin
bitcoin-rpcpassword=******
bitcoin-rpcconnect=127.0.0.1
bitcoin-rpcport=8332
announce-addr=******.onion
bind-addr=127.0.0.1:9735
proxy=127.0.0.1:9050
daemon
log-level=debug
log-file=/home/bitcoin/.lightning/debug.log

Am I missing anything?

I've been running a c-lightning node over Tor with 2 open channel for a few months and it still hasn't forwarded any payment.

With two channels that's not surprising.

but I noticed my channels status shows this log:
CHANNELD_NORMAL:Funding transaction locked. They need our announcement signatures.

The announcement signatures are retransmitted upon reconnection, you could try to restart your node.
Simple test to check that your announcement propagated : check on an explorer (1) if your node appears. If it does, then you node is publicly announced and you not forwarding payment is just because of a lack of liquidity (or fees !) :p.
(1) Here are some explorers :

https://lightning.chaintools.io/
https://ln.bigsun.xyz/
https://explorer.acinq.co/n/
https://explore.casa/nodes/
https://1ml.com/node/

Yes, my node appears publicly, so I must resign myself, it's probably about lack of liquidity.

When the channel is opened the opening side of the channel chooses if the channel should be private or announced. Well actually the other side can also choose not to accept public channels. Maybe that has happened with both of your channels.
From the information you have we can only guess / speculate.
 If you want to you can try to open a channel with my node (details at https://ln.rene-pickhardt.de - the node does not speak tor tough) but I could look in my logs if necessary and we could together debug what is going on.

source: Stack Exchange

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

sort: votes


text:
Doubt on lightning channel opening
It's 5 days since I opened my first (and unique, for now) lightning channel.
Unfortunately it seems that only me have funded the channel while the counterparty didn't, so the channel it's actually a unidirectional channel.
Indeed the output of the command lightning-cli listchannelsshows direction: 1 (I'm running the c-lightning implementation).
Is it normal that the counterparty doesn't have funded the channel yet after 5 days or I should think I've misconfigured my channel?

Channel funding (and the distribution of funds) is determined at the time of channel opening. Once opened, a party cannot ‘add funds’ to the channel, this would require opening a new channel.
If you opened the channel and did not specify that some number of sats should be pushed to the remote node at the time of opening, then the channel will open with the entirety of the balance on your side. Note that pushing sats to the remote node is equivalent to making a payment to the remote node.
If you send a payment using the channel you opened, you will gain an ~equivalent amount of incoming capacity.
The current BOLT spec does not include multi-party funding, but this feature is planned for future updates to the spec.

So, as I thought, I misconfigured the channel. But now the point is: how can I open a bidirectional channel and start to forward payments? Where can I specify that "some number of sats should be pushed to the remote node at the time of opening"? The 'fundchannel' command of lightning-cli doesn't seem to have that option

At this point in time, every channel starts unidirectional (unless you push funds to the remote node); once you make a payment it will become bidirectional. Keep in mind: pushing sats to the remote balance will mean you are giving those sats to the remote node. I’m guessing you have the goal of earning routing fees, but the reality of the current network is that unless you are a well positioned and highly liquid node, you will likely not route payments. Certainly, any routing fees you could earn would be less than whatever amount of sats you push to the remote node at channel opening.

I am more familiar with lnd, which allows you to specify a number of sats to push to the remote node during channel creation, lightning-cli may not have that option. In any case, you’d be better served by just making a normal payment to send some sats to the other side of the channel. At least that way, you can potentially receive something for this payment, rather than just giving sats to the remote node for no reason.

It is worth mentioning that by using the push_msat part of the protocol was intended for testing only, and wasn't supposed to be exposed to the end user at all. You're basically giving away some of your funds to a complete stranger. The canonical way to balance a channel in c-lightning is to have somebody open an incoming channel and then using the rebalance plugin (https://github.com/lightningd/plugins/tree/master/rebalance) to balance those channels by paying yourself along a circular route.

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


text:
Blockchain and ISO/OSI
I've heard blockchain is built on top of the ISO/OSI stack. Does it means blockchain belongs to the layer 7 (Application layer) of the Osi architecture?

I've heard blockchain is built on top of the ISO/OSI stack

This isn't really true in any meaningful sense.
Before the Internet became really ubiquitous with the invention of the World-wide-web (HTTP etc), there were two major competing global-scale inter-networking protocol suites. The Internet is based on a four-layer network model. The competing X25 networks were based on the ISO/OSI 7-layer model. However X25 lost out to the Internet Protocol Suite (often referred to as the TCP/IP protocol suite)
It is inappropriate to map any Internet application to the ISO/OSI model although people often do this.
The Internet model's 4 layers are typically described as:

Application
Transport
Inter-Networking
Datalink or Network-Access.

The Bitcoin/Blockchain protocols are an application-layer protocol.
Transport layer protocols are typically TCP or UDP although other, rarely used, protocols exist.
Internetworking is mostly IP (IPV4 and IPV6) and ICMP
Datalink layer protocols vary considerably and are usually some form of Ethernet at the edges of the Internet (i.e. the LANs) but a variety of different protocols are used as you progress towards the core.

References

RFC795, TRANSMISSION CONTROL PROTOCOL, 1981

 Protocol Layering

                +---------------------+
                |     higher-level    |
                +---------------------+
                |        TCP          |
                +---------------------+
                |  internet protocol  |
                +---------------------+
                |communication network|
                +---------------------+

                        Figure 1

...
+------+ +-----+ +-----+        +-----+
|Telnet| | FTP | |Voice|   ...  |     |  Application Level
+------+ +-----+ +-----+        +-----+
      |   |         |             |
     +-----+     +-----+       +-----+
     | TCP |     | RTP |  ...  |     |  Host Level
     +-----+     +-----+       +-----+
        |           |             |
     +-------------------------------+
     |    Internet Protocol & ICMP   |  Gateway Level
     +-------------------------------+
                    |
       +---------------------------+
       |   Local Network Protocol  |    Network Level
       +---------------------------+

                  Protocol Relationships

                        Figure 2.

Bitcoin uses TCP which would put it at layer 7 of that description, but there's nothing particular that requires it. The transport layer for data is orthogonal to the system, it could alternatively use raw frames, carrier pigeons, or have the packets inked onto the heads of slaves. Systems exist which allow for data to be transfered through a TV satellite relay for example, which skips the networking layers entirely.


text:
SHA256 vs RIPEMD160 in SegWit
In Pay-To-Witness-Public-Key-Hash (P2WPKH), the RIPEMD160 hash function is used to hash the public key of the recipient in the locking script.
On the contrary, Pay-To-Witness-Script-Hash (P2WSH) uses the SHA256 for hashing the redeem script.
Why has this difference been made?
Just to differentiate the two types of witness programs?

The P2WPKH actually uses the HASH160 hashing algorithm, which is just RIPEMD160(SHA256(pubkey)).
The reason for using SHA256 is mentioned in BIP141:

The increased size improves security against possible collision
  attacks, as 2^80 work is not infeasible anymore (By the end of 2015,
  2^84 hashes have been calculated in Bitcoin mining since the creation
  of Bitcoin). - BIP141

And yes, like you said, the witness program is determined not only by the version 0x00 byte, but also the length of the program. See BIP141 - P2SH

As the protocol is upgraded with soft-forks changing script interpreter behaviour, the script-machine is extended with additional runs. Each new upgrade brings a new script run with new rules, whilst previous script runs continue to be evaluated according to older rules. Arguments need to be supplied to determine whether the newer script runs are to be executed.
Native witness transaction introduced script types P2WPKH and P2WSH, which have mutually exclusive evaluation paths. Following the "standard" input and output script run, both script types evaluate to true, but no signatures or embedded scripts are evaluated yet.

The P2WPKH output script pattern will cause the script machine to evaluate witness and an original P2PKH script with the same public key hash. This script expansion is implied by the P2WPKH script
pattern ([00] [20B]).
The P2WSH output script pattern will cause the script machine to
evaluate both embedded and unlocking scripts loaded from the witness. No implied script expansion here. The script pattern ([00] [32B]) can clearly be differentiated from the the P2WPKH script.

Deciding which of the two evaluation paths should be followed requires an argument which is not explicit in either script type operations. This argument is supplied by the hash digest size.
Btw, this argument cannot be supplied in the witness data, because valid input scripts (now in the witness) do not follow a unique, recognisable pattern (e.g. I can always add [data_push] [drop] without affecting validity).


text:
Private key generation doubt
I read that the private key pk has to be any number between 1 and n, where n is almost 10^77.
Since pk' s function is practically to be used as a scalar for multiplying the generator point G, why does it have to be strictly less than n?
I've thought that is because the math behind secp256k:
inside a order-n group, if I multiply times x a number A (with x > n), it's equivalent to multiply the same number A times y, with y =  x % n. So y will be extremely less than x, making A easier to be discovered.
Is this argument correct?

You're right, there is no strict requirement that the private key is strictly less than the group order.
However, it is required that the resulting public key is uniform, which implies that (x % n) must be uniformly distributed between 1 and n-1 inclusive (or at least indistinguishably close to uniform). The easiest way to accomplish this is by saying that the private key must be picked directly uniformly between its bounds. However, you could just as well say you pick a private key uniformly between 1 and 1337*n-1 (except no multiple of n).
To elaborate on "indistinguishably close to uniform": specifically for the secp256k1 curve (which is used in Bitcoin's signatures), the curve order is very close to 2^256, and in general you won't ever generate a 256-bit number that is >= n. This is not the case for all elliptic curves however, and biasing private keys can actually threaten security.

For size, n is approximately 2^32 shy of 2^256

@Anonymous That's the field size. The group order is around 2^256 - 1.27*2^128.


text:
Low-s value in bitcoin signature
What are the problems related in using the "normal" ( bigger than N/2) value of the s number in transaction signature and why we use the lower one?
Is it about the math behind the ecdsa?

Details are in BIP 146:

We require that the S value inside ECDSA signatures is at most the curve order divided by 2...
...
A high S value in signature could be trivially replaced by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.

Signatures encode two important values for verification r and S. If (r, S) is a valid signature, then so is (r, -S), which is equivalent to (r, curver_order -S).

Maybe I've understood. Before BIP 146, a relay node could invalidate my trx using the higher s value, which is mathematically equals, but it would have result in a completely different trx hash. So low-s value is a care for the trx malleability?

Yes, both transactions would be valid, but with different signatures and TX hash. Yes, it's against TX (and TXID) malleability @dc_Bita98


text:
Bidirectional channel opening in c-lightning
With the current version of c-lightning is it possible to open a bidirectional channel funded by both parties?
I managed to open a channel with fundchannel command, but that seems to be a unidirectional channel, since only I provided the funds.
I don't understand how the entire network can work if we can open channels funded by just one party.

Once you send a payment through your channel, it will become bidirectional. Multiparty channel funding is planned for a future BOLT spec. From @cdecker's comment on your other question: The canonical way to balance a channel in c-lightning is to have somebody open an incoming channel and then using the rebalance plugin (github.com/lightningd/plugins/tree/master/rebalance) to balance those channels by paying yourself along a circular route.

So basically the only way now is to wait for an incoming channel and then use the rebalance plugin. Thank you for your patience, really appreciate it

The rebalance plugin isn’t entirely necessary, if someone opens a channel to you you’ll have incoming capacity, rebalancing plugin or not. Once you send a payment you will have receiving capacity as well.

The incoming channels are those showed by the listchannels  command, aren't they?

No you have to use listfunds or listpeers. The listchannels command lists publicly known channels on the network.

You can also rebalance a channel by using a submarine swap for example offered by zigzag.io

There seems to be a mix in notation. Payment channels on lightning are bidirectional by design. However that does not mean that funds can always flow on both directions. Currently channels are funded by one party an as such can not receive funds after opening. As was mentioned in the comment what you mean is called a dual funded channel.
As soon as you use a channel to make a payment the balance changes and you will be able to receive funds. Since the lightning network is in use it is fair to assume that most channels by now are somewhat balanced in the sense they can send and receive. So at this time it might just be a matter of opening one channel t be able to pay some party on the network and thus have the ability to receive money again. There are services that reimburse you onchain once you pay their invoice. This can be used to have a balanced channel.
In deed in the very beginning with the channel design there was the cold start problem. But apparently this has been overcome. Though I agree with you it is hard to imagine that we have been able to do so without dual funded channels.
BTW lisa neigut is pretty far of implementing the dual funded channel protocol for c Lightning. So clightning will probably be the first implementation supporting dual funded channels.

I was wrong about a lot of things concerning the lightning network before your explanation, Thank you so much, you went very deep in the topic.


text:
Difficulty in verifying bitcoin-core signing keys
How can I verify bitcoin0.19 signature bwith gpg?
I read I should use gpg --recv-keys signingkey, but I don't understand where is the file signiggkey. I tried to download Bitcoin Core Release Signing Keys v0.11.0+ but what I got is a .asc file, which I don't know how to use

With the .asc file, you can do
gpg --import <asc filename>


text:
Does bitcoin validate transactions against the mempool?
I want to know whether or not bitcoin checks for the existence of transactions in the mempool as one of the many validation rules it performs for new blocks.
If a transaction most exist in the mempool when a new block is received, how is this rule applied for blocks received during block synchronisation with peers, considering transactions in older blocks will not exist in the mempool?

A transaction that has been included in a block does not need to be in a node's mempool in order for that node to validate the block. Each block contains the transactions, so by downloading and validating a block, the node will have received a copy of all transactions in it (so that it can validate the transactions, as part of validating the block).
As you mentioned, there would otherwise be problems syncing old blocks, because the transactions in those blocks would be invalid if you tried to add them to the mempool today (because their inputs have already been spent!).
Further, a miner can include a transaction in a block, without having ever broadcast that transaction to the network otherwise. So in that case, no other node would ever have included the miner's transaction in their mempool!
Note that compact blocks (BIP 152) is an improvement to the block-relaying process, that allows nodes to compare a new block's transactions to their local mempool, and thus avoid having to re-download transactions they already know about.

A rule that a transaction must exist in the mempool for a block to be considered valid would be a disaster. That would mean there would be no way to guarantee that honest nodes ever agree on which chain is the longest, valid chain because there is no mechanism to make nodes agree on which transactions go in the mempool. Malicious users could trivially cause chain splits just by sending conflicting transaction to opposite sides of the network causing mempools to disagree and thus honest nodes to disagree on which blocks are valid. Disaster!


text:
Can't use bitcoin-cli commands, error message says "could not connect" from localhost
I am simply trying to run bitcoin-cli getinfo on the same machine that my bitcoin node is running on (with bitcoind -daemon)
my bitcoin.conf file is as follows:
server='1'
rpcuser='username'
rpcpassword='password'
rpcport='8332'

The error message I receive is:
error: Could not connect to the server 127.0.0.1:0

This error is confusing me in two ways. First, my home network uses an Xfinity gateway (combined router/modem), and the local ip addresses look like 10.0.0.xx, not 127.x.x.x. Second, why is the error suggesting that it tried to connect on port 0? I have specified in bitcoin.conf that the rpc port is 8332. In this current state I can run a node, but I cannot make any rpc calls, rendering it useless for my purposes. Any advice on how to fix this issue?

Bitcoin.conf does not use quotes in its definition of options. Your lines need to resemble server=1 rather than server='1'. Your port number being zero is an artifact of this, which will not work as you need root permissions to bind to ports below 1024, which bitcoind does not and should not have.
127.0.0.1 is the loopback address used when you're connecting to yourself, rather than a normal routable IP address. For safety's sake the RPC port is not by default enabled to bind to routable IP addresses, such as your 10.0.0.0/24 range. By default, it will only bind to 127.0.0.1 and subsequently only be accessible on the host it is running on.


text:
Following SegWit implementation, is BIP-146 signalling and implementation still on the docket?
Is BIP 146, which defines using the low S value, still on the docket to be signalled and implemented given that SegWit fixed the txid malleability issue by moving the witness outside the transaction? I'm asking because it can fix the wtxid malleability which now requires re-syncing of transaction data when it is changed from what it was originally relayed.
Also, will the implementation be a soft-fork which would treat this transactions as non-standard but miners can still include them in the block, or will it treat the transactions with high S value as invalid?

BIP146 and BIP147 were written originally to be activated along with SegWit, but after feedback, only BIP147 was included. 146 should probably be marked withdrawn.

Bitcoin-core already enforces low S-values as a standardness rule for transaction relay, but making a transaction non-standard does not cause a softfork.
BIP-146 does call for a softfork by making high S-values in tx signatures invalid, not just nonstandard.
The BIP also states that the majority of txs on the network already adhere to the low S rule, as of Aug 2016. To quote from it:

The reference client has produced LOW_S compatible signatures since v0.9.0, and the LOW_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.

If transactions are treated invalid instead of non-standard, wouldn't it result in rejection of blocks which include such transactions, unless these transaction use a different version? That means, there would a split in the chain

Yes, thats why I mentioned BIP146 calls for a softwork, and it says so in the second line of the BIP. If a transaction is considered standard vs non-standard between clients on the network, there will not be a split if the transaction is included in a block. But if the transaction was considered valid vs invalid between clients, then it would cause a split if included in a block.

I agree, but if everything else remains the same and if Low_S signature is implemented with transactions not using it being treated invalid, then it will result in a hard fork. Soft fork is forward compatible so that clients that have not been updated can still function in the current consensus.

Softforks are backwards compatible, rules are restricted. Old clients will remain on the network, but if a miner creates a block using an older client's rules, then the newer clients will consider that block invalid and a network fork may occur.

restriction of rules makes sense.

Are you missing a "not" in your first sentence? Changing the standardness is not a soft fork, right?

@Jannes ah, woops! Good catch on the typo, edited to fix. Thanks.


text:
Remote node signature for HTLC-success and HTLC-timeout transactions
According to BOLT #3, when constructing a HTLC output in the version of the local node (both received and offered HTLC), it requires that the payment to the local node is locked with CHECKMULTISIG opcode that requires both localhtlcsig and remotehtlcsig in order to spend it.
As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint).
So the question: suppose after I receive an HTLC from a node and I successfully pass it to the other nodes, the node that sent the HTLC to me became unresponsive. Now I will need to broadcast my version of the commitment transaction to the Bitcoin blockchain so that I can claim the funds that are locked with the payment_hash (when I receive one). But, in order to spend that output, my witness stack will need to have 0 <remotehtlcsig> <localhtlcsig> <payment_preimage>. Now, if the remote node is offline, how will I get my hands on the remotehtlcsig in order to get back the funds locked in the HTLC?
Just to provide additional details, below is a local node version of the received HTLC output according to BOLT #3
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # To local node via HTLC-success transaction.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node after timeout.
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

As far as what I have seen, nodes do not exchange their htlcsignatures (although we can derive the htlc public keys through basepoint).

I believe you have overlooked the commitment signed message from bolt 02. From there I quote:

When a node has changes for the remote commitment, it can apply them, sign the resulting transaction (as defined in BOLT #3), and send a commitment_signed message.

type: 132 (commitment_signed)
data:
[32:channel_id]
[64:signature]
[2:num_htlcs]
[num_htlcs*64:htlc_signature]

While we already see that signatures for all htlcs are transferred we can find the requirements further down :

A sending node:
  ...
  MUST include one htlc_signature for every HTLC transaction corresponding to the ordering of the commitment transaction (see BOLT #3).

I believe a node SHOULD NOT  forward the htlc before it validated the signatures from all the htlcs of the received commitment signed.


text:
BOLT #7: Can receiving node requirements in channel_update message give rise to malicious attacks?
Following requirements have been placed on the receiving nodes related to the channel_update message in BOLT #7.

if timestamp is NOT greater than that of the last-received channel_update for this short_channel_id AND for node_id:

SHOULD ignore the message.

otherwise:

if the timestamp is equal to the last-received channel_update AND the fields (other than signature) differ:

MAY blacklist this node_id.
MAY forget all channels associated with it.

According to my understanding the receiving node will first check the signature of related the dsha256 of the entire message before verifying the timestamp and not check the remainder of the message if the signature is invalid. So if other fields apart from signature are changed, then the signature will not be valid (as the message has changed) and the node will not process the message further.
Now here's the thing I'm wrestling with: If the node still plans to check the message (as shown in the quoted text above) even though the signature is invalid and then go forward to blacklist the node, it can give rise to DoS attacks. A malicious nodes will just take a channel_update message that it received in the past from a node, change some fields like htlc_minimum_msat and rebroadcast to other nodes. Those receiving nodes will then simply blacklist the node_id without any wrongdoing from its part as (1) the timestamp is equal to the one it received in the past, (2) signature is same AND (3) other fields have changed.
So I feel that this check is simply not needed and if the software goes on to process this message despite checking the signature then it can give rise to attacks from malicious parties. Where am I incorrect in my thought process?

According to my understanding the receiving node will first check the signature of related the dsha256 of the entire message before verifying the timestamp and not check the remainder of the message if the signature is invalid. So if other fields apart from signature are changed, then the signature will not be valid (as the message has changed) and the node will not process the message further.

This is the correct understanding. It is stated earlier on in the receiving rules. Although the client implementation must read at least the chain_hash and short_channel_id from the message in order to retrieve the public key associated with that channel from its storage (if it exists), in order to perform the signature check.

if signature is not a valid signature, using node_id of the double-SHA256 of the entire message following the signature field (including unknown fields following fee_proportional_millionths):

MUST NOT process the message further.
SHOULD fail the connection.

The checks on the timestamp and other field are performed only if the signature is valid, and the purpose of the check is to prevent spam from a valid signer. It is assumed that more than one channel_update in the same second is a DoS attempt, and therefore, the node responsible for signing such messages ought to be blacklisted.

That's what is confusing me. It is said in the documentation that if: (1) time stamp is unchanged; (2) signature is unchanged; (3) but other fields are changed as compared to prior channel_update message then, blacklist the node_id. However, if other fields are changed, then the signature can no longer be valid, so the node should not parse the message further and hence will not detect that the what has been changed and what is not. So there is no way the node can be blacklisted.

So either that rule in the BOLT #7 is redundant as the node would never reach to validating that rule if signature is invalid otherwise it might lead to DoS attacks as I mentioned

The rule is saying that you should not accept multiple channel_update with the same timestamp but different information (particularly the fields below timestamp in the message definition). It is possible to have the same information, same timestamp, but different signature, and the signatures all be valid, because the signature is generated using some random number k. The signer could sign the same details but using a different random number, and this should not result in blacklisting.

I see what you are trying to say and its fair. But that stage of checking will never reach as signature validation is done first, so why have it?

Stated above. If a valid signer signs multiple channel_update per second, with different information, then signature validation will pass, but the messages will be classed as spam and the signer will be blacklisted.

Yes, but if that guys is signing the channel_update message with a valid signature then it will be DIFFERENT for every message he sends if he changes the data. So, changing the data cannot have the SAME signature as it is invalid. The condition says, the signature should be same as previous and data should be different. This is not possible without invalidating the signature

That is not what it says. The check for the timestamp and equivalent data will not even occur if the signature is invalid. These checks are conditional on the signature being valid. An invalid signature will result in ignoring the message and disconnecting from the peer who sent it.

Let us continue this discussion in chat.

if you look at the format of the channel_update message you will realize there is no field node_id in the message. c.f.:
type: 258 (channel_update)
data:
[64:signature]
[32:chain_hash]
[8:short_channel_id]
[4:timestamp]
[1:message_flags]
[1:channel_flags]
[2:cltv_expiry_delta]
[8:htlc_minimum_msat]
[4:fee_base_msat]
[4:fee_proportional_millionths]
[8:htlc_maximum_msat] (option_channel_htlc_max)

Thus the way I read the rfc is that the peer might decide to blacklist the node_id of their peer (the one who propagates the forged / wrongful channel_update message) In this way one would not create a DoS attack to some random node_id (the victim) but for oneself which is exactly how it i should work.

I think the channel_update message works by cross-checking it with channel_announcement message in the short_channel_id field. Because there is a requirement to discard the channel_update message that does not match the short-channel_id of the previously received channel_announcement message. It is also said that: "The node_id for the signature verification is taken from the corresponding channel_announcement: node_id_1 if the least-significant bit of flags is 0 or node_id_2 otherwise."

So I think in that sense, the node_id refers to the one that signs the message rather than the one that broadcasts it

ouch. that seems right. If I find the time I will look this up in the code base because then we have certainty how it is meant / understood.

Thanks Rene! I'm still working my way through the BOLTs! will go through the code after that


text:
Malicious full nodes causing denial of service attacks
To control >51% of the mining power in bitcoin is impractical due to the immense investment that will be required. Also, The Bitcoin Core client has DoS protection against malicious nodes forwarding a flood of transactions. But what would happen if an attacker who has placed several full nodes across the world, does not forward the transactions to the other honest nodes? There are over 10K full nodes on the bitcoin network. An attacker can place 10x the amount of these nodes spread very efficiently in terms of geographic dispersion so that they are one of the first to see the transactions broadcasted. In order to prevent the malicious node from getting dropped by the honest node, it can relay transaction once in a while so as to keep the connection active. Given, that there are 10x more malicious nodes than honest ones, it might highly likely be the case that miners do not see the broadcasted transactions and they do not include them in the block. Has any research been done to prevent such scenario?

There are significantly more than 10k full nodes on the network. The 10k figure is simply the number of reachable nodes which listen publicly for new connections. There are many more times that amount which do not have open ports. Luke-jr publishes information about nodes his own knows about[1], suggesting there are in the order of 100k nodes.
It only takes one honest connection to make any dishonest connections become apparent. The default setting in the bitcoin core software is that a node will make 8 outgoing connections to other peers. By default, the software will also accept up to 125 incoming connections, but miners in particular will increase this figure. (Miners also use separate p2p networks such as fibre).
If a malicious party controls 90% of nodes in the global network, then the probability that any single outgoing connection will reach them, assuming chosen at random, would be 0.9. The probability that all 8 outgoing connections will connect to the malicious nodes then, would be 0.9^8. 10x the nodes wouldn't be sufficient.
There is a paper, Eclipse Attacks on Bitcoin’s Peer-to-Peer Network which addresses the issue and also presents several countermeasures which can limit the chance that an attacker could pull this off, even if they were to manage to spin up the vast numbers of nodes required.


text:
Alternative to Nicehash Miner for Linux
I have a high performance Desktop computer with a powerful NVIDIA GPU available.
I wonder if there is some software similar to NiceHash Miner which I can install in Linux to make some little cash while I'm working on the machine doing other things.

There are many blog posts, howtos, etc. available through Google which will tell you know to mine your favourite crypto currency using an NVIDIA GPU on Linux.
Please note that NiceHash is something similar but different. NiceHash is an online marketplace for hashing capacity. It is not a mining pool. NishHash is about renting out hashing capacity to people who think they know how to get back more rewards from using X amout of hash than they have to pay for it.
AFAIK NiceHash does not offer a Linux client. Did you try to run it in a VM or on Wine?

@TorsenS Actually it did not work with wine. But I managed to start mining with ethminer in another pool.

I know this thread is outdated, but in case anyone is still interested in this question, there are some that can be found here(Linux ones are at the bottom).
To sum it up for you, there are two GUI alternatives for Nicehash on Linux- Cudo Miner and MinerGate.

Welcome to Bitcoin.SE! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.

Thanks Andrew, sorry I'm still new here. Hope the updated answer helps.


text:
Bitcoin node and sending transaction
Is there any bitcoin free full node (both mainnet and testnet) available online that i can make use of like infura for ethereum? This is because i do not intend to host my own node.
Also which javascript library for bitcoin can be used for generate wallet and sending transaction?

You can use this libs for your purposes:
https://github.com/bitpay/bitcore-lib
https://github.com/bitpay/bitcore-explorers
And you dont need a node =)


text:
Can the wallet's balance be deduces from the wallet's address and the blockchain's history? Is this concealable?
Since all bitcoin transactions are public, I guess that all transactions could be summed up to get any wallet's balance. Thus sharing a wallet's address means sharing the whole wallet's data. Even using a proxy wallet would not hide the pattern of expenditure thus potentially revealing where the Bitcoins are being spent. Is there a way to be able to receive payments in Bitcoin, yet keep the balance concealed?

Bitcoin does not offer any way to conceal the transaction amounts.
However, there are techniques such as Coinjoin that allow you to batch your transaction with multiple other peoples', preventing someone from easily identifying which input and outputs belong to you, and making it harder to follow a spending or consolidation trail.
Additionally, it is recommended that addresses are only used for 1 input/output set. Any reasonably modern wallet will give you a new receiving address each time the previous one has a tx, preventing people from tracking your entire wallet with just a single address (provided you aren't regularly consolidating to a single address).

Looks like you misunderstood what is the wallet  and the address. Wallet is not an address, wallet is a bunch of addresses.
An address is a single-use token
Addresses are not wallets, and do not carry balances.

Thus sharing a wallet's address means sharing the whole wallet's data.

Addresses in this particular wallet doesn't related each other, therefore if you know one address you can't calculate the balance of all wallet.

What happens when someone publishes an address so that multiple people can send Bitcoin? Like when someone ask for donations in a website. The address has to be regenerated each time a payment is sent?

No, an address receive all payments and doesn't regenerated each time.

@GabrielDiego If you are listing an address for donations, the implicit assumption is that you don't care about people knowing it belongs to you, since you already declare it as your donation address.

@Gabriel Diego: for a donatin address published on a web, one can think of using HD keys, that allow to change the address on the webpage every time, so funding to your donation address cannot be tracked.


text:
Why were miners still mining BTC at times when BCH was 2-4x more profitable to mine?
From August 2017 until mid November (prior to BCH's hardfork with the difficulty adjustment algorithm) there have been some occasions (notably end of August, beginning of October and mid November prior to HF) where mining BCH was 2-4x more profitable than mining BTC. See: https://bitinfocharts.com/comparison/mining_profitability-btc-bch.html#1y
You would expect that in such cases, where mining one coin compared to the other is much more profitable, all miners would switch to the more profitable coin. However, this did not happen, even when BCH was 4x more profitable, there was still hashrate on the BTC chain (see: https://bitinfocharts.com/comparison/hashrate-btc-bch.html#1y).
What could be a possible explanation for this? I am looking to hear a miner's perspective on this.
Thanks in advance!

Some miners may be ideologically opposed to BCH and thus will not mine it or help it in any way. Others may be too lazy to switch their hash rate to BCH or do not trust any BCH mining pools so they do not switch. Yet others may simply have been unaware of these profitability spikes and were not available to switch their mining hardware to BCH. Given that the change in profitability was only for a very short period of time, some miners may not have had the time in order to switch their hardware, or the effort was not necessarily worth it.
Additionally, mining on BCH means that they would be mining a much less liquid currency. BCH does not have nearly the same trading volume as Bitcoin and mining BCH means that the miners may be stuck with a coin which they do not want and may even lose value compared to what they would earn with Bitcoin.
It is important to note that even if not all miners switch, some still did which you can see in the hashrate charts. This did happen fairly frequently as the EDA could be gamed so that mining on BCH briefly was more profitable than Bitcoin, and several miners did do this.

Miners are interest in profit, if a miner A mine in btc chain and he find a vaild block their reward will be 12.5 btc + transactions fees, have your mind that in the btc blockchain transaction && fees are bigger than bch blockchain, so more transactions -> more fees -> more profit, also btc price is more mature than bch at this time.


text:
How much computing power is required to bruteforce a Litecoin private key in reasonable time?
Say I want to break a Litecoin private key having the public key using brute force. How much computing power is required for that? Does any hardware exist which can find a matching private key in, say, a year? Is it possible that it ever becomes cheap enough to bruteforce Litecoin addresses, i.e. it costs less money than one can steal from the address once the key is found?
I'm asking about Litecoin just for the sake of being more definite. I think mostly the idea is the same for other blockchain systems.

How much computing power is required for that?

The computing power required to brute force private keys is incredibly immense, so much so that the human mind cannot consider its largeness.
Let's assume that you have a processor (say an Intel Xeon) that can perform 1 Trillion key guesses per second. The number of keys possible (and thus the number of keys that you would have to guess in order to guess a private key) is 2^256. With 1 trillion guesses per second, that single processor will take 3.671743 * 10^57 years, which is  2.7 * 10^47 times the age of the universe.
Now if you wanted to have enough processors to get a "reasonable" time frame of 1000 years, you would need 3.671743 * 10^54 processors. With Intels biggest Xeon Platinum chips at 7.6 cm X 5.6 cm, this many chips would take up 1.564162518 * 10^55 Square Meters just to lay them all out (not even on motherboards or the rest of a computer required to even have these processors be useful). With this much area, you could cover the Sun 2.564 * 10^36 times.
Even with more efficient ASICs and processors that can do more key guesses per second, the immense-ness of these numbers makes it so that the numbers barely change; they are still incompreshensibly large.

Does any hardware exist which can find a matching private key in, say, a year?

No, if there were, then Litecoin's signing algorithm would be considered broken.

Is it possible that it ever becomes cheap enough to bruteforce Litecoin addresses, i.e. it costs less money than one can steal from the address once the key is found?

It is possible, but not through brute force. Making it cheap enough requires a cryptographic break. Currently, the only known solution to finding someone else's private key besides brute forcing is to use a quantum computer with several thousand qubits. Such computers do not yet exist.

Thanks! Your comparisons help a lot to realize how unreal it is :)

Though it's theoretically possible, the computational power required to do it would make it infeasible.

Please note that on bitcoinSE, answers are not an appropriate place to ask follow up questions. It is more appropriate to do so as a comment on OPs question, or in a chat room :)

Thank you, I am new to SE in general so I appreciate you bringing this to my attention!

Close to impossible the distribution is just so large.
That characteristic is a design feature.

This doesn't really answer the question, it's simply a statement. Can you include some calculations to indicate why this is so?

To get a sense how vast is a 256-bit key space see this video. TLDW: You can't


text:
Shorts, longs BTC data
I am trying to use the Bitfinex API to get historic shorts,longs BTC/USD data.So, the Bitfinex gives size data with Available values: '1m', this equals last 2 hours, i need last two month at least. Trading view have all data, but i must pass the license. Have another ways to get this data?

It is fairly common for exchanges to only provide a limited amount of historical data. Tradingview and  other sites that have more historical data store it themselves on a database. With 2 hours of data you could ping the exchange API once every 2 hours adding the new data to your database each time.


text:
How to create (many address)/receive/send bitcoin without download blockchain?
I need to create a lot of address on my wallet to get bitcoin.
Check balance and make transfers.
I do not have a hard disk of 200 GB, can I use bitcoin without downloading the blockchain?
Need implementation on NodeJS, or at the command line.

mkdir .bitcoin
echo "prune=600" >> .bitcoin/bitcoin.conf
bitcoind --daemon

And blockchain not more 600 MB


text:
why block minning not interrupted when block found?
I am working with bitcion version < ver. 0.13.0 which contains the setgenerate true functionallity.
I could see in some situations during minning process that when I find a solution, but the other miner has found it already before (and its already published),  I get the message: "ERROR: BitcoinMiner: generated block is stale".
My question is: why the minning process on a specific block not interrupted at the moment when a solution found by one of the other miners?

A realistic bitcoin miner finishes a work unit in less than a second and blocks are only found every ten minutes. So interrupting a work unit would increase mining efficiency by something like 0.1% at best. The additional hardware required to support such interruption on a realistic mining platform would not justify the small performance improvement you might get.
However, it is still beneficial to switch to a new work unit as quickly as possible when a new block is found. But in modern mining systems, this is implemented at a higher level, typically somewhere between the miner's end of the connection to the mining pool and the mining hardware itself.
You can think of it as the software controlling the actual mining hardware having a "big" work unit and, from it, doling out "smaller" work units to individual mining hardware units. When a new block is found, the software gets a new "big" work unit from the mining pool and when the mining hardware needs a new smaller work unit, it gets one from the new big work unit. It's counterproductive, because the small work units are already so small (typically only a few billion hash operations) to try to interrupt them.


text:
how long does it take for an mining machine to exhaust 2^32 in minutes and what is the actual speed of mining machines?
Mining is usually about taking the double sha.
most if not all mining machines such as bitminer's machines usually give some indications for example 1TH/sec per second. Do they count the double sha as one hash operation or does it mean that they count the double sha as two operations.
Wait, even more interestingly, 1 TH/sec means literally 1 terahash per second. Meaning that we can do 1 trillion operations per second !
Does that not mean that I could exhaust a given nonce in less than a second ?! given that we are dealing with only ~4 billion values ?
Assuming that within the ~4 billion values there is one that validates the block, we find a solution in less than a second !
So it aint making sense to me that it takes so long and is so difficult to be a successful solo miner.

According to the Bitcoin wiki, it refers to:

Hash per second is an SI derived unit representing the number of double SHA-256 computations performed in one second, referred to as hash rate. It is usually symbolized as h/s (with an appropriate SI prefix).

You are correct in noting that the nonce space is quickly exhausted with modern miners.
This is solved by updating the so-called "extraNonce" in the coinbase transaction. This has the effect of changing the hash of the coinbase transaction, which in turn changes the merkle root included in the block header. This essentially provides an additional 32 bytes of nonce space, since the coinbase tx can be modified as many times as required.
Additionally, but not nearly as relevant with today's hashrate, the timestamp field of the block updates every second and allows for all nonces to be recalculated with the new timestamp as well.

The flaw in your reasoning is here:

Assuming that within the ~4 billion values there is one that validates the block

That assumption is incorrect.  The key property of hashes is that the hash of any piece of data behaves like a random number uniformly distributed between 0 and 2^256 - 1, and hashes of different data sets behave like independent random variables.  With the current difficulty level of about 5.07e12, each of your nonce values has probability about 4.5e-23  of yielding a hash which is small enough to be a valid solution.  So among 4 billion nonces, the probability that any one of them "wins" is about 1.97e-13.  In other words, for any given block header, most likely there is no nonce that "wins".  So then you just change something else in the block, as Raghav Sood explains, and start over.
How you do it is totally irrelevant for mining efficiency.  All that matters is how many block/nonce combinations you try, and that you don't ever try the same one twice (because that would be wasteful).  There's no particular advantage to actually exhausting the nonce space for a given header.
Incidentally, miners might be designed in different ways, and they don't necessarily try all possible nonces in a given block sequentially before starting over.  Typically an ASIC miner has a large number of cores, each of which performs hashing at a relatively slow speed.  One possible design would be to pass a different block header to each core (varying extraNonce or what have you), and let it exhaust the nonces for that particular header.  If so, your 1 TH/s miner might take a lot longer than 4 ms to exhaust all the nonces for any given block.  If it has 1000 cores each doing 1 GH/s, it takes 4 seconds to exhaust the nonces - but it does so for 1000 different headers.


text:
Failed at the bitcore-node@3.1.3
Approach
I'm trying to install bitcore on Windows 10 and Ubuntu 18 but I could not.
Problem
I have followed the following steps:
# Install NVM (1)
#  Install script
#   With CURl
# curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash
#       or Wget:
wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

Adds the source line to your profile (~/.bash_profile, ~/.zshrc, ~/.profile, or ~/.bashrc)
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

# Install Node.js v4 LTS
nvm install v4
# Install ZeroMQ and Tools
apt-get install libzmq3-dev build-essential
# Install Bitcore
npm install -g bitcore

More information

Bitcore Full
NVM
But when I run it I get the following errors

Error in Windows con git

$ npm install -g bitcore

Output
> bitcore-node@3.1.3 preinstall C:\Users\User\AppData\Roaming\npm\node_modules\bitcore\node_modules\bitcore-node
> ./scripts/download

"." no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.
npm WARN Error: EPERM: operation not permitted, lstat 'C:\Users\User\AppData\Roaming\npm\node_modules\bitcore\node_modules\utf-8-validate\node_modules'
npm WARN  { Error: EPERM: operation not permitted, lstat 'C:\Users\User\AppData\Roaming\npm\node_modules\bitcore\node_modules\utf-8-validate\node_modules'
npm WARN   stack: 'Error: EPERM: operation not permitted, lstat \'C:\\Users\\User\\AppData\\Roaming\\npm\\node_modules\\bitcore\\node_modules\\utf-8-validate\\node_modules\'',
npm WARN   errno: -4048,
npm WARN   code: 'EPERM',
npm WARN   syscall: 'lstat',
npm WARN   path: 'C:\\Users\\User\\AppData\\Roaming\\npm\\node_modules\\bitcore\\node_modules\\utf-8-validate\\node_modules' }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! bitcore-node@3.1.3 preinstall: `./scripts/download`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the bitcore-node@3.1.3 preinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\User\AppData\Roaming\npm-cache\_logs\2018-06-24T12_23_42_800Z-debug.log

Error in Ubuntu

npm install -g bitcore

Output
> bitcore-node@3.1.3 preinstall /root/.nvm/versions/node/v4.9.1/lib/node_modules/bitcore/node_modules/bitcore-node
> ./scripts/download

./scripts/download: line 30: cd: /root/.nvm/versions/node/v4.9.1/lib/node_modules/bitcore/node_modules/bitcore-node/scripts/../bin: Permission denied
npm ERR! Linux 4.15.0-22-generic
npm ERR! argv "/root/.nvm/versions/node/v4.9.1/bin/node" "/root/.nvm/versions/node/v4.9.1/bin/npm" "install" "-g" "bitcore"
npm ERR! node v4.9.1
npm ERR! npm  v2.15.11
npm ERR! code ELIFECYCLE

npm ERR! bitcore-node@3.1.3 preinstall: `./scripts/download`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the bitcore-node@3.1.3 preinstall script './scripts/download'.
npm ERR! This is most likely a problem with the bitcore-node package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     ./scripts/download
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs bitcore-node
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls bitcore-node
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /root/npm-debug.log

Question
Someone who has executed it sees an erroneous step or the same thing happens to him and he has solved it.
Thank you !!

can you add /root/npm-debug.log content?

@Adam Go¡¡ An moment

https://pastebin.com/zBPT2iKD This is an part

"bitcore" is dead, regardless. It's not Bitcoin Core, to ease confusion.

Solution

"bitcore" is dead, regardless. It's not Bitcoin Core, to ease
  confusion.


text:
BTC/USDT trading on binance
I have an account on binance and i would like to trade on the platform in the BTC/USDT market. However something does not add up to me.
Lets say at 1100 HRS 1 BTC = 6154 USDT and at 1200 HRD 1 BTC = 6180 USDT
I should therefore be having more bitcoins if i sell when 1 BTC = 6180 USDT but this does not seem to be the case. I have attached the graphic to demonstrate what i mean.

What is exactly happening here?

What your screenshot is showing: You have set the amount of USDT to 30 in each case, so at the higher price, you will need to sell less BTC in order to get 30 USDT. This is different than setting the amount to a constant amount of BTC in both cases, and seeing the difference in USDT.
The math in your example:
(1 BTC/6180 USDT)(30 USDT) = (0.004854.. BTC)
(1 BTC/6154 USDT)(30 USDT) = (0.004875.. BTC)
The math, assuming you're buying/selling 0.005 BTC at the prices listed:
(6180 USDT/1 BTC)(0.005 BTC) = (30.90 USDT)
(6154 USDT/1 BTC)(0.005 BTC) = (30.77 USDT)


text:
Get the price of a currency at specific time in the past using binance historical data api
I want to query the binance api for historical data but i want to indicate the specific time i want. For instance i want to know the price of etherum at 1103 hours Friday 31 August 2018.
Is this kind of thing possible on binance api?.

Maybe the klines api will suit your needs: https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#klinecandlestick-data
Kline/Candlestick data
GET /api/v1/klines

Kline/candlestick bars for a symbol. Klines are uniquely identified by their open time.

Weight: 1

Parameters:
Name    Type    Mandatory   Description
symbol  STRING  YES
interval    ENUM    YES
startTime   LONG    NO
endTime     LONG    NO
limit   INT     NO  Default 500; max 1000.

    If startTime and endTime are not sent, the most recent klines are returned.

Response:

[
  [
    1499040000000,      // Open time
    "0.01634790",       // Open
    "0.80000000",       // High
    "0.01575800",       // Low
    "0.01577100",       // Close
    "148976.11427815",  // Volume
    1499644799999,      // Close time
    "2434.19055334",    // Quote asset volume
    308,                // Number of trades
    "1756.87402397",    // Taker buy base asset volume
    "28.46694368",      // Taker buy quote asset volume
    "17928899.62484339" // Ignore.
  ]
]

how do I calculate the quote volume from the base volume, dividing them gives what? close? open? median of ohlc, average?


text:
Get private-keys from bitcoinj
I'm using bitcoinj library for bitcoin.
I want all private keys of all my generated addresses.
How can I achieve that? Please help who knows this answer.
Thanks.

I have write this sample code, hope this helps
public class Main {
    private static NetworkParameters params = NetworkParameters.testNet3();
    public static void main(String...args) {
        String mnemonic = "brisk wood symptom party betray ozone dad super beyond sea memory power pig business extra";
        DeterministicSeed seed = null;
        try {
            seed = new DeterministicSeed(mnemonic, null, "", new Date().getTime());
        } catch (UnreadableWalletException e) {
            e.printStackTrace();
        }
        Wallet wallet = Wallet.fromSeed(params, seed);
        System.out.println(wallet);
        DeterministicKeyChain keyChain = DeterministicKeyChain.builder().seed(seed).build();

        // Derive 100 children, default lookahead is 100
        keyChain.maybeLookAhead();

        // Get M/0H/0/5 key, drive address along with other info for specific path
        DeterministicKey key5 = keyChain.getKeyByPath(ImmutableList.of(ChildNumber.ZERO_HARDENED, ChildNumber.ZERO, new ChildNumber(5)), false);

        System.out.println(key5.toAddress(params).toString());

        // derive 100 addresses along with private key
        System.out.println("_________________________");
        int i = 0;
        while (i < 100) {
            System.out.println(wallet.freshReceiveKey().getPrivateKeyAsHex());
            System.out.println(wallet.freshReceiveAddress());
            i++;
        }

    }
}


text:
Bitcoinj Standard
I'm using bitcoinj for transferring bitcoin.
I don't know which standard bitcoinj supports?
Bip32, Bip39, or Bip44
Please help who knows the answer.
Also I want convert bitcoinj standard to Bip44.
How can I do that?
Please help me.
Thanks.

maybe this helps: https://bitcoin.stackexchange.com/questions/69928/how-can-i-switch-from-bip32-to-bip44-using-bitcoinj

It appears that it supports all of the above, see documentation: https://bitcoinj.github.io/javadoc/0.14.7/:

BIP32 - Class HDKeyDerivation: Implementation of the BIP 32 deterministic wallet child key generation algorithm.
BIP39 - Class MnemonicCode: A MnemonicCode object may be used to convert between binary seed values and lists of words per the BIP 39 specification
BIP44 - Class DeterministicKeyChain: see BIP44_ACCOUNT_ZERO_PATH


text:
Why is the probability of finding a winning nonce exactly the same for a new header and a header where you've already tried 1 billion nonces?
I'm referring to this question: When do miners stop waiting for new transactions?
More specifically, this statement from the top answer:
"suppose you have a block header h1 on which you have already tried a billion nonce values, and a header h2 which has just been generated and on which no nonces have been tried yet. If you have the choice as to which one to hash next, which should you choose, for the greatest chance of finding a winning nonce? The answer is, it makes no difference - they both have exactly the same probability. So there is no harm in switching to h2"
I would have thought that the probability would be slightly higher for the first block (h1) as there are 1 billion nonces that you know do not succeed, i.e. fewer winning possibilities.
Complete newbie here and to the bitcoin world so apologies if I'm missing something obvious.

I would have thought that the probability would be slightly higher for the first block (h1) as there are 1 billion nonces that you know do not succeed, i.e. fewer winning possibilities.

Would you agree that every toss of a balanced coin has a 50% probability of coming up heads?
What about if you've previously flipped 9 heads in a row?
A coin has no memory of previous flips, nor does proof-of-work have any memory of previous failed nonces.
Here's a different scenario:
A fishbowl contains 1,000 pieces of paper. Onto 999 of them is printed "lose." On one of them is printed "win."
What's the probability of drawing "win" at the beginning of the game?
1/1,000
What's the probability of drawing "win" after the first unsuccessful round?
1/999
And so on. Your chances of winning improve with every round. The fishbowl has state, and that state carries over to the next round.
Hashing has no state. That's why the miner's chance of finding a proof-of-work on either h1 or h2 is equal.

I think I know the reason behind your confusion here. Here's my interpretation of your original question:
"Out of the finite number of things whose combination is being hashed, all else being the same, the nonce is a 32-bit field with a constant number of possibilities: 2^32. Out of these possibilities, if 1 billion are already exhausted, why does it not mean that you'd have a higher probability of finding the 'correct' nonce using this block header as opposed to 'starting from scratch' using a different block header?"
The answer is that even if all the 2^32 possibilities for the nonce -- using a constant set of block header, timestamp, etc. -- were exhausted, it doesn't mean that one of the hashes you computed would satisfy the difficulty criterion; you might have to keep going by changing the transactions or timestamp and iterating over the nonce possibilities again.

I would have thought that the probability would be slightly higher for the first block (h1) as there are 1 billion nonces that you know do not succeed, i.e. fewer winning possibilities.

For every computation, you have the same probability of generating a valid block hash. Nothing you can do will change this, even if you try every possible nonce value for a given header. Nothing about what you find while testing nonces will tell you anything about what the next nonce value will return as output. Each guess does not get you ‘closer to the goal’, it is just a random chance.
Think of it like this:

You have a six-sided die (numbered 1 to 6) that you know is fairly weighted. If you roll a 1, you get to make the next block! Every other roll does nothing.
You roll the die ten times, and don’t get a 1 on any of the rolls.
Now, on your eleventh roll, you are given the option to switch dice. You can replace the one you were rolling, with a new one that is otherwise the same (also six-sided, printed with 1−6, fairly weighted). Your choice.

What will give you the better odds of rolling a 1? The answer is: it doesn’t matter. The fact that the first die didn’t roll a 1 yet doesn’t influence what the next roll will be. The same goes for the replacement die. Just because it hasn’t been rolled yet, doesn’t make it any more likely to be a 1 (or any other number).

One of the properties we want from cryptographic hash functions (CHF) is that their output looks like random data as much as possible. In particular, when putting two similar messages like header + nonce and header + nonce+1 through a CHF, their digests should not be in anyway more related than two completely unrelated inputs.
If the outputs of SHA256 were to follow some pattern, you would be able to get closer to a solution. This would allow the miner with the most hashrate to win more often than their share of the hashrate. Instead, we want mining to be progress-free: every hashing attempt should have an equal minuscule chance of winning.
It's therefore good that the only way to "predict" the digest of any blocktemplate + nonce is to perform the hash, and therefore, we can think of each hashing attempt as an independent random event—regardless of whether you've tried similar inputs before. (Although the same input will obviously have the same outcome and you'd be duplicating work.)
Let's also look at the magnitudes of the search spaces involved:
The nonce space is 32 bits, i.e. allows for 232 = 4,294,967,296 different values. The hashrate today is about 175 EH/s, which means that about one in every 175×1018 H/s × 600 s = 1.05×1023 H hashing attempts finds a valid block. So clearly, there is not a winning nonce for every block template, in fact, miners exhaust a complete nonce space about 4.07×1010 times per second.


text:
convert 12 word seed into 24 word seed
I used bitcoinj library for wallet and it generates 12 word mnemonic seed.
But I made changes in it and created 24 word mnemonic seed.
But I need to convert old 12 word mnemonic seed into new 24 word mnemonic seed.
Please help me with this.

By changing the seed, you are changing the private keys.

Ok. So In BitcoinJ, how do i move all my private keys, addresses and balances to a new 24 word seed wallet from 12 words seed wallet without losing the ability to use the 24 words seed to restore the wallet in future?

You can't move the private keys but the bitcoins, just create another 24-word seed and make a normal transaction.

Can you please tell me how to export and import private key in bitcoinj?

This is not possible.
The mnemonic words are an encoding of the entropy used in the seed, essentially. A 12 word seed has less entropy than a 24 word one, so you cannot get 24 words out of it. Similarly, you cannot get a 24 word seed to turn into a 12 word one.
Your best bet is to generate a new 24 word seed and move funds over.

Ok. So In BitcoinJ, how do i move all my private keys, addresses and balances to a new 24 word seed wallet from 12 words seed wallet without losing the ability to use the 24 words seed to restore the wallet in future?

You don't move your keys, or addresses. You make a transaction from your old wallet to the new one, so that the coins are now controlled by the 24 word private keys

Can you please tell me how to export and import private key in bitcoinj?


text:
Lightning: Is it possible to send lightning BTC outside of a lightning state channel?
Let's say that I have a channel opened and I want to send some lightning BTC to someone who didn't ever used lightning, is it possible or will it be? Or will I need to open a channel first then send the btc through lighthing(with 2 transactions)?
I know the guys from Raiden want to allow that: https://medium.com/@raiden_network/creating-an-easy-onboarding-user-experience-for-the-raiden-network-4dcdc9e2eeed

There is no such thing like 'lightning BTC'. It is the same BTC, either on-chain, or comitted to a lightning channel, which is technically a 2 of 2 multisig transaction. To receive via lightning, a lightning full node or a wallet with lightning receive capability is needed. And correct, you need to open a channel first, which takes one on-chain commit, the the associated waiting time. But it is possible to transfer value at the same time by already assigning a portion of the channel funds to the receiver when setting up the 2 of 2 multisig transaction. All later value transfers inside the channel will be an just update of this transaction, which will be instantaneous. So either way, no need for a second transaction in terms of on-chain transaction. Except for the closure of the channel, if needed - which will another on-chain transaction ( channels can stay open indefinitely, though).

You can use the wallet c-lighitning for sent bicoin to a simple wallet bitcoin with this command
lightning-cli withdraw <pubkey> <shatoshi>

But you can not use the your channel, the satoshi that you use for sent bitcoin to simple wallet bitcoin are separated by the channel


text:
How do block explorers determine propagation through nodes/P2P protocol?
On several Bitcoin blockchain explorers, I have seen unconfirmed transactions given a dedicated "propagation" value that tells a user how much of the Bitcoin network has become aware of this transaction.
For example, BlockCypher provides a "confidence" value for unconfirmed transactions:

This has always lead me to wonder how exactly they can calculate this? Do they personally have a large distributed network of nodes that are constantly kept track of? Surely this would be cost ineffective and less decentralized.
Their documentation states:

By monitoring transaction propagation, the number of nodes that have received it, and how quickly they received it, we can calculate its probability to be the “winning” transaction at any given point in time, if a double-spend was attempted.

I have had quite a difficult time finding documentation on what exactly nodes can request from each-other directly. Can a node simply ask its peers if the transaction exists in their mempool with a getData request?

related: https://bitcoin.stackexchange.com/questions/79087/can-we-estimate-how-many-node-has-the-bitcoin-network/79093#79093

Blockchain explorers run nodes which have connections to other nodes. They may have hundreds of connections. They likely also run multiple nodes for both redundancy (in case one node fails, they are still online) and to ensure that they are receiving transactions from as many sources as possible. So they will be connected to hundreds, maybe thousands of nodes.
With these connections, they can listen to what all of those nodes are broadcasting. In the current P2P relay protocol, a node announces to its peers that it has a transaction (the inv message). It then waits for a request for it (getdata) before sending the transaction (tx). So someone listening to many nodes would be able to know which nodes have a transaction based on whether they have announced the transaction. This is likely how Blockcypher is computing the "number of memory pools with tx".
However you should be wary of such measurements. They aren't very accurate because they are not connected to all nodes on the network. Furthermore, the confidence they associate with it is largely meaningless. A transaction's likelihood of going into a block depends on many other things, and the number of nodes that have seen it does not effect that number very much.

They don't, essentially, the numbers given for this sort of thing are generally meaningless.
Many of these services attempt to connect to a large portion of the listening network and gain insight into the chance of a transaction confirming, however this is not a measure of safety for transactions. A transaction having been announced by many nodes does not mean that it will not be double spent by a miner, as has happened many times in the past. For BlockCypher in particular, the confidence number does not use a Bitcoin Core node for validation, so will show very high confidence for transactions which are invalid, but have a seemingly high fee.
In the case linked with betcoin dice and ghash.io, they would have shown absolute confidence of confirmation, however the mining pool was simply including alternate transactions that did not spend to the service every time their bet was a negative. For a betting site with a 1% house edge, they only need to be able to do this more than 1% of the time for the attack to be financially profitable for them. This happened for a period of months with nobody noticing, no users stopping using the pool, or any other punitive measure. "Transaction confidence" or other tools only work in a non-adversarial environment, which Bitcoin is not.

Can a node simply ask its peers if the transaction exists in their mempool with a getData request?

You can to some degree ask a node that you are connected to if it has a transaction in its mempool. Nodes implement logic called transaction trickling which intentionally batches and delays relay of transactions in an attempt to prevent privacy adverse behavior such as this. Note that most nodes in the network do not have listening sockets open, so you can not make outbound connections to them. Merchants and miners in particular will not have incoming connections to prevent against trivial denial of service attacks against them.


text:
Distributed Consensus
"Distributed" means operating on more than one devices which dont share physical memory and perform their task (which might be storage or computation) to perform one single task (which in our case might be to have same copy of ledger)
"Consensus" means when everyone is on the same page.
So,"Distributed Consensus" means we want all the different devices on the network which dont have a shared memory and communicate by message passing mechanism to have same copy of ledger. Is that correct ?

Yes, you are correct. In addition, we assume that there are adversaries which can operate arbitrarily and replace some honest-looking devices on the network and make them behave like a "malicious intelligence". They send data adversarially designed to disrupt your protocol.
You want your "distributed consensus" to be able to work under these conditions.
Furthermore, if an arbitrary number of such malicious devices can be injected and you cannot tell devices apart, we call it "anonymous distributed consensus", the problem that bitcoin is solving.


text:
Merkle tree and data validation
If we want to check that data is member of it or not we will take the root, data block, and all the blocks in path between data and root. According to this picture if i want to check that data block, then how can i validate the hash pointer store in above block without having left child?

You are given the hash of the left child itself, and when combined with the computed hash of the data you are given, you can compute the hash of that block (typically referred to as a node). With that hash, you hash it with a provided hash of the left child in it's parent. Then with that node's hash, you hash it with the provided hash of the parent's right child in order to get the root.
If all of the provided hashes for branches that you do not have are correct, and the data is in the merkle tree, then the root hash you end up with will match the root hash that you are given.


text:
How to see bitcoin in my wallet
I bought bitcoin from coinmama and sent it to my bitcoin core wallet, but after the syncing was done I don't see that my wallet has been credited. Has anyone else experienced this issue??
Thanks!

have you got the address public key you sent the btc to? check the address on a blockexplorer to see if the funds are there

A few questions to ask:

Did you send it to the right address?
Is the address's private key controlled by/imported into the bitcoin core wallet? E.g. $ bitcoin-cli importprivkey <WIF>
Make sure the transaction has been confirmed on the blockchain.


text:
Sent to wrong bitcoin address
Need help I sent my bitcoin cash at the atm to the wrong bitcoin HOW can I use this address to send to the address I want it the money on !!! NEED HELP NOW

If transaction was confirmed, you lost your funds. I'am sorry.

Contrary to what others have posted, your money is not necessarily lost forever.
From the sounds of things, you've sent BCH to a Bitcoin (BTC) address, using a bitcoin ATM.
You'll need to contact the operators of the ATM, to ask them to have your funds returned. This is the only way your BCH will be returned. As others have said, there is no way to reverse a confirmed transaction. The coins are now solely controlled by the ATM operator.

If BCH was sent to a BTC segwit address, you cannot recover it yourself, and must ask a miner for help. BTC.com offers such a service

If OP used USD (say) to purchase BCH at an ATM and entered the receiving address of their BTC wallet, couldn't they just import the private key from their BTC wallet into their BCH wallet? (or equivalent process for a multicurrency wallet)

Simply put, it is not possible to revert transactions once they are made because it would allow people to scam others by taking back the money they have paid when they bought something. Your money is lost.

So I can’t send the money to the address I have to another address????

You can only send coins that belong to your own addresses. If you have sent the coins to an address that you don't own, the money are out of your control.


text:
Trying to run the Main file of the wallet template from bitcoinj but JavaFX not found
Trying to run the Main file of the wallet template from bitcoinj but JavaFX not found. When I run the main file of the wallettemplate I get multiple errors of javafx packages not found. When I try to run the entire thing I get an error missing a cucumber thing.
All the tutorials are outdated and I have only coded basic stuff.
Has anyone tried to use bitcoinj on intellij and java 10? Thank you.

yes, kindly post the logs

The JavaFX was removed from JDK > 8 of java.
Now reside is an open-source module of java, look at the official documentation.
Are available more plugins (maven and Gradle) for including the JavaFX in your project, look here

Install the JavaFX SDK
Check this
https://docs.oracle.com/javafx/2/installation/jfxpub-installation.htm

This answer is wrong, you have posted the the oracle documentation but the JavaFX jdk is no longer contained within. Now the JavaFX reside here for version > 9 of java


text:
How to change Nxt/Ardor wallet settings to keep the account ledger table untrimmed?
For purposes of extracting all transactions of an Nxt/Ardor account, it would be very useful to export the complete account ledger table.
Is it then enough to just set nxt.ledgerTrimKeep=0 and nxt.ledgerAccount=ARDR-xxxx-xxxx-xxxx-xxxxx (the account ID in RS format) in nxt.properties or are there other settings to be changed?
How do you initiate a re-scan to generate the whole ledger table afterwards? The database re-downloading would also be an option here, however, would take more time I guess.
A good use for this would be to import the ledger table into a tool for computing taxes resulting from crypto transaction profits, e.g. CoinTracking.info.

To generate a full ledger for a specific account set the following nxt.properties:
# Do not trim the ledger
nxt.ledgerTrimKeep=0

# Only log these specific accounts
nxt.ledgerAccounts=NXT-V4D7-D3XW-JX9Z-EAC8K;NXT-XK4R-7VJU-6EQG-7R335

To rebuild the ledger, invoke the scan API with parameter height set to 0.
This operation can run for several hours depending on your configuration.


text:
Bitcoin: can transaction and its parent be in the same block
I'm trying to understand bitcoin transactions verification specified here. Item 10 states, that parent transaction (mentioned as input for current) should be searched not only in already confirmed transactions (in main chain), but also in transaction pool (which contains unconfirmed transactions). This means, that transaction can become a candidate to be added to block even if it's parent is not in the blockchain. If this is true, than consider following situation:

Transactions A and B are created in the same moment, A is parent of B.
Miner receives both of them, both are considered valid.
Miner adds only transaction B to block.

If such block is mined, it will be invalid, because other nodes will fail to validate transaction B. But if we also insert transaction A in it, will validation succeed on other nodes? I.e., is it possible to add transaction and its parent to the same block?

Yes, you're right. I performed search using different search strings and did not see this post, thank you.

is it possible to add transaction and its parent to the same block?

Yes, as long as A exists in the mempool when B is submitted, it will be allowed in the mempool, and can be in the same block, see Order of transactions within a block. A transaction that consumes invalid unspent outputs (UTXOs) will be rejected before it enters the mempool.
If a miner mines a block with a transaction (in this case B) that has an invalid input (ie the UTXO it is spending does not exist), the block will be rejected when it is submitted because it is a block with invalid transactions.

I.e., is it possible to add transaction and its parent to the same block?

Yes. The "parent" transaction must be earlier in block.


text:
bitcoin daemon use 99.99% io
bitcoin daemon always use 99.99% IO, without using the Internet <1mbit
this is normal?
bitcoin-0.16.0
bitcoin-0.16.2
iotop:
 99.99 % bitcoind -daemon [bitcoin-schedu
Debian 8 x64

Yes, that is normal. bitcoind is downloading the blockchain and writing it to disk. When you are syncing, it has to download and write to disk nearly 200 GB of data, so that is going to use a lot of disk I/O.


text:
What is the best language to use for making API orders?
I have heard that python is at a disadvantage when it comes to making API requests. It’s built on C which makes it slower. Are there any languages that are low level enough to make fast requests and still API accessible?

You will very rarely find that the choice of language  is a major bottleneck,

I'd suggest Golang, it's fast enough and is designed API and website hosting. C is too low level, and C++ might still be a little low level.

C is not a slow language. C and its derivative C++ have become dominant because they are fast. C is fast enough that I have heard it called a "glorified assembler'.  I don't believe any python implementation is written in native machine language .  ( https://stackoverflow.com/questions/21717660/what-exactly-is-the-python-interpreter-implemented-with )

Go - easy concurrency, productive and effcient


text:
Unable to get balance with bitcore lib
Using latest version of bitcore lib , want to check balance for making tx but once I include
var explorers =require('bitcore-explorers');

after
var bitcore =require('bitcore-lib');

Error: More than one instance of bitcore-lib found. Please make sure to require bitcore-lib and check that submodules do not also include their own bitcore-lib dependency.
at Object.bitcore.versionGuard (/home/ubuntu/node_modules/bitcore-lib/index.js:12:11)
at Object.<anonymous> (/home/ubuntu/node_modules/bitcore-lib/index.js:15:9)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/home/ubuntu/controllers/bitcoinController.js:8:14)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
at module.exports (/home/ubuntu/routes/apiRoutes.js:5:15)
at Object.<anonymous> (/home/ubuntu/api/server.js:13:1)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)

I had a look at this thread
Bitcore = "Error: More than one instance of bitcore-lib found"
but it does not help .
When I comment out this part
var bitcore =require('bitcore-lib');

explorer seem to be running but the problem is it always returns 0 for all the wallets .
For instance this wallet  has fonds wallet testnet fonds
here is the code
const insight = new explorers.Insight();
insight.getUnspentUtxos('mkFPBvd3jbPYn4223SNTneBWHodziU287G', function(err, utxos) {
    console.log(utxos);
    let balance = 0;
    for (var i = 0; i < utxos.length; i++) {
        balance +=utxos[i]['satoshis'];
    }
    console.log('balance:'+ balance);
});

and response is always  [] , 0
1) How to check balance using bitcore without conflict with bitcore-lib  ?
2) Which is the  "web3" (most commonly  used for ethereum) node js library for bitcoin ?
Thanks a lot !

This is the only thing I've found about solving this issue so far. Seems like a total hack / oversight.
https://github.com/bitpay/bitcore/issues/1454#issuecomment-306900782


text:
Fiat to Satoshi Relationship
Is there a formula to calculate the fiat value of a Satoshi using your fiat principle?

The number of satoshi per bitcoin is 1e8 or 100,000,000, so if you have a fiat value per bitcoin such as $7000/BTC, the calculation is:
$/satoshi = $7000/1e8 = $0.00007 per satoshi
Of course, there is no fixed fiat to satoshi value because the fiat value of Bitcoin is determined by the market, i.e. exchange value.


text:
Are sockets kept open when connections are made?
The bitcoin protocol says that any given node is connected to at least 8 other nodes. Does that mean that when a client connects to a node and learns about new peers... will the client keep the socket open and wait on recv? Or does it just record the new peers and closes the sockets and opens a new connection when there is new data to be received or sent?

The bitcoin protocol says that any given node is connected to at least 8 other nodes.

Right.

Does that mean that when a client connects to a node and learns about new peers... will the client keep the socket open and wait on recv?

No, since this is about connection between peer nodes, not about clients.

Or does it just record the new peers and closes the sockets and opens a new connection when there is new data to be received or sent?

Nodes try to retain at least eight connections to peer nodes so that they can track the flow of new transactions and blocks on the network. Establishing a reliable set of stable connections to at least eight peer nodes is the objective here.


text:
What can cause bitcoind to take a long time to shutdown?
I just installed Bitcoin Core on a new machine and completed IBD using dbcache ~24000. It took ~40 mins to shutdown for the first time (after running for about 24 hours and completing the IBD). I'm wondering if this is normal, or if it could be related to either IBD or having such a high dbcache?
Shutdown logs for reference:
2022-08-05T22:39:55Z tor: Thread interrupt
2022-08-05T22:39:55Z addcon thread exit
2022-08-05T22:39:55Z torcontrol thread exit
2022-08-05T22:39:55Z opencon thread exit
2022-08-05T22:39:55Z Shutdown: In progress...
2022-08-05T22:39:55Z msghand thread exit
2022-08-05T22:39:55Z net thread exit
2022-08-05T22:39:55Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2022-08-05T22:39:55Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.02s)
2022-08-05T22:39:55Z scheduler thread exit
2022-08-05T22:39:55Z Writing 0 unbroadcast transactions to disk.
2022-08-05T22:39:56Z Dumped mempool: 0.003643s to copy, 0.227474s to dump

<hangs here for 40 mins>

2022-08-05T23:18:52Z Shutdown: done

At shutdown, the chainstate cache has to be flushed to disk. The bigger you set dbcache, the bigger this cache can grow, and the longer it can take to flush it.

it would be good to have a descriptive log entry for this before the expected hang, so users have an idea that its to be expected

Oops just seeing this now - thanks for the explanation Pieter.


text:
keypool option with HD wallet
I'm a bit confused.
According to https://bitcoincore.org/en/2018/02/26/release-0.16.0/#hd-wallets-by-default HD wallet is enabled by default. However there is still keypool option of bitcoind which sets how many addresses will be pregenerated on wallet loading. keypool assumes regular wallet backups in order to not to loose keys generated above keypool value and keypool restore.
So, my question is: with HD wallets does keypool option have any meaning? And do I still need to do these regular backups?

The keypool is how Bitcoin Core achieves the lookahead functionality when you restore a backup. It is effectively the "gap limit". While BIP 32 does mean that one backup should be sufficient, it is possible that the keypool is too small (if you somehow hand out thousands of addresses but never receive at them) so backing up routinely is still a good thing to do. Also, backing up routinely allows you to keep metadata like labels when you restore.
The keypool is also useful for encrypted wallets as it allows getting new addresses to give out without having to unlock the wallet every time.

What if the keypool of an HD-enabled wallet.dat is exhausted? Is it possible that the wallet may silently ignore some funds when an old backup is imported?

As keys from the keypool are used, new keys are generated. So the keypool is constantly being refilled during a rescan which means that funds will not be skipped.

What if the backup is encrypted? Would the sync/rescan process be paused, to ask the user for passphrase?


text:
Where can one download Bitcoin Days Destroyed data? Alternately where to get data to calculate BDD?
I'm trying to find a source of downloadable (preferably csv) data for Bitcoin Days Destroyed. Alternately I can calculate it myself provided I can find the constituent data.
In particular, I want to calculate dormancy which is total number of days destroyed  divided by volume. I know the total number of days destroyed is the value of the transaction multiplied by the number of days since that BTC was last moved.
Where can I find either data that has already been calculated for dormancy, or data on days destroyed, or barring either of those, the number of days since the last transaction for each Bitcoin?

For Bitcoin Days Destroyed data you can for example go there https://blockchair.com/bitcoin/charts/coindays-destroyed?interval=3m you can download the data they used in .csv
https://blockchair.com/bitcoin/ does a pretty good job at providing useful data, charts about the bitcoin blockchain
If you want to compute and made your own calculation yourself the best way would be to download the full blockchain 250giga+ with bitcoin core https://github.com/bitcoin/bitcoin and use a tool like Abe https://github.com/bitcoin-abe/bitcoin-abe to configure how the data are treated


text:
I sent BCH to a segwit btc address, how can i get it back?
I accidentally sent bitcoin cash  to a segwit bitcoin address, please can anyone help me on how i can get it back. i tried using this recovery service, https://bch.btc.com/docs/help/bch_segwit_recovery
but they never replied me or responded to my email, please what can i do?

Your best option is to contact other (well known) BCH mining pools. It's not practical to broadcast the tx on your own (and leaves you open to losing all your coins). Essentially, without a miner's support, you are out of luck

ok, what pool do you suggest, i have no clue.


text:
How to protect a crypto currency from Seed failure
I have created a new currency based on Forknote/Cryptnote.
It has a small number of Seed Nodes.
I am investigating how to mitigate the risks of currency failure due to Seed Node collapse from

Legislation forcing hosting providers to no longer allow Seed Nodes
A synchronized server attack.

Is the only way to mitigate this to have multiple Seed Nodes in multiple locations by multiple providers? Or is there any way I can rely on continuing to have a small number of Seed Nodes but rely on the distributed nature of local copies on the blockchain on mining machines?


text:
Does exist some library for decode/encode raw transaction?
I want to parse raw transaction into JSON then change some values and encode back to hex. JSON like this:
{
"addresses": [
    "346vcZZ6QV4nr68fybMEuA7qxxQeyKWoPS"
],
"block_height": -1,
"block_index": -1,
"confirmations": 0,
"double_spend": false,
"fees": 0,
"hash": "e09c37cca11208a8c372a1e397dcff0382b4d78cdde157ce8824d028dc185a80",
"inputs": [
    {
        "age": 0,
        "output_index": 1,
        "prev_hash": "c15bb773cdd5bb63a65766f5680684ce991c126698db0aa020e3058081742874",
        "script_type": "empty",
        "sequence": 4294967295
    }
],
"outputs": [
    {
        "addresses": [
            "346vcZZ6QV4nr68fybMEuA7qxxQeyKWoPS"
        ],
        "script": "a9141a75cd53e9740caadbf83cbefdd087cdceb978a487",
        "script_type": "pay-to-script-hash",
        "value": 14000000
    }
],
"preference": "low",
"received": "2018-08-21T08:05:02.841875145Z",
"relayed_by": "54.160.159.32",
"size": 83,
"total": 14000000,
"ver": 2,
"vin_sz": 1,
"vout_sz": 1
}

I've tried to use bitcoinj but it returns very simple object without a lot of fields.

What are you trying to change? Most of the fields in the json don't actually exist in a transaction

Try this Python library (Disclaimer: I wrote it)
from btctools import Transaction

>>> tx = Transaction.from_hex('0100000000010153159b2a077d8dfbe4dca4b6b3a9e0ccedb4962ca73280526e6a1eeb1e8e9adc2a00000000ffffffff04a08f3e00000000001976a914de755835002260891962f1e671a2bf7605788d0f88ac0046c3230000000017a914c7c9b5f51244f39f81ec01146eb0d1d98d4bbd4c872052a6000000000017a91469f376599f0ffcaacd6a79854b1ee99513bb7b35870006f21600000000220020701a8d401c84fb13e6baf169d59684e17abd9fa216c8cc5b9fc63d622ff8c58d04004830450221009360af3ec3f9d4ae8acc3ab2213f3f9344cb322b4ea447490bb297a9a4c1d207022067027b032e54b3efb9e885604349ec4f1b6446eed8ed208c6fe6eeae9ace921a0148304502210097cf932eb37513c201b577472d70f1553f338d6439e9181607ec75f2e83fa148022052368c88085838521efc64cf509b95dd53d8c825089acd3ff681e74d3a2b4959016952210266edd4ef2953675faf0662c088a7f620935807d200d65387290b31648e51e253210372ce38027ee95c98cdc54172964fa3aecf9f24b85c139d3d203365d6b691d0502103c96d495bfdd5ba4145e3e046fee45e84a8a48ad05bd8dbb395c011a32cf9f88053ae00000000')
>>> tx
Transaction(inputs=1, outputs=4)

>>> tx.json()
{'locktime': 0,
 'size': 448,
 'txid': '0f6787fe25b631c73db598769eff70d616645eb61ad8c6f7408bc4341917aca5',
 'version': 1,
 'vin': [{'scriptSig': {'hex': ''},
   'sequence': 4294967295,
   'txid': 'dc9a8e1eeb1e6a6e528032a72c96b4edcce0a9b3b6a4dce4fb8d7d072a9b1553',
   'vout': 42,
   'witness': ['',
    '30450221009360af3ec3f9d4ae8acc3ab2213f3f9344cb322b4ea447490bb297a9a4c1d207022067027b032e54b3efb9e885604349ec4f1b6446eed8ed208c6fe6eeae9ace921a01',
    '304502210097cf932eb37513c201b577472d70f1553f338d6439e9181607ec75f2e83fa148022052368c88085838521efc64cf509b95dd53d8c825089acd3ff681e74d3a2b495901',
    '52210266edd4ef2953675faf0662c088a7f620935807d200d65387290b31648e51e253210372ce38027ee95c98cdc54172964fa3aecf9f24b85c139d3d203365d6b691d0502103c96d495bfdd5ba4145e3e046fee45e84a8a48ad05bd8dbb395c011a32cf9f88053ae']}],
 'vout': [{'scriptPubKey': {'asm': 'OP_DUP OP_HASH160 de755835002260891962f1e671a2bf7605788d0f OP_EQUALVERIFY OP_CHECKSIG',
    'hex': '76a914de755835002260891962f1e671a2bf7605788d0f88ac'},
   'value': 0.041},
  {'n': 1,
   'scriptPubKey': {'asm': 'OP_HASH160 c7c9b5f51244f39f81ec01146eb0d1d98d4bbd4c OP_EQUAL',
    'hex': 'a914c7c9b5f51244f39f81ec01146eb0d1d98d4bbd4c87'},
   'value': 6.0},
  {'n': 2,
   'scriptPubKey': {'asm': 'OP_HASH160 69f376599f0ffcaacd6a79854b1ee99513bb7b35 OP_EQUAL',
    'hex': 'a91469f376599f0ffcaacd6a79854b1ee99513bb7b3587'},
   'value': 0.109},
  {'n': 3,
   'scriptPubKey': {'asm': 'OP_0 701a8d401c84fb13e6baf169d59684e17abd9fa216c8cc5b9fc63d622ff8c58d',
    'hex': '0020701a8d401c84fb13e6baf169d59684e17abd9fa216c8cc5b9fc63d622ff8c58d'},
   'value': 3.8496}]}