Shares mostly rejected mining with an FPGA I am using an FPGA to mine bitcoins in a pool, as you can see below I am not really very successful:

[1 accepted, 48 failed, 148.90 +/- 21.27 Mhash/s]

It is running at 150 MhZ but I only have 1 accepted share out of 49.
I guess this quota does not look to healhty. Anyone an idea what could
be wrong?

Give me the make of the FPGA and the name of FPGA binary you are using.

It could well be that you are over-clocking the FPGA too far, due to the way that many of these cores are designed, there is a race condition, where the  "success" flag, gets out of sync with the "nonce".

Basically the FPGA flags the "hit", but by the time it gets to copying the "nonce", it has changed......
and so fails.


Why is still Fee not a 1 Satothi? How I feel this.

Every transaction, 1 address -> 1 address, take a 0.0000 0001 BTC.

Attacker try to flood network with transactions. Presuppose, he have 1 BTC. Flood could looks like 1M of addresses. 1 000 000 * Fee( 0.0000 0001 ) = 0.01 BTC. Attacker could make 100 attacks with 1M addresses, thereafter he out of money.

Will network of bitcoin overloaded ? What a math behind current Fee?

Transactions are very big. So one is very expensive.

Less transactions is better for the network.

Large transactions, with old coins, do not need to pay fee. They can not be spammed with.

Any miner can choose a minimum fee. The miner chooses the math.

The commonly accepted fee is just chosen by bitcoin developers. It was their choice, no special math involved. We try to have a manageable amount of transactions per block.


What is the status of the "Hong Kong Agreement" Are the bullet points below still valid?

We understand that SegWit continues to be developed actively as a soft-fork and is likely to proceed towards release over the next two months, as originally scheduled.
We will continue to work with the entire Bitcoin protocol development community to develop, in public, a safe hard-fork based on the improvements in SegWit. The Bitcoin Core contributors present at the Bitcoin Roundtable will have an implementation of such a hard-fork available as a recommendation to Bitcoin Core within three months after the release of SegWit.
This hard-fork is expected to include features which are currently being discussed within technical communities, including an increase in the non-witness data to be around 2 MB, with the total size no more than 4 MB, and will only be adopted with broad support across the entire Bitcoin community.
We will run a SegWit release in production by the time such a hard-fork is released in a version of Bitcoin Core.
We will only run Bitcoin Core-compatible consensus systems, eventually containing both SegWit and the hard-fork, in production, for the foreseeable future.
We are committed to scaling technologies which use block space more efficiently, such as Schnorr multisig.

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff#.8vbwu3ft7

The full code for Segregated Witness was released on 19th of April, which to the letter fulfills the requirement. However, apparently some people had understood the first point to mean that it would be in production in April which was not the case.

Following the above, an implementation for a hard-fork would be expected to be delivered by 19th of July.

IIRC, Bitmain's Jihan Wu has recently stated that point 4 is to be interpreted as them requiring the code for a blocksize increase hardfork to have been merged into Bitcoin Core before they run Segregated Witness in production. This is of course a much stronger requirement than point 2 and point 4 which could be read as them starting to use SegWit at the latest when code for a hardfork is released.

The argument has also been made that by allowing voting for Classic, some pools have breached point five. The disagreement here is chiefly about whether Classic constitutes an incompatible version. Until a Classic node activates, it follows the same rules, so proponents argue it is compatible. Yet, since Classic breaks with the current rules as soon as it activates, others declare it to be not "Bitcoin Core-compatible".

Altogether, it seems to me that there are still a lot of misunderstandings and conflicts of interest to be ironed out. Vastly diverging priorities and language barriers add to the difficulties. There also seem to be very different assumptions about where the community support lies and how the power dynamics in Bitcoin will work out.

As far as I can tell, we can only wait and see how the situation develops. The next step appears to be the imminent inclusion of Segregated Witness into the next Bitcoin Core release candidate. Once some miners start signaling readiness for Segregated Witness, the situation will probably evolve quickly.


Can I use my "chainstate" folder for anything? I've recently found an old folder called "chainstate" in my PC.
Can't remember why I saved it but inside it there's the following files:
"000003.log"
"CURRENT"
"LOCK"
"MANIFEST-000002"
Are these of any use at all? Could I access an old wallet using these? What does it mean?

The chainstate directory stores publicly available data, specifically unspent transaction outputs and some metadata at the time it was saved. It doesn't contain any private key material and so it can't be used to claim or send any funds.


Detect received transactions of thousands of Bitcoin addresses I'm implementing a Bitcoin payment system that generates bitcoin address for each user to deposit.
I use BitcoinJ to generate user's addresses and rawblock API from Blockchain.com to get every single block to check if my addresses are in any transaction output, then my system increases the user's internal balance.

I save scanned block height in the database and send a request for a new block every 10 minutes.

Is that solution correct? (I need testnet so I cannot use their Wallet Service)

Thank you.

This doesn't sound correct to me.

You're relying on a centralized service to fetch blocks.  What if their system has an error and sends you incorrect data?
What if their service is unreachable?
It doesn't seem like you have any way to handle blockchain reorganization.  You might end up crediting a payment twice, or crediting where a double spend was successful in a competing chain.

Consider looking into something like BTCpay which FOSS self-hosted bitcoin payment processor.


How can I get the private key from multibit? The support section of the MultiBit website shows a completely different UI as well as many options that the current version doesn't have.

How can I find my private key?

If you want to use the original version of MultiBit (called MultiBit Classic) then the installers are available on the https://multibit.org website.

Click on the 'Download' button at the top of the page and then look at the bottom of the 'Releases and signatures' section.

The new version of MultiBit (called MultiBit HD) uses a set of wallet words to deterministically generate private keys and addresses. You restore directly from the wallet words rather than exporting/ importing individual private keys.


How does bitcoin find the block locator hashes in the leveldb database? I am trying to understand how bitcoin core builds the list of block locator hashes needed for sendheaders and getheaders messages. I have looked on the wiki and I have seen that after the 10 most recent block hashes, it goes back exponentially until the genesis block.
So it seems that I have to get a block hash knowing its index in the blockchain. But how can bitcoin core find a block hash by its index? From my understanding leveldb lets you query data only by a key, and in this case the key is what I want.

The answer is that it doesn't use LevelDB for this.
It has an in-memory data structure with all known block headers, each pointing back to its parent. It also has a vector with pointers to all block headers in the currently active chain.
To build locator objects, it simply looks in this vector at specific indexes.


What is the secure, self-hosted wallet to redeem BTG (Bitcoin Gold)? Hacking and being hacked is not cool

I'm looking for a decent solution to redeem BTG.

Ideally self-hosted and open source.

I have 12 words seed phrase, BIP39, deterministic derivation path, etc...

Related: Claiming my BTG from my BTC private key

They suggest using offline version of https://www.bitaddress.org/ to extrac the private key and then https://medium.com/@coinomi/collecting-your-free-bitcoin-gold-btg-coins-da937d4255d1

Relevant / irrelevant detail: after the snapshot took place, I've sent some BTC to another address. I believe I should still own the corresponding amount of BTG.

For security reasons I'll first transfer my current BTC to a new SegWit address I'm holding, and only then start experimenting with BTG.

Related: BTG wallet or exchange with BIP39 seed import

Your recommendation with regards to BTG is greatly appreciated.

Research: https://play.google.com/store/apps/details?id=btg.org.freewallet.app

