Help with bitcoin gold explorer: using explorer after fork I tried to view my free BTG using the bitcoin address, but it doesn't recognize the address. The explorer was at: btgexplorer.com.  Yet, when I try the same thing at bitcoingold.org, there they have a utility titled "CHECK YOUR ADDRESS BALANCE BEFORE BLOCK 491407", it works fine. What is the problem with the explorer? I also get the same error with the explorer at btgexp.com.

After more googling I found this one: https://bitinfocharts.com/bitcoin%20gold/
It displays the correct BTG balances for my addresses at least


How to upgrade Bitcoin daemon in ubuntu 12.04? I am currently having Bitcoin daemon version 0.9.0 and bitcoind getinfo shows error like "Upgrade required"

{
"version" : 90000,
...
"errors" : "URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed"
}

How to upgrade Bitcoin daemon in ubuntu 12.04 and want to know daemon is sync blocks once again needed?

Update

The Ubuntu PPA has been updated with packages for Bitcoin Core 0.9.1.  Ironically, they make the upgrade warning go away, but they do not fix the problem!

The Bitcoin Core packages for Ubuntu do not include a dependency on a fixed version of the OpenSSL libraries.  Therefore, if you have not upgraded OpenSSL on your Ubuntu system, you will still be able to install the Bitcoin Core 0.9.1 packages.  It runs just fine, and displays no warnings, yet is still vulnerable.

So upgrading to the Bitcoin Core 0.9.1 packages is neither necessary nor sufficient to remove the vulnerability.  The one and only thing to do is to upgrade OpenSSL, and then (other than the warning message) it does not matter whether you use 0.9.0 or 0.9.1.  Bitcoin 0.9.1 has absolutely no functional changes versus 0.9.0 (I diffed the sources).

To summarize:

Bitcoin 0.9.1, new OpenSSL: Not vulnerable, no warning
Bitcoin 0.9.0, new OpenSSL: Not vulnerable, displays warning
Bitcoin 0.9.1, old OpenSSL: Vulnerable, no warning
Bitcoin 0.9.0, old OpenSSL: Vulnerable, displays warning.

I will try to find the proper place to report this as a bug.

Previous discussion

The Heartbleed bug is not in bitcoind itself, but in the OpenSSL system library on which it depends.  The bug is "fixed" in Bitcoin Core 0.9.1, but all they did was to require the use of OpenSSL 1.0.1g, which incorporates the actual fix.

However, Ubuntu has not updated their distributed version of OpenSSL to 1.0.1g; instead, they have patched the version that they are using.  The patched version is 1.0.1-4ubuntu5.12.  Ubuntu's security advisory is posted at http://www.ubuntu.com/usn/usn-2165-1/.

Possibly as a result of this, Ubuntu packages for Bitcoin Core 0.9.1 have apparently not been created; but if you upgrade your OpenSSL libraries, it is not necessary to upgrade Bitcoin Core.

If you have the precise-security repository in your software sources (or in /etc/apt/sources.list), all you need to do is install the updates as you normally would, using either the update manager or aptitude update; aptitude upgrade.  If you have unattended upgrades enabled, this has probably happened already.  You can check the installed version by running dpkg -l libssl1.0.0.

Once this is done, you should restart bitcoind.  (In fact, if possible you should probably reboot the system, to ensure that other potentially vulnerable services are also restarted.)

In general, upgrading Bitcoin Core does not require you to re-download the block chain.


How do merkle trees ensure credibility to blockchain, when full node wrongly denies a presence of a txn in a block? How can Merkle Trees ensure that a full node doesn't lie to a thin node that a txn t is not present in a block B if infact B contains t? How can a thin node tell if the full node is lying if the full node denies the presence of a txn t in a block B and doesn't send any hash values(for the thin node to verify) and instead claims it can't generate hashes that are not there.
PS: Don't mind the informal style of my questioning. I'm just trying to get an intuitive understanding of Merkle Trees at first.

Your instinct is correct: a full node can lie-by-omission to a light client and deny them proof that a transaction was included in a block. This is a well-documented vulnerability of SPV wallets and the only mitigation really is to connect to more peers (you only need one "honest" peer).
This problem is also somewhat addressed by BIP157 aka "Neutrino". In this protocol, the light client scans entire blocks for its own transactions. It knows which blocks to check based on filters provided by full nodes. Of course, this brings us back to the first issue: what if a full node provides an invalid filter? Eventually we might see a soft fork that requires valid filters to be inserted in some part of the block, secured by proof-of-work.
Currently, BIP157 offers this:

Unless securely connected to a trusted peer that is serving filter
headers, the client SHOULD connect to multiple outbound peers that
support each filter type to mitigate the risk of downloading incorrect
headers. If the client receives conflicting filter headers from
different peers for any block and filter type, it SHOULD interrogate
them to determine which is faulty. The client SHOULD use getcfheaders
and/or getcfcheckpt to first identify the first filter headers that
the peers disagree on. The client then SHOULD download the full block
from any peer and derive the correct filter and filter header. The
client SHOULD ban any peers that sent a filter header that does not
match the computed one.


Bitcoin multi-sign and the amount of storage it required I read the paper "Threshold-optimal DSA/ECDSA signatures and an application to Bitcoin wallet security". The authors said that in the optimal threshold signature that they propose, players require just a constant amount of storage, while the previous threshold schemes were not efficient because the number of rounds increase according to the number of players; therefore, also the amount of storage that each player needs increased accordingly.

Now, I am wondering about the amount of storage that each players needs when they use multi-signature scheme?
Is it constant or does it increase when the number of player increase?

Didn't find the reference of your text... I'll define usage of multisig and length a bit more generally.
With a multisig scheme, you create a "funding" transaction with a redeem script. This redeem script is the hash of the n-of-m multisig identifiers, and the required pub keys. So the funding tx is not bigger than normal tx.

Then spending the multisig, the V_IN structure gets bigger, whereas V_OU remains the same size. Assume a multisig requires n-of-m signatures, and a typical sig looks like this:

48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG R (32 Bytes)
    4673096ED91CC985:B05F64780BA123E1
    C193FC860B2163DC:B3B5D4F3049F30D2
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG S (33 Bytes)
    00DE2CA5EBBCB5D1:19877AD737930BC5
    7F2356CBAC646405:DC881270CFAE78BF
    1D
01: OP_SIGHASHALL:       terminates ECDSA sig (ASN1-DER structure)

then the first byte already indicating the length of sig (there is comment from me at the top, to a link from Pieter Wuille, explaining length of Sigs to be 71 or 72  Bytes long).  Additionally to the added signatures you have also the redeem script added to the tx, behind the signatures in the V_IN structure. The redeemscript has in a 2-of-3 music the typical structure:
<2><3>
Now it depends, if you use compressed or uncompressed pub keys (33 or 66 Bytes long). This increases your overall length of the tx. Summary for spending funds with a bitcoin tx:

normal tx has 1 sig          (at ~70 Bytes) and 1 pub key  (@ 33 or 66 bytes)
multisig has  n (-of-m) sigs (at ~70 Bytes) and m pub keys (@ 33 or 66 bytes)


What is the scriptCode in a P2WSH transaction? Let's say I am spending from a 2-of-2 multisig with this script:

522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae

OP_2 <len(pubkey1)> <pubkey1> <len(pubkey2)> <pubkey2> OP_2 OP_CHECKMULTISIG

What would go in the scriptCode according to BIP143? Is it just the script listed above? Here is the relevant part from BIP143.

  For P2WSH witness program,
  - if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut.
  - if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below)

Yes, the scriptCode would be that multisig script.


Atomic Swap - What if redeem is done just before expiration As per the explanation provided here: https://github.com/decred/atomicswap

The contract is valid for a certain amount of time (example set to 48h) and in order for the party B to recover the found, he needs the secret that is published on the chain after the party A has redeem the coins on the contract.

As far as I understand, it takes some time for party B to actually recover the secret from the chain and then redeem the coins.

What happens if party A wait last seconds (let's say 5 seconds) before expiration of the contract to redeem the coin, which wouldn't provide enough time for party B to redeem its coin before the contract expiration in which case it would be refunded to party A as well as getting party B coins.

Is the understanding correct and that point valid?

Is it fixable by setting different contract expiration period, lets say party A contract would need longer expiration time to ensure party B ha time to redeem the coins?

As you stated, setting 2 different expiration times provides safety.

My recommendation is to select the network with the longest period before immutability as the first contract, and pick a time that is agreeable with both parties.

The second contract on the other chain should use an expiry that is half of the first contract. This gives the redeemer on the first blockchain some time before the expiry.


Would this wallet backup system work? I was thinking about a possibility to overcome the 'only stored on one PC' wallet problem! I erase or lose my PC, then I lose all my bitcoins.

Suppose that the wallet, associated with an account number and a strong secret password were backed up on all Bitcoin clients.

What would be the drawbacks/advantages of this solution?

In a way, this is how deterministic wallets work: All keys and addresses are derived from a secret pass phrase. The "wallet" in this case is the description of the algorithm, which is "stored" publicly.


How does a Bitcoin client efficiently change forks? Occasionally, a Bitcoin client will come across a fork of blocks that is longer than the chain it is currently on. Depending on how often orphaned blocks occur, this could be quite often. When this happens, any internal data structures relating to the "current" state of the blockchain (for example, a hashtable of unspent outputs) need to be updated to reflect the state of the new, longer fork.

How is this accomplished? Is history played "backwards" to the most recent common ancestor and then "forwards" to the new top block? Is it all just reconstructed from scratch?

The UXTO set certainly isn't reconstructed from scratch, that would be an incredible DoS vector if it did. Even on fast machines a complete reconstruction takes hours, days on slower disks and processors.

From a look at the source on github, we can see that your assumption is correct. The UXTO set is reconstructed backwards to the point where the chain is forked, and then continues on down it as normal.

The client seems to assume that large (100+) reorganisations of the blocks are improbable, which is why coins need to "mature" to avoid the situation where there's transactions spending coins that no longer exist in the chain.


Is it possible to check if an Address was generated from an HD Public Key. Suppose I know a specific address and I know a full HD Public Key. Is it possible to determine if the address is a hash of one public keys generated from the HD public key in constant time, or in other words without checking every possibility?

No, it is impossible to know. You would have to check every possibility.


can cryptocurrencies be energy efficient? Is there an intrinsic reason why cryptocurrencies currently take a lot of energy to keep working? Is there a way to make a cryptocurrency still widely used but make it energy efficient?

As the answer for this question, we have the Proof of Stake approach, firstly implemented by Peercoin (PPC). I think other coins as Ethereum have as well a proof of stake mining/minting approach

links: https://peercoin.net/minting and https://github.com/peercoin/peercoin/wiki/FAQ


Zero-BTC transaction fees, service-specific mining pools and external compensation Bitcoin is a network that is proven to be stable, but if you want applications on top of Blockchains you have to play by the rules of the system. For notary use cases (for example), where you would store a document hash on the chain, it might not be beneficial to charge a transaction fee for issuing a document, since you would want to encourage your users to create content and perhaps charge people who want to verify the information instead.

Let's say you build a mining pool that accepts zero transaction fee that owns and maintains a certain percentage (let's say 0.1%) of the global Bitcoin mining power. Let's also assume the mining costs (energy, hardware depreciation, etc.) are not an issue (for now).

