text:
Watching and spending from a huge number of offline private keys
We plan to accept bitcoins on our eshop website. What we want plan on doing is:
1) Keep all private keys always offline (cold storage).
2) Generate at least 100,000 keypairs of which only one will be stored on our web server.
3) Frequently change our Bitcoin addresses on our webserver to prevent third parties from knowing how many Bitcoins we have received in total. The web server will only contain our public key (Bitcoin addreses), not any of the private keys.
Now my questions are:
I) Is there a way to monitor the SUM of all bitcoins sent to ALL of our addresses?
Something like a wallet that supports import of a huge number of "watch-only" addresses without requiring the import of the private keys? If the wallet is an application, it must support SOCKS proxy connections. (Armory allows watch-only keys, but I don't know if it supports mass bulk import and SOCKS proxies? Also, it seems to be suffering severe RAM overuse bugs as of now, according to its developer...).
II) Is there a way to sell the SUM of all bitcoins ever sent to ALL of our addresses AT ONCE?
III) Will an attacker be able to find out how many bitcoins we have earned in total?
Thanks!

Is there a way to sell the SUM of all bitcoins ever sent to ALL of our addresses AT ONCE? This seems like an unrelated question. I think you might want to ask it separately.

Direct answers to your questions:
I) Technically this is not too difficult. Looping through every new transaction on each received new block does not take too many resources and checking each transaction against 100,000 public keys is no problem at all. However, I do not know of a tool that would do exactly so. (For example, blockparser can output all the balances of all the addresses in the entire block chain in under a minute.)
II) No. You can not transfer all the received bitcoins in one transaction as the maximum size for a transaction is 1 megabyte. That would be able to spend the money on, say, 4000 different addresses at once, but no more. Of course, you can give all the private keys to somebody else "all at once", which enables them to spend the coins - but such a party would be unlikely to accept the sale as successful before transferring all the coins in to new addresses, just in case you kept the private keys as well.
III) No, if you keep the attacker from learning all the public keys. If, for example, the public key currently on the web server is easily viewable, the attacker can just poll your website, note down all the public keys seen and then check all the transactions for the keys. However, if you reveal the public keys only to legitimate buyers (or something) or do not reuse keys ever, the attacker has no way of knowing the full set of keys that belong to you. This also requires some care on the spending side of the coins - if you do a transaction that links the coins to your site somehow, this can be observed.
However, there are some more advanced methods of using bitcoin public keys that will achieve more than what you have asked here. You can see for example Hierarchical Deterministic Wallets. The choices are numerous and the best way to achieve your goals might not be the most obvious one.

In order for your server to monitor all the addresses, you'll need to have all of them on the server which contravenes your requirement that a hacker not be able to see your combined balance.
With that in mind, as far as I see it you have two options:
1) Use a desktop app. Armory, QT, etc - though I'm not sure how well they would cope with 1M+ addresses or keys, and I'm 75% sure they don't have a bulk import.
2) Use another server - hosted or even in your home network (Raspberry Pi anyone?) that knows all of your public keys but is completely separated from your frontend server. It can then use a Bitcoin API (Blockchain, BTCBalance.net, blockexplorer) and periodically work its way through all 1M keys checking their balance. From within your network (this is ideal as very low chance of external access without being on site) you can call up the server and it'll tell you how many Bitcoins you have in total at your last count. I currently have a Raspberry Pi setup to do similar repetitive operations (though with backups not Bitcoin) and it does a fantastic job.
You would also likely be able to route option 2) through a proxy.

Thanks but none of the answers helped me. 1) Using an external server for bitcoin API exposes us to the attack as those services can aggregate our requests and see how much we earn. 2) I also asked if there is a way to SELL (or at least transfer to another bitcoin address) the sum of all bitcoins from all the private keys. You say "Use Armory but not sure if it does what you want"... Thanks but my questions are not really answered.

That's why I suggested using something inside your own network, like a Raspberry Pi. You could use different APIs if you are worried about them aggregating how much money you have,


text:
What are the limits of m and n in m-of-n multisig addresses?
This method describes how to create a 2-of-3 multisig.
I heard that there is an inherent limit with the number of multisig parts, limiting them to 3.
Does the standard method described above of generating and spending multisig addresses work with more than 3 parts? What is the limit? How to work around that and create/spend larger multisigs using bitcoind (practical 'how to' would be appreciated)

This post includes a step by step tutorial for how to create and spend a multisig address.https://bitcoin.stackexchange.com/questions/6100/how-will-multisig-addresses-work

We need to distinguish the limitations for validity and standardness. The first is determined by the consensus rules (which cannot change without a hard fork). The second ones are determined by local relay and mining policies implemented in the reference client, and can change from version to version.
In addition, we need to distinguish raw multisig (a simple OP_CHECKMULTISIG based script), and P2SH multisig (where the OP_CHECKMULTISIG script is only revealed upon spending).
Finally, because scripts include public keys, their sizes depend on their lengths. Both compressed (33 bytes) and uncompressed (65 bytes) keys exist, depending on which version of a wallet was used to generate them.
Raw multisig
Every m-of-n combination is valid (up to n=20), but standardness rules only allow up to n=3.
This limitation is enforced when sending (i.e., sending to a 2-of-4 multisig will not be considered standard).
P2SH multisig
validity rules require that the P2SH redeem script is at most 520 bytes. As the redeem script is [m pubkey1 pubkey2 ... n OP_CHECKMULTISIG], it follows that the length of all public keys together plus the number of public keys must not be over 517.

For compressed public keys, this means up to n=15
For uncompressed ones, up to n=7.

For standardness, it depends on the version. Up to v0.9.*, the reference client required the total spending script to be at most 500 bytes.

For compressed keys, this means m*73 + n*34 <= 496 (up to 1-of-12, 2-of-10, 3-of-8 or 4-of-6).
For uncompressed keys, this means m*73 + n*66 <= 496 (up to 1-of-6, 2-of-5, 3-of-4).

In 0.10, these standardness rules will likely be relaxed, allowing to go up to the validity limits (15-of-15 for compressed keys, 7-of-7 for uncompressed keys).
Also, for P2SH, standardness and validity restrictions are only applied when spending (as the spending script is only revealed at that time). This may mean that sending your coins to a P2SH script may make them irrecoverably lost (especially when violating a validity rule).

from 0-of-0 upto 20-of-20
https://blockchain.info/tx/970b435253b69cde8207b3245d7723bb24861fd7ab3cfe361f45ae8de085ac52
is 0-of-0 p2sh redeemption
https://blockchain.info/tx/da738e29f64e90ae46dcc3e6b4154041d6324abbe7919e722d486a4a3148b7dc
if 20-of-20 bare multisig redeemption
https://blockchain.info/tx/552026dade1c9385e4693a4e82f07080d8d1950fc822346f95a0dc1e0a833465
is 15-of-15 p2sh redeemption

https://blockchain.info/tx/56214420a7c4dcc4832944298d169a75e93acf9721f00656b2ee0e4d194f9970 is relevant too.

I recently implemented multi-sig outputs for Dartcoin, using the BitcoinJ implementation as a reference.
It seems that the reference client has a maximum of 3 keys for multisig transactions. However, the actual limit is 16. This limit is not arbitrary (like the 3 key limit is), but is due to the hard limit of the script limit.
Using more than 3 keys works exactly the same as with 3 keys. As you can see in the code, the output just consists of the number of keys you provide (n) and the threshold for spending (m).

When using P2SH (which the OP is, given the linked method), there is no limit of 3 keys. This is only enforced for raw multisig.

What's the limit when you create a P2SH multisig address? I guess it depends on the size of the input you need to create to spend it.

So, which method does this use, P2SH or raw? https://bitcoin.stackexchange.com/questions/3712/how-can-i-create-a-multi-signature-2-of-3-transaction/10593#10593

P2SH. Whenever there is a notion of a "multisig address", you know it is P2SH.

We've tested p2sh multisigs up to 8-of-15. Above 15, bitcoind caused problems.
You can review our code here, to see how it's done:
https://github.com/orisi/orisi
There's also a project discussion here, with some interesting tidbits:
https://bitcointalk.org/index.php?topic=645589.0
Currently the problem is that anything above 3 of 3 exceeds the standard transaction size and we have to push it through Eligius pool. But from people said in the thread, there is a way to compress the keys and make even 8 of 15 st

As per the below article by Vitalik Buterin, theoretically, you can have one-of-three, five-of-five, or six-of-eleven multisig addresses, it just happens that two-of-three is the most useful combination.
http://bitcoinmagazine.com/11108/multisig-future-bitcoin/

He gave those as arbitrary examples, he didn't mean those are the only possible options...

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
What are the problems with naive pool sharing mechanisms?
@David's comment on this answer suggests that naive approaches to mining pool management don't work. What attacks are possible on such naive approaches, such as every miner gets a share proportional to his work?

This paper offers a more complete analysis.

The primary problem is an "attack" of sorts referred to as "Pool Hopping." Pool hopping was first described in a paper by Bitcoin forum member Raulo and between the paper and the ensuing discussion, it was determined that there is a strategy by which pools utilizing a proportional payout method can be exploited to maximize the miner's payout at the expense of other miners in the pool.
The attack works something like this:

If the number of shares submitted to a pool are less than or equal to 43% of the current difficulty, the miner mines at this pool.
If another pool has a lower share count, the miner switches to that pool instead
If no pools in the miner's list are at or below the 43% mark, the miner switches to a pool with a fair payout system as backup.

The math for why this works is well described in the paper I've linked, but the basic concept is this: If I submit one share and it's the only share in the pool so far and it just so happens to be the share that solves the block, my share was worth 50 BTC to me. If my share is one of two, it was worth 25 BTC and so on. Shares submitted in "short rounds" (i.e. rounds that take n < difficulty shares to solve) are worth more each than those in "long rounds" (n > difficulty shares). If a miner stays at a pool for a long time, the long and short rounds even out. Pool hopping ensures that you're always part of those "short rounds."
The full explanation is somewhat more complex, but that's a fairly basic explanation. 43% was chosen due to the math explained in Raulo's paper and there are a few scripts and applications to automate the pool hopping process, some free and some commercial.
There is rampant argument about the ethics of pool hopping, but there is little argument as to its effectiveness. Even hopping between a single proportional pool and a fair-scored backup pool sees substantial earnings increases. Hopping between multiple vulnerable pools increases gains dramatically.

