Where can I get a list of command options for bitcoind and primcoind? I just installed bitcoind and primecoind on my ubuntu server. I was wondering where can i get all the command options for these daemons. The --help list does not display everything on primecoind as i dont even see the option "listaccounts" there. How else can i get a list of these options?

bitcoind help lists the RPC commands. listaccounts is a RPC command. bitcoind --help lists the commandline options to the program itself.

EDIT:
You can also use bitcoind help [RPC command] for a brief description.


Why would you need to "catch up" in the 51% attack? There is a lot of information on the 51% attack where an attacker is able to branch the chain and "catch up" and build a new branch that is longer than the old branch. Other than requiring more than 50% of the network's computing power, the biggest thing that makes this attack infeasible is that the further behind an attacker is, the harder it is to catch up. Some places say that this means that a payment receiver can simply wait for a couple of blocks to go by and by that time is becomes infeasible for an attacker to catch up from that far behind.

But why would an attacker ever have to "catch up"? Couldn't an attacker with 51% of the network's power branch the chain as soon as a new block is released and work on that branch in secret? Then at any point the attacker could publish his branch, effectively reversing any transactions that occurred between the time he branched the chain and the time it is published to the network.

You're exactly right; there's no need to catch up if you don't start off behind.

As soon as I get 51% of the network's hashing power, I start building my fork in private, then buy something on the 'real' fork and allow the purchase to get as many confirmations as it needs.  It will be a lot, because I'll be buying something really expensive.  I take care not to include my transaction in the private fork.

Then, once the goods are shipped I publish my secret fork and get my coins back.

The Finney attack is only good for double spending when the recipient accepts unconfirmed transactions.


Bitcoin animation from The Good Wife S03E13 Is the Bitcoin-related animation that appeared in The Good Wife S03E13, quite similar to the one on WeUseCoins, available anywhere on the internet in full?

Here is a link (YouTube) to the clip with the animation in it. I don't know if the actual animation on its own is available anywhere.


Multiple Addresses in one UTXO The 'decoderawtransaction' RPC method of the Bitcoin-QT client gives a JSON object with an array of addresses in each UTXO. For example, when I run:

decoderawtransaction "01000000010fb72b5d299f095c3d3abc2130f20ce59d0ed08d56b3f247d6ae554f200eb561010000006a473044022073717edfcde0200f8aca33b6ff4f60a4aa84c6692cd1713876d94f3f19013f6d022057610074eef8285082cb9943913040031869cc98bc71642a3dc5e085a19a1805012103f071bc0f54b95e9049ba515f19cbfb647605a9f1d2f002b4e70ec548af5fbf5bffffffff02b02bc37d010000001976a9148037b2fd4114347070236b37f792966ade2bc4a688acd0ce4101000000001976a914336e5078d05a350fb5e6cdf8fc15d826e625423888ac00000000"

I get back the following JSON:

{
  ...
  "vout":[
    {
      "value":64.04910000,
      "n":0,
      "scriptPubKey":{
        "asm":"OP_DUP OP_HASH160 8037b2fd4114347070236b37f792966ade2bc4a6 OP_EQUALVERIFY OP_CHECKSIG",
        "hex":"76a9148037b2fd4114347070236b37f792966ade2bc4a688ac",
        "reqSigs":1,
        "type":"pubkeyhash",
        "addresses":[
          "1CgxDbrb9d18DFvQn6DW8ij3c6ARpipehU"
        ]
      }
    }
  ]
  ...
}

You can see here that "addresses" is an array. Why is this an array? Can one UTXO send to multiple addresses? I know P2SH addresses can pay to an address that can be redeemed by the use of multiple addresses, but I'm wondering about sending to multiple addresses without the use of P2SH addressses. What would be the format of the scriptSig/scriptPubKey for doing so?

Also, if you only have the P2SH address, then can you determine what the requirements for redeeming from that address are?

Thanks!

An address is a shortened notation for a particular script. As a transaction output contains exactly one script, it has at most one address (it is possible that the script does not correspond to a particular address, though).

Due to historic reasons, a (normal pay-to-pubkey-hash) address is however also used to refer to keys (by giving the address that would correspond to a script paying to the hash of that key). The array that decoderawtransaction and gettransaction return as 'addresses' is an example of this. For a (non-P2SH) multisig address, if it is a m-of-n multisig script, it will decode the script, and give the keys it pays to (in address notation).


decompressing Multibit wallet private key in another wallet I have some bitcoin amount in my Multibit wallet. unfortunately i can not figure the password I put on it for transferring coins for the life of me despite trying all possible passwords i could think of. But i do have a back up copy of my private key and if you are familiar with multibit wallet you know upon backing private key it asks you to password protect your backup and i do have that password. so how can i impart this private key in another wallet and decompress it there? is there any wallet that can do it?
I do appreciate your help and comment.

Check out https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial to brute-force the password, however, you will need many CPUs. If you need help, contact me.


Bitcoin Intellectual Property Threats Are any known threats related to Bitcoin intellectual property?

(While unlikely, I guess one long shot threat is that one or more governments would ban the use of the technology.)

According to our good friend Wikipedia (my emphasis):

  Intellectual property (IP) is a term referring to a number of distinct
  types of creations of the mind for which a set of exclusive rights are
  recognized—and the corresponding fields of law.1 Under intellectual
  property law, owners are granted certain exclusive rights to a variety
  of intangible assets, such as musical, literary, and artistic works;
  discoveries and inventions; and words, phrases, symbols, and designs.
  Common types of intellectual property rights include copyrights,
  trademarks, patents, industrial design rights and trade secrets in
  some jurisdictions.

So to attack Bitcoin you'd need to produce evidence that someone else got there first, or that Bitcoin is mis-using an existing technology beyond it's remit (breaking terms of a license for example).

This would be hard given the unique nature of Bitcoin, the open source license it was released under (MIT - a very permissive license) and the well-established cryptographic protocols and algorithms it uses (SHA-256, RIPEMD-160, elliptic curve DSA) all of which are taken from worldwide standards (think IEEE, ISO, FIPS etc).

However, I am not a lawyer, and the law varies across the world. It may be possible through some convoluted mechanism to attack it and lay claim to a patent of some kind, but it would take obvious collusion on behalf of the respective court of law to ratify it which may serve to discredit the attacker.


How do I prevent lnd from participating in new channels? I have a lnd node that I would like to to cycle down completely. I would like to close all its channels and prevent that the node participates in any new channels while I'm waiting for the force-closed channels to mature.

What settings do I need to use in lnd to prevent my node from creating new channels, and to decline any new inbound channels?

You can set the option --maxpendingchannels=0 to disallow peers to open channels to your node.


Can miner send garbled block height? This previous answer shows that BIP34 adds block height as one of the fields in a coinbase transaction of a block. This question is about whether block height is calculated fully independently by each node, or the miner gets to influence it somehow (even by providing a garbled value that'll be considered only temporarily, i.e, before the validation of his supplied height fails).

Concrete questions:

Does this miner-chosen coinbase block height play any role in the determination of the actual block height when other nodes add this block in the chain?
Is the coinbase block height value "validated" by other nodes and if yes, where in the source code?
Is there any other imaginable situation/way a miner could pass a garbled height value and try to confuse other nodes?

If you look at the changes made to the bitcoin reference implementation with the implementation of BIP 43 (see this commit), you will see that a check has been added to the function 'AcceptBlock'. With this change, the function is now validating the height against the value taken from the coinbase script of the incoming block.

CScript expect = CScript() << nHeight;
if (!std::equal(expect.begin(), expect.end(),vtx[0].vin[0].scriptSig.begin()))
            return DoS(100, error("AcceptBlock() : block height mismatch in coinbase"));

So a block that contains a wrong block height in the coinbase transaction would actually be rejected by the other nodes in the bitcoin network (in the current version of the source code, this check is now in ContextualCheckBlock in validation.cpp). The value of the height to which the coinbase script entry is compared is taken to be the height of the current last block plus one, so it is calculated.

Thus the answers to your questions are:

1) no, the block height that a node actually uses is determined based on the current last block

2) yes, see the check in ContextualCheckBlock

3) probably yes, but then the DoS protection mechanism in the network would kick in and ban the respective node - and apart from that, the mining power that the miner has invested into the block with the incorrect height would be lost


CGMiner no output (LTC GPU mining) Here is my run command:

cgminer -o stratum+tcp://coinotron.com:3334 -u user -p pass --scrypt

the only output in my terminal I get is (and only this):

[2013-11-30 11:34:02] Started cgminer 3.7.2

if Ctrl+C it I finally get this output:

[2013-11-30 11:34:43] Summary of runtime statistics:
[2013-11-30 11:34:43] Started at [2013-11-30 11:34:03]
[2013-11-30 11:34:43] Pool: stratum+tcp://coinotron.com:3334
[2013-11-30 11:34:43] Runtime: 0 hrs : 0 mins : 40 secs
[2013-11-30 11:34:43] Average hashrate: 0.0 Kilohash/s
[2013-11-30 11:34:43] Solved blocks: 0
[2013-11-30 11:34:43] Best share difficulty: 0
[2013-11-30 11:34:43] Share submissions: 0
[2013-11-30 11:34:43] Accepted shares: 0
[2013-11-30 11:34:43] Rejected shares: 0
[2013-11-30 11:34:43] Accepted difficulty shares: 0
[2013-11-30 11:34:43] Rejected difficulty shares: 0
[2013-11-30 11:34:43] Hardware errors: 0
[2013-11-30 11:34:43] Utility (accepted shares / min): 0.00/min
[2013-11-30 11:34:43] Work Utility (diff1 shares solved / min): 0.00/min
[2013-11-30 11:34:43] Stale submissions discarded due to new blocks: 0
[2013-11-30 11:34:43] Unable to get work from server occasions: 0
[2013-11-30 11:34:43] Work items generated locally: 1
[2013-11-30 11:34:43] Submitting work remotely delay occasions: 0
[2013-11-30 11:34:43] New blocks detected on network: 1
[2013-11-30 11:34:43] Summary of per device statistics:
[2013-11-30 11:34:43] GPU0     | (5s):0.000 (avg):0.000h/s | A:0 R:0 HW:0 WU:0.0/m

