Service to send Bitcoins or Altcoins over a specific amount of time? Doing it Decentralized?

You can just publish a bunch of transactions with a particular nlocktime. Say you wanted to give your daughter an allowance of 0.1 BTC/week for a whole year. You can create one transaction with a locktime of next monday for 0.1 BTC, another transaction with a locktime of the monday after that for 0.1 BTC and so on for a whole year. The way bitcoin works, she'll receive the amounts every monday.

At any time, you can create a transaction to yourself to nullify some or all of the future transactions. Many altcoins will also have this feature.

Now, if you want a constant dollar amount and not a bitcoin amount, that actually will require a service. Doing that in a decentralized way is going to be really tough since exchange rates by their nature tend to be centralized.

Here's how you can make an nlocktime transaction using the excellent btcd library in go:

package main

import (
    "bytes"
    "encoding/hex"
    "fmt"

    "github.com/btcsuite/btcd/btcec"
    "github.com/btcsuite/btcd/chaincfg"
    "github.com/btcsuite/btcd/txscript"
    "github.com/btcsuite/btcd/wire"
    "github.com/btcsuite/btcutil"
)

func main() {

    // Ordinarily the private key would come from whatever storage mechanism
    // is being used, but for this example just hard code it.
    wif, err := btcutil.DecodeWIF(
        "<testnet private key in WIF format here>")
    )
    if err != nil {
        fmt.Println(err)
        return
    }

    compressed := false

    privKey := wif.PrivKey
    pubKey := privKey.PubKey()
    serializedPubKey := pubKey.SerializeCompressed()
    if !compressed {
        serializedPubKey = pubKey.SerializeUncompressed()
    }
    pubKeyHash := btcutil.Hash160(serializedPubKey)
    addr, err := btcutil.NewAddressPubKeyHash(pubKeyHash,
        &chaincfg.TestNet3Params)
    if err != nil {
        fmt.Println(err)
        return
    }

    txStr, err := hex.DecodeString("<testnet tx that contains the utxo in hex here>")

    if err != nil {
        fmt.Println(err)
        return
    }

    rbuf := bytes.NewReader(txStr)
    var originTx wire.MsgTx
    err = originTx.Deserialize(rbuf)
    if err != nil {
        fmt.Printf("Deserialize error %v\n", err)
        return
    }
    originTxHash := originTx.TxSha()

    // Create the transaction to redeem the fake transaction.
    redeemTx := wire.NewMsgTx()

    // Add the input(s) the redeeming transaction will spend.  There is no
    // signature script at this point since it hasn't been created or signed
    // yet, hence nil is provided for it.
    prevOut := wire.NewOutPoint(&originTxHash, 0)
    txIn := wire.NewTxIn(prevOut, nil)
    txIn.Sequence = 0
    redeemTx.AddTxIn(txIn)

    addr2, err := btcutil.DecodeAddress("<destination testnet addr here>",
        &chaincfg.TestNet3Params)
    if err != nil {
        fmt.Println(err)
        return
    }
    pkScript, err := txscript.PayToAddrScript(addr2)
    if err != nil {
        fmt.Println(err)
        return
    }

    txOut := wire.NewTxOut(93889960000, pkScript)
    redeemTx.AddTxOut(txOut)

    // unix time of when the tx output will be unlocked here
    redeemTx.LockTime = 1442802900

    // Sign the redeeming transaction.
    lookupKey := func(a btcutil.Address) (*btcec.PrivateKey, bool, error) {
        // Ordinarily this function would involve looking up the private
        // key for the provided address, but since the only thing being
        // signed in this example uses the address associated with the
        // private key from above, simply return it with the compressed
        // flag set since the address is using the associated compressed
        // public key.
        //
        // NOTE: If you want to prove the code is actually signing the
        // transaction properly, uncomment the following line which
        // intentionally returns an invalid key to sign with, which in
        // turn will result in a failure during the script execution
        // when verifying the signature.
        //
        // privKey.D.SetInt64(12345)
        return privKey, compressed, nil
    }
    // Notice that the script database parameter is nil here since it isn't
    // used.  It must be specified when pay-to-script-hash transactions are
    // being signed.
    sigScript, err := txscript.SignTxOutput(&chaincfg.TestNet3Params,
        redeemTx, 0, originTx.TxOut[0].PkScript, txscript.SigHashAll,
        txscript.KeyClosure(lookupKey), nil, nil)
    if err != nil {
        fmt.Println(err)
        return
    }
    redeemTx.TxIn[0].SignatureScript = sigScript

    var buf bytes.Buffer
    err = redeemTx.Serialize(&buf)
    if err != nil {
        fmt.Printf("Serialize error %v", err)
        return
    }

    // Prove that the transaction has been validly signed by executing the
    // script pair.
    flags := txscript.ScriptBip16 | txscript.ScriptVerifyDERSignatures |
        txscript.ScriptStrictMultiSig |
        txscript.ScriptDiscourageUpgradableNops
    vm, err := txscript.NewEngine(originTx.TxOut[0].PkScript, redeemTx, 0,
        flags)
    if err != nil {
        fmt.Println(err)
        return
    }
    if err := vm.Execute(); err != nil {
        fmt.Println(err)
        return
    }

    fmt.Printf("Transaction successfully signed %v\n", hex.EncodeToString(buf.Bytes()))

}


Is the Ledger Implementation of BIP39 Generation Not Following the Spec?

Those are valid mnemonics with valid checksums. In  the bip39 spec is the following:

  The following table describes the relation between the initial entropy length (ENT), the checksum length (CS) and the length of the generated mnemonic sentence (MS) in words.

  CS = ENT / 32

  MS = (ENT + CS) / 11

|  ENT  | CS | ENT+CS |  MS  |
+-------+----+--------+------+
|  128  |  4 |   132  |  12  |
|  160  |  5 |   165  |  15  |
|  192  |  6 |   198  |  18  |
|  224  |  7 |   231  |  21  |
|  256  |  8 |   264  |  24  |

As per the top row, 12 word mnemonics have 128 bits of entropy and 4 bits of checksum. That means any random 12 word mnemonic has a 1 in 16 chance to have a valid checksum.

The "blocking" of the valid final words instead of a totally random distribution is because the checksum bits are appended to the end of the entropy bits. So for every first 128 bits, there is exactly one valid final four bits. Bits are mapped to words by just counting down the alphabetically-sorted word list for each 11-bit chunk. So the first 128 bits determine the first eleven words and which "block" of the wordlist you are considering, and then within that block only one word corresponds to the correct checksum.


Why are m-of-n transactions not used today?

There are some m-of-n transactions in the blockchain (blockchain.info - block explorer) but they have only been recently added to the standard transaction types.

However the reason why they are probably not in wide spread use yet is there is no gui based client that can construct one. My Wallet will be able to construct them soon, I don't know how much demand there will be for usage.

The way I see it BIP 16//17 and m-of-n have different use cases. The drawback of P2SH is that you need to share the script with the recipient in order for them to know they have received a payment - you also need to store the script. While this might be ideal for split key wallets, (where the wallet owner already has the script) it is awkward for use with escrow transactions. If you receive an M-Of-N escrow payment notifications can work out of the box and you can use existing vanity addresses.


What is the difference between kH/s, MH/s, and GH/s?

Sure:

1 kH/s is 1,000 hashes per second (sometimes mistakenly written KH/s).
1 MH/s is 1,000,000 hashes per second.
1 GH/s is 1,000,000,000 hashes per second.
1 TH/s is 1,000,000,000,000 hashes per second.
1 PH/s is 1,000,000,000,000,000 hashes per second.


Well, a very simple case is mentioned in "Providing a deposit" contract, but there are many other uses, and many contracts depend on such transactions.

I also provided a brief description in this comment:

  Transaction with nLockTime in future cannot get into blockchain before that time.

  Previously it was the case that it was stored in memory pool, but now they can't even get into mempool. And it is OK, actually.
  Basically, nLockTime gives you an ability to back off after some delay, and that delay penalizes abuse or gives some time for negotiations.

  For example, suppose there is a service provider and a customer. They do not trust each other very much, so they will put money into 2-signature transaction, with nLockTime'd rollback in future. If customer is satisfied with service, he will release money to service provider. If service provider agrees that he screwed it up, he will release money back to customer. However, if they disagree (e.g. service provider think he did great job but customer thinks it's shit), money can be released by nLockTime'd transaction, say, year from now. In that case customer suffers because he cannot use money for a year, but service provider doesn't get money for shitty job he have done.

But, well, a complete answer will be a rather lengthy article...


How do I access the Bitshares that I received from my Protoshares "snapshot"

Install the BitShares wallet. Create an account and go to that account page. Select the "Keys" tab and import the wallet.dat file.


I know my address but can't remember which site it's from

It isn't trivial to de-anonymize a bitcoin address. Your best hope is that the address has inputs or outputs to other addresses that have been deanonymized somehow (search online for those addresses). This is unlikely though. You would be better just checking all the wallet sites with your login(s). As @nate-eldredge mentions this carry's the risk that you might reveal your login/pass combinations at some exchanges that are not trustworthy.

One tool that seems to have some information about addresses is OXT. For example it determind this address to be associated with btc-e exchange


Transaction still unconfirmed after 2 days

An unconfirmed transaction will eventually be accepted into a block by whichever mining pool mines the block, or the transaction will eventually be rejected by the bitcoin network after an estimated one to seven days. If it eventually is rejected, then the funds would remain at the bitcoin address they were sent from. The only thing you can do at this point is to wait and see if the transaction is accepted into a block. Like all wallet providers, Blockchain.info has absolutely no control over this, and cannot expedite transactions. This is always dependent upon the bitcoin network of miners, which we are not a part of.

Blockchain.info wallets utilize dynamic fees. The following link explains how this works - https://blog.blockchain.com/2016/03/16/introducing-dynamic-fees/.


Does Bitcoin Core support BIP157? (some call it neutrino)

Bitcoin Core 0.21+ support BIP 157, but not necessarily by default. In 0.21, it is default to off. You can enable it by adding peerblockfilters=1 to your bitcoin.conf file.


Do transactions and blocks get relayed even if a node believes them to be invalid?

A block is valid only if it obeys all the protocol rules.  If it is invalid, it will not be relayed:

http://en.bitcoin.it/wiki/Invalid_block