(surely it's not only me who has ponders this question)

Ideally self-hosted and open source.

State of the blockchain, crypto, whole ecosystem - early days - no ideal solutions - skilled developers are in extremely high demand and (to be honest) I didn't expect to find such tool.

With that said - first I moved actual BTC to another address.

Then - using the seed I was able to follow instructions here: https://coinsutra.com/claim-bitcoin-gold-btg/ (very good write up, THANKS)

In essence:

install Coinomi app (currently Android only)
restore wallet
put your phrase (don't tick BIP39)
add BTC (optionally, I first added BTC so that I could easily verify that balance is recognised)
add BTG - advanced - M/44H/0H/0H (important, defaults are not smart)
profit

I happened to keep BTC at blockchain.info (not anymore) so I had access to the 12 words seed - that was easy. There is a number of questions about claiming BTG from other type of the wallets - my first thought are leading towards bounty-smart-contract-fication - put some money in the pot and hire developers - so that whales can get their 5% dividend without risking much.

In my case - I enjoy playing, educating, experimenting. It was time well spent - I believe so.


Electrum paper wallet exploit I want to generate a paper wallet with Electrum using my personal computer that I've been using for a few years now, meaning that I'm online with it daily.
I know that the optimal solution is to use a computer that has never been connected to the internet, but I'm curious if there are any reports of malware compromising this kind of setup.
(I'm considering this setup because where I'm from it is not so easy/fast to get a hardware wallet)

Go offline
Generate seed words
Copy them to paper
Delete wallet from computer

It's more safe to do it on "clean" operating system.
I can propose another solution:

Prepare DVD or USB stick with Ubuntu operating system
Start live session of Ubuntu from DVD or USB stick on your computer
Download Electrum AppImage from official Electrum website
Run Electrum, generate seed
Switch off computer, all data will be lost


Fastest cryptocurrency What cryptocurrency is the fastest in terms of reaching 100% transaction confirmation?

I've found sites like this that show that Fastcoin is the fastest at 48 seconds.

I think David Schwartz said that Ripple gets 100% confirmation in ~10 seconds.

Is Ripple the fastest, or is there another coin that is left out of calculations because of bias like that attributed to Ripple?

In this world of high frequency trading, is 10 seconds the best that can be done right now?

I know people tend to get obsessed about the confirmation time, but the important factors are the number of nodes and the speed at which any given transaction is seen by the network as a whole.

I believe this is under three seconds for a transaction to be seen by the entire bitcoin network.

Why is this measure important? Because this is the so-called "window of opportunity" for a double-spend. In fact as soon as the transaction hits the network, the race is on, so we are actually talking about milliseconds.

Satoshi provided an answer to this somewhere (I can't find it right now) which explains what the real issue is.

A large number of nodes means that any double spend attack, has to work harder to get the transaction seen first, and hence included in a block first. But again this is totally arbitrary because nobody can predict the winner of the block (who gets to choose which transactions to include).

So this "fastest confirmation" metric is a red herring.


In bitcoin-cli getpeerinf call what does "-1" mean as a "synced_headers" or "synced_blocks" value? Sometimes I see this in getpeerinfo:
"synced_headers": -1,
"synced_blocks": -1,
sometimes it's only synced blocks at -1.
What does that mean?

It means you either have no headers, no block, or both known to be (*) in common with this peer.
From the help:
$ bitcoin-cli help getpeerinfo
....
    "synced_headers" : n,          (numeric) The last header we have in common with this peer
    "synced_blocks" : n,           (numeric) The last block we have in common with this peer

(*) As Pieter cleared in the comment it doesn't mean you aren't on the same chain, just that the peer didn't announce any block to you yet.


bad-txns-nonstandard-inputs error after sendrawtransaction I smashed my head over the table trying to send raw transaction and every time get the same error bad-txns-nonstandard-inputs.

So, here is what I do:

Get unspent transactions

bitcoin-cli listunspent
[
  {
    "txid": "txid_number_1",
    "vout": 1,
    "address": "address_1",
    "redeemScript": "redeemScript_1",
    "scriptPubKey": "scriptPubKey_1",
    "amount": 0.00024972,
    "confirmations": 31,
    "spendable": true,
    "solvable": true,
    "safe": true
  }
]

Create raw transaction with tx_id and vout taken above

bitcoin-cli createrawtransaction '[{"txid":"txid_number_1","vout":1}]' '{"address_to_sent":0.00002000}'

tx_id_as_hexstring =

02000000016affa8a874987f66be3ab4791b57042cbf0912088352ba0e3931b7b8b8f374c80100000000ffffffff01d0070000000000001976a9147c99343bb9cba8699e7f7b4f5552357e477dc76188ac00000000

Sign raw transaction

bitcoin-cli signrawtransaction tx_id_as_hexstring

Send raw transaction

bitcoin-cli sendrawtransaction tx_id_as_hexstring

error code: -26
error message:
64: bad-txns-nonstandard-inputs

I tried to create same transaction with coinb.in, but result is the same.

What am I doing wrong?

Also

bitcoin-cli decoderawtransaction tx_id_as_hexstring

returns

{
  "txid": "txid_number_2",
  "hash": "txid_number_2",
  "version": 2,
  "size": 85,
  "vsize": 85,
  "locktime": 0,
  "vin": [
    {
      "txid": "txid_number_3",
      "vout": 1,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00002000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 7c99343bb9cba8699e7f7b4f5552357e477dc761 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9147c99343bb9cba8699e7f7b4f5552357e477dc76188ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "address_to_sent"
        ]
      }
    }
  ]
}

Your transaction is not being signed.

First of all, the hex string that createrawtransaction gives you is not the txid, it is the transaction itself. That transaction is not stored in your wallet.

When you pass it to signrawtransaction, the raw transaction will be signed and returned to you (it will be the thing under the hex field in the returned object. Again, this transaction is not stored in your wallet. That signed transaction is what you pass to sendrawtransaction, not the thing that createrawtransaction gives you.


Why can I observe three different network difficulties in a span of a few days? https://www.blockchain.com/charts/difficulty

If I study the difficulty changes the last 6 months, I can see, as would be expected, that roughly every two weeks, the network makes an appropriate  adjustment. However, I would expect this change to happen in a single block, whereupon the target attribute jumps from one value to another. However, upon closely inspecting the graph on blockchain.com, there seems to be a few intermediate difficulties within the steep slopes on the graph. For example, I can observe these three difficulties in a three day span:

13th of April: 3,511,060,552,899
14th of April: 3,796,188,328,005
15th of April: 3,893,316,899,029

How can this be explained? Were there two subsequent difficulty adjustments within two days? Or does the difficulty adjustment work slightly different than I imagine?

The information you are looking at is incorrect and seems to be the result of interpolation of the graph, there was no difficulty changes that resemble that in the Bitcoin block chain. Difficulty changes are every 2016 blocks, which is approximately 2 weeks if there is no difficulty change within the period.


What happens in detail, when Bitcoin Core verifies a block during synchronization? Since version 0.10.x, block headers are acquired separately, and therefore download is not delayed until previous blocks have been verified.

Previous questions about synchronization mention that the verification takes the most time: How does Bitcoin Core verify each block? I assume it checks each transaction's script, the merkle tree, and finally the blockhash, but how does that go in detail?

Paraphrasing from the Protocol description on the Bitcoin-Wiki:

The following checks are performed on the block:

syntax for correctness
is not a duplicate
has at least one transaction
hash satisfies difficulty statement (nBits)
timestamp is not more than two hours in the future
first transaction is a Coinbase transaction, no other transactions are.
Transactions adhere rules

has inputs and outputs
tx is smaller than MAX_BLOCK_SIZE
each output and the total are between 0 and 21,000,000 bitcoin.

Coinbase's scriptSig length must be 2-100
Reject if sum of transaction sig opcounts > MAX_BLOCK_SIGOPS
Verify Merkle hash of the transactions
Check if previous block is in main chain
difficulty statement (nBits) matches difficulty rules
timestamp is not older than median of 11 previous blocks


Is there a secret number that is only known by the sender and the receiver after making a transaction? After making a transaction and receiving all the hashes and ids, is there a number that is secret and only the two people involved in the transaction know?

Yes. You can view a transaction as being a public link between a number of public keys. If different people have the secret keys for those public keys then they have all the necessary information to calculate shared Diffie-Helman elliptic curve points. So in the simple case that you transfer all the bitcoins in an address to someone else's address then you can use his address and your private key to calculate a point which will be the same as the point calculated by him using his private key and your address. Nobody else can calculate these points.


Given that you have the necessary computing power, how does a tampered blockchain get accepted by the network? I read that you can only tamper with a blockchain if you have more than 50% of the computing power in the network. So say you have 51% of the computing power, then you can create a longer blockchain than the legit one. But how does this one get accepted by the network? I mean, the blockchain gets extended when people broadcast the transfers they want to make. Say the 51% wants to change something 10 blocks earlier. Does he change the copy independently of the network until it's longer than the network's copy? And how does he present it to the network then? Doesn't the network see that since a certain block, all the following blocks are suddenly different from those of the previously ongoing blockchain, which the entire network considered legit?

I know the longest chain gets accepted as the legit one because it's (almost) impossible to have more than half of the computing power but can't they add some security that takes it into account if, like, all but one node have a shorter blockchain, this is probably the legit one?

My apologies if this is considered a very basic question. Just trying to understand the main concepts and can't really find a straightforward answer to this.

It does not matter how a miner broadcasts his blocks if he is performing a 51% attack. The blocks can be kept privately and broadcast later, or they can be broadcast as they are being mined. Either way, once his branch of the blockchain has more work (aka "longer") than the current blockchain, when that most recent block is broadcast, all other nodes on the network will switch to that blockchain.

Keep in mind that "the network" is not one entity that thinks together. It is a collection of independent nodes that make their own decisions; it just so happens that everyone's decisions are exactly the same so it appears as if "the network" is one entity. There is no way for "the network" to decide "everyone but this one node has a shorter blockchain" as it is not one entity but rather thousands of individual nodes. Verifying that this statement is true requires every node to connect to every other node on the network which is practically impossible to do.

And then of course, why shouldn't everyone switch to the blockchain that the attacker made? It has more cumulative work and is thus more secure. It is valid; the attacker cannot insert invalid transactions otherwise his blockchain would be invalid. The only reason to reject this is for human subjective reasons, not the objective reasons that a computer will switch for. In the end, it would come down to human decisions as many technical people would notice such a fork and humans may decide to switch back to the other chain by directly instructing their software to do so. The software itself will follow the valid chain with the most cumulative work.


What is the risk of using wallet.dat files for long term cold storage? i created these wallet.dat files on an offline machine in 2014 using QT.  I've sent coins to the receiving addies over the years.  these files are bip38 encrypted.  do i need to do anything to these files to keep them usable and viable?  if so, what?  additionally, what is the argument against this form of cold storage?  thanks so much.

As long as your machine remains offline and encrypted the files should be usable as long as your hard drive is.

People choose to make multiple forms of backup in part to protect against equipment failure. Paper wallets printed with appropriate paper and ink can last a very long time and can be stores in safety deposit boxes, buried in a hidden location (properly sealed of course) or hidden as words in a poem.

Hardware wallets are another option, but still will require you to store seed words in order to recover in case of equipment failure.


is the proof-of-work for safety or efficiency? i am reading the proof-of-work (aka: pow, target threshold, difficulty, etc.); my understanding is that pow adds a requirement to validate block headers, so that both benign and malign nodes need a reasonable amount of time to create a valid block; but i dont see how this rate limit relates to safety; even if there is no pow, so that every block is valid, as long as benign nodes have the majority of computing power, couldnt they still guarantee the main chain is correctly formed?

for example, assuming benign nodes are the majority:

with pow, malign nodes generate new blocks at m blks/min, while benign nodes at b blks/min, and b > m;
without pow, malign nodes generate at 100000m blks/min, while benign nodes at 100000b blks/min; we still have 100000b > 100000m (even though the public ledger now grows much larger);

above is an extreme example, but you could imagine adjusting pow step by step, from current 10 blks/min to 20 blks/min, to 30blks/min, etc. does the bitcoin protocol become less secure from the adjustments?

In principle, yes, what you suggest could work, even in your "extreme case".  But in practice, if it took very little work to create a valid block, then there would be trillions of blocks created per second (by both good and bad actors), and it would become impossible simply to store or transfer that much data, not to mention trying to sort them into a chain.  You'd also have a lot more people stepping on each other's toes by creating multiple blocks naming the same parent, leading to many forks in the blockchain that would take a while to be resolved.

But there would be nothing wrong with altering the difficulty schedule so that blocks get created at a somewhat higher average rate (note that the Bitcoin standard is 0.1 blocks per minute, i.e. one block every 10 minutes, not 10 blocks per minute).  The choice of 0.1 blocks per minute was arbitrary and a different rate would work fine.  Litecoin, for instance, uses a rate of 0.5 blocks per minute.

It is helpful not to have it too fast, so that most of the time there is at least a few seconds between blocks, and the block has a chance to propagate through the network before a new one is found.  Otherwise you get more forks, as mentioned above.

Also note that a common misconception is that reducing the block time would speed up confirmation of transactions.  The security of a transaction against double-spend is related to the total work done on top of it in the blockchain, not just the number of blocks.  So if Bitcoin increased the block rate to 0.5 per minute like Litecoin, that would mean each block demonstrates only 1/5 as much work as before.  To get equivalent security to the current standard of 6 confirmations, you would now have to wait for 30 confirmations, and it would still take 60 minutes.

So while there wouldn't be any particular problem with increasing the block rate (other than those inherent in changing the protocol through a hard fork), there wouldn't be any dramatic benefits either.


Bitcoind running on external HDD trying to resolve cookie from default datadir On Elementary OS Loki 0.4.1 I've downloaded and installed bitcoind as per the official guide from bitcoin.org .

However, I in my case I don't have enough space on my internal SSD to store the whole blockchain, so I want to download it and maintain it on an external hooked up HDD.

When I run the bitcoind -daemon -datadir=path_to_external_hdd_folder the Bitcoin server starts up successfully and starts downloading the blockchain to that specified folder (In the logs I can see the height is growing and so is the size of the selected datadir which I passed in as an argument)

My problem is - when I try to run commands by running bitcoin-cli getblockchaininfo for example, I get the error:

error: Could not locate RPC credentials. No authentication cookie could be found, and no rpcpassword is set in the configuration file (/home/martin/.bitcoin/bitcoin.conf)

What's weird is that when I move the .cookie file from my external drive to /home/martin/.bitcoin/bitcoin.conf the commands start working.

This is a temporary solution though, I wouldn't like to move that file everytime I startup the bitcoin server.

Do I maybe need to pass in an extra argument to bitcoind -daemon?

I've tried passing -rpccookiefile=path_to_cookie_file_on_External_hdd to it but that didn't work.

Note: My bitcoin.conf file is empty.

UPDATE 1
I tried setting -conf when starting bitcoind but that didn't work either.

You need to pass the same -datadir option to bitcoin-cli as to bitcoind. This will enable it to find the cookie file, but also potential other relevant changes you could have made to bitcoin.conf like rpcport. (I know you haven't, but this approach is compatible with those).


Can I modify the source code of Bitcoin to generate addresses people have already used? Each time you start bitcoin-qt.exe program will generate new random address

But what happen if I modify source code and compile new version:

instead of new random address I can hard code in source code address which already exist on the network with BTC on it ( for example http://blockchain.info/address/1933phfhK3ZgFQNLGSDXvqCn32k2buXY8a )

After I sync "new" wallet with the chain I can retrieve all BTC on it

to do the same I can also modify RANDOM generator source code to generate any address which already exist on the network with BTC on it as above

So the question is:

It's possible to modify source code, compile to EXE and generate THAT way existing BTC address with private keys inside wallet.dat (I believe that private keys are created FROM BTC address by bitcoin-qt.exe) to steal the money

No, because you need the private key to spend the bitcoins. The chance you guess a private key is really, really, really small.

The amount of private keys is 64^16, which is 7.9228163*10^28. Written down this number looks this way:

79,228,163,000,000,000,000,000,000,000

Just to put this number into perspective, the US debt at this moment is:

17,193,871,000,000 $

If you would be able to guess and check 100 million private keys every day, it would take you (64^16)/100,000,000=7.9228163*10^20 days, which is 2.1706346*10^18 years. That is 2,170,634,600,000,000,000 years.

The approximate age of the earth is estimated at about 4.54*10^9 years, which is 4,540,000,000 years.


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

Debian 8 x64

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


How to upgrade Bitcoin Core from 0.18 to 0.20 on Ubuntu 18.04? I've installed Bitcoin Core on Ubuntu 18.04 (CLI). Now, the version 0.20 of Bitcoin Core is released and I want to upgrade my server to it, but it seems the new version is not included in PPA yet. May you help me to upgrade my Bitcoin Core server to 0.20 in a safe and correct way please?

This is how I usually do it. Check the wget links in https://bitcoincore.org/bin

# Download Bitcoin Core packages for Ubuntu

wget https://bitcoincore.org/bin/bitcoin-core-0.20.0/bitcoin-0.20.0-x86_64-linux-gnu.tar.gz

# check the checksum and fingerprint //optional
wget https://bitcoincore.org/bin/bitcoin-core-0.20.0/SHA256SUMS.asc
wget https://bitcoin.org/laanwj-releases.asc
sha256sum --check SHA256SUMS.asc --ignore-missing
    >expected: xxx.tar.gz: OK
gpg --import ./laanwj-releases.asc
gpg --refresh-keys
gpg --verify SHA256SUMS.asc
    >expected: Good signature from "Wladimir J. van der Laan ..."

# extract, install and check versions of the binaries
tar -xvf bitcoin-0.20.0-x86_64-linux-gnu.tar.gz
sudo install -m 0755 -o root -t /usr/local/bin bitcoin-0.20.0/bin/*
bitcoind --version
    >expected: Bitcoin Core version x0.20.0


addr_recv addr_from in version Message I need some clarification about the meaning of the addr_from and addr_recv fields
in the Version Message.

addr_recv: The network address of the node receiving this message
does this mean the public IP of the node I am sending to ?

addr_from:The network address of the node emitting this message
does this mean my public(external) IP address or my local IP address ?

Thanks ..

So assuming node A sends a version message to node B then the two fields have the following meaning and value:

addr_recv: node A says "I believe you are reachable via this IP", hence its value is B's public IP address, the IP this message was originally sent to.
addr_from: node A says "I believe my external IP is this", hence this is what A believes its external IP to be (but may be different if A is behind a NAT and has not learned its true external address yet).


Armory 0.93 on Testnet: consistent unconfirmed Txs sent from connected Bitcoin-cli (log attached) Running Armory (0.93.0.82) on Win7 x64 with the following flags:

"C:\Program Files (x86)\Armory\ArmoryQt.exe" --testnet --datadir=d:\data\armory\testnet3 --satoshi-datadir="d:\data\bitcoincore" --rpcport=8332 --debug --netlog --mtdebug --logfile=d:\data\armory

You'll find the log file throws a recurring error...

    -WARN  - 1427685617: (..\Blockchain.cpp:47) Somehow tried to add header that's already in map
    -WARN  - 1427685617: (..\Blockchain.cpp:48)     Header Hash: 00000000ad4e4c886567776c89e752614f251cca28b7dfcaf16867677ba0245a

FYI, those times/blocks correspond to the most recent blocks, as validated by Bitcoin-CLI.

It's worth noting that the "current block" field in Armory shows a block ~6000 old (stuck on 323060), and mouse hover says "last block received 1.5 minutes ago" (or something similar) and updates with the block discovery.

Bitcoincore (v0.10 btw) gives this screenshot (the top 2 Txs - TxID 706b60a90510e8db0186be5980819931127110e300ce10c5a5b3f5fb04667dc2 - are labelled ? however they are confirmed in Bitcoincore eventually)

I've tried numerous wallets instances in Armory, updating, ensuring the client is connected, using the rescanning/rebuilding database option, etc. EDIT: Rescanning the database has actually erased all record of the Txs in Armory

What is wrong here?

OK, I solved this by numerous trial and error CMDs. The problem lay in the Armory implementation, specifically, the --datadir flag.

The working CLI flags:

ARMORY: -qt.exe --testnet --datadir=d:\data\armory\testnet3 --satoshi-datadir=d:\data\bitcoincore --rpcport=8332
BITCOIN-QT: bitcoin-qt.exe -datadir="d:\data\bitcoincore" -testnet -rpcport=8332

Contradicting Armory's FAQ (in the FAQ itself) is the requirement to explicitly identify the testnet3 directory for the --data-dir flag (--data-dir==SOME\DIR\Armory\testnet3). If the testnet3 directory isn't identified, Armory confuses the mainnet blockchain data with the testnet chain data.

The bitcoin.conf contents were:

listen=1
daemon=1
server=1
rpcconnect=127.0.0.1
rpcport=8332


How to access bitcoin wallet on an android that became unresponsive? My Galaxy S4 mini suddenly stopped working for no apparent reason. It won't turn on via any recommended action or new battery, recovery software from the laptop can't seem to connect as a result. I had bitcoin wallet installed on it with bitcoins inside. How do I access/recover the wallet - or at least coins? Thank you!

It's not possible to answer this question without knowing what's wrong with the phone. Your best bet might visiting a repair shop. Tell them you need the data on that phone.


Resyncing bcoin brings up database version error I was resyncing my bcoin node and got the following error:

 Error: Warning: Your database does not match the current database version.
 This is likely because the database layout or serialization format has changed drastically.
 If you want to dump your data, downgrade to your previous version first.
 If you do not think you should be seeing this error, post an issue on the repo.
   at LowlevelUp.checkVersion (/root/bcoin/lib/db/lowlevelup.js:603:11)
   at <anonymous>

If you're running master, there was a recent migration that would cause this.

you can run this to fix it:
node migrate/chaindb2to3.js /path/to/chaindb.ldb

That will take a very long time, but if you don't mind pruning your DB at the same time, you can run this instead and it will be much faster:
node migrate/chaindb2to3.js /path/to/chaindb.ldb --prune

If that doesn't work you can always reset the DB and resync.
Just remove all .ldb files from ~/.bcoin dir and restart bcoin.


How to get the generator G point for any new curve? I have this bitcoin curve:

y^2 = x^3 + 7

but the finite field Fp is modified to be:

n=115792089237316195423570985008687907853269984665640564039457584007908834675927

1-What is the G point?

2-how to get the Y coordinate for any X value?

I'm using this C# code to get Y from X
but it works with original bitcoin curve only.

    public BigInteger mod(BigInteger num, BigInteger by) {
        BigInteger res = num % by;
        if (res < 0) { res += by; }
        return res;
    }

    public BigInteger EC_GetY(BigInteger x, bool modIt, BigInteger n) {
        BigInteger n_OVER_FOUR = (n + 1) / 4;
        BigInteger alpha = mod(BigInteger.Pow(x, 3) + 7, n);
        BigInteger beta = BigInteger.ModPow(alpha, n_OVER_FOUR, n);//SqRtN
        BigInteger Y = beta;

        if (!modIt) { return Y; }
        Y = n - beta;
        return Y;
    }

You can't just change N. N is the number of elements in the finite group. You can pick a new (prime) P close to 2^256 (or however many bits you want) and get a resulting N.

1) G is a point in the group that when added to itself produces another point in the group. Hence it can generate all other points with repeated additions (generator). If the number of elements in the group is prime then every point has this property and can be used as a generator (via Lagrange's Theorem).

2) Just use the curve equation. y^2 = x^3 + 7 => y = modsqrt(x^3 + 7) (everything is mod P)


Problem caused by unconfirmed transaction chains I want to build a service that requires sending many small bitcoin transactions to multiple wallets (like a faucet).

Since the transactions are small, the fees have to be kept small as well so it takes a while for them to be confirmed.

The system would need to send many transactions, which naturally creates long chains of unconfirmed transactions. If I understand it correctly, after 25 unconfirmed transactions the network starts rejecting new ones, and the system is basically stuck until the previous ones gets confirmed.

This limits the throughput of such a system to 25 transactions per confirmation time (which is at least a few hours given the low fees), making it completely unscalable.

Given the above, is there a way to build a (somewhat) scalable service that can send many small transactions? (without having to manage many wallets)

A few simple ideas get around the unconfirmed-tx-chain-limit you're running into:

Start with more UTXOs. Each UTXO can be used to create <25 unconfirmed child transactions. So if you need to make n payments, you'll need at least n/25 UTXOs to do so using this method.

However, you can definitely do this in a more cost-effective manner. As Murch mentioned, batch payments describe the method of creating a single transaction with many outputs. So instead of paying one customer per transaction, you can pay many customers per transaction.

Another option is to use the lightning network to send your payments. Lightning transactions are extremely cheap, and fast. If you are regularly sending small payments, I'd encourage you to consider this option.


My bitcoin address and name Please how will the receiver of the bitcoin know that I send the bitcoin into his wallet. And how do i send the bitcoin into another person's wallet

Typically the receiver will create a different address for every payment he expects.

That way, once the expected amount of coins have arrived at the expected address, the receiver knows which payment was fullfilled.

This is a better approach than trying to figure out who paid - something that's not generally possible and hurts Bitcoin's privacy. Typically you don't care who pays a bill, only which bill was paid.


Use old legacy bitcoin private key generated from 2012 to generate a segwit address The old legacy addresses starts with 1 and the new ones start with 3 and bc1. Can I use my old private key from 2012 to generate a bc1 address? And how so?

Addresses beginning with a 3 generated using addwitnessaddress are called P2SH-P2WPKH addresses. That means it is a Pay-to-Witness-Public-Key-Hash (P2WPKH) script embedded in a Pay-to-Script-Hash (P2SH) address, which starts with a 3.

To restore from that private key, you should be able to just import the key into your wallet and call addwitnessaddress on it again. Note that addwitnessaddress is an experimental RPC call so the method to restoring may change in future, but you can always generate the corresponding public key hash (address) from the key, create a P2WPKH witness script for it, and wrap it in P2SH.


Mixing Unequal Inputs Let's say have 3 inputs (alice, bob, satoshi): 0.3, 1.3, 1.6.
We can mix these inputs for example like this: 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.1, 0.1.
Or like this: 1.3, 1.3, 0.3, 0.3.
Traditionally it is mixed like this (CoinShuffle/ZeroLink/BlindCoin): 0.3, 0.3, 0.3, 1, 1.3.

There are many combinations, but there are better and worse mixes. I intuitively figured I want to anonymize the most bitcoins in the cheapest way.
First take the sum of the anonymity sets weighted by the amount of bitcoins. With the second mix example (1.3, 1.3, 0.3, 0.3) it would be:

alice: 0.3btc - 2/1=2 anonset -> 2*0.3=0.6
bob: 1.3btc - 2/1=2 anonset -> 2*1.3=2.6
satoshi: 1.3btc - 2/1=2 anonset -> 2*1.3=2.6 AND 0.3btc - 2/1=2 anonset -> 2*0.3=0.6

And the sum is: 0.6+2.6+2.6+0.6=6.4

Next we want the cheapest possible mix, for this we need to minimize the number of outputs, in the second example it's 4. Finally divide the number of outputs by the weighted anonset sum: 6.4/4=whatever (1.6).
We want this whatever number to be as high as possible. This is how we can anonymize the most bitcoins the cheapest way.
With the traditional mix, whatever would be 5 weighted anonset sum / 5 output number=1.

So the my ad-hoc 2nd algorithm exactly 60% more efficient.
I also wrote a little software that compared 3 different algos with 100 random inputs (results below).
The first goes like this: take always the smallest input and pair it up with the rest. This generated many outputs (as you can see it created so many outputs, that it overflow by 173% of the standard maximum Bitcoin transaction size.)
The second algo always took the second greatest input and paired it up with the greatest.
During the third algo I used middle out, so I took the middle input and paired it up with as many inputs as possible. This provided by far the best whatever value: 149.

Test code: https://github.com/nopara73/ConsoleApp14/blob/master/ConsoleApp14/Program.cs

What algorithm can lead to the most optimal mix?

I don't have an answer to your question directly, but it's worth pointing out that anything other than 32 x 0.1btc inputs and 32 x 0.1btc outputs provides worse anonymity. Even having 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.1, 0.1 gives away some information that likely 2 of the inputs were 0.1btc above a number divisible by 0.3. Maybe there's a peak on a benefit/cost curve, but it's still a trade-off against privacy. There are other solutions outside of Bitcoin (that vastly improved on the concepts of coinjoin) like MimbeWimble which do what it sounds like you want in terms of cheap coinjoining, but with other benefits too, that Bitcoin is unable to implement because of its design


Post Bitcoin mine reward: Lowering Difficulty an Option? Maybe my understanding of blockchain, and Bitcoin need to be refined and will allow help me understand why my question wouldn't make sense in the grand scheme.

But first Ill establish my core understandings of the current concept...

With each leading zero added for a hash to be accepted in Bitcoins blockchain, it becomes increasingly more difficult (16 times more difficult) to find an acceptable nonce, thus mine a block.

I understand that the reason these difficulties were built in were to balance the amount of compute power with how fast blocks could be mined and rewards dispersed. This not only ensures there will be rewards long into the life of the coin but also ensures the coin was not devalued by having a "too easy" mining method as it grew in popularity.

In addition, as the difficulty of mining a block increases, reward decreases, the transaction fees also increase. This incentives miners to continue mining blocks and ensuring transactions can occur long past the last reward block mined.

My question is...

In the interest of everyone involved, wouldn't it make sense if the system was built to lower the difficulty after the last reward block was mined?

If that were the case, transaction times could be increased and become much easier to mine. Meaning transactions could cost less, be faster for miners without effecting the value of Bitcoin it self.

Thoughts? Am I missing something big that would make this an impossible concept?

The difficulty is not constantly increasing. It is increasing in response to the hashrate going up. If the hashrate would be going down instead, the difficulty would automatically go down as well.

The goal of the difficulty adjustment algorithm is to keep the average time per block at 10 minutes.

If in response to dwindling fees and/or subsidy, mining would become less profitable, we will likely see a decrease in hashrate. That would result in a reduction to the difficulty, until mining is profitable again (to some).


Can I restore an additional address of Bitcoin Core Once in Bitcoin Core I created an address to receive some payments from a faucet. After years I reopened the Bitcoin Core and started to synchronize it. After a while there was a crash, and I decided to remove the previous Bitcoin Core folder (it appeared to be in a USB hard drive and didn't get to Recycle Bin - when I decided to restore the removed files it was too late).
Then I reinstalled the Bitcoin Core, put there a wallet.dat from backup and successfully synchronized the blockchain. But I discovered - there's no address for the faucet, which I needed and there's no satoshi I expected. Apparently I created it before the backup (some previous history was there - so the wallet was restored - but without the latest address). So, should I consider the value on this address lost?
I tried to create the dump (dumpwallet "dump.txt") and to find the master private key there to restore the private key of this address somehow. The dump file contains some # extended private masterkey (starts with xprv). Also I know the address, which I set to the faucet (1J2ia2JZVoN8fqdvGYjkVaaX3A2C5BZzwj). So I thought I can use this data in "Mnemonic Code Converter" (https://iancoleman.io/bip39/) (extended private masterkey to BIP32 Root Key input and selected the Bitcoin Core presets everywhere). Surprisingly enough the first generated entry contained my first default address, but I couldn't find neither of the other addresses from the dump file. The address from the faucet doesn't exist in the dump either. What do I do wrong?
Here is the address I'm talking about: https://www.blockchain.com/btc/address/1J2ia2JZVoN8fqdvGYjkVaaX3A2C5BZzwj

Try it Electrum. Do import extended private masterkey


Question about identical txids/merkle tree in Developer guide I am new to the technical details about Bitcoin and has been reading Developer guide on bitcoin.org.  I have a question about below contents mentioning merkle tree, identical txids.

I googled and searched here but seemed to be no answer.

  Note: If identical txids are found within the same block, there is a possibility that the merkle tree may collide with a block with some or all duplicates removed due to how unbalanced merkle trees are implemented (duplicating the lone hash). Since it is impractical to have separate transactions with identical txids, this does not impose a burden on honest software, but must be checked if the invalid status of a block is to be cached; otherwise, a valid block with the duplicates eliminated could have the same merkle root and block hash, but be rejected by the cached invalid outcome, resulting in security bugs such as CVE-2012-2459.

I don't quite understand above contents. How would a merkle tree collide with a block? What do "collide" and “eliminate duplicates" mean ?   identical txids either mean same transactions or duplicate txid in order to generate a merkle root. What does "cache the invalid status of a block" stand for ?  How would this be rejected by the cached invalid outcome?

I would appreciate it if you could help me understand. Thanks!

It refers to a (practically impossible) edge case due to how unbalanced merkle trees work.

Let's say you manage to find two transactions with the same transaction ID, T1 and T2.

Now, let's build the merkle tree for a very simple block:

                 H(A, B)
                /       \
       A = H(CB,X)       B = H(T1,T2)
        /        \        /         \
       CB        X       T1         T2

Now, if you were to build the same merkle tree without T2, you have an unbalanced tree with only 3 leaves. To fix this, the last leaf is duplicated, as such:

                 H(A, B)
                /       \
       A = H(CB,X)       B = H(T1,T1)
        /        \        /         \
       CB        X       T1         T1

However, since T1 and T2 share a transaction hash, your merkle root actually ends up being identical to the tree with two separate transactions.

Since the merkle root is the same, the proof of work for a block containing T1 and T2 would also be valid for a block containing only T1.

Thus, if the first block is considered invalid by an honest node, when it sees a second block arrive with the same block header, it may dismiss it as invalid automatically based on the cached status on the original block's header, even though the second block does not contain T2, and is in effect a different, potentially valid, block.


Unable to decrypt wallet.wallet file I have a wallet.wallet file that I think was created with Android bitcoin wallet or Multibit.  It's base64 encoded.
Putting it in a decoder, it gives me this information, redacted just in case:
{"iv":"randomalphanumeric==","v":1,"iter":1000,"ks":256,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"randomalphanumeric=","ct":"randomalphanumeric="}
When I try to upload any part of that, including just the raw base64, into Electrum (the recommended alternative since multibit was deprecated) I get errors that its invalid.  The android bitcoin app either can't read it or I don't know my password.
Does anyone have any idea what this is or what its for? Is it even cryptocurrency related?
Also, the last string has a ton of characters including forward slash "/" and plus signs "+". Not sure if that helps.
I did attempt to try and follow with this thread Bitcoin Wallet for Android - Issues decrypting the wallet backup BIN file using OpenSSL , but to no avail.
I get "error reading input file"

Does anyone have any idea what this is or what its for?

It is obviously related to cryptography.
Since the Bitcoin network itself doesn't use encryption, this is likely a configuration file or data file for a specific wallet's scheme of encrypting the private-keys and other information that need to be protected from being stolen and misused.
{
  "iv":"randomalphanumeric==",
  "v":1,
  "iter":1000,
  "ks":256,
  "ts":64,
  "mode":"ccm",
  "adata":"",
  "cipher":"aes",
  "salt":"randomalphanumeric=",
  "ct":"randomalphanumeric="
}

iv is initialisation vector
v is version
iter is number of iterations of encryption to be applied
ks is key size
ts don't know, maybe the size of something.
mode is an encryption mode. ccm is probably something like cipher chaining mode?
cipher is the encryption algorithm. aes is the "advanced encryption standard".
salt is a random number used to combat attacks using precomputed dictionaries.
ct don't know. Could be "ciphertext" - the encrypted version of some data ("plaintext").

the last string has a ton of characters including forward slash "/" and plus signs "+"

That is fairly common in encoding methods used to take binary data and present it using readable/printable characters. In this case it is probably base64 encoding. As I think you know, encoding is not encryption, just an easily reversible presentation method.

By itself, it is of no use to you. If you know the password (encryption key) you could probably decrypt the possible ciphertext (ct value) after reversing the base64 encoding. You could then examine the (potentially binary) "plaintext" to see if it contains a Bitcoin private key.


What other proof methods are there? I am familiar with the proof of work method and a little with the proof of stake method. Is there any more methods that are out there and how do they work?

A few others on top of my head, in addition to variations of PoS (DPoS, LPoS, etc)

Proof of Importance (PoI): kinda like PoS, but stake here is the total transaction amount (greater than some vested amount of coin)
Proof of Authority (PoA): transactions are validated by selected validators
Proof of Burn (PoB): please refer to this SE question: How does Proof of Burn work?


How can the number of peers from the same IP address be counted? A Bitcoin client connects to peers and can accept connections from peers.  Is it possible to learn how many nodes exist from a specific IP address?

Specifically, the monitoring service from RowIT ( http://bitcoinstatus.rowit.co.uk ) gives a metric "Total Hosts", but I suspect that if there was more than one host from an IP address, the second and successive hosts would not be counted in the total.

That monitoring page states that it counts hosts from 'addr' messages seen on the bitcoin network.

An 'addr' message contains the IP number & port number of a bitcoin client. Since all bitcoin clients use the same listening port number the IP number is the only information to count by.

When a bitcoin client connects to a peer it does send out an extra number to identify it by. However there is no friendly way to force all clients behind an IP number to connect to you so you cannot capture that number for all those clients.


What is the meaning of the "spent" attribute of a transaction output? Looking at blockchain.info/tx/c52b....2b09?format=json, I see this:
[{
    "spent":true,
    "spending_outpoints":[
    {
        "tx_index":0,
        "n":0
    }
    ],
    "tx_index":0,
    "type":0,
    "addr":"1MLZEBnV8z7wKZnqUkkNWCaA7kohsvmkA2",
    "value":493599,
    "n":0,
    "script":"76a914df15522bd48e91e24d4ee94424ae0681ee7f1a1a88ac"
},
{
    "spent":false,
    "tx_index":0,
    "type":0,
    "addr":"3KcFQ3BxZzyPnq6VGW1LWjKnJZR6F3fYVS",
    "value":106862,
    "n":1,
    "script":"a914c48b6e8ee99bef36819e1d90365dea087075ba7187"
},
"..."
]

I've assumed that every output was "unspent" when it is created. Here, it looks as if it is spent directly when the output is created? What does that even mean? Is it maybe spent in another transaction in the same block?
Or is that attribute added "later" by blockchain.info to give the reader a bit more context?

Or is that attribute added "later" by blockchain.info to give the reader a bit more context?

I'm pretty sure that is what is happening.
If you look at that transaction in a different explorer, for example https://blockchair.com/bitcoin/transaction/c52b5df64f10463fbe4f46d7b9da3464449849b7e542d533575a927366b52b09 and click "raw tx" you'll see it doesn't include that information in the JSON.


Is Coinbase transaction required to be signed? I am trying to build a coinbase for mining with the following steps:

1-Create dummy Input and output.

2-Pass them to CreateRawTransaction as collection/

3-Get a transaction back and fill the empty fields according to coinbase structure (specially set Txout’s Value to 12.5 bitcoin).

4-Serialized transaction into Hex string mode.

With above steps preformed in RegTest mode a new block created and 50 Bitcoins added to the wallet which seems to be correct but as far as I know a transaction should be signed, Is Coinbase excluded from signing procedure ? and why it’s add 50 bitcoins to account instead of amount which I specific set to 12.5 bitcoin ?

public async Task<string> BuildCoinbaseTransaction(string MinerAddress, uint Height)
{
    string coinTxSerialized = string.Empty;
    scriptData = Tools.RandomNumbers(rEngine);
    string pubKey = await GetPublicKey(MinerAddress);
    string scriptPubKey = CreateCoinbaseScript(pubKey);

    List<object> txi = new List<object>
    { new CoinIn { TxId = "0".PadLeft(64, '0'), Index = 0x0 } };

    List<object> txo = new List<object>
      { new Dictionary<string, double> { { MinerAddress, 0.00 } } };

    RPCResult<string> rpcResult = await cmd.CreateRawTransactionAsync(txi, txo);

    if (rpcResult.Error == null)
    {
        TotalReward = Math.Min(RewardCoins + CollectedFee, MaxCoinbaseValue);

        string rawCoinbase = rpcResult.Result;
        string decodedTx = await cmd.DecodeRawTransaction_CommandAsync(rawCoinbase);

        RPCResult<string> Transaction jsonTx= JsonConvert.DeserializeObject<RPCResult<string>>(decodedTx);
        Transaction coinTx = jsonTx.Result;

        coinTx.Height = BuildHeight(Height);
        coinTx.TxIn.FirstOrDefault().Coinbase = scriptData;
        coinTx.TxIn.FirstOrDefault().Sequence = 0xFFFFFFFF;
        coinTx.TxOut.FirstOrDefault().Value = TotalReward;
        coinTx.TxOut.FirstOrDefault().ScriptPubKey.Assembely = scriptPubKey;
        coinTx.Hex = coinTx.ToString();
        coinTxSerialized = coinTx.Hex;

        return coinTxSerialized;
   }//if

}//BuildCoinbaseTransaction

The coinbase transaction is constructed by the miner/mining pool operator and is not a transaction which can be broadcast to the mempool.

The amount of the coinbase output is strictly according to the block height, which begins with 50 BTC and halves every 150 blocks in regtest mode. When you create a new block in regtest mode, it will automatically generate a coinbase transaction, with the output spending to your specified coinbase wallet.

The input script of the coinbase has the [blockheight (4B)] and additional data, totally a maximum of 100B.

Input:

Previous TX hash: 00..00
Previous output index: max_value(ff..ff)
Input script: [blockheight (4B)] [additional arbitrary data]

The input is not signed because it does not spend from a UTXO. There are no locking conditions other than to be committed to a header with valid POW.


Would a hardware wallet be hacked in this case Bought a hardware wallet (Ledger nano s) recently, they claim that they are safe since it is a cold wallet. Online wallets (such as Crypto.com) are not safe as they are constantly online and hackers can hack through internet, which is fair enough.
However, in the following 2 cases, would hardware wallet still be safe?

Ledger has their app: Ledger live, which is connected to internet, and connects to Ledge Nano s when it is plugged in. Say hacker has hacked Ledger live and my nano s is plugged in, would he/she be able to steal my assets through Ledger live?

My nano s is not plugged, which is safe as it is cold. A hacker has hacked Ledger live, but he/she's not able to steal my assets since I'm offline. Will he/she be able to steal when I plug my nano s in the next time?

Your hardware wallet is only used to sign (approve) a transaction.
Therefore, unless someone gets direct access to your seed phrase(which will allow him to confirm transactions on your behalf) nobody can do anything with your funds.
The thing to remember is to always keep your seed phrase somewhere safe and OFFLINE.
The reason I like Trezor One is that it has a touchscreen feature. Meaning that even if your computer or phone is keylogged hacker still can't find out what your seed phrase is.
If you're interested, I have written an ultra descriptive guide about hardware wallets and Trezor vs Ledger comparison you can check out.


Possible to use BlockChain.info and Bitcoin-QT synced? I've used both BlockChain.info and Bitcoin-QT. Is it possible to use the same addresses on both? I don't have a incredibly large amount of bitcoins, so I'm not worried about it getting hacked into, however I am worried about it getting corrupt as it will be used in two different wallets. Is it possible for them to get corrupt by doing this? If not, how would I import the key to Bitcoin QT from BlockChain?

You aren't going to run into issues doing this, as wallets don't store transactions (technically), they look them up on the Bitcoin network blockchain. If you make a transaction on one wallet it will automatically update as long as both have downloaded the latest chain. For blockchain.info wallets this will be true and for Bitcoin-QT it takes a few hours to download the full chain.

If you're afraid of making a corrupt wallet accidentally, you can:

Print out the private key for your addresses. Keep it in a safe place. An addresses       private key does not change.
Create an encrypted backup. Both wallets let you do this, your wallet private keys will only be able to be read with a decryption key; the password you set for the wallet. Anyone who will have your encrypted backup won't be able to do much if they don't know your password for it and password strength.
Create a brain wallet and import it into both wallets. All your keys from the memory wallet will simply be memorized in your mind, where you can only forget it.

Check out these precautions as well.


Why was the time between these two blocks not approximately 10 minutes? A new block will be created in approximately 10 minutes, but I saw on blockchain.info that these two blocks were found only two minutes apart!

How come that the time between the first two listed blocks is just two minutes?

There are a few things to know about the frequency of blocks:

Every hash has the same chance of finding a block. So, times between blocks are randomly distributed.
The difficulty (i.e. the expected number of hashes required to find the next block) is only adjusted every 2016 blocks. With ten minutes between blocks that would be every 14 days. However, since a lot of hashing power is being added to the network every day, the hashing power quickly starts to exceed the difficulty that it was estimated to accomodate, and the average time between blocks starts to get lower until the difficulty is adjusted again. So right now, we are probably closer to a block every 7 minutes in average than every 10 minutes.


Would writing one's own cryptocurrency in a language other than C/C++ be stupid? I'm curious from a performance perspective if writing a cryptocurrency from the ground up in a language other than C/C++ be stupid?

For example, if I wanted to write a cryptocurrency and protocol in Python or Nodejs, would I run into performance and speed issues later down the rode since these languages aren't as "low-level"?

Or are there any other issues besides performance I would run into?

Any thoughts are appreciated. Thanks

There's no reason why a cryptocurrency needs to be written in a low level language. It's just that Satoshi's original implementation of Bitcoin happened to be in C++ (perhaps that was the language he/they felt most comfortable with), so now a lot of people seem to think it has to be that way. It doesn't.

You could certainly implement a cryptocurrency (either an existing one, or a totally newly designed one), in Python, or Javascript, or pretty much anything else. Wallet software is mostly managing a big database with a bunch of hashing.


How do I accept Bitcoin Cash without using a third-party? I'm looking for a way to accept Bitcoin Cash on my e-commerce site without using a third-party payment processor such as Rocketr. Third party services would not be ideal for me because:

I would not hold the private keys to my Bitcoin Cash.
I would pay a fee for each transaction.

Seeing this as the case, I'm only willing to use software on my own servers to accept Bitcoin Cash in a security-minded way.

Here's my current approach:

Have two servers: Server A, which runs Apache; and Server B, which runs a Bitcoin Cash wallet such a Bitcoin Unlimited.
Server A requests addresses from Server B through the JSON-RPC interface.
Server A displays the address to the user and pings Server B at intervals until the payment is confirmed.
The user sees a confirmation page and the order is complete.

Advantages to this approach:

I hold my private keys.
I would not have to "refill" the server with public keys.
Private keys (theoretically) never leave Server B.

Disadvantages:

Both Server A and Server B must be online in order to accept transactions.
Server B must be configured in a way so that the commands dumpprivkey, dumpwallet, createrawtransaction, and send* are disabled. (How?)

So, is my approach the way to go, or is there a superior alternative?

Your Bitcoin cash server may be a target for many since it has all the private keys.

I would suggest you get one private master key and public key.

use your public key to generate addresses and your private key to spend Bitcoins.

You can createrawtransaction and all the other commands using PHP or javascript without the need to have a running server.

these libraries are helpful: bitcoinlib-js for javascript and bitcoin-php for PHP

You may need a server just for broadcast a transaction if you want to send bitcoins. you could use your own server or use public servers like electrum servers or blockchain.info


Do I Have to Cash Out? Say I have an account with MtGox, and I put $5k worth of bitcoins in there. The exchange rate subsequently goes up by 10%. Now my MtGox bitcoins are worth 5.5k. Can I exchange this for USD in my MtGox account, but let it sit in my MtGox account until I want to buy bitcoins again?

The reason I ask is because I am in Australia, and MtGox charges a $10 fee (plus the 0.6%) to send to my bank account, and more importantly, it takes a few days to transfer. This means if I choose to buy BTC again, I have to transfer money from my bank account back into my MtGox account which also takes a few days. That's a turnaround time of almost a week, which would make "day trading" impossible!

Can I have usd in my MtGox account without transferring it to my bank account, or having it in bitcoins?

I'm a newbie, obviously...

Can I have usd in my MtGox account without transferring it to my bank account, or having it in bitcoins?

Yep.


Getting balance/downloading blockhain with bitcoinj I am playing around with bitoinj and I can't seem to even get the most basic functionality running.

What I want to do: I have one wallet with one address. I want to dowload blockchain and from that, get the wallet balance.

What I did is following code (in scala, but it is more or less the same thing as Java), the wallet is in address.walet, I want the blockain to be saved at saved.blockchain:

val params = NetworkParameters.prodNet
val walletFile = new java.io.File("address.wallet");
val wallet = Wallet.loadFromFile(walletFile)

val key = wallet.keychain.get(0)
val address:String = key.toAddress(params).toString
println("ADDRESS IS : "+address)

val blockStore = new BoundedOverheadBlockStore(params, new java.io.File("saved.blockchain"))
val chain = new BlockChain(params, wallet, blockStore)
val peerGroup = new PeerGroup(params, chain)
peerGroup.setUserAgent("BitToy", "0.1")

peerGroup.addPeerDiscovery(new DnsDiscovery(params))
peerGroup.addWallet(wallet)
println("START DOWNLOADING BLOCKCHAIN")

peerGroup.start()
peerGroup.downloadBlockChain()
peerGroup.stop()
println("DONE; BALANCE IS :")
println(wallet.getBalance)

I do have balance on the address in the wallet.

Now, when I run it for the first time, the blockchain (or, rather, the headers) gets downloaded and I see the correct balance. However, when I run it for second time, I just see:

ADDRESS IS : [correct address here]
Aug 19, 2012 8:06:00 AM com.google.bitcoin.store.BoundedOverheadBlockStore load
INFO: Reading block store from saved.blockchain
Aug 19, 2012 8:06:00 AM com.google.bitcoin.store.BoundedOverheadBlockStore load
INFO: Read chain head from disk: 00000000000001b10c347b5ec05f9a1910d541905c5cd8827784a5c3e0695c95
Aug 19, 2012 8:06:00 AM com.google.bitcoin.core.BlockChain <init>
INFO: chain head is at height 194575:
v1 block:
   previous block: 00000000000005ac50dc06021362cd4c284fafd4a1bdb7bad2849c978a875bb1
   merkle root: 158aedd0bc3386c7686f85ab933fd9e3ecb38e348b121ed0e61e2e776eda04a1
   time: [1345356028] Sun Aug 19 08:00:28 CEST 2012
   difficulty target (nBits): 436709470
   nonce: 4238997601

START DOWNLOADING BLOCKCHAIN
Aug 19, 2012 8:06:31 AM com.google.bitcoin.discovery.DnsDiscovery getPeers
INFO: DNS lookup for dnsseed.bitcoin.dashjr.org failed.
Aug 19, 2012 8:06:36 AM com.google.bitcoin.core.TCPNetworkConnection$NetworkHandler channelConnected
INFO: Announcing ourselves as: /BitCoinJ:0.6-SNAPSHOT/BitMessage:0.1/
Aug 19, 2012 8:06:41 AM com.google.bitcoin.core.Peer$PeerHandler exceptionCaught
INFO: com.google.bitcoin.core.Peer$PeerHandler@193f6e2 - No route to host
Aug 19, 2012 8:06:46 AM com.google.bitcoin.core.Peer$PeerHandler exceptionCaught
INFO: com.google.bitcoin.core.Peer$PeerHandler@61736e - No route to host
Aug 19, 2012 8:06:52 AM com.google.bitcoin.core.TCPNetworkConnection$NetworkHandler channelConnected
INFO: Announcing ourselves as: /BitCoinJ:0.6-SNAPSHOT/BitMessage:0.1/
Aug 19, 2012 8:06:52 AM com.google.bitcoin.core.PeerGroup handleNewPeer
INFO: Peer(seed.bitcoin.sipa.be/50.130.4.89:8333): New peer
Aug 19, 2012 8:06:52 AM com.google.bitcoin.core.PeerGroup handleNewPeer
INFO:   starting block chain download
Aug 19, 2012 8:06:52 AM com.google.bitcoin.core.PeerGroup setDownloadPeer
INFO: Setting download peer: Peer(seed.bitcoin.sipa.be/50.130.4.89:8333)
Downloading block chain of size 0.
Done downloading block chain
Aug 19, 2012 8:06:52 AM com.google.bitcoin.core.Peer blockChainDownload
INFO: Peer(seed.bitcoin.sipa.be/50.130.4.89:8333): blockChainDownload(0000000000000000000000000000000000000000000000000000000000000000) current head = 00000000000001b10c347b5ec05f9a1910d541905c5cd8827784a5c3e0695c95
DONE; BALANCE IS :
0
Aug 19, 2012 8:06:52 AM com.google.bitcoin.core.PeerGroup$PeerGroupThread run
INFO: shutdown start

and the balance is zero. If I delete the saved blockchain and let it re-download again, it works again, but only for one time.

What am I doing wrong?

OK, now I get it.

I can't.

Bitcoinj saves only the headers. And - what I did not know - you can't get the balance with just headers.

For more ingormation you can see the exact description what is in the headers here https://en.bitcoin.it/wiki/Block_hashing_algorithm

What I can do, however, is saving the wallet right afterwards. Which I will do.

previous "answer"/thinking out loud:

I am poking around in source code.

It seems like the important part is when sendTransactionsToWallet is called in BlockChain.java - but it gets only called during connectBlock and nothing else.

connectBlock is called only during add. And the only added blocks are the new blocks from the network, not the ones from BlockStore.

But I will look around the code a bit more.

I am not sure, what terrible would happen, if I rewrote the constructor of BlockChain.java from:

/**
 * Constructs a BlockChain connected to the given list of wallets and a store.
 */
public BlockChain(NetworkParameters params, List<Wallet> wallets,
                  BlockStore blockStore) throws BlockStoreException {
    this.blockStore = blockStore;
    chainHead = blockStore.getChainHead();
    log.info("chain head is at height {}:\n{}", chainHead.getHeight(), chainHead.getHeader());
    this.params = params;
    this.wallets = new ArrayList<Wallet>(wallets);
}

to (writing from my head, getters/setters might not be right, etc)

/**
 * Constructs a BlockChain connected to the given list of wallets and a store.
 */
public BlockChain(NetworkParameters params, List<Wallet> wallets,
                  BlockStore blockStore) throws BlockStoreException {
    this.blockStore = blockStore;
    chainHead = blockStore.getChainHead();
    log.info("chain head is at height {}:\n{}", chainHead.getHeight(), chainHead.getHeader());
    this.params = params;
    this.wallets = new ArrayList<Wallet>(wallets);
    StoredBlock sBlock = blockStore.getChainHead();
    Sha256Hash prevHash = sBlock.header.prevBlockHash();
    while (prevHash!=Sha256Hash.ZERO_HASH) {
        for (Wallet wallet:wallets){
            sendTransactionsToWallet(sBlock, NewBlockType.SIDE_CHAIN, wallet, sBlock.transactions);
        }
        sBlock = blockStore.get(hash);
        prevHash = sBlock.header.prevBlockHash();
    }
}

but again, I don't want to reinvent the wheel or anything.


Why doesn't RBF include restrictions on the outputs? Why didn't the RBF specification include additional constraints on the replacing transaction, such as that it would need to contain the same outputs (with at least the original output amounts) as the transaction being replaced? Couldn't this have made it safer to assume that zero-confirmation RBF transactions would eventually settle on-chain?

The one downside I can think of is that every RBF replacement would then need an additional input since the fee increase needs to come from somewhere. Are there any others?

Why didn't the RBF specification include additional constraints on the replacing transaction, such as that it would need to contain the same outputs (with at least the original output amounts) as the transaction being replaced?

Because it is not as effective to do this. What you describe is known as First Seen Safe RBF (FSS-RBF). However this imposes additional restrictions on transactions that make fee bumping difficult, if not impossible to do.

FSS-RBF notably requires spending an additional input. However if no input is available (e.g. user has one input, or is sweeping their wallet), then the transaction cannot be replaced. Or users may wish to retain their privacy by avoiding to spend certain inputs together and so if they have no inputs they are willing to add to the transaction, then it cannot be replaced.

Furthermore, this increases the size of a transaction with each bump thereby taking up more and more block space for little utility. The cost to continuously bump a transaction's fee also will grow non-linearly. In addition to the new feerate you are targeting, you also have to pay for the input you've just added at that feerate.

It also means that continuously bumping the transaction fee is annoying to do, and eventually, impossible (due to lack of inputs). If you lowball the fee, then decide to bump it later, and that is still too low, to bump it again requires another input. And so on and so forth. Bumping the fee like this reduces your future ability to FSS-RBF transactions too as you will be consolidating inputs.

Conversely, Full RBF does not require extra inputs, so as long as you have a change output, you can keep decrementing that to get the new fee. This means that the fee will only grow as the fee rate grows, and it does not require more block space. Since it does not require more inputs, you can fee bump transactions when you have no additional inputs available.

  Couldn't this have made it safer to assume that zero-confirmation RBF transactions would eventually settle on-chain?

No, in fact, it would have made it worse.

To assume that a 0-confirmation transaction is safe means that you are willing to spend its outputs. In that spending transaction, you will be explicitly referencing the txid of the transaction whose output(s) are being spent. Replacing a transaction (in both RBF and FSS-RBF) means creating a new transaction that spends the same inputs, i.e. a double spend. This new transaction will have a different txid because it, at the very least, changes the amounts of the outputs and thus results in different data being hashed. So if the bumped transaction becomes confirmed, then any transaction the spent the outputs of the lower fee transaction instantly becomes invalid. This is not safe at all.

The fact that people will think that unconfirmed transactions are safe to accept if FSS-RBF were used (as you did) is far more dangerous than Full RBF. With Full RBF, people know to just wait for confirmations. With FSS-RBF, people will think that unconfirmed transactions are safe to accept, spent its outputs, and then find out that their transaction is invalidated when a bumped version of the original unconfirmed transaction is mined instead. It is a false sense of security.

In general, unconfirmed transactions are not safe to accept, regardless of RBF, FSS-RBF, or no RBF at all. Either way, an unconfirmed transaction could be replaced with a conflicting one and result in any transaction that spent from the original unconfirmed transaction to become invalid. Because the dangers are all the same regardless of RBF and which type of RBF is used, Full RBF where any outputs can be replaced is better as it is more space and fee efficient.

There is some discussion of the motivation for Full RBF over FSS-RBF in BIP 125 itself.


How can I reduce the time until I get the newest block ? Does the number of the outbound peers affect the speed? I am running a full node on the Bitcoin network. Sometimes, I find that it takes a while until I get the newest block.
I checked the source code, and found that every node can at most connect to eight peers. Would it help to increase the number of connections, to reduce the time until I receive the newest block?

Up until the latest release (v0.9.3), more peers actually means slower synchronization typically, because we only really fetched from a single peer.

The upcoming release (v0.10.0) has a completely rewritten block fetching/validation mechanism, which first validates headers, and then fetches the blocks from all peers in parallel. The result should be much faster synchronization.


Is there a calculation for exchange rate stability? Exchange rate stability can be used as an indicator to determine how consistently you will earn the same profit over a period of time when mining a cryptocurrency. My current thinking is that a chart of the daily average exchange rate values from the last 14 days can indicate the exchange rate stability of a coin based on exchange rate fluctuations in the last 14 days.

But I have no idea how to actually go about calculating a metric like this or what the units would be.

This site can help you calculate the beta of Bitcoin:

https://btcvol.info/

"What definition of volatility does btcvol.info use?

The standard deviation of daily returns for the preceding 30- and 60-day windows. These are measures of historical volatility based on past Bitcoin prices. When the Bitcoin options market matures, it will be possible to calculate Bitcoin's implied volatility, which is in many ways a better measure."

https://en.wikipedia.org/wiki/Beta_(finance)

In finance, the beta (β or beta coefficient) of an investment indicates whether the investment is more or less volatile than the market. In general, a beta less than 1 indicates that the investment is less volatile than the market, while a beta more than 1 indicates that the investment is more volatile than the market. Volatility is measured as the fluctuation of the price around the mean: the standard deviation.


Bitcoins not showing up in Bitcoin-Qt wallet I bought 1 BTC from localbitcoins.com and received my bitcoin in my online wallet with no problems at all, after that I then sent it to my "bitcoin-qt wallet" address located inside the Bitcoin wallet itself under the "receive" tab. My bitcoin transaction seemed to work because the transaction information was on blockchain.info but once I looked at my "bitcoin-qt" wallet there where no bitcoins in my balance? Where have I gone wrong? Where have my bitcoins gone? it also says (out of sync) on the overview page and also "no block source available on the bottom left next to a bar saying "32 weeks behind"

If your client is "32 weeks behind" then it hasn't yet received the transaction that sent the coins to its address. Once it is in sync, you should see  that transaction and a correct balance. If you are able to connect to the network, the client should sync automatically (though it may take many hours or even days, depending on the speed of your computer and internet connection). If it is not updating at all, check that your internet connection works and isn't blocked by a firewall.


Bitcoin full clients checks all the blockchain every time they receive bloom filter? I assume that an spv client like bitcoinJ requested transactions related to the client one week before and the client has been offline for a week. When the spv client come online, does it just request new transactions which has been created while it was offline?

Also, does a full client which receives a bloom filter from the spv client check only the new transactions, or all the blockchain from the genesis block?

They will not do so automatically. When a peer sets a bloom filter, the node will not do any additional work except note that there is a bloom filter set for a given peer and begin matching things against the filter. It will not go back in history to match historical data against the filter and then relaying everything that matches. Doing so would be computationally expensive and a way to effectively DoS a node.

Instead of giving a node the historical data, the peer that set the filter must ask for it. They do so by sending getdata messages for historical blocks and the full node will pull up those blocks, match them against the filter, and then send a merkleblock message. This way it's easier to avoid being DoS'd and the receiving peer can specify where the full node should start and stop so that it can get the data it wants as quickly as possible.


Compiling Stellar-core on windows: where does mingw/cygwin come in I am trying to compile stellar-core code on windows but I can't to figure out what to do with mingw to make it work. I.e. I have downloaded and installed all required tools including mingw but I don't know how to setup mingw to work here.

The install.txt says mingw is required for building xdrc but there isn't much more. When I tried to build is 2 out of 7 projects compiled successfully.

All tips will be appreciated. Thanks

I am not sure StackExchange is the place to ask this as it's issue level (which GitHub can take care of - https://github.com/stellar/stellar-core/issues).

Anyways, in the Install-Windows.txt it says to also update your PATH environment variable, did you do this?


With Ripple, what is "Close Resolution?" In the spec for the ledger format, there's something called "Close Resolution" in the header. It is described as "the resolution (in seconds) of the close time." What does it mean, and what is its significance?

Ledgers do include a close time because it is expected that contracts will be able to support things that can "expire" such as escrow. However, validators might see a ledger close at very slightly different times owing to their slightly different network views and errors in their clocks.

To resolve this, Ripple uses a close time resolution. Validators announce the close time they actually saw to help their clocks stay in synch, but they only try to reach a consensus on the rounded close time.

If validators ever fail to reach a consensus on the close time (and this has happened a few times), they agree to disagree, indicate this in the ledger, mark a close time one second greater than the previous ledger, and (if it keeps happening) raise the close time resolution to make it more likely they'll agree.

If validators consistently do agree on the close time and the close time resolution hasn't reached the minimum (10 seconds, I believe) it will decrease until it reaches that minimum.


I upgraded bitcoind to 0.8 from 0.7, may I delete the old blocks? Upgrading to 0.8 from 0.7 I noticed the old blk*.dat files were untouched, while it was created a new directory called blocks/.

I guess I can delete the old blk*.dat files? Is there something else I'm supposed to delete?

Yes, if you don't plan on switching back to the old version you can delete the old blk*.dat files.

The final 0.8 release will include this little script to tidy your data directory:
https://github.com/bitcoin/bitcoin/blob/master/contrib/tidy_datadir.sh


How do I install a second independent C-lightning node on the same machine as one with an already operational node? I have followed the steps to install a C-lightning node on my Ubuntu machine.  I wanted to know if I could install configure and make a second node on the same machine where both could run in tandem?

Unless you want to test multiple versions of the lightningd binary, there is no need to check the source code out multiple times, since the binaries can be shared among multiple instances.

Assuming you are in the root directory of the source code, and you've executed ./configure and make, you can start multiple instances like this:

$ lightningd/lightningd --log-level=debug \
                        --lightning-dir=/path/to/lightning-dir1 \
                        --addr=0.0.0.0:1111 &

$ lightningd/lightningd --log-level=debug \
                        --lightning-dir=/path/to/lightning-dir2 \
                        --addr=0.0.0.0:2222 &

$ lightningd/lightningd --log-level=debug \
                        --lightning-dir=/path/to/lightning-dir3
                        --addr=0.0.0.0:3333 &

Each of these commands will start a new node with its own directory and with its own port.

Notice that you'll also need to tell lightning-cli where to find the various instances you're trying to talk to. For example the following will run the help command on the second instance:

$ lightning-cli --lightning-dir=/path/to/lightning-dir2 help

I usually will set up a couple of aliases for each instance that I run:

alias lcli1="lightning-cli --lightning-dir=/path/to/lightning-dir1"
alias lcli2="lightning-cli --lightning-dir=/path/to/lightning-dir2"
alias lcli3="lightning-cli --lightning-dir=/path/to/lightning-dir3"

Then you can just use lcli1 help to talk to the first instance.

If you'd like to run multiple versions, the procedure is identical, with the key difference that you need to compile and run these in the source code directory of the corresponding version that you are trying to run.


How to spend an UTXO P2SH pay-to-script-hash Anyone knows specific instructions on how to claim an unspent P2SH TX (pay-to-script-hash) based on a redeem script? No multisig.

I am looking for node.js JS instructions in bitcore-lib or similar.

Any suggestions or help appreciated.

Thanks :)

edited:

How to spend the output depends on the redeemscript. You have to provide a scriptSig that makes the script evaluate to True. More info on the wiki

If there are no signatures involved you can try to repeat the scriptSig that was revealed, although I doubt that would work as there are bots that do that automatically.


Recover Bitcoin Wallet info I sent some (worth around 1000usd) bitcoins to one of my wallets and doesn't remember which wallet it was. Now I'm checking wallet and seeing balance is still there. Can somebody tell me how do I see wallet information using wallet address (3CGphwQHf5QvK6dMrLcLQvQNCuBsc85T5k) or wallet name(1fac700f695d9d63).

You cannot determine the software used to create an address wallet, and this is by design. Anything else would be a serious security flaw: everyone you transact with would be given information about how you store your bitcoin.

  wallet name(1fac700f695d9d63)

I assume this comes from an explorer site like OXT. If so, then it is simply an index created by their system to group transactions according to certain heuristics, it does not provide any info about the wallet software used in the first place.

I hope you are able to locate your coins, but the information you’ve provided is not sufficient to do so. Best of luck.


Building on Ubuntu 16, missing SSL during ./configure I am trying to build bitcoind on Ubuntu 16 64-bit. I have installed the dependencies and have built it fine many times on other machines.

During ./configure, I am getting

checking whether the Boost::Unit_Test_Framework library is available... yes
checking for dynamic linked boost test... yes
checking for mismatched boost c++11 scoped enums... ok
checking for SSL... no
configure: error: openssl  not found.

I have run sudo apt-get install libssl-dev and tried it, also tried brew install openssl, still no dice.

Before, I was getting a missing pkg-config at this point, even though I had installed it. I installed pkgconf and also installed it via brew, and now it's complaining about openssl, which is definitely installed.

$ which openssl
/usr/bin/openssl

Any ideas? Frankly, I'm stumped.

UPDATE:

I built openssl from source, now I'm getting this:

checking for mismatched boost c++11 scoped enums... ok
checking for SSL... yes
checking for CRYPTO... yes
checking for EVENT... no
configure: error: libevent not found.

I'm not sure what is going on... it seems it cannot find packages installed via apt-get for some reason.

I fixed the issue by installing extra libraries, the whole list

sudo apt-get install -y autoconf g++ make openssl libssl-dev libcurl4-openssl-dev

sudo apt-get install -y libcurl4-openssl-dev pkg-config

sudo apt-get install -y libsasl2-dev

Source: https://github.com/mongodb/mongo-php-driver/issues/138#issuecomment-184749966


Tracking Hash/sec of major pools and individual (solo) miners I'd like to get a list of the hash power of the major pools, solo miners, and if applicable undocumented hash networks.  How can I obtain this information?

If this information already exists, how did that site or service collect that information?

How about http://blockorigin.pfoe.be which aims to provide a reliable source of information by scraping pool web sites to see which pool claims ownership of each and every block (hence avoiding the problem that Peter Wuille mentions).

See https://bitcointalk.org/index.php?topic=78391.0 for discussion.


ScriptSig field during P2PKH transaction signature In P2PKH transactions, the content after signing the transaction contains: <signature(with hash_flag)><public_key>. However, since the signature can't sign itself, during the signature process the ScripSig field is temporarily set to a certain value.

According to the accepted answer from How to redeem a basic Tx?, the field is temporarily set with the ScriptPubKey field from the UTXO we want to redeem (in this case a P2PKH ScriptPubKey with the RIPEMD160 of the previous address). However, according to VButerin's pybitcointools, the field is set with a P2PKH ScriptPubKey with the RIPEMD160 of your own address (the one you are using as a source, and which private key will be used to sign the transaction).

I used pybitcointools signing function several times, and the generated transactions are valid, but the answer from the aforementioned question has been well received, so at this point I'm quite confused about what the field should contain.

According to the accepted answer from How to redeem a basic Tx?, the field is temporarily set with the ScriptPubKey field from the UTXO we want to redeem (in this case a P2PKH ScriptPubKey with the RIPEMD160 of the previous address). However, according to VButerin's pybitcointools, the field is set with a P2PKH ScriptPubKey with the RIPEMD160 of your own address (the one you are using as a source, and which private key will be used to sign the transaction).

You're saying the same thing twice here.

A transaction T1 existed with an output T1:0 which has a scriptPubKey P2PKH(K1). This is the transaction that credited you. It resulted in the creation of a UTXO with script P2PKH(K1), and your own key is K1.

You're trying to create a transaction T2 with as input T1:0 and an output T2:0 with scriptPubKey P2PKH(K2). This is the spending transaction, which you're signing for with K1. It sends money to K2, but consumes the UTXO T1:0 which has script P2PKH(K1).


Strange LockTime values in Electrum transactions? Electrum includes a locktime in all transactions by default.

Usually the value is equal to the current block height, eg 592918, however it sometimes drops perhaps 20 or so blocks.

What is going on here?

The locktime value is deliberately set to discourage a subtle attack known as "Fee sniping" and randomly set to an earlier block height to improve privacy (eg for CoinJoin users that need more setup time).

This is also done in Bitcoin Core with the nLockTime.


Does a bitcoin exchange transfers my bitcoins to a "temporary address" when an order is placed (and not yet executed)? I am using a digital currency exchange platform to swap between cryptos (Bitfinex, although the specific Exchange shouldn't matter I guess) and noticed something that I wanted to confirm. I started by transferring some Zcash from my desktop wallet to my "Exchange Wallet" on Bitfinex (the t-addr was generated using Bitfinex's "Deposit" functionality). When the transfer was confirmed and my Total Balance showed the correct amount, I placed an order to swap all of the Zcash for Bitcoins; the order is still active (not executed nor canceled). I then incidentally checked my balance on explorer.zcha.in and noticed it was zero, even though the order has not yet being executed. Indeed, by exploring the chain itself I found an actual transfer of my Zcash to another t-addr, with the corresponding transaction being inserted on a block and mined. The questions/comments are:

1) Does the Exchange (to avoid double spending?) temporarily transfer the money to an escrow t-addr until the order is executed? (And when that happens it both clears my Zcash Balance and increments my Bitcoins balance I assume).

2) If the order is indeed executed, I am assuming the Exchange does a second transfer, this time sending the Zcash from the escrow t-addr to the buyer's t-addr. This means two transactions on the chain for a successful trade.

3) On the other hand, if I cancel the order I assume the Exchange transfers the Zcash back to my t-addr, creating another transaction on the chain that needs to be mined. Similarly, if I instead modify the order (price or amount) does the Exchange need to refund my Zcash first, and then do another "escrow transfer" with the updated order parameters? (meaning additional transactions on the chain).