my GPU is properly detected:

11:34:56 me@ArchPC::~/Desktop cgminer -n
 [2013-11-30 11:36:35] CL Platform 0 vendor: NVIDIA Corporation
 [2013-11-30 11:36:35] CL Platform 0 name: NVIDIA CUDA
 [2013-11-30 11:36:35] CL Platform 0 version: OpenCL 1.1 CUDA 6.0.1
 [2013-11-30 11:36:35] Platform 0 devices: 1
 [2013-11-30 11:36:35]  0   GeForce 9600 GT
 [2013-11-30 11:36:35] 1 GPU devices max detected
 [2013-11-30 11:36:35] USB all: found 6 devices - listing known devices
 [2013-11-30 11:36:35] No known USB devices

What could the problem be?

EDIT: Just tried it without --scrypt... it works then, but I need scrypt for LTC. How do I fix this?

Apparently I do not have enough points yet to give your answer a vote, but your solution also worked for me! Adding -T to the command line command did the trick. Not only do I now get a neat output of what is happening; the -T parameter also made the entire mining process actually work!

Before adding the -T command:
Screen flashed with the "Started CGMiner 3.7.2" message.
No messages were shown until I pressed CTRL + C.
The report said that only one share had been submitted and accepted - every time I ran CGMiner.

After adding the -T command:
The screen doesn't flash any more.
Everything that happens is outputted line by line to my command prompt.
CGMiner is actually working and submitting shares. As we speak I'm on a total of 3616 accepted difficulty shares, contrary to 32 before.


Specified data directory does not exist - but it does... anyone ever had a similar issue where the directory exists but bitcoin-cli isn't recognizing it? Perhaps this is related to me setting the folder up as a symlink to my external HDD?

Thank you!
aaronson

-Mac-mini:~ $ bitcoin-cli -regtest generate 1
Error reading configuration file: specified data directory "/Users/---/Library/Application\ Support/Bitcoin" does not exist.
-Mac-mini:~ $ cd /Users/---/Library/Application\ Support/Bitcoin
-Mac-mini:Bitcoin $ ls
banlist.dat bitcoind.pid    chainstate  db.log      peers.dat
bitcoin.conf    blocks      database    debug.log   wallet.dat

Do not use backslash and space symbols in folder name


Is there a significance as to why bitcoin mining "costs" time/energy/money? I have heard that the bitcoin mining process was created in a way that purposefully required the expenditure of resources (energy/money) in order to add real value to bitcoins. In this way, when more miners join, the value of bitcoins would rise because there would be additional resources that would be used to process the transactions. However, the way I see it, it is the opposite. In other words, it seems that the value of a bitcoin is based on supply and demand from buyers/sellers, and the degree of mining interest is based on this pre-established value. My reasoning is that people do not suddenly decide to buy or sell bitcoin because "oh there is more mining power going into validating the blockchain so it must be worth more." On the contrary, miners enter or leave the mining process based on whether the potential reward for successfully mining a block is "worth" the work, with the value of the reward being strictly based off the current market value of a bitcoin. Would anyone like to confirm or refute the latter hypothesis?

I have heard that [...] when more miners join, the value of bitcoins would rise because there would be additional resources that would be used to process the transactions.

I do not see why more validation power would make the currency unit more valuable. But before this discussion, lets clarify the technical side.

In general, the idea behind the Bitcoin protocol is to achieve a consensus view on the common transaction ledger in a decentralised way, i.e. no third-party intermediary to act as a clearing agency etc.
To avoid double-spending of coins, transactions need to be verified by miners before insertion into the blockchain - also, all nodes will synchronise with the longest chain available, so effectively the system works on a majority-based consensus system (majority of the miners determine the global chain).

Now, this would open up to security problems - one example is the Sybil attack, where an adversary simply creates countless virtual identities who all vote for his (potentially false) chain.

This is where the Proof-of-Work (PoW) scheme used in Bitcoin's mining protocol comes in. It is purposefully made computationally difficult for miners to verify blocks. Because of this, miners need to invest resources (energy, money) in order to participate - the rationale is that it is much harder to fake computational power in the network than simple identities, preventing a Sybil attack.

Back to the value of Bitcoin: Note that the following is rather subjective, and highly controversial.

I argue that it is simply determined by market supply and demand. Following this basic logic, the value of 1 BTC must increase in the number of users to join the network, since the monetary base of Bitcoin is limited by design. Because this is unrealistic in the long run, this argument can not be final.

On top of this, we can see extreme levels of speculation on cryptocurrency exchanges, driven by developments such as

