Just realized right now how an ICO scam can be run... without transparency■■ Been doing some research on ICO (initial coin offerings) coins, assets, and companies. And I just realized right now there is nothing stopping the initial stake holders from putting in their own money or Bitcoins into the ICO and then paying themselves back with either a high salary or some other means that look legitimate.

In effect, it would make the ICO look as if it was well funded fooling everyone else into funding the project.

The only way to defeat this type of shenanigans is by having transparency and seeing where all the money came from. If one can track down where most funds are coming from we can avoid these shenanigans.

I'm sure down the line regulation will encapsulate this funding technique eventually and bust everyone that has done this. So its best to stay anonymous if anyone is doing this type of marketing tactic.

Technique seems to be:

Show a very promising technology thats on the way.
Code up something that seems like it works.
Ask for funding and give investors a higher % of return.
Show that you raised  millions of dollars to prove large stakeholders are onboard.
Pay investors back a large % of their money.
Pay yourself and your friends a large salary to get your initial funds back.
Profit.

Not a scam necessarily, but one can see it as a very smart marketing tactic. But end result is the uninformed public is left with the bag.

I wonder if all the ICO related companies or devs did this. It's very tempting i'd imagine.

The basic idea is the same as running a crowdfunding campaign where you ask for $1000, but you were only able to raise $700 and its your last day before the campaign ends. What do you do!?!? Put in your own $300 of course just to get the $700 from everyone else. Which is fine for small potatoes like that, but what if it involved millions of dollars? Is it still fair anymore? Or was the public fooled?

Now the question is which ICO's could have executed such a marketing technique to a large extent? Not naming names, its just something i recently realized of how profitable an ICO can be if executed properly.

What you're describing is something I understand to be a well established practice in the land of ICOs and premined altcoins. I've seen it called "salting the tip jar".  It doesn't take much effort to go find high profile "cryptocurrencies" that premined and presold 72 million tokens than as soon as their presale ended their "CEO" paid himself out a million dollars to repay "loans" and exited stage left...

I have no idea if this kind of conduct is generally unlawful, but it doesn't matter because the people creating premined alts and ICOs don't care and don't seem to suffer any negative consequences for their unethical behavior.

I think its yet another reason why people should stay far far clear of any ICO or anything like an ICO.


How do Schnorr signatures impact coin selection and the utxo growth? Will Schnorr signature incentivise different practices in coin selection? How do they impact the utxo set in the long run?

Yes, Schnorr signatures are generally slightly smaller than ECDSA signatures. This is due to their more efficient encoding that takes only 64 bytes instead of 72 bytes.
A comprehensive Coin Selection algorithm should therefore e.g. prefer an input with a Schnorr signature at high feerates and should prioritize using up non-Schnorr inputs at lower feerates to minimize costs.
In combination with the signature aggregation, we may generally see more consolidation and batching transactions, and may additionally see a market for creating multiparty transactions as combining multiple transactions will lowers overall cost.
I would expect the UTXO set to shift from old style UTXO to newer, more efficient formats over time, but whether the growth of the UTXO set would be impacted and how, is difficult to predict.


BitCoin Core Error Message: "Assertion failed!" I am experiencing a recurring problem with my BitCoin Core wallet. The main issue here is that I get an error message every so often as the program is updating the transaction blocks.

Please see the jpeg in the link above, this is the exact error message I get when the client is updating.

Details:

I am using BitCoin Core V 12.0
I have tried reindexing using : c:\Program Files\Bitcoin\bitcoin-qt.exe -reindex
I have tried to reinstall the client, then restart my computer, then open and let it update.
I haven't yet tried a RAM test to see if my RAM could be the source of corrupted data
I'm running Windows 7 OS 64-bit, 8Gb DDR3 RAM

I feel its something that can be fixed with a patch, but I could be wrong. If anyone has a solution that I can try myself, that would be most welcome.

It is possible that you are running out of RAM or HDD space.  Check this github report from a user with a similar issue.  If this is not the case then I would run a memtest and see if you don't have an issue with your RAM.


blockchain checksig fail i'm attempting to verify a checksig from a transaction in the live blockchain. it is failing on my debian jessie pc with openssl 1.0.1k, failing on my ubuntu 12.04 virtual machine with openssl 1.0.1 and validating correctly on my debian wheezy pc with openssl 1.0.1e. both are using the same code. the transaction is the first instance of a SIGHASH_NONE in the live blockchain. i calculate the "message" (tx) hash as:

hex: 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a
same thing in base58: 3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB

the signature is:

hex: 30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2
same thing in base58: 381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd
note that this signature does not have the 02 hashcode appended to it

and the pubkey is:

hex: 04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6
same thing in base58: SJa4B8CrqDs6St5KaXMm4KCCksaT7RDcCaRDyKSD6Mbu1WzSwokEq3JwGtfZRz7by6jYD5QmuVhgqsPYc6wTijQq
converts to bitcoin address: 145YPBBWRj4aquewvx59SAWNrSZFT5rvxr

could someone tell me if these parameters pass the ecdsa verification or not? also if anyone knows of an online validator that would be helpful.

i'm trying to verify this with the jsonrpc client but it doesn't work on any machine i have:

#!/usr/bin/env python2.7

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
rpcuser = 1
rpcpassword = 1
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332" % (rpcuser, rpcpassword))
message = "3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB"
sig = "381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd"
addr = "145YPBBWRj4aquewvx59SAWNrSZFT5rvxr"
res = rpc_connection.verifymessage(addr, sig, message)
print res

output:

False

maybe i'm encoding the message or signature wrong for the rpc client? i tried passing binary encoded data to it, but it didn't like that:

File "/usr/local/lib/python2.7/dist-packages/bitcoinrpc/authproxy.py", line 125, in __call__
    json.dumps(args, default=EncodeDecimal)))
  File "/usr/lib/python2.7/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/lib/python2.7/json/encoder.py", line 200, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python2.7/json/encoder.py", line 263, in iterencode
    return _iterencode(o, 0)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xcd in position 2: invalid continuation byte

verifying with pybitcointools works on all machines:

from bitcoin import *
import binascii

msg = "2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
# make sure to include the 02 hashcode on the end of the signature here!!
sig = "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a202"
pub = "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6"
msg = binascii.unhexlify(msg)
print ecdsa_raw_verify(msg, der_decode_sig(sig), pub)

output:

True

Yes, you calculated digest 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a correctly.

Here is my piece of dirty code:

static void xxtest ( )
{
  const QByteArray t ( MyByteArray ( )
      .putInt32 ( TX_VERSION ) // 01000000
      .putInt8 ( 1 )           // 01 : one input
      .putArray ( QByteArray::fromHex ( "5f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e" ) )
      .putInt32 ( 1 )          // 01000000 : index
      .putPrefixed ( MyByteArray ( )
         .putInt8 ( OP_DUP )
         .putInt8 ( OP_HASH160 )
         .putPrefixed ( QByteArray::fromHex ( "21c43ce400901312a603e4207aadfd742be8e7da" ) )
         .putInt8 ( OP_EQUALVERIFY )
         .putInt8 ( OP_CHECKSIG ) )
       .putInt32 ( TX_SEQUENCE )
       .putInt8 ( 0 )          // no outputs
       .putInt32 ( TX_LOCK )
       .putInt32 ( SIGHASH_NONE ) );
  _trace ( QString ( t.toHex ( ).constData ( ) ) );
  const MyKey32 digest ( t.constData ( ), t.size ( ) );
  _trace ( QString ( "digest = %1" ).arg ( digest.toStringRev ( ) ) );
  const QByteArray pubkey ( QByteArray::fromHex ( "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6" ) );
  const QByteArray signature ( QByteArray::fromHex ( "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2" ) );
  _trace ( QString ( "verify=%1 (expected value=1)" ).arg ( digest.verify ( pubkey, signature ) ) );
  // now test the same with wrong digest
  const MyKey32 temp ( "temp", 4 );
  _trace ( QString ( "verify=%1 (expected value=0)" ).arg ( temp.verify ( pubkey, signature ) ) );
}
//--------------------------------------------------------------
bool MyKey32::verify ( const QByteArray& pub, const QByteArray& sig ) const
{
  return 0 < ECDSA_verify ( 0, constPtr ( ), 32, (const quint8*)sig.constData ( ), sig.size ( ), EC_KEY_pub_key ( pub ) );
}

the output is:

"01000000015f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e010000001976a91421c43ce400901312a603e4207aadfd742be8e7da88acffffffff000000000002000000"
"digest = 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
"verify=1 (expected value=1)"
"verify=0 (expected value=0)"

Update:
Here is small program for checking signatures with dependency only for OpenSSL lib:

#include <QByteArray>
#include <QDebug>

#include <openssl/ec.h>
#include <openssl/evp.h>
#include <openssl/ecdsa.h>
#include <openssl/sha.h>

static EC_KEY* EC_KEY_pub_key ( const QByteArray& pub )
{
  static EC_KEY* eckey = EC_KEY_new_by_curve_name ( NID_secp256k1 );
  const quint8* ppub = (const quint8*)pub.constData ( );
  o2i_ECPublicKey ( &eckey, &ppub, pub.size ( ) );
  return eckey;
}
//--------------------------------------------------------------
int main(int argc, char *argv[])
{
  const QByteArray data ( QByteArray::fromHex ( argv [1] ) );
  const QByteArray sign ( QByteArray::fromHex ( argv [2] ) );
  const QByteArray pubk ( QByteArray::fromHex ( argv [3] ) );

  quint8 tmp [32];
  ::SHA256 ( (const quint8*)data.constData ( ), data.size ( ), tmp );
  quint8 digest [32];
  ::SHA256 ( tmp, 32, digest );
  qDebug ( ) << "data=" << QString ( data.toHex ( ) );
  qDebug ( ) << "sign=" << QString ( sign.toHex ( ) );
  qDebug ( ) << "pubk=" << QString ( pubk.toHex ( ) );

  qDebug ( ) << "digest=" << QString ( QByteArray ( (const char*)digest, 32 ).toHex ( ) );

  const bool v ( ::ECDSA_verify ( 0, digest, 32, (const quint8*)sign.constData ( ), sign.size ( ), EC_KEY_pub_key ( pubk ) ) );
  qDebug ( ) << "result=" << v;

  return 0;
}


