Found an Air-Tite that fits.



More pics

Read this.

I describe a way to incrementally detach the wallet from the client.

Read the rest of that thread too.  It describes my notion of a hardware client, and as an added bonus, Gavin describes a service that would provide a lot of security for regular folks.  Actually, the thread was Gavin's, and all of my stuff was off-topic, but whatever.

Also, read this thread.

And while you are at it, read natman3400's posts, particularly on his project, BitClip.  We don't always agree on the details, but his project looks pretty good.

That's what a peg is.

Good to know that there are at least two other projects actually using the thing.

That said, I'm going to just say this publicly.  The X notation is stupid.  First, there was already a widely known and used notation for powers of 10.  And second the base unit, 1E-8 BTC is an accident of history.  The foolishness of basing the notation on this value will become obvious just as soon as the first 128 bit client extensions show up.

The only good thing about it is that it lets people use E notation, and do it in a way that makes sense.  So, I propose the following:

Amounts that match this regex:


should be interpreted using standard E notation, based around 1 BTC.  In E notation, xEy is shorthand for x * (10 ^ y).

Pegs are only possible under very special circumstances, none of which will ever apply to bitcoin.  Ever.

Situation 1 is where you can create at least one of the two currencies in unbounded quantities.  Really, you need to be able to do both, but if you can do just one, you can keep the game rolling for a long time.

Situation 2 is where the two currencies are identical, which makes the peg (and the new currency) pointless.  By identical, I mean created at the same time and in the same amounts, and totally identical supply and demand.

I don't know if they matter or not.  Like most things they are probably unimportant most of the time, but absolutely critical in a few cases.  Stripping the field names down to a for amount and l for label is probably a good idea in the same way.

Since you are working on the receiving end, you could always rig your client to accept short versions and long versions, plus absolute values and E notation.

By making a working implementation, and getting it out there in the wild, you are essentially defining the standard in a way that carries a lot more weight than just tossing some ideas on the wiki.

If bitcoind is running on the same box as the cart.  Even better, I think you can just have no rpcallow= line unless you have a damn good reason to accept remote connections.

There is one argument in favor of using E notation for the amounts.  People embed (or want to be able to embed) these URIs into QR code labels, and then scan them with cheap readers, meaning cell phones with cheap cameras.  More bits means higher resolution, which makes them less suitable for one popular intended use.

Although URIs are not intended to be human-readable, in practice, we do it all the time.  For all the computers care, we could represent the amount as the product of a string of complex numbers (as long as the final multiplicand conjugates the rest of the sequence).  So, because the computers don't care, we should make it as human friendly as possible.  10E-9 is far more readable than 0.00000001.  SI prefix abbreviations should be pretty readable too, so in the previous example 10n.

The hash rate reported by your client is the only place that the actual hash rate is measured.  Pools don't know and don't care about that, they care how many candidate blocks you return.  In the (very) long run, the measured hash rate and the rate estimated by the pool based on your shares should be fairly close, but that isn't a constraint on any particular interval of time.  The difference is commonly known as "luck" in the community.

If you suspect a problem with a pool, what you need to do is remove your personal luck from consideration.  Stop a few miners, clear the stats for those workers on the pool, then start the miners again.  If the shares reported by your client don't match the shared reported by the pool, then there is a problem with the pool.

There is a wiki page, but I've never seen it used.  Haven't exactly been looking, but still.

It seems pretty straightforward, at least for address, amount and label, so I think you should be pretty safe implementing it if you want.  If nothing else, someone has to go first.  But if you do, please, please, please use E for the exponent instead of X.

There are people working on these devices, and hundreds of threads on the subject.  Anyone interested in the idea should search, because this thread is almost word for word identical to many of them.

See this chart.

Chart taken from this article.  I don't agree with the conclusions necessarily, but it gives a good discussion of the exchange mechanism and demonstrates how sterilization works in the real world.

Can you spot the one critical feature in the chart that explains how PBC is able to hold a peg?  Do you understand how the lack of that feature will make it impossible for you (or anyone else) to maintain a peg?

I love ignorant forum lawyers.

The courts have been dealing with intangibles for hundreds of years.

If you already have the hardware, then yes, it is profitable.  But unless you get an insane deal, right now a card will probably not pay for itself over time, even ignoring other costs.

The model that I've been considering is reinvesting the output from my cards back into new cards to sustain/grow income.  That model does not currently work, production gradually tapers off towards zero.  It takes nearly 1% daily growth in the exchange rate to grow income, and we are going in the wrong direction.

The bot is selling to you, and then using some sort of magic to drive the price lower so that it can buy more to sell to the next guy.  It is essentially a short, but without borrowing.

If the bank is sending checks drawn on the bank's own account, then you are right, those checks will not bear his account number.  Those checks will also be paid for up front, rather than at clearing.  Oh, and I've never seen a bank offer a service even remotely like that as a mainstream normal activity, while every bank in the country is completely willing to print and mail checks bearing the customer's account numbers, either for free, or for a nominal fee.

If it doesn't have your routing and account numbers on it, it isn't a check.

I'm pretty sure that even a lawyer bad enough to get stuck working as a judge can see that bitcoin is very clearly neither a way to store USD, nor a way to prepay for anything.

So, uh, how exactly does the bot "make the price lower"?  Can you think of any way to do it that doesn't involve reducing their asking price?

If you've made it this far, can you think of a strategy to counteract this type of bot?

Oh, and feel free to add me to your list.  My bot doesn't act at all like your paranoid hallucination, but it is a bot.