4) Item "3" above implies that several modifications in a given order will create many transactions back-and-forth the chain which need to get mined. Do these "pseudo-transactions" require a fee as well? Also, if I end up canceling the order after several order modifications, will I have generated some "useless" work on the chain for the sole purpose of speculative trading?

Is this the way Exchanges actually work? If so, is there a (safe) way this type of control can be done without creating various transactions which are not "real transactions" in a sense?

Hope the question is not confusing, thank you for any help.

I don't have any specific knowledge about Bitfinex, but I doubt that it works that way.

The most straighforward way to run an exchange is to pool all customer deposits.  When you make a deposit (to a "t-addr"), the exchange credits your account (in their internal books), and the coins in that address are considered part of the "pool" and no longer have anything to do with you specifically.  They're not "escrowed" in any way; they literally belong to the exchange now, and you have to trust that the corresponding credit in your account will be paid out by the exchange upon your demand.  And there's no need to move coins gratuitously to avoid double spending; it wouldn't help.

Any external transfers that have to be made from the pool (customer withdrawals, moves to cold storage, Bitfinex extracting their earned fees, etc) are made from arbitrarily selected pool addresses.  Trades that take place on the exchange can be done just by crediting and debiting the internal accounts of the customers involved, and typically would not provoke any external transactions, neither in cryptocurrencies (on the blockchains) nor in fiat (in actual bank accounts), until one of the customers wants to make a withdrawal.  That would just be a needless expense in (external) transaction fees.