Anyone know of an API I can get historical price time series for multiple coins I'd like to build some historical price charts, to use in my cryptocoin portfolio tracking app, using time series data (with HighCharts js).

Anyone know of an API that provides this price data, preferably for multiple coins (btc, ltc, eth, etc)?

I am developing the ccxt cryptocurrency trading library, check it out on GitHub:

https://github.com/kroitor/ccxt

It is a library for cryptocurrency trading and e-commerce with support for many bitcoin/ether/altcoin exchange markets and merchant APIs.

With it you can access market data and trade bitcoin, ether and altcoins with more than 70 (!!!) cryptocurrency exchanges. It is used to connect and trade with crypto markets and payment processing services worldwide. It provides quick access to market data for storage, analysis, visualization, indicator development, trading strategy backtesting, bot programming, building trading algorithms on top of it, webshop integration and related software engineering.

The codebase is in JavaScript / Python (2 and 3) / PHP. You can deploy it from PyPI, with npm (for Node.js) or by cloning the GitHub repository.

The ccxt library is under heavy development right now, but already offers a quick-start for trading and technical analysis with many crypto exchange markets out of the box. It is intended to be used by coders, developers and financial analysts to build algotrading strategies on top of it.


Electrum wallet address not showing I've just installed the electrum wallet accordingly said by every other website but wasn't able to find my wallet address under the receiving tab or anywhere as mentioned over the internet.

Also what are these multiple addresses stated under addresses tab; difference between receiving and change address? Why have so many receiving addresses, have to manage the private key for each.

click on request on the receive tab to get an address. optionally you can enter a description before clicking on request. the description will be saved in your wallet and will show up on the history tab when you receive money. this helps you keep track of what the money is for.


I forgot my bitcoin core passphrase. Is there anyway I can recover? I've tried brute forcing it. Doesn't work.

0.02 BTC in the wallet.

No.  The whole point of strong encryption is that it is impossible to recover the data without the passphrase.

You can:

Keep trying to brute force (maybe with faster computers, or a better initial guess at the passphrase)
See if you have a backup of the wallet.dat file that isn't encrypted
Try really hard to remember
Give up, and resolve to be more careful with strong encryption next time.


I've found two mined txs with no fee I was debugging my little project and I've found this pair of txs without fees (they caused an alarm):

[txId=e8f6f08430ab6b1f3e645f499cf90c69acf2eb8a8d9766abb9d76314f29209dd, fees=0, weight=879600], [txId=cf7ba67c57d72dc735c200f5bf81789f6464adf65816b7640562d38a8c706a05, fees=0, weight=16052]}

both in block 618858.

first one is very heavy (almost a quarter of a block).

just curiosity. Do I have to suppose that it's probably the miner the one who has auto-sent this tx?

A transaction having a fee is not a consensus rule. Although the vast majority of nodes refuse to relay a 0 fee transaction, it is valid.

Such transactions can be included in a block by directly passing them to a miner, and would tend to belong to the miner themselves, or someone they have some kind of relation with.


How does an encrypted wallet persist used keys from "getnewaddress" and the keypool after a restart? I'm reading this wiki on wallet encryption  and am confused on how I can call getnewaddress as described here and where that is being tracked after a restart of bitcoind.

  When a wallet is encrypted, the passphrase is required to top up the
  keypool, thus, if the passphrase is rarely entered, it is possible
  that keypool might run out. In this case, the default key will be used
  as the target for payouts for mining, and calls to getnewaddress and
  getaccount address will return an error. In order to prevent such
  cases, the keypool is automatically refilled when walletpassphrase is
  called with a correct passphrase and when topupkeypool is called
  (while the wallet is unlocked). Note that the keypool continues to be
  topped up on various occasions when a new key from pool is used and
  the wallet is unlocked (or unencrypted).

  When wallet passphrase
  enrcyption becomes enabled, any unused keys from the keypool are
  flushed (marked as used) and new keys protected with encyption are
  added. For this reason, make a new backup of your wallet so that you
  will be able to recover the keys from the new key pool should access
  to your backups be necessary.

You can't call it an infinite number of times. In fact, with default settings, the 101st call will fail.

While the private keys that control the bitcoins are encrypted, the addresses corresponding to those keys are not.


If the supply of Bitcoin is regulated, how could it be said to be decentralized? The minting of new bitcoins is deterministic, and there will eventually be a cap to the production of new bitcoins. Why do we say that bitcoins are a decentralized currency if they are created in such a "top down", regulatory way?

Bitcoin is decentralized because the authenticity of all transactions depends on the 'decentralized' network of miners who compute SHA-256 proof of works hashes. The Bitcoin cap is completely arbitrary and doesn't really matter since Bitcoins are divisible to multiple decimal places. Whether there will be 2,100 bitcoins or 21 trillion bitcoins, the cap doesn't really matter. Its all relative. I feel as though the 21 million number was picked with consideration to the number of potential users in correspondence to the size of ints, floats, etc.

Many people debate as to how 'decentralized' bitcoin really is. It seems as though those who create or own ASIC miners are the ones who really have the edge on the market. Some say that certain altcoins that cannot be mined with ASICs may be more decentralized, since CPUs and GPUs are more widespread.


Why are some public keys prefixed with 0x00? ECDSA public keys seem to always start with 0x02/0x03/0x04/0x05 1, followed by either 32 bytes of 64 bytes.

However, I encounter some public keys prefixed with 0x00.

For example, the source output of transaction
5c7c65bb950d3605cc67bd02c29e84cc14dfaa80626ef6a575132c7ce7979d2f contains two public keys:

037953dbf08030f67352134992643d033417eaa6fcfb770c038f364ff40d761588

0014fa6851313844da08b6a539aff5e74e705b7465fad0fc5ceeccae707995b846

When fed into EC_KEY_oct2key function from OpenSSL 1.1.1, the second public key directly fails.

Another example is transaction f0020466ca75caa648cdc8364f297bda7bb06329bec5305ffb59ea2ea348ac39, which uses an output that lists a public key like this:

0029a38fa2eaf8e67481c47eeeaeb625e6d426eb78f3b9e0728a4679370ce5ac96

These 0x00 public keys seem to always come with OP_CHECKMULTISIG and never block validation because some other public key would be valid.

What are these keys and what should a client do with them?

These are not keys, they are arbitrary data.

Until Bitcoin 0.16, an invalid public key was allowed in the bare multisig, as long as it's the right size. With the upcoming 0.17, this is no longer possible, and transactions like the ones you linked to will be considered non-standard (note that this does not prevent their inclusion in a block, and they are still valid if included).

People have often used such tricks to embed data in the blockchain. For instance, providing 1 valid and 1 invalid key in a 1 of 2 multisig allows someone to embed 33 bytes of data, without sacrificing the BTC locked up in the wallet.

A more extreme example of this is in tx fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016, which contains "keys" like 100000000000000000000000000000000000000000000000000000000000000000.

(example tx from this issue)


How can I measure the "health" of Bitcoin? What are the metrics that matter when evaluating the overall "health" of Bitcoin?

What are the thresholds?

Specifically

Economic (e.g. velocity, days destroyed, market volume & beta)
Technical (e.g. rate of difficulty change, block size, tx fees, size of the chain)
Diversity of stakeholders (who are the market movers, large investors, what are their intents: profit vs stability)
etc.

Specifically, I'm trying to get an understanding of financial health of a system that proclaims to be superior to the one it's trying to replace (or compliment).

This strongly depends on what you think makes a financial system healthy.

As long as there is no challenge to the core of Bitcoin, distributed no third party controlled transactions, there is no need to worry about any of the technical aspects. Stakeholders are the major problem here, the hashrate distribution being the clearest example. Stakeholder power must be distributed to preserve the nature of Bitcoin. Hashrate has a hard limit at 50%, but even close will cause less reliability. Other stakeholder measurements have no clear/hard limits.

The health measure then comes purely from the hashrate (indicating security and current interest in the minable Bitcoin) and the amount of users connected to the network. Sadly the users connected cannot be measured correctly due to Bitcoin wallet services.

Any other metrics can show you what happens to Bitcoins, but not everywhere else. Some indications can be given about how Bitcoin are used, but not about their actual "health". At least not in any measure of health I can currently see to be valuable. I'd consider transaction origin and destination diversity to give some indication of user diversity, which would indicate how much Bitcoin is used, which would indicate robustness through diversity.

FYI: Many interesting graphs are here. They say something, but do not clearly indicate health. I do think most of them have "better" or "worse" directions, but they are fairly easily manipulated, especially in unhealthy circumstances.


Bitcoins didn't arrive to new wallet I use Bitcoin-Qt. Decided to make another wallet and transfer some bitcoins there. Wanted to give that wallet to my friend as a gift. What I did was:

renamed wallet.dat file to 1_wallet.dat
started Bitcoin-Qt it created new wallet.dat file
copied address of new wallet
renamed wallet.dat to 2_wallet.dat and 1_wallet.dat back to wallet.dat
transferred some bitcoins to new wallet address

finally after transaction was confirmed I still didn't see bitcoins in a new wallet. What I did wrong? Is it possible to get back these bitcoins?

Removing all block chain and retrieving it again solved this problem. I guess -rescan should help too.


How do non-standard transactions get created, broadcast and mined? Can someone explain how this transaction was validated, broadcasted and mined?

When i looked at the scriptsig it only had the hex value for OP_True.

https://blockchain.info/tx/91c8b08f305d895d6bc8f43bbdd36dcbc7f1d998e3df5e8f13dd9cdeebf15cb5?show_adv=true
Also how can i create a transaction like this and have it broadcasted and mined?

Normally, non standard transactions would be rejected by P2P nodes (but would still be mineable by miners directly since this is just a policy rule).