Now the client does maintain side chains.  So if there is the main branch and a side branch, even though the node included a transaction in the main branch doesn't mean it will reject a block for the side branch just because it too contains the same transaction.  So for each branch it is determined if that block was valid or not.

But there is a rule that valid blocks are only relayed if they are added to the (new) main branch / best known chain (thanks to Pieter for the correction).

As far as a new transaction being relayed - if it is invalid for the main branch (e.g., double spend) then it will not be relayed by the node.

So a transaction is either already in a block in the main branch already (and thus would be rejected if it is a double spend) or it isn't in the main branch and will as a result always be relayed.

This will be relayed even if that transaction is already included in a block in the side chain.


Why does the bitcoin mining code have the same if statement twice?

This is double-checked locking, which is

  ...a software design pattern used to reduce the overhead of acquiring a lock by first testing the locking criterion [...] without actually acquiring the lock.

This pattern can be fraught with issues; even folks who otherwise know what they're doing can be bitten by subtle issues.  See, for example, C++ and the Perils of Double-Checked Locking by Scott Meyers and Andrei Alexandrescu.

The particular use case you cite looks fairly innocuous, though.


It is impossible to know how many nodes each node is connected to or has in its peers table. This information is not broadcast publicly and the information that is available publicly (by asking a node) is not representative of what the node actually knows.


Yes, it does. There's a detailed guide on the Ledger site, and a bunch of videos on youtube explaining how to use your Ledger with a Electrum.


Exporting the private key, then importing it into a new wallet (still in MultiBit) recovered the missing bitcoins for me.


How does Bitcoin Gigahashes Convert to Ethereum Megahashes?

Bitcoin and Ethereum use different hashing algorithms. General consumer hardware (like a CPU or GPU) can be easily programmed at a software level to perform either the Bitcoin or the Ethereum (amongst many other) hashing algorithms. However, specialized hardware (like the Block Erupters you mentioned, which are Application Specific Integrated Circuits (ASICs)) have the hashing algorithm hard-coded into the chip's design, allowing it to much more efficiently perform one type of work (Bitcoin's double-SHA256, for example) at the expense of flexibility--they can't be reprogrammed to do anything else.

On a side-note, a £60 ASIC which runs at 16 GH/s (which isn't a block erupter, it might be the USB Stick from GekkoScience?) is very unlikely to ever reach ROI. At current difficulty and Bitcoin price, and assuming free electricity, a 16 GH/s miner would bring in about £0.26/month, which is likely to get even worse as more mining power comes online in the future.


Double spending race attack first transaction

No, not really.

First of all, there is no clear way for everyone to agree on which was the first transaction to be sent to the network.  If the attacker was to send two conflicting transactions (call them A and B) to different nodes almost simultaneously, then depending on how the propagate, some nodes might see A first, and others B.

For the Bitcoin Core reference client, if it receives A first and later receives B, it will ignore B and will not relay B to its peers.  This hampers a double-spend attack somewhat.  But if a client later receives a mined block that contains the transaction B, it will accept it in place of A.  And a miner has total freedom which of the two transactions to include in a block.


Is 30,000 rounds really needed for PBKDF2?

Can I safely reduce the rounds to make it a bit faster? and if so what would be the minimum?
Could I get away with 10,000?

Anyone trying to crack your encrypted data is not going to be limited by the speed of javascript executing in a browser. They'll be running FPGAs or something much faster than that. So 20,000, 10,000 or 0 doesn't make any sort of difference here.
Where I learned this


Where do i get parts for diy hardware wallet and program

By DIY I guess you mean not a pre-built product like a Trezor.
Any electonics store or distributor (Mouser, Farnell, etc etc etc) will sell you parts to make any of the open-source options listed in https://en.bitcoin.it/wiki/Hardware_wallet
To pick a random easy example: pi-wallet - though a compute-module or zero-W would be more compact. There's plenty of open-source hand-held, battery-powered gaming devices based on that hardware that could be adapted to suit.
If you are more ambitious, and handy with a soldering iron, you could check out something like BitBox which is apparently based on standard electronics parts. They publish schematics and bill-of-materials for parts as well as the code. You'll not match their production quality but a functional portable device should be achievable with the right skills.


Was there ever reasoning presented for the size of a satoshi (i.e., the minimum amount of bitcoin that can be transacted)?

Like most of these internal choices in the Bitcoin system, it's not really explained by the author and can't be easily changed even if anybody had a strong objection to it. Internally all values are 64 bit integers, and just displayed to the user as value / 1e8.

The original wxBitcoin releases displayed two decimal places of precision.


Transaction with 0.0002 BTC fee but not confirmed sice 2 days

this tx has "dust" output of 300 satoshi. miner nodes treat such transactions as non-standard and do not confirm them

  Could anyone say what happens to my transaction (~100 USD) if no miner
  confirms it for some reason?

nothing happens to your transaction


Actually there are "addresses" in bitcoin. You have an address and associated transactions (equivalent to the amount of satoshis you have). When you want to spend these bitcoins, you create a transaction where it says : "the destination address" to which you pay.
To have a bitcoin address, you do not need to give personal data, you only have one address (a hash) and the public and private key that make you owners of that address.
It is this procedure that offers you anonymity, but all these transactions are stored in plain text on all nodes in the network.


Is it possible to confirm a specific transaction with your own miner?

You could try to confirm it by mining a block in which you explicitly include said transaction. However, unless you have very powerful mining hardware, it is highly unlikely that you will succeed any time soon to solo-mine a block.

You could either try to double-spend the outputs you used to fund that transaction and for the second one include the correct fee, or just wait until the transaction's priority has risen sufficiently that it will be processed eventually.


Option 1

I'm not sure on which platform you are, but if you use a Linux or Mac, you can combine the following two commands (sources here and here. Check also the at manual):

echo "ls -l" | at 07:00

and

 bitcoind sendtoaddress <bitcoinaddress> <amount>

to make something like:

echo "bitcoind sendtoaddress    1MAtHias8yvaLcDgckkG5QnVLY7ucBZrGv 0.01" | at 07:00

to send me 0.01 BTC at 07:00 o'clock in the morning. I think you're computer should stay on for this, as it cannot send a transaction with it turned off.

Option 2

You can also work with sleep (Mac and Linux only):

sleep 120 && bitcoind sendtoaddress 1MAtHias8yvaLcDgckkG5QnVLY7ucBZrGv 0.01

The number behind sleep is the amount of seconds that there is nothing executed. So now it will send 0.01 BTC to me, after 2 (=120/60) minutes. The && will first execute the left side. If that executed succesful, the right side is executed. It is more insightful, but you'll have to calculate the amount of seconds and is as precise as your calculations.

Option 3

For windows:

timeout 120 && bitcoind sendtoaddress   1MAtHias8yvaLcDgckkG5QnVLY7ucBZrGv 0.01

timeout is the sleep variant of windows. Probably doesn't work on Windows XP, but works here on W8 and should work on W7. The && does the same as in Option 2.


Just write down the 12 words and put them back in and its done.  never give out them words because that your passphrase or in other words your Backup


How is 10% transaction fee possible for a bitcoin transfer from coinbase to another exchange?

This is normal.  You can see on https://bitcoinfees.earn.com/ that BTC 0.001 is a pretty average fee right now.

You should not think of it as a percentage, since the fee for a transaction is not related to the amount of coins transacted.  Instead, it has to do with the size of the transaction in bytes, which is more a matter of its complexity (e.g. number of input transactions spent, number of addresses paid).  You'd have paid the same fee whether the amount you sent was BTC 0.0001 (in which case it would be a 1000% fee) or BTC 1 (an 0.1% fee).

  Also, is there a way to avoid such high transfer fee on coinbase?

No.  If you want the percent fee to look smaller, send larger amounts.  Or you could wait and see if fees go down in the future (they might or might not).


This should be the location of wallet.dat on MAC

~/Library/Application Support/MultiBit/

You will be able to copy this file to USB and paste it into the same location on your new MAC.


You should know that lots of things in life come for free. Specifically when it comes to software, lots of professional developers would rather develop things "their own way" for free, instead of getting paid and "being forced to do it". Most open source developers also simply enjoy the act of creating things. They're engineers and scientists that care more about people using their inventions, rather than an economical compensation.

However, as you say, at the end of the day developers have to eat and pay the bills too. If I remember correctly the MultiBit developers will add an option to automatically send a portion of the fees you use for transactions towards themselves. However, I've read this news on some blogs and not directly from the MultiBit developers: http://www.coindesk.com/cash-strapped-multibit-developers-charge-transaction-fee/

But at the end of the day, if you're a developer of a famous bitcoin wallet, you'll have no problems finding a job to earn some money. So money isn't really an issue for most of open source developers. I'd argue that money would actually poison the open source philosophy. You're more in it for the act of creating, for the reputation and fame, for the feeling of doing something nobody has ever done before.


Can you list receiving addresses in bitcoin-cli?

Yes, you can do it.

bitcoin-cli listreceivedbyaddress 1 true

I had to read the argument documentation. Thanks Sven Williamson.


How to convert regular transaction to MULTI-SIG one?

Yes, you are right. There are two ways of doing so:

You can create a multi-sig transaction as you mentioned, including a m-of-n script in which you will define the number of signatures (m) of the total n that will be necessary  to redeem from the transition. The script structure from T2 will be:

ScriptPubKey: <m> <PubKey_1> <PubKey_2> ... <PubKey_n> n

And the redeem script from T3 will be:

ScriptSig: <Sig_1><Sig_2> ... <Sig_n>

Notice that, in order to be valid, the signatures in T3 must be in the same order as the public keys in T2.

On the other hand, you can encapsulate the multi-sig scripts mentioned avobe in a Pay-to-scriptHash, in that way the first transaction script (T2) will simpler, since it will be just a hash, and the transaction will look more similar to a traditional Pay-to-Publickey-hash.


The scenario you name would be great for cryptocurrencies as it would make them mainstream. As soon as people got sick of govt intervention with Bitcoin in such a scenario, it would probably be relatively easy to get enormous numbers of people to switch over to a very similar (but independent) Altcoin.

The nature of the cryptocurrency technology is such that it is very difficult to stop people running the software, but a govt could have success in closing down businesses that accept unofficial versions such as the fictional Altcoin. If that happened, it could however still thrive outside of the region being regulated.

Prevention would probably need to occur at a political level, but I'd hope market forces as I've just described will be sufficient prevention as long as no organisation gains too much power over international law. Agreements negotiated in secret like the TPPA are something to watch out for though.


How do I set up a fee for my p2pool node?

Found out why I'm not seeing the fees:
The fee payouts are of type 'mined' so in the client history, they don't show up with an address.

http://dogechain.info/chain/Dogecoin/q/addressbalance/DMYSTUPIDADRRESS

Told me that there must have come some coins in.
Wow, such joy!

Edit:
seems like the new client shows to which address it was mined.


How does difficulty is defined for block '55798'?

How to calculate difficulty from Bits fields (which is stored in block).

Convert value to hex: bits=471067731 -> 0x1c13ec53
Split hex value, take 8 high bits (0x1c), and 24 low (0x13ec53)
Use formula to get 256-bit target value: T = low * 2 ^ (8 * (high - 3)). In our case it will be: T = 0x13ec53 * 2 ^ (8 * (0x1c - 3)) = 0x0000000013ec5300000000000000000000000000000000000000000000000000
Divide highest possible target Tmax (0x00000000ffff0000000000000000000000000000000000000000000000000000) by our T. If we truncate zeros, it will be: 0x13ec53 / 0xffff00 = 12.849

Network recalculates difficulty every 2016 blocks (2 weeks). This is how 12.85 is getting recalculated from block timestamps:

block -  diff - time stamp
...
52415 -  7.82 (2010-04-21 21:50:53)
52416 - 11.46 (2010-04-21 21:52:52) <- difficulty update
...
54430 - 11.46 (2010-05-04 09:39:19)
54431 - 11.46 (2010-05-04 09:40:03)
54432 - 12.85 (2010-05-04 09:46:16) <- difficulty update
...
55798 - 12.85 (2010-05-14 16:21:05) <- your block

When network recalculates difficulty, it takes time to mine the latest 2015 blocks (due to bug in code, it should take 2016). In our example, it would be:

2010-05-04 09:40:03 - 2010-04-21 21:52:52 = 12.491 days

In normal scenario 2016 block should be mined in 14 days. So, new difficulty:

11.46 * 14 / 12.491 = 12.844


In this case, you trusted Coinmotion during the hardfork and as you don't have the private keys, you can't really do anything. You need to hope that they'll accept BCH and BTG in the future on their site.

And their site says:

  The two options we plan to give our customers are as follows. When we are ready, each customer is presented with a choice.

  We can convert your BCH to BTC automatically and add the amount to your BTC balance.
      We can send the BCH to your own BCH wallet address outside Coinmotion.

  Our goal is to make BCH funds available in January 2018 at the latest.

https://coinmotion.com/blog/bcash-update/


What is the benefit of upgrading the wallet file?

The latest wallet.dat version is 0.6.0; wallet.dat didn't change with the 0.7 releases.

Wallet.dat version 0.4.0 introduced the wallet encryption feature.

Wallet.dat version 0.6.0 introduced 'compressed public keys', which make transactions you send smaller. Right now, that is the only reason you might want to run -upgradewallet, although even if you upgrade, you won't start using compressed public keys until you use up the 100 uncompressed keys in the wallet's keypool. You can force bitcoind to use up the old keys by running the 'getnewaddress' RPC command repeatedly.

Note that when you encrypt a previously unencrypted wallet bitcoind/Bitcoin-Qt will automatically upgrade to the latest wallet.dat version, because it has to re-write the entire wallet.dat file anyway.


Where can I get testnet Bitcoins in the year 2017-March?

https://testnet.manu.backend.hamburg/faucet
Try to give them back when you are done with them. Also a simple google search "testnet faucet" would have found you that site and similar ones.


The Bitcoin difficulty started at 1 (and can never go below that). Then for every 2016 blocks that are found, the timestamps of the blocks are compared to find out how much time it took to find 2016 blocks, call it T. We want 2016 blocks to take 2 weeks, so if T is different, we multiply the difficulty by (2 weeks / T) - this way, if the hashrate continues the way it was, it will now take 2 weeks to find 2016 blocks.

For example, if it took only 10 days it means difficulty is too low and thus will be increased by 40%.

The difficulty can increase or decrease depending on whether it took less or more than 2 weeks to find 2016 blocks. Generally, the difficulty will decrease after the network hashrate drops.

If the correction factor is greater than 4 (or less than 1/4), then 4 or 1/4 are used instead, to prevent the change to be too abrupt.

There is a bug in the implementation, due to which the calculation is based on the time to find the last 2015 blocks rather than 2016. Fixing it would require a hard fork and is thus deferred for now.

It is possible to give a rough estimate for the next difficulty change, based on the time to find the recent blocks. Nobody can make longer-term predictions for the future difficulty reliably, but anyone is free to speculate based on exchange rate trends, Moore's law and other hardware advances.


You are being scammed.

Individual accounts do not need mining, mining is required to secure the network as a whole.

This is a common scam, where they ask you to "invest" a certain amount into mining, and then string you along by asking you to pay more to unlock better returns, or unlock your keys, or whatever other nonsense they can come up with.

Cut your losses and write of the $300, do not send them any more funds.


BTC Transfer from One Exchange Vendor to Other Exchange Vendor

I've marked this as a duplicate of a 'my transaction isn't confirming' question, there is a lot of good info if you look at the answers there.

One additional note: when sending from one exchange to another, you do not decide the fee. The exchange controls the keys that spend the coins, so they will set the fee for you. If you control the keys of your coins yourself, then you can choose the fees when you spend your bitcoins.

Exchanges can choose to 'batch withdrawals', which means they will send multiple withdrawals to customers as a single transaction with multiple outputs. Batching a transaction allows the sender to pay less fees than if each transaction was sent individually.


How to install the latest bfgminer binaries directly from terminal without 'aptitude' on a raspberry pi 4 8gb running raspbian?

Update: sudo apt-get install bfgminer failed several times, as the same for sudo apt-get install cgminer.
After trying numerous times it finally worked!
No more need to download it from this website, got it.
Thread can be closed. Thank you anyway for your time! :)


