The rounding error was an unintentional result of me taking the form input and running it through parseInt, which truncates all decimal precision. I've changed that to parseFloat - the discrepancy is now resolved.

Hi there, I'm the co-founder and CTO of Casa! Just stumbled across this thread and figured I'd chime in to address concerns.

To start off, we've outlined our threat model and design decisions here in our Wealth Security Protocol: https://docs.keys.casa/wealth-security-protocol/.


This is a valid concern, and our Gold tier is "bring your own hardware" while our premium tiers include devices. We are authorized resellers for both Trezor and Ledger. Users are welcome to buy directly from them if they wish to further reduce supply chain risk!


You can certainly skip backups if you want, though we believe this is the best trade-off between convenience, security, and redundancy for the average user. Advanced users may be capable of securing seed phrase backups, but we believe this is asking too much of casual / mainstream users.


There are so many risks that go unstated when people say "store your seed phrase in a safe place" that it's laughable. I've performed extensive tests that show many seed backup devices are actually can't withstand common house fires, for example. And if you put a seed phrase in a safety deposit box it's still vulnerable to the bank itself and to state actors that can coerce the bank. We do recommend storing a coldcard in a safety deposit box, however, as the hardware then provides another layer of security against insider / state level attacks.

TL;DR you may not agree with our thesis that the average user isn't capable of securing seed phrases against all of the attacks that our security model protects against, and that's OK.


This is a misunderstanding - the Emergency Lockdown feature is not available to 2-of-3 multisig accounts, only to 3-of-5 accounts. When activated on a 3-of-5 account they still have a sufficient threshold of keys to route around our service without the Mobile Key if necessary. We take great care to ensure that Casa can not unilaterally create or block transactions; we strive to eliminate any single points of failure, including our own service. For further clarification you can view our step-by-step recovery guides at https://walletsrecovery.org/recovery-docs/casakeymaster-recovery.html

Also worth noting that for 2-of-3 we support using 2 hardware devices and no mobile key, which I believe alleviates several of the concerns you voiced.

I'm not on this forum often; feel free to direct further questions to me via any of my verified accounts listed on https://keybase.io/lopp or ask our support team at help@team.casa!

I don't know; how many times did Silk Road crash?

Hello all,

I'm a software engineer who has spent much of this year trying to gain a better understanding of Bitcoin's network of nodes and I'm now at the point where I could use feedback and support from the community.

My journey began when I asked the question: How many Bitcoin nodes is enough? Many people were worried about the declining number of nodes, myself included, but I wanted to prove or dispel those worries with hard numbers.

To help answer this question I created the Statoshi fork of Bitcoin Core and began digging deeper into the messages being passed around between nodes.

After a few months I felt that Statoshi was ready for node enthusiasts to run on their own and released the project. The setup process is fairly complicated due to all of the software dependencies, but I hope to make this process much easier by eventually releasing Docker containers that will handle the dependencies automatically.

Because I want these statistics to be readily available to the public without requiring installation of Statoshi, I built a public dashboard that is easier to use. You can find it at http://statoshi.info

After monitoring the network for 6 months, I posted my findings regarding the health of the node network. Long story short, the network is healthy but we always desire more nodes to make it more robust and decentralized.

I have plenty of ideas for the future direction of this project, some of which I outlined in this post.

If you're interested in this project, I would appreciate your help. Potential ways you could contribute:

• Post ideas for new stats / charts / features, either on here or by creating an issue on Github.
• Submit pull requests for new stats collection to the Github project.
• Play around with building custom charts on statoshi.info to see if you can find any interesting correlations. If you're unfamiliar with Grafana you can watch some how-to screencasts here. If you build a chart that may be useful for the community you can save it as a JSON payload and send it to me to store permanently.
• Donations to my 1STAToshi address will only be used to pay for server costs; my current costs are $40 / month for the statoshi.info server
• If you have high bandwidth servers that you'd be willing to donate toward running a fleet of managed Statoshi nodes, that would be greatly appreciated.

Anyone who wishes to contact me off-forum can find me through https://onename.io/lopp

