text:
Get node 1 to mine another block, send it to node 2, and check that node 2 received it
I am trying to write a test with the bitcoin/test/functional/example_test.py to get node 1 to mine another block, send it to node 2, and check that node 2 received it. Any idea on how to go about/get started on this? I am familiar with python but this is fairly new to me.
Thanks.

The default setup_network() implemented by the test framework connects all nodes, as explained by the comment in example_test.py's setup_network(). Since you want node 2 to be connected to nodes 1 and 0, you can simply delete the setup_network() implemented in example_test.py to use the default setup_network(). Then inside of run_test(), you can just do .generate() with any of the nodes and the block should be synced to all of the other nodes.
To guarantee that all nodes are synced to the same block, you can use self.sync_blocks() which will ensure that every node has the same tip before it returns.
Your run test would have something like:
def run_test(self):
    self.nodes[0].generate(1)
    self.sync_blocks()

This is very illuminating, thank you, just to confirm:                                                                             1. Getting node 1 to mine another block can be done with self.nodes[1].generate(1) ? 2. Send the mined block from node 1 to node 2 can be done with self.sync_blocks() [after deleting the  setup_network example_test.py to use the default setup_network()]                                      3.  How do I check that the node 2 has received it?

Yes. 2. Once a block is mined, it is automatically sent to all of the nodes the mining node is connected to. sync_blocks() just ensures that all nodes are synced before continuing with the test. 3. You can use getbestblockhash() on nodes 1 and 2 and check that they match. But it is unnecessary to do that since sync_blocks() will do that for you.

Sorry for being such a noob, You can use getbestblockhash() on nodes 1 and 2 and check that they match. How would that look in code? thanks again.

The check would be something like assert_equal(self.nodes[1].getbestblockhash(), self.nodes[2].getbestblockhash())


text:
Low number from getconnectioncount
I have been running my bitcoin node for about 24 hours now and I'm hovering at 54 active connections. However, I thought that I would be at 125. Why is it that I'm not exceeding this number? Additionally, I have two IP addresses for my server and I noticed that I'm getting some transactions twice. Is it because I have two IP addresses? Could someone explain to me how I might go about getting more connections?

I have been running my bitcoin node for about 24 hours now and I'm hovering at 54 active connections.

That's quite high for just 24 hours.

However, I thought that I would be at 125. Why is it that I'm not exceeding this number?

125 is just the (default) limit on the total number of connections your node supports. It itself will only make around 10 connections to others; the rest of the connections will be from others connecting to you. It takes a long time before other nodes on the network learn about your node's existence and care about making connections to it.

Additionally, I have two IP addresses for my server and I noticed that I'm getting some transactions twice.

Can you explain what "getting some transactions twice" means? In normal circumstances pretty much all your peers (all 54 of them, in your case) will announce every transaction to you.

Is it because I have two IP addresses?

That may help in getting more inbound connections, but it sounds unrelated to transaction download.

Could someone explain to me how I might go about getting more connections?

You may, over time, get more connections, but there is no reason to actively want more. It's important to note that for almost anything you want your node for, the 10 outgoing connections are almost all what matters to you. The inbound connections you permit others to make to you are a service you provide to the network.

thanks for answering. So, I guess my follow up question would be how long until I max out my incoming connections?

I don't know; days, weeks, months perhaps. It shouldn't matter.

source: Stack Exchange

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

sort: votes


text:
bitcoin-cli deriveaddresses always returns an error
I am copying and pasting the example from the bitcoin-cli help:
deriveaddresses "wpkh([d34db33f/84h/0h/0h] xpub6EuEBhzm7KD3yxmt9wFHisymSNmK8w2CFmfgUgXi74ChFa79YouJ1w3hpZmFAWiuLezZqD38fY6K8PkxUfPifzSEB35skuBBNf1efmSp12K/0/*)#trd0mf0l" "[0,2]"

And copying in a valid xpub.
However I always get an error:
Invalid descriptor (code -5)

Even if I copy in the exact bitcoin-cli call from the bitcoin github page here deriveaddresses pull request
deriveaddresses "wpkh([d34db33f/84h/0h/0h]xpub6DJ2dNUysrn5Vt36jH2KLBT2i1auw1tTSSomg8PhqNiUtx8QX2SvC9nrHu81fT41fvDUnhMjEzQgXnQjKEu3oaqMSzhSrHMxyyoEAmUHQbY/0/0)"

I still get the same error.
I am entering the commands directly in the console. What am I doing wrong?
Im using mainnet bitcoin core 0.18.0, mac OS 10.13.6