P2SH addresses do not disclose the script they hash until they are first spent from. So you can send BTC to any script (valid or not) using P2SH addresses. Standardness rules are not imposed on P2SH input scripts, they just have to respect the protocol rules (size, use enabled opcodes, etc...).

To create your own scripts, you can use this question as a starting point.


Which payment processors do not allow for chargeback? I would like to receive a payment for selling my bitcoins. I don't trust the person much, so I will ask for money in advance. However, I'm not sure which payment processors could I use for such a transactions that are chargeback-resistant. I know PayPal is bad for this, but what are my other options?

Which payment processors do not allow for chargeback?

It's a short list.

Cash
Liberty Reserve (though they did freeze some customer funds recently until they became verified)
Bank Wire (though see comment below)
Webmoney (supposedly)

Here's the payment methods hardness list:

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


How to detect a rejected transaction? If the nodes I connect to don't support the BIP 61 reject message, how do I know that my transaction was eventually rejected by the network (e.g. due to my bugs)? Is there any timeout or whatever after which it's reasonable to assume that my peers will never relay the transaction?

There are no timeouts, and a valid transaction can be mined at any time.

The only thing that can ensure a particular transaction won't get mined in the current block chain is to make it invalid.  The only practical way to do that is to create a confirmed double spend---another transaction that spends one of the same inputs as the transaction you don't want mined.  Once that double spend is confirmed, your original transaction can't be added to a block in the same block chain as the confirmed double spend.


How are bip44 coin identifiers assigned? There is a list of bip44 identifiers for altcoins here.

It uses the term registered coin types.  My question is, is there anything in code for each coin that the bip44 number is derived from, or this is purely an arbitrary assignment from a 3rd party?

From reviewing code, bip44, and slip44, my conclusion is the latter: namely that one "registers" simply by sending an email to the author(s) of slip44, and they hopefully assign a number.

If I am incorrect and there is code in bitcoin-core or an altcoin derived from it that defines or uses the bip44 id, please point me towards that code.

thanks!

BIP44 is more like a standard which you are supposed to follow. The coin id's assigned are way to standardise the approach in case you are making a wallet and want better segregation of your coins.

For example, with the same seed, you can derive keys for different cryptocurrencies, just by changing the coin  id. Do note all those ids can be used to generate addresses for only one crypto as well.

Basically it is trying to maintain some nomenclature in this open source community. There is no code in the source code specifying this.
As a matter of fact , the address and private keys generated are backwards compatible to a node version not having the HD wallet implementation.

Address generation is something which the bitcoin core software provides, however anyone can write their own code for address generation as long as it follows the guidelines for address generation.


How to move sync's data to another partition after run Bitcoind for a while? I have download a new bitcoin package from official site. And then I ran it with daemon mode also with default configuration (Default means not bitcoin.conf file was created in ~/.bitcoin/.bitcoin.conf). After ran 2 hours. I got stuck, and the process exit. When I checked my disk with:

df -lh

And then, I got those:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        20G   20G  118M 100% /
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G  233M  3.6G   6% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vdb        800G  7.7G  792G   1% /data
tmpfs           783M     0  783M   0% /run/user/1000
tmpfs           783M     0  783M   0% /run/user/1001

And I googled for a while, but could't find a good way to move all sync's data to the /dev/vdb. I understand what my mistake came from, but I just fixed it by move data and then put a new configuration with --data-dir=/dev/vdb. and then keep sync it.

So, How do I reach that?

I have try to ran the bitcoind -data-dir=/data/db -daemon , but it's not write the data to the path where I specify. Actually, The right way to do that with :

bitcoind -datadir=/data/db -daemon

Attention

   -data-dir --> -datadir


rpc json outside localhost I tried to to host bitcoin core json-rpc to listen other than localhost but it would not work even i set it to listen to ip 0.0.0.0

My config (for bitcoin.conf)

testnet=1
server=1
daemon=1
listen=1
rpcuser=something
rpcpassword=secret
rpcport=8332
rpcconnect=0.0.0.0

So how do i make it so that it will listen to ip other than localhost or 127.0.0.1?

VPS informations:

Ubuntu 16.04

Latest Core (just installed it today)

client is remote

The listen option is for the P2P network connection, not the RPC service.

The option you want is rpcallowip=<ip>. To allow all IP addresses to connect to your node's RPC port, you can use rpcallowip=0.0.0.0. Note that doing so is not recommended as it is insecure.

Don't set rpcconnect as that will make it impossible for bitcoin-cli to interact with Bitcoin Core.


Quantifying the long term costs associated with self hosting the Bitcoin node? In this question I discussed the option of self hosting the Bitcoin node vs. using 3rd party services with API access. I quoted a colleague who said that "for every coin we wish to support, we will be required to hire a dedicated expert developer to maintain each node at a cost of $40,000 per year per node".
Although this was not the main point of my other question, I received a polarizing response to this quote.
For example, the user @Anonymous commented:

Where could they have possibly got the idea that maintaining a bitcoin
node costs $40,000 a year?

In response, the user @chytrik wrote:

Perhaps not for bitcoin, but for some poorly developed altcoins that
number is maybe too low – chytrik

A similar sentiment to @chytrik has been echoed by @Murch♦:

I agree, developers with a cryptocurrency background is not neither
cheap nor abundant. Obviously, it depends on your location, but I
suspect that you may find that $40,000 p.a. to be actually highly
optimistic. In the US, you'd probably be looking at $150k+ per
position (salary+rest).

Since this site is for Bitcoin, the focus of my question will be exclusively on Bitcoin.
Is there a practical way of quantifying the cost associated with self hosting the Bitcoin node? This includes the cost of hosting, scaling and hiring a competent developer to setup and debug the node. Obviously, a big part of the evaluation is likely to depend on the number of expected transaction so let's assume for this example we are dealing with an app that will scale from 5,000 to 500,000 customers at some point or from 500 to 50,000 requests per day.
What is a practical way of quantifying the long term costs involved and what type of maintenance/upgrades would a developer be required to do in the long term?

Is there a practical way of quantifying the cost associated with self hosting the Bitcoin node? This includes the cost of hosting, scaling and hiring a competent developer to setup and debug the node.

Depends on the business. If it's a startup you can always hire a developer for initial setup. If you experience any issues in future, pay another developer per hour for a specific work.

What is a practical way of quantifying the long term costs involved and what type of maintenance/upgrades would a developer be required to do in the long term?

Type of upgrades/maintenance can involve anything mentioned on https://bitcoin.stackexchange.com or https://github.com/bitcoin/bitcoin/issues


Can unrelated people know the private key of a multisig address? After a multisig address is created, can one of the private keys of that address be known by an unrelated person and the security of that address still remain uncompromised?

My understanding being that nobody would be able to spend from that address without the other signatures

I think your question may stem from a misconception.

An ordinary Bitcoin address is the hash of a public key (plus a few extra bytes), which in turn is associated to a private key.  So in that sense an ordinary address has a private key.

Multisig addresses do not work like that.  The address is not the hash of a public key, and so there is no private key directly associated to the address.  Rather, a multisig address is the hash of a script.  The script in turn lists the public keys whose signatures will be needed to redeem the transaction.  I think it is these keys that you are referring to as "existing addresses" in your comment.

So spending the transactions requires you to know the private keys of the intended recipients.  There is no other private key involved.

Also, there is no real problem if other people know the script whose hash is the multisig address.  The only extra information it contains is the public keys of the recipients.  This might help someone identify who those recipients are (though the script has to be revealed in order to spend the transaction, so this information will eventually be public anyway), but it doesn't help them spend it.

For more information, see these answers:

How will multisig addresses work?

What is "Script Hash" address exactly and how does it work?