Are you still there, BitcoinAverage? Your Twitter bot has been broken for over a month... https://twitter.com/bitcoinaverage

Yes, Grafana is highly customizable and all of the graphs are editable. You can even build your own charts from scratch, though I have it locked down so that you need the admin password in order to permanently store them. If you compose a chart on statoshi.info that you think would be useful for the general public, feel free to save it as a JSON payload and send it to me; I'll add it as a permanent chart.

As for machine specs, I'm running on a single core VPS with 30 GB of disk (that I'll need to bump up soon) with 4 GB of RAM, though bitcoind only uses about 1.5 GB. My node uses ~150 GB of (mostly upstream) bandwidth per month. I hope to eventually make it easier for people to install the entire software stack required to run a Statoshi instance; at the moment it requires a fair amount of Linux admin skills to install & configure.

My full node metrics: http://statoshi.info

I'm running a fork of Bitcoin Core that emits metrics to Statsd, which are then collected by Graphite and rendered with flot graphs by Grafana.

https://medium.com/@lopp/announcing-statoshi-realtime-bitcoin-node-statistics-61457f07ee87

https://github.com/jlopp/statoshi

Looking at the price alone is worrisome, but I've seen more innovation in the Bitcoin ecosystem in the past 6 months than in all the time prior. I suspect that eventually these new services will result in greater adoption and the price will rise again along with demand.

As a similar stopgap measure, Bitcoin Core provides a Quality of Service bash script for Linux users that will throttle bandwidth usage. https://github.com/bitcoin/bitcoin/tree/master/contrib/qos

Excellent. I added in the functionality over the weekend and the only way that seemed appropriate was to call CloseSocketDisconnect(), but I'm not nearly as familiar with the codebase as you!

I'm working on a daemon to manage peer connections across multiple nodes but seem to have hit a wall when it comes to instructing a node to disconnect from a peer. I have succeeded in using the 'addnode' command to get my nodes to connect to specific peers, but apparently using the 'remove' option does not force a disconnect from the peer.

Is there any way for me to achieve peer disconnects via the RPC API?

If not, would it make sense for me to submit a pull request to add a 'disconnect' option to the 'addnode' RPC call?

It's complicated. TL;DR the consensus is that first we need to fix the inefficiencies in how Bitcoin Core transmits data, as that could alleviate many of the problems. Here's the 3 year long debate on the subject: https://github.com/bitcoin/bitcoin/issues/273

The block size limit in the protocol will not become an issue until transaction fees become a more substantial portion of mining revenue. As it stands at the moment, there is a market-based soft block size limit that results due to the economic incentives that miners face due to block propagation races. Since transaction fees are eclipsed by the block reward, miners are incentivized to publish smaller blocks with fewer transactions.

Malla: http://bitcoinmagazine.com/10625/cryptocurrency-castle/

No one knows the future, but predicting that the exchange rate of bitcoins will remain stagnant for 6 months is the most outrageous prediction that one can make.

I didn't check the wallet software for trojans, however, I recently performed an audit of Rimbit's code repository on Github. It is, quite simply, a clone of Novacoin with absolutely no new features. All they've done is tweak a few of the parameters from Novacoin and re-branded it. There is no compelling reason to use Rimbit so far as I can tell.

I can answer the "is it good" question. I recently performed an audit of Rimbit's code repository on Github. It is, quite simply, a clone of Novacoin with absolutely no new features. All they've done is tweak a few of the parameters from Novacoin and re-branded it. There is no reason to use Rimbit so far as I can tell.

We're trying to bootstrap a new DIY hardware market for Bitcoin users at https://www.tindie.com/m/bitcoin/

If you have any custom hardware that you've developed, please list it for sale. If you know anyone with a hardware project, please pass along this post.

Have any ideas for hardware you'd like to see developed? Discuss it here!

I, for one, would love to see an all-in-one plug and play Bitcoin node with its own Web UI for configuring and updating the node software. Bonus points if it supports bandwidth throttling.

A 51% attack cannot create more coins other than the normal block reward, thus it cannot cause an increase in the inflation rate. https://www.youtube.com/watch?v=bTPQKyAq-DM&feature=youtu.be&t=48m56s