I suspect the blockchain transaction you saw around the time of your trade was just a coincidence, meaning only that the exchange needed to move funds for some reason (as described above) and happened to choose "your" address for that purpose.


Query unspent outputs for arbitrary address Is there a way to query all unspent outputs for an arbitrary address (which I don't have the private key for), without resorting to a third party service (like Blockchain.info).

bitcoind apparently only lets you do that with addresses that belong to your wallet, even though it internally maintains the list of all unspent transaction outputs.

They're planning to add 'watch-only addresses' to bitcoind; https://github.com/bitcoin/bitcoin/pull/4045

this is already the 4th pull request, they've been working on it for a long time, should be getting into the next version or something I'd guess

once that is in you can get this kind of data out of the basic wallet, until then you'll need to use a blockexplorer or a 'better' wallet (eg Armory) that supports watch-only addresses.


What does "NODE_WITNESS (12)" mean as it is shown in bitnodes.21.co? I'm running a pruned full node of bitcoin core version 0.14.0 and checking on https://bitnodes.21.co/nodes/ I can see that my node was labelled "NODE_WITNESS (12)" unlike of the others nodes shown, which was labelled "NODE_WITNESS (13)".

I've looked through several pages on bitnodes to find some more nodes that show NODE_WITNESS (12). I've noticed a pattern: the number corresponds to the services that a node offers. Nodes advertise the services that they offer by sending a bitmap named nServices. The number in the brackets matches the decimal representation of the service bits that a node has set.

Looking around a bit, I've identified the following five bits:

NODE_NETWORK (1)
NODE_GETUTXOS (2)
NODE_BLOOM (4)
NODE_WITNESS (8)
NODE_XTHIN (16)

So, I'd say that with (12), you must be offering the services NODE_BLOOM, NODE_WITNESS (12), lemme guess, you run a pruning node? :) Or would it be "blocksonly"?

Edit: Here are the service bits defined in the source code: protocol.h:249


Go to the previous wallet address ￼The computer reinstalled the system, and then downloaded the bitcoin core again. I forgot my wallet, and then the exchange transferred the previous wallet address. Can I still retrieve it?

It's not possible to recover your coins unless you have a backup of the wallet.dat file. If you had a notable amount of coins, you can try using a file recovery software, although I believe they can't recognize wallet files.