What are the chances of getting duplicate wallet using bitcoinlib in python3? I am using bitcoinlib in python to create bitcoin wallet as shown here. My question is that how random private keys are which are generated by bitcoinlib?

For example Alice has private key '5ThisIsMyPrivateKey' which was created by some other program (bitcoin core, coinbase, hitbtc or anyone) and I am using bitcoinlib and I have a wallet for Bob and Bob's private key generated by bitcoinlib can be '5ThisIsMyPrivateKey'? What is possibility of it?

Another question is that is there a possibility of having same public key of two or more private key? I have seen lots of different private key structure when I was looking for information and I found three of examples where private keys starts with "5", "K" and "L" so is it possible that same public address can be created by using either of private key version?

I am still new here at encryption and bitcoin and I am just looking for information.

Thanks for your time.

When you create a private key, this process is (or at least should be) completely random - meaning that in theory, the probability of creating some specific private key is 1/N where N is the number of possible private keys. There's nothing stopping someone from creating an already created private key, except chance.

A private key is made up of 256 completely random bits. Thus, the number of possible private keys is 2^256 (approximately 10^77) and the chance of getting a certain exact private key is 10^-77. It's hard to overstate how tiny this probability is - for example, it's roughly equal to the number of hydrogen atoms in the observable universe. We can treat this probability as essentially 0.

  is there a possibility of having same public key of two or more private key?