Can a transaction that offers zero fees target this mining pool? (I assume yes, through a tag in metadata perhaps)
Could this mining pool filter staged transactions by this tag?
Can the mining pool, if it owns 0.1% of the global mining power guarantee the confirmation of the transaction within a certain period of time? (1hr, 10 hrs, 1 day, 1 month, 1 year?)
Is there any example out there that do something similar and use an external mechanism how to compensate mining costs?

Every mining pool can select (valid) transactions for confirmation on basis of whatever criteria they want. If the mining pool had an agreement based on direct payment by those wanting to use the notary service, they could prioritize confirmation of document hash transactions.

The criteria of selection would then perhaps be that they get the transaction from their customer with the request to confirm it.

However, this scheme would only make economic sense for the mining pool, if confirming the notary transactions was more valuable to them than the fees paid by regular transactions. So, in a sense, those notary transactions would have to compete with a similar value level as regular fees anyway.

With 0.1% of the global mining power, the expected time until the pool finds a block is 10000 minutes, which is pretty close to one week. If the pool were to maintain their 0.1% hashrate, it would have a chance of 1 - exp(-4) = 98.1% chance to find at least one block in four weeks.

Something very similar is already happening: BTCC is running a service called BlockPriority that prioritizes transactions of BTCC customers.

That said, it is unclear to me why one would want to encourage users to create bloat on the Bitcoin blockchain. It would make much more sense to create a Merkle tree from all documents to be confirmed, publish it somewhere online, and just anchor the root of that Merkle tree in the blockchain by paying a single transaction fee.


Should the Policy to Miniscript compiler(s) be considered as deterministic and is this the end goal? Should the Policy to Miniscript compiler(s) be considered as deterministic and is this the end goal?
This question was asked by Jeremy Rubin on ##miniscript on IRC and has been paraphrased.
For basic explanations of Policy and Miniscript see this previously asked question.

The mapping between Miniscript and Script will never change. (At least, not without a major version bump of this library and at this point, probably a "Miniscript 2" which is billed as a different language.)
The mapping from Policy to Miniscript may change even between successive runs of the compiler.  Currently, the Miniscript compiler produces the most optimal compilation in terms of average satisfaction costs but the compiler internal uses non-deterministic HashMap traversal. It might produce two different compilations of the same average satisfaction cost. So it is not advised to rely on the Policy compiler producing the same results. Even the C++ and Rust implementations may differ in actual Miniscripts but will have same average satisfaction costs.
In the future the compiler could be improved and Miniscript extended. In addition there may be auxiliary information someone has that changes the optimal script but doesn't fit in the currently accepted Policy compiler. Policy language and the current compiler should be seen as a demo and not the final authority on declarations of Miniscript. The real value of Miniscript comes with being able to reason about arbitrary scripts that people give you regardless of how they came up with them. If you reduce that to needing the Policies they were compiled from you're massively restricting its possibilities.
There is a concern that the ecosystem comes to implicitly rely on knowing Policies in this quick and dirty Policy language and a compiler can't evolve because of it. The end goal should be eventual interoperability and the the layer at which things interact should be Script/Miniscript not Policies.
This question was answered by Sanket Kanjalkar, Pieter Wuille and Andrew Poelstra on ##miniscript on IRC but has been paraphrased. Any errors are my own (and I will gladly correct).


Does mining a block force others to restart their work? Does mining a block mean that anyone else who was working on mining a block loses their progress and must restart?

Yes and no.