Hunting missing Bitcoin from Multibit Classic

Should the private key for importing the coins show in the wallet?

Most wallets will not show you the private keys unless you explicitly request them in the menu. This is for security, because the private keys are all you need to spend the coins sent to the corresponding address, so they should be kept as secure as possible.

  So if I go export keys it should have two keys? Or is the wallet the only key that will be exported

Your wallet can have multiple private keys in it, usually one private key per address (at least for addresses starting with a 1). So the number of keys exported will just be the number of keys in your wallet. Your bitcoins will have been sent to one or a few of these addresses, other addresses might have no coins sent to them.

  and I can import that in to Bitcoin Core even though the imported key is not showing in the export and the keys, bitcoin address, history nor are my coin balances are showing in the wallet?

Yes, the keys are all you need in order to import the addresses into another wallet program like Bitcoin Core. The wallet will then calculate the corresponding address, and look through the blockchain for transactions sent to that address (as long as you import with the rescan option set to true).

  I had 0 transactions. Just imported, checked how many I have and value and left it only with install and again before changing HDD did I check and it then showed the balance.

What do you mean you had 0 transactions? In order to have any coins, they must be part of some transactions. Do you mean no transactions are displayed now, but they were earlier?


What would happen if a mining pool admins having majority of hash power turns evil?

After reading two papers: https://blog.ethereum.org/2015/01/28/p-epsilon-attack/ and https://www.cs.cornell.edu/%7Eie53/publications/btcProcFC.pdf I conclude, that the neither ETH nor BTC (and most if not all any other crypto currencies) are secure against such attacks. It is also not secure against a so-called Schelling scheme, i.e. attack made not by the party that controls a big pool of miners, but simply a party that has enough coins to bribe miners into mining his own double-spending block. If the attacker is able to bribe majority of the miners, such an attack can be zero-cost for the attacker.

Specifically, "The P + epsilon Attack" paper concludes:

  Of course, in practice, proof of work has survived despite this flaw,
  and indeed it may continue to survive for a long time still; it may
  just be the case that there’s a high enough degree of altruism that
  attackers are not actually 100% convinced that they will succeed – but
  then, if we are allowed to rely on altruism, naive proof of stake
  works fine too. Hence, Schelling schemes too may well simply end up
  working in practice, even if they are not perfectly sound in theory.

I hate to be a bearer of bad news, but the world with affordable, decentralized and deregulated finance services Ethereum and other cryptcurrencies bring might not be as secure, as we might want think.

Another sad update in this article: Decentralization in Bitcoin and Ethereum Networks, 11 Jan 2018


How to re-secure a multisignature wallet if private key is stolen

How do that re-secure their wallet and effectively revoke the information that Mallory has learned?

They would have to generate new keys and send the Bitcoin to the multisig address that uses those new keys. If Mallory has/had access to one wallet, she could record any and all keys in that wallet. Thus all keys in that wallet must be considered compromised and never used again. Any Bitcoin associated with those keys should be moved to a newly generated wallet that is not compromised.

  2) If BitCorp uses 2-out-,2 instead of 2-out-3 wallet, what steps can they take 'in advance' so that they can recover, even in the event of one of their servers getting broken into(and Mallory not just learning but also potentially 'deleting' the key material on that server)?

They can create pre-signed timelocked transactions that send the coins to another address that they control where those private keys are stored on separate servers. In the event that Mallory compromises and deletes the private key for one key in the 2-of-2, that transaction can be broadcast after the timelock and the coins moved to a new address where the private keys exist.


Sample proof of work in Ruby, what am I doing wrong?

A few things that need to be fixed here:

Endianness - The data given to you in JSON is almost completely in big endian but bitcoin uses little endian to serialize block headers before hashing.
You need to double hash the result with SHA256, meaning apply it once on the header and then apply the algorithm again on the result of the first hash.
Conversion to binary before hashing. You can't just hash the ascii characters, as those are just an encoding for the underlying binary, which is what is meant to be hashed.

I'm not very familiar with Ruby, but I made a short python script that you can use as a reference.

import hashlib
import binascii

def rev(string):
    revsed = ""
    for i in range(int(len(string)/2)):
        revsed = string[2*i : 2*i+2] + revsed
    return revsed