adaptation (e.g. recognising Bitcoin as legal tender in some countries, more vendors' acceptance...)
news flow on upcoming updates, increasing awareness of cryptocurrencies and the resulting interest by the public and corporations
negative economic/political activity in some economies might lead to more demand for bitcoin

  On the contrary, miners enter or leave the mining process based on whether the potential reward for successfully mining a block is "worth" the work, with the value of the reward being strictly based off the current market value of a bitcoin.

Yes, this is correct. A causality between hashing power and the market value of 1 BTC is not apparent, other than that new miners will likely participate in the system themselves, increasing demand. Rather, as the market value increases, mining becomes more attractive in the short run. Note that after each 2,016 blocks, mining difficulty is adjusted to maintain a fixed mining rate, so then it becomes more expensive and miners will have to decide if they continue participating.


What were the previous Binance coin burns as stated in the white paper before 2018 April? What happened to the price prior to the Binance coin burn as stated in the white paper? How high did the coin go in terms of BTC prior to the burn and after?

Found this on their website. They plan to burn 100 million coins every quarter by burning 20% of their profits in BNB. Currently have have burned 2 million so far.

Q1: https://support.binance.com/hc/en-us/articles/115002205552-Binance-1st-Quarter-BNB-Burn-Event

Q2: https://support.binance.com/hc/en-us/articles/360000012892-Binance-Coin-Burn-in-2018-Winter


Do the DNS servers make Bitcoin more secure than the IRC channel? Possible Duplicate:
  How secure are the DNS servers for Bitcoin?

In earlier version of Bitcoin the IRC channel was used to seed initial peers, and as of version 0.6 it was largely replaced by the DNS servers. Does this approach make Bitcoin more secure, and if so, in what way?

The DNS system is vastly more scalable than an IRC channel. It has its downsides, in particular it is only unidirectional. However, given enough seeds it is much harder to knock out than a centralized IRC server.


Buying Bitcoins without identity checks? Are there any exchanges that offer Bitcoins without identity checks? I would like to remain anonymous while buying the currency.

LocalBitcoins provides

In-person cash trades - can be done complete anonymous. Check "Buy bitcoins with cash" on the site.
Cash deposits - depending on the bank and the country you may be do cash deposit anonymously


When does MtGox "volume" get reset? What time of day (in GMT) does the volume get reset to zero?

I'm trying to correlate this with the charts, however I'm unclear as to when this actually would occur

It is a moving sum, it sums up the volume for the last 24 hours of trade.
Bitcoin trading never closes, so the usual way of calculating volume as the sum of trades that happen between the open and close of the market doesn't apply.


What could drive Ripple adoption? Now, I have been reading a lot about Ripple lately and here is something that still eludes me: For example Bitcoin has a clear early adopter advantage, which incentivices investments and helps build up a critical mass of people until the network effect sets in. Additionally, the Bitcoin system is designed to reward collaboration towards stability (mining rewards).

Ripple seems to have some problems here:

It is hard to make out an early adopter advantage for users, except perhaps scoring a few Ripples to spend for free. After spending that money, there seems little advantage for users to stick around.
There seems to be mostly a first mover advantage for businesses (see 1, 2). However, for most businesses this should be a chicken-egg problem, without customers there is no interest to implement, without usage opportunities there is no interest for customers.
There is no strong incentive to do what is good for the network: While inactive users in the bitcoin network don't matter, should users in Ripple lose interest, their outstanding IOUs lose worth. So, not only do I have to trust that somebody is good for their money, but also that he will stay interested.

My question then is: How is Ripple supposed to attract enough interest to build a user base that propagates a network effect?

Related questions:

1 : Does Ripple give an advantage to early adopters?
2 : What benefit or incentive is there for someone to run their own ripple client or ripple server?

It is hard to make out an early adopter advantage for users, except perhaps scoring a few Ripples to spend for free. After spending that money, there seems little advantage for users to stick around.

That's probably true for people who have no real urgent use case. But what about users who need to make international payments such as remittances? But largely I agree with you, pursuing users directly is not a good adoption strategy this early.

  There seems to be mostly a first mover advantage for businesses (see 1, 2). However, for most businesses this should be a chicken-egg problem, without customers there is no interest to implement, without usage opportunities there is no interest for customers.

The good thing about chicken-egg problems is that if you get one, you get the other for free. So when adoption is blocked by a chicken-egg problem, you pick the side of the problem that's easier to solve and work on that. Then the problem turns into something that drives adoption.

So what's the wedge into that problem? Well, businesses can accept payments through Ripple whether or not their customers send payments through Ripple directly, and customers can make payments through Ripple whether or not the businesses accept Ripple payments directly. The obvious example is the Bitcoin outbound bridge which lets Ripple users make payments to merchants that accept Bitcoins whether or not those merchants adopt Ripple. Similar bridges can be constructed in the inbound direction and from conventional payment systems.

There are numerous adoption strategies that don't require getting users directly but where Ripple is used as a "back end" payment rail and remains invisible to users.

  There is no strong incentive to do what is good for the network: While inactive users in the bitcoin network don't matter, should users in Ripple lose interest, their outstanding IOUs lose worth. So, not only do I have to trust that somebody is good for their money, but also that he will stay interested.

Community/social credit is not expected to be a realistic use case for Ripple for some time. It's reasonable to expect that the initial adoption will be driven primarily by assets issued by gateways, possibly even by business-to-business transactions using Ripple as a back end to provide irreversible, high-speed, cross-currency settlements.


How to handle incomplete blocks when reading blk*.dat files? I'm trying to write a parser for blk*.dat files from scratch. Right now, I can read blocks, extract the header fields and calculate the correct block hash based on the header fields.

I just tried to run the parser through all blk-files and it failed after successfully reading the first ~300 blk-files. When inspecting the failing file with a hex-editor, I found two "magic byte fields", only separated by 4 other bytes.

Since the mandatory block-header is supposed to be 80 bytes in length, I'm now quite confused.

I found three probably related questions:

blk file error when reading - did something change in the format?
How can you tell if you're at the end of an incomplete blk*.dat file?
Zeros in blk00*.dat files

My guess, based on these other questions, is the following:

This is an 'incomplete block'
This happens when a block can only be partially downloaded, or written to disk.
Deleting the affected blk files and re-downloading parts of the blockchain doesn't make sense, since this can be expected to happen again.
The parser should be able to skip these blocks.
The overall blk file is not missing actual data and is not corrupt.
The 'incomplete block' will be downloaded and written again further down in the blk file (or to an other blk-file).

Which of my assumptions are correct? .. which are not? Am I missing something?

I'm going to answer my own question. These are my conclusions based on the comments from Nade Eldrege and eponymous.

Assumption 1: This is an 'incomplete block'

Yes, this is an incomplete block. More specifically, it is not part of the blk file format.

Assumption 2: This happens when a block can only be partially downloaded, or written to disk.

Yes, evidence strongly suggests that this happens when the bitcoind is interrupted / killed while writing to disk. If restarted, it just continues to download and write new blocks to the blk file. It doesn't clean up incomplete block.

Assumption 3: Deleting the affected blk files and re-downloading parts of the blockchain doesn't make sense, since this can be expected to happen again.

Yes and no. Yes, because deleting and re-downloading the blk files without interruptions solves the issue. When writing a blk-parser, however, it should be able to handle these incomplete blocks. For example, by skipping to the next valid block.

Assumption 4: The parser should be able to skip these blocks.

Yes. See #3

Assumption 5: The overall blk file is not missing actual data and is not corrupt.

I'm not sure, but since the bitcoind just continues with downloading blocks and works without any issues, one can assume that the incomplete block is just  re-downloaded afterwards.

Assumption 6: The 'incomplete block' will be downloaded and written again further down in the blk file (or to an other blk-file).

It seems so. See #5


What should I choose - GPU Mining or CPU Mining? I have a HP Pavilion G6-2313AX Laptop with
Processor  : APU Quad Core A10 and
Graphics  : 512 MB AMD Radeon HD 7660G (Integrated) and 2 GB ATI Mobility Radeon 7670M HD Graphics (Dedicated)

I know both specifications are not enough for dedicated mining. But I'm interested in it and just want to try mining.

Please help.

It is likely that neither is profitable for you, because ASIC miners are alot more effective than any GPU mining, which in turn is alot faster than CPU mining. But don't take my word for it. This hardware comparison wiki is a good source to make an initial estimate. There is one entry listing the combination of an A10 and a HD7660G GPU, claiming to get 105 MHash/s just from the graphics card (and not listing any value for the CPU).

If that doesn't deter you---at 100 MHash/s you are looking at an expected average reward of less than a dollar per month, probably less than the electricity your computer needs is worth---please consider updating that wiki with the performance you are getting.


What are 'pegged' side chains are and how they will be useful for Bitcoin? What seems to be a very important paper was released this past week (http://www.blockstream.com/sidechains.pdf). It centers around the idea of 'pegged' side chains, and being able to move coins from one blockchain to another.

Can someone summarize how these pegged side chains would work?

How will they be useful for bitcoin?

Portions of this are copied from my answer to Scott's question.

This particular proposal only requires one change to Bitcoin: SPV proving.

SPV proving is required when you want to move Bitcoins from the sidechain to the mainchain. The idea is that rather than putting all of the rules to validate transactions on the other chain into the original Bitcoin client, Bitcoin clients would look at how much hashpower was used to secure the transaction. It's pretty clever, actually.

Destroying Bitcoins to fund other blockchains has always been possible.

One issue that I see is that I don't think there would be enough hashpower to secure the network from double spending; merged mining could probably fix that though.

Another weakness of the paper that I see is that it does not address what to do if someone does steal coins from the sidechain. (In other words, the Bitcoin network thinks there are 90 Bitcoins in the sidechain, but the sidechain thinks it has 100 BTC.) One possible approach would be to devalue all coins moved back to the mainchain by the percentage that was stolen. Another would be to take a flat percentage off the top of coins moved into the sidechain.


How do I determine each transaction fee on the blockchain? I would like to be able to see each transaction fee charged when I look at the transactions in a block.  How do I do this?

The transaction fee is the difference between the value of the inputs being spent and the value of the outputs being created. Most block explorers will tell you the transaction fee for a transaction though, so you don't need to calculate it manually.


Calculating the target from the hash leading off bits I'm implementing my own cryptocurrency and I found it that saving the "hash difficulty” as the leading off (0) bits of a 256 bit number in a SHA-256 hash is the most intuitive.

I'm struggling to find a way to calculate the bitcoin equivalent “target” from that number.

Additionally I wonder why it is not implemented that way in the bitcoin protocol? Does it cause too harsh steps of difficulty?

I'm struggling to find a way to calculate the bitcoin equivalent “target” from that number.

Your difficulty recalculation algorithm will need to be completely different then. The easiest way to change it is to just start with an initial difficulty with all bits set and then bit shift this number as needed to get a target with some set number of leading zeros.

  Additionally I wonder why it is not implemented that way in the bitcoin protocol? Does it cause too harsh steps of difficulty?

Because it only allows for the difficulty to double or halve. Furthermore, there are only 256 possible difficulties so this is not at all ideal nor would it work particularly well. This means that the target would usually be too high or too low. By using a target value, the difficulty can be adjusted to far more levels (2^256 possible difficulties) to better match the network hashrate.


Getting Hash160 of bitcoin address How to get hash160 address in string using bitcoinj ,I tried the following code

NetworkParameters params = TestNet3Params.get();
String ads = "n1XZMMm3ikh97Mr8JVnnahfugad2DRcVrB";
Address address = new Address(params, ads);
byte[] adshas160 = address.getHash160();
System.out.println(adshas160);

all I'm getting is [B@4c762604

To get the hash in a human readable version, I advice you to use a class that'll do it for you:

System.out.println(javax.xml.bind.DatatypeConverter.printHexBinary(adshas160));


QR Scan "Unrecognized format" mycelium "Mastering Bitcoin' Noobie here.
In Ch. 2 of Antonopoulos' "Mastering Bitcoin", I try to scan figure 2-2 (per his instruction) using a recently installed Mycelium on my Android.

Why do I keep getting "Unrecognized format"? How do I properly scan this?

Mh i'm try with Bitcoin android wallet and work, this is the result

Can be your wallet have a bug?


BIP39 Japanese Mnemonic vector unit test process There is a json for unit tests of Japanese characters which I want to validate using Python, specifically with this fork of pybitcointools, which has bip39 functionality.

Unit tests from Trezor's python-mnemonic test vectors work fine (in Python 2.7 IME), however, this is straightforward since there's no normalization of unicode dialectics and such, since all mnemonics are lower case English.

The Japanese fields are:

Entropy (hex)
Mnemonic (Japanese)
Password (Japanese, appears to be the same for all tests)
Seed (hex, 64 bytes)
xprv

So entropy seeds mnemonic (bip39?), then mnemonic | password hashes to Seed; Seed then acts as the master key for the bip32 xprv? (correct me if I'm wrong!?)

So, assuming it's that straightforward...

how is the Japanese unicode text "normalized"? (Is it just NKFD Unicode normalization, which Electrum 2.0 does?)
what does "normal" mean for Japanese?

So entropy seeds mnemonic (bip39?), then mnemonic | password hashes to Seed; Seed then acts as the master key for the bip32 xprv? (correct me if I'm wrong!?)

That sounds about right. Most of the process is well detailed in BIP-39.

An SHA-256 is taken of the entropy, and the first entropy_len_in_bits / 32 bits of this hash are appended to the end of the entropy. The resulting entropy bit string is divisible into 11-bit-long chunks (it's no longer an integral number of bytes).
Each 11-bit chunk is converted into one of 211 mnemonic words.
The words are joined by spaces. For display purposes in Japanese, these should be Unicode IDEOGRAPHIC SPACEs, '\u3000'. If there's no need to display the mnemonic to the user, they can be "normal" SPACEs ('\u0020').
The mnemonic sentence is Unicode normalized in NFKD form. This converts any IDEOGRAPHIC SPACEs into SPACEs. It also changes some characters in some of the mnemonic words, therefore this step cannot be skipped. (The question What is NFKD normalization? is a whole separate topic that's probably best asked elsewhere IMO....)
The mnemonic sentence is converted into bytes via UTF-8 encoding.
The binary seed is computed as PBKDF2HMACSHA512(key= "mnemonic" | passphrase, data=utf8_mnemonic, iterations=2048, out_bytes_length=64). The passphrase can be the empty string. It must first go through the same steps 4 and 5 as the mnemonic.
(this part isn't detailed anywhere AFAIK) The master extended private key is constructed by using the first 32 bytes of the binary seed as the private key, and the last 32 bytes as the chaincode.

  Is it just NKFD Unicode normalization, which Electrum 2.0 does?

Electrum 2.x does use NFKD normalization, but it also performs additional steps, such as removing spaces between Japanese words after step 4. It also uses a different key string in step 6, and a completely different process prior to step 4. See this answer for an implementation of Electrum 2.x's mnemonic-words-to-seed procedure in Python.


Could many large forks cause a DoS attack on the miner? Suppose it was possible to influence a miner to create many forks.  My understanding is that a miner won't retransmit the fork, but will track it internally.

Where is this information saved in a miner (disk, RAM, etc)?
What protections exist to protect a miner from a resource depletion attack due to forking?

If you mean a miner as in a computer that only does mining, it should be generally as resistant to DOS attacks as any casual computer on the network - it doesn't open its ports.

If you are worried about a standard client being flooded with many blocks and having to store it - the developers did think of that and they put in the checkpoint system. Basically, making a lot of forks of the new blocks would require a lot of computational power and so forth, so it is highly unlikely. However, changing some of the earliest blocks in existence would be dirt cheap nowadays. However, the standard client will not accept any block chain forks that branch out from blocks older than the most recent checkpoint.


"At first, anyone could spend anyone's coins"? I've been watching this Bitcoin video: https://youtu.be/ZIugzFygviw?t=294
At the linked-to timestamp, he claims that:

Due to bugs, at first, anyone could spend anyone's coins!

I'm not saying that I think he's lying, but was Bitcoin really that buggy initially? That's honestly a bit shocking to hear for me. I did think that Bitcoin was quite solid from the very first v1.0, and has only been "expanded upon" with BIPs ever since. I did not know that such serious bugs existed early on.
Exactly how early are we talking? I had coins in 2009 or 2010. So, back then, anyone could just spend those even though only I had the private keys? And this extremely serious bug was somehow fixed without breaking Bitcoin?

He might be talking about the "1 Return" bug

1 RETURN Bug (July 2010)
In July 2010, Satoshi and fellow developer Gavin Andresen received a tip-off about this bug that would have made it possible to spend anyone else’s Bitcoins. In the early releases of the Bitcoin Core, OP_RETURN was defined as:
case OP_RETURN:

{

    pc = pend;

}

break;

An unlocking script of OP_1 OP_RETURN would then always result in a 1 on the top of the stack, as OP_RETURN would end the script evaluation without modifying whatever was already on the stack. This was fixed by changing the opcode to return false and end the script.

(my emphasis).

Related

What is the "1 RETURN" bug?


Can any Bitcoin client do local peer discovery and blockchain synchronization? Usually, when a full Bitcoin client such as bitcoind, Bitcoin-QT, or Multibit start on a fresh installation, they connect "to the network" to download the blockchain. If someone has multiple computers or devices, they could end up downloading the whole blockchain several times. This puts a lot of stress on their connection and extra clients on the network that could get their data locally.

Have any clients implemented a standardized way to exchange blockchain data locally, without going over the Internet?

I imagine this would work something like how BitTorrent local peer discovery works, where two clients on the same subnet discover each other through multicast groups and then negotiate transfer of data.

The Bitcoin.org client can be launched with the -connect= parameter.

Simply have it connect to another local node and no outside connectivity occurs.

But once it is caught up to the latest block, the amount of bandwidth is relatively trivial.  There's no reason to do this to save bandwidth once a node has been brought current.


What would a country adopting Bitcoins as official currency have to reinvent? Let's say that a country decided to ditch their currency and go for Bitcoins. What would this country have to reinvent. The reason why I ask, is because I believe that if a tiny country was to adopt Bitcoins as their official currency, then this would remove all legal issues related to this currency, and hence would enable it to get adopted more widely.

Some of the issues that could require reinventing something could be in relation to:

Transparency requirements for the government to efficiently tackle

Black economy
VAT and general taxation fraud
Financing of terrorism

Ability to peg the currency to other currencies if this is judged as a good idea
Have an efficient banking system
Ability to fight deflation

Any other issues, which I have not thought about. Please note that you do not have to answer all these issues in any one answer, just one of them.

TL;DR:

  In the first instance, my belief is that a government would have to
  create their own brand of Bitcoin (i.e. a new version of the
  blockchain) and use that to trade against other currencies. This is a
  useful move because the government retains control over their currency
  (they set the mining rules) and they don't suffer a wealth drain in
  the process.

In more detail, once a country (our mythical Seashell Island from the earlier draft) has decided that it wants to adopt Bitcoin as it's local currency the following timeline is likely to come into play:

Research into Bitcoin

At this time the government will need to look into what benefits and drawbacks Bitcoin is likely to bring to their economy. Assuming that they currently have a weak currency, then adopting Bitcoin early could be seen as a smart move since it gives them lower cost of entry into the Bitcoin marketplace.

Among the obvious advantages that Bitcoin brings with it are:

resistance to counterfeiting
resistance to inflation
easier to track than cash for traditional transactions types (i.e. not including private sales of high value private keys)

Some of the drawbacks are:

economy becomes vulnerable to loss of electricity/networking (true of all electronic transactions at present)
banks have a reduced regulatory role since transactions become largely anonymous
increased potential for anonymous transactions to take place in large amounts

This last drawback is perhaps the most serious since it allows for a vast amount of money to be moved in and out of the country without the knowledge of the government. Admittedly, this happens in the present system although due to the large physical size of cash it usually requires laundering of some kind (conversion to something precious).

However, government resources are significant and it is very hard to remain anonymous for long. Over time detailed statistics analysing transactions could be used by the police to pinpoint individuals reusing Bitcoin addresses. This process is made much easier by the existence of tools like blockexplorer.com and should be seen as an improvement over the existing traceability processes.

Setting up the necessary processes/contracts to obtain some form of Bitcoin

By this stage the government researchers will likely have determined that there are only a few feasible options to get hold of bitcoins (note the lowercase here):

set up their own mining pool (initially paying for it in their own currency) - unlikely
create a suitable contract with a mining pool to buy a large quantity of bitcoins (without including their own soon to be worthless currency - unlikely
encourage their citizens to go forth and buy bitcoins themselves and slowly drain the local currency into foreign hands then pull the plug on it (not exactly above board) - unlikely

Using any of the above approaches at this stage requires a significant transfer of wealth from the country into bitcoins and is probably the hardest part to get right. The problem is that there is no central authority who can control the supply of bitcoins exposing the country to the influence of the market. In the case of Euros, the exchange rate of the participating currencies was fixed well in advance after significant negotiation. When the time came to switch over nobody lost out because all the old currency was replaced with the new, which could be printed at will by the central bank.

It could be argued (by @David Perry for one) that some kind of intermediate value-store could be used, such as gold or silver. However, this still requires all of the country's wealth to be slowly converted to this value-store which will raise eyebrows among those folks selling it in exchange for a soon to be worthless currency. I'd welcome further discussion on this.

There is a significant danger that the country could be declared bankrupt in it's own currency before it is able to complete the operation.

EDIT to cover the most likely path by a government:

if a government made their own blockchain (e.g. SeashellCoin) then they could in theory use scripts to manage trades with Bitcoin.

This would permit a staged transition and essentially solves the value-store problem. The value of a Seashell would be fixed against their SeashellCoin equivalent (probably as 1:1). In my opinion, this is probably the most likely mechanism that a government could take. The government could decide upon their own inflation model, select a Version entry and then throw a supercomputer on the job for 5 minutes to generate a few million coins. Once that's done then they can take advantage of the blockchain approach and off they go.

Setting up the necessary legislation to make them legal tender locally

Once an adequate number of Bitcoins are, somehow, in the government coffers they can then make the announcement that all local debts can be paid in bitcoins and will be accepted by a court of law. This ratifies Bitcoins around the world (assuming the country is a recognised state) leading to a huge increase in the value of Bitcoins. It also opens the door to taxation in bitcoins which would largely operate in the same way as it did before.

Value Added Tax (VAT) (aka sales tax) would continue to be added to Bitcoin transactions by merchants who would then transfer the money to the government at regular intervals, overseen by accountants
Income tax would also stay the same
Accounts would have to be returned along with their transaction IDs to allow verification of truth
Standard statistical methods to detect fraud would remain (relies on most folks behaving themselves)

Managing the transition among the general population

Since it is the government driving this then they are likely to provide all necessary equipment to facilitate the transfer. This would include:

recommendations for mobile phone applications (probably not likely to make their own due to "backdoor" privacy concerns)
provision of Bitcoin Wallet Devices that offer tamperproof private keys and are essentially like smartphones for those that don't have mobile phones (see the original Fred)
provision of EPOS systems that are Bitcoin enabled

All of the above would probably occur via contracts with private companies.

Handled well, the transition to Bitcoin would be like introducing a new contactless payment system. They would still want to maintain a secure location for their bitcoins (most likely a government backed bank) and after a while it would just fade into the background.

Reaping the benefits to the economy afterwards

Much of the long term benefits would stem from

the decreased transaction friction within the existing legal and banking system
better fiscal policy since supply is limited leading to improved standards of living and quality of life
increased long term wealth as an early adopter to a global currency
greater transparency in accounting that can be easily verified
immunity to global currency crises

Just my 2 BTCs.


Why is syncing the last 5000 blocks so much more CPU-intensive? I deleted my block chain and I'm currently syncing again. Just as I did last time, I noticed that from a certain point, my CPU usage raises to almost 100% and stays so for much longer than the usual peaks before this.

I think it's around the last 5000 blocks.

It also sometimes just stops, I don't know if that is for saving resources or something else, but sometimes it just stops (both CPU and network traffic go to nearly nothing) and almost no new blocks are added.

Is there a reason for this different behavior while syncing the last 5000 blocks?

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


How does timejacking enable double spending? http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html

I went over this blog, but I am still not clear how double spending is achieved by this attack. From what I read, the attackers submit wrong timestamps to a target node. During this period, the target wouldn't receive legitimate transactions confirmation because the target node is behind network's median time. However, I am not clear how double spending can be achieved from this.

The blog you linked to talks about a fairly sophisticated attack, involving large scale network manipulation.

The basic premise is:

You are able to identify the node that belongs to the person/entity you want to execute a double spend against
You trick that node into thinking that the network time is far behind what it actually is (up to a difference of 70 minutes against the node's own system time)
Optionally, you convince other miners that the network is 70 minutes ahead of the actual time.

This gives us the basic following setup:

The actual time, T (the actual value of this is irrelevant)

The majority miners' network time, T+70.

The victim's network time, T-70.

In Bitcoin, when a node receives a new block, it runs through some validation checks. If any of these checks fails, the block is deemed invalid. One of these checks is to verify the timestamp in the block header.

The node checks to verify that this timestamp is within 70 minutes of the what the node believes the network time to be (the network time is the median of the time the peers a node is connected to have reported).

To execute the attack, the bad actor has created a situation where the victim is 70 minutes behind the actual time, and the rest of the world is mining as if the actual time is 70 minutes ahead of the network time.

Thus, when a valid block is found, when the victim's node receives it, it will be dismissed as invalid, since from the victim's point of view it is around 140 minutes ahead of the network time (T+70 - T-70).

The bad actor then uses his own mining power (it is assumed that the attacker has a sufficient share of mining power to produce a few blocks a week) to mine a block that is within the victim's acceptable time parameters. Note that the rest of the network will either already be on a longer chain, or will find a longer chain soon enough, since the attack does not control the majority hashpower.

By broadcasting this block to the victim, the attacker can convince them that some transaction in that block is confirmed. If required, the attacker can then mine a few more blocks (which may take several days) to trick the victim into believing that the block containing the transaction has been confirmed multiple times.

At the same time, the attacker will make another transaction spending the same inputs on the much longer chain being mined by the rest of the miners. This will also be confirmed, and receive far more confirmations than the chain being created by the attacker specifically for the victim's node.

Finally, once the attacker has convinced the victim of the transaction and reaped whatever benefits, the attacker will let the victim's node connect to more honest peers. This will result in the node recalculating the network time, arriving at a more realistic value.

Once this happens, the victim's node will be able to accept the original, longer, honest chain, which will have more blocks (and more work) since it was being mined by the majority hashpower. This chain contains the double spend of the transaction the victim was tricked into believing was confirmed.

The minor chain on which the victim was convinced of the transaction will then disappear, being replaced by the longer chain, and leaving only the double spend on the blockchain.


is Gap Limit only for consecutive address? Suppose we generated 35 address, 1 to 5 are paid, 6 to 34 not paid/used and 35 paid.
Because of 20 gap limit we won't see 35 in our wallet, but what happen if we send some money to address 19 for example, will that fix the gap limit problem because even when are still having 28 not used address they are not in a row?

The gap limit is the number of consecutive unused addresses after the highest used address. So if address 19 receives some Bitcoin, then, with a gap limit of 20, the next 20 addresses will become the lookahead. Since 35 will then be seen, the next 20 after address 35 become the lookahead.


Are there enough Ripples for everyone? There is a finite amount of Ripple tokens (XRPs). If I recall correctly the amount is 100 billion XRPs.

Opening an account requires 200 XRPs.

So, are there only enough for 1/2 billion accounts, ever? Can the numbers be tweaked later on? Could XRPs be divided below 1 XRP?

Was this problem discussed anywhere? (E.g. on the Ripple forums)

XRP can be divided into millionths. The reserve levels can be changed by consensus. By the time this becomes an actual issue, the system will be managed by consensus and there's no way to predict what stakeholders will decide to do. The rough expectation is that they'll try to keep the cost of opening an account consistent with the actual cost imposed on the network by having an additional account.

Also, just to point it out again, those 200 XRP aren't lost. You can use them to fund transactions. You just can't transfer or exchange them. The reserve is designed to discourage ledger spamming.


What does it mean when addresses are labelled "beyond the gap limit (highlighted red)"? There is a lot of red highlighting in the 'Label' column of my online/watch-only Electrum client, including for addresses which contain considerable balances.

After trying to find out what this meant, I found out that it is something to do with the gap limit, and I read in the thread Electrum 1.9 released on BCT:

  "red means that the address is beyond the gap limit, so it will not be recovered if you restore from seed
  the red color will disappear once other (preceding) addresses receive coins."

This makes me think, that if my hardware is damaged and I need to restore the wallet from seed, that I will lose the BTC which I have stored in those red-labelled addresses. I don't know why this would be, as I didn't think it worked that way, but I don't know enough about it to know, and this is coming from the lead developer.

First, what exactly does it mean, that I have this red highlighting?
Second, should I be concerned about it, do I need to do anything about it?
Third, if I should do something about it, what should I do?

Thanks.

Additional information: In the past, there was a time when I was signing a transaction with my offline wallet, and I did not have all the addresses generated which were involved with the transaction from the online wallet. Because of this, I used some command in the Electrum command-line interface of the offline wallet to generate new addresses, I think by increasing the gap limit possibly. In fact, I used the thread Offline send - can't send from change address for guidance on how to do whatever it was I did:
I used a mixture of those three commands, but in the end I think I did it mainly by using the command, wallet.storage.put( 'gap_limit', 20 ). I may have done this repeatedly, or with a large number, to make sure I definitely generated the addresses I was looking for; I don't know if this was excessive and may have caused problems.

Edit: I should probably add, that all of these red-highlighted addresses are change addresses.

If you have your wallet seed it is fine:
From what I understand, your coins are safe, they will not be lost as long as you have wallet seed. When reimporting, Electrum would just not look far enough to find everything, until you nudge it a bit.

Explanation:
The gap limit gives the number of addresses that Electrum will generate from the seed starting from the last address that it found a balance on.

The error message tells you that Electrum wouldn't find some of your addresses by itself, because Electrum would think that it arrived at the end of your transaction history, before all your transaction history is discovered.

Example to make it graphic:

Gap limit = 3
S is Seed
I address with balance
• address without balance.
X address with balance beyond gap-limit

An arbitrary transaction history:
You have a balance on a few addresses, already spent/didn't use some addresses intermittently, and then you skipped a bunch (five here) for some reason before receiving balances on some more.

SIIII•III••I•III•I•IIII•••••XXX
                       ^gap^

The gap of five is bigger than the currently set gap limit of three, so now, reimporting the seed, Electrum would only regenerate to:

SIIII•III••I•III•I•IIII•••
    last used address ^ +3

Because it will only regenerate gap-limit unused addresses after an address with a balance.

If you set the gap limit higher (in the example to six), or use the previously unused addresses that make up the gap, Electrum will rediscover the addresses.

The imported wallet so far:

SIIII•III••I•III•I•IIII•••

Receive 4 new transactions N:

SIIII•III••I•III•I•IIIINNNN••XXX
                             ^ oh, that "new address" was used!

Recovery of all addresses with balances plus gap-limit new addresses:

SIIII•III••I•III•I•IIIIIIII••III•••

Altogether, it shouldn't be much of a problem. Electrum should probably be able to safely store thousands of addresses, so unless you created a humongous gap, probably no need to think about any problems there.

So, what you might want to do, is figure out just how many addresses you have now generated from your wallet seed. If you then want to recover your wallet on another computer, just generate the same amount of addresses or temporarily increase the gap limit until you have the same number of addresses.


Is the unencrypted copy of the wallet still usable after a copy is encrypted? My wallet is not protected with a password, I have a few receiving addresses generated and a some funds in it, then I make a copy of the wallet and I set a password on this one.

Will the old unencrypted copy of the wallet still be able to spend current and future incoming funds without requiring a password ?

Or does something change in the private keys and addresses that gets updated with the network and old wallet becomes useless ?

The old wallet is unaffected, assuming it uses separate data files (e.g. when new wallet is on a different computer or is a different software product).

The password is typically used to protect the program's critical data by encrypting it. It does not change the private-keys.

In the case of Bitcoin core, the data files would be wallet.dat (where private keys and other settings are stored) not the directories holding the blockchain data.

See https://en.bitcoin.it/wiki/Wallet_encryption

  This page describes the algorithm used for encrypting the wallet.dat file used in the original Bitcoin client.

...

  Wallet encryption uses AES-256-CBC to encrypt only the private keys that are held in a wallet.

...

  At runtime, the client loads the wallet as it normally would, however the keystore stores the keys in encrypted form. When the passphrase is required (to top up keypool or send coins) it will either be queried by a GUI prompt, or must first be entered with the walletpassphrase RPC command. This will change the wallet to "unlocked" state ...

Obviously, if you had two different wallet programs using the exact same single wallet.dat file, encryption by the new software would affect use of the old software


Do we know enough about Casascius to trust their physical coins in the long run? Casascuius offers an attractive product, a physical coin storing a private key. From a CNET article and the website itself, we learn the company is run by

  Mike Caldwell, 2901 Little Cottonwood Road, Sandy, Utah 84092,

who appears to be a trusted member of the Bitcoin community.
They provide a digitally signed list of Bitcoin addresses and claim that this makes Mike  legally accountable. (I'm not sure how the GPG key used can be connected to a real person.)

The only form of payment, they accept directly is Bitcoin.

Such a service allows for two types of fraud:

At some point in time, they stop sending physical coins in exchange for BTC received and disappear. This is a very common risk when making payments in advance and it is particularly obvious if the form of payment is designed not to allow chargebacks.
The risk here is not different from shopping at many other businesses online. However, the relatively simple website and the connection with Bitcoin, is likely to raise alarms with customers.
Although they claim otherwise, they could easily keep a copy of the private keys. This would allow spending the balance on all coins that have not been spent yet at some point in the future.

What should the Bitcoin community expect Casascius to do to render the scheme trustworthy?

wrt the suggestion that I put up a website with the name and address of the founder, this information has consistently been displayed on the home page since I put up the site. Agreed, there exists a theoretical possibility that I could scam and there is little anybody can do about that, even if my processes were to be audited, it's still impossible to know I didn't keep a copy somewhere at some moment someone wasn't looking.  On the other hand, I am known to care about the success of Bitcoin, and own a fairly successful payroll software business independent of Bitcoins, and (especially with my signed list of addresses) have the means to be held accountable and be ordered to pay restitution in the event of fraud. If this is unsatisfactory, then of course you should not buy the coins. I indeed hope I spur successful competition (my life career is not in making coins), this has been a neat project thus far.


What will happen if transactions are being generated by multiple person with same one private key? Let's assume people got the same private key of 1 BTC amount(Unspent state) for somehow lucky. Let's call that wallet address is WALLET_A.

So people trying to send all the balance to their each own wallet address, like:

tx1:WALLET_A(input) -> Person_A_WALLET(output)
tx2:WALLET_A(input) -> Person_B_WALLET(output)
tx3:WALLET_A(input) -> Person_C_WALLET(output)
...

But we all knows only one transaction can be mined which is unspent state of WALLET_A for all 1 BTC balance.

How's gonna the mempool handle when people generates transactions simultaneously?
Will miners mine the first registered transaction in mempool? If any person pay a much higher fee, can it be mined instead of the old one?
What happens if people compete by repeating infinitely resending their transaction through the -zapwallettxes option in Bitcoin Core?

There is no "the mempool". Each node has its own mempool. So in your example, each node would receive each of the transactions, possibly in a different order, and at different times. It is physically impossible for all three transactions to reach every single node at the exact same time.

If we assume that none of the transactions signal for RBF and all of them pay the same fee and it is sufficient (i.e. above the minimum relay fee), then every node will accept into its mempool the first transaction it sees. Due to network latency and physics, each node will probably accept a different transaction because they will arrive at slightly different times. So some nodes will accept tx1, some tx2, and some tx3.

Miners will then choose the transaction that they have in their mempool. If their node's mempool accepted tx1, then tx1 will be in their block. If tx2, then tx2, and if tx3, then tx3. It is purely whichever one arrived at their node first.

Now let's suppose the only thing different is the fees. Still no RBF, but everyone has paid a different and still sufficient fee. Then the same thing pretty much happens. The vast majority of full nodes use Bitcoin Core which does not implement full RBF. So a conflicting transaction that pays a higher fee will not be accepted. This is for anti-DoS and anti-spam reasons. In order for a transaction to be accepted as a replacement, the original must signal that it is replaceable.

If one of the transactions signals for RBF and one of the other two transactions pays a higher fee, then we have a more interesting scenario. For the sake of example, lets say that tx1 signals for RBF, and both tx2 and tx3 pay higher fees than tx1. Then nodes that accept tx1 will replace it with the first one that they see of tx2 or tx3.

So in this case, in the end, most nodes will end up with either tx2 or tx3. And the miners select from either tx2 or tx3, depending on what their node sees, which depends on which arrived first.

If tx1 again signals RBF but this time only tx2 has a higher fee (tx3 has a lower one, but still sufficient), then nodes that receive tx1 that then receive tx2 will accept tx2. Nodes that first received tx3 will reject tx1 and tx2 as double spends. The rest plays out as before with tx2 and tx3.

If tx1 and tx2 signal RBF, and tx3 has a higher fee than both, then ultimately most nodes will end up with tx3. Nodes that received either tx1 or tx2, and then received tx3, will replace with tx3. If tx2 has a higher fee than tx1, then nodes that received tx1 then tx2 will first replace with tx2. Once they see tx3, they will replace with tx3. Ultimately, most nodes will have tx3 so tx3 is most likely to be mined by miners.

If tx1 and tx2 signal RBF, but this time tx3 has a lower fee, then we could have a repeat of the first scenario, or a race between two of the transactions. If tx1 and tx2 have the same fee, then it will be a race between all 3 transactions as no transaction outbids the other so none of them can be replaced. If tx1 has a higher fee, then nodes that received tx2 will likely replace with tx1. And vice versa. In this case, it becomes a race between tx1 or tx2 and tx3. Nodes that received tx3 first will not replace it because it does not signal RBF.

Lastly, if all 3 transaction signal RBF, the transaction that is most likely to be mined becomes the one with the highest fee. Again, if all 3 have the same fee, then all 3 are eligible as in the first scenario. But if one pays a higher fee and can replace the others, then that transaction will become the one that is in most node's mempools will be the one that pays the higher fee.

If any transaction does not pay enough fee, then it doesn't get relayed and it becomes a race of the other transactions. If two transactions don't pay enough fee, then the one that does becomes the one that is mined.

So the transaction that gets mined depends on whether any signal RBF, which signal RBF, the transaction fees, and which transaction miners have.

  What happens if people compete by repeating infinitely resending their transaction through the -zapwallettxes option in Bitcoin Core?

-zapwallettxes doesn't make a difference if the transactions pay enough fee. If the transactions don't signal RBF, it doesn't matter. -zapwallettxes only affects your local Bitcoin Core wallet (not even the node, it does not remove the transactions from your node's mempool). So doing this has no effect.


Why does the default miner implementation use pay-to-pubkey? Looking at the v0.9.3 source in miner.cpp:

CBlockTemplate* CreateNewBlockWithKey(CReserveKey& reservekey)
{
    CPubKey pubkey;
    if (!reservekey.GetReservedKey(pubkey))
        return NULL;

    CScript scriptPubKey = CScript() << pubkey << OP_CHECKSIG;
    return CreateNewBlock(scriptPubKey);
}

The default scriptPubKey is a pay-to-pubkey? Does it need to be preserved for compatibility? I'm just surprised that it's not using pay-to-pubkey-hash.

Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive IP-to-IP payment protocol; P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK.

Is this space savings why Nakamoto chose to use P2PK for mining and interactive payments even when he had P2PKH available, or did he have some other reason for using different transaction types?  I think only he knows.

In a situation where you don't need the shorter P2PKH addresses, such as mining, interactive payments, or paying to your own pubkey for change, using a P2PK may be the better option, although there is a security advantage to P2PKH if you don't reuse addresses and if ECDSA someday gets broken in a certain way that makes attacks possible but slow to execute.

Type   Output                Input             Total Bytes
       ScriptPubKey          ScriptSig

       push ....... 1        push  ... 1
       <key> ...... 33       <sig> ... ~72
P2PK   checksig ... 1
       --------------        -------------
       Total ...... 35       Total ... ~73     ~108

       dup ........ 1        push .... 1
       hash160 .... 1        <sig> ... ~72
       push ....... 1        push .... 1
P2PKH  <hash> ..... 20       <key> ... 33
       equal ...... 1
       checksig ... 1
       --------------        --------------
       Total ...... 25       Total ... ~107   ~132

The numbers above assume that you're using a compressed public key, which are widely used today but were not implemented until Bitcoin Core 0.6.0.  If you want to consider the older "uncompressed" public keys, add 32 bytes to the <key> byte sizes.  Also, we ignore all constant factors in creating an output or input and just consider the number of bytes in the script.

I'm not aware of any compatibility issues---plenty of miners and mining pools use their own software to pay to P2PKH addresses, as you can see from the coinbases in recent blocks.


How to resolve Minera cgminer "no devices found" error after installing additional GekkoScience USB-Antsticks? I successfully completed my first attempt to configure my Raspberry Pi for Bitcoin mining with a GekkoScience USB Antstick and Minera; however, after installing additional Antsticks, my env somehow became corrupted which ultimately lead me to wipe my Raspberry Pi and install a fresh copy of Raspian and reinstalling Minera- my question is this: should I have re-compiled Minera after installing additional Antsticks, as detailed within screenshot below captured from the Minera manual-install page?

I've detailed my Minera install-process within the following Gist if that helps clarify- basically, I'd like to avoid any future complications after installing additional Antsticks or miners because more are on the way!  Thank you.

Ok, any hardware additions to an existing Raspberry Pi * Minera environment or any adjustments to the hardware parameters specified in Minera Settings > Manual-options do indeed require recompiling cgminer.  In order to resolve, proceed with the following:

cd /var/www/minera
sudo nano build_miner.sh
Scroll down to the cgminer config and append -enable-blockerupter so the entire line displays CGMINER_CONFIG="--enable-avalon2 --enable-bflsc --enable-bitforce --enable-bitfury --enable-drillbit --enable-hashfast --enable-icarus --enable-klondike --enable-modminer --enable-blockerupter"
Exit and Write.
Run sudo ./build_miner.sh all
Upon compiling, exit from your host-session, unplug the antsticks, power-cycle the Raspberry Pi and then plug-in antsticks.
Log-in to the Raspberry Pi and sign-in to Minera- you should see verifiable success displayed in the Minera Dashboard > Device Tree.


Bitcoin client IRC - a potential network weak link? I'm currently learning more and more about the Bitcoin protocol and I`m wondering if using an IRC channel as the source to find your Bitcoin peers is a potential weak link of the Bitcoin network?

From what I understand the channel is hosted on irc.lfnet.org , so if that website was brought down normal clients would be unable to find peers?

They'd have no problem finding peers for several reasons:

Once the client finds a single peer, it can get a list of peers from that peer.
The client has a built-in list of about 500 peer IP addresses known to be stable.
The client knows several DNS names (such as bitseed.xf2.org and dnsseed.bluematt.me) that resolve to lists of Bitcoin peers.
The client stores peer addresses in a local database.

In fact, IRC has been removed from the Bitcoin client since 2013.


Electrum Wallet, Coinsquare source I am new to this bitcoin wallet use. I have funds allocated to Coinsquare but have yet to buy a single bitcoin or fraction of one. My question is,....... do I need a certain wallet for use in conjunction with a certain funding source? Will my Electrum wallet receive crypto currency from my Coinsquare account?

Its late answer but anyhow.

Definitely you don't need to have wallet linked to and funding source.
Actually opposite : your wallet must be independent from any financial entities and trusting only blockchain.

Yes your Electrum wallet will receive crypto currency. But why ask? Just send small amount for test!

My favorite wallet for bitcoin is Eclair Mobile just in case u need one.


What are the requirements of a transaction being included in a block? What are the requirements of a transaction being included in a block? How does a miner verify that a transaction meets such requirements?

From the Bitcoin wiki (as-of March 19, 2013):

  Transactions are cryptographically signed records that reassign
  ownership of Bitcoins to new addresses. Transactions have inputs -
  records which reference the funds from other previous transactions -
  and outputs - records which determine the new owner of the transferred
  Bitcoins, and which will be referenced as inputs in future
  transactions as those funds are respent.

  Each input must have a
  cryptographic digital signature that unlocks the funds from the prior
  transaction. Only the person possessing the appropriate private key is
  able to create a satisfactory signature; this in effect ensures that
  funds can only be spent by their owners.

  Each output determines which
  Bitcoin address (or other criteria, see Scripting) is the recipient of
  the funds.

  In a transaction, the sum of all inputs must be equal to or
  greater than the sum of all outputs. If the inputs exceed the outputs,
  the difference is considered a transaction fee, and is redeemable by
  whoever first includes the transaction into the block chain.

  A special
  kind of transaction, called a coinbase transaction, has no inputs. It
  is created by miners, and there is one coinbase transaction per block.
  Because each block comes with a reward of newly created Bitcoins (e.g.
  50 BTC for the first 210,000 blocks), the first transaction of a block
  is, with few exceptions, the transaction that grants those coins to
  their recipient (the miner). In addition to the newly created
  Bitcoins, the coinbase transaction is also used for assigning the
  recipient of any transaction fees that were paid within the other
  transactions being included in the same block. The coinbase
  transaction can assign the entire reward to a single Bitcoin address,
  or split it in portions among multiple addresses, just like any other
  transaction. Coinbase transactions always contain outputs totaling the
  sum of the block reward plus all transaction fees collected from the
  other transactions in the same block.

http://en.bitcoin.it/wiki/Protocol_specification#Transaction_Verification


Why change the nonce instead of just rehashing? Why do miners increase the nonce to compute a block hash rather than just generating a random block hash?  It seems to me that both approaches would have the same likeliness of finding a result that is below the target.

If the answer is that it is quicker to increase the nonce instead of just generating a random hash to find a valid result, could you show this in a mathematical/statistical way?

The hashing function used in Bitcoin is deterministic, that is hashing the same input, i.e., block header, will always result in the same output. This is necessary so that others can also check that a Proof-of-Work is valid.

This means that in order to compute a new hash the input to the hash function needs to be altered. The easiest way to alter the input is changing the nonce since this is a free-form field that may take any value. Other ways to modify the input is for example swapping transactions or modifying the coinbase transaction, which would require that the merkle root be recomputed in the header. The timestamp is also a popular choice, however its values are limited by a range of acceptable times.

In case you are wondering why we don't simply rehash the output of the previous hashing function to get the next value: this would destroy the proof-of-work mechanism, which requires an easy to verify proof that the issuer has performed some work. The key here is easy: if we iteratively hash the results of the previous solution then the verifying party would also have to perform this work to check that the issuer has performed the work. when varying the input this does not happen since given the input the verifier can perform a single hash operation and check the result.


How to identify the sender from crypto payments I want my users to deposit crypto into the website for credits, but the biggest issue is getting the input address (the user's address). How can I identify the sender from the transaction (since there can be multiple inputs) as well as the amount they sent (since there can be multiple outputs)?
A lot of services offer payment forwarding but they all seem the same but have different fees, some requiring a subscription of over 80$ a month (cryptoapis, blockcypher) or some having service fees (apirone, bitapis, etc). However they all seem to be the same so I don't understand the price differences, in fact some of them are downright identical (cryptoapis & blockcypher). How would I make my own, and would it be worth it for a start up?

As RedGrittyBrick suggested in a comment: Give each user a different deposit address.
Think of your process as the users purchasing credits in exchange for a Bitcoin payment. You respond to each purchase request with an offer. The offer includes an invoice address. Each new offer should have a new address, so you can identify which user took what offer. Since the address is unique, you'll know which user to credit how much when you receive the corresponding payment to an address.


Exchange rate of limit orders with a positive interval Consider some exchange, e.g. Mt. Gox, with just two users, Alice and Bob. If Alice places a sale order limited above 90$, and Bob places a buy order limited below 110$, at what rate will the exchange take place?

It depends on who posts the order first.

If Alice posts first a sell at 90, then Bob posts a buy at 110, Bob will buy from Alice at 90, and any excess will be posted as a buy at 110 (if he wanted to buy more than Alice sold).

If Bob posted first a buy at 110, then Alice posted a sell at 90, the opposite would happen: Alice would sell to Bob at 110, and any excess would be posted as a sell at 90 (if she wanted to sell more than Bob wanted to buy).


How to set a payment in Ripple without specifying currency issuers? I want to send IOUs from one of my accounts to another through the use of the API. Both of the accounts trust the same IOU issuer, which is a separate address. According to the Transaction Format, I would set the Amount issuer to the receiving account, and the SendMax issuer to the sending account. However, trying this, I get a "path dry" error:

{
  "id": 6,
  "status": "success",
  "type": "response",
  "result": {
    "engine_result": "tecPATH_DRY",
    "engine_result_code": 128,
    "engine_result_message": "Path could not send partial amount.",
    "tx_blob": "1200002280000000240000000E5011000000323031342D30392D32335430313A34373A34303A39383834383635303061D4445EADB112E0000000000000000000000000005442430000000000D3BC678DA1AEC545F393F5B0AFD2B8654CE43DB368400000000000000A69D44469DD823458000000000000000000000000005442430000000000D6C315BE3EADA22F12AC21AC94A5FC38CA5AFADA73210220AFA84AEEE2DD794576E98411946D671F8E1F80E6C432B5ABAAAB2957651CD674473045022100FD0F2FECF958294BEA74876A4E5FE4192EA10EFC55C9B166F9F427861D5CBC42022067AA4B5CDA1BEB1D400937888C7819A412B238C79423A3DDB6F4FC8F45D45D618114D6C315BE3EADA22F12AC21AC94A5FC38CA5AFADA8314D3BC678DA1AEC545F393F5B0AFD2B8654CE43DB3",
    "tx_json": {
      "Account": "rL2ZJ8iTF9w5UGr8MzQSt8GpedNmutpEEQ",
      "Amount": {
        "currency": "TBC",
        "issuer": "rLJZHsAbNZu264dWnPCGgpqePAYfNZR1Zk",
        "value": "0.123"
      },
      "Destination": "rLJZHsAbNZu264dWnPCGgpqePAYfNZR1Zk",
      "Fee": "10",
      "Flags": 2147483648,
      "InvoiceID": "000000323031342D30392D32335430313A34373A34303A393838343836353030",
      "SendMax": {
        "currency": "TBC",
        "issuer": "rL2ZJ8iTF9w5UGr8MzQSt8GpedNmutpEEQ",
        "value": "0.12423"
      },
      "Sequence": 14,
      "SigningPubKey": "0220AFA84AEEE2DD794576E98411946D671F8E1F80E6C432B5ABAAAB2957651CD6",
      "TransactionType": "Payment",
      "TxnSignature": "3045022100FD0F2FECF958294BEA74876A4E5FE4192EA10EFC55C9B166F9F427861D5CBC42022067AA4B5CDA1BEB1D400937888C7819A412B238C79423A3DDB6F4FC8F45D45D61",
      "hash": "6CDB694DF36F4BD3AB928A9D761A9F60C285557B3C1136749DF7BC56A46ED641"
    }
  }
}

Despite rLJZHsAbNZu264dWnPCGgpqePAYfNZR1Zk and rL2ZJ8iTF9w5UGr8MzQSt8GpedNmutpEEQ trusting the same issuer (rTJdjjQ5wWAMh8TL1ToXXD2mZzesa6DSX) and having enough IOUs to cover the transaction.

How can I fix this issue? What am I doing wrong?

Ripple won't search for paths while processing transactions. The paths must be found first, using pathfinding, and specified in the transaction. You're getting a path dry error because you're not specifying any paths, so the only path you're getting is the default path.

A simple solution is to change the issuer of the SendMax amount to be the gateway. This will implicitly insert the gateway's account node before each path, including the default path. Alternatively, specify the gateway's account node as an explicit path or use pathfinding.


Can you encrypt not just the private key, but also the public keys (ie bitcoin addresses) in an Armory wallet? I would imagine that the paranoid darknety bitcoin user has an interest in keeping not only their private keys safe (so nobody can steal their bitcoins), but also has an interest in keeping their public keys safe (so nobody knows what addresses they control). With bitcoin armory, at least by default, a wallet's public information is available without any password protection when you load the program. Is there an option to encrypt all the wallet's information, so you can be safe in case, say, some jerk steals your computer and scrapes it for information about you?

I would get a Tails USB and store the Armory application and wallet files in encrypted storage. That way not only can they not tie your addresses to you, but if you access bitcoin related sites only through Tails, it would be hard to show you even know anything about bitcoin.


when will the bitcoin wallet app be available for windows phone? I've been wondering because i just bought a windows phone and realized it doesnt have  the wallet app. any idea when windows phone will get the wallet app?

There is no "the" wallet app.

Various development teams have produced wallet software. Some are only for certain desktop or phone platforms, and some are multiplatform. You can find a list here. Some support Windows Phone.

As you have a Bitcoin Core related tag, there are no plans for creating a version for Windows Phone (nor for any other mobile platform).


More Input-Values than necessary. How and why is this possible? No it is not the fees! The TXID I am talking about: 21179a8560a0a0906f0c3396af338f74528130d46b65b7f0c79c378d343b3177

blockchain.com link: https://www.blockchain.com/btc/tx/21179a8560a0a0906f0c3396af338f74528130d46b65b7f0c79c378d343b3177

3JZq4atUahhuA9rLhXLMhhTo133J9rF97j is a known Exchange-Address.

Within above listed transaction there are multiple output-transactions which this address has received referenced as input-transaction to pay 1Kr6QSydW9bFQG1mXiPNNu6WpJGmUa9i1g.

In the above transaction, the source address 3JZq4a.. issues 7 previously received transactions to pay the target address 1Kr6QSy... with 2000 BTC, the rest goes back to its Change address.

My question now is why 7 transactions are "consumed" for this, when it would have worked with a fraction of the transactions.
For example the 7793.90573 BTC transaction.

My first assumption was that this is somehow chronologically handled by the wallet, but even if that were the case, according to the listing in the blockchain explorer after the first 4 referenced transactions used as input, the sum would be sufficient.

131,37735 BTC

1687,1255 BTC

157,79525 BTC

395,876 BTC

Are the first Transactions consumed and the result already exceeds 2k BTC.

I am thankful for any help and ideas!

Only the exchange can answer this - most exchanges and hosted wallets implement their own utxo handling mechanisms, and don't necessarily follow a space/fee optimal approach. There could be other considerations, such as reducing the number of utxos in their wallet, consolidating funds into bigger utxos during a low fee period as they expect larger payments during a high-fee time, or other business reasons.

Alternatively, it could just be an inefficient implementation.


Correct Citation Format for a Bitcoin Transaction When writing an academic style paper where specific bitcoin transactions are used as examples, is there a standard format to "cite" a bitcoin transaction?

If not, what do you think an appropriate format would be?  What data should be included?  What about altcoin chains, what would be different for those chains?

There is none that I'm aware of, but technically speaking, the blockchain and the transaction hash would suffice to find it. It might be nice to add the block height number as well.

Something like:

Tx 35779d11b2c5aedc1ada50aaa33aafb53ccc07dae71e6d18a35a0ccb872a0efa, Bitcoin Block 342508

Would work as a citation.


what is measured in units of sat/kw? Whilst learning about bitcoin & lightning fees I have encountered the abbreviation sat/kw a few times, most recently here:

Why can’t lightning tx’s be signed with sighash single to allow for fee updates?

Is it a ratio of satoshis per kilowatt?

I assume that James is using "sat/kw", to refer to "satoshi per kiloweightunit" as a means to express the fee rate of a transaction. "Weight" here refers to what replaced "blocksize" as a blockspace limit in the protocol rules with the segwit softfork.

I'm seeing "sat/kw" for the first time in this context. I've seen wu used before to refer to weightunits instead of w, and "virtual bytes vB" seem to be more common generally.

I've explained the relationship of blocksize, virtual size and weight in depth here: Is there a difference between bytes and virtual bytes (vbytes)?


Can I get Bitcoins anonymously by having a friend perchase them from an exchange and tranferring them to me? Be kind to me as I'm a little bit fresh off the block with regards to bitcoin...

Basically I'm looking for a practical way to get bitcoins anonymously. I know I can find people to meet up with to purchase bitcoins for cash and I know about Bitcoin ATMs but I was wondering, what if were to set up an anonymous bitcoin wallet and then have a friend purchase bitcoins legitimately through an exchange and then transfer the bitcoins to my wallet... Isn't this pretty much exactly what those people meeting for cash are doing? Obviously then it's not anonymous for my friend but so what? They don't need anonymity if all they're doing is buying and selling bitcoins right?

Thanks

At best, you're going to get Pseudonymity doing things that way. A determined adversary will know that your friend got the bitcoins and transferred them to someone. It wouldn't take that much digging to find out who your friend transferred those bitcoins to.

For example, if you were to purchase something illegal with those bitcoins and law enforcement cared about it, they would find out that these bitcoins at one point were with your friend. At that point, they'd go and find out from him who he sold the bitcoins to. You would be found out very quickly if they can locate your friend. This is, in fact, the sort of thing detectives do all the time.

You'd have much better luck tumbling your bitcoins.


is there a tool to produce addresses given a master public key? I have master public key of my wallet and I want to generate addresses but without using my current wallet. Is there a tool that does that?

Check out libbtc (https://github.com/libbtc/libbtc), once compiled, you get a command line application called bitcointool.

libbtc compiles without external dependencies (compile it with --disable-net if you don't need libevent based p2p network features).

You can then derive a sub-key from your master with something like...

./bitcointool -command hdderive -keypath m/1 -privkey xprv9s21ZrQH143K3C5hLMq2Upsh8mf9Z1p5C4QuXJkiodSSihp324YnWpFfRjvP7gqocJKz4oakVwZn5cUgRYTHtNRvGqU5DU2Gn8MPM9jHvfC

(should also work for public key derivation)

Maybe check the docs: https://github.com/libbtc/libbtc#the-bitcointool-cli


What are some of the things that would make bitcoin better and more accepted? More trade... more trust... more btc 'banks'...? It is such a great system. It just needs to go main stream.

Any thoughts?

Adoption is limited because of a chicken and egg program. People don't accept bitcoins because nobody else accepts bitcoins.

Normally, the way you solve a chicken and egg problem is to get the cycle going by finding a niche in which the technology works so much better than other available solutions that adoption is possible even without a critical mass -- that is, by finding a killer app. The problem with bitcoin getting started through these kinds of mechanisms is the lack of stability in the price of bitcoin relative to national currencies.

For a while, speculation and investment were the killer apps that were driving bitcoin. The problem is that if this is the driving force behind a commodity, there will inevitably be bubbles and crashes. These drive down the use of bitcoin as a medium of exchange. The adoption cycle only works if the killer app drives widespread adoption, it fails if the killer app works against it.

So that's where we're stuck. But there are a lot of really smart people working on the problem. They're working on getting ATM machines to sell bitcoins, adding the ability to accept bitcoins into widespread point-of-sale systems, solving the problem of having to wait for confirmations, and so on.


Bitcoin charity fraud - is it illegal? So we're all aware of services like CoinAd, but what if someone took advantage of that? Imagine if someone had a video game on facebook or something and had people fill out a CAPTCHA before they could play... couldn't someone really just ajax a separate, custom server that curl'd coinAd, kept the session alive, passed the image generated by google to the user, have them fill it out, then pass the answer back to coinAd, and inserting their own BTC address? Couldn't someone decieve people into giving them a BTC charity?

I know it's "limited" to one address per hour per user or whatever, but if you played it smart, you could have thousands of addresses and make thousands of users with thousands of email addresses. You could even shard the servers around the world so that you won't have one ip address. Heck, I bet you could even put it on the user's own computer in an  with display:none!

Although coinad's rate is only .00005 BTC (~1/1000th of $0.01), but if you get 20,000 users on your facebook game, you'd make $100.

What I'm saying is, is it illegal to take advantage of this (technically speaking) give-away? ;)

If you were smart enough to set up the system you describe, you'd have far easier ways to earn $100!

Such activity would show up in statistics as a significant drop in ad clicks or similar measurements. If the operator of the site is canny, they could start to make regular (even automated) changes to the site design to make it tougher to parse. It's a cat and mouse game I guess in a similar way to malware and anti-malware software.

If you dropped the profitability of the site too much, I'm sure it would close.

This question discusses the legality of fraud relating to Bitcoin:
Is performing a 51% attack / double spend on Bitcoin illegal?


Export Market realtime rate Please is there any web site that purpose web services, to export Market rate value of different currency even bitcoin.

https://openexchangerates.org/ is a great API for forex rates.


Can a bitcoin transaction get confirmed unexpectedly? Let's asume I make a transaction with no fee and doesn't get confirmed after a while (let's say 10 days).

Could it be confirmed after that if for some reason some miner keeps a copy? I don't ask if is likely to happen but if it is posible.

Absolutely. There are cases of transactions remaining unconfirmed for several days and then getting confirmed.

If the transaction was ever broadcast and is still valid, it can be included in a block by any miner who wishes to include it.


Does blockchain.info retain the wallet password in client-side memory? When you log into blockchain.info - you enter the password on the client side.

Does the password remain stored in a local javascript variable on the client side after the login process is over?

If yes, does that count as real a security risk? What kind of attack vectors does that open you to?

If not, how else does the wallet update the server side state?

I guess that it must have, because it updates the server after any modifying operation is made, without asking for a password.

That is DannyHamilton claims as well. See also.


Could Bitcoin dust spam be effectively combatted by actually including it in the block-chain? After reading this question I got interested in these mysterious spammers who sent satoshis randomly. For what I read, here's been plenty of discussion about this, mainly at Bitcoin talk (discussions here, here and here - in Spanish also here,
here and here) but also somewhere else on the network (as in here).

I got sad when I saw I hadn't received such micro-payments, doubly sad when I read most of such transfers won't ever be included since most miner pools actively avoid collecting such "dust" - so spammer gets his message out for free, even though it may only last for a short while.

And I wondered - why not do include such dust, so that spammers are harmed economically and stop doing it? Plus, plenty of people would get tiny bits of money.

What would be the cons? Plus, if I've understood how Bitcoin operates correctly, spammers would end up paying much more in transaction fees than the amounts they actually send - which makes it doubly mysterious to me why not include them.

why not do include such dust, so that spammers are harmed economically
  and stop doing it?

I'm still not sure that would be enough to prevent this kind of spam activity. Even if these transactions were committed to the blockchain, 100,000,000 such broadcasts could be made from 1 BTC, that's a lot of reach for $700.


How does the 'move' command work? I have so far enjoyed the experience of learning about Bitcoins, mining, etc. I've setup a bitcoin daemon in hopes of developing a few apps and services in the near future. However, there is one thing that has been bothering me for a few days now and I can't seem to find an answer for.

There is a 'move' command in the client/API calls list that will "Move from one account in your wallet to another". I read somewhere that this DOES NOT flow through the block chain. If that is the case, then HOW can you actually use those coins in the new account/address when there is no public record of the transfer.

Thanks for your help

Accounts are an internal bookkeeping mechanism of the Bitcoin client. They are not the same thing as addresses. When you move from one account to another, the coins remain in the same address, and if you need to spend them they will be spent from the same address. The only thing moving does is subtract a number from one account and adding to another - both of which are just things the client displays and nobody else on the network has any knowledge of. An account balance can also be negative.

Accounts are good if you run a shared eWallet and want to track users' balances (and "move" can be used to make an intra-bank transfer), or if you want to keep track of different purposes of savings (so you can direct all incoming coins to an account called "unallocated" and then move 100 BTC to the account "college fund"; if you make sure to designate all outgoing transfers as coming from "unallocated", you will not accidentally dip into the college funds, no matter in which addresses your bitcoins physically sit).