There are multiple things you are doing wrong.
Firstly, in your first descriptor, you have a miscellaneous space between the origin info (the stuff in square brackets) and the xpub. Secondly, this descriptor is also invalid because you have not computed the correct checksum for it. The checksum is the stuff that appears after the pound symbol (#) at the end of the descriptor. The checksum you have there is the checksum for the one from the help text which is only valid for that descriptor.
In order for your descriptor to be valid, you need to remove the space and recompute the checksum. Remove the checksum, including the pound symbol separator, and pass the non-checksummed descriptor into getdescriptorinfo. This will give you a descriptor with the correct checksum. Please note that it will change the hs in the origin info to single quotes (') which may need to be escaped.
Furthermore, because you are changing the xpub in your descriptor, the origin info in your descriptor is incorrect (although Bitcoin Core does not know this). You should change the origin information to match your xpub, or remove it entirely.
The reason the second descriptor you are trying does not work is because it does not have a checksum. The PR for deriveaddress was written before descriptors had checksums. The RPC was updated and changed when checksums were introduced.

Thank you, what is the "d34db33f" portion of the origin info and how do I get the correct origin info for my xpub? I understand the derivation path 84'/0'/0' but not the rest.

That is the fingerprint of the master public key. It's the first 4 bytes of the ripemd160 hash of the sha256 hash of the public key.

How can i ensure the descriptor has range?

By having /* after your xpub. You can specify unhardened indexes after the xpub, and ending with /* indicates that the last index is the range.

Still trying to wrap my head around the origin info and its effect on the derived keys. Again i get how the 84'/0'/0' derives keys work. But when I input deriveaddresses "wpkh([d34db33f/84'/0'/0']xpub6EuEBhzm7KD3yxmt9wFHisymSNmK8w2CFmfgUgXi74ChFa79YouJ1w3hpZmFAWiuLezZqD38fY6K8PkxUfPifzSEB35skuBBNf1efmSp12K/*)#9k0fv7eh" "[0,99]" It returns the same 100 keys from an xpub that I created on another app, which is great, but I copied the d34db33f from the example origin, it seems like the fingerprint doesn't have an effect? If it does can you explain its effect?

Origin info has no effect on key derivation entirely. It is metadata that is useful for transaction signing. You would want to have origin info if you were importing the descriptors via importmulti, but for deriveaddress, it is unnecessary.

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


text:
How to import multi sig using importmulti correctly?
I create a 2 of 2 with createmultisig using 02254aba14091e45a9067fbe5b225b3863d1c49650226d583dcede06a7c33f8613 and 02ad64a03b7fc53c02f68eac04743b819bfeeabe6ca7007f473dbaf7c3570f5dc9 pubkeys.
I then
curl --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "importmulti", "params":[[{ "scriptPubKey": { "address": "2NETfDLgh1VmER2RGRnEeWqx73Hn4xhJpU5" }, "label": "Imported MultiSig", "timestamp": "now", "keypool": false, "internal": false, "redeemscript": "522102254aba14091e45a9067fbe5b225b3863d1c49650226d583dcede06a7c33f86132102ad64a03b7fc53c02f68eac04743b819bfeeabe6ca7007f473dbaf7c3570f5dc952ae", "pubkeys": ["02254aba14091e45a9067fbe5b225b3863d1c49650226d583dcede06a7c33f8613", "02ad64a03b7fc53c02f68eac04743b819bfeeabe6ca7007f473dbaf7c3570f5dc9"] }], ''{"rescan": false}''] }' -H 'content-type: text/plain;' http://user:password@127.0.0.1:18332/

Which returns a warning:
success = 1;
            warnings =             (
                "Importing as non-solvable: redeemScript does not match the scriptPubKey. If this is intentional, don't provide any keys, pubkeys, witnessscript, or redeemscript."
            );

I am using the address and redemption script createmultisig returns.
What am I doing wrong? Why is the redemption script incorrect?
My goal is to add the multi sig wallet to my node so that I can build transactions with the wallet without having to manually input the redemption script.

createmultisig is likely giving you the p2sh-segwit address, not the p2sh one. This means that the "redeemScript" you get from it is actually the witnessScript and the real redeemScript is the p2wsh script for your witnessScript. You can tell createmultisig to create just a p2sh address by setting the address type parameter to legacy.
Alternatively, you can get the redeemScript for your witnessScript by usingdecodescript.decodescript` will first decode your script, then it will give you the various possible addresses for it (for each address type available) along with the scripts for them.

Or even better, use the descriptor based importmulti.

Thanks to you both. I will try the descriptor based approach.


text:
 In what cases would a bitcoin address not have a private key?
According to the https://en.bitcoin.it/wiki/Address site, it states that "most" addresses have a private key.  Here is the relavent text:

Most addresses have a "private key"
For most addresses, there is a corresponding secret number known as a private  key that is required to spend funds previously sent to an address.
  When using a Bitcoin client, private keys are typically stored in the wallet file. The private key has a special purpose - it is mathematically needed to create valid transactions that spend the funds originally sent to the address. If the private key to an address is lost (for example, in a hard drive crash, fire or other natural disaster), any associated Bitcoins are effectively lost forever.

I have always assumed that Bitcoin worked in such a way that all addresses must have a matching private key due to the public/private key encryption on which it is based.  In what cases would a bitcoin address not have a private key?

If an address merely 'looks like' an address and all other aspects of a transaction are ok then miners will include it in a block.
This has been (ab)used to embed ASCII art into the blockchain at the cost of permanently destroying some bitcoin.
For an example with explanation see https://bitcointalk.org/index.php?topic=33618.msg420597#msg420597

Here's another example: 1BitcoinEaterAddressDontSendf59kuE
Most certainly nobody has the private key that results in that Bicoin address (it would take more than trillions of years of all of today's existing computing capacity for a VanityGen type of app to find a private key that would hash to that Bitcoin address.

And a related forum thread: http://bitcointalk.org/index.php?topic=26539.0

So the issue isn't so much that a private key doesn't exist as that no one knows (or can know) what the corresponding private key is... got it.

@JasonSouthwell: And it is at least theoretically possible that there might not be one.

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


text:
PBFT algorithm - how do we know how many nodes are faulty?
I am reading this article about PBFT and I have trouble understanding how it can be used in practice. If we don't how many nodes are faulty (which I believe is a valid assumption), then how can we calculate the number of rounds during which processes send messages to each other?
The linked article shows an example with n = 7 and m = 2 and in that example two rounds of messaging are executed and then the output values are calculated. But how can we know that m = 2 in the first place? Can the algorithm itself figure it out during execution?

The n and m parameters are chosen by the implementer when they choose to use the algorithm. For example, I may decide to use this algorithm on 50 nodes and choose to be able to tolerate up to 4 faulty nodes. Thus, my n is 50 and my m is 4.
If I need to design a system to tolerate a variety of different n values, I'll have some piece of code somewhere that, given the actual number of nodes being used (the n value), picks the number of faulty nodes I want the algorithm to be able to tolerate (the m value).
In all cases, n must be known. You have to know how many nodes are in your system or you don't have a system. Then m can be chosen by code, subject to the limitations of the algorithm. Then both n and m are known.
For example, you might have some code that reads a configuration file that specifies the identity of the other nodes in the system as well as the number of faulty nodes that the system is going to tolerate. Then people using that code create that configuration file and load it into all of the nodes. Now you have a usable system.

"choose to be able to tolerate up to 4 faulty nodes" - this is the part that I was missing; that the implementer chooses how many faulty nodes the system is able to tolerate


text:
Two errors when trying to run make command
I am trying to build Bitcoin Core on MacOs.
Followed instructions here https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md
When I run make command, I get these two errors

2 errors generated.
make[2]: *** [libbitcoin_server_a-miner.o] Error 1
make[1]: *** [all-recursive] Error 1

Tried sudo make but results are the same.
Bitcoin core version I'm working with is 0.15.0 (I know it's old but I'm trying to follow instructions from the 'Mastering Bitcoin' book)
EDIT : FULL ERROR

In file included from /usr/local/include/boost/multi_index/ordered_index.hpp:17:
/usr/local/include/boost/multi_index/detail/ord_index_impl.hpp:1253:26: error:
no matching function for call to object of type 'const
boost::multi_index::detail::ordered_index_implboost::multi_index::identity<CTxMemPoolModifiedEntry,
CompareModifiedEntry, boost::multi_index::detail::nth_layer<2,
CTxMemPoolModifiedEntry,
boost::multi_index::indexed_by<boost::multi_index::ordered_unique<modifiedentry_iter,
CompareCTxMemPoolIter, mpl_::na>,
boost::multi_index::ordered_non_unique<boost::multi_index::tag<ancestor_score,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
boost::multi_index::identity,
CompareModifiedEntry>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
std::1::allocator >,
boost::mpl::v_item<ancestor_score, boost::mpl::vector0<mpl::na>, 0>,
boost::multi_index::detail::ordered_non_unique_tag,
boost::multi_index::detail::null_augment_policy>::key_compare' (aka 'const
CompareModifiedEntry')
return y==header()||!comp(key(y->value()),key(v));
^~~~~
./miner.h:74:10: note: candidate function not viable: 'this' argument has type
'const
boost::multi_index::detail::ordered_index_implboost::multi_index::identity<CTxMemPoolModifiedEntry,
CompareModifiedEntry, boost::multi_index::detail::nth_layer<2,
CTxMemPoolModifiedEntry,
boost::multi_index::indexed_by<boost::multi_index::ordered_unique<modifiedentry_iter,
CompareCTxMemPoolIter, mpl_::na>,
boost::multi_index::ordered_non_unique<boost::multi_index::tag<ancestor_score,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
boost::multi_index::identity,
CompareModifiedEntry>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na,
mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>,
std::_1::allocator >,
boost::mpl::v_item<ancestor_score, boost::mpl::vector0<mpl::na>, 0>,
boost::multi_index::detail::ordered_non_unique_tag,
boost::multi_index::detail::null_augment_policy>::key_compare' (aka 'const
CompareModifiedEntry'), but method is not marked const
bool operator()(const CTxMemPoolModifiedEntry &a, const CTxMemPoolMo...
^
2 errors generated.
make[2]: *** [libbitcoin_server_a-miner.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

This can't be the only error printed. Can you see any other error above?

@MCCCS Right. Editted the post

This issue caused by newer versions of Boost was later solved. You may either checkout v0.15.2 or download the 0.15.2 tagged source code here

Tried it. Getting same errors. I only chose 0.15.0 because it's used in the book. Can I try latest version still understand what the book says? Is there a big difference?

@GugaTodua Yes, no, the build instructions haven't changed since


text:
How to create a valid time locked descriptor?
I am attempting to bitcoin-cli getdescriptorinfo "wpkh([00000000/84h/1h/0h/2]tpubDECM3jqdpSiGU2mKmo6xXxxXwFcmz6fX9EHMV3zbTY236jYYK9tM57cRFWaHqNjLbqAy52P6wkyo9wCAnr4P7Q1hGGFnrW98LPLajXEZPez/35:1669852800)" as Join Market expresses this format 35:1669852800 (address index 35 with a unix timestamp in a bip32 path) for time locked addresses but it does not work with bitcoin-cli.
How would one create a valid output descriptor for a time locked address derived with bip32 (which contains all info to make it solvable in my wallet)?

The format you have shown is not a valid descriptor format - it is not described in either the descriptor documentation nor the BIP, so JoinMarket is producing incompatible descriptors.
Strictly speaking, with just descriptors as specified in the documentation and the BIPs, it is currently not possible to create a descriptor with a timelock. However Bitcoin Core has added Miniscript watchonly support for the upcoming 24.0 release. While this is documented, it does not have a BIP yet.
It is possible to use Miniscript to make a descriptor that produces a logically identical script. However it may not actually match what JoinMarket produces, so use at your own risk. The descriptor would look something like:
wsh(and_v(v:pk([00000000/84h/1h/0h/2]tpubDECM3jqdpSiGU2mKmo6xXxxXwFcmz6fX9EHMV3zbTY236jYYK9tM57cRFWaHqNjLbqAy52P6wkyo9wCAnr4P7Q1hGGFnrW98LPLajXEZPez/35),after(1669852800))

which would produce a witness script hash address that has a witness script of the form
<pubkey> OP_CHECKSIGVERIFY 1669852800 OP_CHECKLOCKTIMEVERIFY

Could it be that one is about timelocked transactions (nlocktime field) and the other about scripts with op_cltv?

There is BIP proposal for fidelity bonds by Chris Belcher - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html.
JM uses
<timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP <derived_key> OP_CHECKSIG

not
<derived_key> OP_CHECKSIGVERIFY <timelock> OP_CHECKLOCKTIMEVERIFY

See https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e?permalink_comment_id=4151609#gistcomment-4151609.

Interesting. It seems like that is incompatible with Miniscript and Bitcoin Core then.


text:
How are crypto wallets derived? Specifically the BIP32 Root key
I realize this is a very broad question.  I'm not getting helpful resources from anywhere. White papers don't really explain the code, YouTube videos are vague or abstract, demonstration sites don't really show the work.
I'm coding my own wallet (I wont actually use it; it's just academic), in Python. And no, Im not using special crypto wallet packages; it would defeat the purpose of learning what's going on here.
I'm also using https://iancoleman.io/bip39/ as a reference to verify my work.
I've gotten all the way up to the BIP39 Hexadecimal Seed. I don't know where to go from there; it suddenly got complicated and like I said, references don't really explain much of anything. If anyone knows of a good source to learn the nitty gritty details of actually constructing a working wallet, for arbitrary coin, please do let me know. I'd appreciate it immensely not to keep having to ask questions for every step.
It would seem, judging from Ian's site, that the next step is to decide which coin I'm using, and to produce a BIP32 Root Key. The site would also seem to indicate this is done before deciding on a derivation path. How is this done?
Assume I know which coin I'm wanting to build the wallet for (I know there is a list of registered coins with an associated number for each, e.g. BTC=0).
FYI, Im not looking for python code; Im looking for a specific, detailed explanation on the next steps in the process. Something that I can actually implement.

I’ve went through that exercise before, take a look at https://github.com/mcdallas/cryptotools/blob/master/cryptotools/BTC/HD/bip32.py (pure python code) and https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

Does this answer your question? Can someone explain *simply*, but precisely, how the mnemonic seed phrase is used to produce the bip39 seed


text:
What is the concept behind extracting point x from point y given that both are correspondants of G ^ k mod p
Within the encryption protocol that governs bitcoin (Secp256k1 to be precise), the generated points publicKey_x and publicKey_y are a results of calculated coordinates within the finite field " G^K " (where G is a combination of GeneratorPoint_X and GeneratorPoint_Y and k is order value of n).
My question is, if we have only the Y coordinate belonging to a given publicKey, can we get the X coordinate?
or Is it only possible to derive Y from X and not the other way around?
If so how can this be achieved?

It isn't an encryption protocol as nothing is being encrypted. A public key is calculated from a private key and then the private key is used to generate digital signatures proving ownership of the private key associated with that public key without leaking the private key.
But yes with an elliptic curve the Y coordinate can be calculated from the X coordinate and vice versa. Just substitute x into
y^2 = x^3 + 7 (mod p)

where p = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1
or rearrange to get:
x^3 = y^2 - 7 (mod p)

There is a complication in that every valid X coordinate has two possible Y coordinates (as detailed in BIP340) but BIP340 also instructs you on which Y coordinate to pick for Schnorr public keys.
Pieter added in the comments that it is also the case (only for y^2 = x^3 + B curves like secp256k1) that every valid Y coordinate has three corresponding X coordinates.

Thanks for your answer.. Yes not encryption meant to say DSA... My bad. Thanks anyways

Similar to how every valid X coordinate has 2 correponding Y coordinates, it is also the case (only for y^2=x^3+B curves like secp256k1) that every valid Y coordinate has three corresponding X coordinates.

@PieterWuille You know at this point, you're literally a guru..

I refuse to believe that you're real


text:
Verifying the Pizza transaction in Python
A friend of mine and I are trying to learn how to read the bitcoin blockchain. We've gotten pretty much everything except the ECDSA verification that the coins spent actually belong to the person who is spending them.
We're working off this answer from @amaclin from here: https://bitcoin.stackexchange.com/a/32308/235711
Here's our gist: https://gist.github.com/bnsh/922b5331a77f6b85d14e0bd682f6304d
And, here's the code directly.
#! /usr/bin/env python3
# vim: expandtab shiftwidth=4 tabstop=4

"""
Hi.

We're trying to implement this code at https://bitcoin.stackexchange.com/a/32308/235711 in python with the
ecdsa library. Unfortunately, we're not clear on what language this code below is written in.. C++? C#?

We'd like to verify using python, but it doesn't seem to work. Can someone tell us what we're doing wrong?

const QByteArray xx ( QByteArray::fromHex ( "01000000018dd4f5fbd5e980fc02f35c6ce145935b11e284605bf599a13c6d41"
                                            "5db55d07a1000000001976a91446af3fb481837fadbb421727f9959c2d32a368"
                                            "2988acffffffff0200719a81860000001976a914df1bd49a6c9e34dfa8631f2c"
                                            "54cf39986027501b88ac009f0a5362000000434104cd5e9726e6afeae357b180"
                                            "6be25a4c3d3811775835d235417ea746b7db9eeab33cf01674b944c64561ce33"
                                            "88fa1abd0fa88b06c44ce81e2234aa70fe578d455dac0000000001000000" ) );
const MyKey32 digest ( xx.constData ( ), xx.size ( ) ); // construct object of sha256 (sha256 ( xx ) )
_trace ( digest.toString ( ) );                         // print result
const QByteArray pubkey ( QByteArray::fromHex ( "042e930f39ba62c6534ee98ed20ca98959d34aa9e057cda01cfd422c6bab3667b76426529382c23f42b9b08d7832d4fee1d6b437a8526e59667ce9c4e9dcebcabb" ) );
const QByteArray signature ( QByteArray::fromHex ( "30450221009908144ca6539e09512b9295c8a27050d478fbb96f8addbc3d075544dc41328702201aa528be2b907d316d2da068dd9eb1e23243d97e444d59290d2fddf25269ee0e" ) );
_trace ( QString ( "verify=%1" ).arg ( digest.verify ( pubkey, signature ) ) );
"""

import hashlib
import ecdsa

def from_hex(hexval):
    return bytes(int(hexval[idx:(idx+2)], 16) for idx in range(0, len(hexval), 2))

def to_hex(raw):
    return "".join(reversed([f"{int(val):02x}" for val in raw]))

def mykey32(data):
    return hashlib.sha256(hashlib.sha256(data).digest()).digest()

def main():
    # We're preserving the same variable names as the sample code above
    # for clarity.
    xx = from_hex(
        "01000000018dd4f5fbd5e980fc02f35c6ce145935b11e284605bf599a13c6d41"
        "5db55d07a1000000001976a91446af3fb481837fadbb421727f9959c2d32a368"
        "2988acffffffff0200719a81860000001976a914df1bd49a6c9e34dfa8631f2c"
        "54cf39986027501b88ac009f0a5362000000434104cd5e9726e6afeae357b180"
        "6be25a4c3d3811775835d235417ea746b7db9eeab33cf01674b944c64561ce33"
        "88fa1abd0fa88b06c44ce81e2234aa70fe578d455dac0000000001000000"
    )
    digest = mykey32(xx)
    print(to_hex(digest)) # This clearly works as described in the post.

    pubkey = from_hex("042e930f39ba62c6534ee98ed20ca98959d34aa9e057cda01cfd422c6bab3667b76426529382c23f42b9b08d7832d4fee1d6b437a8526e59667ce9c4e9dcebcabb")
    signature = from_hex("30450221009908144ca6539e09512b9295c8a27050d478fbb96f8addbc3d075544dc41328702201aa528be2b907d316d2da068dd9eb1e23243d97e444d59290d2fddf25269ee0e")

    verkey = ecdsa.VerifyingKey.from_string(pubkey, curve=ecdsa.SECP256k1)

    # This fails with ecdsa.keys.BadSignatureError: MalformedSignature('Invalid length of signature[...]')
    # It seems like it wants a 64 byte signature.
    verkey.verify(signature, digest)

    # How would we verify the pizza transaction as was done in the post
    # in python?
    # Thanks!

if __name__ == "__main__":
    main()

We're using the ecdsa python library (but we're OK with any other more appropriate library). How can we verify the signature using python?
Thanks.

OK, answering my own question..
There were three problems:

VerifyingKey.verify's default value for hashfunc is hashlib.sha1, but we need hashlib.sha256. So, we need to add a hashfunc=hashlib.sha256 to the verify call. ECDSA docs

What needs to get passed to the digest should be a single call to hashlib.sha256, not the double call that's usually done.

The signature is actually a DER signature, which needs to be extracted. There is a library to do this, but we wanted to understand what was happening.
a. The first byte in the signature is a 0x30 which signifies a "sequence" Intro to ASN.1.
b. Next comes a 0x45, which indicates that the total following length of the sequence in bytes: 4 * 16 + 5 = 69.
c. Next comes a 0x02, which indicates an integer.
d. Next comes a 0x21. This is supposed to be the length of the first integer in the signature. But, we have to only extract the last 32 bytes of the integer.
e. After the 33 bytes at byte 37 is another 0x02 (for another integer)
f. Then comes a 0x20 (32 bytes) for the next integer
So, the "real" signature is signature[5:(5+32)] + signature[39:(39+32)]

If we then do verkey.verify(signature, digest, hashfunc=hashlib.sha256) it runs without any exception.
The fixed code is here: https://gist.github.com/bnsh/808f2652818907e5153ee0dfde57a40f


text:
Keys Security Best practices in a Lightning company
"What are some key security practices for running a company that works on Lightning?

Risk of someone running away with the funds
Alternatives to multi-sig for lightning
Resources in the space
Best practices


text:
Altcoin solo mining issue with Cpuminer
I have cloned litecoin to make my own altcoin for fun and i want to solo mine the new coin using cpuminer on mainnet. I have compiled and installed cpu miner in my Mac OSX and i am running the altcoin daemon and opened the port as well.
./src/altcoind -daemon

When i run cpuminer i get this error.
./minerd -o http://127.0.0.1:26201 -O litecoinrpc:9eac7ba52764a6d42aa48386e8f435f8 -a scrypt --no-longpoll --no-getwork --no-stratum --coinbase-addr=xxxxxx

[2018-02-27 17:55:48] Binding thread 2 to cpu 2
[2018-02-27 17:55:48] Binding thread 0 to cpu 0
[2018-02-27 17:55:48] Binding thread 1 to cpu 1
[2018-02-27 17:55:48] Binding thread 4 to cpu 4
[2018-02-27 17:55:48] Binding thread 3 to cpu 3
[2018-02-27 17:55:48] Binding thread 5 to cpu 5
[2018-02-27 17:55:48] 8 miner threads started, using 'scrypt' algorithm.
[2018-02-27 17:55:48] Binding thread 6 to cpu 6
[2018-02-27 17:55:48] Binding thread 7 to cpu 7
[2018-02-27 17:55:48] HTTP request failed: Failed to connect to 127.0.0.1 port 26201: Connection refused
[2018-02-27 17:55:48] json_rpc_call failed, retry after 30 seconds

Here is my altcoin.conf
rpcuser=litecoinrpc
rpcpassword=xxxxxx
rpcport=262012
rpcallowip=127.0.0.1
server=1
gen=1
listen=1

Why is cpuminer not working?
Another attempt: I changed the conf file removing port
rpcuser=litecoinrpc
rpcpassword=xxxx
rpcallowip=127.0.0.1
listen=1
server=1
daemon=1

and now it seems to connect to the port but i receive, empty reply from server
[2018-02-27 18:23:11] Binding thread 4 to cpu 4
[2018-02-27 18:23:11] Binding thread 5 to cpu 5
[2018-02-27 18:23:11] Binding thread 6 to cpu 6
[2018-02-27 18:23:11] 8 miner threads started, using 'scrypt' algorithm.
[2018-02-27 18:23:11] Binding thread 7 to cpu 7
[2018-02-27 18:23:11] HTTP request failed: Empty reply from server
[2018-02-27 18:23:11] json_rpc_call failed, retry after 30 seconds

Any help or advise is much appreciated.

your node should be connected to others

I had similar issue and i switched to sgminer, even cgminer is good option but personally i used sgminer with same setting as yours, and everything is working fine in my case

(c/s)gminer  is easy to configure and easy to setup as well

all these support scrypt?

ya they supprot scrypt and they are very easy to use and configure as well

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


text:
Altcoin nodes connection issues
I have cloned litecoin for fun and i am struggling with connecting to nodes. I have generated genesis block and compilation all works fine.
I have two litecoin daemons running on my local Macosx and on amazon vps but i cant seem to connect both.  I am running mainnet on port 26201
i tried running ./litecoind -daemon -addnode=x.y.y.y but it is not working.
chainparams.cpp
class CMainParams : public CChainParams {
public:
    CMainParams() {
        strNetworkID = "main";
        consensus.nSubsidyHalvingInterval = 100000;
        consensus.BIP34Height = 710000;
        consensus.BIP34Hash = uint256S("e6024058338254100b68f794f3a5d14f9b9a7f0bfb68bf302d63c47c027b64ca");
        consensus.BIP65Height = 918684; // bab3041e8977e0dc3eeff63fe707b92bde1dd449d8efafb248c27c8264cc311a
        consensus.BIP66Height = 811879; // 7aceee012833fa8952f8835d8b1b3ae233cd6ab08fdb27a771d2bd7bdc491894
        consensus.powLimit = uint256S("e6024058338254100b68f794f3a5d14f9b9a7f0bfb68bf302d63c47c027b64ca");
        consensus.nPowTargetTimespan = 3.5 * 24 * 60 * 60; // 3.5 days
        consensus.nPowTargetSpacing = 2.5 * 60;
        consensus.fPowAllowMinDifficultyBlocks = false;
        consensus.fPowNoRetargeting = false;
        consensus.nRuleChangeActivationThreshold = 6048; // 75% of 8064
        consensus.nMinerConfirmationWindow = 8064; // nPowTargetTimespan / nPowTargetSpacing * 4
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28;
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 1199145601; // January 1, 2008
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 1230767999; // December 31, 2008

        // Deployment of BIP68, BIP112, and BIP113.
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 1485561600; // January 28, 2017
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 1517356801; // January 31st, 2018

        // Deployment of SegWit (BIP141, BIP143, and BIP147)
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].bit = 1;
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 1485561600; // January 28, 2017
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1517356801; // January 31st, 2018

        // The best chain should have at least this much work.
        consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000000000000000000000400040");

        // By default assume that the signatures in ancestors of this block are valid.
        consensus.defaultAssumeValid = uint256S("0x3095c904a9907471390b80730bb760b28754501006cd7fe8ea0943dd71796c51"); //1353397

        /**
         * The message start string is designed to be unlikely to occur in normal data.
         * The characters are rarely used upper ASCII, not valid as UTF-8, and produce
         * a large 32-bit integer with any alignment.
         */
        pchMessageStart[0] = 0xfb;
        pchMessageStart[1] = 0xc0;
        pchMessageStart[2] = 0xb6;
        pchMessageStart[3] = 0xdb;
        nDefaultPort = 26201;
        nPruneAfterHeight = 100000;

        genesis = CreateGenesisBlock(1518803474, 4251767 , 0x1e0ffff0, 1, 1000 * COIN);
        consensus.hashGenesisBlock = genesis.GetHash();

        //printf("Genesis hash:  %s\n", consensus.hashGenesisBlock.ToString().c_str());
        //printf("Merkel root:  %s\n", genesis.hashMerkleRoot.ToString().c_str());

        assert(consensus.hashGenesisBlock == uint256S("0xe6024058338254100b68f794f3a5d14f9b9a7f0bfb68bf302d63c47c027b64ca"));
        assert(genesis.hashMerkleRoot == uint256S("0x29b1458191d86739ff3ef0f179c0927a95cb89fa054e3e2a41dfe843ee0acc42"));

        // Note that of those with the service bits flag, most only support a subset of possible options
        //vSeeds.emplace_back("dnsseed.citizenshipcoin.org", true);
        //vSeeds.emplace_back("dnsseed.thrasher.io", true);
        //vSeeds.emplace_back("dnsseed.litecointools.com", true);
        //vSeeds.emplace_back("dnsseed.litecoinpool.org", true);
        //vSeeds.emplace_back("dnsseed.koin-project.com", false);

        base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,11);
        base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,5);
        base58Prefixes[SCRIPT_ADDRESS2] = std::vector<unsigned char>(1,50);
        base58Prefixes[SECRET_KEY] =     std::vector<unsigned char>(1,176);
        base58Prefixes[EXT_PUBLIC_KEY] = {0x04, 0x88, 0xB2, 0x1E};
        base58Prefixes[EXT_SECRET_KEY] = {0x04, 0x88, 0xAD, 0xE4};

        vFixedSeeds = std::vector<SeedSpec6>(pnSeed6_main, pnSeed6_main + ARRAYLEN(pnSeed6_main));

        fDefaultConsistencyChecks = false;
        fRequireStandard = true;
        fMineBlocksOnDemand = false;

        checkpointData = (CCheckpointData) {
            {
                { 1, uint256S("0xcbf5d62bd22c4bbd616bd59b2b634d2fa896a4192a5c24298b26e1d9454e8559")},
                { 3, uint256S("0x3095c904a9907471390b80730bb760b28754501006cd7fe8ea0943dd71796c51")},
                { 5, uint256S("0x11f32abdff3d58c27ebbf53ff1fbc15aabef8b5f7665fd84ba3ce1f368402798")},
           /*     { 23420, uint256S("0xd80fdf9ca81afd0bd2b2a90ac3a9fe547da58f2530ec874e978fce0b5101b507")},
                { 50000, uint256S("0x69dc37eb029b68f075a5012dcc0419c127672adb4f3a32882b2b3e71d07a20a6")},
                { 80000, uint256S("0x4fcb7c02f676a300503f49c764a89955a8f920b46a8cbecb4867182ecdb2e90a")},
                {120000, uint256S("0xbd9d26924f05f6daa7f0155f32828ec89e8e29cee9e7121b026a7a3552ac6131")},
                {161500, uint256S("0xdbe89880474f4bb4f75c227c77ba1cdc024991123b28b8418dbbf7798471ff43")},
                {179620, uint256S("0x2ad9c65c990ac00426d18e446e0fd7be2ffa69e9a7dcb28358a50b2b78b9f709")},
                {240000, uint256S("0x7140d1c4b4c2157ca217ee7636f24c9c73db39c4590c4e6eab2e3ea1555088aa")},
                {383640, uint256S("0x2b6809f094a9215bafc65eb3f110a35127a34be94b7d0590a096c3f126c6f364")},
                {409004, uint256S("0x487518d663d9f1fa08611d9395ad74d982b667fbdc0e77e9cf39b4f1355908a3")},
                {456000, uint256S("0xbf34f71cc6366cd487930d06be22f897e34ca6a40501ac7d401be32456372004")},
                {638902, uint256S("0x15238656e8ec63d28de29a8c75fcf3a5819afc953dcd9cc45cecc53baec74f38")},
                {721000, uint256S("0x198a7b4de1df9478e2463bd99d75b714eab235a2e63e741641dc8a759a9840e5")}, */
            }
        };

        chainTxData = ChainTxData{
            // Data as of block 59c9b9d3fec105bdc716d84caa7579503d5b05b73618d0bf2d5fa639f780a011 (height 1353397).
            1516406833, // * UNIX timestamp of last known number of transactions
            19831879,  // * total number of transactions between genesis and that timestamp
                    //   (the tx=... number in the SetBestChain debug.log lines)
            0.06     // * estimated number of transactions per second after that timestamp
        };