def DoubleHash(string):
    bin = binascii.unhexlify(string)
    hash = hashlib.sha256(hashlib.sha256(bin).digest()).digest()
    raw = str(binascii.hexlify(hash))[2:-1]
    return rev(raw)

# Straight from JSON

version = "02000000"
prev    = "000000000000000007c464352935f12c3695f7de4eee8390f444233682abf8aa"
merkle  = "14b2c974a4f9ab92a68f03a491965063d1f8a2e8b2268fdb4cbce92262bb09c0"
time    = "55078076" # hex(1426554998)
bits    = "18172ec0"
nonce   = "c3c1e61f" # hex(3284264479)

header = version + rev(prev) + rev(merkle) + rev(time) + rev(bits) + rev(nonce)

print(header)
print(DoubleHash(header))

The results:

02000000aaf8ab82362344f49083ee4edef795362cf135293564c4070000000000000000c009bb6222e9bc4cdb8f26b2e8a2f8d163509691a4038fa692abf9a474c9b21476800755c02e17181fe6c1c3
00000000000000001354e21fea9c1ec9ac337c8a6c0bda736ec1096663383429


Does listsinceblock list all transactions, or only transactions my wallet is interested in?

listsinceblock will only list txs your wallet is interested in i.e. transactions involving as input or as output an address A such that:

either A is an address whose private key is known to your wallet and consequently can sign transactions that spend UTXOs of A
or A is an address your wallet is following as watch-only i.e. does not know A's private key but A was added to the wallet using importaddress

listtransactions will also only return transactions your wallet is interested in but with different criteria. It returns count most recent txs of interest (as per above criteria) and you can also define to omit most recent skip txs and also filter by label (or account for older versions which is not deprecated).

All in all, following two should both return all txs your wallet is interested in:

bitcoin-cli listsinceblock <hash_of_genesis_block> 1 true

bitcoin-cli listtransactions "*" <a_number_greater_than_your_wallet_total_tx_count> 0 true

There is no direct way through CLI to return all txs in the blockchain afaik.


How do mining pools distribute work effectively?

Traditionally, pools gave miners work units covering the entire nonce range 0-4,294,967,295. When the miner finishes work, he requests a new work unit with a different extraNonce (or payout address). Different miners also get work units with different details.

To reduce load, pools are now moving on to a setting where the miner can himself change details of the generation transaction and compute the Merkle root, so he can do as much work as he pleases without needing new assignment from the pool.


Try adding the -std=c++11 flag.

I had the same problem and the following worked for me:

g++ -std=c++11 -o test test.cpp $(pkg-config --cflags --libs libbitcoin)


Where can I download bitcoin core version 0.16.0

As you've explicitly asked for Bitcoin-core 0.16.0 download link, Just went through the links for version 0.16.0 under bitcoin.org & bitcoincore.org & yes, links are broken!

So, even though I agree with Andrew that you may use other minor versions (e.g. 0.16.1, 0.16.3) without any loss, but when it comes to merely helping you to download your desired version, you've got a couple of choices:

Download the source files & Build the client on your own
Use the Docker container here & you will be up & running in minutes.


How to restore redeem script from a spent transaction?

If the P2SH output is already redeemed, then the transaction that spent it must have provided the redeemscript with the scriptSig in the outpoint to that P2SH output.

The last push of data in the scriptSig contains the whole redeemscript (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#Specification).

E.g. for a multi-signature the scriptSig that spends the output will be of the form:

scriptSig: 0 [signature1] ... [signatureM] {M [pubkey1] ... [pubkeyN] N OP_CHECKMULTISIG}

Where everything inside {...} is a push of that redeemscript which you just have to extract.


How do I prevent Bitcoin from synchronizing?

bitcoin-cli invalidateblock `bitcoin-cli getbestblockhash`

or

bitcoind -maxconnections=0


How can my private key be revealed if I use the same nonce while generating the signature?

Let me rewrite your question in a different notation, where all lowercase values are integers and uppercase values are points.

The group generator is G (a known constant).
The private key is q, its corresponding public key is Q = qG.
The nonce is n, its corresponding point is R = nG.
The X coordinate of R is r.
The hash function is h(x).
A signature is (r,s), where s is computed as n-1(h(m) + qr).
A signature is valid iff r = x(s-1(h(m)G + rQ)) (where x() stands for "The X coordinate of point ...")

Now for the two signatures it holds that:

s1 = n-1(h(m1) + qr)
s2 = n-1(h(m2) + qr)
s1 - s2 = n-1(h(m1) - h(m2))
n = (s1 - s2)-1(h(m1) - h(m2))

As s1 and s2 are just integers, (s1 - s2)-1 can be trivially computed using a modular inverse; there are no elliptic curve points involved here (over which this problem would be hard).

Once you know n, you can find q by rewriting the first equation:

ns1 = h(m1) + qr
ns1 - h(m1) = qr
q = r-1(ns1 - h(m1))

Substituting this in the earlier equations gives you:

q = (r (s1 - s2))-1(m1s2 - m2s1)


CGMiner freezing on anything above intensity 16

I eventually figured out this problem, and it was solved by lowering the voltage on the cards to 1100 or 1150.

Stock Sapphire 7950 boost cards are volted at 1250, and when running both cards concurrently it was making the system unstable and thus it would crash.  Even so, I would have expected a Corsair CX750 to still be able to handle them both, but it seems not.

Lowering the voltage through Sapphire Trixx makes the whole rig stable, and I can now run at 18/19 intensity without any problems. Heck I might even try 20 soon ;)

Hope this helps anybody out in the same situation.


Need to use two bitcoin core but issue with syncing

You can just copy the wallet files from node A to node B.

Note that this is not recommended and may result in strange behavior. You will not have any labels synced across the two nodes as they really are operating independently of each other. They just have wallet files that have the same private keys.

If you just want node B to have the transaction history from node A, you can import addresses from node A into node B so that node B is watching the blockchain for those addresses.


Will someone who has 1 of my old .dat files and who knows the old password be able to access my bitcoins?

Yes. Including bitcoins added anytime afterwards!
As far as I know, the password is used to encrypt the file contents (or at least the private-keys in it). So old passwords are still valid for decrypting old files that were encrypted before you changed passwords.


From where does the 2 hours limitation on bitcoin time stamp come?

I don't ever recall seeing an actual calculation for it, and I strongly suspect the reason is that it is "good enough".

The original, primary use of block timestamps is in difficulty calculations. They now also adjust the time for locktime transactions, but that's a newer addition.

A block's timestamps must:

Be greater than the median of the past 11 blocks (11 also seems to be a number chosen because it's good enough)
Within 2 hours of the network adjusted time

The network adjusted time is calculated by asking all your peers for their UTC timestamps, and if it's within 70 minutes of your own node, updating a network adjusted time median calculation over all the node times.

This imposes limits on how much a single node or miner can influence the time related parameters. Since difficulty adjustments look at the time between blocks and adjust to bring the mean down or up to 10 minutes, allowing for a very large variance may be counterproductive. 2 hours (to me) seems like a reasonable amount, since even if someone confuses DST time settings and has a bad clock, they would still be off in the range of 1-2 hours, on a reasonable system.

Of course, with ntp and other timekeeping services these days, nodes should be off a lot less. I've never heard of the 2 hour limit being insufficient, or of it being too large and causing issues with difficulty readjustment.

There are several things in the Bitcoin spec that exist because that's the way it was set up in the original implementation, and no pressing reason exists to change it.


Should I buy my Bitcoins now before a 2016 fork happens with Classic vs Core?

Buying advice is not appropriate for this website.

Actually the fork has become quite UNlikely. It was only a loud and ignorant minority threatening one. This has been cleared up and re-established at the round table talks: https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff#.paosf94p3

Judging by the spike in price after that news, I guess that has been factored in now.

In case a fork does happen, it's quite likely that both sides lose value, at least initially. Nobody likes uncertainty, infighting and chaos. So even if you sell off one side of the fork, the other side will also have dropped in value.

Note that IF you want to play such a game, you MUST make sure that you actually own the Bitcoins, which means they are in your own wallet and you have the private keys. If you leave the coins on an exchange when the fork happens, you are totally dependent on them not stealing/losing one side. And even when you do own the coins yourself, you still have to do some trickery to untangle both halves.


Can a smart mind explain block difficulty calculation in lay terms?

I am interested to understand that so I can understand what makes a block or a block chain more difficult than another. It is said that when a bitcoin client starts it chooses the most difficult block chain it sees.

In order to mine a block, one needs to attach work to the block header. If too many blocks are created, the requirement for work is increased, meaning the difficulty increases. When two chains are compared, the difficulty of each block is totaled up, and the chain with a higher score wins.


A 30 days old chainstate database does not make sense. Either you have the chainstate completely, and are able to do full validation, or you don't, and you can't validate at all. There is no middle ground of only validating recent transactions, as any transaction you encounter with unknown inputs could either be fraudulent or created more than 30 days ago, and you'll have no way to tell without a full chainstate.

So, either you don't need full validation, and you can use a number of lightweight clients instead, or you do, and you'll either need to build the chainstate yourself by synchronizing history, or copying from a source you trust.

Please don't go download a chainstate from a random place on the Internet though. They can introduce arbitrarily many coins assigned to themselves, and your client would accept them. If many people started running nodes using the same chainstate 'copy' such transactions could even get into blocks, and cause forks in the best case, and theft in the worst case.


Why is Public Key aggregation in MuSig described as a product of the public keys?

This is purely a matter of notation.
The points on the elliptic curve form a cyclic group. A group is a set with an associated identity element and a group operation. People need a symbol for that group operation. In some contexts it is more common to use an addition symbol (and multiplication representing repeated application of the group operation), and in other contexts it is more common to use a multiplication symbol (and exponentiation representing repeated application of the group operation).
Both notations are commonly used, and it has no effect on the actual operations. It's just a question of how to write what. There are even somewhat heated debates on this topic. You may even notice one of the MuSig2 paper's authors commenting in that thread.
One thing to point out that may explain this, is that the MuSig2 paper not ever mentions elliptic curves. It needs prime-ordered groups in which certain assumptions hold, but beyond that it could be any group - and the paper states, in Section 3.1, "The group G is denoted multiplicatively". This is the case for most cryptography based on the discrete logarithm problem: it works for any group. And historically, the first type of groups used for this purpose were integers modulo a prime numbers (with certain other restrictions) - where multiplication is the obvious choice for the symbol. You may also notice it is called the "discrete logarithm" problem, and not the "discrete division" problem.
At the same time, in the context of elliptic curves, you're right of course that the operation is called point addition - and repeated application of it is called point multiplication. I personally prefer it as well, as means you get a more obvious correspondence between scalar and group operations (e.g. s = k + H(R,P,m)x for computing a Schnorr signature vs s·G = k·G + H(R,P,M)·x·G = R + H(R,P,m)·P for verifying it, as opposed to Gs = R·PH(R,P,m) in multiplicative notation), and avoids sometimes nested layers of superscripts in typesetting.
EDIT: Tim Ruffing pointed out to me that the real reason for using multiplicative notation in MuSig2 is because the paper started as a revision of the MuSig paper, which also used multiplicative notation. The MuSig-DN paper uses additive notation, however.


Why is there sometimes no output that sends funds back to the sender's address?

You are confusing addresses and UTXOs. What you are talking about are addresses, not UTXOs.

The inputs of a transaction have no effect on the outputs. There is no requirement that a transaction must have an output that corresponds to an address that is an input. In fact, what you described first is known as address reuse which is highly discouraged. The behavior you see in the address you have a question about is exactly the kind of behavior that is encouraged: the change is sent to a newly generated address.


Why not just use Electrum instead? It's easy enough to integrate with an Electrum wallet, and it has a customisable lookup gap that can be as big as you need it to be.


How to make Bitcoin-Qt client portable? (Windows)

Put the bitcoin-qt.exe binary in the folder
Create a bitcoin.bat file
Open the file with notepad
Add the following line: bitcoin-qt.exe -datadir=.
From now on you can start by double-clicking the bat


The problem was with windows firewall. Turned it off, tried again, it worked. Turned it back on and set the appropriate windows firewall exceptions for stratum_proxy and cudaminer and it worked.

I had this problem suddenly appear again this morning. Turning off firewall made no difference. I changed cudaminer to point to my machine ip address instead of 127.0.0.1 and then it started working.


Unconfirmed transaction, cannot see money in receiving account

Barring chain reorganizations, valid transactions are binary: either they are confirmed, then your money has been signed over to the recipient, or they are yet unconfirmed and your funds are still unspent.

A transaction can remain valid but unconfirmed indefinitely, if the miners never chose it for block inclusion.
Most wallets have a mechanism to forget unconfirmed transactions in order to be able to spend the funds elsewhere. When any of the funds used for the original transaction are used, the original transaction ceases to be valid.

Addresses do not become invalid after some time, and generally services keep records to associate addresses with the corresponding users even if an address didn't get used for a long time after it was generated.

For more general information on how to deal with unconfirmed transactions, please see: Why is my transaction not getting confirmed and what can I do about it?


Download the official wallet : https://vertcoin.org/wp/get-started/
Then, install it and wait for full sync (aka vertcoin blockchain download)
During the sync, look how to build a simple appropriate vertcoin.conf file which had to be store in the appropriate vertcoin folder (%appdata%/vertcoin in windows)It basically look like this :

rpcuser=WORKER

rpcpassword=SUPERPASSWD

rpcport= X // CheckDefault rpcport vertcoin

daemon=1

server=1

listen=1

Then restart your wallet (node)
Download the appropriate miner according to your hardware configuration https://vertcoin.org/wp/mining/

Create a batch file

sgminer -o 127.0.0.1:rpcport -u WORKER -p SUPERPASSWD -I 13

Make sure to be fully synchronized with the vertcoin network before start it.Hope for the Best
It's not an exhaustive solution but it gives you a good overview about how to set up a solo mining configuration


How to transfer only the blockchain to a friend's computer?

Transfer everything except wallet.dat and the database folder.


What would be the process for identifying a person that performed a transaction from a wallet on a personal device?

The block chain doesn't report the IP address and the IP address isn't passes by nodes.  Any entities knowledge of Bitcoin network is limited to the connections it has.  If you get a transaction from a specific IP address you can't know that IP address originated the transaction you simply know it came from that IP address.  It was either originated or relayed by that node.

The more connections you have to the network the more information you would have about where an transaction originated.   However no matter how many connections you have you can never know you have a connection to every single node, thus all you can know when you see a specific transaction is that node at IP address X is where the transaction was first seen.

You can never be 100% sure of the originating node as you can never be 100% sure you have connections to ever node in the network.

Someone concerned about privacy could restrict the nodes they send transactions to only nodes they trust.  This would ensure that at most (unless they trusted you) you could only find the node that relayed the transaction not the originator.

Someone concerned about privacy could also route their transactions via VPN which would add another layer.  The connection couldn't be traced further back than the VPN gateway without the assistance of the VPN providers which likely would require a court order.  If the VPN provider was located in another country that would make enforcement even more difficult.

Using both trusted nodes (using web of trust like fature), and VPN which doesn't keep logs in a foreign country would make tracing the source of the transaction very difficult.

I find it unlikely that many courts would issue a warrant based on only the IP address of the "node transaction was first seen" as it really is proof of nothing.  The actually originator could be that node, a node which relayed it to that node, or a node which is x hops further down the chain.

Lastly a transaction is simply a sequence of bits. There are websites which act as dropboxes where a user can post a transaction in text form and the website will relay it to the rest of the network.  While this isn't particularly secure one could create a similar service on Tor and possibly require transactions to be encrypted with a public key of trusted operator reducing the likelihood of tracing the transaction back.

Of course the drop box method could be combined with trusted nodes, VPN access, and using a public internet wifi location to further obfuscate the source.  It really depends on how paranoid the sender is.


What type of port protocol do json-rpc and p2p use? does it use TCP or UDP?

Both use TCP.

  If possible, can you config or reprogram the open-source and compile the source to use TCP only if it also uses UDP?

Certainly. It's open source, you can change whatever you want.


Using NBitcoin or C# to derive Litecoin and Ethereum Addresses from Master HD Key

Not sure how NBitcoin works, but it looks like so far you have derived your private and public key, you now need to hash it in the Ethereum method rather than the bitcoin way.

Look at step 3 in this answer: https://ethereum.stackexchange.com/questions/3542/how-are-ethereum-addresses-generated

Edit:
Nethereum has implemented it in C#: https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Signer/EthECKey.cs#L115


Is it technically possible to create and use dynamic private key - public key pair and use it with bitcoin?

No, it is not possible to do what you are suggesting.  Here's more info about cryptography.

You can create create an ECDSA keypair with almost any random data (it must a lower than a certain value, but go check ECDSA specs) and then generate an address... But a keypair will always be valid to receive bitcoins or send them (if you still have the private key).

The thing is that a other party will not be able to know what is your next address since you need the private key to do that.

So yeah you can create keypairs with almost any data, but I don't think it'll be dynamic in the way you think.


Which wallet can I use to store all my cryptocurrencies ?

Jaxx is a multi-currency wallet. Hardware wallets like Trezor and Ledger support multiple currencies as well.


Is there any chance of the Ripple gateway market NOT consolidating into a small transnational oligopoly?

That wouldn't really be a bad thing if they were reliable and kept costs down. But I think it's inevitable that, if Ripple catches on, small gateways will always be around at least to serve more remote and underbanked areas and populations that transnationals can't be bothered to target.

However, I don't think the barrier to entry will be that high. You might think that a small company couldn't compete with a larger company because trust is required. But actually, a gateway can operate without people trusting it. The gateway can basically resell another gateway's IOUs for cash. And for getting cash out, the gateway can accept other gateway's IOUs. I think there will always be "gateways" of this type selling and buying IOUs in person.

Over time, if the gateway continues to operate reliably, people will hold its IOUs. This is especially likely if the gateway offers some advantages such as a lower transfer fee or the ability to costlessly exchange their IOUs for IOUs from a number of other gateways.

Of course, transnationals may be able to eliminate this opportunity by providing their own costless inter-gateway exchanges and keeping their own transfer fees low. But if they serve everyone at low cost, nobody should much care that there isn't much competition.

A model that I frequently use to think about the relationship between gateways is Internet service providers. They compete with each other, but if they don't also inter-operate with each other, none of their customers will be happy and they will move to other providers that inter-operate with their competitors better. Small Internet service providers don't exactly compete on a level playing field, let's be honest, but they still have little problem finding niche markets.


Easy.
Someone has/had remote access to your wallet/files.  They don't need access to the computer during the time of a transaction.  Example:  Send me your wallet and go ahead and secure your computer all you want.... I can simply use your wallet on my machine and spend the funds.  Also, it doesn't need to even be your wallet as I would only need your private key or your seed.   It's likely your computer is infected, they downloaded the wallet, and simply waited to withdraw.

No, you can't get your bitcoin back.  Once gone, it's gone.

The fact is, your computer wasn't always offline since you admittedly used it to download the wallet software.

What you should do?  Well, nothing about the bitcoins that are gone, but know that you should never use that seed/wallet again.  It's already compromised.
Again, what you should do?  Get a hardware wallet like Trezor and know that even if your computer is infected with a virus, your coins are still safe.  (As long as you don't backup the seed via notepad on the computer.)


Which command line software tools are required to mine litecoin

You have miners on command line like sgminer or cgminer. You can use this with a GUI but it is not a requirement.

You can find usage guide on previous link.
Exemple for sgminer. After you build it and install it, you simply have to execute this command to lunch mining :

sgminer -o http://pool:port -u username -p password

Replace :

pool by adresse of your pool
port by the port of your mining pool
username and password by your pool login.

If you want more information check official github of these projects


I use Litecoin Core wallet on my PC and need to have it on laptop to take away on holiday

Yes.  You'll need to backup the wallet.dat file from litecoin core on your PC, transfer it to your laptop, then replace the wallet.dat file in your laptop with the one you grabbed from your PC.

How to Backup Litecoin Core

Open Litecoin-QT
File-> Backup Wallet
Save it
Grab a USB
Drop the newly saved wallet.dat file into the USB

How to Insert wallet.dat into New Litecoin Core

Download Litecoin Core but do not open it.
Open your file explorer and type the following line:
C:\Users\YourUserName\Appdata\Roaming\Litecoin
Delete the wallet.dat file in the Litecoin folder. Rename your wallet.dat file from your PC to "wallet.dat" if you need to.  Drop it in the Litecoin folder.
Open Core and if you see unconfirmed tx it worked.

Another Option

You can dump priv keys to the addresses that received LTC and sweep it into Electrum-LTC.  Only download this from Electrum-LTC.org.  Electrum-LTC is a light-weight client that references other Full Nodes so you don't have to use your own.  This means you don't have to keep your laptop on to stay up to date with the most recent blocks in order to send LTC.  But if you want to keep supporting the LTC network by running Litecoin Core, then kudos to you!

How to Dump Priv Keys from Litecoin Core

Go to console in Litecoin-QT
type: walletpassphrase "your walletpassphrase here" 600
type: dumpprivkey [your Litecoin address here]

Sweep into Electrum-LTC

Open Electrum-ltc. Go to Wallet-> Private Keys-> Sweep.
Input the private key and an LTC address you want to send it to. Often times, Electrum-LTC provides one for you.


Running a store through Tor - what are the setup options available?

Try using bitwasp. It seems to provide a lot of features you need. Try it and let us know if it works.

https://github.com/Bit-Wasp/BitWasp

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


How do I scan my bitcoin receipt into my wallet?

Using the blockchain.info app go to your address book (menu button in top left).. then when in the address book click the same top-left menu button and you'll see the import private key option. Scan the QR, job done.

Alternatively use a QR scanning app such as QRDroid and then you can copy & paste the resulting private key into anything you like.


What keeps bitcoins mined in testnet from being used in mainnet?

Yes, that's correct. A mainnet node would just see those transactions as invalid because the outputs they attempt to spend are not in its database. It would have no idea that there is some other network on which they are valid.


What is the use of hashing the public key to obtain the bitcoin address?

Early renditions of the Bitcoin client did use raw public keys in this way for pay-to-IP-address transaction orders, it's still valid to spent an output to <raw pubkey> OP_CHECKSIG, though miners might not be willing to include it in a block.

Before an output owned by a fresh address is spent, the hidden public key points are unknown to anybody but the creator. If the situation arises that ECDSA is weakened there is only minimal exposure between signing a transaction and having it included in a block. To transition from a weakened ECDSA a new signature algorithm would be soft-forked into the consensus and outputs quickly shuffled over to using it instead. This bit of protection is effectively gained for free so it would be silly not to use it, though some wallets choose to re-use addresses multiple times which destroys the protection offered by this system.

As pointed out addresses are also appreciably shorter at 20 bytes rather than 33 or 64 bytes, which makes a difference if you have the need to manually transcribe one.


It is part of the basic concept of Docker that Docker assigns an IP address for you to the container.

But maybe this isn't what you are asking?

From what I can see on your screenshot, you have certain port mappings active, as listed under "PORTS". You should be able to access those ports under the IP of your Docker host as Docker will expose those port for you.

In other words: More often than not, you don't care about your container's IP address at all.


How do fees get processed in bitcoin? (protocol question)

how does the miner prove he has access in his wallet to the fee amount?

Miners do not prove this.
The ability to reap the difference in inputs and outputs in a coinbase transaction is baked into the bitcoin consensus rules.
Any miner who was lucky enough to find a block can sum all the differences in included transaction inputs and outputs in a block and aggregate them in the coinbase transaction.

The miner can then spend the coinbase outputs 100 blocks later.

Edit #1: @eponymous's comments regarding potential reduction in bitcoin supplies if miner does not reap all transaction fees.

Suppose a miner elects to not reap all the difference in inputs and outputs in a coinbase transaction, then the supposedly total supply of bitcoins will be reduced. The 21M bitcoin supply is a theoretical limit that assumes that all miners reap all potential transaction fees and block subsidy rewards.

Example: Total difference in inputs and outputs is 1 BTC, but miner reaps 0.9BTC. Then 0.1BTC will be lost from circulation.

Edit #2: Included @pwuille's excellent explanation on the existence of 21M bitcoins


How does a node get information from other nodes?

get set of UTXO.

Note: nodes don't download the UTXO set directly, they download the entire blockchain and build their own UTXO set as they verify the blockchain.

  How does a node tell other nodes these requests?
  Like git, are there commands like 'pull requests'?

Nodes communicate with each other directly via a P2P protocol, sending different types of messages to each other to retrieve different types of information. You can take a look here for the specifics of each message, https://bitcoin.org/en/developer-reference

  Where does a node get information from?
  I believe blockchain is decenterlized and all information is in the hands of all nodes.There must not be centerlized database.
  Then, how does a node decide who is reliable to get information from?

Nodes will ask multiple neighbour nodes for information at once, rather than just trusting a single other node. It can then use the longest chain from all its neighbours, so as long as it connected to just one honest node it will be able to download the blockchain. This is very likely because the nodes it connects to are randomly selected from a set given to it by a DNS server


Why does an adversary have to control 50% of the computing power to double spend?

There are two assumptions in your question that aren't completely correct.

1) Each node would then require 68 minutes to find a proof of work (trying 2^52 hashes).

The process of finding a new block is not a linear task of work that needs to be accumulated. Rather it is a random process. Instead of a pile of work you are going through that has a fixed size, you could think of it as a lottery: Each try can win, but in average it takes 2^52 tries to win. This distinction is very important, because…

2) The honest nodes on the network do not work in collaboration.