When a new block is created, everyone on the network must discard old work and use the new information provided (assuming they don't want to create forks). It does lead to some small performance loss.

On the other hand, creating a block is more or less like playing a lottery - there is no real "progress" per se, you are just trying more and more tickets until you win something. When a new block is created you don't have a situation of "10% left, I lost so much work", as there is no telling whether there actually IS a solution to the particular configuration of a block you were creating.

All in all, yes, everyone must start over when a new block is created, but they don't lose much (aside from some small performance drop due to stale shares).


Do thin clients leak which addresses you own? According to this, thin clients use bloom filters to request "addresses and transactions they are interested in to the peer".  And according to this, bloom filters are used to help prevent the SPV peer from "know[ing] which transactions belong to the client and which don't.".

But the accuracy of bloom filters, and thus how easily the peer can deduct which addresses belong to the client, is determined by the thin client.

So how well do the major thin clients (Electrum, Multibit, Mycelium, etc.) protect the privacy of the addresses belonging to your wallet from their SPV peer?

Electrum:

No protection, the server you are connected to knows every address you own and will own in the future. If you use Tor your IP address is hidden, but the addresses are still associated. Bloom filters are not in use for this client.

MultiBit

In theory the bloom filter can be modified to include junk data to hide your addresses with loads of fake ones, currently this is disabled for speed and so there's no protection. Your peers know your IP address and the contents of your wallet, Tor is not supported.

Mycelium

I believe this client uses BitcoinJ (same as MultiBit) so the same caveats apply.


bfgminer 'Rejected' problem I'm running bfgminer with block erupters, and all is working fine 90% of the time. However, if my internet connection drops briefly, then I get nothing but Rejected shares from that point onwards. This never rectifies itself unless I restart bfgminer. This probably happens once every few days which is a little frustrating.

Does anyone have any idea why is happens?  And what I can do about it?

Thanks

?

Bugs can be reported at https://github.com/luke-jr/bfgminer/

Please run with --log-file debug.log --debuglog -P and upload the entire file to Dropbox (or equivalent); if you have sensitive information (passwords?), be sure they are not in the log file before publishing it.


What is criteria of mining priority except for transaction-fee? I am reading "Mastering Bitcoin written by Andreas" and I found this explanation of mining.

  Transactions are added to the new block, prioritized by the
  highest-fee transactions first and a few other criteria.

  Source: [Mastering Bitcoins: Mining Transactions in Blocks]

I want to know what the a few other criteria are. And I want to see the source code where the system prioritizes by highest-fee transactions first and a few other criteria.

I guess that the code is in miner.cpp. But I don't understand the exact line.

https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp

The code you're looking for is in CreateNewBlock.

The usual way transactions are added to a block is by sorting by priority. The priority of an input is the value being spent in the input multiplied by the number of confirmations it has. The priority of a transaction is the sum of all the priorities of the inputs. See this line:

dPriority += (double)nValueIn * nConf;

Transactions are added to a vector of transaction priority:

vector<TxPriority> vecPriority;

Then they are sorted according to their priority:

TxPriorityCompare comparer(fSortedByFee);
std::make_heap(vecPriority.begin(), vecPriority.end(), comparer);

And one by one, transactions are verified to be valid and then added to the block, done by order of priority, higher priority first.:

while (!vecPriority.empty())
...
// Added
pblock->vtx.push_back(tx);


Which cryptocurrencies are better suited to users with limited bandwidth? I'd like to try my hand at cryptocurrencies, but have limited bandwidth. Which cryptocurrencies are best suited to users such as me? Why?

Due to the high bandwidth costs, I expect cryptocurrencies to not be profitable for me, so my main priority here is to try my hand at a few of them without using up too much bandwidth. I'm not sure if this makes much difference to bandwith use, but I'd like to try my hand at mining and trading.

Apart from a few cryptocurrencies, including Bitcoin, most of them have very low exchange rates. So although you will find many such virtual currencies, it won't be profitable either way. And mining does not require bandwidth as such, it's only the blockchain synchronization which would be slower with a lower bandwidth. Mining is achieved by your machine and not the bandwidth.

If it's only the knowledge you wish to gain, then you can use the bitcoin testnet to mine test bitcoins, however trading testnet coins is not an option.


Scrypt server mining process killed On my vps I decided to start mining litecoin because I wasn't really using the server for anything. I thought, why not?

I ran the cpuminer script with the correct command line arguments and it connects to the mining proxy fine. It mines like normal for a few minutes.

It works pretty well and then the script just says Killed and gives me the command line. I can run the same command again and mine litecoin for a few minutes and the same thing happens. I think this is the work of my vps hoster (vpscheap.com if it helps). What could be causing this and is there any way to get the script to automatically restart when it is killed? Any help is appreciated.

p.s the server is ubuntu 13.04-x86-64

Have you ever thought of looking through your host's Acceptable Use Policy regarding CPU usage? You're breaking their terms so it's no big surprise that your process keeps getting killed. I'm honestly surprised that you haven't been suspended yet for it. To quote:

CPU Usage
Every vps comes with a number of CPU cores that client has access to. The said CPU cores are not dedicated to any vps. Client may not use more than 85% of one CPU core per process thread for more than 10 minutes. Client may not use 100% of one CPU core for more than 2 minutes. When CPU abuse is detected by our automatic programs, process will be killed and/or vps stopped/suspended, and the above Resource Abuse policy will be enforced.

Find a host that allows cryptocurrency mining, or even better- rent a dedicated server.


Bitcoin core full node - Should I choose my peers or it's fine to use the hardcoded ones? I have a full node v 0.17.1 running 12-14 hrs/day and I was wondering if it's helpful, for privacy or for whatever reason, to add peers (maybe from https://bitnodes.earn.com/nodes/leaderboard/) with connect= or addnode=.

The list is just for bootstrapping, no need to manually list peers unless you have others you specifically want to maintain connectivity with.


Subscription-based payments I'm writing a web application that will require subscription fees from users. I'd like to automate this process without relying heavily on 3rd party services (web-based wallets, etc).

Currently, this is how it is designed:

Web app connects to a websocket on the server using a JWT bearer token for authentication and requests an address.
The server calls the getnewaddress method to the RPC daemon and returns this address over the websocket
The wallet's pub (is priv necessary?) keys are stored in the webapp's database as well as the user that requested the address.
The websocket will provide periodic progress updates along with a refreshed JWT (tokens expire every 2 minutes) while waiting for the transaction. If the user disconnects, no harm done.

Once the transaction is completed, a curl command is triggered by walletnotify and submits this TXID to the web server, which ensures "confirmations" are > 0, and the "receive" address is used as the database query to determine which user added time to his/her subscription.

Questions:

Does getnewaddress generate a new wallet? Or am I free to receive as many as I'd like?
Running getbalance <account> shows the summation of all addresses listed in listaddressgroupings. Is this all usable from the same wallet?
How can I consolidate or remove addresses when they're no longer necessary? Do the BTC stay in the "account"?

getnewaddress will generate a new Bitcoin address for your existing wallet, Yes you can get as many as you like.

I would use getreceivedbyaddress which returns the total amount received by the specified address in transactions with the specified number of confirmations or listunspent to get all transactions for specific address with confirmations

AFAICT, You can't remove an address from your wallet using any RPC call, but by editing wallet.dat manually.


Official Canadian source saying bitcoin is not legal tender? I've been reading a lot that Canada no longer considers bitcoin legal tender.

  "Only Canadian bank notes and coins are recognized as legal tender in
  Canada. Bitcoin digital ‘currency’ is not legal tender in Canada,” an
  official from Canada’s finance department said in an emailed
  statement.

It can be read in all of these places:

Canada Real Time
Memeburn
The Wall Street Journal

among others. However, not a single one that I can find sites the source document. They all just seem to refer to each other. Does anyone have a copy of the email or government source document stating this? I'll also accept proof that the document never existed as a valid answer.

The Currency Act defines what is meant by legal tender in Canada:

Legal tender

8. (1) Subject to this section, a tender of payment of money is a legal tender if it is made
(a) in coins that are current under section 7; and
(b) in notes issued by the Bank of Canada pursuant to the Bank of Canada Act intended for
circulation in Canada.

Since these are the only two forms of payment considered legal tender, and bitcoins are quite clearly neither of these, the conclusion must be that bitcoins are not legal tender in Canada. Note that the Act doesn't explicitly have to name Bitcoin for this conclusion to nevertheless be true.


Bitcoin unusable UTXO Attack could be happened? Let's say current BTCUSD rate is 1BTC = 3,000USD and average fee is 300satoshi per byte And I need to pay some bitcoin to P2PKH address owned by bitcoin exchange/cafe or bar, basically whoever allows Bitcoin payments.

Because Bitcoin allows that transactions which has multiple same address output, I can do something like this

Input

0.0135 BTC($40)

Output

cafe address 0.00045BTC($1.332)
cafe address 0.00045BTC($1.332)
cafe address 0.00045BTC($1.332)
... 27 more same outputs

I need to pay about $9 extra fee(because each output are 34 byte data therefore each output costs $0.306 (3000 * 0.00000034 * 300)).

Once the transaction is contained in the blockchain, I technically paid 0.0135BTC and I get a cup of coffee.

The problem is, the caffe owner almost never be able to use it.
each P2PKH input needs around 148bytes and costs 0.000444BTC(0.00000148 * 300) as fee.

spending 0.00045BTC requires 0.000444BTC.

I don't know who would do this.But this might work.

Could this be happened?

Technically, sure, this is possible.

Practically, you might get away with it the first time.  You'll have effectively paid an extra $9 for your $40 round of drinks, but you'll get the added satisfaction of having been a jerk.  The bar owner will realize that he can't spend the money, shake his fist, and write off the cost of the drinks (which is probably more like $10).

The next time, you'll find a sign posted that says "Bitcoin payment rules: maximum one output".  If you try your multi-output trick again, they'll point to the sign and say "nope, that doesn't count, you haven't paid".  You'll have to pay again, and now you are out $89 for a $40 round of drinks.

(The third time, you'll find a photo of you behind the bar, marked "DO NOT SERVE".  And a very large fellow in a T-shirt will ask you firmly to take your business somewhere else.)


How to connect to a public node through json RPC? I found a list of public bitcoin nodes here.  I am using a php library. How can I connect to these nodes via JSON RPC? Is it safe to connect to public nodes? What should I give as username and password?

I had tried a bitcoin node on my ec2 instance. It is taking too long to sync and blockchain size is also increasing. I want to communicate with bitcoin network without running a bitcoin daemon.

Not all nodes will have the JSON-RPC enabled, and especially without private credentials. You will probably find a block explorer API much more accessible, because they are built to handle public traffic. There are many blockchain explorers online that have public apis, they are easy to find.


Bitcoin Core not showing content of address Bitcoin core newbie here.
I have an old wallet  backed up here, and upon download of the latest blockchain info, importing the wallet, my balance is empty.
Now I do have 3 transactions which I made in 2018, including one on which I transferred all my remaining assets. One of these addresse, upon blockchain explorer verification, indeed contains my asset.
How can I access it via bitcoin core? The wallet was originaly created within Bitcoin Core.
When getting the private key to the address holding my asset, and importing the priv key into an alternative wallet such as electrum, I can't see the public address holding my assets and not access them either.
Can someone tell me how I can access the content of the public access bound to my private key please?
I spent hours on this already...
cheers

download of the latest blockchain info, importing the wallet,

If you did it in that order you probably need to rescan using the console or command line options.

rescanblockchain ( start_height stop_height )
Rescan the local blockchain for wallet related transactions. Note: Use
"getwalletinfo" to query the scanning progress.
Arguments:

start_height    (numeric, optional, default=0) block height where the rescan should start
stop_height     (numeric, optional) the last block height that should be scanned. If none is provided it will rescan up to the tip at
return time of this call.


Do I have someone else's private key in my wallet, or has my wallet been compromised? Apologies for the vagueness of my memory.

I started using Bitcoin in mid-2015. I believe I installed Bitcoin Core at that time but got bored waiting for it to sync the blockchain, so I instead used MultiBit

Last week (April 2017) I decided to migrate off what is now called MultiBit Classic, since it's no longer supported. I upgraded Bitcoin Core to the newest version, waited for it to sync the blockchain, and was surprised to see two transactions from October 2016, both involving the address 1QKcPYdiDfPgNH4dYnC99uZqTszU4gndnn.

Dumping my wallet shows this address was generated back in 2015, and is marked as "reserve":

[private key deleted] 2015-04-29T18:42:36Z reserve=1 # addr=1QKcPYdiDfPgNH4dYnC99uZqTszU4gndnn

I'm sure these transactions have nothing to do with me. I wasn't using Bitcoin in October 2016, and I don't believe I ever performed any transactions at all with Bitcoin Core. What's going on?

This is indeed strange.

What you should have done before upgrading Bitcoin-Core (if your old Core wallet didn't had any funds in it) delete the wallet.dat file.

Because you are using now keys that where exposed on your hard drive since 2015.

This is the case because Bitcoin-Core uses "key pool". Once you launch Bitcoin Core the first time, it will pre-generate 100 keys (these are the reserve=1 keys in your dump).

My recommendations would be creating a new wallet (these steps assume you currently have funds in your wallet):

Stop Bitcoin-Core
Move your wallet.dat to somewhere save (rename it wallet.old.dat)
Start Bitcoin-Core (a new wallet will be created)
Encrypt your wallet with a secure passphrase
Copy out a new address to send your old funds to.
Stop Bitcoin-Core
Move your wallet.dat to somewhere same (rename it wallet.new.dat)
Move back your wallet.old.dat to your datadir and rename it back to wallet.dat
9 Start Bitcoin-Core and send all your funds to the address in your new wallet (step 5)
Stop Bitcoin-Core, move away your old wallet and move back your wallet.new.dat to your datadir
Start Core, and check if your funds are there


What are the trade-offs between transacting on Lightning Network and Bitcoin mainchain? Lightning network's first prototype code is online, so it's about time we learn more about what it is. (At least I wish some people would…)

What are the expected trade-offs of Lightning Network to Bitcoin mainchain?
Some points that would be nice if they got covered:

privacy
confirmation speed
fees
time until spendable

And for the bonus: Will Lightning Network be centralized?

Below describes these points during what's planned to be normal operation. Once a channel needs to be torn down because of a problem with one of the nodes (evil or accidental) some of these answers are a little different.

privacy - Privacy is not a linear scale, but there are a few factors that clearly improve privacy:

Very few transactions actually end up on the permanent and public blockchain. And those are a payment from you to an LN node (or vice versa) and there is no record on the blockchain of the actual destinations (or sources) of the money.
Routing of messages (and LN transactions) will be done in a Tor like fashion (Onion routing) with encryption of the message such that intermediate nodes can't read the transactions nor do they know the true origin or destination (IP address) of the transaction.
To obfuscate your actions, you can pay to yourself from one channel to another, and I'd assume it's a lot easier to do quick and trustless mixing through LN.

confirmation speed - You don't need to wait for any confirmations at all, so transactions are truly instant. Network latency (multiple hops) will be the deciding factor as all encryption and other overhead is low even for relatively low end hardware (phones).
fees - Every hop will want a little bit of fee for the service of forwarding your transaction. This can be pretty tiny though, allowing for true micro payments. In some cases nodes might want to balance out their channels and give you negative fees depending on which direction the money is flowing. This will create an interesting market between all the nodes offering their services and keeping fees fair and low.
time until spendable - Immediate. Any money you receive on a channel you can immediately spend again (through the same channel). If you want to settle on the blockchain and then spend the bitcoins there, you'll first have to close the channel, which under normal conditions requires the standard 10 minutes confirmation time (you don't need more confirmations, although the person you are sending the Bitcoins to might still require 6 confirmations).
centralized - The software is fully open source. Any one can start up a node, put some Bitcoins in and start offering their service to the network and earn some fees for doing it. This low barrier to entry and ease of use should provide enough competition and enough nodes to make it decentralized.

There are some caveats: people will have to put some funds into the node that are at risk if the device gets hacked (initially possibly through bugs in LN, but in general through any malware or badly secured and outdated operating systems). This might be a slightly centralizing force as security is relatively cheaper to do at scale.

DOS protection might be something to think about too. Maybe have the option of using a 3G phone or other channel invisible to the attackers (even sneakernet!) when a true attack is underway and you need to close some channels before they expire. Very little bandwidth is necessary to do that, I'm not sure a DOS attack make uploading a few transactions impossible anyway.

Also I think it's required (or maybe just wise) to run a full Bitcoin node (possibly pruning) on the LN node. LN needs to have access to the blockchain data in a trustless way and need to be able to send transactions to the Bitcoin network reliably in case it's necessary to tear down a payment channel (within a certain timeout). A pruning full node is not that bad to run, but there's a bit of cost that would be lower in a centralized situation.


How do I buy Bitcoin with cash? How do I buy Bitcoin with cash? I am Canadian, and have a lot of cash that I would like to convert to Bitcoin without using any banks. Can I do this?

Yes surely you can, Check out this website : https://localbitcoins.com/country/CA


Where can I find out which BIP (bitcoin improvement proposal) are going to be implemented or not? Is there a site where I can see which BIP's are going to be implemented or not?

https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

BIPs aren't too organized, but usually there's a thread in the development section of bitcointalk and a few things on mailing list.


Coins sent without downloading the full wallet i sent bit-connect tokens to my desktop wallet and now i cant seem to see them can you please help me it says on the block explorer that it is already there but the network is updated. after that transaction i sent another one which came to the address can you please help? Are my coins gone?

Ultimately, if you:

have the private key for the receiving address the funds have been sent to
can still see the expected balance for the receiving address in the appropriate block explorer for BitConnect
can confirm the receiving address was correctly generated from the private key (eg by importing the private key to a freshly installed wallet, and checking the receiving address)

Then your funds should be retrievable, somehow (but you may need to resolve an issue with the wallet).

Firstly, I'd recommend ensuring you have a safely stored backup of the private key(s) for your funds.

Then, you may like to try re-installing the wallet, or deleting some of its data so that it re-sync's from the network.


c-lightning missing outputs A few days ago I did a submarine swap in order to rebalance a channel of mine. I opted to be refunded on-chain using a brand-new address generated with c-lightning newaddr command. I used the p2sh address (aka starting with 3...) because last time I had some issues with the bech32 version.
Here is the point: the on-chain transaction has (at time of writing) more than 80 confirmations, but my c-lightning node still cannot show the output with the listfunds command.
Using dev-rescan-outputs didn't get any results as well.
Am I miss something? Have that utxo gone lost?

For readers, this issue has been solved by @cdecker here: https://github.com/ElementsProject/lightning/issues/3359.

TL;DR: Use the --rescan startup parameter of lightningd.


How to get the addr from this transaction https://www.blockchain.com/btc/tx/2ccc3f59d28c709770a8bc478b112e10feda4bf55197c2e48deaa0eb6bca0311?show_adv=true

The SCRIPT in the transaction is:

DUP HASH160 PUSHDATA(20)[482f0027662731277fdfa3b7f639c976a3bab11e] EQUALVERIFY CHECKSIG

What is 482f0027662731277fdfa3b7f639c976a3bab11e ?

It is not a pubKey.
RIPEMD160(SHA256(482f0027662731277fdfa3b7f639c976a3bab11e)=146sN8tLxV2xueQXQgMJkMZi2hFazEuV8F.

The result is not the address(17afxUJouat3fkaaQ9tZrDThxdkXGL4WrM) in the blockchain.info either.

How we convert the 482f0027662731277fdfa3b7f639c976a3bab11e to it's addr？

482f0027662731277fdfa3b7f639c976a3bab11e is HASH160 (RIPEMD160(SHA256())) of the public key. The hash is the most important part of addresses (addres: network byte + hash + checksum).

You can look at how P2PKH script works step-by-step here.


How to fork a cryptocurrency I have cloned a coin and changed some variable to make it my own coin. I have launched it and have a few mining pools mining my coin. Going through the code I notice I have an error and the reward halving starts over at block 10k. So miners are getting 500 coins per block instead of 250 coins. I believe this sort of change would fork the coin to a new blockchain but I want current holders to keep the same amount of coins on the new fork. How can I change the code and fork the chain to comply with the new info?

https://github.com/DataSaverCoin/DSC/blob/master/src/main.cpp

Compile the code. Release the new client. Old and new version will disagree at some point in the future (block 10k in your case) et voila, you will have a forked chain.


What ultimately happens to mining if blocks contain mostly non-Bitcoin data? I'm trying to understand what can happen if

A block consists entirely of 3rd party (xCoin) data like Namecoin
There are no Tx fees to collect since they are on alternate chains.
Assume that the Block reward is quite low (0.25 BTC).

How will mining be profitable?

If the 3rd party data must subsidize mining, what would that subsidy look like within a block?

Whoever discovers the block can choose what information to put into it. Therefore a miner that finds a hash that has a sufficient level of difficulty can choose to only include transactions that actually pay their transaction fee.


Sent two btc transacton to payeer wallet less than the mnmum deposit,neither where credited recently sent to my payeer wallet a 0.0002 btc transaction which is less than the 0.0005 minium btc deposit, then did a second transacton of 0.0003 btc thnking that it will sums up.
Both transaction where conrmed more than 100 times and sent to the payeer wallet adress but are not credited and payeer system refuse to credited it. Yet those btc habe been sent to as the bitc explorer show for a total deposit of 0.0006 btc?
What can  do to retrieve my funds ?

What can do to retrieve my funds ?

Bitcoin transactions cannot be reversed once they have been included in a block that is part of the valid chain.
The only way is to have the funds returned is to contact the person you sent them to, and ask for them back.


Is there a block chain bootstrap for Litecoin? For Bitcoin, various people distribute a bootstrap.dat file which contains a snapshot of the blockchain.  A new Bitcoin user can download this file and verify it with their client, which is often more efficient than downloading the entire chain from the peer-to-peer network.

Does something similar exist for Litecoin?

The site below has good information, including guides for different operating systems:

litecoin.info/Bootstrap.dat


Why do we need a genesis block? In bitcoin, a blockchain always starts at the unique genesis block. Beyond that point there can be forks, and only when it is clear which branch will grow fastest (or if it has grown enough), we can know for sure (or almost) if a block will end up in the actual blockchain.

Is it necessary to have a genesis block? I could imagine that without, when bitcoin was launched, miners would just have started mining blocks, and as soon as one was mined, the chain would grow from there. If another miner found another block 0, the blockchain could be extended from there as well just as with any other fork (note that this would be equivalent to having an abstract genesis block that doesn't need to have any properties that can be treated as the parent of any block 0).

Is this just an accidental feature of the initial design of bitcoin, or is there a deep reason for the existence of an eternal genesis block?

I think your misunderstanding is in the assumption that the genesis block must be a block.

There is no need for that.

For all we care the genesis block is just a specific hash that is used as hashPrevBlock to identify block number 1. It doesn't actually need to correspond to an actual block. Modern Bitcoin software doesn't actually treat the genesis as a block at all. It's just a piece of data - and its hash is special.

So, no, there is no need for a genesis block. But there is a need for a genesis something - just to identify what the first real block is.


Is it possible to buy a prop of one of the "bitcoins" you often see in the pictures? Is it possible to buy a prop of one of the "bitcoins" you often see in pictures? Does anyone actually make physical "bitcoins?" I collect weird iconic things.

Casascius made physical coins with a private key attached (hidden with similar technology to scratch lottery cards). They were shut down in 2013 by the USA Treasury.

There are other companies who make physical Bitcoins but I cannot vouch for the services personally.

If it's memorabilia then a "used" coin is no problem. However it was possible to use non-polar solvent through an insulin syringe to peel back the Casascius safety seal to see the private keys without showing signs of tampering. This means it may be an issue to pay for ฿1 and find later your coins were stolen since your private key is known. If you buy a coin with ฿ associated with a Casascius coin private key I'd immediately transfer it to a "safe" address.


How can I generate a large number of Bitcoin addresses? I would like to generate a large number of public Bitcoin addresses (several hundred thousand) quickly and efficiently into a simple text file. What would be the easiest way to get this done? I'm just wondering if there are any particular scripts or services that handle this already without having to roll my own.

Vanitygen is a command-line tool that can be used to generate random bitcoin addresses. It also has OpenCL-compatible GPU version called oclvanitygen. Both can be built from source, GitHub, and both are included in the Windows binary package. PGP signature here.


Version prefix used for Bech32 addresses I was compiling a table for Version prefix (hex)  and Base-58 result's prefix for different types of Bitcoin addresses.
I came across the content here: https://en.bitcoin.it/wiki/List_of_address_prefixes, which does not contain information about Decimal, prefix Hex for Bech32 addresses (I guess they also called SegWit address, right?)
So, I checked this chart here:
https://en.bitcoin.it/w/images/en/4/48/Address_map.jpg but, I don't understand the meaning of "x03x03x00x02x03".

If x00 equal 0x00 in hex and x80 equal 0x80 in hex, how should I interpret x03x03x00x02x03?
What is the version prefix for Bech32 addresses (bc1 addresses)?

Those bytes (x03x03x00x02x03 or better shown as 0x0303000203) are the expanded human readable part. You can find the code on BIP-173.
def bech32_hrp_expand(s):
  return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]

The problem however is that unlike Base58 encoding, those bytes are only used in calculation of checksum not as the starting bytes. Which makes the picture misleading in my opinion.
Bech32 encoding is very different from Base58 encoding as there is no "version prefix". There is an Hrp, a witness version, a data (hash) and a checksum. Witness version | hash are the data being encoded and expanded_hrp | data is used in checksum calculation (| is concatination).


Where does the extended block in a segwit transaction get stored? I understand where normal blocks get stored. They’re passed along and saved by various nodes. What about the extended blocks of a segwit transaction.

This is defined in bip-0141:

  This BIP defines a new structure called a "witness" that is committed
  to blocks separately from the transaction merkle tree. This structure
  contains data required to check transaction validity but not required
  to determine transaction effects. In particular, scripts and
  signatures are moved into this new structure.

  The witness is committed in a tree that is nested into the block's
  existing merkle root via the coinbase transaction for the purpose of
  making this BIP soft fork compatible. A future hard fork can place
  this tree in its own branch.

This new structure represents the extended block which is attached to the merkle root of the coinbase.

If a full node doesn't understand SegWit format it won't be able to validate the transaction. But it can accept it as is, just like lightweight clients do.


How To Get a New Bitcoin Payment Address I have one bitcoin ewallet and this has one bitcoin payment address.  I have read we should change our bitcoin payment address frequently for security reasons.  How do we do that?

Most online wallets will create for you a new address each time you indicate that you want to receive a transaction, or give the option of creating a new address. Some enforce this by never showing an address twice and simply handle amalgamation  on the backend.

Creating a new address for each transaction is a fool-proof way of ensuring that someone has paid you, because you've given that address to only that person and no one else. There are also some privacy benefits, as using a new address makes it more difficult to trace the bitcoin trail.


Basic question about transaction verification I am fairly new to crypto and had some questions about how transactions are verified by the nodes
Would it be correct to say that the full nodes check to see if the sender(Alice’s) signature is valid. And they check against double spends by seeing if the hash value that is included (of the transaction where Alice received the bitcoin) has ever been used an another transaction?
My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?
Why can’t it just check against Alice’s other transactions since you know she controls that coin.

My question is, if that is the case, why can’t the verification only check against transactions signed by Alice, why does it have to check against the entire blockchain?

A node has no concept of who controls certain outputs. So there is no way to 'check all of Alice's outputs', how would the node be able to ascertain which outputs belong to her?
Rather, the normal operation of a node is to check all transactions, to ensure that no transaction has spent coins that were previously spent (and to check that new coins aren't being created against the network's rules, etc). In doing this check, the node creates an index of unspent transaction outputs (UTXOs), which it will use to help check validity of new transactions.


What is a "share rate"? What is a "share rate" one can find in a mining pool dashboard?

I understand what a hash-rate is, and how that applies to myself (miner), as well as to the pool or the network. I also understand to some degree what shares of a block being mined are. But what is then the shown share rate (shown as a value between 0 and 1, as well as in shares/s).

Depending on which pool your mining, this is usually representative of how many valid shares are being passed back to the pool.

It has been displayed in a decimal fraction it seems, so 0.985 would be an amount of 98.5% valid shares returned.


What are some potential scenarios that a state actor can harm bitcoin if they control more than 51% of the hashing power? As reported recently, China controls more than 51% of the hashing power and just in one province in China controls 54%. Assuming China has bad intentions and forces all these mining operators to collude to harm the Bitcoin network. What are some of the potential scenarios to dethrone bitcoin from the #1 spot?

From my understanding a 51% attack would just cause a loss of confidence, but wouldn't kill Bitcoin as the real chain will just fork off onto its own.

There may be a lot of miners in China, but the People's Republic of China do not control the mining power.

A 51% attack on Bitcoin may be theoretically possible, but it is definitely not feasible. Andreas Antonopoulos addressed this question and answers it better than I could. Here's a video of this Q&A: https://youtu.be/yWTQgmCuiCw?t=8


Could a Multi-Chain Bitcoin Help the issue of Scaling? This question falls under the heading of "shower thoughts" that are Generally discouraged in the bitcoin-dev list.
I hope this is the right forum.
I have been running my full node for a few weeks now and have been watching the number of transactions in the memory pool hover around 90K. I'm thinking this is only going to grow and yet we seem to have peaked at an average of 2.5k transactions per block.
I have read of various proposals (BIPs) to fix this but have not seen anyone suggest breaking up the chain into multiple chains.
Currently we have ONE BIG CHAIN that everyone mines...and all transactions go into it...all wallets addresses are contained...
But what if we take half of all addresses (say last digit odd or even) and create TWO Bitcoin chains...
Each chain would start out with:

Half the difficulty setting.
Half the mining reward.
And a special wallet address on each chain that contains all the bitcoins in the other chain. This wallet would not be able to have spends as normal. It would only be able to spend based on the workings on special rules.

Miners would split their mining across both chains. Difficulty would adjust independently as normal. Rewards would continue to halve as expected...however more transactions processed would mean more fee income per block. (Should take 2.5k peak transactions per block to 3.75k per pair of blocks to both chains)
Transactions will go to the chain for the source wallet address (odd or even)
Any transaction that is odd to odd will stay on that chain...This is the savings in mempool and number of transactions as it won't effect the other chain.
Any transactions from odd to even will generate a transaction to the Special Wallet on Odd chain and add a new transaction to Even chain from special wallet to final wallet. And vice versa on the other chain.
The trick here would be having rules for the special wallet so only transactions can be spent from it using the other chains confirmed transaction as Proof. Embedded in that transaction is the spend to address that generates the final transaction on the other chain.  Cross Chain transactions would be a bit slower as they would require a confirmation from 1st chain before adding a transaction to the mempool on second chain... And then the issue of if the first transaction on first chain got orphaned...how would you cancel transaction on second chain...but this is a far as I've gone...
If this works...you could split this up to 3 chains, four chains...etc...with rapidly diminishing returns.
Has anyone heard of this before? Thoughts? Comments?
Thank you for reading!
Ryan

No, I don't think that sharding is as simple or beneficial as portrayed here. Here are a few thoughts:

Splitting by addresses doesn't seem plausible. Most transactions have either multiple inputs or multiple recipients. It's not clear how transactions would be handled that attempt to spend funds from both chains or pay to both chains. If they need to be present on each chain, I don't think we'd get a significant traffic reduction on either chain. If they do get included on both sides, how do we ensure that they don't get confirmed on only one side? If they can only be included on one side, how do we coordinate that?
ETH has been working on Sharding since 2016(?), and as far as I can tell, it requires layers of mitigations and complexity, and comes with all sorts of trade-offs. ETH requires global state for each transaction's execution. By introducing sharding, ETH gets multithreaded validation. Bitcoin's transactions are inherently stateless, and its scalability concerns are related to total resource usage. Two shards of 0.5 MB blocks are no better than one chain with 1 MB blocks for that. Two shards with 0.5 MB blocks that have a storage footprint of 0.75 MB and coordination overhead sound like a step back.
It sounds like a complete consensus overhaul. It's unlikely that people would be comfortable to support such a proposal.

That said, we already have some sidechains and second layer solutions that we can offload transaction traffic to with far less overhead or critical changes.


When does miner insert the coinbase transaction? When a miner creates the candidate block with transactions from the mempool, does he insert the coinbase transaction after winning the PoW or during PoW?

If you add the coinbase transaction later, that will change the merkle root. If merkle root is changed, the block header is changed and hence the header hash you calculated earlier is no longer valid. This is why the coinbase transaction needs to be entered before you start calculating the hash of the header.


bitcoin volatility and transaction fees We know that the Bitcoin currency is volatile, but does the transaction fees correlate with it's volatility? Is it right to assert that if there is high level of Bitcoin demand, then the currency goes up, and then if the demand comes from a great amount of person, then the network size increases and so the transaction fees could be balanced by a greater availability of blockchain space, or am I going wrong ?

The logic behind the transaction fee in the bitcoin network is that the miners take  in consideration first the txs that have higher fees to be added to the blocks, those txs are taken from the mempool, the place where they should wait until miners decide to add them to a block to be validated.

For example:
If I perform a transaction that has a fee of 300 satoshis it will be first added in the mempool before it goes to a block; and let say, that some minutes later you perform a txs that has a fee of 30000 satoshis it will added  to mempool too, but the miners will consider first your tx because of its higher fee.

Taking that in consideration, when the bitcoin price get up, usually there are a lot of people performing txs and since the size of the blocks is only 1MB, where only can be attached about 2500 txs, much of those people prefer to pay higher fees so their txs could be added to the next block. That cause the mempool get full of transactions waiting to be added to a block.

According that explanation we can say the transaction fees is not directly correlated with the  volatility of bitcoin, it is more correlated with increase or decrease of quantity of transactions waiting in the mempool and the wish of people to get txs done asap. If there are many txs in the mempool people will be more tempted to pay more to get them done.


How long to get an accepted share? I am very new to bitcoin mining and am unsure if I set up GUIMiner correctly. I have a new MacBook Pro with a discrete graphics card (ATI Radeon R9 M370X) and am getting about 129 Mhash/s according to GUIMiner. However, it says "Shares: 0 accepted" in the bottom left side of the window. How long does it take for shares to accumulate? Did I set something up wrong? It has been running for about 3.5 hours.

Thanks!

The Bitcoin network has a global block difficulty. Valid blocks must
  have a hash below this target. Mining pools also have a pool-specific
  share difficulty setting a lower limit for shares.

ASIC hardware is required for profitable mining because the current difficulty is extremely high as a result of increased hashing power coming online. GPU mining is unable to compete with this specialized hardware. It is most likely the case that your GPU is unable to find any valid shares within the ~10 minute timeframe that occurs between discovery of new blocks.

See this response for more information


How to get the available balance of a specific address using blockchain.info? There seem to be two calls. What's the difference between them ? I basically want to know the total amount available to spend on each address(actually on the whole wallet but there is no such api call so I have to calculate the amount from all the addresses).

  Unspent outputs

https://blockchain.info/unspent?active=$address

  Multiple Addresses Allowed separated by "|"   Address can be base58
  or xpub

  Optional limit parameter to show n transactions e.g. &limit=50
  (Default: 250, Max: 1000)
      Optional confirmations parameter to limit the minimum confirmations e.g. &confirmations=6

  The tx hash is in reverse byte order. What this means is that in order
  to get the html transaction hash from the JSON tx hash for the
  following transaction, you need to decode the hex (using this site for
  example). This will produce a binary output, which you need to reverse
  (the last 8bits/1byte move to the front, second to last 8bits/1byte
  needs to be moved to second, etc.). Then once the reversed bytes are
  decoded, you will get the html transaction hash.

{
    "unspent_outputs":[
        {
            "tx_age":"1322659106",
            "tx_hash":"e6452a2cb71aa864aaa959e647e7a4726a22e640560f199f79b56b5502114c37",
            "tx_index":"12790219",
            "tx_output_n":"0",
            "script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac", (Hex encoded)
            "value":"5000661330"
        }
    ]
}

  Balance

  https://blockchain.info/balance?active=$address

Multiple Addresses Allowed separated by "|"
Address can be base58 or xpub

  List the balance summary of each address listed.

{
    "1MDUoxL1bGvMxhuoDYx6i11ePytECAk9QK": {
        "final_balance": 0,
        "n_tx": 0,
        "total_received": 0
    },
    "15EW3AMRm2yP6LEF5YKKLYwvphy3DmMqN6": {
        "final_balance": 0,
        "n_tx": 2,
        "total_received": 310630609
    }
}

Your question:

  How to get the available balance of a specific address using blockchain.info

The description for the /balance API:

  List the balance summary of each address listed.

So use /balance.

/unspent lists all the outputs for all addresses you provide in one big list, not grouped by address. But since you're just adding them all anyway, it doesn't make much difference for you. The /balance result is shorter and simpler.

  basically want to know the total amount available to spend on each address(actually on the whole wallet but there is no such api call

Have you checked the Wallet API? "Fetching the wallet balance" looks like what you need.


What actually happens in a basic DAO in ethereum? I've had a look at the white paper but I fail to understand exactly what is happening on the code shown on the page.

As far as I understand this example manages shareholders. But, is it possible to store organisation data somewhere? I (honestly) don't understand this.

That's a pretty general contract: As long as more than two thirds of the shareholders agree, you can change every single storage entry. This enables to add or remove shareholders, change the program itself (as it's part of the storage as well), and store arbitrary additional data.

To extend the description in the white paper a little, here's how a voting could look like:

1) One shareholder proposes a change of some storage bytes using the second transaction type ([1,k,L,v0,v1...vn]). k is a kind of ID to refer to this suggestion later, L is the first storage address that will be changed and v0, v1, ... is the data to store. As you can see, arbitrary changes of storage entries are allowed.

2) Now, the other shareholders can vote to implement the change with the first transaction type ([0,k], where k refers to the previously registered proposal). The number of votes in favor of this proposal is stored at a storage location given by the hash of k.

3) As soon as enough votes have been received, a shareholder can send the third transaction type to apply proposal k, i.e. write the data to the storage.


How to connect 2 wallets locally to each other? I remember somewhere I saw how to do it, but I can’t find
I want to run 2 wallets without nodes and connect them locally to each other.

Bitcoin Core supports addnode in the configuration which will add a dedicated outgoing peer to the defined IP address. connect will make a single outgoing connection to only that peer and nobody else.


Transfer between exchanges without fees What is the best way to transfer money between exchanges without fees? I think the most obvious option is to buy a redeemable coupon at one exchange, and redeem at another. But are there any exchanges who don't ask fees for this?

The best way to transfer between exchanges without fees is bitcoin.

Coupons (like mtgoxusd) used to be very nice, but now it seems fees are often charged in addition to some of the coupons becoming unreliable.

An arrangement in #bitcoin-otc may work well at a low fee, but -otc isn't often quick.

In consideration of these two facts, I've come to the conclusion that it's typically quick and cheap enough to convert to BTC and transfer that.


Balance not going up in deepbit after mining I've been mining with a deepbit account and noticed the balance hasn't been increasing. I use the following bat file to run cgminer version 3.5.0

cgminer.exe -o http://pit.deepbit.net:8332 -u emailme@gmail.com_one -p 123abc -I 10 -g 1 --auto-fan --queue 1 --temp-target 70 --gpu-engine 945 --gpu-memclock 275 --temp-overheat 80 --gpu-fan 75-85  -k diablo -v 2 -w 256

After upgrading to 3.5 when I press q to quit Windows gives me the error "Display driver stopped responding and has recovered".

Here's a screen shot of it working

What should I do to find out why it's not working?

Are you mining with proportional rewards or PPS?

If proportional then you get paid when a block is found. That can take several days at the size Deepbit is now. So things are most likely working, it just takes time.


Can someone help me understand what these scripts mean? Could someone explain what the commands i have in bold do? if possible. Thank you.

Transaction URL www.blockchain.com/btc/tx

Input Scripts-
ScriptSig: PUSHDATA(71)[3044022069f0c9da12ce7b002c68d25e4445191b149627987367fdec4e4b80e442379f3902202109994c46d8c6afd8e94542d07fa8a07da234f7537c4a1d639d2dcdd32f9c5b01] PUSHDATA(33)[03c26e5ff8c75d6272b2d9cd3a882c20315d440251deb79873b75b690d0b71f4cf]

Output Scripts-
DUP HASH160 PUSHDATA(20)[264cf7a09b68a436bafc4d7281743d7f1c721ded] EQUALVERIFY CHECKSIG
HASH160 PUSHDATA(20)[72cf56ba8b7312ae658debf033d88e4370b9a8f5] EQUAL

PUSHDATA(71): Pushes the next 71 bytes onto the top of stack
PUSHDATA(33): Pushes the next 33 bytes onto the top of stack
DUP: Pushes a duplicate of the top stack item onto the top of the stack
HASH160: Pop the top stack item off of the stack, hash it using SHA256 then that hash with RIPEMD160, and push the resulting hash to the top of the stack
PUSHDATA(20): Push the next 20 bytes onto the top of the stack
EQUALVERIFY: Check that the top two stack items are equal. If they are, do nothing. If they are not, immediately fail execution
CHECKSIG:Pop the top stack item and interpret it as a public key. Pop the next stack item and interpret it as a signature. Check that the signature verifies to that public key when the message that is signed is a modified version of the transaction containing the signature. If the signature is valid, push OP_TRUE to the top of the stack. If it is false, push OP_FALSE to the top of the stack.

A full description of all script opcodes and their actual byte values can be found on the Bitcoin wiki.


How come some addresses show up in search results while others don't? Some Bitcoin wallet addresses can be found by google, but some others shows no result. For example, this wallet is visible on many Bitcoin websites and google has a lot of results 1ENFY4h7ntGZbqwcwpQtXVFJrPnfXRHQLe and we can see its transactions. But this other address 126kUxBmdLTk4M7w1uaQ2pjAhm9KbZ6dxp (a ransom-ware wallet!) has no result. How it is possible? How can people do this?

The latter address does not show up in google because it has not been used for a transaction yet. Once someone sends money to it, it will show up.

It's possible that we'll be able to create systems in the future that don't have this problem, but don't hold your breath.


What sort of calculations do the miners have your computer do? I recently heard of a new cryptocurrency (or maybe it's not new and I'm just out of the loop) called Gridcoin which uses your GPU/CPU/ASIC to do research calculations rather than "meaningless" calculations.

I had previously thought that Bitcoin miners have your computer do calculations required to process Bitcoin transfers, and then takes a little bit off the top as payment for doing the calculation. If that's true, then why do all the Gridcoin articles say that the calculations are useless?

I'm trying to understand the actual details behind Bitcoin further, and there's very little information out there that's accessible to the layman.

What does the miner have my computer do when I'm mining? And why weren't "more useful" cryptocurrencies such as Gridcoin developed earlier? Why does the system reward you for meaningless calculations, and how is that sustainable?

The calculations are fairly meaningless, it's a pot luck type process so that it is fair for all. They aren't /useless/ though - because they are what power the vast and incredibly secure Bitcoin network.

Edit (elaboration):
Bitcoin hashing is sha256(sha256()) (i.e. sha256 twice.. just for extra protection from sha256 attacks)..  the input to the sha256 algorithm contains various data that identifies the "solution" to the next block.. so it'll have data like the previous block hash, a timestamp, and a hash for transactions included in the block.

If a miner finds a valid solution then the node verifies and accepts it and broadcasts it to other nodes. If enough nodes receive and verify this solution then it becomes a block and all miners move on to the next block solution. Because mining is random there is no historical data lost when someone else finds a block - every miner has the same chance (proportional to their hash rate of course) - they just repeat sha256(sha256()) over and over. In order for a solution to be valid it must fit all previous blocks and must be a number low enough (defined by the current network "difficulty" level).


Lightning Network scaling alternatives? I'm really looking forward to the Lightning Network and all the efforts being put in by Blockchain.info, Blockstream, and others. But I was wondering if there aren't other options for decentralised scaling besides LN?

In particular, are there are other decentralised+offchain scaling models that have been suggested beside hub-and-spoke?

The obvious one would be side chains, the idea being that the transactions on the side chain would be off the main chain. Most other scaling solutions are either on-chain or centralized. For example, segwit and block size increases are on-chain and using a service like coinbase to move coins off-chain are clearly centralized.


What is the age of the oldest known Bitcoin core developer? I am trying to compile some demographic data on who has contributed to Bitcoin so far and track how the demographics are changing over time.

Since GitHut does not show me demographic data I have attempted to use Google with limited success.

What is the age of the oldest known Bitcoin person to submit a pull request to Bitcoin core? I asked the same question about the youngest person the other day and the answers were helpful to me.

Eventually I want to try to compare the mean and median ages (and sex) of users and developers and track the changing demographic trends of each group.

I am unsure of how old these core developers, but 2 that come to mind are Gavin Andresen and Mike Hearn. Hearn left recently  due to personal conflicts. (story here)


what is the difference between a private pool or solo mining I would like to understand if there is a difference in resolving blocks with a private pool and solo mining, I understand that when solo mining you are given a block to resolve but within your private pool you may resolve various, this of course having several machines.

There's no technical difference in generating blocks in pooling vs. solo mining. The only difference is that pool mining can create a more steady pay flow.

Why do people do pooled mining?

Bitcoin's difficulty can give unrealistic time frames for payout. The average computer will mine a single block in 1000+ years at current difficulty. But say I got into a pool with the average computer, I'd get a payed proportionally to the amount of work I contributed to a block being found. Although my "work contributed" may not end up being a block, it had a chance proportional to my own hash rate. In the end I'd get payed a few satoshis daily as opposed to getting the block reward (25 BTC at the moment) at some random point in the future likely to be no later than 1000+ years from now.

Why do people do solo mining?

The main reason is because they can. Certain miners have enough hash rate to get blocks in a reasonable time span. If I had a 1/144th the hash rate of the Bitcoin network I'd statistically have a 100% chance of finding a block of 25 BTC within 24 hours. There's no benefit for large miners to do pooled mining, may even hurt them because of fees.

Pooled vs. solo mining will theoretically yield the same amount of coins if difficulty and block reward never changed and you solo mined long enough. Although you should consider pooled mining if you aren't mining with a rack of gear.


Recovering a Ripple wallet on Ledger Nano I have 20 XRP in a Ledger Nano and before I load everything onto it I want to test the recovery procedure so I am prepared in case something goes wrong down the track

I have read the material here on the Ledger documentation but it does not elaborate on how it recovers the keys for the apps you have installed - in this case XRP.

Ideally I would also like to generate my public and private keys as described here and store them somewhere safe - but again it does not elaborate on the keys for altcoins.

Thanks in advance on any guidance!

Ledger should recover all your funds including any altcoins like XRP from your 24-word recovery phrase. You may read technical details about the process in BIP44.

I'm not sure whether there is an official Ledger tool for deriving keys for XPR from recovery phrase. You may use Ian Coleman's BIP39 Mnemonic Code Converter. It is possible to launch this site on the offline computer if you worry about keyloggers.

You may also find this discussion on Reddit interesting.


Send and Received BITCOIN I have been working on Ethereum for years. Now assigned to work on Bitcoin. The way that BTC handle transaction is vastly different and utterly complicated.
After reading for quite sometime. Can I assume that for a simple website to receive and send bitcoin, I only need to handle the scenarios below:

Coin only. No colors, no assets.

Receive coin using P2PK and / or P2PKH only?

For sending I can always stay with P2PK or P2PKH is that correct?

Are the above sufficient for me to handle coins sent to my website and subsequently transfer to another account?

Coin only. No colors, no assets.

Yes, the bitcoin baselayer facilitates payments. You will find however, that Bitcoin on-chain payments are not cost efficient for micropayments as fees would eat large portions of the received funds.

Receive coin using P2PK and / or P2PKH only?

There is no address standard for P2PK, so receiving to P2PK is not trivial at all. You could use P2PKH, but it is more than twice as expensive as more modern address formats. I would suggest to go with P2WPKH instead.

For sending I can always stay with P2PK or P2PKH is that correct?

Yes, inputs must satisfy the locking script the output used which is defined by the address the receiver chose. If you receive funds to a P2PKH address, you have to spend them as a P2PKH input. I'd say receiving is easier, since it only requires deriving a new private key and the corresponding address, then polling whether the address got paid. Sending on the other hand requires you to estimate an appropriate feerate, select inputs to fund the transaction,  support a number of different output formats for compatibility, produce the correct signatures, build the transaction, and submit the transaction to the network.
You don't have to reinvent the wheel. There are libraries that will solve most of these issues out of the box, or you can set yourself up with a BTCPayServer which solves all of the above and enables you to send and receive Lightning Network payments.


What data structure should I use to model a Blockchain I'm working on a functional mini-Blockchain implementation in Scala. I've given this a lot of thought but still can't comprehend the most suitable data structure to model a Blockchain. Specifically :-

1.) It can't be a simple Linked list/Stack, because there are forks , which means that two different blocks can refer to the same Block.Should it be a List of top blocks , i.e. a list of topmost(heightwise) blocks ? I can then traverse the blockchain by starting my traversal from either of the topmost blocks.