"Hopping between multiple vulnerable pools effectively multiplies these gains by the number of available pools" - That's not literally true. The potential rewards asymptotically scale as the logarithm of the number of pools (but, in the limit of few continuous miners, scales as the hashrate of the continuous miners).

Modified my wording. I think my insecurity over that last sentence was actually what sparked my Pool Hopping Math question, which you answered so excellently. I seem to have forgotten to change my wording here :)

The problem isn't with giving every miner a share proportional to his work - this is the ideal, and the problem is how to give every miner a share proportional to his work. By itself this isn't an unambiguous specification of how rewards are given. Two reasonable interpretations are:

Split each block's reward according to the number of shares submitted since the last block. This is the proportional system which suffers from the pool-hopping problem.
Give each miner a reward directly proportional to the number of shares submitted, regardless of blocks found. This is the PPS system, which puts the operator in a lot of risk so it only makes sense if he charges a high fee. In the future, though, the infrastructure will exist to reduce the operator's risk and thus allowing PPS with a modest fee.

The different reward systems try to offer the ideal of fair payments while minimizing variance, maturity time, vulnerability and so on. Summary of mining pool reward systems and Analysis of Bitcoin pooled mining reward systems analyze the different methods and the background for their necessity.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Is the alert system still in the main client's code? Will it be removed?
It is said that Satoshi removed the alert system from the client ... still, there are at least some leftovers in.
Is the alert system functioning in 0.3.24? Are there plans to remove all traces of it?
See also this answer.

Satoshi didn't remove the alert system; it still exists in the client. However, it cannot trigger RPC safe mode as it could before.
There are no plans to remove all traces of it, as all it does in its current state is display a warning message.

Citation please.

main.cpp:  else if (strCommand == "alert") when processing network messages.  And see the ProcessAlert() method in that file.