chainparamsseeds.h
#ifndef BITCOIN_CHAINPARAMSSEEDS_H
#define BITCOIN_CHAINPARAMSSEEDS_H
/**
 * List of fixed seed nodes for the litecoin network
 * AUTOGENERATED by contrib/seeds/generate-seeds.py
 *
 * Each line contains a 16-byte IPv6 address and a port.
 * IPv4 as well as onion addresses are wrapped inside a IPv6 address accordingly.
 */
static SeedSpec6 pnSeed6_main[] = {
   // {{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0x0d,0x3b,0xbd,0x0b}, 26201}
};

static SeedSpec6 pnSeed6_test[] = {
    //{{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0x0d,0x3b,0xbd,0x0b}, 26202}
};
#endif // BITCOIN_CHAINPARAMSSEEDS_H

litecoin.conf (macosx)
rpcuser=litecoinrpc
rpcpassword=xxxx
addnode=xx.xx.xx.xx:26201

i dont have litecoin.conf on my vps node.
debug.log (macosx)
2018-02-23 17:07:18 0 addresses found from DNS seeds
2018-02-23 17:07:18 dnsseed thread exit
2018-02-23 17:08:19 socket recv error Connection reset by peer (54)
2018-02-23 17:08:19 Adding fixed seed nodes as DNS doesn't seem to be available.
2018-02-23 17:09:19 socket recv error Connection reset by peer (54)
2018-02-23 17:10:20 socket recv error Connection reset by peer (54)
2018-02-23 17:11:20 socket recv error Connection reset by peer (54)
2018-02-23 17:13:22 socket recv error Connection reset by peer (54)
2018-02-23 17:15:23 socket recv error Connection reset by peer (54)

