You cannot just query for all transactions with some given parameter, bitcoind does not work like that. Bitcoind is not a block explorer and is not meant to be one. What you can do is request for specific blocks (and transactions if you have enabled the transaction index). So you can get the blocks around the timepan that you want and get the transactions from there to analyze.

Can you print out the values for amo and txfee too?

No, it will not be fixed because 0.16 has the same error messages guarded by the same conditions.

If you have an http packet inspection tool, you can intercept the packets being sent to your node and see what the actual JSON for the command is being sent. That will give you more information too about the error as you can see what was actually sent by your code.

Miners generally only select new transactions after a set of nonces and extranonces has been exhausted. However it depends on the software being used. There is no set order nor is there a set algorithm for the order of things to try.

Every RPC error comes with an error code and a message. The message was "Invalid amount for send". As I said earlier, this only appears in 4 places and is guarded by only a check for negative or 0 values. This error can only be triggered by having a negative or 0 amount. This is still a type error, but type error can still mean many things. In this case, the type is "positive decimal" which is not what is being provided.

That's just another way to write the derivation path for 1'. Hardened derivation are indexes beginning at 2147483648, but for simplicity we use ' or h to indicate this.

That error code and string occur in only 4 places in the code, with each one protected by an if branch checking whether the amount given is <= 0. If you are getting this error, then your amount is being interpreted as being <= 0, regardless of what you intended it to be.

There are many Bitcoin media sites in non-english languages. There are also many forums in non-english languages. From previous events, we know that these things get reported on fairly quickly and the news spreads around fairly quickly. There isn't any need for the alert system.

The other reasons for removing the alert system were its centralization and insecurity. No one knew exactly who held the alert key. Anyone who did could send an alert and this poses a security risk. Furthermore, there was some talk previously about using the alert key for non-alert things and rather as a way for developers to force changes in a centralized manner. This is completely undesirable, and combined with the fact that we had no idea who had the alert key, it needed to be removed.

Sure, that's something that has been discussed. But there is no urgent need for one, and we believe that existing news and media are sufficient for getting information out to everyone.

Automatic updates (and updates in general) are inherently centralized. You need to get the binaries from a centralized distribution source.

That's not at all how mining works. It isn't just "follow the majority".

There is no way to detect reliably what version clients are running. It is easy to spoof the version you are using and it is impossible for a third party to verify that you are running that version. If an attacker compromises the distribution server, they can easily spin up fake nodes for their new compromised version and then people with the auto updater will then update to the compromised version. Any sort of auto updating feature has the same problem. Additionally, the Bitcoin Core developers do not want to force people to use specific versions; it is up to the node operators to update at their own convenience.

The address format is incorrect for testnet. Your addresses should start with m or n, not 1.

How did you determine that it did not receive the funds? Are you checking a testnet block explorer or are you expecting some sort of notification from the library that there was a transaction?

No, there is not.

Bitcoin Core automatically creates a new wallet file if one does not already exist.

There are multiple cryptographic hash functions used in different places in Bitcoin (and other cryptocurrencies) and in the Lightning Network. What that section is specifically talking about is the scripting language and that the scripting language must support the same hash functions. The hash functions in the scripting language are completely separate from the hash functions used in the PoW.

The Lightning Network operates solely on transactions and scripts which are independent of block related consensus rules, including the Proof of Work.

That error means that the signature is invalid. coinb.in has, for quite a while now, been known to have issues with their signer which results in invalid signatures.

Looking at the transaction, it is actually incomplete. It is completely missing the redeemScript.

The error has nothing to do with the wallet.

Error code -3 means that there was a type error. With the error message "invalid amount for send", the amount that was specified was less than or equal to 0. This means that your code probably has a bug in it where amo is too small.

No, the hash function for the PoW is irrelevant to the Lightning Network. It does not matter if they are the same or if they are different.

This topic has been moved to Trashcan.

Duplicate thread

No buffer overflow attacks were found. All known attacks were described in this post. With the C++ standard library, it's actually kind of hard to get a buffer overflow.