So to disable the alert system we'd literally just have to remove/comment out one elseif block? Just glancing at the code I don't see where it would break anything (well other than the thing we're intentionally trying to break). I'll gladly fork, modify and submit a pull request myself if it'll start the conversation among the real devs... I legitimately think this feature needs to go away ASAP.


text:
How do I find the hash "market share" of P2Pool?
P2Pool is a peer to peer mining pool, offering some advantages over centralized pools:

There is no central node to take down (assuming the pool is indeed fully decentralized). Pools have suffered from DDOS attacks in the past.
An open source P2P pool should theoretically be able to operate with zero fees.

How can I find out how many people are using P2Pool?

As currently phrased, this is fairly localised in time.  What's the enduring question here?

@eMansipater - "How should I talk to a database in Java" is also time-dependent, but that doesn't mean it's not a good question. I'd like to know the answer now - and if it change, let's change the accepted answer.

"Is X being adopted?" changes monthly if not daily.  Talking to a database in Java, not so much (but that's still not an amazing question for SO.  Much better would be "How should I talk to a database in Java in the following situation?" or "Which ways of talking to a database in Java meet the following criteria?" etc.)

@eMansipater - perhaps "How do I find the hash 'market share' of P2Pool?"

Much better imo.

You can find a graph showing the hash rate of the pool over time here: http://forre.st:9332/graphs/ (or at http://localhost:9332/graphs/ if you're running p2pool on your own machine).

In concept, P2Pool is much stronger than centralized pools. Unfortunately, most centralized pools still hold a high hash-rate.
You can see the global hash rate, and its distribution at http://bitcoinwatch.com/
My opinion is that miners are used to using slush, deep bit, and btcguild - and are either unaware of the incentives of P2Pool, or don't care.

Is P2Pool cheaper than other pools? Can it be?

The largest reason miners use the "big 3" is reduced volatility.  Now medium sized pools w/ various "pay per share" methods have reduced that demand somewhat but p2pool is proportional and in proportional pools size matters.

@ripper234 P2Pool charges a voluntary 0.5% fee, so it's much cheaper than some other pools.  Deepbit charges 10% for example.


text:
How can one remain relatively anonymous while using Bitcoin?
Bitcoin transactions are pseudo-anonymous. What can an individual that uses Bitcoin do in order to remain as anonymous as possible?

Get behind like 8 proxies at a public library and wear a tin foil hat! Or Tor

A public library probably has CCTV so best to avoid that

@Alex Waters I don't think that fully addresses the threat model. The problem with Bitcoin anonymity is not that someone would trace your transaction to your IP (though that is also a possibility). A bigger problem is that someone might learn that some addresses are under your control, then link you to other transactions. This can be done without knowing anything about which computers or geographic location you made the transactions from.

See also http://bitcoin.stackexchange.com/questions/9594/how-can-one-remain-relatively-anonymous-while-using-ripple

Don't publicly disclose any address in your wallet, or associate any address with your true identity.
Use currency exchanges to break the 'money trail' of bitcoin addresses associated with you.*
Use anonymizing services such as TOR when conducting business.
Break up your transactions between online and offline (person to person) transactions.
Buy bitcoins for cash.
Mine bitcoins yourself either directly (solo), or with pools such as Eligius that do not require registration.

*If you transfer bitcoins into a large currency exchange or other large private repository of bitcoins, then pay bitcoin back out to a new address that is not associated with you it is difficult (without a warrant) to track the bitcoins.

"without a warrant" are the very important keywords here.

Can you add purchase with cash / mine (see @David Perry's comment on my answer)? I'd like to accept your answer, and I want it to have all the info. See also Stephan's answer.

Thanks. Not sure how to incorporate Stephen's answer science it doesn't, in itself, improve anonymity.  Plus I see no reason to usurp his answer.

Re: David Perry's edit, I'm not sure that we can assert what data Elegies retains. That's way I phrased it the way I did.

How do you do #1 and actually use bitcoins at the same time? I mean: As soon as I want someone to give me money or if I want to buy something I have to use at least one of my wallets, right?

Use Tor whenever connecting to the Bitcoin network or to exchange sites.
Never publish one of your Bitcoin address publically (e.g. in a signature or blog). If you do, and someone actually sends money to this address, you run the risk of them being able to identify your other addresses and monitoring every transaction your make via Block Explorer.
Any Bitcoins that you want to keep truely anonymous should be managed via a dedicated account, and never linked on the internet to your name. E.g. if you buy some Bitcoin through Mt. Gox, this can theoretically be traced to you by law enforcement agencies if they can correlate the money transfer you made to Mt. Gox with the funds transfer (assuming they get access to Mt. Gox logs).

A simple way to remain truly anonymous is buying bitcoin in exchange for cash (e.g. through Local Bitcoins) and moving them to an address you will only access through Tor.

In addition to purchasing in cash you can mine (through TOR) at a pool like Eligius that keeps no information other than a Bitcoin address and an IP address.

There is a patch that can be used to let you specify specifically which addresses to use for spending in a transaction.
 - http://github.com/bitcoin/bitcoin/pull/415

Download the Tor package with vidalia from http://www.torproject.org/
Run Tor... When it is working, a green onion means your entire network traffic is being anonymized.
Details on how Tor works are at: http://en.wikipedia.org/wiki/Tor_(anonymity_network)
Install it... and then in your bitcoin application, under settings, tell it to use a proxy.
The default setting is the correct one.  You could probably disable the option that starts Bitcoin when your computer starts, because you want Tor up and running before Bitcoin.
All of your transactions are recorded in the block chain... mix things up by using available tumblers.  Also... the anonymous markets are displaying text saying they now use tumblers to make tracing where transactions come from and go difficult to analyze/trace.

Tor and proxies are a good thing, as it obscures which IP address that is broadcasting your transaction.
But the best way of making an anonymous transaction is to trade you Bitcoins into a different currency which have anonymity built in as a feature, which currently only are Monero and Dash. Then if you are able to use either of these for you purchase or other usage, then it would be easy enough to just stay with these, but otherwise its just transferring the other currency back into Bitcoin before usage (and make sure its a new unused btc address).
With Monero this would look like:
BTC (1) -> Monero (1)  --anon_send--> Monero (2) -> BTC(2)


text:
What happened to Bitoption.org?
BitOption was one of the first sites that traded Bitcoin Options. I was going to put it up as an answer to this question, but then noticed that I'm getting a 502 Bad Gateway error.
Does anybody know what happened to them?

Last I heard, they were down to rewrite their code. Apparently too much was being done manually and they're trying to automate as much of the process as possible. There was a landing page for a time and I've not heard anything new on the subject so I'm assuming they've simply taken their web server offline for some reason.


text:
How are the unlocking script + locking script executed?
I just wanted to verify the input of transaction 7de75. The related output is index 10 of transaction 00f64.
The locking script defined in 76a91 (index 10) is:
OP_DUP
OP_HASH160
7ddb236e7877d5040e2a59e4be544c65934e573a
OP_EQUALVERIFY
OP_CHECKSIG

The unlocking script in 7de75 is:
3045022100b7393ff959120e3ccb5284e3cf2eaa200235643a1549a4e6faaa911619089e2b02207b677827c7beeb53503e016a8dd29164d07cb79f0f1e058df9b8dfa3568d029001
04c4b7a7f7bb2c899f4aeab75b41567c040ae79506d43ee72f650c95b6319e47402f0ba88d1c5a294d075885442679dc24882ea37c31e0dbc82cfd51ed185d7e94

I've concatenated both:
3045022100b7393ff959120e3ccb5284e3cf2eaa200235643a1549a4e6faaa911619089e2b02207b677827c7beeb53503e016a8dd29164d07cb79f0f1e058df9b8dfa3568d029001
04c4b7a7f7bb2c899f4aeab75b41567c040ae79506d43ee72f650c95b6319e47402f0ba88d1c5a294d075885442679dc24882ea37c31e0dbc82cfd51ed185d7e94
OP_DUP
OP_HASH160
7ddb236e7877d5040e2a59e4be544c65934e573a
OP_EQUALVERIFY
OP_CHECKSIG

and executed it via bitcoinIDE. However, OP_EQUALVERIFY failed. Could somebody explain to me where I made a mistake?
edit: I think Rene Pickhard explains the issue here but I cannot follow the explanation

This appears to be a bug in BitcoinIDE. The issue is that it is computing the hash differently from what it actually is. Because it finds a different hash, the comparison that checks that the hashes match (the OP_EQUALVERIFY) fails.
However the hash does match. If you compute the hash manually, you get a different hash than what BitcoinIDE is showing.
Using the btcdeb project, I am able to execute this script and step through all of the opcodes correctly.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How can I get the list of all bitcoin transactions?
I am currently thinking of doing a research project on Bitcoins. I want to download the list of all transactions of bitcoins. I was wondering what are the ways to do this? I believe I can scrape, but is there a better and faster way to do this?

There is a new tool by a Princeton research group that does exactly this: https://github.com/citp/BlockSci

If you're looking for all BTC balances, this github repository looks useful. It would likely crash due to memory issues, but could show you all transactions using the "transactions" argument.  https://github.com/znort987/blockparser

The list of all transactions is the blockchain. The fastest way to get the blockchain is to run a full node which will download the blockchain for you and provide ways for you to access the data stored within the blockchain.
You can use Bitcoin Core and enable the transaction index so that you can get all transaction information. The transaction index is enabled by adding txindex=1 to your bitcoin.conf file.

How do you recommend I run a full node? I am sorry, I am completely new to blockchain/bitcoin etc. I do know Python well though so any guidance would be appreciated

Downloaded bitcoin core. Downloading all the transactions. Could you actually guide me, how I could import all of it (once its downloaded) into a sort of a csv file or maybe in a data frame in python?

You can use the JSON-RPC interface to connect to Bitcoin Core and send commands that fetch the blockchain data for you. Then you can put that into whatever format you want and handle it however you want. This library may be helpful to you: https://github.com/jgarzik/python-bitcoinrpc

If you already download (sync) the full blockchain database with Bitcoin Core, the fastest way to get the full list of all transactions is to use blockchain parser.
This script parses raw blockchain database which is stored in blk******.dat files and can extract all the data. If you need just TX hashes, you can leave only them as output information and just comment all the fields that you don't need to be in the output text files.
This is the most easiest way to do what you need.

Download the bitcoin core bootstrap.dat
Most downloads are compressed to save on download time.
Update:
Here's the torrents.
https://getbitcoinblockchain.com/

The bootstrap.dat  download method was deprecated around the release of Bitcoin Core 0.10 in february 2015.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
When will the official client support partial blockchain downloads?
Are there concrete plans for the official client to be able to download just a portion of the blockchain?
By concrete I mean what's the issue tracking this on github, is there a planned version for it?

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

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

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


text:
Is there a usable Namecoin GUI client?
Is there any GUI client that is capable of trading Namecoin, and is somewhat trusted by the community?

Multicoin can be used to trade Namecoin although the functions for registering names and such cannot be used.
There is a current bounty of 750NMC to produce a web UI for the client to run within a local machine. It can be found on the http://dot-bit.org wiki site.

Do you know Where can I find a Windows binary of MultiCoin?http://bitcoin.stackexchange.com/questions/1421/where-can-i-find-a-windows-binary-of-multicoin

A .Net NameCoin GUI was recently posted to Reddit.

Testing in a VM now. If this works it's some of the most fantastic news for NameCoin I've heard in a while.

@DavidPerry - do post your test results, please.

on my XP test VM it works quite well and at least hasn't made a grab for %appdata%\roaming\Bitcoin\wallet.dat or sent/received anything other than standard Bitcoin traffic. It's closed-source so I'm not sure how much I trust it, but it seems to be working and hasn't done anything malicious yet.

it's no longer available.

I realize that this is a very old question, but I think it makes sense to give an update nevertheless.  Recently, a port of the Qt-UI for Bitcoin has been done also for Namecoin.  It provides full support also for name operations and even configuring domains directly without the need to come up with the correct JSON strings.
The new Namecoin-Qt is available at https://github.com/namecoin-qt/namecoin-qt, and third-party binaries can be found at https://namecoin.org/download.


text:
How is a BIP accepted?
Who decides to change the status from Draft to Accepted?
BIP 0001 doesn't seem to clearly state this.

Is this a vote by the developers?
Whose vote exactly do we count?
How is it conducted and counted?
Are there veto rights?
Who handles disputes?
Is there a specific channel/topic/bitcointalk thread where accepted BIPs are published? (for those of us who don't follow the entire dev mailing list)

The process is not formalized precisely because only really non-controversial changes are supposed to make it in at all.
This hasn't always been the case, but is becoming more true in the last year.
Right now the process goes like this:

Start by thinking of some feature/improvement.
Convince the dev team(s) of the relevant parts (core consensus, wallets, other layers) that this is a good idea in the abstract, and it needs to be standardized.
Write a draft.
Get gmaxwell to assign a BIP number for reference.
Make everyone happy with the detailled draft.
At some point, the status of the draft changes to Accepted (based on actual agreement of all/most devs).

You can follow https://github.com/bitcoin/bips to see when changes are made.

Who is "everyone"? Is there a list of all people that need to approve a change?

"Everyone" means pretty much all relevant devs working in that space. BIP0032 became accepted only once multiple wallet implementers agreed it should happen, and started working on their implementations.
The BIP process isn't binding on anyone so it only can be relevant if it actually represents community consensus.


text:
Is there a correlation between Technical Analysis predictions and actual prices?
Technical Analysis is a disputed method for "predicting" future prices. This blog has been offering technical analysis on Bitcoin for quite some time (AFAIK it's the only one).
Has there been any significant correlation between its predictions (Short/Mid term UP/DOWN) to actual price movements?

If you are talking about Technical Analysis in general, we would need to write a book to answer that.
As for Technical Analysis applied to Bitcoin, just look at the date when the predictions were made, look at the graphs and compare. During the last couple of months:

He wrongly predicted a short term rally starting at $14 at the end of July
He correctly predicted the short term fall to $6 at the beginning of August
He has been predicting a long term up trend for two months that hasn't happened yet

Overall, I think his analysis are well documented and based on market indicators that work very well in other markets. However, I am not sure if the Bitcoin market got to the point where Technical Analysis plays an important role for price movements. No one can really tell because this is not an exact science.

Personally I think technical analysis is not useful for Cryptos, especially in the long run. I traded commodities and forex for a while and moved to Crypto's more than a year ago. Crypto's are better analyzed along the lines of "Start up" companies or "New technology" rather than commodity/forex trading. They are heavily influenced by news and politics and all altcoins are influenced by the grand daddy Bitcoin. Trendlines are handy and I created one over the whole of bitcoins history and it has been pretty accurate for predicting the future so far. I uploaded a video on it if you're interested the link is in my profile. Starts off a little slow but pretty valuable if you trade bitcoin.


text:
Errors running bitcoind in the background
I have installed bitcoind on a new computer, and I use nohup to run it:
$ nohup bitcoind &

However, every now and then I see that the process does not exist, and I have to restart it using nohup.
Any idea what went wrong? Are there any logs I can check, and is there a better way to run bitcoind in the background than nohup?

bitcoind has a -daemon command line option that will cause it to run in the background.  That is likely to work better than using nohup.
There should be a debug.log file in your bitcoin data directory where any errors will be logged.


text:
Is bitaddress.org compromised?
When I tried accessing https://www.bitaddress.org with Firefox, I was redirected to https://www.bitaddress.org/bitaddress.org-v2.7.2-SHA1-364542f1ccc5777c79aebb1692a6265cf3e42e7e.html and got a security certificate warning:

The same redirection happened with Chrome, without any security warnings.
Is there a real security problem with bitaddress.org?

The certificate for www.bitaddress.org is issued by PositiveSSL. Chrome trusts them (PositiveSSL), firefox does not.
There are an awful lot of issuers, and different browsers are bound to have slightly different lists.
If you trust them or not is up to you. If you trust Chrome's security, then you can trust that certificate.
If you "add exception", then BEFORE confirm security exception, you can "View..."; you can check the fingerprint (SHA1 & MD5), and if they match, then the security is the same between Chrome and Firefox (not necessarily good, just the same between the two browsers). If they are different, then someone is doing something SERIOUSLY FLAKEY!
Of course, you shouldn't trust a website that throws up a warning, just because some guy on the internet told you to :)


text:
Withdrawing Ether from Cryptsy to geth
I am trying to withdraw Ethers from Cryptsy to geth account. Cryptsy says address, where I enter my account id, is invalid. Do I need to create a separate addresses besides running geth account new to create a new account?

It is just a formatting issue.  Include "0x" at the beginning.

Thanks! Edited the question with screenshots. I assume this is the problem with Cryptsy?

Ok, I removed my comment about the typo that has been fixed

Yeah, I don't see why that wouldn't work if Cryptsy is working properly.  I may try it myself tonight.  I've seen reddit comments verifying that people have been able to withdraw ether from Cryptsy about a week ago.

Saw that my deposit address had "0x" at the beginning.

I can confirm account id (address?) needs to be prefixed 0x


text:
Decoding hex scriptsig in Python
Running decodescript on d1a076722d11ddfd0fadb96d6d960b8b2ad6c6369570cd00df70a801a6be9e44 is returning:
{
  "asm": "0 30440220278ee027abaf4720f580ce469139d75e330e120f91ff52b2c73955a712b96f3902204f11b7b1541dee5497cffd50291347b796e44ab1b6dac845d43a7185fdda184901 3045022100c3602c2872248e73f543fbf21ddc9fa3b73052261f619452fd5254852c9ea55102202c1323830f38a6fe149e0eccb18f92eba962165733285812deb96bcb8482de5d01 30450221008caaadf9b887828d02911ff22df335606c372f968d5c2ea0fa2f8c1a083fe5f502204c55eb85c0f06e10d488d7643a5c571bbabdeb935acc917836d44e755db6b1f601 532102939a016f9a4cfc4c73ba395c2baf16382a4de078dadf2bafaaac6846d786ed392102c7cf0bd62fb500d8f6ed39a46c7e72dc1b5185754e1a48d25a22195f113b35d8210306179c491a25d6db330a3a3e3ba0788b3ccea45aebfa2a06fc114787aadc01532103b8a79bd499afbc0f4b68e4c0e175176a013b1e2143da6ec95772add5c6728d6d2103bec7b18285d7af85b4f2c0936a106b746eaad14071f41788257fdffeb2e68e9a2103e4fda639ffcf2d996dc372db5eda18857afdd21054009d65ddd17ce96d5feed22103f5d1065abd2a8b5adc6ecda48712d2a572a24130b786f538629ff834b298379857ae",
  "type": "nonstandard",
  "p2sh": "32QZxW8qHSufifvr5UzXpzGG6jdcgnTCSF",
  "segwit": {
    "asm": "0 59d0d03149e611e8f8e879ab7c1133c99091ec09758ed29a9111341e424d9891",
    "hex": "002059d0d03149e611e8f8e879ab7c1133c99091ec09758ed29a9111341e424d9891",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bc1qt8gdqv2fucg7378g0x4hcyfnexgfrmqfwk8d9x53zy6pusjdnzgsdvlm7s"
    ],
    "p2sh-segwit": "36sk1CLrrv8HXgE1d1CKkNkwnK2tWKeWSL"
  }
}

The original Hex:
004730440220278ee027abaf4720f580ce469139d75e330e120f91ff52b2c73955a712b96f3902204f11b7b1541dee5497cffd50291347b796e44ab1b6dac845d43a7185fdda184901483045022100c3602c2872248e73f543fbf21ddc9fa3b73052261f619452fd5254852c9ea55102202c1323830f38a6fe149e0eccb18f92eba962165733285812deb96bcb8482de5d014830450221008caaadf9b887828d02911ff22df335606c372f968d5c2ea0fa2f8c1a083fe5f502204c55eb85c0f06e10d488d7643a5c571bbabdeb935acc917836d44e755db6b1f6014cf1532102939a016f9a4cfc4c73ba395c2baf16382a4de078dadf2bafaaac6846d786ed392102c7cf0bd62fb500d8f6ed39a46c7e72dc1b5185754e1a48d25a22195f113b35d8210306179c491a25d6db330a3a3e3ba0788b3ccea45aebfa2a06fc114787aadc01532103b8a79bd499afbc0f4b68e4c0e175176a013b1e2143da6ec95772add5c6728d6d2103bec7b18285d7af85b4f2c0936a106b746eaad14071f41788257fdffeb2e68e9a2103e4fda639ffcf2d996dc372db5eda18857afdd21054009d65ddd17ce96d5feed22103f5d1065abd2a8b5adc6ecda48712d2a572a24130b786f538629ff834b298379857ae

Blockstream explorer is returning the script in form of OP_CODEs, my question is, is there any python library that can decode it to the same state?

There are at least two I'm aware of: Python-bitcoinlib and bitcoin_tools

Thanks, I was aware of the libraries, and Peter Todd's one looks legit for this case, but all the methods there relates to script evaluation/serialization rather than to decoding the content of decoderawtransaction into SCRIPT. I am just confused on which method to use to get the result that's being shown by blockchain explorer.

Not sure what method you should use in Python-bitcoinlib. You can construct a transaction or script from hex in bitcoin_tools and call the deserialize to get that representation: https://github.com/sr-gi/bitcoin_tools/blob/master/bitcoin_tools/core/script.py#L54


text:
How can I remove the charity features in my Devcoin clone?
I'm trying to produce a SHA256 altcoin which is merge mined with Bitcoin.  I'd like to use some recent code, rather than base in on a 0.8.* or earlier codebase.  I've found this source:
https://github.com/sidhujag/bitcoin-0.9.2-Merge-Mining-fork
However, it's based on Devcoin, so it sends some of the mining proceeds to other parties.  I'm finding it very difficult to extract this feature, while keeping the merged mining.  For instance, in the miner.cpp file I've modified the CreateNewBlock function to remove the "Prepare to pay beneficiaries" section, but when I do so the compiled code segfaults.
Thanks to anyone who can help with this.
EDIT:
I've run the node with GDB, this is the error and backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd49e4700 (LWP 2385)]
0x000055555562ca50 in CreateNewBlock (scriptPubKeyIn=...)
    at miner.cpp:375
375         pblock->vtx[0].vout[0].nValue = GetBlockValue(pindexPrev->nHeight+1, nFees);

(gdb) backtrace
#0  0x000055555562ca50 in CreateNewBlock (scriptPubKeyIn=...)
    at miner.cpp:375
#1  0x000055555562dc4f in CreateNewBlockWithKey (reservekey=...)
    at miner.cpp:513
#2  0x000055555562de51 in GreedycoinMiner (pwallet=
    0x555556502c70) at miner.cpp:597
#3  0x00007ffff7547a4a in boost::(anonymous namespace)::thread_proxy (param=<optimized out>)
    at libs/thread/src/pthread/thread.cpp:164
#4  0x00007ffff5cc2182 in start_thread (arg=0x7fffd49e4700)
    at pthread_create.c:312
#5  0x00007ffff59ef30d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Have you tried stepping though your code with gdb? Have you tried adding print statements to see where it segfaults?

See my edit for the backtrace.  I haven't added print statements because I'm not really sure where to add them.

This question appears to be off-topic because it is about a bug in code we can't see.

I think this question can only be answered by someone with access to your code and a debugger.  Debugging with someone usually involves a lot of back-and-forth investigation and discussion, which is not a good fit for this site's Q&A format.

Ok, that makes sense.  I thought maybe someone had encountered a similar problem.

It's not a problem, per se. The whole idea of devcoin is the small percentage is supporting the developers, which was agreed upon when you cloned the coin. This is more akin to cracking software which I can't really see being something SE would get behind. Correct me on details if I'm wrong though

int64_t nFees = 0;
int64_t minerValue = GetBlockValue(pindexPrev->nHeight+1, nFees);
int64_t sharePerAddress = 0;
if (coinAddressStrings.size() == 0)
    minerValue -= fallbackReduction;
else
    sharePerAddress = roundint64((int64_t)share / (int64_t)coinAddressStrings.size());

LogPrintf("coinAddressStrings: %d\n", coinAddressStrings.size());
for (unsigned int i=0; i<coinAddressStrings.size(); i++)
{

This is the code in miner.cpp. I think what you should try is changing the following line:
sharePerAddress = roundint64((int64_t)share / (int64_t)coinAddressStrings.size());

change it to
sharePerAddress = 0;

That should remove any payment to the beneficiary.


text:
Bitcoin network splits?
Alleged situation, due to X, country or geographical region Y falls off the internet map, but still has it's own network running. Blockchain splits and this situation continues for 6 months.
After 6 months there is a country specific chain, and the rest of the chain.
What happens, how can it be folded back in, does it permanently cause a chain fork, has this been considered or does bitcoin already handle this situation?

longer chain wins I guess

When the network rejoins, the chain with more proof of work wins. Servers on the losing chain will switch to the winning chain. Transactions from the losing chain will be recovered and mined into new blocks on the winning chain.
There are three types of transactions that can't be recovered:

Any transaction that claims a block reward cannot be recovered.
Any transaction that uses an input that is already consumed by a transaction in the winning chain cannot be recovered.
Any transaction that uses an input from a transaction that falls into either class above cannot be recovered.


text:
Does sending coins to someone incur fees?
Some noob questions.

If I send someone coins, will it incur fees?
If it incur fees then is it true for all other coins too?
If it incur fees then can I set fee for the transaction?
If I can set fee for transaction then what will be its impact if the fees is low or high? What if I set no fee at all?

Related: http://bitcoin.stackexchange.com/q/13624/5406 http://bitcoin.stackexchange.com/q/14360/5406 http://bitcoin.stackexchange.com/q/18792/5406 http://bitcoin.stackexchange.com/q/5256/5406

I voted to close this questions, as it has been answered here several times before, the question doesn't show previous research, and is not adhering the SE format of "one question per post".

Yes it will since you need to give money to miners in order for them to keep up the work of securing the network.
What do you mean by "all other coins"?
You can set the fee for your transaction yourself, but if it's too low it might not be picked up by miners. Remember they're looking to include transactions with highest fees first, since they'll be getting the fees themselves.
If the fee is too low, the miners might not include your transaction in the next block. This might mean that it could take a long time for your transaction to be confirmed. Sometimes it happens that it doesn't get confirmed at all, even after waiting a long time, and you have to send the transaction again with a higher fee. If the fee is too high, well, the transaction will most likely get picked up immediately and get confirmed as soon as possible.

By all other coins I mean other Alt Coins like LTC, DOGE etc. Who exactly are miners to whom this fees is paid? All users who are mining? So let's say if I am also mining BTC then it means I will also receive fee if someone sends BTC to anyone?

The transaction fee policies are pretty much the same for all cryptos. Miners are people that provide computing power to a crypto's network. Over a sufficient long time, you would expect to gain mining rewards corresponding to your share of the total mining power of the crypto you are supporting. Perhaps you should check out What exactly is mining?.

Yes it incurs fees but it is as low as 0.001 so it doesn't really bother. Moreover you can set what fees you want to pay from the QT if you are running QT on windows you can set it by navigating to Settings >> Options >> Main and then fill the box which says "Pay transaction fee"
if you are running headles QT on linux then run bitcoind settxfee
The time taken by a transaction depends whether you are paying fees or not if you are not paying fees your transaction will take more time than usual


text:
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).

I tried to improve your question a bit, please check whether my changes are in accord to your original intention.

Do you mean as in the number of shares you have found?

I wrote some more. It's probably just an artifact of a bad UI without any decent explanations. At least now I know it's not something important or well-known.

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.


text:
bitcoin-qt crashes when any bitcoin.conf file is used
I am running 0.8.5 beta on my mac under 10.8.3 and it runs fine until I try to use a bitcoin.conf file.
If there is a file, even if it is completely empty it will crash before the application even starts.  All I receive is a message "Bitcoin-Qt quit unexpectedly."  The is no log even generated.
I have tried redownloading the application and trashing all the files including the blockchain.
If I remove the bitcoin.conf file the application launches and runs fine.
Any help is greatly appreciated.


text:
Number of transactions per block
I am just starting to understand the internals of bitcoin. I am a CS graduate and familiar with most bitcoin terminologies. I've read Satoshi's paper and researched the question but I couldn't find the answer.
Now that it is much more profitable to mine blocks for the reward (25coins) than the transactions fees. my question is what prevents miners from only including 1 (or 0 if its allowed) transactions in their generated blocks as hashing smaller data will result in greater hashes/s (yes?)
Also, and most importantly is how does a miner decides that enough transactions has been received and start finding the nonce as adding a new transaction to the attempting block will result in all the work done for this block as obsolete.
I'll try to give my guess so correct me if I am wrong. While the miner tries to find the new block it buffers any received new transactions. If he/she finds the new block or a a new valid block is received they start working on the next block by putting all the buffered transactions into a new block and get to work.
Please excuse me if my questions seems primitive. I tried my best to research and any links are greatly appreciated.
Thanks.

Also see this question: http://bitcoin.stackexchange.com/questions/16606/do-transactions-affect-the-discovery-of-a-block/16622#16622

Nothing is stopping miners from not including transactions in their blocks, in fact it has happened before.

hashing smaller data will result in greater hashes/s (yes?)

No, the hashes are always the same size, and adding transactions to the block does not make any difference to the difficulty in finding the nounce that validates the block (the speed of hashing remains the same, and the probablity of finding the bock also remains unchanged), hence it makes financial sense for miners to add as many as they can since they earn more transaction fees.
Edit: for more details on the mining process, this thread provides a good summary:

Simplified mining process 1) Miners select tx from the memory
  pool for inclusion in a new block (the number, method, and criteria is
  up to the miner) 2) Miners construct a merkle tree from the tx in
  step #1 3) Miners create a block header with the merkle tree,
  prior block hash, version, timestamp, and nonce 4) Miner will
  hash the blockheader.  If it is a solution go to step 5. 4a)
  Miner will increment nonce and go to step 4.  If nonce range is
  exhausted go to step 4b 4b) Miner will modify another element in
  blockheader, reset nonce range back to 0 and go to step 4 5)
  Miner has found a block.  They broadcast it to peers.  So
  once a miner finds a block they are done.  All the work for deciding
  tx comes BEFORE solving a block.