Yes, absolutely. There is nothing preventing two private keys from being associated with the same public key - however, the only way of finding such a case would be through brute force (generating keys until you find a pair that match, and as we learnt above bruteforcing 256 bits is essentially impossible. Even doing a birthday attack - where you generate keys until ANY two of the generated match, you will still have to create 10^38 keys before a 50% chance of collision.

Also, if by public key you are referring to bitcoin addresses, then this can very easily be mathematically proven to be true by the pigeonhole principle. There are 2^256 possible private keys but only 2^160 possible addresses - so it's impossible to have each private key generate a unique address.


What is the motivation behind Russell Yanofsky's work to separate Bitcoin Core into independent node, wallet and GUI processes? What is the motivation behind Russell Yanofsky's work to separate Bitcoin Core into independent node, wallet and GUI processes? What are the advantages to process separation?

There are benefits to both users and developers to having Bitcoin Core split into separate node, wallet and GUI processes.
As Alyssa Hertig outlines here the benefit to users will be being able to run the Bitcoin Core node on a different machine to the Bitcoin Core wallet rather than being forced to run them on the same machine. A user could leave a node running continuously in the background but start and stop the wallet and the GUI as needed. It also opens up the prospect of using a different (i.e. not the Bitcoin Core) GUI or wallet with the Bitcoin Core node.
For Bitcoin Core developers, Yanofsky highlights maintainability and security as the key advantages.
Process separation will make Bitcoin Core more easily maintainable as it defines interfaces at process boundaries. Different parts of the code can interact by calling each other instead of sharing state. This helps code review by making it easier to identify dependencies between parts of the code. Defining boundaries in the codebase will also make code review more scalable as reviewers will just need to understand part of the codebase well rather than needing to understand interdependencies across the whole codebase.
From a security perspective, the wallet and node code could run with different privileges and vulnerabilities should be harder to exploit given they will be limited to a single process. Inter-process communication (IPC) makes new debugging tools available such as the IPC_DEBUG environment variable to log all IPC calls.
There are some potential disadvantages that Yanofsky highlights. Inter-process communication is generally slower. IPC code can be tricky to write and may have bugs. Bad interfaces and unnecessary layers of abstraction can make it harder to implement new features. Features such as SPV (Simplified Payment Verification) that cross process boundaries will likely be more difficult to build.
[edit: ariard contends that the ZeroMQ library makes it relatively easy to write IPC code. He also argues that clean interfaces don't make it harder to implement new features (e.g. SPV) compared to bloated code as a single process.]
Overall it seems clear the advantages outweigh the disadvantages. At the time of writing (August 2020) there are four remaining PRs to be reviewed and merged into Bitcoin Core and then Bitcoin Core should be multiprocess!
For more details on the process separation project see here.
You can install multiprocess Bitcoin Core using these instructions with debugging guidance here.


Should we wait 10 minutes to confirm a transaction I have read this proof of work calculation takes about 10 minutes. That mean people who are making the transaction should wait 10 minutes ?

Let's imagine i want to buy a drink with bitcoin. The waiter should wait 10 minutes to be sure the transaction is okay before giving me a beer ?

Thanks

Yes, you need to wait, because the tx fee is too low, it won't be mined ever, so the transaction will be refused.

BUT if you're using the lightning network, you can create instant transactions. You can read more about lightning.

If you're dealing with tons of money, recommended to wait for 6+ block confirmation, because a strong miner can rebuild the last piece of the blockchain (this is almost impossible)


If I invest £2,000 in bitcoin and the price goes down, can I lose more than my investment. Could i Have to sell my house to pay back the losses? If I invest in Bitcoin is it possible to lose more than my initial investment ?
In other words if the price goes down substantially, to well below that of when I initially invested; is it possible that I might be sent a bill for the further losses ? Could I be sued for Bitcoin losses ?
I might be prepared to risk an investment if all I can lose is that investment, however I may not be prepared to make an investment if there is a risk, however seemingly small at the moment, that Bitcoin investors may be sued or expected to sell their house to pay off Bitcoin debts in the future.

...if the price goes down substantially, to well below that of when I initially invested; is it possible that I might be sent a bill for the further losses ?

No.

If the price of a bitcoin dropped to $0, you would lose your entire investment, but no more than that.

Think of it like buying gold: if the price of gold dropped to zero, you would now just own some worthless metal. You wouldn't owe anyone money, you would simply have lost the capital you used to buy the gold in the first place.

The only way you are going to owe more money than your investment is through some external factor. As an example, if you took out a loan to buy bitcoin, and then owed interest on the loan. But that debt would be owed to whoever lent you the money.


Why more threads reduce h/s rate? I have dual xeon processors (total 48 cores). I am using cpuminer-easy with nicehash pool on fedora. I have noticed that if i keep my number of threads greater than 10, the h/s falls dramatically. I am using Cryptonight algorithm. For 40 threads, i get 2-3h/s per thread while with 10 threads i get 25 -30h/s per thread. What is wrong here? How can i utilize all cores?

The E7-4830v3 has 10 physical cores and 20MB of L3 cache. With two CPUs, you'd only have 20 physical cores and 40MB of L3. Since every thread is doing exactly the same thing, hyper-threading is virtually useless. It wouldn't help you anyway since you only have 2MiB per physical core and that's exactly what cryptonight requires.

So, short answer, with 40MB of L3 cache, you cannot run more than 20 instances of the cryptonight algorithm concurrently without dropping from L3 speed to RAM speed, which is a huge performance loss.

You can probably go higher than 10, but more than 20 is a non-starter.


Should I use Electrum Wallet OR Bitcoin Core as my website's payment gateway? I'm a developer who is building a website that need to process Bitcoin payment requests. So I need a payment gateway.

In my last project, I used Electrum wallet as payment gateway but my last project doesn't have too much bitcoin payment requests, and electrum works fine.
But I'm afraid of electrum's limitations and I'm not sure it's a good idea to use electrum when processing lots of payment requests.

Bitcoin Core runs bitcoin node but it takes too much disk space (full node) or CPU usage (prune mode) and I'm afraid it's not a good idea too.

So please tell me which one preforms better as a website's payment gateway, and why. Thank you all for answering.

I use Coinbase commerce as a solution for Bitcoin payments on my website. I like them because the fees are very low and the API is very stable.


What can I do if I suspect that my Mycelium word list backup has been compromised? When creating a backup with the Mycelium app, it gives me a list of 12 words which are used as some form of seed which I am supposed to write down and store in a safe place. Anyone with access to this word list can access any current and future funds in the wallet.

Well, what if my safe place gets compromised and the list of words stolen - can I somehow cancel the backup and generate a new one? Or would I need to set up a new wallet and transfer my funds there and just abandon the old one?

There is no way to cancel the backup. Also you cannot be sure if it is comprised until the person actually spends the funds.

Transfer the funds to a new wallet
Diversify risk: Don't but all funds in one wallet !


How can a deterministic wallet have one private key but multiple public keys If we take for example bread wallet.

There is one mnemonic to remember, which means one private key?

But when you use the app, your public address constantly changes.

So more than one public key?

How is this possible?

No, there is not one private key. There is one Master private key. The master private key is then used to generate more private keys in a deterministic fashion, i.e. using the same master private key, you will generate the same private keys. Those private keys are what are actually used in your wallet. Their public keys are generated and the addressees calculated from there.

The mnemonic is an encoding for a seed value. That seed is then converted into the master private key. The specification for the mnemonic generation and conversion is BIP 39. Deriving private keys from a master private key is specified in BIP 32.


listtransactions returning duplicate transactions with category "Send" & "Received" both I am facing serious problem in listtransactions call. I am getting duplicate transactions with "send" and "Received" category. For I have sent some bitcoins from 31zeoskE8zeyQARFEVzwJzsp7GQpLn5zhF to 13MwqVWaNjad4xbGV5WQPaPVcMekU5YJmB. And when I call listtransactions, I get this output,

    {
    "involvesWatchonly" : true,
    "account" : "",
    "address" : "3Ft9W7HfXeBMwuwcfehV9UPs5gnxbc7Wji",
    "category" : "receive",
    "amount" : 0.00019000,
    "vout" : 1,
    "confirmations" : 20,
    "blockhash" : "0000000000000000007f43360b2d7005c8f25013647359d468b8c2ef281672ab",
    "blockindex" : 438,
    "blocktime" : 1437928178,
    "txid" : "eb0f12741947a3be8fdbb15c0401a663e45bd0c68b317b58f250fbb3a698e5fa",
    "walletconflicts" : [
    ],
    "time" : 1437928101,
    "timereceived" : 1437928101
},
{
    "involvesWatchonly" : true,
    "account" : "",
    "address" : "31zeoskE8zeyQARFEVzwJzsp7GQpLn5zhF",
    "category" : "receive",
    "amount" : 0.00010000,
    "vout" : 0,
    "confirmations" : 20,
    "blockhash" : "0000000000000000007f43360b2d7005c8f25013647359d468b8c2ef281672ab",
    "blockindex" : 438,
    "blocktime" : 1437928178,
    "txid" : "eb0f12741947a3be8fdbb15c0401a663e45bd0c68b317b58f250fbb3a698e5fa",
    "walletconflicts" : [
    ],
    "time" : 1437928101,
    "timereceived" : 1437928101
},
{
    "involvesWatchonly" : true,
    "account" : "",
    "address" : "3Ft9W7HfXeBMwuwcfehV9UPs5gnxbc7Wji",
    "category" : "send",
    "amount" : -0.00019000,
    "vout" : 1,
    "fee" : -0.00010000,
    "confirmations" : 20,
    "blockhash" : "0000000000000000007f43360b2d7005c8f25013647359d468b8c2ef281672ab",
    "blockindex" : 438,
    "blocktime" : 1437928178,
    "txid" : "eb0f12741947a3be8fdbb15c0401a663e45bd0c68b317b58f250fbb3a698e5fa",
    "walletconflicts" : [
    ],
    "time" : 1437928101,
    "timereceived" : 1437928101
},
{
    "involvesWatchonly" : true,
    "account" : "",
    "address" : "31zeoskE8zeyQARFEVzwJzsp7GQpLn5zhF",
    "category" : "send",
    "amount" : -0.00010000,
    "vout" : 0,
    "fee" : -0.00010000,
    "confirmations" : 20,
    "blockhash" : "0000000000000000007f43360b2d7005c8f25013647359d468b8c2ef281672ab",
    "blockindex" : 438,
    "blocktime" : 1437928178,
    "txid" : "eb0f12741947a3be8fdbb15c0401a663e45bd0c68b317b58f250fbb3a698e5fa",
    "walletconflicts" : [
    ],
    "time" : 1437928101,
    "timereceived" : 1437928101
}

Why I am getting duplicate transactions in this output! ?

Any Help will be appreciated, Thanks

One is showing your send, the other is showing your receipt.  Without seeing both entries your accounting would not add up!


Which values are GetValueIn() and GetValueOut() calculate? In Transaction.cpp, there is a function CAmount CTransaction::GetValueOut() const.
In Coins.cpp, there is a function CAmount CCoinsViewCache::GetValueIn(const CTransaction& tx) const.
My understand the GetValueIn() is calculater all vin value for a Tx.
But what the GetValueOut() calculate - all vout for a Tx?

But what the GetValueOut() calculate - all vout for a Tx?

Yes, it calculates the total value of all the outputs in the transaction. It also makes sure that the value is not out of range of the total supply of Bitcoin (21M).


What PSU to use with antminer s7 I'm planning to buy myself a Bitmain Antminer S7 Batch 9.

Unfortunately, the Bitmain PSU (APW3-12-1600-B2) is not available to me, and I need to replace it with a regular PSU from another shop.

I think S7 needs a 9 6pin PCI-E connector. I haven't seen a 9 6pin PSU ever.

Which PSU could power my S7?

You need 9X of the 6-pin PCI-e connections to make this work with your miner.  You need about 1350 watts for this to account for the ±10% requirements for nominal running, perhaps more if you plan to overclock it.  They also say not to run it with more than one PSU per board, that may be tricky, because I would have normally said to perhaps get a three CX750s to run or perhaps my juggernaut Evo 1500ewt. If you’re interested I’ve got a couple laying around.  Despite that… you would still need another one as my own PSU only has six available 20A connections.

As @murch points out, if you have 1300 watts per device that means you have at least 450 with zero headroom. So if you split it, you need at least 500 watts with the proper headroom without considering overclocking all the way.


How do people know how to construct the OPCodes? The scriptSig is:

    OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
    OP_EQUALVERIFY OP_CHECKSIG

How did people know that this was the correct permutation of OPCodes and data?

Bitcoin Script is a programming language. As such, it is similar to other languages - You need to know what you are trying to achieve to be able to write in it.

The script you've presented is a P2PKH (pay-to-pubkey-hash) script. The goal here is to allow someone to spend Bitcoin with the corresponding private key by applying a signature. In this kind of verification, you take the input pubkey, duplicate it (OP_DUP), hash160 the duplicate (OP_HASH160), push the hashed value, check if the value you created in the first two operations matches the one you just pushed (OP_EQUALVERIFY), and finally check the signature against the original, pre-dup pubkey (OP_CHECKSIG)

Since Bitcoin Script is a stack based language, it looks a little different to the day to day ones we see (Python, Java, etc). However, it is just another programming language, and you can write code in it just the same way.

Just for reference, a similar program in a more conventional language would look something like:

verifyInputScript(signature, pubkey, outputscript):
    inputPubkeyHash160 = hash160(pubkey)
    if inputPubkeyHash160 != outputscript.hash160:
        return "Invalid"
    else:
        isSignatureValid = verifySignature(signature, pubkey)
        return isSignatureValid


Does my Bitcoin-Qt wallet backup file have "everything" I need (private key)? Does my Bitcoin-Qt wallet backup file have "everything" I need (private key)?

I mean, is that the file I would copy and store offsite in case my house burns down? Does it have my private key encoded in there?

Your bitcoin.dat file contains your private key(s) as well, however I would suggest you extract them now for the addresses that hold money (if any), if empty then it's not much of a use, unless you accept donations there or have a business set up to that address.

How to extract your private keys for addresses that hold at least some money:

Go to Help > Debug > Console
Unlock your wallet if it is encrypted by calling: walletpassphrase YOURPASSWORD
Call listreceivedbyaddress to get all not-empty addresses
For each of them call the dumpprivkey MYADDRESS
Call walletlock once you're through to lock back your wallet


Can you retrieve funds send to a legacy address created with a Segwit extended private key imported in Mycelium from a Ledger Nano S? I imported a segwit xpub6-key in Mycelium as a watch only address. It only shows address starting with 1 instead of 3, which makes sense. I retrieved a small amount on the legacy address and it shows up in Mycelium and on block explorers.

But as a watch only address, I cannot touch it in Mycelium, but it does not show up in my Ledger applications, as those are only showing the Segwit addresses.

So, is there any way of ever touching that funds again?

I found a lot of comments on sending funds from a non-segwit to segwit address, but nothing on this interesting problem.

I have to add some info:
- when I derive the account extended public key from other wallets but the Ledger-wallets I get an ypub6-address, which is also showing up when I write my mnemonic key in iancoleman.io (mnemonic code converter)
- technically I should not have been able to import a BIP49 public key into a non segwit wallet. Where does the xpub6-key come from in Ledger's system when you use your Segwit account (it shows the correct xpub6-key when I use the legacy account)

I actually discovered the answer:

The answer is described on Reddit: https://www.reddit.com/r/ledgerwallet/comments/7d39pu/legacy_to_segwit_wallet_transfer_nightmare/

But if that answer would ever get lost, a summary:

Apparently segwit xpub addresses are not a good marriage (yet). The Mycelium wallet imports the xpub address which is generated by the Ledger Segwit wallet, but creates legacy addresses from the key. As Mycelium is watch only, you cannot send your funds anymore as the legacy bitcoin address does not show up in a segwit enabled wallet, so you want the private key which signs for the public legacy bitcoin address. That's what you have to do know: find the public key which is hashed into the public bitcoin address.

The public key (not the bitcoin address) is the same for the address which appears as a legacy address and the segwit address. When you choose the right derivation path, you will see the address starting with a 1 and you'll see the public key next to it. That last part, knowing where to look, is not very straight forward foor n00bs like me. That public key corresponds with a segwit address, starting with a 3. And next to the segwit address you'll find the private key. After importing the private key in a wallet like Electrum, you can move your funds to a normal segwit address.

So, Mycelium uses m/44'/0'/0'/x path, which is BIP44, and a SegWit address uses BIP49 (m/49/etc)

If this is about a lot of funds, try to do as much offline as you can, but the advise is to create a new seed for your ledger and transfer all funds from all coins to the new seed. After you've done that, playing around with your private keys from your old seeds does do no harm as the balances are zero (except for that one address)

Now, go and search for a BIP39 tool, like: https://iancoleman.io/bip39/ (you can use it offline as well)

Copy the xpub address you got in the SegWit section of your Ledger Bitcoin wallet and copy the address into the tool. Be sure to select derivation path BIP32! Leave Client at Custom and derivation path at m/0.

Paste your xpub-key in the BIP32 Root Key field. On the bottom of the screen you'll see a list with Derived Addresses.

Go back to your Mycelium install and check which address was used for the transaction (or paste the xpub key into a blockexplorer). In my case it was the first one. On the right side of the Address starting with a 1 is the Public Key. Copy the public key into notepad or gedit or so. The private key part is empty (makes sense, everything we've done is with public keys, no option to derive a priv. key from that!)

Now, delete the Root Key and go to the tab BIP49. Paste your Mnemonic seed in the BIP39 Mnemonic field. Your 24 words in the correct order, separated only by one space, should derive a new address list.

If done correctly, there has to be a public key next to the list of public addresses starting with a 3 which corresponds with the public key you just copied into your gedit! Next to the Pub Key is the Private Key (yay!) and now you can import that key in a wallet supporting importing priv. keys and you can finally send your funds to a new bitcoin address, preferably one which you can reach ;)

In Electrum you can easily import private keys, create a new wallet, select 'import bitcoin addresses or private keys' at the first wizard screen, paste the priv. key and there it is!

Thanks again, user stiVal on Reddit! :)


Is Bitcoin network an Asynchronous network or a synchronous network? Conventional BFT protocols work on weak timing assumptions, and if a faulty primary does not respond or forward a client's request a view change message is initiated by the backup nodes. Therefore, if an adversary delays the messages beyond timeout period, he can affect the network through a DoS attack.  The blocks in Bitcoin Blockchain are also time-stamped, therefore, I just want to confirm that does delay in reaching of any transaction or Block to maximum nodes affect the validity of that transaction/block after any timeout period?

In my understanding it is an asynchronous network: It works over the Internet. The Internet is the biggest asynchrounous network. An adversary cannot delay the transactions effectively if he doesn't control the majority of the hashing power. Therefore without making the asumption of a malicious adversary with that power, your transaction will eventualy be included in the network: the answer to your las question is no, the protocol is asynchronous and it will reach consensus.


Possible optimisation to bitcoin propagation One of the main arguments for not raising the block size in Bitcoin is the fact that larger block size means slower propagation.

The most space consuming section of the Bitcoin block is the data of the transactions. Assuming a large portion of the nodes is full nodes, there is a large redundancy in the block data.

When a miner successfully mines a block, he needs to send it to the other nodes in the network. Many of those nodes already possess most of the transactions data that is included in the block.

Maybe it is better to send a hash of each transaction instead of the data itself. In case the receiving node doesn't have this data, it can request it from the sending node.

This might compress the size of a block by 5-10 times (depending on the size of the hash) and allow significantly larger block size.

My concern would be that in the case where the recipient doesn't have all the transactions, the extra request(s) to get them would end up taking more time than just sending them in the first place.  Miners are scattered all around the world but are likely to be able to pay for fast connections, so I would expect connections between them to have high latency and high bandwidth.  In such a case it's better to preemptively send a larger amount of data (fast because of high bandwidth) than to risk a request/reply round trip (slow because of high latency).

Also, miners pretty often include transactions that they originated, or were sent to them privately, or otherwise have not been broadcast on the peer-to-peer network.  Consider mining pool payouts, nonstandard transactions, low-fee transactions which the miner has agreed to "accelerate", etc.  So I think this extra request protocol would be needed more often than not.

This could be a reasonable optimization for full nodes who are not miners, and thus don't need to receive the block urgently.  They might save some bandwidth this way.  But on the other hand, since they don't need to receive the block urgently, we don't care so  much about them, and it's hard to justify a major p2p protocol change just for this.


How to programmatically send Bitcoins without requiring a local copy of the blockchain? I'm quite new to Bitcoin development! I've seen the documentation about RPC commands, available when you have a local copy of the blockchain.

But I'd like to know if it's possible to create and broadcast send transactions on the Bitcoin network without a local copy of the blockchain?

I use Java, but I try to avoid using Bitcoinj. Currently, I try to understand how everything works under the hood. I'm able to create new addresses, with their associated private keys (raw and WIFformats). Those work well!

Using the API provided by blockchain.com, I'm able to get info about those addresses and to know if they have received coins.

The only missing part for me is to find a way to programmatically send some coins from those addresses to other addresses, without a local copy of the blockchain (and using RPC calls on it).

I see blockchain.com also provides a Wallet API but, correct me if I'm wrong, by using this they control the private keys right? I'd prefere a way to send coins by creating and signing the transactions locally and then broadcasting them, by myself... Without a local blockchain.

Is it possible? What are the options?

There is a similar question from 6 years ago with different options and answers Is there a remote, trustless bitcoin API that doesn't require anything (blockchain/SPV headers) to be stored locally?

Otherwise I suppose the options havent changed much, unless maybe the pruning mod which allow you to run a lightweight bitcoin node (550mb instead of 250giga+)


What is the DAO, and what is its connection with Ethereum So the DAO was hacked due to a vulnerability in the way they wrote their smart contract https://blog.ethereum.org/2016/06/17/critical-update-re-dao-vulnerability/

The Ethereum plan is to fork the chain to specifically prevent the attacker from being able to withdraw from the DAO account.

So what is the DAO's connection with Ethereum, and what is its purpose? Why is the operation of the DAO so cruical to warrent a fork? I also see mentions of a company called Slock.it being involved somehow, what was their role in this ordeal?

So what is the DAO's connection with Ethereum, and what is its purpose?

The DAO was a decentralized autonomous organization designed to invest in DAPPs built on Ethereum

Why is the operation of the DAO so crucical to warrant a fork?

Whether a hard fork is warranted is being hotly debated. Ultimately miners will have to make that decision. "Too big to fail" and the sheer amount of money invested in the DAO are some of the most cited reasons by those trying to justify a fork

pro fork:

https://blog.colony.io/an-ethereum-hard-fork-is-not-a-bailout-its-foiling-a-bank-robbery-db2a472fe9e1#.x7rn8026i

anti fork:

https://www.reddit.com/r/ethereum/comments/4oithy/a_too_big_to_fail_political_hard_fork_is_very/

I also see mentions of a company called Slock.it being involved somehow, what was their role in this ordeal?

Slock.it designed the code theDAO is built on and was likely to be one the largest recipients of theDAO investment


How to check testnet address balance I have an address mpc1rKeaMSCuQnJevMViLuq8uWjHwgdjiV
I check it via json rpc and get balance = 4.6 with 6 confirmations
When I check http://blockexplorer.com/testnet/address/mpc1rKeaMSCuQnJevMViLuq8uWjHwgdjiV
I get nothing.. is it OK ?

The testnet Block Explorer doesn't seem to be working. If you go to http://blockexplorer.com/testnet, the most recent block it shows is from August 29, about two weeks ago.


Are public keys included in signatures? I can't easily and quickly determine from these wiki pages, 1 and 2, if the public key is included in the signed message.

Are public keys included in the signed message, or are they transmitted alongside the signatures, external to the signed message?

There are two answers to your question.

For a signed message, you can recover the public key if you have both the signature and the message that was used to create the signature.  The algorithm actually returns four possible keys, so the signature includes a header byte to identify which of the four should be used.  This is possible because we know which curve (secp256k1) is used by Bitcoin when it generates the signature.  If you want to see how this is done, look at recoverFromSignature() here

For a transaction, the public key is provided in the input script, the output script or a hashed script.  In the case of a multi-sig transaction, there are multiple signatures and multiple public keys.  There are also multiple ways to sign a transaction as determined by the signature hash type (a control byte added to the end of the signature).  If you want to see how this is done, look at checkSig() here


Calculating Different Investments altogether? Bitcoin was my first dive into investing.

I am trying to see how much I made and how well I did.

I am getting a problem however where I bought multiple times at different periods and prices.

What's the standard way to calculate how well I did when each order was at different prices and etc?

So for example:

if I bought X BTC with Y USD at time t0
and Z BTC with Y USD at time1

How would I calculate my return and profits?

The simplest way to calculate would be:

averagecost = ((BTC[t0] x USD[t0]) + (BTC[t1] x USD[t1]) + (so on))/total_BTC

where t0,t1 and so on are different time when you bought.

The above gives you the average cost for all your BTC

Now to know the profit, use the below formula:

profitloss = (current_BTC_price - averagecost) x total_BTC

If profitloss is negative, then you have a loss.

If profitloss is positive, then you have a profit.


How to link a bitcoin address to a wallet address? BitGo has a feature where you can have multiple addresses under a wallet. The wallet also has its own address. Now suppose I have two addresses under my wallet. This means for any user to send me BTC, I can give one out of any three addresses which is 2 addresses + 1 wallet address.

How is that even possible to link two bitcoin addresses?

The wallet is simply a logical separation (or group, in this case). It simply means that multiple keys are kept in the same wallet.

As far as the blockchain is concerned, there is no wallet, just a set of output scripts, controlled by private keys.


Debts denominated in bitcoins I was reading an ebook, called Bitcoins: what they are and how to use them, the book says

  ... it would be a fools bet to take a promise to pay a debt in
  Bitcoins, as they will by definition, become increasingly difficult to
  obtain.

This doesn't make sense to me; just because the number of new Bitcoins being produced will decrease, that doesn't mean they will be harder to obtain, because people can still buy and sell existing bitcoin. The quoted text seem to imply that the value of bitcoin will always go up, or am I missing something?

That is indeed what that author is implying, though I think his conclusion is wrong. Any good currency will increase in value over time, or ideally the money supply will increase at the same rate wealth is added to society, which would imply its value remains constant.

This is distinctly different for instance then the USD which is intentionally being rapidly inflated by the Federal Reserves quantitate easing policy.

Bitcoin does not match the rate of wealth creation, and coins become more difficult over time to acquire, but the same is true of gold and people have been paying debts in gold for centuries. Perhaps its a good thing to be a little foolish.


Get Master Private Key from BIP39 Seed I have BIP39 Seed:

5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570

I want to get Master private Key

Then I Have to use HMAC-SHA512, I can use this site, which secret I have to add ? I don't have any secret, for test  I choose "mnemonic", the same constant that I use to generate BIP39seed (is it correct? )

the result is:

  9744d0d7e168f725b6cc36a73c24dfc91bd6d80bf5a6871ad2c6c0b854e4e281b74049c41d25f0b338b3fc9b053b87b95636c3c94c31f37458fe98a09a4a94c9

and I can get

left 256 bits  => 9744d0d7e168f725b6cc36a73c24dfc91bd6d80bf5a6871ad2c6c0b854e4e281
right 256 bits  => b74049c41d25f0b338b3fc9b053b87b95636c3c94c31f37458fe98a09a4a94c9

And I can Get master private key in this way?

PKM = bx ec-to-wif 9744d0d7e168f725b6cc36a73c24dfc91bd6d80bf5a6871ad2c6c0b854e4e281

  result:
  L2Hku6wzwvWnHAct8TmtfvviE4QXBTXtZrae2buXwjq5mRG4doF2

but this result is not in https://iancoleman.io/bip39/ If I import my mnemonic phrase

  (army van defense carry jealous true garbage claim echo media make crunch)

Here are the mechanics for "Mastering Bitcoin" Creating an HD Wallet from the Seed using  bitcoin-explorer and this Python HMAC command.

Root Seed:

% echo "army van defense carry jealous true garbage claim echo media make crunch" | bx mnemonic-to-seed -p ""

5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570

Master Private Key:

% echo 5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570 | bx base16-decode | hmac --algorithm sha512 --key "Bitcoin seed" - | cut -c 1-64

b2a0d576b828b537688b561f2cfa8dac3602d54c62bde619ad5331e6c235ee26

Master Public Key:

% echo 5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570 | bx base16-decode | hmac --algorithm sha512 --key "Bitcoin seed" - | cut -c 1-64 | bx ec-to-public

03ca72b45eede592f059b7eaf3da13eb7d8d15aa472b6f79f74820bb22ff596186

Chain Code:

% echo 5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570 | bx base16-decode | hmac --algorithm sha512 --key "Bitcoin seed" - | cut -c 65-128

b70d675323c40ec461e0a6af603b1f135fb2af9ae753eeff18922732a73b0f05


How exactly does MyWallet's Android client work? When I create an account via my desktop browser, I am assured that the password only exists on my browser, and is not saved.

So, if I "pair" an Android device with MyWallet, can or can't I send BTC without entering the password?

How does this work with/without a secondary password? What if I first installed the Android app, and only then created a secondary password?

Are the files on my Android device / Dropbox encrypted with my first password? My second password? Both?

I think when you scan the QR code, your password is encoded in that barcode, so your Android phone stores it locally.

I haven't tested it myself, but considering this I think you have to enter the secondary password to your Android phone as well. It will either require you to do it every time you make a transaction or remember it for you.


Can Bitcoin Diamond be claimed on Segwit addresses? I currently have my Bitcoin (BTC) on a Trezor hardware wallet with Segwit (Not in a "Legacy account").

Can I claim Bitcoin Diamond (BCD) with this or not?

In general: Should I move my BTC to a Legacy account to be more compatible with future forks?

Bitcoin Diamond does support segwit, so it is possible to claim it. However, it may not be possible to (safely) do it directly from the trezor.

There is apparently an Electrum for Bitcoin Diamond, which claims to support hardware wallets. However, I have never used it, and would be hesitant to trust it to not send the coins to its own address (maybe even from other chains).

If you really do want to claim it, I would suggest:

Move all coins from the trezor, for all chains, to a temp. wallet
Reset the trezor to get a new seed
Send all coins back
Use the old seed to derive your keys using a BIP39 tool, such as https://iancoleman.io/bip39/
Import the required keys into the core client for Bitcoin Diamond, and sweep them.


Trustworthy url address for bitcoin download? I would like to download install some bitcoin software and create a wallet. I know there are some programs like Bitcoin-QT or Multibit. There are more sources to download these programs. I want to be sure, I downloaded the right one.

Which software from which url is trustworthy? Can I check the checksum of the downloaded installer of specific version against some MD5 from a list somewhere, that it is safe?

http://bitcoin.org/en/download is the official download page for bitcoin-qt, it is the oldest client, the most trustworthy and it is the client I would recommend for a beginner.

The same client can also be downloaded from the Bitcoin Core website, here: https://bitcoincore.org/en/download/


Multisig synchronization I understand what the multisig wallets are but I need help understanding what exactly this script does:
https://gist.github.com/gavinandresen/3882537
If I understand correctly, bitcoinds are bitcoin daemons but I'm not sure what daemons should be used in this script and how it all works.

I'm not sure what daemons should be used in this script and ...

You first run two bitcoind daemons locally and then specify their ports as arguments to the command along with other information such as authentication credentials:
# Example usage:
#  multisigsync.py \
   --connect1=http://abc:123@127.0.0.1:9000 \
   --connect2=http://abc:123@127.0.0.1:9001 \
   2MsrtHjVXGdT7RuTEiUWzec87Cik1rPpmyD

In this example one bitcoind has been configured to listen on port 9000 the other is listening on port 9001
It looks like this should also work with remote bitcoind instances.

... how it all works.

It isn't clear what part you want help with.
The ServiceProxy stuff seems to be described at https://www.jsonrpc.org/archive_json-rpc.org/python-json-rpc.html


Double spend question during fork What happens to a double spend during a fork where one of the transactions are in a orphaned block and the other in the main chain?

2 transactions get broadcasted in the network and 2 conflicting blocks gets mined at the same time. The transaction that gets broadcasted first is for the seller and the second transaction is fraudulent. First transaction gets in the orphaned block and the second transaction goes in a block that becomes part of the main chain.

With the knowledge I have now, I assume the 2nd transaction is considered valid. While the first one gets returned to the memory pool and the pool sees that there is already a transaction in the main chain so it gets dropped. Is this true? And how do the confirmations show up?

Yes, what you wrote is correct.

The number of confirmations a block has is defined as the number of block building on top of it.

The number of confirmations a transaction has is defined as 0 if the transactions is not included in any block and as the number of confirmations the oldest block* (block with the lowest block number; it's not about time) containing it has + 1 otherwise.

You know how many confirmations a block or a transaction has by knowing a (usually "the") longest blockchain has.

* Note that in any blockchain, a transaction is included in at most 1 block but there can be different blockchains and a transaction can be included in blocks having different block numbers in different blockchains.


Why is a full sweep of a cold wallet more secure than a withdrawal? I've seen on This question that you should not make partial withdrawal from a cold storage address; because it could compromise the security of the cold wallet. Can someone explain the related security concerns?

That makes sense to me.

You see, you can generate a wallet completely offline. If so, the private key of that wallet would have never been on a internet-connected computer. That's a safe key.

However, you cannot (as far as I understand) send money without putting the private key of that wallet onto a computer that touches the internet.

Makes sense to completely empty that wallet and create a band new one offline again. Transfer partial money to where ever you want, then transfer the rest to the public key of a new wallet that has never had its private key on an internet-connected computer.


Minimum and maximum values of "all" cryptocurrencies? I can't find a "cryptocurrency" stack exchange, and I have a question that spans all cryptocurrencies, in particular, how to handle them programatically - one database column to rule them "all"!

I say "all", because it's becoming super-hard to keep track of them all, so I don't expect anybody to know the whole story.

So, we want to store an amount in the database - the implication for BTC is that we should store values from 1e-8 to 1e8 - but what about other cryptocurrencies?

I'm looking for a value which would be enough for all of the current mainstream coins, and if possible (fingers crossed!) a rationale why that value would be enough for at least 90% of any future currencies that might appear?

I can't answer for all cryptocurrencies, but for bitcoin, you shoud store values as long and not doubles. The unit of account of bitcoin is the satoshi, a hundred millionth of Bitcoin. Since there can only be 21M BTC ever, that's a maximum of 2.1 quadrillion (2.1 * 10^5) satoshis. That number fits in 64 bits.

For Ethereum, you need 256 bits unsigned integers IIRC.


How is the Max Target of a Genesis Block Decided? I've been diving into the world of Blockchain and crypto lately, trying to build my understanding of mining specifically. I understand that in POW systems, the difficulty of the first block is 1, and the current difficulty can be seen as being "current difficulty multiples harder than the first block" to mine (aka it scales linearly).
What I've been having a hard time figuring out, though, is how the designers of POW systems settled on the maximum target for their first blocks. To quote another stackoverflow answer:

Satoshi decided to use 0x1d00ffff as a difficulty for the genesis block, so the target was 0x00ffff0000000000000000000000000000000000000000000000000000.

This leaves me with a few questions:

Is there a reason to why Satoshi picked this number specifically?
How does this relate to other cryptos?
Is the max target fairly arbitrary so long as the designer is careful not to pick a max target that's too low?
(3b) If so, does the max target not matter in the same way after the first re-target (i.e., after the first 2016 blocks in bitcoin's case)?

My reasoning for asking this question is because when I look at the difficulty charts for cryptocurrencies, I've been curious if they're relatable to one-another, that is, if you could reason that because BTC has a difficulty of X and LTC has a difficulty of Y, you could determine which to mine based on difficulty and block reward alone.

It's important to note that "difficulty" as such doesn't actually exist in the system; it's just a convenient way of representing the target value for human consumption. Internally (and on-chain) only the "target" and "nbits" representation are used.
Furthermore, the actual difficulty for the genesis block doesn't really matter, except for the fact that at least in Bitcoin it also happens to be the maximum permitted target value. And that value is relevant.

We don't know how or why Satoshi picked the specific value of 65535×2208 as maximum target. But perhaps they measured the speed of mining on their own system/implementation, and chose a nice round number (in nbits representation) corresponding to what they estimated would be reasonable for the operational network.

Not sure what you mean. Questions about specific altcoins are off-topic here.

Yes, probably.

Well, in Bitcoin the genesis's difficulty is also the minimum difficulty a block can have, and early on in Bitcoin's history, there were many retarget periods where the difficulty was just 1, because the hashrate wasn't sufficient for a higher difficulty.

My reasoning for asking this question is because when I look at the difficulty charts for cryptocurrencies, I've been curious if they're relatable to one-another, that is, if you could reason that because BTC has a difficulty of X and LTC has a difficulty of Y, you could determine which to mine based on difficulty and block reward alone.

You cannot compare hashrate of unrelated proof-of-work functions. They require separately-designed hardware, so one cannot be converted into another once you get out of the realm of general purpose (CPU & GPU) hardware.


What would happen if SHA256's pre-image or collision resistance would be broken? I'm experimenting with some self study cryptography and I was curious about the two following scenarios (simple answers and/or in relation to bitcoin)

If SHA256 was found to lack pre-image resistance, would it make solving the puzzle easier?

Alternatively, if the algorithm was found to be not collision resistant - would the puzzle again be easier to solve?

Thanks

Any collision resistant hashing function Hk : {0,1}* → {0,1}k is pre-image resistant regarding the uniform distribution on {0,1}2k.

A ⇒ B ⇔ ¬B ⇒ ¬A: I.e. if a function isn't pre-image resistant it is not collision resistant either.

SHA256 is a function that maps a potentially unlimited set of numbers to a smaller set of numbers.

  Hk : {0,1}* → {0,1}k

Collision resistance is a property that loosely says, it is difficult to find two inverse images X ≠ X' that have the same image H(X) = H(X').

More to the point:
A function H is collision resistant, if any algorithm can only find a collision with a negligible probability in probabilistic polynomial time.

I.e. if SHA256 would turn out to not be collision resistant, one could try to pick hashes that would succeed at the current difficulty, use the above predicted inverse function of SHA256 to calculate inverse image candidates, and finally check whether one can satisfy them with the currently available block input.

My gut feeling would be though, that it would be pretty difficult to find inverse images that also satisfy the required structure of the block input, especially getting right the hash of the parent block, and matching an address that one controls for the coinbase transaction.

Unfortunately, I have no idea whether the complexity of that would be greater or smaller than bruteforce mining.


Does FIPS 140-2 crypto certification matter for Bitcoin? I'm implementing part of the Bitcoin client in C# and noticed that I have the choice between FIPS 140-2 and non certified versions of SHA256.  Supposedly both versions give the same hash.

Does the choice of SHA-2 library matter for Bitcoin?  Does the FIPS-2 library exist in Mono and mobile devices?

You should basically never choose FIPS-140 unless you have no choice. FIPS-140 compliance is provided primarily for people who must comply with FIPS-140 for regulatory or policy reasons.

Note that that's not to say FIPS-140 validation is bad. It's great. If it finds bugs or problems, that's a pure win. If you have a choice between an implementation that has been FIPS validated and one that has not, the former is the better choice. But that has nothing to do with whether you enable FIPS-140 modes.

Your implementation has been FIPS validated. Don't brain damage it.


Lightning network without main chain? I've been reading about the working of LN. I had this interesting thought, what if we dont need the main blockchain and the miners to have a p2p cash system. Let me explain.

The difference between the current LN and what I thought is, people have channels only with the people they know and trust. There wont be any multisig wallet(may be set a limit for each channel based on their trust of the other person). And when they wanna close the channel, they transact in real life either with bitcoin or fiat (whatever unit they are using). Since it the people they trust there wont be any cheating problem.

This will be a completely p2p system. Would such system work? Am I missing anything?

You've basically described Ripple (aka XRP). You may want to read up on it - and specifically, criticism of it that can help illuminate why this system does not offer the same benefits that Bitcoin's does.


Moving Bitcoin from Bitcoin Core to another Bitcoin Core or Bitcoin Diamond Before I even begin I'm going to admit that I know it was my fault in the end.

I was part of a community for crypto on a chatting server. I've been a part of it for more than a year. I got to know some people and asked one of the people I knew about getting some help for the following:

I've had a Bitcoin Core Wallet on my desktop from 2016 that I've held my Bitcoin in this whole time. I knew there were waves of up and down to come but I didn't want to sell. Part of being a hodler and thought I had helped the Bitcoin price by just keeping it and not doing anything with it.

Recently I had asked if anyone had experience with forks from a Bitcoin Core Wallet in said chatting community. One of the guys I know said he did and was willing to help. We got on TeamViewer and set everything up for forking. I had my Bitcoin Core Wallet on my desktop that was a bit outdated and a new laptop that I said would be better to put new wallets on for processing wallet nodes faster. We had done the BTG Core Wallet the other day and was going to do the Bitcoin Diamond one. He said that it would have to be a bit different from the Bitcoin Cash and Bitcoin Gold ones we did.

We got on Team Viewer again and I started downloading the Bitcoin Diamond Core Wallet on my laptop. He said it wasn't going to work on the laptop so we needed to connect on my Desktop that has the original Bitcoin Core Wallet. I said I wasn't comfortable with moving any Bitcoins out of the wallet itself and that I wouldn't let him have any control over the session. He said it was fine and would just type on the chat system of what he needed me to do (as usual). He asked that I had the wallet open so he can just look and tell me what to do. After he connected he said he would brb so I waited. After a few minutes, and almost instantly, before I could do anything he had sent a request from my BTC Core Wallet to transfer to an unknown address and clicked the shut down on my computer.

I was still on the laptop and he was in the chat so I just asked why and wanted to know what he did. He said that he "sent it to the BCD addy". I didn't know what he meant so I asked. He said "you need to send it onto the bcdblockchain im pretty sure" and that I should have the Bitcoin Diamond on the Bitcoin Diamond Core Wallet on my laptop. The BTD wallet is not synced and said we had to wait for it to finish (still not finished). After that he appeared offline and hasn't spoken to me from that point (late last night).

My question is this:
potential situation #1: If he did send said BTC to the BTD wallet, what should I do?

potential situation #2: If he sent to the Bitcoin Core wallet on said laptop instead what should I do? That one is also syncing as I put it on in case I had to move wallets, but it looks like he might have put the .dat file on it from desktop wallet (not sure).

Potential situation #3: If he moved it out of said wallet I don't control is there anything I can do? I know I would have to report a theft, but anything else?
thanks in advance

he moved it out of said wallet I don't control

Yes, your helper stole all your money.

  is there anything I can do?

No, report the theft to the police.

Your money is gone forever though.


Delegating the creation of a transaction This question might seem quite strange. but I am wondering if its possible to delegate the creation of a transaction to a third party, without having to trust them with your private key?

In the same way that with credit cards you can preauthorise a transaction, i'm wondering if its mathematically possible to do the same with bit coins. What I'm thinking of is having the client create the transaction, from the private key, and then forward the transaction to, and only to the authorising body. That way they would then hold a cryptographically secure transaction which at a later time if appropriate they could distribute to the rest of the bitcoin network.

so specifically:

Does this leave open the risk of that person double spending the same bitcoin?
Is there a mathematical window between the point when the private key is no longer required, and when the distribution process has begun.  (e.g.  adding it the current block?)
Has anyone solved this already?

Edit for clarity:

The key aspect is the ability for someone other than the person sending the bitcoin to 'hold the transaction' and at a later date to either forget the transaction (so it never left the original wallet) or to distribute the transaction, so it is accepted by the bitchain as having been transferred.

It would be required that the only trust that the sender needs to have is that the transaction holding place is trusted to either distribute or drop the transaction fairly.  In particular that they do not obtain access to transfer additional money later, or different amounts etc..

Yes this is possible, and there are a couple of clients that let you do this out of the box. Electrum is popular for this.

The purpose of the private key is that you are able to "sign" the transaction. Once the transaction has been created and signed actually anybody can broadcast it to the network.

I understand that it is even technically feasible not to use the bitcoin client but recreate a transaction, sign it and broadcast it as a string.

Edit to answer third point also in an edit from the OP: If you are suggesting that you can possibly drop off signed transactions everywhere using the same bitcoins to create a double-spend, you would also have to prevent any one of the recipients from broadcasting. As soon as the transaction is broadcast you can consider that those coins are spent, because a later transaction would be rejected. It is not therefore in the interest of the recipient to hold a transaction for you. The answer is in another function of the original code which allows escrow payments.

Localbitcoins.com operate an escrow process, I couldn't say for sure if they use the original functionality in the bitcoin code or have written it themselves, but essentially it is the same idea. Coins from your unspent balance are set aside and only released when certain conditions are met. This prevents the double-spend because once the coins are in the escrow they cannot be used in another transaction.

I think you ought to have a look at how transactions are actually constructed, as it is not as simple as saying that "I have a balance of n bitcoins and I spend x bitcoins". There is the notion inputs and outputs, spent coins and unspent coins.


Simple, default, "hello world" smart contract for an auction? (winner wins, all the rest gets refunded) I recently read an article: https://medium.com/@jimmysong/the-truth-about-smart-contracts-ae825271811f

  Because of a lot of centralized marketing from Ethereum, there’s a mistaken belief that Smart Contracts only exist in Ethereum. This is not true. Bitcoin has had, from the very beginning in 2009, a pretty extensive smart contract language called Script.

If Bitcoin has smart contracts, I would like to see how to create a simple "hello world" auction - winner wins, those who didn't win get refunded.

(I've heard that RSK is EVM-compatible but that's more involved)

If Bitcoin has smart contracts, I would like to see how to create a simple "hello world" auction - winner wins, those who didn't win get refunded.

Your question isn't clear about the details of how you would expect this to work, so I'll start with some assumptions:

The seller has put something up for auction. There are two possibilities: the item being sold is a digital asset native to the Bitcoin chain, or it is not.
The bidders are placing bids (assumedly using BTC, but any on-chain asset will do I suppose)
The 'auctioneer' that orchestrates all of this is some sort of 'smart contract', that sends the winning bid to the seller, the item sold to the winning bidder, and returns all other bids to the non-winning bidders, if necessary.

So the 'auctioneer' must be some bitcoin script, that is capable of determining the result of the auction. Here we encounter a problem: Bitcoin script does not allow us to create a transaction which considers the status of other transactions in order to determine how the transaction being created can be spent. In other words, you can't use Bitcoin script to create some logic that says "after some time, forward the largest payment sent to auction_address on to seller_address, and return all other payments to back to the non-winning bidders".

The 'smart-contracting' capabilities of Bitcoin Script are intentionally limited, to quote the article you referenced:

  Bitcoin’s solution to this problem is to simply not have Turing-completeness. This makes the contracts easier to analyze as the possible states of the program are easier to enumerate and examine.

All of that said, if we do not expect the entire logic of the auction to fit neatly into a single transaction's script, then we can perhaps use some more 'simple' constructions and protocols to accomplish our goal. For example, see this clever answer by Luke-jr. In this case there is no fancy smart-contract used, just financial incentives (to take the highest bid), coupled with consensus rules (a coin cannot be double-spent). This answer elaborates further on this type of construction.

More broadly, and as mentioned in the article you referenced, the oracle problem is a critical consideration: in order to participate in this auction, do you need to trust any third party? If the answer is yes, then it is prudent to consider if using a smart contract is a reasonable approach to solving your problem. For example, if the item up for auction is not a native digital asset, but is instead physically deliverable, then you need to trust the seller to deliver in any case!

All this isn't to say that Bitcoin script can't be utilized to create a 'better auction experience'. For example, by using a multi-sig constructions, bidders and auction-houses could enjoy a more trust-minimized set up of certifying and transferring funds to be used in the auction. But 'smart contracts' don't just magically enable us to 'make everything trustless', and indeed in many cases such a thing isn't possible anyways.

Additionally, it is possible to create a protocol that includes a Turing-complete language that runs on top of Bitcoin (eg the RSK EVM you mentioned), but this seems to be outside the scope of the question.


How does the network determine whether to replace a transaction? Further to this question, how does the network determine whether to accept a new version of a transaction as a replacement transaction? Could an attacker replace transactions maliciously?

Each node in the network accepts any transactions with a higher sequence field (in TxIn) as long as the transaction isn't locked (lock time hasn't expired).

This can't be used as an attack because the client is aware the transaction is unlocked and thus could be modified.  The client (and thus any merchant) will/should treat the transaction as even less secure than an unconfirmed one.

To protect oneself the merchant just needs to wait until the lock time has expired (then transaction is similar to any other 0-confirm transaction) and for even more security wait for 1 to 6 confirmations.

Currently the client only supports lock time of 0 (lock as soon as created) and sequence of max UINT (no possible higher sequence) which prevents modifying transactions.


How is it possible, that nobody can track anyone on the bitcoin network? Is it possible that a person on the bitcoin network cannot be tracked?

I was studying, no one can track a person on the bitcoin network. Is that true?

Users can be tracked IF they don't follow the best practices. Although lot of on-chain analysis and investigation works on assumptions.
How?

Every transaction on-chain has lot of information associated with it including address, amount, type of transaction etc.
Not every user runs their own full node with tor
Some users share information related to transactions on social media

Best practices:

Use non-kyc non-custodial exchanges
Use full node with tor
Do not share information about transactions on social media
Use coinjoin, payjoin etc.
Do not reuse addresses


Is there a solution to paying high fees when opening and closing lightning channels once we hit a fee only market? Paying several hundred dollars to open and close a lightning channel seems uneconomical. This is a common argument against lightning by big blockers, I’m yet to read a valid argument against this.

'Under the hood' of a lightning network channel open/close, a user will be sending a bitcoin transaction. In order to send a bitcoin transaction, a fee is paid to miners.

One advantage of having a lightning channel is that you can amortize the cost of the miners fee across a potentially enormous number of payments. All else equal, having the ability to transact on the lightning network thus lowers a users expected fees/payment, small blocks or not.

Channel factories are a technology that could allow for immense cost saving for lightning users. So this is potentially a 'solution', in the context of your question.

  Paying several hundred dollars to open and close a lightning channel seems uneconomical. This is a common argument against lightning by big blockers

'Uneconimcal' doesn't seem like the right word to use here. If in the future a bitcoin transaction costs hundreds of dollars in fees, that would mean that the ability to send a bitcoin transaction is in high demand. By many measures, being in high demand is a mark of success, though 'big-blockers' will argue that by increasing the block size the network can increase the 'supply', thus lowering transaction fees.

To illustrate this point, consider the absurdity of this sentence:

"That restaurant has become very popular! Nobody goes there anymore"

So you may ask "Why don't we just increase the size of the restaurant then?"

Well, the issue is that by increasing the size of the restaurant, the restaurant will lose the properties that made it popular in the first place!

So lets return to Bitcoin, to explain why increasing the block size ('making the restaurant larger') is a naïve solution that damages the network's desirable properties, while only providing a rather meagre linear scaling relief:

Implementing larger blocks means that running a full node on the network will be more resource intensive (bandwidth, computational cycles, storage, etc), and so naturally we should expect less nodes will exist due to the increased costs. This is damaging to the core properties of bitcoin (eg censorship resistance), which can only exist when the network is sufficiently decentralized. 'How decentralized is good enough?' is a question that is difficult (if not impossible) to answer, but this much is certain: increasing costs is a centralizing force, and the most conservative approach is to be 'better safe than sorry'. A blockchain network is a very expensive and inefficient way to implement a database, but the core properties mentioned above make these expenses 'worth it', at least according to the market.

In any case, there has never been a time where the average Bitcoin transaction fee is 'hundreds of dollars'... in fact transaction fees have been quite low for the majority of the history of the network. This isn't to say that fees can't or won't increase in the future, but making changes that sacrifice the most important properties of Bitcoin seems like an extremely misguided approach to scaling the network.


Is encryption really needed for blockchain to work? Is it right to say that Bitcoin and other blockchains do not use encryption? I read somewhere that blockchains rely on digital signatures and hash functions but not on encryption, and that encryption is only used on the client side (e.g. crypto wallets)… But it seems that encryption is also part of these other cryptographic techniques… So I’m trying to clarify whether blockchain technology needs encryption or not. Thank you!

Bitcoin does not use encryption, and does not need to in order to secure ownership of coins. Ownership of coins is proven by digitally signing a transaction with the owner's private keys. The signature can be validated by anyone using the owner's public key.

Encryption obfuscates data for anyone that is not authorized to view (decrypt) it. Bitcoin cannot encrypt data that is stored in the blocks because the data needs to be able to be validated by all users (to prevent double spending).

Encryption is used, however in wallets to secure one's private keys, but that depends on the wallet software and how they've chosen to implement this type of protection. For example, Bitcoin Core wallet has a way to encrypt the wallet with a passphrase, see RPC Docs - Encrypt Wallet, but this is not essential for Bitcoin, users can use any wallet application.

Edit: As pointed out in the coments, a point of confustion is that Bitcoin uses Elliptic Curve cryptopgraphy, not RSA. This means that a digital signature in Bitcoin does not use encryption like RSA does, but instead an algorthm called ECDSA.


Are Bitcoin and Litecoin test addresses compatible? It seems to me that they are. I mean you can send test bitcoins to test Litecoin addresses. I don't think it's problem at all, but it can cause some confusion.

Real addresses cannot be mixed, but I managed to send test coins from Litecoin wallet to Bitcoin test wallet. The coins did not come obviously.

Yes, they're interchangeable.

The components of an address are a prefix byte, a 20-byte public key hash (160 bits), and a 4-byte checksum.  Litecoin testnet uses the same prefix byte as Bitcoin testnet (hex 0x6f, decimal 111) and computes the hash and checksum in the same way.  This was arguably not a good decision on the part of the Litecoin developers, but we are sort of stuck with it now (maybe until testnet4).

If you have the private key for the address in your Bitcoin wallet client, it should in principle be possible to export it from there and import it into your Litecoin client (they also both use the same prefix byte for testnet private keys).


Why mark a transaction as RBF (Replace-by-Fee) explicitly? I could broadcast a second transaction that has the same inputs but a higher fee, without marking the original transaction as replaceable. Miners would most likely favor the second transaction and reject the original one. Why should I mark my transactions as replacable if they can always be replaced by broadcasting another conf-0 transaction?

I could broadcast a second transaction that has the same inputs but a higher fee, without marking the original transaction as replaceable.

Default node behaviour is to accept the first-seen transaction into the node's mempool. So your second transaction that spends the same inputs would likely be dropped by most nodes, and thus it would be less reliably broadcast across the network, and therefore be less likely to be included in a block.

Of course, the second transaction could still be included in a block, but this 'first-seen' preference makes it less likely. Even though a miner may prefer the transaction that pays higher fees, if they do not hear about that transaction in the first place then there is no chance of it confirming. An explicit RBF marking allows the user to more reliably broadcast a modified transaction spending the same inputs later.


Localbitcoins history btc_in_usd rate? In 2016 Localbitcoins (LBC) introduced a new stable variable for price equations called btc_in_usd. It was/is based on the rates of the seven most famous exchanges, and LBC calculates a median price from all these sources for btc_in_usd.
Is it possible to fetch history btc_in_usd for my trade, i.e. the rate which was active on LBC at the moment buyer bidded my advertisement? Or just at any point of time.
Thinking from the other side, can I get the price equation for any trade I made, to calculate history rate myself using traded amount?
If it is not possible, maybe I can get history rates from all these exchanges for and calculate this median myself? Are there sources for that?
Thanks in advance.

It's possible to get your price equation via their API:
https://localbitcoins.com/api-docs/#ads
As well as the price at which each of the trades are locked in at:
https://localbitcoins.com/api-docs/#dashboard
It should be possible to write a script to scrape this data and calculate the btc_in_usd value using this.
(I'm sure this information is available somewhere in their user panel too, although you might have to look around)


How can I create a transaction that collects inputs from many addresses and sends them to one address in bitcoind? I'm using bitcoind and would like to understand how to create transactions that send inputs from many specifically selected addresses (from my wallet) to one destination address. I want to do manually what the sendtoaddress command does automatically.

If this operation requires me to create a raw transaction could you please provide a working example? I already read bitcoin.it:raw_transactions, but it is hard to understand without an example and unfortunately the wiki article doesn't provide any.

I would appreciate help greatly.

When you have a bitcoin balance, that balance is actually unspent outputs from transactions your addresses have already received.

So when you want to send a raw transaction, what you include in that is the transactions and unspent outputs from those transactions... these can be from any address in your wallet.

The basic idea is;

createrawtransaction
signrawtransaction
sendrawtransaction

If you google around, you'll find plenty of examples of their use.


How do I program smart contracts? Is there a guide to learn how to program smart contracts for the Bitcoin blockchain?

Ivy is a higher-level language that allows you to write smart contracts for the Bitcoin protocol. It can compile to instructions for Bitcoin’s virtual machine, Bitcoin Script, and can be used to create SegWit-compatible Bitcoin addresses.

Ivy GitHub Repository

Another interesting approach is to use RSK. Rootstock is a project to execute smart contracts (turing complete) to the ecosystem of Bitcoin. It is a Sidechain that uses as currency the SBTC (Smart-BTC) which is convertible 1: 1 with Bitcoin (2-way peg).

Balzac is an high-level language for writing transactions, verifying their correctness, and compiling them into actual Bitcoin transactions. You can also use Balzac to design Bitcoin smart contracts.


If I have bitcoins in blockchain.info wallet, can I transfer it to my local bitcoin account wallet? If I have bitcoins in a blockchain.info wallet, can I transfer it to my local bitcoin wallet? If so, how?

Yes. Get a Bitcoin address from the wallet you want to send to and then send to that address.


In pooled mining, what is pdiff, bdiff and ldiff? In pooled mining, there seem to be three different terms for difficulty in use. Apparently, the Stratum protocol uses bdiff, BTCGuild uses pdiff, and Ldiff is common for various Scrypt pools as mentioned in this bitcointalk thread.

What are the meanings of pdiff, bdiff, and ldiff? In what way do they differ?

What are the meanings of pdiff, bdiff, and ldiff?

The numbers are the current difficulty of the network(s).

bdiff is the target difficulty of the whole Bitcoin network.
ldiff is the target difficulty of the whole Litecoin network.
pdiff is your pool's target difficulty.

As you may know, the difficulty is a measure of how difficult it is to find a hash below a given target value.

In what way do they differ?

Is bdiff 1 == pdiff 1 == ldiff 1, or how do they relate?

TL;DR: No. That defeats the purpose of having multiple difficulties.

This is a multi-part answer; I'll try to divide it in a manner that it makes sense.

Bitcoin

Difficulty

The Bitcoin network has a global block difficulty (bdiff). Valid blocks must have a hash less than or equal to this target. Mining pools also have a pool-specific share difficulty setting a lower limit for shares (pdiff, usually 1).

Calculation

How is bdiff calculated?

bdiff is an approximation based off of a known hash where the leading 32 bits are zero and the rest are one.

  difficulty = difficulty_1_target / current_target

  (target is a 256 bit number)

  difficulty_1_target can be different for various ways to measure difficulty.
  Traditionally, it represents a hash where the leading 32 bits are zero and the rest are
  one (this is known as "pool difficulty" or "pdiff"). The Bitcoin protocol represents
  targets as a custom floating point type with limited precision; as a result, Bitcoin
  clients often approximate difficulty based on this (this is known as "bdiff").

How is that value stored?

  Each block stores a packed representation [...] for its actual hexadecimal
  target. The target can be derived from it via a predefined formula. For example, if the
  packed target in the block is 0x1b0404cb, the hexadecimal target is

0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff, while the smallest is 0x008000. To make a larger value you must shift it down one full byte positive valid value.

How does one calculate (estimate) bdiff?

Say your value is 1 (0x1d00ffff) 0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

That would be 0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.420938523983

Source

Litecoin

Difficulty

Because Litecoin is based on Bitcoin ldiff is calculated the same as bdiff. It is an approximation relative to a known hash (256-bit number where the leading 32 bits are zero and the rest are one).

Calculation

ldiff is calculated in the same way bdiff is.

They both have a maximum of infinity (basically), and a minimum of 1/4096

Because Litecoin takes its roots in Bitcoin, this also means ldiff is an approximation, not a precise value.

Source

Pools

Difficulty

pdiff is relative to the crypto-currency in question. In the cases of Bitcoin and Litecoin pools, it represents the same thing; but in, for example, a Namecoin pool, the difficulty may not be 1, or it may be calculated differently. This is confusing because the 256-bit number in question is 0x1d00ffff. The number was not called anything initially. But once pooled mining started, it colloquially became known as pdiff. But it was around before pooled mining. Pools just happened to use it as their target difficulty, and because bdiff was already a thing, the name pdiff was transposed to the number 0x1d00ffff.

Note that pools usually use non-truncated-targets, and usually use a difficulty of 1. This means that even within the same crypto-currencies there really is no set definition of what pdiff is; however, I know of no pools/pool software that contradict these rules, because they are desirable. Just remember that anyone can make his pool do whatever he wants it to.

pdiff is relative.

Calculation

Assuming this is a standard pool, calculation follows basically the same as bdiff, but with one exception:

Let's say the target value is still 0x1d00ffff. The Wiki says pools usually use "non-truncated targets" So, instead of 0x00000000FFFF0000000000000000000000000000000000000000000000000000 we get 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Which, when calculated, yields 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.669773817162

Source


Scalability of Bitcoin What will incentivize miners to keep processing transactions after bitcoin production slows down and or stops?
I understand that miners could work off fees, but are these costs per transactions for the consumer cheaper than they are now with the current credit card system?
If the suggestion is just for the consumer to send bulk transactions instead of individual payments, what stops someone from buying coffee and then not sending it?

What will incentivize miners to keep processing transactions after bitcoin production slows down and or stops?

We don't know. The hope is that fees can take over the function of subsidy over time (and to an extent, that seems to be happening), but the incentives in the system become more complicated to reason about in that case (search for fee sniping attacks).

  I understand that miners could work off fees, but are these costs per transactions for the consumer cheaper than they are now with the current credit card system?

It is important to realize that not every payment in BTC-the-currency needs to happen on Bitcoin-the-blockchain:

Transactions happening within exchanges do not hit the blockchain, and probably wouldn't fit regardless.
If you need to pay me, and I trust you, you could just give me a private key with associated funds.
Payment channels (including bidirectional ones like Lightning) can result in many small payments being aggregated before making the whole world validate it.

Bitcoin-the-blockchain is good as a currency:

Fair, verifiable, beyond control, resistant to theft and seizing.
Being natively digital, it hopefully simplifies building systems on top (for example, systems with cryptographic proofs of reserve).
Going beyond the traditional forms of ownership: money that inherently requires multiple people to sign off on, or even further, money that can be tied to the exchange of knowledge (look for ZKCPs).

For all these properties, it is not good at being a payment system:

It's slow at transferring (it takes hours for transactions to confirm).
It is expensive for small payments (its fees are proportional to transaction complexity, not amount)
It lacks consumer-oriented features like disputing claims.

All this means is that for different purposes, different technologies may be more appropriate. Nothing prevents existing (or, hopefully new) payment solutions to be brought to BTC-the-currency.

  If the suggestion is just for the consumer to send bulk transactions instead of individual payments, what stops someone from buying coffee and then not sending it?

Lightning does not have this problem - it processes transactions between two parties instantly, without needing the whole world to verify it for them. The downside is that it requires channels to be setup beforehand, and loaded with some money from both parties (which returns to them after closing the channel, or can be taken by the other party when you cheat).


Possible to transfer BTC via QR code? Is it possible to embed an amount of BTC in a QR code to transfer to whoever scans it?

E.g. I create a QR code for .5 BTC from my wallet, send the QR code to someone (without knowing their BTC wallet address), they scan it using their wallet app and receive it?

Just add amount parameter to QR data:

bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?amount=0.005

use google chart to generate QR

https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?&amount=0.005

  if you are asking about auto sending bitcoin through QR so it's not possible.


How to salvage bitcoins from corrupted hard drive? I have been mining bitcoins for years, all which now appear to be gone.

The bitcoin machine is running ubuntu 10.04 LTS. The bitcoin miner is version 0.3.20.2.

The machine crashed after a power failure/spike after which the blkindex.dat file was corrupt, along with very many filesystem errors (claimed to be fixed on reboot).  I managed to load the wallet.dat file onto a Mac OSX machine, installed the latest version of bitcoin and let it run to update the wallet info.  Before syncing the wallet showed 0 bitcoins.

After ~14 hours of "syncing" the wallet still shows 0 bitcoins.

Searching online, there are a few people that have lost their bitcoins when upgrading from one version to another.

I've built another machine with the same version of Linux and bitcoin miner and installed all the bitcoin files EXCEPT the blk*.dat files.  It is now running.

Is there anything else I could try?

You can also try running pywallet on the old wallet file to get at the private keys. Not sure it'll work with such an old file but it's worth trying:

https://bitcointalk.org/index.php?topic=34028.0

Once you have the private keys you can import them into any client like electrum, bitcoin-qt, multibit etc. to see if you have any coins.


Project on modelling Bitcoin blockchain data I am doing a thesis project on modelling Bitcoin blockchain data, but atm I am having trouble getting data from the Bitcoin blockchain into a format that is easy to deal with in e.g. Python.

I have all data from Bitcoin Core, do you know a way to aggregate the data, into a format that would give an idea about users balance or something like this?

If you have ever done a similar project, I am very interested in what you have done in the preliminary phases!
Thanks.

As to how to convert anonymous transactions to "users" (at most a statistical attempt, as Bitcoin is in principle anonymous), which could lead to your requested "users balance" info, there are papers available that describe the process. These for example could serve as a start point (with good descriptions and images):

"An Analysis of Anonymity in the Bitcoin System" by Fergal Reid and Martin Harrigan
"Analyzing the Bitcoin Network: The First Four Years" - Matthias Lischke and Benjamin Fabian, Institute of Information Systems, Humboldt-Universität zu Berlin, Spandauer Str. 1, 10178 Berlin, Germany (CC BY 4.0)

Basically, citing the latter:

  ... a “user” is a grouping of public keys that were used as inputs into a single transaction (user owns the private key to each address) ...

As for the troubles using Python directly to treat raw data, you can use, perhaps as template or to get ideas, this post which uses Python to convert binary block header data to a CSV:

#!/usr/bin/env python
# convert binary file http://headers.electrum.org/blockchain_headers
# to CSV ASCII

import binascii

STRUCT_OF_BLOCK = [ 4, 32, 32, 4, 4, 4 ] # blockchain_headers does not contain always "0x00" txn_count
BLOCK_SIZE = sum(STRUCT_OF_BLOCK)

FILE_OUT= open('blockchain_headers.csv','w')

FILE_OUT.write( "version,prev_block,merkle_root,timestamp,bits,nonce,txn_count\n" )

with open('blockchain_headers','rb') as FILE:
    block = FILE.read(BLOCK_SIZE)
    while block != b'':
        position = 0
        for i in STRUCT_OF_BLOCK:
            FILE_OUT.write( bytearray(binascii.hexlify( block[position:(position+i)][::-1] )).decode('ascii') + ',')
            position += i
            if position >= BLOCK_SIZE:
                FILE_OUT.write("00\n") # blockchain_headers does not contain always "0x00" txn_count
        block = FILE.read(BLOCK_SIZE)


How does the 51 percent or 2/3 majority voting rule work? For a block to be added to the chain, it needs vote from majority of miners, is that correct? If yes, does that mean a single block gets worked upon by all of the miners?

For a block to be added to the chain, it needs vote from majority of miners, is that correct? If yes, does that mean a single block gets worked upon by all of the miners?

There is no voting. Each miner works on their own version of blocks. Once they have found the hash of the block header which meets the difficulty target, they broadcast the block to the rest of the network. When the other full nodes and miners receive this block, they will first verify if the block meets all the protocol rules, and the transactions within the block are also valid. The bitcoin software is designed so as to accept the chain with the most proof of work. In most cases this is also same as the longest chain. So, when the new block is received by the nodes, they would add this block on top of the existing chain if the block is valid. When the block is received, the other miners would see that they have lost the 'race' for that particular block height. Now they will start working on the next block, by building on the top of the block that they just received.

  How does the 51 percent or 2/3 majority voting rule work?

I assume you are referring to 51% attack. 51% attack basically means that if a miner has more than 50% of the hash power of the total network, he has higher probability of mining blocks that is faster than the rest of the network combined. If that is the case, then the miner can double spend the bitcoins. If you want more clarity as to what 51% attack is, then you can refer here. Regarding 2/3rd voting, you might have read that as a part of Byzantine Fault Tolerance (BFT) threshold. However, bitcoin doesn't exist within the normal model of BFT consensus. Under conventional assumptions bitcoin will converge on a stable history if honest participants have a majority hashpower (>50%).


Maysspayout, SendMany, Bulk Payouts with Bitcoin Core Do I have to download the whole bitcoin blockchain (145GB) to be able to do a sendMany transaction with Bitcoin Core?

Are there other Desktop Software, where I can do a masspayout?

Maybe an App, where I can read a CSV like this:

address amount,

address amount,

...

Electrum is an SPV wallet which means you don't need to download the entire blockchain. It will be up and running in a few minutes

It has a handy sendtomany feature where you can even upload a csv file


Which BIP-148 branch is the most recommended? I want to run an BIP-148 ("segwit UASF") node. However, I am not sure which of the various branches is most maintained and recommended to run.

There is this pull request by earonesty (386 commits behind master, last commit May 30)
There is a different pull request by earonesty (on luke-jr repo, 154 commits behind master, last commit June 22)
There is also UASF/bitcoin repo (1379 commits behind master, last commit July 2)

Which of these repos is the most recommended one?

(Note: this question might get outdated soon. For reference, I am asking it 3rd July 2017.)

As luke-jr (author of the code in one of the PRs) said in the comments right now, the branch is abandoned and the recommended code is in UASF/bitcoin repo.

(Again the answer might get outdated soon.)


Jelurida Public License (jpl) and IGNIS ico I've heard alot of hype from several sources about IGNIS coins receiving a share of new coins it is used to forge, but when I finally got round to reading the JPL it appears NXT is the coin that will receive a 10% share (proportional to holdings), but for coins created when the software is FORKED, not when a parent chain forges a child chain?

Could someone clarify what forking the software means it this context and it's implications?

If you held NXT during the ignis snapshop on 2017 Dec, 28 you'd receive .5 ignis once the Ardor platform releases in 2018. As for the JPL license, supposedly you'd receive 10% of the coins being created with a new fork of NXT. Also child chains on Ardor are giving out airdrops if you hold ignis like bitswift. (https://www.jelurida.com/bitswift)

  Paul Busch also announced that he will be giving away 10% of all
  Bitswift tokens to all holders of Ignis coins, relative to the amount
  of Ignis coins they are allocated at the time of the Ardor Genesis
  Snapshot. However, all funds for this 10% giveaway will come from
  Paul’s own personal funds. Bitswift does not intend to compete with
  Ignis as a child chain, but rather to complement the entire platform.
  Additionally, further customized development will be explored that
  will not only differentiate the two chains, but also provide the
  needed customizations that Bitswift requires. Some features will also
  be disabled due to business reasons as requested by Bitswift.


Without being continuously connected to the network, how can I protect from Double Spend attacks? I'm a vendor who is interested in protecting myself from double spend attacks.

What software, configuration, connectivity, or timeout is required to mitigate this risk?

Namely, how would I protect myself if a continential communications blackout were to occur, as described here.

This could occur if I'm accepting payment on a satellite link, as often occurs on boat-casinos, islands (Hawaii), or in 3rd world countries.

To essentially eliminate any risk due to double spending, the recommended level of confirmations is six.

For most transactions such as those to a bricks and mortar merchant, payment might be accepted immediately (with 0 confirmations), but that exposes the merchant to a small degree of double-spending risk.

A recommendation for merchants running their own node is to have the configuration where there are no incoming connection and to explicitly have an outgoing connection to a well-connected node.

Thus, properly configured this way, the merchant is not much at risk of double spending because either the transaction was broadcast and it reached the well-connected node that the merchant connects to or it didn't and the merchant doesn't know about it until communications from the party attempting to pay can be re-established with the outside world.

In that scenario, bitcoin fares no worse than any other merchant payment system as those require authorization from connected sources as well.

The amount of data to receive blockchain data is relatively little -- under 100MB per day.  Thus even a single dialup modem connection is all that would be needed and that node could then serve all other nodes connected locally.

Additionally, if mobile communications are present, the merchant could simply use mobile notification from a hosted service and not run using a node at all.

There is a business solution not a technical one to the specific scenario requested.  Just as a hotel will accept a check from a guest even when it doesn't have a guarantee that the check won't bounce, a merchant can accept a bitcoin transaction even when there are no communications by adding a layer above (e.g., verifying identification, getting approval to charge against a backup payment method using a credit card, not selling anything of high value during the communications outage, etc.)


When mining, all my shares are rejected. Why am I not getting any accepted shares? This applies for when I mine anything (Litecoins, Dogecoin, etc.) I have a Radeon HD 6670 (mining @ 100 Mh/s according to cgminer) and it isn't overclocked or anything. Kind of puzzled as to why this is happening.

Does anyone know why I am not able to mine successfully?

My guess is that you did not launch cgminer with the --scrypt option.  This is required to mine Litecoin, Dogecoin or any other scrypt coin. When mining scrypt coins that card should deliver ~100 Kh/s in your screen shot it shows Mh/s which would indicate that you are using SHA256 which is for Bitcoin.


How does a Merkle proof differ from the Merkle tree? I'm not sure how Merkle tree and Merkle proof are different. I thought Merkle proof is the same as the Merkle root in each block. However, it seems like Merkle proof contains all Merkle roots of all blocks. Could anyone explain about Merkle proof visually?

Merkle proofs are not for blocks nor is there a singular "the merkle proof." Merkle proofs are for transactions. They prove that a particular transaction is contained within a particular block.
A merkle proof begins with the transaction that is being proved. Then each branch in the merkle tree that cannot be derived from the transaction is provided, all the way up to the root. The result is a path from the merkle root to the transaction. A verifier can then use this path to compute the merkle root and check that it matches the one in the block header.


"New rules activated" warning after upgrading to 0.20.0 I've upgraded a node from the previous release. It's up and running but for some reasons I get this warning.
How can it be related to the upgrade?

$ bitcoin-cli -testnet getblockchaininfo | jq
{
  "chain": "test",
  "blocks": 1764182,
  "headers": 1764182,
  "bestblockhash": "0000000000004a0e9cc1fbc2a21938feef1a26cd480483b3c498ae2ef16b46f8",
  "difficulty": 65536,
  "mediantime": 1591710673,
  "verificationprogress": 0.9999998260147338,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000000000000000000000015bbad4a75d4239391e",
  "size_on_disk": 27411142847,
  "pruned": false,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": true,
      "height": 21111
    },
    "bip66": {
      "type": "buried",
      "active": true,
      "height": 330776
    },
    "bip65": {
      "type": "buried",
      "active": true,
      "height": 581885
    },
    "csv": {
      "type": "buried",
      "active": true,
      "height": 770112
    },
    "segwit": {
      "type": "buried",
      "active": true,
      "height": 834624
    }
  },
  "warnings": "Warning: unknown new rules activated (versionbit 28)"
}

Miners have been using the version field of the blocks' headers as an "extra nonce" (*).

However, this version field has been used to signal readiness from miners to deploy a soft fork (update to new backward-compatible rules).

The version field being used to synchronize the update to new consensus rules is the reason you see the warning.

The version field value not being enforced by the consensus, and the development of new techniques that increase miners' revenue is the reason they can "disgress" the protocol.

(*) In this specific case, it's known as version rolling and is likely part of using overt asicboost.

EDIT - Some reference of discussions about how to deal with this in bitcoin-core :

BIP320 implementation
Discussions on an issue
GUI warning removal


Coins not yet refllecting in wallet i transferred coins to my wallet, but the wallet hasn't finished syncing with the network as yet, so the coins have not reflected. Is this something i need to be concerned about? Do i just wait for it to finish and then see if they appear? I did use the address the wallet gave me.

Assuming you sent the amount to the correct address you have nothing to worry about. This is expected for a wallet that has to download and verify the whole blockchain. Other wallets use SPV that only verifies transactions for your addresses and thus they do not have to download the whole blockchain. Examples of SPV wallets for the desktop are Multibit and Electrum.

After syncing you will see the balance reflected but you could also immediately check if the coins arrived to your address correctly with a block explorer. E.g. go to Blockchain.info or BlockExplorer and search for your address: you will see the amount on that address, the number of confirmations, etc.


Link to Algorithmic behind signatures verification Does anyone know a good paper where the process of signature verification is explained (message+signature+public key = valid/not_valid) ??? And I mean it at a low level, with the code or pseudo-code of the algorithms doing the verification or similar. All sources I have found explain it with the verification process being pretty much a black box.

I know StackExchange is not the place to ask for references, but I haven't found what I am looking for, so someone might now a good source...

Thank you all in advance. Cheers

Signature generation:

xRandSignPoint, yRandSignPoint = EccMultiply(Gx,Gy,RandNum)
R = xRandSignPoint % N
S = ((HashOfThingToSign + R * privKey) * (modinv(RandNum,N))) % N

Signature verification:

w = modinv(S,N)
xu1, yu1 = EccMultiply(Gx,Gy,(HashOfThingToSign * w)%N)
xu2, yu2 = EccMultiply(xPublicKey,yPublicKey,(R * w)%N)
X,Y = ECadd(xu1,yu1,xu2,yu2)
if R == X:
    print "Signature verified"

EccMultiply – elliptic curve point on scalar multiplication.

ECadd – elliptic curve 2 points addition.

Here is the original source.


confirmation time limit Reading How does mining works and towards the end of the explanation,

  As more people start to mine, the difficulty of finding valid blocks is automatically increased by the network to ensure that the average time to find a block remains equal to 10 minutes.

But in Why do I have to wait for confirmation?

  Each confirmation takes between a few seconds and 90 minutes, with 10 minutes being the average.

Since "finding a block" is "confirmation" of a transaction, the above quotes seam like a contradiction.

The other question is why the difficulty increases when more mining power is available? one would thing the opposite should be true. I must be missing something. Any  explanation for this? Thanks

The difficulty of the network adjusts in proportion to the hash rate, so that on average a block is found every 10 minutes. Of course, it's still a random process, so sometimes blocks are much shorter and sometimes they're much further apart.

As a result, if more hash power gets added to the network, the difficulty has to go up to compensate. Otherwise doubling the hashrate would result in one block per 5 minutes instead of per 10 minutes.

I don't understand where you think there is a contradiction, but feel free to clarify.


What's the best way to integrate bitcoin API's into a wordpress site? I'm fairly new to coding, I understand the philosophy but I'm lacking practical application. Does anyone know any practical guides that will help me? I've completed most codeacademy courses.

You can integrate Shapeshift plugin in your website. Build something like this. That's a good way to start with. You can see an example here http://radelcorp.in/shp