Instawire fees over Bitcoin Central fees and their respective KYC policies? Instawire, Bitcoin-Central, Instawallet, Paytunia and Paymium are seem to be closely related, they cross reference each other on their sites, though their respective guarantees for their services are quite different (that was two links in two words just it's difficult to see it on your platform, perhaps you can fix that) which is interesting.

The question is why Instawire charges much more than the prices you can get on Bitcoin-Central? Maybe because the first one is a service and the latter one is an exchange. But perhaps do they have different KYC policies? Though I'm not sure about Instawire' KYC (Know oyur customer) policies they state on their site that you can send up to 100 euros, though, for a high fee. Maybe you pay for your privacy with this service? On the other hand, Bitcoin-Central requires your personal documents for even the smallest transactions, right? Though I'm not sure, didn't find these data explicitly on their sites.

You got the answer in the question : the fees are higher on Instawire because it is a service, not an exchange.

The fact is also that (until Bitcoin is legally considered a currency) sales of Bitcoins are subjected to European VAT which instantly adds 19.6% to the price. (If Paymium buys a Bitcoin at 10 EUR, it must sell it at 11.96 EUR to start breaking even).

There is no legal requirement to do KYC on Instawire as no funds are held on behalf of users, sometimes documents might be requested, but when they are it is for fraud-prevention purposes, not KYC. The 100€ limit is also a fraud-prevention measure.


Setting up a basic test transaction for p2p donation web app - API recommendation My question relates to the use case of trying to build a simple payment flow where one user (a donor) can donate directly to another user (a recipient) with Bitcoin.
To begin with, I would like to manually load up and input 2 addresses that respond to a Donate button and ideally get processed from test accounts on the Testnet blockchain.

I am new to bitcoin development and want to understand the underlying mechanics rather than immediately implementing a more sophisticated and abstracted plugin (e.g. Stripe).
Additionally, my preferred language is Ruby so I have been favouring APIs with Ruby SDKs.

So far I have a shortlist of the following APIs:

Chain.com (https://chain.com/docs/ruby#bitcoin-transaction-overview)
Blockcypher (http://dev.blockcypher.com/#payments) >> provide direct access to Testnet, not clear how would implement with others
Blockchain.info (can't link with current rep points) >> may force you to use their wallets

Has anyone worked with these and can provide guidance on which is best to implement the above use case? Other suggestions welcome. Appreciate this could be interpreted fairly broadly but I can try and specify further if you have questions.

In case anyone else faces this decision I decided to go with the Blockchain.info API (https://blockchain.info/).

Primary factors:

Easy to use ruby gem and interface - I was able to create wallets and transactions through invoking a few simple methods within my Sinatra app
Blockchain.info provide and utilise a stable wallet, recipient address which is easier and more intuitive to work with when starting out (e.g. easy to track senders and recipients against IDs)

Drawbacks:

I couldn't find a way to link in the Testnet blockchain so had to experiment with real Bitcoins
I was totally reliant on the Blockchain.info wallet and transaction structure. This was fine for a prototype/ experiment but for an actual MVP you would want to be able to integrate a wide range of wallet providers.


On my first shopping via bitcoin I get "The fee for this transaction seems unusually high. (20%)" What to do about it? I have some bitcoins in a local Electrum wallet and wanted to do my first shopping with bitcoin from a shop offering payment via bitpay for an item costing (in USD) 20 dollar.
So I went through the payment process with bitpay (Bitcoin amount is around 1.8 mBTC), disabled in Electrum as they had suggested Replace-By=Fee and then pasted bitpay's payment url (bitcoin:?r=https://bitpay.com/i/....) into Electrum.
I got to the send screen. But here I received the following warning: "The fee for this transaction seems unusually high. (20%)" as shown in this screenshot:

Why is the fee so high and how can I reduce it to an "normal level" like with credit cards (say 0.5-5%)?

This is expected, given the current mempool situation.
There are over 100k transactions pending as of this answer's writing. This has resulted in the fees rising significantly, up to 10x of what you might pay normally.
As your overall transaction value is small, this results in the warning showing up. The warning itself was added to prevent people from paying absurdly large fees. In your case, as the amount is small, the fee is proportionally considered large.


How can Blockchain.info query information from the blockchain faster than I from my own node? I've just run a Bitcoin node but I don't understand how blockchain.info or any other blockchain explorer works. I mean, sometimes I have problems like "socket.timeout". Shouldn't it be faster to query info from my own node than from a blockexplorer?

API providers, such as Blockchain.com, are not querying a node to answer your queries to them usually. For the handful of providers that actually do offer a proxy service to a bitcoin node, they usually run several of them and spread out incoming queries so that no single node is answering a huge number.

They extract the information they need and store it in a separate database, which is optimized for quickly serving the information for all transactions and addresses.

bitcoind is optimized for running the Bitcoin Protocol, which is largely just communicating with other nodes, maintaining the utxo set, and validating blocks. While it does let you retrieve historical transaction information, it is not the primary goal. It also does not offer universal address indexing, and only indexes transactions for the known wallet addresses.

It may be worthwhile for your usecase to extract historical information from bitcoind once and use that as a source for your future queries.


Under what conditions could a change address immediately send the entire balance to a third-party address? I have a situation where I sent 1 coin to and address I own and my wallet sent the unspent output to a change address but due to a glitch in the wallet software, that change address doesn't show up in my wallet. I did see that change address in my wallet at some point in the past but when I upgraded the wallet, the address was gone. When I look at the unspent transaction, I see that it immediately flushed the entire address to another address that I think I do not own. I do not have my private key and cannot seem to reproduce it from my 24 word BIP32 mnemonic.

Questions:

If I own the private key to the change address, then how could the change address spend my coin without my private key?
If the wallet doesn't identify the change address as being owned by me, does the miner take the balance?

I'm stumped by how and why this happened.

Thanks

Generally, this should not happen. The situations this can happen should be limited to:

bugs in the software
malicious acts by the software

to resolve this you will need to look up the transaction on a block explorer and document all relevant information, including the block height, transaction id, inputs spent, target address, change address and possibly the miner that relayed the block.

armed with this information you then reconfirm in you wallet and doublecheck for deviations, and if necessary contact the developers of the wallet.

if they cannot help, you should at least be able to ask new and more precise questions here afterwards.


Bitcoin testnet3: unable to push/publish raw transaction: how to verify validity of transaction? I have created a raw transaction and am now trying to push the hex format into testnet3. I have used following two ways and both are giving me two different errors, first one:

curl -d '{"hex":"TX_HASH"}' http://tbtc.blockr.io/api/v1/tx/push

I get this error:

{"status":"fail","data":"Could not push your transaction!","code":500,"message":"Did you sign your transaction?"}

and second one using this link:

https://test.webbtc.com/relay_tx

gives me this error:

Testnet3 - Error - Request took too long.

Not sure if signature is really the problem here. I used decode api from blockr.io to check my message - it seems well formed and is 226 bytes in length. I played around with fee wondering if that was an issue, but I think i have ruled that out as well.

I have also checked the validity of signature in the code (inspired by David De Rosa's guide).
Any tips on how can I verify the validity of my transaction?

Thanks.

Edit: Now I am getting this very descriptive error message from blockr:

{"status":"error","data":"NULL","message":"It's looking like you may have taken a wrong turn. Don't worry... it happens to the best of us.","code":404}

Wish these guys didn't employ their sense of humour in error messages :(

used blockcypher api to push the raw transaction. This is the error message I get:

Error sending transaction: Error running script for input 0 referencing 87ce205d61e4bf63c0bcc42db1a58c36a2cac0048df32e470f3dc1bd39741367 at 0: Script was NOT verified successfully..

After signing the transaction, I checked for signature verification using ECDSA_verify(0,digest, sizeof(digest), sig, sig_len, key) and this function call returns 1 - So I assumed my signature is correct. Am I wrong in assuming this? Am I missing something big here?

Found the error!

I am using OpenSSL library and was signing using the function: ECDSA_Sign

The parameter unsigned int *siglen passed to this function is supposed to be filled with signature length. I was using the signature(parameter sig) and the length from parameter siglen to serialize the data. Turns out, although the signature being generated was always 72 bytes, the siglen parameter was filled seemingly randomly with 70, 71 or 72. And hence the number of bytes of signature that was being copied into my txn was not correct. Interestingly, if I call ECDSA_size(key) after making call to ECDSA_Sign(), i would get correct 72 value back.

AAAAh! Has anyone experienced this issue before with ECDSA_Sign? I haven't found anything on google yet.

But successfully posted the raw signed transaction using blockcypher's web tool/api.


Doest 'coinbasevalue' in GBT call include fees, or just the total block value? BIP 22 doesn't seem to specify... Pretty important if you're building a coinbase by hand.

Judging from the output of a GBT call to bitcoind  (2505616072), it must include fees.


When will the official client support partial blockchain downloads? Are there concrete plans for the official client to be able to download just a portion of the blockchain?

By concrete I mean what's the issue tracking this on github, is there a planned version for it?

Gavin has stated that he wishes to pull features in the version .5 release candidate this weeks.  He further states maybe the version .6 release will have it as a killer feature.

  Maybe the big feature for version 0.6 can be fast initial download (I'm thinking the best thing to do for brand-new, starting-with-an-empty-wallet installations is to download only block headers, function as a 'lightweight' client, and 'backfill' full blocks until you're caught up with the full chain-- then function as a 'full' client)

https://bitcointalk.org/index.php?topic=46493.msg553778#msg553778


what are private keys (essentially) how can i make them using any given data? private keys decode pub keys so how can they reveal other things?
can i reveal a web address from a private key?

I should be able to unpack anything from a private key seen as I can unpack something that can read/wrire decoide/encode

right?!

Bitcoin private keys (secp256k1) are just a random 256bits "number" (256 random zero and ones), or say 32byte random data. The only constraints are, that the random number must be between 0x1 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD.

You can calculate the public key from your private key but not vice versa (it's not practical possible).

With "revealing a webaddress" you probably mean encryption. You can use Bitcoin private keys with available schemes (Ex. diffie hellman) to derive a symmetric encryption key (ex. AES256) and encrypt data for a particular receiver.


Where can I find a graph of Bitcoin value vs USD for over 60 days? Bitcoin Charts seems to only offer graphs of up to 60 days.

Bitcoin Charts currently have charts of up to a year in length, as well as "all data" charts.

Example 360 days:

http://bitcoincharts.com/charts/mtgoxUSD#rg360zvztgSzm1g10zm2g25


What's the probability of vanity pools causing RIPEMD-160 (public key hash) collisions? As Bitcoin vanity pools become more popular, the possibility of using that power to derive another person's Base58 public key hash becomes slightly more likely.

I'd like to know if anyone has done the math calculating probability of guessing a public key hash vs keys generated per hour.

In particular this information would be useful to defenders (and attackers) of accounts with large balances... Namely it may make sense from a risk avoidance strategy to keep large balances spread among several accounts for this reason

So the question is, what is the horsepower required needed to crack someone else's key hash and what are the mitigating circumstances such as ASIC or FPGA availability?

If someone wants to take this a step further what is the maximum balance that should be held in an account based on those previous statistics

Bitcoin addresses are 160-bit numbers. Hence, randomly finding a private key corresponding to an address takes on average 2^160 attempts.

If 4 billion computers work on cracking a key doing 1 billion calculations per second for 15 billion years, they will find a total of 1.8*10^36 keys, so their chance to hit a right one is

(1.8*10^36)/(2^160) = 1.23 * 10^(-12)

which is one in a trillion. And this is only if they intentionally try to crack keys. If they just run normal vanity calculations, it doesn't matter how many keys they go over, as they'll eventually report just one key.

In the future (when the above figures may be slightly less ridicuolous), we might move on to longer key hashes.

So no, there's no risk.


What prevents a node from sending a different version of the blockchain? I understand that proof of work prevents a node from creating a new version of the blockchain unless they have >50% of the hash rate, but what if the attacker is also able to intercept the victim's internet traffic?

In that case, it would be able to mine a few blocks (or if that's too difficult, start a new blockchain from the genesis block) and then replace traffic to any node on the network with traffic to their fake node with a different version of the blockchain. The victim would then not know that a longer chain exists, so would believe the attacker.

What prevents someone from doing this?

In the scenario you describe, in which the only peers a bitcoin core node can connect to are owned by an attacker or colluding attackers, there is a minimum-chain-work-required for the block headers, so the client will not accept a chain which has a total amount of work less than the amount hardcoded into it here. There may be more forms of protection too, my knowledge is incomplete, but that at least provide a lot against such a situation. The node performs headers-first-sync which means it will know what the work of the chain is before it spends a lot more bandwidth and processing power validating the blocks themselves.


Bitcoin script execution unsuccessful I'm working my way through "Mastering Bitcoin".

The author made a transaction:

0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2

https://www.blockchain.com/btc/tx/0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2

I tried to execute the transaction script (with the Unlock script in vout) in a Bitcoin Script online simulator:
https://siminchen.github.io/bitcoinIDE/build/editor.html
putting the current ScriptSig:

ScriptSig: PUSHDATA(72)[3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301] PUSHDATA(65)[0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf]

with the output script:

DUP HASH160 PUSHDATA(20)[7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8] EQUALVERIFY CHECKSIG

according the blockchain explorer.

I got "execution unsuccessful" even though i didn't figure out what's the problem.
Apparently the op_EQUALVERIFY got failed.

The online script check program that you are using to evaluate the script has numerous issues. First, there is a known issue of the software calculating the OP_HASH160 incorrectly. For example, the HASH160 of the public key that you have entered (the one starting with 04...) is 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 while the program is calculating it as 6DF13DE1F1D824380834E0D42E49E5E451A647CF. This results in a failed validation when the OP_EQUALVERIFY opcode runs.

The error derives from mishandling the hashing strings as ASCII instead of binary. By this I mean that the program is hashing the public key as a string rather than treating the public key as a hexadecimal number and hashing the bytes. Below is a python code of how the hashing should actually be done.

import hashlib

def hash160(payload_in_hex):
    payload_in_bytes = bytes.fromhex(payload_in_hex) # note this step
    payload_sha256 = hashlib.sha256(payload_in_bytes).digest()
    payload_sha256_ripemd160 = hashlib.new('ripemd160', payload_sha256).hexdigest()
    return payload_sha256_ripemd160

pub_key = '0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf'
hash160(pub_key)
>>> '7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8'

Secondly, the signature verification against a public key without knowing what message was signed is simply incorrect. This is resulting in the program accepting any signature for any given public key. For example just try the below script and it will show you that execution was successful.

aecd 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf OP_CHECKSIG


How many coins been mined on the Testnet? How many coins been mined on the Testnet?
How can I check how many coins have been mined?

By visiting http://blockexplorer.com/testnet you can browse the testnet blockchain.

As of this writing, it shows that 128558 blocks have been mined on the current iteration of testnet (testnet3).  Since each block has a reward of 50 BTC (it has not decreased), that's a total of 6427900 BTC mined to date on testnet.


Bitcoin & Bitcoin-cash in Ubuntu same server : Use same Block Data for both Configured Bitcoin server/rpc working good in Digital Ocean Ubuntu VPS.
I also want to set Bitcoin-Cash server parallel in same server.

So do I require to download all blocks of bitcoin-cash node? because I already downloaded Bitcoin core blocks and BCC/BCC is forked from it. Your help could save my much BCC block sync time.

  I'm aware of setting BCC server independently. Just wan to know can we
  use same downloaded blocks for BCC JSON-RPC?

Followed this link how to install bitcoin legacy and bitcoin cash on the same ubuntu server?

So do I require to download all blocks of bitcoin-cash node?
Yes. Bitcoin and Bitcoin Cash share a history, but only up to the fork.
Possibly you might be able to make yourself a bootstrap.dat up to the fork for Bitcoin Cash to load, depending on exactly what software you are running for each. There are accurate and working instructions for creating bootstrap.dat linked in another recent question here.


How frequent are side-chain reorganizations of various lengths? I'm wondering if anyone has collected statistics on how often reorganizations of side-chains with length 1 happen in comparison with lengths of 2, 3, or more.

Related: What is the longest chain reorganization that has ever happened?

Random reorganizations of length more than 1 are rare. To get a fork of length 1, you need two miners find a winning nonce at nearly the same time. To get a fork of length 2, you need the same (1) happen right after a fork of length 1 and (2) have those miners mine on different sides of the fork.

However, such fork happen once in a while. See this answer for some statistics. And even longer forks happen due to bugs in Bitcoin code, like this one in March 2013.


Basic questions about lightning network HTLC I'm reading about lightning and I have a few questions:

The HTLC contract seems to be different at each new path payment channel is opened (due to a different Hash value that needs to be provided), but from my understatement, the channel opens in an independent and in advance to the payments in that channels, between two parties.
How is it possible? Does the HTLC is not written on the blockchain?
This part confuses me.
Are there are known ways to extend the time of a channel before the predefined period time is over? (without closing and opening a new channel)?

Thanks.

How is it possible? Does the HTLC is not written on the blockchain?

In the Lightning Network, HTLCs are part of the commitment transactions which are not broadcast to the network. This means that the HTLCs do not go onto the blockchain unless some fraud has occurred or someone is unresponsive.

None of the conditions of a commitment transaction (all of the punishment, timelock, HTLC, etc. stuff) ever go onto the blockchain unless fraud has occurred or one party is unresponsive. In a typical Lightning Channel, the only things that go onto the blockchain are the funding transaction which just pays a standard 2-of-2 multisig address, and the closing transaction, which just spends from a standard 2-of-2 multisig.

  Are there are known ways to extend the time of a channel before the predefined period time is over?

Channels do not have a predefined period of time.

Only HTLCs have a predefined timeout time and this cannot be changed without revoking the HTLC and creating a new one.


Is it possible to send a message to a bitcoin address? how? Say I have an online store that accepts bitcoins and want people to be able to contact me through my wallet, because that is ultimately the entity involved in an hypothetical trade.

Can that be done? how?

Not in any way that is intended by the protocol.

What do you mean by "ultimately the entity involved in a hypothetical trade"? It's just a hash of a public key, the corresponding private key to which you hold.

What is preventing you from having a contact form or e-mail address in the online store?


Checking external bitcoin address balances via JSON-RPC API I'm using bitcoin core json-rpc api in python and am wondering why...

getreceivedbyaddress()

...doesn't allow me to specify an address that isn't in my local wallet?

The whole blockchain is open, I can search anyone's address/balance via a web browser, so why would the API prevent me checking?

Is there another method for doing this that I'm missing?

Bitcoin Core does not track each individual address, only the addresses associated with your wallet.

There are other clients, such as bitcore-insight and btcd, which maintain a separate address index.

Alternatively, you can implement an index yourself, or run an existing one such as ElectrumX.


Is multi-PPS the correct solution to the mining centralization problem? See this post. Meni believes that this could be the correct solution to the mining pool centralization problem, and that are no known drawbacks. There is some work that needs to be done to write, test and integrate the code of course (perhaps money could be raised for this via Lighthouse).

Is multi-PPS indeed the right solution?

First it should be understood that Multi-PPS aspires to solve only one aspect of mining centralization - the centralization of many small miners in a few large pools. It doesn't solve the problem of huge mining entities that enjoy economies of scale - though, I don't think that problem is too great to begin with, as I claimed in here.

Under the assumption that the cause of mining pool centralization is the built-in performance advantage (in terms of variance and fees) of large pools (as opposed to psychological factors and features), any solution must be based on having each miner target multiple pools simultaneously. This way, there can be many small pools while the miners enjoy the performance of large pools.

Multi-PPS specifically is best suited for a future scenario when Bitcoin mining is dominated by transaction fees. However, that scenario has some inherent challenges that will need to be solved in the context of any reward framework, Multi-PPS included.

Multi-PPS is an extension of classical PPS, in the same way that mining in multiple pools is an extension of classical PPLNS. Multi-PPS allows PPS with low fees, and mining in multiple pools allows PPLNS with low variance.

For either of these to work, mining pools need to become more of a commodity, so that the mining client can automatically connect to many pools to optimize the performance.


Why the leading zeros in the desired hash pattern? Why are leading zeros desired in the block chain hash?  I have searched the internet but cannot find why.

The leading zeros are there to control the difficulty of the problem. More zeros mean a lower space of possible solutions and hence harder problems (more hashes to try before you find one that wins).


Is the compact block protocol faster than normal blocks when it has to do getblocktxn/blocktxn round trip? When a compact block fails to rebuild a block from the mempool the node sends a getblocktxn message to learn about the missing transactions.

Does requesting for the missing transactions make the compact block protocol as slow as the normal block during new block propagation?

Thanks!

Yes, compact blocks are still usually faster even when there is a getblocktxn round trip.

The reason for this is because all that needs to be sent in that case is the requests for the missing transactions and the missing transactions themselves.

Although the time is increased by another round trip in this case it is only a single round trip and there is little delay from sending the data itself (serialization delay) since there is very little data to send.

When a full block is sent many round trips can be required due to TCP flow control and packet retransmissions and simply from the time it takes to send the additional data.

In the case where almost all transactions are unknown (which doesn't happen in practice) compact blocks would take about the same amount of time as non-CB transmission.

FWIW, on my node here 86.75% of the last 288 blocks (203) required no round-trip and 99.9749% of transactions were known in advance (378715 out of 378810).


How do I set up my machine to process transactions and earn the transaction fees? I am unable to earn money from solving blocks, but I think I could make money from transaction fees. The issue is that pools hide the transaction fees from the miners. The miners earn the solved blocks. How would I go about processing transactions on my own?

This will satisfy two goals:

earn transaction fees
any transactions I perform, I can process myself

The only way to collect money from transaction fees is to solve blocks; they are one and the same thing. The reward for being the first to successfully mine a block is:

the coinbase reward (currently 25 BTC), and
any transaction fees for the transactions included in the block

There is no way to separate these two.


Can I open many channels to one connection? Trying to learn the Lightning Network :)

Can I do something like this:

STEP 1: Generate new addresses

address_1 = cli/lightning-cli newaddr
address_2 = cli/lightning-cli newaddr
address_3 = cli/lightning-cli newaddr
address_4 = cli/lightning-cli newaddr
address_5 = cli/lightning-cli newaddr

STEP 2: Get transaction ids

txnid_1 = bitcoin-cli -testnet sendtoaddress address_1 60000
txnid_2 = bitcoin-cli -testnet sendtoaddress address_2 70000
txnid_3 = bitcoin-cli -testnet sendtoaddress address_3 80000
txnid_4 = bitcoin-cli -testnet sendtoaddress address_4 90000

Question 1: the commands above transfer money the BITCOIN NETWORK to the LIGHTNNG NETWORK - right??? If so, which BITCOIN "FROM" address is being used?

STEP 3: See who I am connected to

run: cli/lightning-cli listpeers (to see who I am connected with)

Please note that for my example:

Public Key for NODE_B => is not on list above (not a peer)
Public Key for NODE_C => is not on list above (not a peer)
Public Key for NODE_D => is not on list above (not a peer)

STEP 4: Fund the channels:

The command I see for funding a channel is:  cli/lightning-cli fundchannel

BUT -

What I would like to do:

cli/lightning-cli fundchannel NODE_B 10000 [txnid_2]
cli/lightning-cli fundchannel NODE_C 20000 [txnid_2]
cli/lightning-cli fundchannel NODE_B 30000 [txnid_3]
cli/lightning-cli fundchannel NODE_D 40000 [txnid_4]

For example I want to fund a channel to NODE_B with 10000 Satoshi from  txnid_2

Question 2: Is what I would like to do possible?

TIA

he commands above transfer money the BITCOIN NETWORK to the LIGHTNNG NETWORK - right???

No. It sends money to addresses the c-lightning can use for creating Lightning Network transactions. There is no "transfer money from Bitcoin to Lightning", they are not separate and distinct things.

  If so, which BITCOIN "FROM" address is being used?

There is no such thing as a Bitcoin from address. That is not how Bitcoin works. It may seem like there are from addresses, but that's just a simplification for users.

  Is what I would like to do possible?

No, it is currently not possible to choose what transactions to use to fund your channels with c-lightning.


What exactly is Mining? I have heard that mining is for people with ready hardware and blah blah blah... But what exactly is it? Does it operate like real mining? I mean, people talk about it like you are physically mining.

David Schwartz's answer is entirely accurate, but all that "bitspeak" might be a little intimidating to the average user.  Let me try and put it into more plain language:

The way Bitcoin works is that instead of having one central authority who secures and controls the money supply (like most governments do for their national currencies), this work is spread out all across the network.  Most of the heavy lifting for Bitcoin is done by "miners".

Miners collect the transactions on the network (like "Alice pays Karim 10 bitcoins" and "Liam pays Sofia 8.3 bitcoins") into large bundles called blocks.  These blocks are strung together into one continuous, authoritative record called the block chain, which doesn't permit any conflicting transactions.  This is necessary because without it people would be able to sign the same bitcoins over to two different recipients, like writing cheques for more money than you have in your account.  The block chain lets you know for sure exactly which transactions count and can be trusted (so no bad cheques!).

The way Bitcoin makes sure there is only one block chain is by making blocks really hard to produce.  So instead of just being able to make blocks at will, miners have to compute a cryptographic hash of the block that meets certain criteria.  Bitcoiners refer to this process as "hashing".  The only way to find a cryptographic hash that's "good enough to count" is to try computing a whole bunch of them until you get lucky and find one that works.  This is the "lottery" that David Schwartz refers to, because miners who successfully create a block are rewarded some bitcoins according to a preset schedule.  The difficulty of the criteria for the hash is continually adjusted based on how frequently blocks are appearing, so more competition equals more work needed to find a block.  Modern dedicated mining hardware (e.g. ASIC miners) can try trillions of hashes per second, so to be competitive in this race to find hashes miners need specialised hardware, otherwise they will tend to spend more on electricity than they make in the "lottery".

In addition to the hash criteria, a block needs to contain only valid, non-conflicting transactions.  So the other main task for miners is to carefully validate all the transactions that go into their blocks, otherwise they won't get any reward for their work!

Because of all this work, when a Bitcoin client signs on to the network it can trust the block chain that was most difficult to produce (since this is evidently the one that was being worked on by the most miners).  If there was a "fake" blockchain competing with the real ones (say, where someone pretends that they didn't actually give Sofia those 8.4 bitcoins and they still have them), the fraudster would have to do as much work as the whole rest of the network to make their block chain look as trustworthy.  So essentially, the intense work that goes into finding blocks through hashing secures the network against fraud.  There is also, of course, some nifty code that figures out how to choose between conflicting transactions; and what to do if two people find valid blocks at the same time.

One last thing:  why is it called mining?  In the original analogy, people who performed this essential work were compared to gold miners digging the gold out of the ground so that everyone could use it.  But in reality, Bitcoin "miners" are just running computer programs on very specialised hardware that automates the process of securing the network.  To sum up, this software

Collects transactions from the network
Validates them, and doesn't allow conflicting ones
Puts them into large bundles called blocks
Computes cryptographic hashes over and over until if finds one "good enough to count"
Then submits the block to the network, adding it to the block chain and earning a reward in return.

That's mining in a nutshell!


Vanitygen: How ot store all generated addresses? i want to know it is possible to store all generated addresses into file (or DB).
How it can be?
For example i need to generate 1,000,000,000 addresses, with vanitygen speed about 50M per second.

./vanitygen -k 1 -o output.txt

will generate addressses until you stop it, and will save the addresses to output.txt. It won't be formatted, so it's a better idea to use Vanitygen Plus's -z option, which formats the output as CSV.


How multi-signature wallets comunicate with each other? I wonder how multi-signature wallets communicate with each other?

My favorite wallet is copay. How do they communicate with each other before payment is done? How is privacy handled between each multi-sig device?

The final transaction that gets broadcast to the network, just like every other Bitcoin transaction, is public.  This is safe because signatures do not reveal any secret information.  In the case of multisig wallets, when one wallet adds its signature and then sends it to another wallet, it doesn't matter if anyone is eavesdropping.  It would be perfectly safe to send the partially-signed transaction in the clear.  After all, when subsequent signatures are added, it will all be made public anyways.

That said, there can be privacy implications about whether you wish to let the world know who you are doing multisig with.  In that case, establishing secure channels for communication becomes important, as well as making sure the addresses/public keys used are not somehow associated with your identities.


Lightning network: which update messages are replayed? If I understand correctly, after a new node connects to a peer in the Lightning network, it receives all past channel announcement / update messages for currently open channels to recreate a local snapshot of the network. What messages are replayed? For example, for a very old channel with lots of channel updates, are all of them replayed? Why not just report the latest update message?

You should look at BOLT 07 which describes the gossip protocol and depends on BOLT 08 (Transport via the Noise Protocol framework) and BOLT 01 (Messaging)

In particular if you look at the channel_update message you will find this quote from the BOLT 07:

  if timestamp is NOT greater than that of the last-received channel_update for this short_channel_id AND for node_id:
  SHOULD ignore the message.

  otherwise:
  if the timestamp is equal to the last-received channel_update AND the fields (other than signature) differ:
  MAY blacklist this node_id.
  MAY forget all channels associated with it.

  if the timestamp is unreasonably far in the future:
  MAY discard the channel_updat

Also in the section about rebroadcasting you can find the following quotes:

  upon receiving a new channel_announcement or a channel_update or node_announcement with an updated timestamp:
  SHOULD update its local view of the network's topology accordingly.

  after applying the changes from the announcement:

  [...]

  SHOULD update the appropriate metadata AND store the signature associated with the announcement.
  Note: this will later allow the node to rebuild the announcement for its peers.

The way how I read this is that nodes only store the latest channel_update message per channel which they can detect via the timestamp. Also when the initial sync takes place the latest update messages for each channel are also being sent.


why should I backup zcash wallet regularly On zcash official website, making regular backups of the wallet is recommended.

When I use bitcoin, I have a master private key, and all private keys can be generated using the master key. So I can only backup my wallet once.

So what's different in zcash? Why should I backup the wallet regularly?

The BIP32 specification allows a user to derive many keys from a master extended private key, and this master key is derived from a seed (often, a mnemonic phrase). This allows the user to just back up one piece of data (the seed phrase), knowing that they'll be able to use it to derive all subsequent keys in their wallet.

Prior to the implementation of BIP 32, most wallets were a collection of keypairs that were independently generated at random, so one key would bear no relation to the next. In this style of wallet, every time you generate a new address, you need to save a new backup copy that includes the new address. Older backups would not contain the info that allows you to derive the same new address.

I am not extremely familiar with Zcash, but I would guess that not all implementations of their wallet software use a BIP32 style wallet architecture, thus the recommendation for regular backups (similarly, not all bitcoin wallets use BIP32).


Are Bitcoin transactions permitted to have no outputs (i.e. all inputs become transaction fee)? I am interested in the possible use of the Bitcoin (or other altcoin) blockchain as a generalized distributed ledger, meaning that it is useful for tracking information other than coin transactions proper. A prerequisite for that would seem to be the ability to pay for transactions whose primary purpose is not moving Bitcoins from one address to another. So, can Bitcoin transactions list no outputs, thus leaving all inputs as a transaction fee reward for the miner?

No. If you create one, it won't be relayed or mined by Bitcoin Core. If it gets into a block, it will be rejected. From the source code for Bitcoin Core (tx_verify.cpp:164):

if (tx.vout.empty())
    return state.DoS(10, false, REJECT_INVALID, "bad-txns-vout-empty");

However, you can create a vout with 0 satoshis. That isn't a "standard" transaction, so it will not be mined by the software by default. However, if it gets into a block, it's valid.


Can you really trust a non-open-source desktop wallet? I am a newbie in the crypto markets, but as a software engineer, it seems to me that a huge security vulnerability could be choosing a wrong wallet.
If you are using a hot wallet, and can't see the app code, doesn't that mean it is theoretically possible for the devs to steal your crypto, even if you can see your private key?
Shouldn't everyone be using exclusively open-sourced wallets for this reason?

Can you really trust a non-open-source desktop wallet?

No

Shouldn't everyone be using exclusively open-sourced wallets for this reason?

Yes, everyone should use open source wallets. And still use small amounts in hot wallets or wallets that are relatively new and experimenting with new features.
More details: What stops a wallet from stealing bitcoins?


Bitcoin UTXO anatomy I've been using a command line tool to fetch spendables from a Bitcoin address. Given an address the following command (source) ouptuts UTXOs the address can spend.

tx -i 1A3cbxFC4zrfgxEb6GhAe97m2rSEyvUetp
 >
4db2ddb59e0cd123d8d0715da9dddbe6b2697c5a1d83163cc049dcc152d1f7ed/0/76a9146337aefd82e6c1f83ab505b78c3bcc413b49364088ac/1061/0/0/0

The format is address/utxo index/script hash/...
However I do not know what the last 4 elements mean, I'm guessing amount, but don't know what the 3 zeros that come afterwards mean - any help appreciated.

As per the source, the parts of that output are:

tx_hash/tx_out_index/script/coin_value/block_index_available/does_seem_spent/block_index_spent


What are the major components of a bitcoin full node's bandwidth usage? A bitcoin full-node uses bandwidth to at least:

Receive each block
Send each block to other nodes

What other major components of bandwidth usage are there for a bitcoin full node in early 2018, and what proportion of the bandwidth usage does each take up?
Bandwidth usage is many times higher than that required to receive and then send 1 full block of data per block, and I'd like to understand why.

Receiving transactions from other nodes
Sending transactions to other nodes
Sending the entire blockchain to other nodes so that they can sync

Note that with compact blocks, block relay does not consume nearly as much bandwidth as it used to. Compact blocks allow blocks to be relayed with way less data. The bulk of a node's bandwidth is taken up by transaction relay.


Who can 'own' a wallet? I administer a public association. Can the association have a bitcoin wallet? Or does it have to a person that owns the wallet.

Any sort of entity can own a bitcoin wallet. Being a decentralized system, there are no rules in place saying what sort of persons or organizations can own bitcoins.

The simplest way to manage it would be to give the password to one or more trusted leaders of the association. This would mean that any of those leaders could spend (or steal) the funds at any time.

Another way would be to use a multi-signature address, so that some quorum (say, 4 out of 5 board members) of signatures is required. This would mean that your leaders must agree to spend (or steal) some amount of funds. You might generate this with, e.g. https://coinb.in/multisig/

You could have one of each: a "hot" wallet that anyone can spend from, for convenience, and a "cold" wallet that stores the bulk of your funds, but requires additional authorization to spend from.


bip44 address generation I am writing hd wallet following bip44.

After each transaction, should I create a brand new change address each time?
Or can I use the same change address multiple times?
What is the recommended practice here?

The recommended practice is to use any address for only one input and one output. Once you've done that, don't use it again.

To illustrate with examples:

You receive 1 bitcoin to address A. You later send 1 bitcoin out. The next time you receive any bitcoin it should be with new address B.
You receive 1 bitcoin to address B. You later send .5 bitcoin out. Transaction input should be 1 bitcoin from address B. Output should be .5 bitcoin to other person's receiving address and .5 bitcoin to your address C.
Later, you receive 1 bitcoin. You should receive it with new address D. Your total wallet balance is 1.5 bitcoin, between addresses C and D.
You spend .25 bitcoin. The transaction input should be .25 from address C and output should be .25 to other person's address and .25 to your address E. Address C is favored because it is the least number of inputs required to make the transaction. You now have 1.25 bitcoin between addresses D and E.
You spend .15 bitcoin. Input is address E. Output is other's address and your address F. You now have 1.1 bitcoin between addresses D and F.
You spend 1.05 bitcoin. Inputs are addresses D and F. Outputs are other's address and your address G. You now have .05 bitcoin in only address G.


Is it cost-effective to purchase an expensive card? I was considering purchasing the Monarch BPU 300 C or the 600 C.  However, neither of them are expected to ship before February of 2014 or later.

If this calculator is to be trusted, it doesn't seem like one could ever earn back the cost of either of these units, especially if this difficulty graph is accurate.

According to said calculator, the 600 model would leave you $2000 short after 6 months at a purchase price of $4680.  Also, the cheaper 300 model would leave you about $1450 short after 6 months after a purchase price of $2800.  And those figures are assuming you start using the product in mid-February.  If Butterfly labs are late on shipping the cards, and you start in March... forget about it.

I'm fairly new to the Bitcoin game, so can someone tell me if I'm wrong about this?  Is it actually wise to purchase either of these cards?

Edit - The short answer is NO, especially for SHA-256 currencies.  I spent about $1000 on a 50 GH/s miner.  It generated about $30 per week in gross profit, but the net profit was less due to pool fees.  Also, my electric bill rose by $100 per month.  Luckily, I was able to find someone to buy the miner from me on ebay for CLOSE to what I paid for it.

For $2800 (the price of Monarch 500GH/s, as of 23 Dec 2013), and $4680 (the price of Monarch 600GH/s, same date), you might as well purchase a 1TH/s mining hardware, such as from VMC, or CoinTerra.

The other alternative is to use these mining hardware to mine some other altcoin, instead of Bitcoin, and hope that the other altcoin would come to prominence one day, instead of bitcoin.

The answer to your question is that unless the difficulty drops, it is no longer cost effective to purchase mining hardware.


How do I move money from one address to another on the same wallet? My wallet have 3 addresses. I want to consolidate payment into one.

What should I do in bitcoin-qt.

Notice on the SAME wallet. I know how to do this if the addresses are on different wallet.

I just don't want to keep moving wallets because I have backups on those wallets.

Create a new address and send your entire balance to that new address.


How to make a Hidden Tor Bitcoin Mixing Service? Bitcoiners. I have been trying to seek out a legit Bitcoin Mixing service, and I just don't feel secure by putting my coins in their hands. I have scoured the internet trying to find a tutorial on how to make a .onion Mixing Service. I want to be able to help others and me become safer with transactions, and I am running out of luck. If you know how to make a Mixing Service, please let me know how, or give me a link. Also, I would like to be able to have a small transaction fee [E.G. Base Fee of: 0.75%; For every transaction/day an additional 0.002 BTC is taken]. I am really feeling annoyed that I can't find an answer ANYWHERE, so please reply to me ASAP with an answer on how to host a service.

P.S. I am using a Windows XP [Dell Desktop] and Windows Vista [Toshiba Satellite] to host it on. If you have something I ABSOLUTELY NEED to download for the service, you can send it to adaptornode@tormail.org

BitcoinFog is popular and has been around for a few years. If you really want to make your own, you'd need a dedicated server, Tor (for the hidden service), web server software like Apache, and Bitcoin-Qt (or some other bitcoin software which can be interfaced with through PHP). To have it be really safe, you'd need to set in place other precautions like a firewall or a separate server running Bitcoin-Qt.


Warning: Unknown block versions are being mined! Unknown rules may be active Best regards.
What's going on internally when I get this warning.

Warning: Unknown block versions are being mined! Unknown rules may be active

Bitcoin Core version v0.17.1 (64-bit)

Thank you

This warning is currently benign and has been fixed for Bitcoin Core 0.18. You see it because miners are using the block version number for a mining optimization called ASICBOOST. However soft forks in the past have used the version number for readiness signalling. Bitcoin Core is seeing version numbers it is not expecting (due to ASICBOOST) and thus triggering the warning.


Dynamic coinbase as incentive to fill blocks Miners do not currently have a monetary incentive to fill up blocks with transactions (tx fees are negligible compared to the coinbase tx). Those miners that do fill up the blocks may do so with the long-term interests of the network in mind.

It seems clear to me that making the coinbase amount a function of the relative size of the block would result in a much better incentive. I cannot see any obvious drawbacks with it.

A simple formula would be: actual_coinbase = coinbase * (actual_block_size/MAX_BLOCK_SIZE)

For example: actual_coinbase = 25BTC * (512KB/1024KB) = 12.5BTC

Of course the actual implementation would have to take into account consensus issues (rounding, corner cases, etc), but it should be possible.

Why would this not work?

This adds an incentive to fill blocks with ANYTHING that will take up space in the block. There are many different ways to incentivize including transactions, but they can typically be gamed because miners can create transactions themselves, and they gain all the fees from those transactions right back into their coinbase transaction.

Your suggestion, which has good intent, would likely cause miners to be incentivized to fill their blocks with meaningless transactions, and increase the already ever-increasing size of the blockchain, making it harder to run a full node.


Web Wallet Creation with PHP and bitcoind How would one start creating a web wallet?  What I have so far:

Generate an address per user of the wallet using bitcoind

How can I secure the private key?

Tell user deposit address using bitcoind and php
Get balance of address after a deposit using more php? (what RPC call must I use?)
Here's where I am stuck - How can I allow the user to send to somewhere else?

Thank you

I would look into using sxtools/libbitcoin or maybe just the blockchain.info API. You can make private keys using a vanitygen if you want to make addresses without using bitcoind and perhaps (if you are skilled enough) create raw transactions and push them straight to blockchain or chain sites or even a public bitcoind.


nLockTime in Bitcoin Core Currently, the Bitcoin Wiki states:

  A part of the original Bitcoin implementation, nLockTime is a field that specifies the earliest time a transaction may be added to a valid block. A later Bitcoin soft fork allowed nLockTime to alternatively specify the lowest block height a transaction may be added to a valid block.

Is the ordering correct? It appears that the source code as of v0.1.5 used the block height and v0.1.6 extended this to handle timestamps. Also, does this new ordering make it a hard-fork?

I believe you are correct, both about the fact that height-based logic came first and time was added later, and the fact that this is a hard-forking change. A transaction with a locktime > 500000000 would not have been acceptable before the change, but possibly valid after.

Of course, given that no such transactions occurred (to the best of my knowledge), it isn't exactly a fork; but it was a change that could have led to one.

Also, before the removal of OP_VER, technically speaking every new release had a hard forking change of this nature.


How to retrieve all transactions from bitcoind? I am working on a project that need to parse all transactions from bitcoind. I have been using bitcoind which the option txindex=1 and pulling transactions using RPC call getRawTransaction. It work, but is very slow.

Is there any fast way to pull all transactions from bitcoind? (I dont need to pull them in order).

I tried to read then directly from bitcoind DB, but according to What is the database for? transactions are not stored in levelDB, there are only at blockXXX.dat, in network format, so I would need to parse the block to extract them, which doesnt seem OK (I guess that orphan blocks are also there, so that will generate problems).

Making an RPC call per transaction adds a lot of overhead.

It's not clear exactly what you mean by 'all transactions', but I'll assume you have a way of identifying 'all blocks' for which you want the transactions.

You can reduce the overhead, then, to one RPC call per block, by using getblock with the second option (verbose) set to false (getblock blockhash false), and then parsing the raw block data directly yourself.

There's a bit of work involved in parsing the raw block data yourself, but if you're already working with raw transaction data then I guess you may already have the code to do the relevant decoding.
If not, it's not too hard to set this up, in any case.

As a side effect, note that the full transaction index (txindex=1) is no longer required with this method.

I've written about this specific issue in more detail in this blog post, so check this post for more details, and some example code..


Can this double-spend attack happen in Bitcoin? I am trying to learn more about Bitcoin.

I was looking at this video to understand how a "double-spend attack" is kept from taking place on the Blockchain (in Bitcoin).

https://youtu.be/Lx9zgZCMqXE?t=12m13s

In this case, Alice might send money to Bob to purchase an item.

Alice may use the same input to send money to Joe for another item at the same time.

It then becomes a race as to which one will get approved and which one will get rejected (the one sent to Bob or Joe).

It is my understanding that a "double-spend attack" could not take place because all of the nodes will be working at the same time.

I have heard of transactions not being processed for days because of a low miners fee.

In such a situation, would not this allow ample time for a "double-spend attack" to take place?

TIA

Yes, double spend attempts can happen. They're the reason we need a blockchain in the first place. To be able to know which transaction was "first" and which one was the double spend we need an agreed-upon record of history: the blockchain.

Until a transaction is in the blockchain, there is no way to know whether it was the first or a double spend, so it's actually pretty irrelevant which is which. Once a transaction is in the blockchain it by definition becomes the "first", and all further attempts are "double spends" (and invalid, so they'll never go into that blockchain).

Proof of Work mining provides a slow ticking (and very hard to fake) clock that defines the order of transactions.

The only thing that can still screw you over is a re-org: another branch of the blockchain with possibly different transactions overtaking the branch that you were looking at before and becoming the de facto accepted branch. That's actually not uncommon to happen if you only have one or two confirmations but becomes exponentially less likely with each additional confirmation. That's why the white paper suggests waiting for six.


You did, presumably.

The transaction you're showing is the coinbase; it's a  special transaction added by the miner. The OP_RETURN output is the SegWit block commitment. It is the Merkle root of all transactions' wtxid (a txid that includes the witnesses), thereby making sure that the block commits to all witnesses.

When running in regtest mode, you probably directly or indirectly from a script called the generate RPC call, which produces a new block. If there were any SegWit transactions in the block, the commitment is mandatory (and optional otherwise).


Relation between bitadress and blockchain When i create a wallet at bitaddress.org i could see my balance at  https://www.blockchain.com/explorer . If bitadress.org is a client sided page and shouldn't send any information to outside world and I haven’t shared the wallet address with anybody, how does the blockchain.com/explorer page know if an address is included in a wallet?

how does the blockchain.com/explorer page know if an address is included in a wallet?

Short answer: it doesn't.
Blockchain.com just looks to see if it has a record of a transaction involving the address you give it.
A transaction is something such as a bitcoin-exchange sending you Bitcoin (after you sent them dollars) or you sending Bitcoin to someone else (e.g. when buying something with Bitcoin)
Details of Bitcoin transactions are public information and are copied to every Bitcoin user (or are available to every Bitcoin user).
But you don't need to use bitaddress.org or any similar service and I wouldn't!

A little more detail.
The web-page at Bitaddress.org uses a pseudo-random number generator based on mouse movements and keyboard input to generate a random private-key.
From a private-key you can derive a public-key. The Bitcoin-address is a hash of the public-key.
The private-key enables you to spend Bitcoin and should never be shared with anyone else.
The public-key enables other people to send you Bitcoin, you give them the address derived from the public key.
There need be no link between bitaddress.org and any blockchain explorer. The latter just searches the blockchain for transactions involving the address you type in.
The blockchain is a ledger (or more accurately a journal) containing a record of all bitcoin transactions from the creation of Bitcoin 10 years ago. All "full-node" wallets have their own copy of the whole blockchain.

Don't trust websites
Despite the above, I would not use a public service like bitaddress.org to create my private-key. After all, we don't know if the owner of that website dishonestly keeps the private-keys (or has been hacked). Bitcoin was originally designed to be used without trusting third-party services like this. You can download a desktop-wallet and generate your private-key in the privacy of your own home on a computer that is disconnected from the Internet. That is the one of the safest ways to inexpensively create a Bitcoin wallet.

Never let anyone else generate, use, borrow or see your private-key
Never share the password to your wallet, even if you change it afterwards it is useless to do so because they can already have copied your private-key - which they can later use outside your wallet to spend any  Bitcoin you later added to that wallet.
If you do not understand Bitcoin adequately you may lose all your money.
If you trust websites, you may lose all your money.
If you are not careful about these things you will lose all your money.


Does the Share Difficulty given to each miner matter? I am running two 7970's and am adding a 3rd here in a few days (Mainly a Gaming Rig)but mining when I am not gaming.  I was wondering though does the minimum share difficulty that BTCguild sends to my miners make a difference?  Currently it is just the default of 1 but can go all the way up to 256 share difficulty. What is going to yield the best results for my hardware?

I am still quite new so any other advise is appreciated!

Increasing your submission difficulty will reduce the number of shares you submit, in turn reducing your bandwidth costs and your pool's bandwidth requirements.

The downside for you as a miner is that increasing your share submission difficulty increases your variance in earnings. If you mine at a pool with user determined share submission difficulty (such as HHTT and Itzod) then it's up to you to decide how much variance you can bear. I've covered in detail the amount by which your earnings variance increases with increasing share difficulty elsewhere, and you may want to look there for specific details.

Otherwise, at pools which automatically change submission difficulty to keep you submitting at a constant number of shares per minute, the variance should not be noticeable over an hour, and definitely not noticeable over a day.


How to check Bitcoind is mining? I am still very new to Bitcoin.
I installed bitcoind on my Ubuntu server as described on bitcoin.org.

After installation I issued

  bitcoind -daemon

and the tool started to download/get the blockchain (which is finished meanwhile).

Three questions:

In contrast to what the setup guide says, the tool did not complain about a missing rpcuser and rpcpassword in the bitcoin.conf file. Is that an issue with the documentation or is there something wrong with my installation?
In case my node gets the chance to process a block, I would be rewarded those 25 BTCs. But to which account would the be sent? Is there a default or do I need to do some configuration for that?
As the process to become the node to mine the next block is computational very heavy, I would have expected that the CPU usage of my server should always be very high - but it's only at <10%. How can I make sure that my node participates to become the one to process the next block? Is there some configuration that I missed?

Answers to your respective questions:

Since 0.12, bitcoind supports cookie file authentication. This means that on startup of bitcoind, a file with a random key in it is created. Anyone who can present the contents of that file to the running bitcoind is allowed access. Since bitcoin-cli runs locally and as the same user, it can read this file and do so.
Bitcoin does not have any concept of accounts (at least not at the protocol level). Generated funds by bitcoind's built-in miner are sent to an address taken from your local wallet. If you want to modify that, use mining software instead of the built-in miner (which is only there for testing purposes).
The built-in miner is off by default. You can enable it by setting gen=1 in the bitcoin.conf file, but I would strongly discourage you from doing so. The chance of finding a block using that setup is about 1 in a billion, if you leave it running for 10000 years. If you insist on using your CPU for mining (which won't ever be profitable), at least use optimized software like bfgminer, and sign up with a pool, so you can get small rewards for work, rather than waiting for a lottery you'll never win.

Update august 2016: The internal miner is removed entirely in Bitcoin Core 0.13.


Multibit is not accepting the correct password any idea or possible bugs that i could fix just what i said. Multibit simply isn't accepting the password i used this morning to unlock it.

i have tried retyping it about a million times in a million different way.

does any one have any insight on this? it there a way to import the wallet into a different program and de-crypt it there?

That is certainly weird and it's most likely that you simply are typing a different password. To test this hypothesis, install MultiBit on another computer and import your wallet to see if it works. Perhaps your local MultiBit instance is corrupted.

Another option would be to try different versions of the client, although the wallet encryption algorithm hasn't changed. From the source code it seems to be using the Bouncy Castle Crypto APIs for Java: https://github.com/jim618/multibit/blob/master/src/main/java/org/multibit/crypto/KeyCrypterOpenSSL.java

Perhaps what you could also try is download that Bouncy Castle library and try decrypting your wallet directly using the raw library.


Only 10 connections on my raspberry pi full node I'd like to know why I only get 10 connections on my full node?
Is there something missing in the conf file?
$bitcoin-cli -netinfo
Bitcoin Core v0.21.0.0-7d8a10a6f - 70016/Satoshi:0.21.0/

ipv4
ipv6
onion
total
block-relay

in
0
0
0
0
0

out
7
0
3
10
2

total
7
0
3
10
2

Local addresses
myadress.onion     port   8333    score      4
my bitcoin.conf file
#Tor stuff
proxy=127.0.0.1:9050 #outgoing
listen=1 #enable download of new data
bind=127.0.0.1
deamon=1 #to run binary in background s.t. console is free
server=1 #to access deamon API
rest=1 #deamon offers web service so other tools like curl can access it
rpcuser=myuser
rpccallowip=127.0.0.1
rpcbind=127.0.0.1
maxconnections =50
Let me know if you need more info, thx!

bind=127.0.0.1

Binding the p2p port to localhost means that it can not accept incoming connections from anywhere other than software on your own machine.

listen=1 #enable download of new data

This allows incoming connections to whatever is configured by bind, it doesn't have anything to do with downloading data yourself.