So the number and size of transactions has no real impact on the repetitive step #4.
Having said that, it has been claimed that some miners do choose smaller blocks in order to minimise network propagation delays, and hence reduce the chance of their block becoming an orphan.

The probability of finding the hash remains unchanged but the speed? How is the time hashing 1kb = hashing 150kb. As of adding transactions wouldn't affect difficulty, could you elaborate why? is the nonce being tested picked randomly (or  pseudo-randomly) or is sequential?

@Moshohayeb I have edited my answer to better explain why the size of the block does not affect the hashing speed, as there is a preliminary step involved in creating a block header out of them. The hashing process only uses this header.
Having said that, block size will affect its network propagation speed.

Thank you very much, also found this in the wiki The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

@ktorn thank you for this, answered my question directly. Does this mean that miners/pools have some sort of personal policy as to how many transactions to include, to weigh the risk of delays in producing the merkle tree?

The others already answer your question, but I'd just like to clarify one more point (since you said it was "most important"):

Also, and most importantly is how does a miner decides that enough transactions has been received and start finding the nonce as adding a new transaction to the attempting block will result in all the work done for this block as obsolete.

The nonce-searching process is a memory-less process.
This means that if miners A and B have the same hashrate, and are working on the exact same block, and at time T A already tried 1000000000 nonces (with no success) and B already tried only 1 nonce (with no success), both have the same probability to find the next block. I.e., at time T, the fact A is "ahead" of B doesn't give B any advantage.
In this sense, every work a miner does which doesn't result with a block is already "obsolete".
With that in mind, if a miner wants to add txs to her block, she only needs to repeat once steps 1-3 from @ktorn's answer.  It might waste some searching time (thus decreasing the probability to be the first to find the block), but it also increases the potential reward (more fees).  This means there's a tradeoff, and a miner will do it only if she thinks it is profittable (e.g. there's a new tx with high enough fees).

Nothing prevents miners from not including transactions in their blocks. However, miners are trying to make money and 0.0005 * 54 = 0.027 BTC, which isn't a trivial amount in this market.
See https://en.bitcoin.it/wiki/Transaction_fees for more info.


text:
What does one need to do to earn Decred through PoS?
If I understand correctly, Decred can be mined through PoS (Proof of Stake) rather than PoW (Proof of Work).
What needs to be in place to achieve this? There are some technical details here about how Decred works but I'd like something in laymen's terms.
I understand that I would need to run a full node to qualify, but:

Is there a minimum number of Decred that need to be held? Does the age of them make any difference?
What kind of download/upload speeds would be required for the node?
Anything else I haven't thought of that I should know?

Decred has a hybrid Proof-of-Work/Proof-of-Stake model, which means that block rewards are shared between the miners and the stakers (and the developers), with PoW mining earning the larger portion of the reward. (60% PoW miners, 30% PoS voters, 10% Decred development subsidy)
The way staking works in Decred is through a ticket system. You purchase a ticket, and it enters the ticket pool. Out of the pool, a few tickets are randomly selected along with every block, and these tickets vote on that block. Every ticket has a 50% chance of being selected in 28 days, and a 99.5% chance of being selected to vote in 144 days, after which it expires, and returns to your wallet. For all the time that your ticket is in the pool, the DCR used to buy the ticket is effectively locked.
You don't need a full node to stake DCR. You can just be a part of a staking pool. A stake pool allows you to stake your coins along with the pool, which will have full nodes of their own running at all times.They will vote on your behalf, and take a small cut of your earnings (1-5% depending on the pool). Note that you do not give up access to your private keys at any point during this process.
Coming to your questions,

Yes. There is a minimum number of DCR you need. It is called the ticket price. Currently it is around 75 DCR (you can check the current price here), and it fluctuates with demand and supply of tickets. The age of the coins don't matter. But the ticket itself takes about a day to mature before entering the ticket pool.
In case you are using a staking pool, the question of upload/download speeds is now irrelevant. But overall, it is not a question of speed, rather availability/uptime. So if you're running a full node all the time, the staking part should be trivial.
At this point you can only buy full tickets. There are several requests for ticket splitting, which would allow you to buy a fraction of a ticket and stake regardless of how less DCR you own, but that really isn't priority on the dev pipeline. Also, there is a 0.5% chance that your ticket is not picked, in which case the amount you spent on the ticket will be returned to you minus any transaction fees.

For a good introduction to the whole system, the PoS Documentation is a great place to start.
The FAQs are a great resource as well.

Thanks, that's an excellent explanation! (don't forget to upvote the question if you think it would be useful to others)