debug.log (vps)
The debug.log on my vps shows this (lots of lines) with port numbers cycled.
2018-02-23 17:09:19 connection from x.x.x.x:55668 dropped (banned)
2018-02-23 17:09:19 connected to self at y.y.y.y:49226, disconnecting

I know x.x.x.x is my ip of macosx and y.y.y.y is local vps server public ip address.
Why is it iam not able to connect to nodes?
Looking at the debug.log why are the IP's cycling through different ports over 55,000 instead of connecting to 26201 where it is supposed to connect?

It started to work, after i deleted the .~/.litecoin` folder except wallet.dat on both nodes.

2018-02-23 17:09:19 connection from x.x.x.x:55668 dropped (banned)

Looking at what you have posted in your question, your node is dropped because it is banned.
You need to clear your ban list for starters and possibly work out why it was banned - from the logs.

Looking at the debug.log why are the IP's cycling through different ports over 55,000 instead of connecting to 26201 where it is supposed to connect?

The ports over 55,000 are the from ports, since you are seeing the connection attempt in your logs the to port is 26201 presuming you have                                                                                everything correctly configured as described.


text:
Why cant my Altcoin Regnet create first 100 blocks?
I have modified bitcoin source code for my altcoin. I have successfully created genesis block, merkel root, noonce and daemon is working well. I have tweaked number of coins per day, total coins etc.. I have also set the bitcoin.conf to server=1, regtest=1 with rpc user and password.
Now i am following the bitcoin CLI tutorial to create first 101 blocks,  but it only creates 1 block instead of 101 blocks.
https://bitcoin.org/en/developer-examples#testing-applications
The problem is using the CLI, when i generate 100 blocks only one block is created why?
Here is my chainparams.cpp (clipped code)
/**
 * Regression test
 */
class CRegTestParams : public CChainParams {
public:
    CRegTestParams() {
        strNetworkID = "regtest";
        consensus.nSubsidyHalvingInterval = 150;
        consensus.BIP16Height = 0; // always enforce P2SH BIP16 on regtest
        consensus.BIP34Height = 100000000; // BIP34 has not activated on regtest (far in the future so block v1 are not rejected in tests)
        consensus.BIP34Hash = uint256();
        consensus.BIP65Height = 1351; // BIP65 activated on regtest (Used in rpc activation tests)
        consensus.BIP66Height = 1251; // BIP66 activated on regtest (Used in rpc activation tests)
        consensus.powLimit = uint256S("7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff");
        consensus.nPowTargetTimespan = 14 * 24 * 60 * 60; // two weeks
        consensus.nPowTargetSpacing = 10 * 60;
        consensus.fPowAllowMinDifficultyBlocks = true;
        consensus.fPowNoRetargeting = true;
        consensus.nRuleChangeActivationThreshold = 108; // 75% for testchains
        consensus.nMinerConfirmationWindow = 144; // Faster than normal for regtest (144 instead of 2016)[/code]

and in the commanline, it is executing only one block.
./bitcoin-cli -regtest generate 101
[
  "179ef1bb855aed3d01324e6eff17ce63773b3ae79a0e123bfdf7f5d11cad0360"
]

and the output (clipped)
 ./bitcoin-cli -regtest getblockchaininfo
    {
      "chain": "regtest",
      "blocks": 4,
      "headers": 4,
      "bestblockhash": "179ef1bb855aed3d01324e6eff17ce63773b3ae79a0e123bfdf7f5d11cad0360",
      "difficulty": 4.656542373906925e-10,
      "mediantime": 1516037681,
      "verificationprogress": 1,
      "initialblockdownload": false,
      "chainwork": "0000000000000000000000000000000000000000000000000000000100010009",
      "size_on_disk": 1551,
      "pruned": false,
      "softforks": [
        {
          "id": "bip34",
          "version": 2,
          "reject": {
            "status": false
          }

What is preventing creating 101 blocks?
I am seeing this in debug.log
2018-01-16 20:40:30 Bitcoin version v0.15.99.0-45173fa6f-dirty
2018-01-16 20:40:30 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2018-01-16 20:40:30 Assuming ancestors of block 0000000000000000003b9ce759c2a087d52abc4266f8f4ebd6d768b89defa50a have valid signatures.
2018-01-16 20:40:30 Setting nMinimumChainWork=000000000000000000000000000000000000000000723d3581fe1bd55373540a
2018-01-16 20:40:30 Using the 'sse4' SHA256 implementation
2018-01-16 20:40:30 Using RdRand as an additional entropy source
2018-01-16 20:40:30 Default data directory /Users/prabhubalakrishnan/Library/Application Support/Bitcoin
2018-01-16 20:40:30 Using data directory /Users/prabhubalakrishnan/Library/Application Support/Bitcoin
2018-01-16 20:40:30 Using config file /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/bitcoin.conf
2018-01-16 20:40:30 Using at most 125 automatic connections (283 file descriptors available)
2018-01-16 20:40:30 Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2018-01-16 20:40:30 Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2018-01-16 20:40:30 Using 4 threads for script verification
2018-01-16 20:40:30 scheduler thread start
2018-01-16 20:40:30 HTTP: creating work queue of depth 16
2018-01-16 20:40:30 Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
2018-01-16 20:40:30 HTTP: starting 4 worker threads
2018-01-16 20:40:30 Using wallet directory /Users/prabhubalakrishnan/Library/Application Support/Bitcoin
2018-01-16 20:40:30 init message: Verifying wallet(s)...
2018-01-16 20:40:30 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2018-01-16 20:40:30 Using wallet wallet.dat
2018-01-16 20:40:30 CDBEnv::Open: LogDir=/Users/prabhubalakrishnan/Library/Application Support/Bitcoin/database ErrorFile=/Users/prabhubalakrishnan/Library/Application Support/Bitcoin/db.log
2018-01-16 20:40:30 Cache configuration:
2018-01-16 20:40:30 * Using 2.0MiB for block index database
2018-01-16 20:40:30 * Using 8.0MiB for chain state database
2018-01-16 20:40:30 * Using 440.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2018-01-16 20:40:30 init message: Loading block index...
2018-01-16 20:40:30 Wiping LevelDB in /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/blocks/index
2018-01-16 20:40:30 Opening LevelDB in /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/blocks/index
2018-01-16 20:40:30 Opened LevelDB successfully
2018-01-16 20:40:30 Using obfuscation key for /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/blocks/index: 0000000000000000
2018-01-16 20:40:30 Initializing databases...
2018-01-16 20:40:30 Wiping LevelDB in /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/chainstate
2018-01-16 20:40:30 Opening LevelDB in /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/chainstate
2018-01-16 20:40:30 Opened LevelDB successfully
2018-01-16 20:40:30 Wrote new obfuscate key for /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/chainstate: 58c6b9c1e6d24649
2018-01-16 20:40:30 Using obfuscation key for /Users/prabhubalakrishnan/Library/Application Support/Bitcoin/chainstate: 58c6b9c1e6d24649
2018-01-16 20:40:30  block index              38ms
2018-01-16 20:40:30 init message: Loading wallet...
2018-01-16 20:40:30 nFileVersion = 159900
2018-01-16 20:40:30 Keys: 1002 plaintext, 0 encrypted, 1002 w/ metadata, 1002 total
2018-01-16 20:40:30  wallet                   38ms
2018-01-16 20:40:30 setKeyPool.size() = 1000
2018-01-16 20:40:30 mapWallet.size() = 0
2018-01-16 20:40:30 mapAddressBook.size() = 2
2018-01-16 20:40:30 Reindexing block file blk00000.dat...
2018-01-16 20:40:30 UpdateTip: new best=00000000f81247b7a7fe3c913d1d4ca3e8534349639cf21d0a0ed45fad2582c5 height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2018-01-08 16:25:32' progress=0.000000 cache=0.0MiB(0txo)
2018-01-16 20:40:30 mapBlockIndex.size() = 1
2018-01-16 20:40:30 nBestHeight = 0
2018-01-16 20:40:30 torcontrol thread start
2018-01-16 20:40:30 Bound to [::]:21600
2018-01-16 20:40:30 Bound to 0.0.0.0:21600
2018-01-16 20:40:30 init message: Loading P2P addresses...
2018-01-16 20:40:30 Loaded 1025 addresses from peers.dat  4ms
2018-01-16 20:40:30 init message: Loading banlist...
2018-01-16 20:40:30 init message: Starting network threads...
2018-01-16 20:40:30 net thread start
2018-01-16 20:40:30 dnsseed thread start
2018-01-16 20:40:30 addcon thread start
2018-01-16 20:40:30 init message: Done loading
2018-01-16 20:40:30 opencon thread start
2018-01-16 20:40:30 msghand thread start
2018-01-16 20:40:30 Loaded 1 blocks from external file in 208ms
2018-01-16 20:40:30 Reindexing finished
2018-01-16 20:40:30 Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there
2018-01-16 20:40:41 Loading addresses from DNS seeds (could take a while)
2018-01-16 20:40:41 0 addresses found from DNS seeds
2018-01-16 20:40:41 dnsseed thread exit
 2018-01-17 15:45:56 Potential stale tip detected, will try using extra outbound peer (last tip update: 68726 seconds ago)
    2018-01-17 15:56:26 Potential stale tip detected, will try using extra outbound peer (last tip update: 69356 seconds ago)
    2018-01-17 16:06:56 Potential stale tip detected, will try using extra outbound peer (last tip update: 69986 seconds ago)
    2018-01-17 16:17:26 Potential stale tip detected, will try using extra outbound peer (last tip update: 70616 seconds ago)
    2018-01-17 16:27:56 Potential stale tip detected, will try using extra outbound peer (last tip update: 71246 seconds ago)

Can you post the contents of the debug.log file?

@AndrewChow Posted the debug.log

The section of debug.log you posted is completely useless. Post all of it.

Your generate command is wrong.
try: ./bitcoin-cli -regtest generate 101 -1
The -1 part means the daemon will continue attempting to generate blocks indefinitely until the amount of blocks, 101 have been generated


text:
How to run dns seeder?
Are there any tutorials on how to setup dnsseeder for a new altcoin. I am struggling with this for past couple of days.
I am modifying dogecoin seeder and i just cant setup on my server. My coin daemon is running on the same AWS server. I did open the ports 53 and for daemon and rpc.  I only have one ip running both daemon and dnsseed. My understanding is that the more nodes connect to dnsseed, it will auto add the nodes to its dns list.
i have set this on godaddy records
dnsseed.example.com -> IP

and IP is running dnsseeder.
Here i run
./dnsseed -h dnsseed.example.com -n IP

and i see this
Supporting whitelisted filters: 0x1,0x5,0x9,0xd
No e-mail address set. Please use -m.

When i check whether dnsseed is running,
netstat -anp

I could not find any process listening on port 53.
How do i check if dnsseed is running? Thank you for your time as i find this topic confusing.

Where you have set dnsseed.example.com -> IP I presume that you need an NS record so that queries can be resolved by your resolver.

I went to Godaddy, added dnssed.example IN NS vps.example.com and finally added host ip pointing from vps.example.com resolving to IP. see https://networkhobo.com/2014/07/22/godaddy-delegate-subdomain-to-different-nameserver/

Looks good, should work like that.

I realize this question is a couple years old, but a proper tutorial has never been written until now. The tutorial is somewhat large, so I won't re-post it here, but I wrote a step-by-step guide for setting up a DNS seeder that you can find permanently hosted here: https://github.com/team-exor/generic-seeder/blob/master/SETUP.md.
The instructions are written for a clone of the original bitcoin-seeder called the generic-seeder, which is a modified clone of the bitcoin-seeder that makes it easier to set up a DNS seed for virtually any alt coin by using a config file.
As far as why your seeder isn't working, part of it seems to be because you may not have created the proper DNS records. You say that you created:
dnsseed.example.com -> IP

but it should look more like this:
dnsseed.example.com -> vps.example.com -> IP

vps.example.com: "A" record that points to your server IP address
dnsseed.example.com: NS record that points to your "A" record (vps.example.com)
Once your two DNS entries are created, you can run the seeder app like this:
./dnsseed -h dnsseed.example.com -n vps.example.com -m test@example.com

test@example.com: this can be any email address and is only used to serve SOA record data from the local DNS server that the DNS seeder app is creating.
Full disclosure if it wasn't already obvious: I am the author of the generic-seeder.

DNS Seeders are not regular coin nodes but rather servers running a customized DNS binary. They do crawl a coin's P2P network and keep a list of currently live nodes to give as an answer when queried about a domain name.
This is great, because instead of a DNS server with a list of fixed IP addresses (where people promised to maintain nodes at), this dynamic DNS Seeder answers queries with many IP's of coin nodes that are really live at the time and actually do have their incoming ports open
There is no requirement to run a coin daemon on the same machine where the DNS Seeder is running, but it's OK if you do.
There is a tutorial at https://bitcointalk.org/index.php?topic=599623.0
The original DNS Seeder software was written and is maintained by Sipa (Peter Wuille). I think most others are derived from his. You can find it here: https://github.com/sipa/bitcoin-seeder
The best way to check if your DNS Seeder is answering requests is to use a DNS tool such as 'dig' or 'nslookup'. If it works, you will get a list of active nodes in your coin's P2P network.
Example:
$ nslookup seed.bitcoin.sipa.be

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   seed.bitcoin.sipa.be
Address: 2.154.184.130
Name:   seed.bitcoin.sipa.be
Address: 188.194.135.136
Name:   seed.bitcoin.sipa.be
Address: 65.95.168.76

..... (many more answers)

Name:   seed.bitcoin.sipa.be
Address: 46.166.164.223
Name:   seed.bitcoin.sipa.be
Address: 81.247.189.92

It looks like you had an extra space in your DNS seeder invocation ( -h ); you can also get rid of the email warning by adding an optional email address of the DNS Seeder admin:
./dnsseed -h dnsseed.example.com -n IP -m admin@my-coin.com


text:
NBitcoin get signature, use spending P2SH transaction with non-standard script
After creating a new NBitcoin transaction (with a single pay-to-script hash input and multiple outputs), is there any way to calculate the transaction signature and manually put it in the inputs[0].ScriptSig, along with other parameters used by the script?
A related issue is whether (and how) non-standard scripts can be used in P2SH transactions.

It seems the first question can be accomplished with something like:
//after creating newtx and specifying input and outputs
newtx.Inputs[0].ScriptSig = privatekey.ScriptPubKey;
newtx.Sign(privatekey, false);  //puts signature and pubkey in ScriptSig
//use those plus additional parameters in script
newtx.Inputs[0].ScriptSig = new Script(
   newtx.Inputs[0].ScriptSig + " " +
   //leave signature and pubkey as first parameters pushed onto stack
   //then add additional parameter (type PubKey)
   Op.GetPushOp(additionalParameter.ToBytes()) + " " +
   //then add script whose hash was in original P2SH trans
   Op.GetPushOp(scriptIn.ToBytes()));

The scriptIn is the same as the usual P2KH script preceded by a check for the hash of another parameter
scriptIn = new Script(
        "OP_HASH160 "
        + Op.GetPushOp(additionalParameter.Hash.ToBytes())
        + " OP_EQUALVERIFY"
        + " OP_DUP"
        + " OP_HASH160 "
        + Op.GetPushOp(pubkeyhash.ToBytes())
        + " OP_EQUALVERIFY"
        + " OP_CHECKSIG"
        );

But when the transaction is sent it gets the following error:
    16: mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation)
Not sure why it's failing.

the signature you are providing in newtx.Inputs[0].ScriptSig might not be valid for the script in scriptIn.


text:
Create a transaction spendable in a specific block height
I am new in Bitcoin and I try to create an address in Bitcoind and send a transaction that the amount will be spendable in a specific height of the blockchain.
Here is what I have done:
privateKey = 'cS5bZo8D1PBXwLbpGwYpb3CPvev5FYA7zPpftXAc6vzvbXt3aAa4'

absolute_time = 150

addr = getAddressFromPriv(privateKey) #customFunction

seq = Sequence(TYPE_ABSOLUTE_TIMELOCK, absolute_time)

script = Script([seq.for_script(),
                        'OP_CHECKLOCKTIMEVERIFY',
                        'OP_DROP',
                        'OP_DUP',
                        'OP_HASH160',
                        p2pkh_addr.to_hash160(),
                        'OP_EQUALVERIFY',
                        'OP_CHECKSIG'])

addr2 = convertScriptToAddress(script)

Then in bitcoin-cli I use that addr2 to bitcoin-cli sendtoaddress <addr2> 10
However, when I inspect the transaction it says that it is spendable in the current block height. Any idea?

Shouldn't you add the <absolute time/blockheight> before OP_CHECKLOCKTIMEVERIFY in the script? Also you are using 150 as the block height, which means it should be spendable immediately.

@UgamKamat: I think you're on to it, but please don't use comments to answer a question, rather post an answer. You can always edit your answer as the topic evolves.

Yeah, wasn't totally sure. So wanted @Tasos to check if that works. Writing it as an answer.

You have to add the absolute time/blockheight before OP_CHECKLOCKTIMEVERIFY in the script to depict how long you want to lock the transaction. Also you are using 150 as the CLTV parameter. Anything that is below 500M is dubbed as block height. Given you are using 150, that means that transaction is not spendable until 150 blocks, which should mean it is spendable immediately.

I use regtest and I reset the chain to test it. So, 150 blocks haven't reached yet. As for the OP_CHECKLOCKTIMEVERIFY isn't the seq.for_script() which is before that do the trick? Since the seq has the absolute time/blockheight

No. nSequnce has different meaning for CLTV. If nSequence value is >=2^31 it indicates that CLTV, or opt-in-replace is used. However, if nSequence value <2^31, it indicates CSV. nSequence value should however not be 0xffffffff when using cltv

So, to understand, it should be replaced with an integer for the absolute height like that? script = Script([150, 'OP_CHECKLOCKTIMEVERIFY', 'OP_DROP', 'OP_DUP', 'OP_HASH160', p2pkh_addr.to_hash160(),  'OP_EQUALVERIFY', 'OP_CHECKSIG'])

Unsure about the exact syntax, but think that should work.


text:
What is a security model, security assumption, and security guarantee?
I often hear bitcoiners talk about

security models
security assumptions
security guarantees

but I can't find definitions of these terms.
What do these terms mean and how do they relate to each other?

Maybe better suited for https://security.stackexchange.com/ (if this wouldn't be a duplicate already). Although i guess we can have an answer explaining how those applies to Bitcoin specifically.

@AntoinePoinsot yeah, there is one similar question there, https://security.stackexchange.com/questions/239211/threat-adversary-trust-security-model-what-is-the-difference but it's unanswered. And I ideally want this question answered with examples from a Bitcoin context.

A security model defines the abilities of an attacker and also defines what it means to break the security. For example, security models for key exchange protocols often define a break to mean an adversary can distinguish the shared secret key derived in the exchange from a random other key. Such models then define powers the adversary can have such as compromising certain combinations of keys, etc. More complicated protocols have more complicated security models. A good security model is one which captures all the real attacks one might expect on the system.
In security and cryptography, nothing is ever certain. Hence the reliance on clearly defined assumptions. When defining security, we do so in the context of these assumptions - if an assumption turns out to be false, the security of the scheme may be broken. Assumptions usually say something like, "it is infeasible for anyone to do XYZ" (although obviously stated more formally). For example, a lot of cryptographic protocols rely on the assumption that the discrete logarithm problem is hard in large enough elliptic curve groups over prime fields. The assumptions are made with respect to the best known attacks / computing power / resources of adversaries in the real world.
I'm not as familiar with what a "security guarantee" is in a formal sense. From what I understand, it is just used to mean anything which is guaranteed to hold in a security model based on the assumptions made. For example, we have a security guarantee that you cannot recover a private key from a secp256k1 public key if the discrete logarithm is hard on that curve.

Great, useful answer, thanks! An example of a security model for the moon may be "To break the security means to cut the moon in two", together with "The attacker has an axe".  A security assumption may be "there is no axe big enough to cut the moon in two". A security guarantee derived from this model and assumption is that the moon will not be cut in two. Did I get this right?

Something like that, sure!


text:
What is the relationship between LevelDB's cache (default 8MB) and Bitcoin's UTXO cache?
Please correct me if I am wrong.
Bitcoin uses levelDB to store UTXO set. LevelDB has a default 8MB block cache, and the Bitcoin also has a dbcache(default 450MB).

What is the relationship between the two?
Which part of the Bitcoin system does the levelDB's block cache correspond to?


text:
What is the data structure of the signature cache in Bitcoin?
There is a signature cache in Bitcoin, which is used to cache the result of signature verification to avoid extra signature verification. What data is stored in the signature cache? Is it stored in the form of key-value pairs or other forms?
When a Bitcoin node performs block validation, how does it determine that the signature verification result of a transaction is already in the signature cache?

The signature cache is basically a set of public key, message hash, and signature tuples. When there is a valid pubkey, message hash, and signature combination, all of those are hashed together with SHA256. This hash is then inserted into the signature cache. So the signature cache contains only the hashes of valid combinations. When verifying a signature, the pubkey, message hash, and signature are hashed together, and that resulting hash is looked up in the signature cache. If it is in there, then the signature is known to be valid and actual signature verification can be skipped.
The signature cache itself is not just a set. It is actually a Cuckoo cache which is a type of hash table that guarantees constant time lookup in the worst case.


text:
When the UTXO in the cache is full, what strategy is used to replace one UTXO with another in the cache?
The UTXO set is stored on the disk, but some UTXOs are also stored in the cache. When validating a transaction, you need to query the UTXO pointed to by the input of the transaction. First, you go to the cache to find it, if it's not found, you need to go to the disk to find the UTXO. Due to the characteristics of levelDB, the UTXO searched on the disk needs to be written into the cache. If the cache is full at this time, how does the node make room in the cache for the UTXO just found?

The UTXO set cache is not a fixed size and the limit isn't a hard limit. New entries can be added to the cache without regards for the maximum cache size. In fact, the cache object itself doesn't even know what the limit is.
Rather what happens is that the cache is flushed periodically. Because the UTXO set only changes during block validation (mempool UTXO set is handled separately elsewhere), this periodic flushing is primarily tied to incoming blocks rather than a timer. After each block is validated, the node determines whether it should flush the cache to disk. There are several conditions that would cause a flush, including being close to the cache limit, and being over the cache limit.
So if during the validation for a block, the cache became full, it would actually just keep growing until the block is fully validated. Then at the end, the entire cache would be flushed to disk and the cache emptied.
Note that LevelDB itself has a cache that is independent of the UTXO set cache.

Thanks, I get it. But I have another question.Does the node flush the entire cache to disk every time? Or the node can flush part of the cache to the disk? Can the node decide the flushing stradegy?

Maybe what I said above is not very clear. I mean, the node flushes the entire cache to the disk every time, or only flushes the UTXOs which is spent in the just validated block?

The entire cache is flushed, but there is some optimization to avoid writing unnecessary items to disk. For example, if a UTXO was created and spent in between flushes, that UTXO is never written to disk.

What’s the mempool UTXO set and when validating a new transaction,which cache  does the node query?


text:
Paper wallet safety
I'm using the mobile "trust wallet" app, and my plan is (was?) to write down the mnemonic key and keep it in a safe place, then delete the app.
Then whenever I need to receive or send money to a petty cash address, take my paper mnemonic from my safe place and import it on trust wallet.
Now, from what I saw online (source: https://www.youtube.com/watch?v=A5I55aOgX2o at around 4:00) it appears that keeping the private key in paper is dangerous because of the way bitcoin works with change and other technicalities, I could lose my btc (even without losing the paper wallet), and I can't really understand why... Can anyone please help me shed some light here?

There is a difference between a traditional paperwallet and a BIP32/39 based mnemonic and seed system.
Traditionally, a paper wallet would be for a single address, with a single private key. When importing this into another wallet, a possible concern was that the change from any transaction would not be returned to that single address, but instead be sent to another address belonging solely to that online wallet.
This is easily solved by using a wallet such as electrum, which ensures that change is sent back to the single address, since any wallet you create will have just that one address in it.
If you import that address into a preexisting wallet, then you need to build a transaction that returns the change to that address.
With BIP32/39, the seed is imported as a whole - this results in adding not just one address, but the entire address chain. As a result, any change will return either to the sending address, or to another address controlled by your mnemonic. This is considerably safer, and better for privacy.
Naturally, this also means that if your mnemonic is compromised, all of your addresses are compromised.


text:
LND funding transaction stuck in mempool due to low fees
I have a funding transaction stuck in mempool due to low fees. Searchng around I have find that there is "BumpFee" wallet option to push your transaction. i have tried in this way:
~$ lncli wallet bumpfee [Channel_point] --sat_per_byte 150
>[lncli] rpc error: code = Unknown desc = the passed output doesn't belong to the wallet
When type:
~ $ lncli pendingchannels
i can see the transaction waiting for confirmation, but when type:
~$ lncli wallet pendingsweeps

{
                "pending_sweeps": []
    }

there arent.
The transaction is still present when type:
~ $ lncli listchaintxns
Someone can  try to explain or have had similar behaviour?
Don’t found so much useful stuff in Github
https://github.com/lightningnetwork/lnd/blob/master/lnrpc/walletrpc/walletkit.proto

I solved the problem whit CPFP (children pay for parent).
I used the  unconfirmed change of the fund TX stuck in mempool to open a new channel.
At the time of broadcasting TX the median fee is around 150sat/vb, so i chose to slight increase at 200 sat to ensure good probability to push the first fund tx and the second one in the next block avaible.

Can you please give me the command using the fund TX stuck in mempool to open a new channel?
When I do a new 'lncli openchannel' I cannot specify the fund TX stuck in mempool. I tried it with the same Public Key and the same local-amt but instead a new channel was opened to this Node. The old unconfirmed transaction still stuck on the mempool. Again: Can you please post how the command TX stuck in mempool to open a new channel looks like? Thanks in advance

I got a sweep TX (from a force closed channel) stuck, also due to low fees. This answer is inspired by OPs answer.
I got it working with:
lncli openchannel \
--sat_per_byte=${fees per byte for the funding transaction of the new channel} \
--min_confs=0 \
${remote nodes id} \
${local amount}

The --min_confs=0 part is the important bit, it allows lnd to use unconfirmed TXes for the funding, but that doesn't mean it will use that particular unconfirmed TX.

bos seems to have an option for specifying UTXOs with their bos fund --utxo ${utxo} command. (haven't tested that)
bos fund can be used with other commands for example bos open to open (multiple) channels as described here.


text:
How can you trust Bitcoin nodes?
If you send send a transaction request to a node, what is to to ensure that node doesn't simply log your private key and do nothing?
What is to stop the entry node from taking a transaction intended to transfer 1 bitcoin, and transfer 100 instead? Or to stop the node from changing the receiver of the transaction to someone else?
Lastly, what is to stop a node from sending a completely made up blockchain?
Do you just have to choose a trustworthy node?

Bitcoin is meant to be a decentralized network not requiring trust to make/receive transactions. Transactions contain signatures to prove that they haven't been tampered with. Signature is not just the private key, it is something that is derived by the private key and some other parameters. This is called ECDSA, Elliptic Curve Digital Signature Algorithm. If the crypto implementation is proper, it's impossible to extract the private key from signatures.
Changing the blockchain is a different topic. Each block contains "Proof Of Work", which means its hash (a value to check a block's authenticity, but no private key) would change if any part of the block is altered. This'd invalidate the block, and miners would have to re-mine that block (change little things until the hash is lower than a value, the target) But if you create a fake chain with lower targets for blocks, then your chain would have have less Proof Of Work accumulated and other nodes would switch to the chain with the largest PoW once they're aware of it. (But in practice there are checkpoint blocks, so the initial target for remining a chain is high)

Ah! I understand now that the private key is never sent.
However, I still am confused on how you know a node doesn't just return a false blockchain. Yes, other nodes wouldn't accept that as a valid blockchain (as there is less POW), but wouldn't the requester still get a fake blockchain and not know it?
How does bitcoin prevent this? Do wallets or apps used to trade bitcoin simply choose a trusted node to connect to?

I think I've answered my previous comment question... Wallets don't just connect to nodes, they start their own "lightweight" nodes, and connect to other nodes to find the most valid chain (longest). Then they use that blockchain! Is that correct?

Nodes and wallets are given checkpoints like "Don't accept the blockchain unless the block 5000 has hash A, 2000 has hash B, 500 has hash C". And yes, if they find a longer chain then they'll erase their chain and switch! But I don't think they find the longest chain before downloading it, because any node can lie at the beginning.


text:
Problem connecting on Slush's pool with GUIMiner, i tried many Host adress to connect, every time it says the target computer expressly reject it
I'm on Windows 10 with GUIminer, i want to mine on the slush's pool but every time i enter every host adress i saw it didn't work on slush pool.
I entered the right login for my miner and on GUIminer it says that the target computer expressly refused it, i have Bitcoin core too and i didn't finish to download it, Bitcoin core and GUIminer are on my external drive, can this make some trouble?
the full message was "errno 10061: no connection could be established because the target computer expressly refused it"
and my second problem is need more than 1 value to unpack"

ah i forgot something i used the adress 'stratum+tcp://eu.stratum.slushpool.com:3333' so i think i need to used the general adress and my software bitcoin core has not finish the synchronisation so can this be a part of the problem?

Can you give us the full error message you get ?

Now, its "need more than 1 value to unpack"

i'm searching for the error but the error was "errno 10061" something like that.

yes i found it the error was "no connection could be established because the target computer expressly refused it" and i entered all of the current host adress and it didn't work.


text:
How to build Bitcoin Core Linux tarball from sources
I'm trying to build the same tarball you can download from the website, containing the following filetree:
$ ls -R ../../bitcoin-0.15.0/
../../bitcoin-0.15.0/:
bin  include  lib  share

../../bitcoin-0.15.0/bin:
bitcoin-cli  bitcoind  bitcoin-qt  bitcoin-tx  test_bitcoin

../../bitcoin-0.15.0/include:
bitcoinconsensus.h

../../bitcoin-0.15.0/lib:
libbitcoinconsensus.so  libbitcoinconsensus.so.0  libbitcoinconsensus.so.0.0.0

../../bitcoin-0.15.0/share:
man

../../bitcoin-0.15.0/share/man:
man1

../../bitcoin-0.15.0/share/man/man1:
bitcoin-cli.1  bitcoind.1  bitcoin-qt.1  bitcoin-tx.1

I'm using the 'prefix' configure to put the binaries into a specific folder
./configure --prefix=/home/ff/bitcoin-build

Now, the content I get inside the target directory is almost the same (there are some files more). However,when I try to copy and run it inside a container it gives me an error (which is not the case with the original tarball).
So, my question is: how do I build the sources in order to produce the same tarball you get from the website?

The compiled binaries on the website are built using gitian. This is deterministic so you'll get an identical build to everyone else who has built it, for verification purposes. You can find instructions on how to do this here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md

For the sake of completeness, I add this link, which is also very important:
https://github.com/bitcoin-core/docs/blob/master/gitian-building.md

Since I had some troubles in actually completing the building process, I wrote a small guide as a reference:
https://gist.github.com/frz-dev/3e3e906fa06294e61930e81b473e1e5b


text:
Is who is richer game possible with bitcoin script?
With Bitcoin script, is it possible to construct a timelocked address X in such a way that:

Players A and B (maybe more players) can send bitcoin to this address;
When the timelock expires,the player that had sent more bitcoin to address X can withdraw all bitcoin to himself;
If deposits where equal, then whoever is first - withdraws;
?

There's a few misunderstandings in your question. You don't construct timelocked addresses, you can construct time-locked transaction outputs. Each payment a player makes to an address results in a different transaction output - so each would need a timelock. There is no way to cross reference information from different transaction outputs in bitcoin script, nor can the script have access to the amount.

Thanks for clarification!

I guess this: https://bitcoin.stackexchange.com/questions/23780/is-there-any-way-to-send-an-output-to-a-script-which-can-then-only-be-sent-to-on?rq=1 answers my question as well.


text:
what is meant by DEFAULT_ANCESTOR_LIMIT in child pay for parent?
Why is 25 the max parents a child can rescue in a child pay for parent?
I don't think I understand what DEFAULT_ANCESTOR_LIMIT = 25 means.
Does that also mean that the child transaction has 25 input utxos from those parents?

Bitcoin Core by default does not forward a transaction to its peers, when the full tree of its ancestor transactions contains more than 25 unconfirmed transactions or 101 kvB of unconfirmed transaction data. This limit helps curb spam attacks using long chains of unconfirmed transactions.
Example1:
If you have no unconfirmed transactions associated with your wallet, and then send a single transaction, you may spend the unconfirmed change output of the first transaction in a second transaction. This second transaction would now have one ancestor transaction for the purpose of the above described metric.
Example2: Alice sends funds to you and Bob, but Alice's transaction itself spends outputs from two other unconfirmed transactions. If you use the transaction output sent to you by Alice, you will have an ancestor count of 3. If Bob then also spends his output in yet another transaction, his ancestor count is also 3. Your transaction is not part of Bob transaction's ancestry.
Unless you create a lot of transactions in rapid succession or always pay minimum fees even when there is a large queue of transactions waiting to be confirmed, you will not usually get to 25 ancestor transactions.


text:
Replace-by-fee issue
Ok so i recieved a 50$ transaction and it was on my account ( the bottom transaction) and 2 days later i have 0 $ on account and all funds from that transaction apparently got replaced by fee, am i gonna get it back eventually or , what does this mean,  i tried googling it but language barrier is kinda messing up things for me

'Replace By Fee' (RBF) is a method of increasing the fee rate for a yet-unconfirmed transaction. As a user, if you send a transaction and then realize the fee-rate was set to low, you can utilize RBF to create a replacement transaction which includes a larger fee, in the hopes of quicker confirmation.
In this case, it looks like there was an RBF-enabled transaction that paid those funds to the 18dC... address mentioned in your screenshot. This transaction would otherwise be a normal bitcoin transaction, that just has the 'RBF flag' enabled so that it can be replaced if the user so desires.
If you did not create this transaction, then you should consider the fact that the machine your bitcoin wallet is running on is infected with some sort of malware. Without more info, its not really possible to say for certain what happened here though.


text:
Someone made a small, apparently fraudulent, transaction to my public address. What is the purpose behind it?
I have a small e-commerce site and someone made three cryptocurrency purchases just seemingly to know my public addresses as she never paid the cost of goods. The three addresses she viewed are public derived from the master public key so there shouldn't be any security problems there afaik.
She seemingly wanted to know my BTC, ETH and LTC addresses but only made a small transaction of $1.89 in BTC. I got 0.2¢ and other address got the rest. Here's the blockchain transaction data.
By the multiple transactions from this address and others related to it, it looks like if someone is trying to move a large quantity of BTC through multiple addresses to make it difficult to track. But why using public addresses from e-commerce sites like mine? Shouldn't be the same creating multiple new addresses? Maybe you can extract more meaning from this transaction and the intention behind it.
For additional info, the IP from where she made the purchases at my site is 68.65.122.134

She might be expecting you to make a transaction consolidation all of those coins you received. Since the inputs of a transaction are almost always the coins (in jargon "unspent outputs") of the same person, she could then find the transaction which spent those 0.2 cents, add up all the inputs, which would be the amount you earned in the last N days.

So, if I understood right, she's trying to know my income in crypto to see if it's worth the effort to hack my website? Is there a way to avoid this security issue? For example, using a crypto payment platform as a middleman?

Yes, then they would also be able to see your customers' balances. Yes, a crypto-accepting payment processor such as BitPay would solve those privacy issues.

Thanks @MCCCS can you provide a link to an article that explain this more in depth? I don't understand how can they see all our balances just with a small transaction to one of my public addresses because my wallet may or may not incorporate those coins to a transaction and it's hard to tell from the blockchain what addresses are part of my wallet, what outputs are change or which are intended for the recipient. Also I've searched BitPay for articles on how they would solve this privacy issue in detail. By your same reasoning anyone could know my wallet from the BitPay address when they pay me

https://en.bitcoin.it/wiki/Privacy#Common-input-ownership_heuristic You wallet may include some of the coins enough to account for the total output, but it might also merge all of the coins in the transaction. Here's an example of a transaction shown on a block explorer that shows possible privacy issues: https://blockstream.info/tx/44ca53186c56827d3ea9e1e2bbbc2e8ce0757729b4fbff7ee024402d6431649e As you might guess the output with less decimal digits is for the recipient (0.23) while the ugly number is the change 0.00137737.

BitPay has lots of circulating coins, they'll receive your coins to their accounts and increase your balance number. When you want to receive your coins they'll send that balance number of random coins from their pool coins.


text:
Is there any better alternative to limit or stop order in crypto exchanges?
I have somewhat understood both limit and stop orders at some exchanges, even executed some similar order types but I am still looking a way to execute an order based on target volume of a coin (say to buy)...for eg.
Okay i will try to make things simple with an existing eg. of binance plus BTC and MKR (both volatile).Suppose,
I wish to buy 23 MKR for 1 BTC (that's 100% of available BTC in my account) & current market order price allows me 1 BTC = 21 MKR hence I create Limit order to buy MKR in binanace (BTC/MKR market) such that I select the BTC price in a way (with 100% available BTC selected) that it shows quantity at 23.
Now, is this limit order executed according to the BTC/MKR price ratio OR specifically when BTC goes up and MKR goes down/stays same or vice-versa?
I guess binance limit-order is only concerned with MKR value going down such that order is executed and 1 BTC results in 23 MKR i.e wait for MKR going down not BTC going up?
I believe that the order should not be concerned which one goes down/up....simply want to see 23 MKR in my binance wallet. Is this sort of autoinvest?
I am not able to understand this specifically as my target is to make 23 MKR??Stop-limit order has no role in this I guess?

When you create a limit order to e.g buy 23 MKR with 1 BTC, this is registered in ledger and will stay there until filled or cancelled. To fill the order a matching order will need to exist in the system, so someone actually needs to sell at that price or cheaper.
Stop-limit order will not be registered in ledger until price reaches some point (STOP price). When you create the order you specify both the price MKR needs to reach and price for your order (LIMIT price).
So if you set the stop price to 1/23 (0.04347) and limit price to 1/22 (0.04545), when the price reaches 0.04347 a purchase order to buy at 0.04545 will be registered in ledger.

With your answer I deduce that 1) Limit order executes only when some other party is interested or have filled an order at that price or less (& chances of filling are high if the market also shifts to that level) and 2) Stop-limit order only increases this probability by executing limit order when prices are favorable for any party to grab the deal because market has shifted to that possible level. Can u please specify advantage of stop-limit order over limit order or I have already stated it.

For both type of orders there is no guarantee your order will be filled if price changes very rapidly.Stop-limit order still has better chances to execute, this is main advantage in my opinion.

For what I feel, stop-limit order is more sort of beneficial (less loss) for those who wish to get profited from daily trading...by investing and strategically moving from 1 coin to other in order to create net profit.


text:
bitcoind sync is utilising very little CPU and bandwidth and is very slow
Is there a way to increase the sync speed. It's running in single thread on raspberrypi connected with USB HDD.
top
top - 13:58:12 up 32 min,  2 users,  load average: 2.64, 1.74, 0.80
Tasks: 138 total,   1 running, 137 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10.1 us,  2.6 sy,  0.0 ni, 56.3 id, 30.9 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem :   947732 total,   101584 free,   239716 used,   606432 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   623092 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1594 necktwi   20   0  345160 198200   7864 S  50.8 20.9   1:33.10 bitcoind

nethogs
NetHogs version 0.8.1

    PID USER     PROGRAM                    DEV        SENT      RECEIVED
   1594 necktwi  bitcoind                   enxb82     0.234       1.388 KB/sec

actually, I have a bandwidth of 6MBps.

Make sure you are connected to enough peers (maybe >4)
Make sure you use either the default -par config value or you set it according to your available CPU cores (usually num of cores +1)
Make sure, you have fast disk access (ideally SSD). If disk access is slow (don't use NFS, NAS, etc.), it could tear down the verification process (leaving your CPU partially unused)
Try to change the default database cache size. A -dbcache of 4GB can really significant speedup the sync, though don't over-allocate if your system has not plenty of RAM to waste.

running bitcoind on a raspi is possible, but very slow (I have done that too, and search here in the forum, there are users who reported the experience). Calculate minimum 2 weeks until the whole blockchain is loaded, even more with a USB HDD.
For once each tx included in a block must be verified, that takes time - and you can see your process CPU usage is 50%. At the beginning blocks are small, then it is really fast, but then, over the last years blocks got full, and it takes time.
And also you have a USB HDD - bitcoind has to lookup data of already loaded blocks, so the speed of your disk connectivity defines the process duration. Have a look at your block I/O, that is probably the most limiting factor.
Maybe a fast SD Adapter card (>50MBytes/sec) and pruning is the better option. Still the initial load would take the CPU time...


text:
Have any books has been written about Ripple and Litecoin?
I buy some ebooks about cryptocurrency, bitcoin and blockchain from
http://sacredtraders.com/index.php/product-category/crypto-book
Have there been any books written about Ripple and Litecoin?

I found a few books on Amazon that may interest you.

Ripple Book

Generic book explaining Ripple

Litecoin

These books can be very generic.
For understanding the technology, I would recommend that you read the white-paper (yellow-paper if super interested).

Whitepaper-Ripple

Solutions using Ripple

Ripple whitepaper explained

Video Resources

Ripple consensus algorithm explained

Litecoin explained by its founder

P.S. As of writing this answer, there's no official whitepaper for Litecoin, as it is a fork of Bitcoin and uses similar underlying technology with the claims of being faster than its predecessor.

I have gone through some of them mentioned above and found it to be really helpful

I'm unaware of any books about Ripple.  However, you can purchase an introductory e-book for new cryptoinvestors on Litecoin from the Litecoin Foundation.
https://litecoin-foundation.org/product/understanding-litecoin-the-digital-currency-for-payments/


text:
What do these memory configurations in debug.log of BitCoin Core represent?
In the debug.log file of BitCoin Core, the cache configuration is described as follows.
Cache configuration:
  Using 2.0 MiB for block index database
  Using 8.0 MiB for chain state database
  Using 441.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)

What is the 8MB cache space allocated for chainstate database here used for? What is the difference and connection between it and the in-memory UTXO set?

The block index and chain state databases are LevelDB databases. LevelDB has its own caching and cache management. So 2 MiB is being allocated for the block index's LevelDB database cache, and 8 MiB is being allocated for the chain state's LevelDB database cache.
However Bitcoin Core does additional caching by itself, particularly for the UTXO set, which is stored in the chain state database. So Bitcoin Core is also allocating 441 MiB for itself to manage a cache of UTXO set entries.
The difference is that LevelDB will organize its cache differently from Bitcoin Core's in-memory UTXO set because LevelDB is a database system. So it is optimized for data handling and has a strategy that is generalized to all kinds of database uses. However Bitcoin Core knows what data it is putting into the database and so it can cache that more effectively. It caches the data before it needs to be serialized and written to the database. Because Bitcoin Core knows how the data will be used, it's caching through the in-memory UTXO set can be optimized for the actual use cases.

Thank you. Your answer is very helpful. So my understanding of the purpose of these caches is as follows (if I am wrong, please correct me):
When a node validates a transaction, for the UTXO used in the block, the node first performs a query in the 441MiB in-memory UTXO set. If it is not found, it needs to access the levelDB database in the disk. However, since levelDB also has an 8MiB cache, the node needs to query this 8MiB cache first. If it is still not found, go to the disk to search, and write the search result into the 8MiB cache instead of the 441MiB in-memory UTXO set.  Is it right？

@GoneV That's correct.


text:
Does Bitcoin Core have/need an archive mode?
Similar to Ethereum's Archive Node:

Stores everything kept in the full node and builds an archive of historical states. Needed if you want to query something like an account balance at block #4,000,000.

Or is it not needed because Full Node is an Archive Node due to Bitcoin's UTXO model?

The language used in the Ethereum ecosystem doesn't always entirely align with the language used in the Bitcoin ecosystem.
All full nodes in the Bitcoin ecosystem verify all transactions and blocks from genesis. This is generally not the case in the Ethereum ecosystem as this exercise is much slower and requires significantly more disk operations (i.e. see Jameson Lopp commentary).
Full nodes in the Bitcoin ecosystem can either be pruned or archival. Pruned full nodes don't store data on spent transaction outputs in perpetuity while archival full nodes do. If you want to do something like query the effective balance of a Bitcoin address at block 4,000,000 you would need an archival full node. You would also need software like Electrum Personal Server (EPS) or alternatives that index historical UTXOs by address.
For more details on the different types of full nodes in the Bitcoin ecosystem see this presentation from John Light at London Bitcoin Devs in July 2018.

Thanks for this @Prayank. scantxoutset scans the current ie most up to date UTXO set right? You can't use it to scan a historical UTXO set say in January 2015, to see what the effective balance of an address was in January 2015?

Cool, so I think my answer is correct for querying historical balances. Though the example given in the question, block 4,000,000 is actually decades in the future ;)


text:
How does randomness works in mnemonic phrase generation?
As far as I know, randomness in computers are not truly random, but rather pseudorandom, mostly derived from current timestamp. So when creating various wallets, I have saw a lot of them introduced some kind of user-generated randomness (like just moving the mouse) and then deriving the wallet and mnemonic phrase out of it, but some does not.
For example, TrustWallet or many others, you just install the app, it creates the wallet for you and you just write down the words.
Is not it possible, but highly unlikely, that two different people create the same address in the same time with the same wallet creator tool?
Or what if I set the timestamp to some certain precise number, would I be generating the same wallet like someone before me?

Most computers these days actually do have true random number generators (e.g. the rdrand instruction on modern Intel CPUs).

That depends on the specific wallet’s implementation. Typically wallets will mix multiple sources of entropy to generate a random seed (user input, system time, /dev/urandom etc). Also most operating systems will provide a source of cryptographically secure randomness that is very hard, if not impossible, to replicate.


text:
What languages can I write plugins for c-lightning in?
I know that there's a Python library available for writing plugins for c-lightning. What would I need to do to for example use a JVM language like Scala?

Plugins can be written in any language as long as a client library for that language exists.
The command line API and the Plugins communicate with lightningd over a unix domain socket using JSON RPC 2.0.
As far as I know no Java / Scala lib exists. I have started creating one at this pull request: https://github.com/ElementsProject/lightning/pull/2223
also it makes sense to look at the python plugin lib to see how the format of the JSON RPC 2.0 is used. Check out: https://github.com/ElementsProject/lightning/blob/master/contrib/pylightning/lightning/plugin.py which is really just a client lib talking to the UNIX Domain socket and parsing / dispatching the JSON RPC responses. So as soon as you create this in Java / Scala you should be able to create as many plugins as you wish. You could build upon my pull request (though I have started with the client library for the standard API)


text:
listchannels returns no results from CLN
CLN 0.12.1
My node has been running for hours now. But it doesn't seem to be aware of the network. This is what I get when I try to run listchannels.
$ lightning-cli listchannels
{
   "channels": []
}

What would cause this? And what can I do about it?

Do you have a connection to a peer in the network? Nodes gossip about the state of the network to learn about channels and nodes, but if you don't have a connection you won't get gossip.

https://lightning.readthedocs.io/lightning-listpeers.7.html

listpeers returns no results either. Would I use the connect command to make a connection without actually opening a channel? And if so, how would I find a peer?

@Zephyrus: I think the general advice would be to connect to a peer controlled by an individual/company that you know. But if you don't know anyone 1ml.com and amboss.space list Lightning nodes.

https://lightning.readthedocs.io/lightning-connect.7.html

As cdecker points out in the comments, I think you are running a node where you do not have any connection with an external peer.
In fact core lightning is preservative, and it does not start to gossip information about yourself if you do not have any information to share.
Moreover, you can choose also to use the core lightning with only private channels so in this case, the network must not know your information!
So, I guess you want to use cln to make some analysis on the network? if yes you need to configure your cln and start to connect with some public peer.