…it allows the network to collaborate without coordinating!
Every mining entity is trying to confirm a different block. This is so, because each is trying to claim the block reward for themselves, therefore at least one transaction, the coinbase transaction, must differ.¹
So, since we have established that we are looking at a random process, and everyone is working on different data, we realize that the honest nodes are not duplicating each other's work. Therefore, all the honest nodes are going through a lot more inputs together than the adversary, and in effect are collaborating at finding a new block.
As cpast has pointed out in the comments, it is also very important to realize that nobody loses progress by switching. Therefore, only the time that the block requires to propagate through the network is lost, and everybody will switch to the new block with the one just found as a parent as soon as they receive it.
Finally, this means that we need to compare the mining power of the honest network with the adversary's mining power in order to see who can create the greater chain. And as you have said yourself, with your exemplary numbers the network is 2^15 times as powerful than the adversary.

¹ Also, they can be working of different sets of transactions, the transactions will be in a different order for different miners, the timestamp changes every second, and they add more random data to try different inputs.


First of all, "real value" is a questionable term. Some people deny a concept called Intrinsic Theory of Value. Anyway I can give us some reasons:

1) Limited supply and increasing demand

Bitcoin (as some other cryptocurrencies) has a fixed supply, which is currently 16,8 millions of units but it is going finish in the next years, when it hits 21 millions of units.

This supply of units is totally public through its ledger, which brings us an authentic and transparent scarcity.

According the classic economic model of Supply and Demand, if the demand increases and the supply does not increase in the same speed, the price will increase.

2) Bitcoin is a more effficient payment system

You can send an amount of money for an relatively small fee in a short time. The current systems simply can't send 3000 USD from NY to Japan in 10 minutes for 2 USD less than 1 USD and the next updates can make it cheaper and faster.

3) High liquidity and media coverage

Anyone can trade relatively small amounts of bitcoin in Internet. It doesn't have the same limitations or restrictions that other markets have, like trades with minimal amounts. It has more liquidity than stock market, as you can trade in smaller positions.

So, if the Bitcoin market is bullish it trends to be really bullish, specially when media coverage show how bullish it is and much high it is performing, which brings more interested people to the market - even people who doesn't know exactly how Bitcoin works, how its blockchain works, etc. It happened specially during 2017. So we have an explosive scenario, where:

Bitcoin price increase much more than other investments in the same
timeframe
Media coverage about Bitcoin performance increases people
curiosity
Bitcoin is easy to trade in relative small amounts and
people buy some Bitcoin
Repeat.


What is the Witness and what data does it contain?

This structure contains data required to check transaction validity
but not required to determine transaction effects. In particular,
scripts and signatures are moved into this new structure.
The witness is a serialization of all witness data of the transaction.
Each txin is associated with a witness field. A witness field starts
with a var_int to indicate the number of stack items for the txin. It
is followed by stack items, with each item starts with a var_int to
indicate the length. Witness data is NOT script. See BIP 141.