text:
Are there any bitcoin banks (online services) and what are the benefits and pitfalls of using them?

Possible Duplicate:
Is there a solid "Bitcoin Bank" yet?

Say that I wish to control my bitcoins from a (for me) single point and I don't have the technical resources to have a single access point with a wallet amongst my own personal computers / devices.
Is there a bitcoin bank or similar service that hosts my bitcoin wallet for me and is there a benefit to such a service beyond likely better backup and being a single point to which I can manage my bitcoins without having to set up my own remote access to a home PC?  What are the reasons against using such a service?

There are such services. But there's a good reason not to use them -- if one day the service is gone, so are all your Bitcoins. This has already happened once and will almost certainly happen again. As of yet, there are no companies I would consider sufficiently reputable in this business.
You can, however, keep both Bitcoins and other currencies in a TradeHill or Mt. Gox account. You can fairly easily transfer Bitcoins into and out of those accounts and they're run by well-financed companies that can reasonably be trusted. And both TradeHill and Mt. Gox have made noises about making their accounts more like online wallets.

Flexcoin offers an online wallet and "banking service" which actually pays interest on positive balance.
They do this by charging a fee for external payments, flexcoin to flexcoin remains free. 70% of all interest is then distribuited between its users.
The concerns of this is that an unregulated third party is in control of your money. Bitcoin is aimed at a cash style system, its all about trust when you put your money in other peoples hands.


text:
What does a comparison of Bitcoin Days Destroyed say about Bitcoin vs Namecoin vs SolidCoin?
The Abe blockchain explorer provides statistics for percentage bitcoin days destroyed, using the generic term "% CoinDD".  Currently Bitcoin is 36.1245%, Namecoin is 41.5547%, and SolidCoin is 47.0952%.
My guess is that the relatively high numbers for Namecoin and SolidCoin could indicate that people are cashing their mined coins in for other currencies or goods more regularly than people have historically done with Bitcoin.  What is known about the Namecoin and SolidCoin transaction cultures?
But of course Bitcoin only became really active in recent months.
It would be interesting to see comparisons of recent activity.  Are regularly updated graphs over time available for these % CoinDD values?

To be fair, older coins will have a lower percentage of DD, all other things being equal. (Think about lost coins if nothing else.)

@david I'm not following what you're saying.  DD isn't about coins themselves, but about transactions on coins.