2.) How do I make a block point to the previous block ? I know that every block has the hash of the previous block. But how is that enough for me to go from a block to the block it refers to in my blockchain data structure ?

Would really appreciate any help I can get.

First, a blockchain is it's own data structure.  It's best to think of it as one.  It represents a way to organize data in which desirable properties are gained.  However, that still does not explain how to hold one in memory/storage.

In Bitcoin, the blockchain is stored on disk (not memory) using leveldb.  This is a key/value database where the keys are the block hashes and the values are the blocks.

For an in-memory equivalent, a hash map is what you are looking for.  This is a data structure where the key is a hash of the contents (such as a block header).  From there, the header's Merkel root would point to another hash map of transactions arranged in a Merkle tree (as per the protocol).

However, an in-memory solution (which seems to be what you are after) is a terrible solution for a blockchain.  The data simply grows too quickly.  You will want to store the data to disk and have a fast way to query it.  This is why Bitcoin uses an existing database such as leveldb.


From the Whitepaper: Timestamps prove that the data must have existed at the time" The whitepaper says exactly this: "The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.  Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it."

It seems to me that you could put any time you want in the timestamp. Is it the next sentence about "reinforcing" that is key to his meaning?

It seems to me that you could put any time you want in the timestamp.

No, there are specific rules:

  A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you. As a result, block timestamps are not exactly accurate, and they do not even need to be in order. Block times are accurate only to within an hour or two.