The alert key was owned by numerous people; the full list is actually unknown because it is impossible to know whether someone passed the alert key to someone else and simply did not say so. The alert key was created by Satoshi and passed to others, including gmaxwell, sipa, kanzure, wumpus, theymos, etc. Kanzure (Bryan Bishop) who co-authored this text, had the alert key and he was the one to disclose it.

Because we want to get rid of the alert system. It has already been removed from Bitcoin Core for several years. There are already sufficient media outlets and sites where people get their news about Bitcoin. If there is a network event in the future, people can easily get information about it from those places.

It is impossible to enforce that the timestamp be exactly a specific time due to network latency and the imprecision of clocks in computers. So the timestamp in a block just has to be within a range of times that goes from the median time of the last 11 blocks to a few hours ahead of current time. A miner can modify the timestamp as long as it fits within this range of time.

No. Transactions do not have timestamps and their times have no effect on the block's timestamp.

There are two forms of "compromised" for hash functions: a preimage attack and a collision attack. A preimage attack allows the attacker to determine the data that a given hash came from. Basically a preimage attack allows you to reverse a hash. This kind of attack is difficult, and AFAIK, no known preimage attack has been found for any hash function, even ones considered broken. If a preimage attack were found on SHA256, it may allow miners to simply mine blocks faster. Depending on how the attack works. this could mean that blocks are found at a constant time regardless of the difficulty. But such attacks are unlikely, and even if one existed, it may not even result in finding a valid block header since, technically, there are infinitely many pieces of data that hash to a given hash.

Collision attacks are a different story. Collision attacks are much easier to find and possibly more problematic than a preimage attack. All broken hash functions are broken because of collision attacks. A collision attack is where two pieces of data can be found that hash to the same thing. Although technically there exists infinitely many pieces of data that hash to the same thing, finding those pieces of data is incredibly hard and there are so many possible hashes that finding a collision through brute force would take a very very long time. However, a collision attack allows someone to find two colliding pieces of data in a practical time frame (e.g. several years). If someone were able to find another valid block which has a hash that matches one of another existing block (so a collision), then there would be a lot of problems since the hashes would match but the transaction history could be different.

It does actually work, and many people have made and received many payments. All of the software for the Lightning Network are still in beta and actively being worked on. What you are experiencing are just the issues that come with using prerelease software.

Wladimir has actually had a version of this code on his github gists for several years now: https://gist.github.com/laanwj/0e689cfa37b52bcbbb44

The process of mining uses hashing. It really isn't solving a problem or answering a question. It is just doing work. The data that is hashed is the block header. The block header is 80 bytes and contains multiple fields: a version number, the previous block hash, the merkle root (hash of all of the transactions in the block), a timestamp, a nonce, and a compact representation of the target value. A miner's goal is to modify this block header until they are able to find a hash that, when interpreted as a 256 bit integer, is less than some target value.

In order to do this, miners will modify as much data in the block header as possible. You can really imagine this process as simply constructing a block (complete with block header), computing the hash of the block header, and comparing it with the target. Then doing this over and over with different blocks (done by tweaking some values within the block itself) until one is found that has a block header hash that is less than the target.

Miners can change a lot of things in the block header in order to get different hashes. First and foremost is the nonce. The nonce is specifically designed to be changed in order to get different block headers. However the nonce is fairly small, only 4 billion possible values. Thus something else needs to be changed. Miners can then change the timestamp and the merkle root. Miners change the merkle root by including different transactions in their trial blocks. They can also permute the order of transactions. Miners can also change the data within the coinbase transaction such as adding extra data as a extraNonce.

The target value that miners compare their block hashes to is calculated from the original target value from the genesis block. The target value changes every 2016 blocks. So the target value can be known and calculated simply by looking at the blockchain and computing the targets for every 2016 blocks. Since the target uses the timestamp, all data necessary to compute the target is available to anyone who has the complete blockchain. It is important to note that the difficulty adjustment is actually the target adjustment. The difficulty is simply the inverse of the target and is not actually part of the blockchain or consensus rules. Only the target is.