I'm saying that an older currency will have more lost coins. Obviously, there won't be transactions moving lost coins. So even if all other things are equal, the longer a currency has been around, the lower the % CoinDD. (Of course, all other things are not equal. % CoinDD for most currencies are going up because they're gaining traction. But lost coins puts a higher negative pressure on Bitcoins than other currencies.)

@david Ahh - got it - thanks.  I wonder what the percentage is of lost bitcoins - seems like that would be a second- or third- order effect.

While Bitcoin DD% is lower it is a lower % on a larger base.  Converted to a standard unit say USD Bitcoin transactions are a magnitude higher than other coins.  The lower DD% doesn't tell us anything about the nominal amount of transactions but rather the relative days destroyed between currencies.
The lower DD% simply means that less of the older coins are moving in the bitcoin economy than other economies.  Other economies are much newer thus they don't have very old coins which due to their extreme age can skew the stat donward.    If the oldest SolidCoin miners simply mine and hold they at most can prevent a 14 days from being destroyed.  For early bitcoin miners holding onto a single coin can prevent hundreds of days from being destroyed.
As for reason why older coins may not have the same velocity as newer coins.  Some of that may be loss.  For a long time bitcoin was worth less than a cent.  Someone with 10,000 coins (a huge sum tody) may not have taken very many precautions against it and lost coins in data losses or system formats.
Some early miners may have done it simply for academic reasons rather than any investment and when they stopped they deleted (intentionally or accidentally) their wallets.
In the early years of bitcoin there wasn't much value or reason to quickly sell coins.  Now the miner may no longer even be mining and just holding the coins as a speculative investment.  Newer chains usually have an exchange open from day one.  Checking the alternative cryptography forums and exchange chats will indicate a large number of miners aren't mining alt coins for long term appreciation (which would result in low DD%) but instead are quickly selling on exchanges for other currencies including fiat.

I agree with much of this.  But you say Other economies are much newer thus they don't have very old coins which due to their extreme age can skew the stat donward. Since we're talking about DD%, not just DD, this is already taken care of.

As we can't really know what the particular coins are doing in the network, we can't tell for sure whether they are being actively traded for other coins, or traded in another way.
As for what the percentage can tell us, is that Bitcoins are transferred less frequently, be it because they are hoarded, saved, lost, or otherwise not moved. For example, coins stored in BitBills will contribute to lowering the Days Destroyed, as they are not actively traded through the network. As Namecoins and SolidCoins are still young currencies, there are less means for those coins to be not moved (less people loose their wallets, store coins offline, etc.), and less people want to save in them to store value (if NC or SC are attacked and destroyed, BC will still be able to hold on on it's own relatively unharmed, if BC goes down, all the alternative coinages will probably go down as well, as people have less trust in them for now).
So in general, comparing Days Destroyed can show how many people move their coins, rather than storing them, but the details as to why that is so requires the knowledge of all the ways people use the given coinage.


text:
Make sure my offline Wallet is ok?
Let's say I make an offline wallet from a live cd with bitcoins-qt.
I make some addresses (10 pcs.)
I encrypt the wallet. Save it on a usb (wallet.dat).
I then send over some bitcoins to one of my newly made addresses.
Then I run my normal OS (online) and install bitcoins-qt, download the whole block chain.
Closes bitcoins-qt.
Replaces wallet.dat with my encrypted wallet.dat
Starts bitcoins-qt.
Can I see the balance of my addresses, without decrypting the wallet?
Is it once I'll send them as I have to decrypt it?
If this works ... Can I in any way try to decrypt the same wallet offline (without the block chain?) To ensure that I can access it, the day I'll send my bitcoins?
Is there a security risk with going online with my wallet.dat if I never decrypts it online?
Edit:
I know that I can see my balance online without the private key.
But I can't think of any other way to make 100% sure I can access my bitcoins in the future?
1.First I make sure that my wallet.dat is working and does have my adresses and the correct amount of bitcoins. (without decrypting it).
2.Then I go offline and make sure I can decrypt the exact same wallet.dat
Is this possible?

If you just want to check if your wallet/password is working, you can do so using the bigcoin-qt debug window. To open the window, select "Help" from the menu bar, and then "Debug Window". Once you open the debug window, you can type this:
walletpassphrase "your walletpassphrase here" 600

to unlock your wallet. If the command completes without an error, you wallet has been decrypted successfully. If you get an error, your wallet couldn't be decrypted. From that same console, you can type this:
listaddressgroupings

to see the addresses stored in the wallet. When you are finished, type this:
walletlock

to lock the wallet. You do not need to be on the internet to do this, so you could do it from your live cd. I also believe you can do this without having downloaded the block chain, but I haven't tested it so I'm not 100% sure. Additionally, the commands available from the debug window are listed here if there are other things you would like to check.

Thanks. But then I type the "listaddressgroupings" I get nothing. Just []  and nothing more?

Try using this then listreceivedbyaddress 0 true

You can see your balance on blockchain.info without having access to the private key
EDIT:
I think Armory has feature called a "watching address" that lets you have addresses in your wallet that cannot be spent

I know that. But I want to make sure that my wallet.dat working properly because I do not plan to use it in a few years.
I want to know (online) that I can import it (wallet.dat) and see my addresses and the correct number of bitcoins at these addresses.
I would then try to decrypt the same wallet.dat (offline).
That way, I am 100% sure that everything is as it should.

Look at just using a private key.  This way you only need to keep 256 bits of data safe rather than an entire wallet file

I think you're trying to over complicate the problem by using a bitcoin qt wallet file.
If the purpose of this is for long term cold storage and to ensure in the future you can still access your funds, you should look into storing just the private key.
A private key can be stored in just 64 hexadecimal characters, short enough to be engraved in stone, steel or some other (semi) permanent medium.
Once you have a 64 character hex private key, it's a simple process using the brainwallet code on an offline computer to convert the key to a public bitcoin address.  Brainwallet can also sign transactions offline if you provide it with the list of unspent transactions.


text:
Claim BCH with Electrum wallet
Here are the steps I took:

I moved my BTC to a new Electrum wallet and waited to get 6 confirmations.
I copy pasted the seed of the old electrum wallet
I installed Electron Cash on a new PC
I created a new wallet there and used the seed of the old electrum wallet

output: 0 BCH
is this because I could have had Multibit HD at the time of the fork? I do not know for sure if I used Electrum back in august 2017...
Or is there an other explanation?
edit I think that I found a similar situation here Bitcoin Cash Multibit HD/Electrum but I am not 100% sure that I had a multibit hd wallet back then or an electrum. But because my electrum seed gave me 0 BCH it probably was multibit hd back then.

Where have your BTC been on Aug 1? That's deciding.
If I understand it correctly, you created a new BTC-wallet and sent your BTC there. But your BCH are still on the adresses on which your BTC have been on Aug 1.
So you need to get the seed of your older wallet (where they have been on Aug 1) or (if you did not use a HD wallet that time) you need to get the private keys of the adresses of the old wallet (almost wallets allow you to export them). You can import them in Electron Cash then.

It is either in Multibit HD or Electrum. I do not know for sure. Is there a way to verify the balance of a wallet address on that date? If it was in multibit-hd is there a way to get the bch?

I'm finding it hard to import private keys into electron - Electrum bitcoin exports a huge csv file - and this doesn't import properly - telling me I only need to import keys with balances. Super not clear.

I did it! with this https://bitcoin.stackexchange.com/a/57505/10173

I found my seed/ wallet words of the old multibit wallet.
Installed bitcoin cash on a new pc
select new standard bitcoin cash wallet
select use seed
type the wallet words
click options to select BIP39 seed
derivation path. changed the default m/44'/145'/0' to m/0'
made a new password for the bch wallet

and it's done!


text:
How do I restore a wallet from a backup file in MultiBit HD when you have the words and cloud backup?
I have read this: How do I restore a wallet from a backup file in MultiBit HD?
and have the words and mbhdxxxx.aes files in my cloud storage and the wallet password....
but the next button is not enabled when I enter the words:

update
I have had multibit before the hd client. I have a file like

mbhd-8a659fc1-9acd420e-b2127154-b924c146-3f974bab-20150825115221.zip.aes

in the cloud and have found a file like

mbhd-20160630143523.wallet.aes

I have used decrypt_bitcoinj_seed from github and entered my password and got 12 words to restore. The python script did not work with the long and older filename but did work with the short one. But when I have the words and try to recover it says: no datestamp found. When I use the words to continue and select a folder containing the old long file names it does proceed but with errors. I feel that I am getting closer. But I could use some pointers from people who have more experience with multibit hd and recovery.

I did found a folder in a backup on an external hdd which seems to work, but then I got:

I have had 2 wallets now in Multibit. I have selected the old one and waiting an eternity for the sync to finish. I have now my old wallet value as unconfirmed.
How can I fix this? I have read this. but there is no repair... only recover.

Be sure to write the words in correct order and with small letters, secondly use only spacebar button between them, DO NOT USE Enter button to go to the next line.

I copy pasted them in a notepad document (.txt) and copy pasted them back in to restore. So no typo's there and no newlines etc.

Enter them manualy and the lock icon will change and allow you to proceed further.

It is not the lock icon that is the problem. I clicked on it to make words invisible. It did not affect the "next" button. It stays disabled. Perhaps because the words are from an old multibit (hd) version? I still can not restore my wallet while having the words, the password and the cloud backup.

If the words were from another wallet but correct they should restore that said wallet.  How many words are you using, 12/16 or more ?. If you still have the wallet files and password you can look up wallet words using th [this link][1]
[1]: https://github.com/gurnec/decrypt_bitcoinj_seed
After you the procedures written there, you'll be able to see the correct and only words for this exact wallet that you have and from there restore it.

16 words. I have heard from Multibit HD that 16 words cannot be from multibit hd. So I have no clue how I have managed to get 16... perhaps before it was 'HD' ?

16 words must be a different wallet because Multibthd allways used 12/18/24(i think..) words. It won't be and earlier version either because classic MB did not use wallet words. Try the tool I've linked before on your mbhd.wallet.aes file using your password as input value, after several minutes you'll see words which then you can use to restore wallet using only wallet words(without timestamp, password, etc) If you have more problems you can contact me directly at vanboohen(youknowwhat)mail ru.

Thank you @Vanboohen but it seems that not only my 16 words are failing, also the password is incorrect according to decrypt_bitcoinj_seed.pyw http://imgur.com/a/9K2NY I think I lost 36 euro :'(

Living on the edge, yolo @Mark. I have the 12 words and the password to get them from the wallet.aes file but it says that there are no backups for 'this' wallet. But it's a backup from older wallet from older pc. it's asking for a datestamp now :S

authors: Никита Захаров


text:
Is there a limit to how much extra data can be put into blocks via scripts?
According to this answer, miners can include extra data in blocks.
Is there an upper bound to how much a miner can add? How much?

The maximum size of a block is 1MB. A block can be filled entirely with arbitrary data.
Namecoin actually puts its extra data into the "coinbase" parameter, which is specifically designed to hold arbitrary data. Data put here is limited to 100 bytes, and this data will in the future be safely forgotten by most clients.

so how much would it cost someone to embed 1kb worth of data into the bitcoin blockchain? say i wanted to embed a js script file and then retrieve it from the browser by querying the blockchain.


text:
Can someone with 51% computing power earn more than he deserves?
See also What can an attacker with 51% of hash power do?
This may have been discussed elsewhere, but I'm not sure what the answer is - if someone owns 51% of the hash power, can't he just ignore the rest of the network, and only focus on his chain, thus earning more than 51% of the rewards (100% in fact)? Will he in fact earn 100% of the reward?
Also - is it possible that several attackers working independently could achieve this scenario? If two people have 34% each, won't one of them always out-race the legitimate chain? Of course, they can't both win, but for some period of time, won't the stronger one among them gain more than his fair share of block rewards?

@WimCoenen - it's not a sudden increase, see theymos' answer and my comments.

If you have 51% of the network and you see that someone else has solved a block, then you can either accept their block or compete with it. In either case, if you get the next block you'll get 50 BTC. Usually neither option is more desirable than the other unless you're doing other attacks. It might be a bit better to take 100% if you're worried about difficulty or subsidy adjustments.
So an attacker could get 100% of block rewards, but this alone won't help him much.

I guess that depends how long your attack runs. If your attacks runs longer than the time needed for difficulty adjustments, then the next adjustment will only see your (shorter) chain, and the block reward you receive should increase if you ignore other blocks. Am I right?

Actually, isn't is always profitable to do this, if you're fairly certain that you do have 51%? (If you're not certain of it, the you're at risk of losing all your rewards if the other chain gets longer).

@ripper234 You can decrease difficulty to some degree. Maybe this would be profitable.

If you mine legitimately, you get 51% of the block rewards, or about 50 Bitcoins per 20 minutes. If you ignore all other blocks, you get 100% of the block rewards, or about 50 Bitcoins per 10 minutes. It's a no brainer.

Yes, if you have 51% of the network you can reject all other blocks, thus making sure you receive all rewards. The difficulty will adjust to match just your own hashrate, making sure you mine the expected 144 blocks per day.
In fact, with a clever strategy you can get more than your fair share of block rewards even if you're below 50%. This was discussed here - for example, with 46% of the hashrate you can get 51.29% of the rewards, assuming the rest of the network is honest.
In the multi-attacker case, an attacker with more hashrate than the honest network and any other attacker (where every attacker rejects all blocks but his own), will get 100% of the blocks. If there are several attackers at the top, you'll have occasional massive reorgs where one moment one attacker owns all the bitcoins generated since the attack started (if he hasn't spent them), and the next moment another attacker one-ups him and replaces the whole branch with one where he has generated all coins.

He could do whatever he wants to, the problem is legitimate clients would ignore the blocks if they are out-of-spec!

Why do you think the blocks he generated would be "out-of-spec"?

The client will follow the rules and use the longest chain.  So if attacker has 51% of hashing power and doesn't give up (i.e. abandon current block when a legit one is found) eventually the odds are in favor of the attacker that he will have a longer chain.  With 51% vs 49% the cheating attacker will have the longest chain 99% of time after 10 blocks.  At which point every client on the network will see the attacker's chain as the longer and thus valid one.


text:
How can the alert system be triggered? Who can do it?
Since we established the alert system is included in the official client, I would like to know who can trigger the alert system, and how?
Can this system be spammed (activated 1000s times per second) thus disabling any use of the client? (Because he would get annoying popups all the time)

Just got confirmation that Satoshi passed the signing key to Gavin before he retired, so at present only Gavin (and Satoshi if he ever returns) is able to send out alerts.

You mean only Gavin and Satoshi.

Correct, let me amend that.

"Alert messages are signed with a private key that only I have." - Satoshi Nakamoto
Such a spam would be pretty pointless. It would take only a few hours at most before the alert system was disabled.

Is this still true? Does only Satoshi have the key? How do you know?
It wouldn't take hours to disable it, because everyone (or a significant chunk of people) would need to upgrade to the new client.
It is my impression that the alert system in its present form is obsolete and should be removed.

I find it problematic that a p2p system still has a secret backdoor (even though it doesn't do much) owned by one individual, whose identity is secret. I would like for this to be removed / replaced with something more transparent.

Satoshi said only he has the key. We have no way to know if that's true or not. I don't see why everyone would need to upgrade. Only people who were using the GUI version of the client and needed to do transactions would need to update. It's not like the network would be harmed by people who weren't monitoring their clients. Also, once many nodes stop passing alerts, many will stop getting them. And I bet a patch to add a '-noalert' option to the client would be accepted. But this is kind of a non-issue -- it's something that could happen exactly once.

So you don't think it's obsolete? I would move this discussion to Chat, but we only get that option after a long comment thread.

I agree that it's obsolete as implemented. It is a good idea to have some mechanism to say "this version has security problems", but the key should be held by the current development leads (since they're the ones who will respond to a problem) and there should be a simple option to disable it (for those who choose not to trust them) without changing the code and recompiling.

It's definitely a feature that, if implemented well; could be very beneficial. IMO it's not a major priority, nor is it a major risk.


text:
Could the Ripple protocol be modified to allow funding your initial account with BTC?
See How can you buy XRP with BTC if you don't have any XRP?
Currently, there's no way to open an account with direct access to XRP. Could the ripple protocol be modified to include a way to open an account with BTC instead of XRP? The BTC would be exchange to XRP in the distributed exchange using the best available exchange rate.

The problem is that you need an account to hold BTC in the Ripple network. There is no known practical way to allow Bitcoins to transact directly on another network without a central authority to hold the keys that release the Bitcoins on the Bitcoin blockchain.
Hopefully, this should only be an issue for a short period of time. Once billions of XRP have been given away, there shouldn't be any significant difficulty in getting enough XRP to open an account.
Update: The gateway protocol could be used to do this, allowing you to do your initial account funding right from a Bitcoin account.


text:
What are all the different fees used in Ripple?
This article mentions two fees:

200 XRP for creating an account
50 XRP for creating a credit line

Is the credit line fee one time or per credit line? Are there any other fees in Ripple? Is there a place that summarizes all the different fees, both inherent in the protocol and determined by gateways/users? This answer is rather comprehensive, but it doesn't mention fees for credit lines nor the number '50', so it isn't be complete.

The answer you cited discusses the fees that can be charged on fiat currencies by gateways, when exchanging currencies, and when using other users to swap IOUs. The XRP fees are imposed by the network itself.
The transaction fee is the only fee that is destroyed. Currently, it is 10 drops per transaction under normal load conditions. (A drop is a millionth of a Ripple.)
The fees you mentioned are actually reserves. Reserves are amounts of XRP you must hold to maintain an entry in the ledger. The reserve is returned when the entry is removed, however, there is no way to remove an account. The reserve is not destroyed, it stays in the account. You can use your reserve to pay transaction fees. You just can't create a new entry if you don't have the reserve to cover it.
Currently, the only entries that require a 50 XRP reserve are credit lines and offers. It is expected that future entries, such as contracts, will also require a reserve. A credit line only counts towards your reserve under some circumstances. Other people can't extend credit to you and increase your reserve.

Perhaps someone should contact Bitcoin Magazine and ask them to explain that the fees are actually reserves - their article is rather accurate and comprehensive, it's a shame to leave such a mistake. Is the 50 XRP required per credit line?

It's per credit line if you created the credit line and under some other circumstances. But nobody else can extend credit to you and thereby raise your reserve.

I assume multiple credit lines of different currencies to the same entity don't count as one line, right?

BTW, I'm surprised that you don't upvote Ripple questions more often.

@ripper234: Each credit line counts if you extend credit, including different currencies from the same issuer.

Has the unit's name been changed from "drop" to "drip" now ?

@AlexKravets: It should be "drop"! Fixed now.

That was a nice Freudian slip related to the XRP distribution process :-)