Example:
It's December 29th, 2017 at 11:00:00. The median for the previous 11 blocks is the current time - ~1 hour in average. Let's assume that it's exactly 1 hour in this case.

December 29th, 2017 at 13:00:00 is not accepted
December 29th, 2017 at 12:59:59 is accepted
December 29th, 2017 at 9:59:59 is not accepted
December 29th, 2017 at 10:00:01 is accepted


Hardware Bitcoins (Smartcards, RFID etc.) is it possible to create a real hardware Bitcoin, e.g. a specified (and verifiable) value which is stored on a smart card or RFID which can be given directly to other people?

It's certainly possible. The card would basically need four functions: add/generate account, add bitcoins, prove bitcoins, spend bitcoins. The card could piggyback on external smart systems so the card doesn't need to do very much.

Each function would be implemented as follows:

Add Account: An ECDSA private key would either be randomly generated by the card or loaded from an external source. The card would add the key to its store of keys. This would be a secure operation that would require the card's internal key to perform.

Add Bitcoins: A list of transaction identifiers and output indexes would be loaded into the card. This would also be a secure operation.

Prove Bitcoins: This operation would prove the ability of the card holder to spend a particular number of Bitcoins. An external device specifies a number of Bitcoins to prove. If desired, approval is sought from the card holder via a PIN or similar mechanism. The card then forms a transaction to pay that number of Bitcoins but damages it so the transaction is invalid (for example, it adds a single transaction input for a billion Bitcoins). Then it signs it. The recipient, seeing the invalid transaction signed knows the card holder could have signed the corresponding valid transaction. (If desired, a challenge can be included to prove the signed transaction was generated on the spot.)