Witness data depends on the type of transaction.
Input 3
Looking at transaction input #3 in the raw json:
script = a914771962306e72e479245d48e879dd2a1862225b4c87
This has the structure of a Pay to Script Hash (P2SH) transaction. Because of the witness data, this is probably a multisig P2WSH nested in BIP16 P2SH:
witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig:    <0 <32-byte-hash>>
              (0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
              (0xA914{20-byte-hash}87)

witness:
04 (4 stack elements)
00 (1st stack element, 0 Bytes)
47 (2nd stack element, first signature, hex: 0x47 decimal: 71 Bytes)
304402202c3f94e5daf4057377d9f16d45b57e962de42fb42cb7e95a0382b7c66624980a02204098f6acd43b0391ea1b4a8102797e78895848fb7e883f98d207d14d45945a6901
47 (3rd stack element, second signature, hex: 0x47 decimal: 71 Bytes)
30440220448460edd5291a548c571ccf3a72caf47b02364035dc84f420d311e3a0c5494802205bb1cc89f20dc1e2c1f6eadb74898f8eecc46fbf488b676636b45fafaeb96e0f01
69 (4th stack element, 2-of-3 multisig script, hex: 0x69 decimal: 105 Bytes)
<52 OP_2>
21  (33 bytes)
<021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe pubkey1>
21  (33 bytes)
<03bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38 pubkey2>
21 (33 bytes)
<0280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c65 pubkey3>
<53 OP_3><ae OP_CHECKMULTISIG>
Note that the OP_2 and OP_3 indicate this is a 2-of-3 multisig transaction script.  See Pay-to-Script-Hash | Transaction


What is stopping me from modifying the mempool of my node (may it be PoS or PoW)?

Transaction signing process involves signing the hash of the entire transaction data as a message in the ECDSA signature. So, if you modify the transaction outputs or any other data then it will render the signature invalid. If you include this transaction in the block, mine it and then relay that block, the other full nodes will see that a transaction included in the block is invalid (since it has invalid signature) and reject the block. So you will lose the block reward even after spending huge amount of electricity and compute costs to mine it.

However, having said that there can be transactions that can be signed with SINGLE or NONE sighash flags. The SINGLE flag commits to only one output, while the NONE flag commits to none of the outputs. If those flags are set while signing the transaction, then the miner can modify other outputs.


How does `createrawtransaction` and `fundrawtransaction` work with Elements?

Ok it turned out I was a bit confused about the way fees and change is handled here. Here are the commands that worked for me:

createrawtransaction "[]" "[{\"$UADDR\":1.2},{\"$UCHANGE\":1.8}]" 0 false "{\"$UADDR\":\"$ASSET\",\"$UCHANGE\":\"$ASSET\"}"
fundrawtransaction $RTX "{\"changeAddress\":\"$UFEECHANGE\",\"includeWatching\":true}"
blindrawtransaction $RTX
and then on the signing side signrawtransactionwithwallet $RTX

Some comments:

the change address given in the fundrawtransaction command is actually used for the change of the fees paid in L-BTC, since here fees are explicit, not like in Bitcoin. That's why I added an explicit change address and amount for the asset I was sending.
I used unconfidential addresses to create the raw transaction
includeWatching is not implicitly true like in a bitcoin watch-only wallet
the tx worked, it was broadcasted and accepted by the network, but there's still something wrong with the blinding, the destination output has not been blinded, and on the other hand I messed up the change of the fee, it seems I can't unblind it myself


A pool will generally create a unique merkle root for each getwork request by a miner.  If it accepts difficulty 1 shares, the miner can spend an average of about 4,000 Mega-hashes on that block (and will earn an average of 1 share per getwork).

To create a block header for each miner, the pool operator changes some unique information in the first (generation) transaction of the block, and then rehashes the block to create the merkle root.  If done naively, this will take O(N log N) sha256 hashes (where N is the number of transactions in the block being mined).  By saving some information from computing the last merkle root, you can recalculate a change in the generation transaction with only O(log N) hashes.

With hundreds of transactions per block the ratio of hashes performed by the pool operator and the miners is over 100 million to 1.

For an even greater savings, pools can accept a getblocktemplate api request instead of a getwork request.  This mode allows the miner to generate his own block headers and mine for an average of 10 minutes before needing to be refreshed by the pool.


How can I find out what happened to my transaction?

I'm assuming by asking where the payment went, you're asking how to find the transaction output address. If you have the transaction ID, you can search for it on a site like https://blockchain.info/. Then look for the output address.

If you don't have the transaction ID, but you have your original Gladiacoin wallet address, you can look up the Gladiacoin wallet address on https://blockchain.info/ and see what transactions were made that way.


How to retrieve unspent outputs on mSigna

Can you please send the sharedacct file to support@ciphrex.com? Thank you!


TorCoin
is an alternative cryptocurrency, or altcoin, based on the Bitcoin
protocol [8]. Unlike Bitcoin, its proof-of-work scheme is based on bandwidth
rather than computation. To \mine" a TorCoin, a relay transfers bandwidth
over the Tor network. Since relays can sell TorCoin on any existing altcoin
exchange, TorCoin e ectively compensates them for contributing bandwidth
to the network, and does not require clients to pay for access to it.

For more info, see the white paper on TorCoin.


How to make Abe query MySQL instead of reading from the bitcoin block.dat for each request?

I'm still loading the blockchain into my database, but are you starting Abe with the --config option pointing to your configuration file?

See line 49 in https://github.com/bitcoin-abe/bitcoin-abe/blob/master/README-MYSQL.txt


How does Bitcoin makes sure that nobody can duplicate a transaction?

However, what is stopping someone, for example the recipient of the original transaction, to simply send in the same exact transaction with the same data and signature?

Bitcoin does not have the concept of account balance but works on the concept of unspent transaction outputs (UTXOs). Each output of a transaction (except OP_RETURN ones) lead to the creation of a separate UTXO. When you create transactions in Bitcoin, you consume these UTXOs in entirety and create separate UTXOs. This is done by referencing the outpoint (txid and n) from which you 'earnt' these UTXO. For example, if you control 2 UTXOs (1 BTC and 0.5 BTC), and you want to send your friend 1.25 BTC, you would have to consume both your UTXOs and send the remaining change of 0.25 BTC to yourself (neglecting tx fees). So if the recipient of a transaction output tries to broadcast the same transaction again, the Bitcoin nodes when verifying the transaction would find that these utxos do not exist and hence the transaction is invalid.

When full nodes start syncing from the Genesis block, they start to build the database of all these UTXOs. Every transaction involves removing spent UTXOs and adding new ones. These database is stores in chainstate directory and aggressively cached in memory.


Bitcoin-qt is trying toload to C drive instead of my D drive

You can create a bitcoin.conf file that specifies datadir=(your/desired/filepath) in order to override the default data directory location.


Why are there no Bitcoin price/trade records before 2013?

This is a fascinating question and good catch. The only chart I could find listing anything before 2013 is 99Bitcoins. TradingView history begins in May 2014, and CoinMarketCap goes back to May 5, 2013. The bigger exchanges I checked don't go back that far except for Bitfinex, which starts in January 2013, and for dates during that period Bitfinex only charts weekly changes.
I don't have a definitive answer but will offer two possible explanations. The first is that this lack of price data is related to the March 12, 2013, "accidental hard fork" caused by an undiscovered inconsistency between versions 0.7 and 0.8.0, when a block created by a miner running the newer version was considered invalid by miners running the older one. This would mean that for a short time there wasn't a way to define a price because there wasn't consensus about what wallets held which coins (which led Mt. Gox to temporarily suspend deposits with a subsequent crash in exchange rate).
But the more plausible explanation for why there aren't trading records or a price prior to 2013 is that for there to be "a" publicly available price for any exchangeable asset, there has to be some sort of public market for the asset. BitcoinWiki has a table of prices for periods before 2013, but before March 2010 the price is listed as "basically none." The page also says that on Oct 5, 2009, the first public sale was offered on the New Liberty Standard stock exchange (at a rate of 1 USD/1,309.03 BTC), which is also mentioned in this review of Nathaniel Popper's Digital Gold: Bitcoin and the Inside Story of the Misfits and the Millionaires Trying to Reinvent Money. So before October 2009, there literally wasn't a price (if by "price" we mean the exchange rate denominated in fiat currency). There were no trades (denominated in fiat), hence no trade history.
On March 17, 2010, the first online market exchange, BitcoinMarket.com, began operating. Mt. Gox launched the same year and by 2014 was the largest exchange. Although both companies are now defunct and their trade histories (presumably) not publicly available, 99Bitcoins does list "the" price of bitcoin going back to the day BitcoinMarket.com began operations. For these two companies there likely isn't a publicly available record of trades that would allow for an accurate calculation of an average exchange rate in fiat currency for bitcoin before still-existing exchanges began publishing their trade histories. Exchanges may only publish pricing information from the date they begin operation, and the USD/BTC exchange rates on TradingView are all based on particular exchanges, which is why even their aggregate data may not go back before 2014.


What are the pros / cons of using Electrum 3.3.2 over Bitcoin core 0.17.1? And what about running your own Electrum Server?

Using Electrum has some advantages and disadvantages over Bitcoin Core. Electrum is a bit more feature rich than Bitcoin Core. It supports hardware wallets, 2 Factor Authentication with a third party paid service, (better) multisig, and mnemonic phrases. There's probably a few other things that I've forgotten. However Electrum comes at the risk of decreased privacy and security. You are sending all of your data an Electrum server. That server knows all of your addresses and your transactions. That server can also withhold transaction information or refuse to relay transactions that you make. Electrum servers can also currently push malicious phishing messages to your Electrum wallet. That issue is currently in the process of being fixed (it requires a protocol change).

If you use your own server, there are a lot of benefits. If you trust that the server software is not malicious, then you won't have the cons mentioned above. Your transactions will be private and the server won't be withholding or refusing to relay transactions because you control it. Since it is your own server, you can have Electrum installed on multiple devices pointed to that server too. However running your own server has a cost. It requires a fully synced bitcoind with transaction index enabled. The electrum server will also maintain its own indexes. Overall, the setup can use over 250 GB of disk space, possibly even 300 GB. It also takes a long time for it to sync and build all of the necessary databases. Running an electrum server also uses significant CPU and RAM especially during the initial setup.

If having the full blockchain with additional databases is too much, you could instead use Electrum Personal Server. This is like running your own full blown Electrum server but only for your addresses and transactions. It can run without transaction index and be ran with a pruned bitcoind so you don't need to store the whole blockchain. With some manual configuring, you can also use Electrum Personal Server with Electrum wallets on multiple devices.


How does a bitcoin transaction enter the network?

I'd suggest you read this blog post about using the raw Bitcoin protocol: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html

To answer your question, you should specifically read the "How to find peers" section of that post. Specifically this part:

  There's a chicken-and-egg problem, though, of how to find the first
  peer. Bitcoin clients solve this problem with several methods. Several
  reliable peers are registered in DNS under the name bitseed.xf2.org.
  By doing a nslookup, a client gets the IP addresses of these peers,
  and hopefully one of them will work. If that doesn't work, a seed list
  of peers is hardcoded into the client.

and

  The hardcoded peer list in the Bitcoin client is in chainparams.cpp in
  the array pnseed. For more information on finding Bitcoin peers, see
  How Bitcoin clients find each other or Satoshi client node discovery.


What has happened with the investigation of mtgox.com?

AFAIK, the latest official news is the article After the CEO’s Indictment the Great Mt. Gox Bitcoin Mystery Deepens from the 14th of September 2015, and these two tweets:

  PDG #Français de MtGox,banque #BTC basé à #Tokyo sera condamné sans jugement sur des charges n'ayant aucun lien avec disparition 50,000,000$ – @NathalieStucker (Jan 7th 2016)

and

  30歳のフランス人が6ヶ月間以上東京の #刑務所 に #永遠 と取調べられてるため、#外国メディア は日本の #司法制度 に #疑問。23日間の #保管期間、#人権 にかかわる。– @NathalieStucker (Jan 9th 2016)

You can follow Nathalie Stucky on Twitter @NathalieStucker and as a contributor on Daily Beast, she seems to be the only one interested in truth and justice on this topic.

Now a few unofficial news, AFAIK Mark Karpelès hasn't been allowed any visits, not even contacts with his family and is not allowed to use a computer either.
 He already lost 35 kg but still hasn't accepted to be the scapegoat, which seems to be why he's still detained after more than 4 months, without any trial or official charges…


How much memory and bandwidth does bitcoind take up on a CentOS Linux system?

I run bitcoind 0.8.3 on a VPS. In May and June, the VPS used between 250 and 300 GB of bandwith per month. Most of that (~98%) was incoming traffic.

I'm not sure if all traffic is due to bitcoind. Of course, we ran updates on the server. But it is only used for bitcoind. No other webservices are active.


You can add the bitcoin address to the search field at blockchain.info and you should be able to track any incoming transactions to that address.

https://blockchain.info/address/1BF8SHKnT8ZysYNrj5toeu6DsuGE5XDcCR


If SHA256 were compromised tomorrow, would Bitcoin collapse, or is there some contingency plan to move the network to a new hashing algorithm?

As Meni mentions, there are ways to change the hashing algorithm used for Bitcoin. For this change to be made, all clients would have to be updated and the blockchain would look very weird as it would still contain all historic data that used SHA256.

However, when some party from one day to the other can manually create collisions, as I think you suggest with "compromised", they will only be able to send bitcoins from all existing addresses if also RIPEMD-160 and ECDSA will be compromised. These three algorithms are used to create the address from a private key.

SHA256 has more significance in mining. But still, I think the ability to manually create SHA256 collisions won't help you much with mining. When mining, you hash a bock that has a certain formatting. This hash must satisfy certain conditions in order to be accepted. So what you would be able to do when you compromised SHA256 is take a valid hash and look for different plaintexts that result in this hash. However, the chance that this plaintext has a valid block format is very low. I'd guess myself it is even smaller than the chance to find a valid block in the regular way of mining.

(Can anyone please verify this conclusion?)

Concerning address generation and generating address collisions, I once read (sorry I forgot where), that it is indeed the plan to change the hashing algorithm if the mining ecosystem evolves to a certain point. Currently searching for hash collisions is far less profitable than mining. But finding a collision can earn you more than one block reward. So what I read was that as soon as collision finding is no longer discouraged enough by being so much less profitable than mining, a change of hashing algorithm will be necessary. This change will probably make address generation harder.


What happens if everyone suddenly adops bitcoins, or it becomes very easy to create blocks

Increased demand would raise both the price for bitcoins as such, and also increase the fees rewarded to miners. So the effect would be an increased investment in mining efforts.

Technology advances would increase the networks total Hash/s rate. Which first of all would lead the network to rebalance and demand more hashes/BTC, thus keeping the output constant.

The dynamic aspect I find interesting though, is that until all miners have upgraded their relative contribution to the network would shrink, and thus their individual share of the return. They would therefore be force to choose either to quit mining (operating costs would be higher than the return) or invest in new hardware. Which in effect would lead to a pruning of miners and a reconfiguration of relative performance among the remaining.

I wonder if the economy can sustain a long tail of miners or if the major players will use such transitions to invest in enough hardware to raise the barrier to entry beyond the tail miners returns.

It would be interesting to see a simulation on http://insightmaker.com/


What would you do while a hard fork lasts?

A contentious hardfork (where some portion of the network doesn't agree to modify their consensus rules) is effectively a doomsday scenario, there's no making this safe or making tools which allow you to transact on two chains simultaneously with no ill effect.

  This almost happened once before, and the miners picked the fork that solved the problem (a fork that would otherwise have lost, mind you).

That does not reflect current understanding of how BIP50 operated.

The chain abandoned by human intervention was actually the correct one, the decision was made just because a majority of the networks nodes were using buggy software that would have had to have been updated very quickly. Nodes running 0.7 or earlier software could randomly fail out of consensus (with 0.8, or even just with other nodes running the same version) depending on their own environmental influences.

It's a little out to argument if fixing the implementation was a hard fork or not, but BIP50 is not an applicable example for gaining knowledge about how the network might operate under intentionally changed operating conditions.

  How long do you think it would take for bitcoin clients to appear that would ensure that your transaction is broadcast to both forks so that anyone seeing only one chain would see your transaction?

There is no scenario in which two networks can continue to happily operate in unison.

The two chains of differing consensus rules will fall out of synchronization. Inevitably due to a single transaction not confirming, being mutated between the chains changing the TXID, or someone spending a coinbase output, transactions on one side will become invalid where they would otherwise be valid on the other.

Rebroadcasting your transaction doesn't mean anything if it literally cant't exist in both chains, no wallet vendor will bother doing this for the extreme amount of development time required to make it work functionally, and the high amount of user confusion it would cause.
Clients on one side (or both) will ban their peers for not following consensus rules. This is part of a long list of denial of service attack prevention measures which include sending invalid blocks and wasting validation time on something that can never be accepted. Nodes that disable this rule may find that they reorganize onto different chains and flip flop between them
If two fictional companies Coinbarse and Bitflinux decide they will follow alternate chains, then there is an opportunity for every Bitcoin owner with an account on each to double their money. Simply sell your BTC twice for USD on each chain and you've got double the USD you would otherwise, the markets clearly couldn't survive this sort of behavior one way or the other.

  The worst people using bitcoin generally rely heavily on irreversibility, and the best people nearly always have some way to re-do any reversed transaction (rebroadcast is built into the standard client)

That does not accurately portray the behavior of the system, and I'm not sure how that couples with "worse" people. If somebody pays you with a mature coinbase output which is reorganized out of the chain, then you are stuck without your money no recourse.  If someone pays you and an alternate payment included in a different block, then you are stuck without your money no recourse. The vast majority of users do not use wallets which rebroadcast transactions, and in almost all scenarios where payments could be reversed there is a high probability that they could also become invalidated as well.

The simple answer is just that if you don't want dangerous and undefined things like this happening, don't go along with the belief that 75% of the mining hashrate is "consensus". Work towards solutions which don't actively destroy the ecosystem, and have complete agreement on their implementation and execution.


Using Bitcoin or another Altcoin for Decentralized Database Storage

Yes there have been some proposed ideas such as FileCoin, Storj and probably others. However, I'm not sure how well these systems work because there would need to be a way to prove to other peers that you actually are serving the piece of data. Some call it proof-of-storage, others proof-of-retrievability. But it's still an open problem that nobody seems to have solved yet. I mean, this is probably why both projects I mentioned above aren't ready yet.

From a technical point of view the idea of a P2P storage system is that if you upload a piece of content on this cloud, you'd expect it to be there all the time. That's the whole point of a cloud; you upload it, and can download it from anywhere in the world at any time. I'm not sure that P2P is a good solution to this issue. A client-server model, from an entity that you trust and pay directly which has reputation (say Dropbox), is probably a better mechanism of doing this.

In a P2P system, all the nodes that were holding your data could simply go offline for no particular reason and your data would be unreachable. Furthermore, even if the nodes were incentivized to keep sharing your data (perhaps being compensated through some form of cryptocurrency), there's still no way to figure out how the incentive would work exactly. For example, how would you stop yourself from serving your own data using another computer, and therefore getting all the crypto yourself?

It's a very interesting problem and I think we're slowly getting there, but we really need to get the incentives right, and it's a really hard problem in a P2P system. But hey, there's hope, just look at Bitcoin!


According to the website:

  The machine will be smash and grab resistant. It is not meant for
  unattended or outdoor use, but it will have thick metal mounting
  plates, a dual locking system and an internal strong box for the cash.

According to this site:

  The outer casing is a custom steel case made in Portugal. There’s a
  Protec cylinder lock holding it closed. Inside, there’s yet another
  steel case and another Protec lock. The tablet that runs the software
  has no open ports, and all outgoing connections are via https.


How to accept USDT payments the right way?

fill addresses with dust, like 300 sats, receive OMNI/USDT on those. as soon you received, send them to your hotwallet. it's a regular BTC transaction, so you need to have some balance to pay the fee.

or, just do it on the etherchain as regular ERC20 token


I wonder if this is due to the fact that prices can change very rapidly if many orders are executed in a short period of time.

In my tests both prices are the same, and none seem to lag after the other.


Please try to open copay on another mobile phone and see if it gonna work,
some countries may block access to bitpay servers which are few, to avoid country citizens using bitcoin.

if so, try to install some VPN software and try again. if still doesn't work, you have to open an issue here https://github.com/bitpay/copay/issues with more details about your mobile phone.

if you don't want to do so, you can install copay on your laptop or any other device and import your mnemonic phrase there.


Does the 1 MB block size limit include the header?

CSizeComputer is a serialization stream that discards all data written, and just counts how many bytes were produced. It is inlined, and the compiler in most cases actually avoids computing the bytes.

So, GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS) just computes how many bytes would be produced when serializing a block for the network ignoring witnesses.

As blocks on the network indeed are prefixed by their header (and transaction count), those do contribute towards the maximum block size.


How to push through transaction that has been pending for 2 weeks using Blockchain.info?

Normally, I would refer you to:
Q: Why is my transaction not getting confirmed and what can I do about it?

But I'm going to make it simple for you.

You basically got two options:

1. Wait it out.
Easiest solution. Wait until the transaction gets picked up or dropped.

2. Ask miners for help
Some mining pools and miners offer services to allow you to prioritize your transaction in their mempool so that it is chosen sooner for inclusion in a block. One such service is https://pool.viabtc.com/tools/txaccelerator/. Also you can find others here.

Some members on Bitcointalk.org offer free transaction accelerator services, some of them have access to several pools. If urgent, you may consider the paid services(Beware of the scammy ones though).

3. Rebroadcast
You can try to manually broadcast the transaction, but this probably won't help you at all because your fee is low.

4. Replace by Fee (RBF)
Won't work with blockchain.info.

5. Child Pays for Parent (CPFP)
Won't work with Binance.


6 x GPU mining rig only installs drivers for 5

(since I can't comment) I had this problem too about a month ago. Try using AMD Catalyst to install the drivers.


creating address in wallet and sending how it works

Address are similar in a way to your bank account number, it just says where your wallet is. It differs in the way that a bitcoin wallet can have more than 1 address. Personally, I am receiving bitcoin on 4 to 5 different addresses.

But I don't actually understand what you mean by creating new addresses to send bitcoin from, you only create a new address (or use an old one) when receiving bitcoin not sending one.


Why is syncing the last 5000 blocks so much more CPU-intensive?

Up until the last checkpoint, your client knows that all transactions are properly signed. After the last checkpoint, your client has to validate each input to each transaction by matching it against the corresponding output and executing the script, typically involving an ECDSA verify.