text:
Explanation about how to build network upon bitcoin blockchain
Sometimes, I would see some news says:

xxx service is build upon bitcoin or base on bitcoin blockchain
xxx servie is making use of current bitcoin network
And today I see a DNS project says that it use bitcoin blockchain:
Its doc  says:

For example, a Bitcoin node may look at a Blockstack transaction and only see that bitcoins are moving from one address to another and that an unintelligible sequence of data has been attached in a data field (e.g. a field identified by OP_RETURN). Meanwhile, a Blockstack node will look at that data and will know how to interpret it in a way that updates the name database.

How do them mean build upon/ making use of ???
Here, assume X network with 5 node build upon bitcoin blockchain, I think it need:

has some bitcoin in each node(for making transaction)
if X network want to achieve immutable, it need send some bitcoin to another with some data(bitcoin allow to write additional data in a transaction).

Is this how them use bitcoin blockchain? But this way cost transaction fee... Or there is a free way to do such things?


text:
Why is halving the best time for block size increase hard fork?
Gavin Andresen said the best time to launch the block size increase update / hard fork would be the next reward halving (when mining discovery bounty would go from 25btc to 12.5btc).
Why has halving anything to do with increasing odds of success of a hard fork?
Source: Gaving Andersen said that at the Dev Core conference London on April 19th in his keynote "Why we need a bigger chain". There was a live broadcast of the event but I can't find a video link.

It would be good to include a link to where he says that.

A couple of months prior to a reward halving, the entire community is awake and excited about its prospects:  this has happened not only with bitcoin but will the other alt-chains out there.  So at this moment, bitcointalk, reddit, and most everyone is ready to listen and actually upgrade.  At other moments, many people might "just be going on with their lives" and not following the news.
Technically, due to bitcoin's and other alt-coins successful reward-halvings, there are slim chances of major issues in the reward-half process. That codebase is extremely solid.
It's especially important that miners upgrade, or a hardfork will be created, with all the possible inconsistencies that could happen, drop in computational power, not to mention user confusion and trust in the network.