Spend Bitcoins: This is the same as the prove Bitcoins operation except the transaction is valid, the recipient commits the transaction to the block chain, and the card updates its memory to reflect that the coins are spent.

The only other thing you might need is a 'sync' operation where the card fixes any discrepancies. For example, if a spend operation is done but for some reason it doesn't make it into the block chain, the card needs to know that it still holds those Bitcoins. (And can't spend the 'change' from that transaction.)

This is a minimal implementation. You can certainly add more capabilities.


Is it possible that a virus could be included in the block chain or even spread out to computers as miners are trying to mine? I'm new to BitCoin and curious about a lot of things about it, and about the mining network. So is it safe for everyone to mine and not get their PC or other machines get hit by a virus if it goes along the transfer of information? How safe are we from this scenario as users?

Ideally it is safe, the data transferred in bitcoin protocol is never meant to be executed. However:

The transactions themself are programs. While they are limited and cannot directly affect your computer, they can be just very computationally expensive, DoSing your PC. This attack is impossible now and in foreseeable future, since any non-standard transaction will not be evaluated.
Not virus, but it is possible to include arbitrary text messages inside blockchain. Therefore, one can include something that is illegal in some jurisdiction, potentially making bitcoin illegal as well, since blockchain can not be retroactively redacted. However, it is dubious whether such trick will actually work (1, 2). But there was some commotion about including catholic prayers in block headers.
There might be some bugs in bitcoin software (be it client or miner), just like in any other software. For example, it is possible to crash a computer by sending specially formed ping or execute code by sending packets to a closed network port. This applies to all software and is not bitcoin-specific.


