Personally, I give more leeway to names I recognize as experienced (except for those I recognize as experienced trouble-makers). The simple fact of the matter is that the prior probability of misconduct tends to be lower for experienced users, and so, comparatively, the chances that I'm the mistaken party is greater.

If people are frequently engaging in conduct where it matters where the benefit of doubt lands ... you have greater problems to worry about than a somewhat biased moderation policy.

No, you can only merge-mine coins which are designed to be merged mineable. Not all of them are.

You can also do this if you run P2Pool, FWIW— P2Pool pools your Bitcoin mining (but in a secure decentralized way) but also gives you the freedom to merge mine anything that can be merged mined. (You're a solo miner on the merged mined things).

You cannot switch BDB versions on a wallet that wasn't cleanly shut down on the prior version, I'd guess thats whats happening here.

Well even ignoring the non-even bob part, the classical across chain contracts are trivially traceable by everyone.

3.6GBytes VM isn't huge for a process which uses mmap, note the res is just 777MBytes.

Can you run uname -a on that system as well as file /path/to/your/bitcoind  and show me the results?

If blocksize isn't scarce at all why not include every transaction that pays at least 1e-8 BTC which you've already received and validated?  If it's purely orphaning that influences your decision why won't all your spending go to bandwidth (neutrino links to other miners and such ) and none to POW? etc.

Yea, its a real problem and personally the only negative thing I can say about the product. Unfortunately it's not just a cosmetic limitation... (Even noise, I mostly consider that a cosmetic limitation, at least for a >$1000 miner— we're not talking about a coffee warmer here ) but fortunately it should be easy to fix.

Weird that you say that, I wrote glowing comments about the noise level about my single blade s1 in my yet-unpublished-review.

I hope there will be an easy way to use these cards with desktop and laptop computers and not just smartphones.  I'm eagerly awaiting this, it should be an interesting system.

You are presenting a false choice. The choice is not "centralized systems" OR "everything in Bitcoin". There are many options to build non-centralized ways of settling payment on a decentralized Bitcoin— ilpirata79 linked to one such approach. A lack of care into the operating costs of Bitcoin nodes may result in Bitcoin itself becoming effectively centralized, which is an outcome which would make building a non-centeralized payment method on top of Bitcoin pointless or impossible.

Go look in the regular hardware forum... most of what gets put there gets moved by mods into custom hardware, and most of what remains is arguably misplaced anyways.

I propose we merge custom hardware into mining hardware: All viable bitcoin mining hardware today is "custom" to some extent. I also propose we create a "mining hardware development" subforum to host the small amount of actual development discussion.

Thoughts?

This is a very inefficient and destructive way to perform this tasks. I would not recommend using or promoting this service.

Not enough information to help. You may have added or lost some characters from it, but thats my best guess.

I think you should be careful to distinguish Bitcoin the currency and Bitcoin the payment network when you speak because on this matter what you can "never" do is quite different depending on which you're speaking of— I know you know this but the language makes it unclear.

The Bitcoin Foundation plays no formal role in the development of Bitcoin. The foundation is a 501(c)(6) professional organization created fairly recently (last year) in order to help sponsor and promote Bitcoin.  If the foundation did have control over Bitcoin it would be very bad indeed, as they could be ordered to abuse that control. Fortunately, they do not. If you wanted you could start your own Bitcoin foundation.

Bitcoin is, foremost, an autonomous zero trust system. Every Bitcoin node such as the reference client software (Bitcoin-QT), run by anyone who wants to,  independently validates that the messages they receive from the network conform to all the rules written in the software they trust no one. As such, "majority" is generally irrelevant in terms of the system's rules. They cannot be violated by just a simple majority of anything... though if some kind of super-majority of Bitcoin _users_ wanted to adopt different rules, they could: they would arguably be using another system though.

Unfortunately, there is no way to decide the ordering of events in a decentralized and purely autonomous manner, so Bitcoin uses a computational majority to order transactions via mining... Ordering is powerful but the inability to control more than ordering is believed to be part of the incentive balance that keeps mining mostly honest.

As of yet, we've (the Bitcoin community) never really changed the system in a way that wasn't backwards compatible with the earlier versions at least at the rules level— save one exception which was that versions prior to 0.8 would non-deterministically refuse to validate some blocks processing large numbers of transactions and fixing this bug was a not-completely-backwards-compatible change to the system rules.

It's possible to add new restrictions to the rules without breaking backwards compatibility (e.g. transactions not consistent with the new rules are just ordered infinitely far into the future) and this has been done a couple times to correct bugs and provide some new functionality. To make these changes safely it requires a decisive super-majority of mining to be enforcing the new restrictions. Fortunately the protocol itself can coordinate this by miners signaling with a bit in their blocks that they will start enforcing the rules when— say— 750 of the last 1000 blocks have the signal bit.

Anyone who wants to can develop Bitcoin software, and many people— advisably other otherwise— have.

Any chance of posting the source code for the firmware images on the devices?

The current firmware is based off an old copy of cgminer which has poor performance for large blocks or large coinbase transactions. As a result I'm seeing 100% cpu usage and a stale rate several times higher than my avalons.  This could easily be fixed by porting the driver to bfgminer or a current cgminer (or backporting some of the work generation improvements from newer cgminer), and I'm willing to give it a shot at doing it myself— but I need the source.

Then someone starts maximum rate dust flooding transactions and people are forced to include them. Good job. Worse— they send floods of orthogonal transactions to different nodes on the network and now can freely trigger forking by effectively partitioning block propagation.

There is nothing in the protocol that can be changed to effect that substantially. Uncertainty and variability in time to irreversibility is inherent in an anonymous consensus system. Twiddling around parameters may change the distribution of values somewhat, but there will always be long confirmation times intermittently.

The same way they use credit cards— which are not irreversible for months, Bitcoin is irreversible very fast compared to credit cards.... or through any of several different ways to achieve instant irreversibility with some tradeoffs externally to the network.