There's definitely no reason for that from a technical perspective. Success is entirely dependent on convincing all the wallets, nodes, and lastly miners in the network to make a breaking change to their software.


text:
How does an online market place collect commissions on bit coins?
How do online marketplaces that transact with bitcoins take a commission from the sales?
Do they simple accept the bitcoin first, take their cut, and then transfer the remaining proceeds to the seller?
EDIT: I am referring to a website taking a commission of an online sale, not bitcoin exchange charge fees.

Bitcoin exchanges charge fees on trades.
https://www.mtgox.com/fee-schedule
https://www.bitstamp.net/fee_schedule/

I meant a website like ebay that uses bitcoins.  How does the website get a cut?

You should edit your question to clarify then, because answers can be removed independently sometimes.

authors: Дмитрий Бравый


text:
Split BCH out of BTC and then BSV out of BCH?
I have an old Bitcoin wallet from before the BCH split.
I think I can still split the BCH out of it, but then would I be able to split the BSV out of these BCH?
If that's possible, is there a special procedure?
I'm thinking :

Send full BTC wallet to some other address (to secure them)
Import the private key of the original BTC wallet in Electrum Cash to get the BCH
Send the BCH to another address (to secure the BCH)
Split the BCH into BSV from the original BCH wallet

Would that work?

All fork coins are tied to same private key. Simply import your private key to a multi-currency wallet like Exodus. This will unlock funds from all chains in one place.

Would that work from the recovery seed as well? And doing that means that I will be able to control the coins from either my original wallet or Exodus (which supports more), right?

Yes, that's correct.


text:
Could a hacker replace Bitcoin QT in some Linux repository and steal Bitcoins?
Bitcoin QT, being a Linux application, is updated regularly when the application in the repository is being updated (For example, apt-get upgrade on Debian).
Theoretically, if a hacker could get into some Linux repository, he could replace the application with a malicious one that steals both the private key and the wallet file and send it to a remote server (effectively stealing all the Bitcoins from most the users).
If possible, even through social engineering, the incentive for such hack is enormous.
How likely/unlikely that to happen?

Software distributors typically have authentication mechanisms to prevent an attacker from inserting malicious versions of their software.
In the case of Debian and its derivatives, there are two steps.

The binaries and data for bitcoin-qt are distributed as a .deb file.  A cryptographic hash (currently md5, sha1 and sha256) of this file is contained in the Packages list that apt-get uses to determine which packages are available.  If an attacker modifies the .deb file, say by breaking into one of the Debian mirror servers, the hash will not match and apt-get will refuse to install the package.
The Packages file is also distributed by the same servers, so an attacker could modify it so that the hash listed there matches the malicious .deb.  However, the Packages file is accompanied by a signature produced with Debian's master private key, so this signature would not match and apt-get would refuse to proceed.

Thus in order to pull this off, the attacker would not only have to get access to a Debian mirror server, but also to the Debian master signing key, which should be well protected.

What if the bitcoin-qt package manager is the attacker?

@unor: Then you're in trouble.  Part of using a distribution is trusting the people who distribute it.

You know you don't have to trust the repo. The developers of Bitcoin-QT actually recommend using their binaries rather than the distro's. So you can just keep up to date with those. Official binaries are signed with a Bitcoin-QT developer's PGP keys.

You need ONLY private key to steal the money - you don't need wallet.dat file
Yes it's possible to do BUT it's easier and most profitable to break in any exchange or pool site and steal a loot more in one go

When Bitcoins are in an exchange people usually understand that there is a certain risk. However, I believe that most people assume that their Bitcoins are safe when stored on their local machine.


text:
Is there a Base58 encoder function that runs in pure javascript without node?
I see a lot of JavaScript Base58 encoder functions online, but all of them seem to require node.  Is there a simple JavaScript Base58 encoder that will just run in the browser without any node installation or modification?

Here's a pure javascript base58 encoder fuction I helped put together. Included are some comments that helped me understand what is going on beyond the barebones functions you can find elsewhere.
function encode_b58(hex_number) {
    // Set of base58 chars (Note: there is no '0','O','I' or 'l').
    const base58 = [1,2,3,4,5,6,7,8,9,'A','B','C','D','E','F','G','H','J','K','L','M','N','P','Q','R','S','T','U','V','W','X','Y','Z','a','b','c','d','e','f','g','h','i','j','k','m','n','o','p','q','r','s','t','u','v','w','x','y','z'];
    //Take input string of hexadecimal bytes and convert it to a base 10
    //decimal number. BigInt needed as regular JS numbers don't represent enough significant digits.
    var num = BigInt('0x' + hex_number);
    //Our very large number will be repeatedly divided by 58.
    const fifty8 = BigInt(58);
    //The remainder of this division will be a number (0-57).
    var remainder;
    //Each remainder's value maps to a character in our base58 array, and
    //the string of these characters becomes our Base58 encoded output.
    var b58_encoded_buffer = '';
    //We move from: Hex Bytes -> Decimal Number -> Base58 Encoded string.
    //To move through each place value of a base58 number, we continue to
    //divide by 58, until the integer number rounds down to 0.
    while (num > 0) {
        //The modulus operator returns our remainder, which depends on
        //the least significant digit in our BigInt converted input.
        //For example: if we were doing modulo 2 division, all odd
        //numbers - regardless of how long they are - would return a
        //remainder of 1, because the least significant digit is odd.
        remainder = num % fifty8;

        //Thus, we're encoding the right most (lowest place value)
        //digits first, and so each subsequently encoded character
        //needs to be added to the left of our encoded buffer
        //so that the beginning & end of our input string/bytes aligns
        //with the beginning & end of our Base58 encoded output.
        b58_encoded_buffer = base58[remainder] + b58_encoded_buffer;

        //Dividing by 58 gives us our quotient (rounded down to the
        //nearest integer), and moves us over one base58 place value,
        //ready for the next round of b58 division/mapping/encoding.
        num = num/BigInt(58);
    }

    //When we convert our byte-based hex input into a base 10 number, we
    //lose the leading zero bytes in the converted decimal number.
    //For example, if our hex input converted into the decimal number
    //000017, this number would be reduced automatically to 17 in base10,
    //and so we'd lose the leading zeros, which aren't important
    //when doing base 10 math, but are important in preserving the
    //information held in our original input value. So, in order to not
    //lose the leading zeros, we count them, and then prepend them (as
    //1's, which is their corresponding base58 value) to the beginning
    //of our Base58 encoded output string.
    while ( hex_number.match(/^00/) ){
        //For each leading zero byte, add a '1' to the encoded output.
        b58_encoded_buffer = '1' + b58_encoded_buffer;
        //And remove the leading zero byte, and test for another.
        hex_number = hex_number.substring(2);
    }

    return b58_encoded_buffer;
}


text:
As a full node, does limiting bitcoind bandwidth hurt the network?
As the top answer to this post, Maximillian Laumeister claims:
"IMPORTANT NOTE: If you limit the bandwidth of Bitcoin Core far below your actual upload speed, it can actually harm the Bitcoin network instead of helping it."
It would seem to me as though every contributing full node would only help the network (regardless of ISP speed). Does limiting the bandwidth of Bitcoin Core actually hurt the network (compared to not running a full node at all), and if so, how precisely?

The reason I added that section to my article is because Gavin Andresen, one of the Bitcoin Core developers, suggested in response to it that limiting bandwidth too much could be detrimental to the network because it slows block announcements:

gavinandresen
@maxlaumeister limiting number of connections is better for the network, limiting bwidth slows block announcements.
From Twitter

it slows the block announcements at your node level, but it's better than no block announcement at all (if you didn't have a node at all), right?

It would seem to me as though every contributing full node would only help the network (regardless of ISP speed). Does limiting the bandwidth of Bitcoin Core actually hurt the network, and if so, how precisely?

Not necessarily, but if everyone did it then yes.
If everyone actually trottled upload bandwidth so much that there is not sufficient bandwidth to bootstrap new nodes, then yes it is a major hindrance to future uptake.
In general, I believe the claim is applicable to the health of any peer-to-peer network, as oppose to just the bitcoin network. If the majority of users in Bitcoin are "leechers" and do not supply sufficient bandwidth to relay blocks and transactions, then clearly the bitcoin network will become less healthy as it will be harder for nodes to come into a consistent state and harder for new nodes to join the network.

It does not hurt the network; it just helps it less than the maximum potential amount you theoretically could be helping it.


text:
bitcoind JSON-RPC interface timeouts under unit tests
I am running unit tests against bitcoind which do JSON-RPC requests in high rate. Random failures are an issue. E.g. if you have something like this in printconsole logs:
ThreadRPCServer method=gettransaction
ThreadRPCServer method=gettransaction
ThreadRPCServer method=gettransaction
ThreadRPCServer method=gettransaction
....
ThreadRPCServer method=gettransaction
ThreadRPCServer method=gettransaction
sending: inv (37 bytes)
ThreadRPCServer method=gettransaction
ThreadRPCServer method=listtransactions
sending: inv (37 bytes)

You start getting:
synced with network?".format(name)) from e
cryptoassets.core.backend.bitcoind.BitcoindJSONError: Got timeout when doing bitcoin RPC call listtransactions.

I have tried with both reusing HTTP connection and not reusing HTTP connection with various results.
Are there any low hanging fruits to make bitcoind RPC interface more stable (increase threads, concurrency, etc.?)
I am using the following Python JSON-RPC implementation:
https://github.com/jgarzik/python-bitcoinrpc/blob/master/bitcoinrpc/authproxy.py
UPDATE: Looks like the problematic call might be listtransactions. When called at the same the time from command line using curl there is no response either:
[~]% curl --user foo:bar --data-binary '{"id":"t0", "method": "listtransactions", "params": ["cryptoassets"] }' http://127.0.0.1:8332/ |python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:--100    70    0     0  100    70      0     58

rpcthreads=64 seems to work around the issue, but doesn't explain what's happening.