What SIGHASH flags does CoinJoin use? What SIGHASH flags are used when constructing a CoinJoin transaction?

CoinJoin uses SIGHASH_ALL.

I initially found this confusing because I assumed the interface to CoinJoin a little less synchronized than it is. CoinJoin requires each participant to first specify a UTXO and a public key to pay out to.

Someone then constructs a partially complete transaction which makes use of those UTXOs and pays out to the public keys specified by the participants -- this transaction is "partially complete" because it doesn't yet have signatures which unencumber the UTXOs. Each participant then signs their input with SIGHASH_ALL, which prevents outputs from being manipulated after the fact.


Fees for transfering money by bitcoins and banks When I send money to someone using the bitcoin network, I have to pay fees for converting my dollers to bitcoins in an exchange market, then I have to pay the miner fees then the Wallet fees to receiving my bitcoins and the Wallet fees to sending the bitcoins to the other person.
Why do people say that using the bitcoin network in transfering money is less fees than banks?

I for sure cannot answer, why other people say, that transferring money with bitcoin has less fees. Your picture is correct, everywhere are fees.

For specific cases, fees might be lower than bank transfers. I usually send money to Africa. I was doing it with banks, with WE and Moneygram, and with bitcoins. With bitcoins the advantage is, that the fees are independant of the amount. So I can send the equivalent of 1 mio Euros in bitcoin to Africa, and pay just the transaction fee. Try this with the 7 or 8% fees of the best banks or money transfer agencies. You will never ever end up at 5 Euros tx fee. So in these cases, bitcoin is far cheaper than traditional, old-style money transfers.


is bfgminer running correctly? As a complete newbie I purchased USB ASIC mining device, installed bfgminer on raspberry pi and tried to run it. As the reward is not changing, I am wondering whether bfgminer is running correctly.

This is the snapshot of bfgminer:

And this is the snapshot of workers status in Slush's pool:

I would be very thankful if anyone could tell whether this is working correctly or how to check in general if everything is OK.

When i look at the snapshot it seems like your device isn't hashing. Did you have your device hashing? and did you get the USB TO UART DRIVER BY SILICONE LABS? respond when you have the answers.


How to broadcast a non standard transaction? How can i broadcast a non standard transaction?

I tried using the core client, coinb, blockchain.info, luke-jr's test release as well as pushing it to eligius but it doesn't work.

You generally don't - there are likely to few nodes on the network that will forward it far enough to reach a miner.

What you can do is find a miner yourself, contact them, and see what mechanism they offer to include your transaction (perhaps for a fee). In this case, the transaction will not propagate through the network directly; only as part of the block after mining.


CPU Solo Mining on ARM I am playing around with bitcoin mining. I have set up a full node on an ODroid C2 device. I am running Ubuntu 16.04 and Bitcoin core. That seems to be running find. It is keeping up with the block chain with no errors.

I downloaded the cpuminer source and built it without errors.

When I run it it starts up the 4 mining threads, but always gives and error that the host returned a 404 error.

I have the rpc set up and am using the correct username and password.

I am using the default ip address for localhost and the default port of 8882.

Can someone explain what I have done wrong that minerd won't connect to the local bitcoin node?

The ability to solo mine was removed some time ago. You have to set up a stratum proxy server.


Can I save stuck bitcoins by creating a completely new transaction? I tried to make a bitcoin payment but accidently set a too low transaction fee so it got stuck. By now the payment is cancelled so I don't want to do this transaction anymore.

Can I now instruct my bitcoin adress to send the bitcoins somewhere else (instead of the stuck transaction) by broadcasting a completely new transaction? I used Bitcoin Core for the initial transaction.

P.S. Nobodys waiting anymore for the initial paymant so I'm not trying to scam anyone here.

Of course you can do it as long as the previous transaction does not get confirmed.


Is there an efficient and secure way to transmit bitcoins over shortwave radio? This experiment by CBC that used chirp over the radio to transmit a wallet seed tickled my interest. Of course this isn't secure. And it's also inconvenient to create the wallet from the seed. What's a better way to do this in a practical way? Chirp is very accessible and convenient. Shortwave radio has a decent range, some distance over the sea.

Although I am not qualified enough to suggest a protocol for over-the-air, I can still get some technical pointers. You may want to ask at the ham radio SE community.

Yes you can easily send Bitcoins over shortwave radio using encryption but radio encryption is not a topic of this community. It's also severely illegal in the U.S. for a HAM operator to use any kind of encryption when transmitting.

The Bitcoin network over-the-air

This is what I think you are asking, the Bitcoin protocol does not send private keys of bitcoins around as its main technique as this is risky and dangerous inherently. The Bitcoin protocol moves bitcoin without the need to exchange private keys of any bitcoin so it be better to just implement the network over radio.

Bitcoin can practically be agnostic to the protocol you are using, as long as communication is possible Bitcoin will work. There are many protocols for shortwave radio available that can move data from a transmitter to a receiver. As an interesting example, you could totally set up a node that communicated via Morse code as long as it has other nodes to talk to. You'd run into problems with bandwidth as some tx/rx modes are slow. You can possibly use a modified version of Bitcoin-qt and use the same handshakes and messaging it does over tcp/ip.

The HAM radio community has interesting an P2P by itself which you can look into. APRS is a packet-based network which relies on peers to rebroadcast messages, it's really cool and is readily documented and has many tutorials.


Bitcoin Full Node + Lightning running on single-board-computer, possible? I know similar questions (regarding a Bitcoin Full Node) were already asked here, but they date all back to 2014 and I think especially the space needed by the blockchain changed a lot since then.

I am thinking of buying a single-board-computer to turn it into 24/7 online bitcoin full node + a lightning node. I want a single-board-computer to reduce the energy consumption, since it is running 24/7. My question is now what single-board-computer I should buy and how well that works. I read a lot about Raspberry Pi 3 and that its not working very well so I think of buying something more powerful.

At the moment I am thinking of a Banana Pi M3 or an ODROID-XU4.

Did someone already try something like this with another single-board-computer than the Raspberry Pi 3?

Please take a look at pine64.org. They have the Rock64, which has a quad-core A53 ARM 64-bit CPU; up to 4GB RAM. And I have heard they will release a new model with a hex-core CPU soon as well. I have used the Pine64 (original 2GB model) for simple Linux experimentation; installed Ubuntu on it, etc. Have not tried Rock64 yet, but am planning to.

The ODROID XU4 may work well too, although I have found with my VPS full nodes, that 4GB of RAM is helpful... see: http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825


destination_tag best practices when integrating Ripple I'm integrating Ripple with a commerce system, to accept payments to a Ripple wallet.

My understanding is that the destination_tag, an integer, is the only data I can use to track a transaction.  I can specify the destination_tag when I send the user to their wallet, and it will be tracked in the ledger.

If I'm correct this is the only parameter, I'm worried about conflicting destination tags.

Am I correct that if a wallet is being used with my system, it can't be used with any other, as they might use the same destination tag?

When a user of my system specifies their ripple account (wallet), am I expected to query the ledger for all past transactions to that wallet and, if any, throw an error that the same wallet can't be used with two payment systems?

Do I have to store not only the account id, but also the ledger sequence when my system learned the account id, so that I only search for transaction ids after that ledger sequence?

I will make my answer a little longer than necesary and mention some things you obviously already know in the hopes that the expanded answer will be useful to others as well:

The destination tag should be something that allows the receiving account to perform things like implement "for further credit to..." or to determine which invoice (or other event) a transaction corresponds to without knowing the payer's Ripple address before the payment is made.

As such, it's only meaningful for the receiving wallet. When someone wants to pay using Ripple, you would tell them something along the lines of:

  Send payment to
  rrrrrrrrrrrrrrrrrrrrBZbvji
  and use destination tag 1313426242

In other words, the destination tag is something that you must create and give to the user, who will then use it when making the payment.

So how to choose a destination tag? Well, there are many ways. Here are a few options:

Just give out an incrementing number, so the first transaction gets tag 1, the second tag 2, etc.
Use the invoice number generated by the commerce system you are integrating with.

You can read more destination tags and requiring them at the Ripple Wiki.

Now, your question is what to do about conflicting destination tags. Obviously if you're the only one generating tags for a wallet, then you don't have to worry about that - simply don't generate conflicting tags.

My personal recommendation is to require/mandate that a vendor create a new  Ripple wallet, to be used exclusively by your system. This is certainly not unrealistic. In fact, it's a good idea™.


What's to stop someone from making a ton of mining nodes as an attack method? My understanding is that if two miners make a block by completing a hash at the same time, it is then up to the miners to decide which is going to be 'accepted' by vote of which block reaches 51% of the votes first.

What's to stop someone from making a ton of nodes just so that they can get an advantage if this situation arises for himself? (Another node finished a block at about the same time as me, so I unleash my army of nodes to all vote for the block that I made)

When two blocks are found at the same height, only one can ultimately become part of the chain with the most total work. Miners do 'vote' which of the blocks to accept, however this is not by casting a ballot, but by producing a succeeding block and thus making one of the two chains longer than the other. Miners thus vote with their hashpower by trying to extend one or the other chain-tip.

Thus the "attack" you describe is impractical: if miners only used their expensive mining hardware solely to decide chain splits, they'd be losing out on a lot of revenue. Instead, they mine all the time to find as many blocks as possible.

Also see:

Why doesn't the same miner always win?
How much would it cost to execute a 51% attack?