Topic: Bitcoin parity. - page 2. (Read 9974 times)

In a hyper efficient market I would assume that you could get a better deal on goods for paying earlier and/or taking delivery later. Obviously we already see this in shipping. Overnight costs more than standard. And we see what happens if you want to pay months or years after you take delivery, you pay more (interest). This really isn't different than a discount for paying before you get the item. It is valuable to a producer to know in advance who needs what when and where and prepaying is the surest way to prove your future demand for an item. There's no reason a producer wouldn't pay to get this info.

I could imagine buying a Pepsi and paying with bitcoin and the store instantly forwarding part or all of that payment to their Pepsi supplier as prepayment for the next shipment. It could be in the very same block! Demand information passed on virtually instantly. It doesn't stop there, Pepsi uses the payment to 'notify' their corn syrup supplier, their plastic bottle supplier, etc. This is not necessarily caused by bitcoin though, it's just a conjecture I have about future efficiency. It could conceivable happen with a central currency too.

This all comes to mind because obviously it increases velocity. I guess the big question is whether there is good reason to be a bitcoin holder or whether it makes the most sense to trade in and out of some other store of wealth on some short cycle. 

I know right now that I'm willing to hold a decent amount of crappy money because it's super liquid and my expenses are somewhat uncertain. As bitcoin to dollar trade because quicker and easier I will hold fewer and fewer dollars. Beyond a certain point though I want an appreciating asset over liquidity, once bitcoin has reached saturation in terms of breadth and velocity is increasing it might not be as attractive to hold bitcoins as it is to me now.

On the other hand I feel like a good currency pays you for deferring consumption. I suppose that would be true in a stable bitcoin velocity economy that was growing. Ah, maybe what you get paid the most for is announcing (by paying) what you'll be needing immediately after you produce (and get paid) but waiting as long as reasonable to actually take the thing.

I hope some of that is clear, I'm not really sure of any of it.

When you say "be mathematically proven it won't go awry using finite state machine models" do you mean that incase the bits holding the registers for the finite state machine get flipped (and thus may enter into a random state), that the state machine transitions must be robust such that it will gracefully return the state machine back to a known legitimate state?

When you say "be mathematically proven it won't go awry using finite state machine models" do you mean that incase the bits holding the registers for the finite state machine get flipped (and thus may enter into a random state), that the state machine transitions must be robust such that it will gracefully return the state machine back to a known legitimate state?

That was speculation. We're back to ~0,33.

It was taught in CS class that some critical NASA programs have to be mathematically proven it won't go awry using finite state machine models. Any digital currency that becomes foundation of the commerce of modern society, it has to undergo same process, I think.

Overview

I2P's netDb is a specialized distributed database, containing just two types of data - router contact information (RouterInfos) and destination contact information (LeaseSets). Each piece of data is signed by the appropriate party and verified by anyone who uses or stores it. In addition, the data has liveliness information within it, allowing irrelevant entries to be dropped, newer entries to replace older ones, and protection against certain classes of attack.

The netDb is distributed with a simple technique called "floodfill", where a subset of all routers, called "floodfill routers", maintains the distributed database.

RouterInfo

When an I2P router wants to contact another router, they need to know some key pieces of data - all of which are bundled up and signed by the router into a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity as the key. The structure itself contains:

The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate)
The contact addresses at which it can be reached (e.g. TCP: example.org port 4108)
When this was published
A set of arbitrary text options
The signature of the above, generated by the identity's DSA signing key

...

Bootstrapping

The netDb is decentralized, however you do need at least one reference to a peer so that the integration process ties you in. This is accomplished by "reseeding" your router with the RouterInfo of an active peer - specifically, by retrieving their routerInfo-$hash.dat file and storing it in your netDb/ directory. Anyone can provide you with those files - you can even provide them to others by exposing your own netDb directory. To simplify the process, volunteers publish their netDb directories (or a subset) on the regular (non-i2p) network, and the URLs of these directories are hardcoded in I2P. When the router starts up for the first time, it automatically fetches from one of these URLs, selected at random.

Floodfill

The floodfill netDb is a simple distributed storage mechanism. The storage algorithm is simple: send the data to the closest peer that has advertised itself as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them for the entry to be sent, verifying its proper insertion / distribution. If the verification peer doesn't reply, or they don't have the entry, the sender repeats the process. When the peer in the floodfill netDb receives a netDb store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers. The peers selected are the ones closest (according to the XOR-metric) to a specific key.

Determining who is part of the floodfill netDb is trivial - it is exposed in each router's published routerInfo as a capability.

Floodfills have no central authority and do not form a "consensus" - they only implement a simple DHT overlay.

We should be busy trying to make the network as resilient as possible. This reliance on IRC and a few hard-coded nodes is an obvious weak point. The protocol should be hashed out rapidly and implementations should be as secure as possible. If the protocol is set, the software is solid and the network strong, then bitcoin has hope. The value will sort itself out naturally.

MtGox just made a jump. We are at 0.4 USD per BTC now.

The velocity point is something I hadn't thought about. I think there is a tendency for a finite currency to gain value over time. This reflects the fact that someone who works first and waits to enjoy the fruits ought get more. This should keep the velocity from absolutely exploding.

I think that if B gets even close to $ parity - not to mention gold parity - the network will be attacked - physically if not legally - by some governments and/or powerful banking groups.

One of the guys on the show Bruce Wagner did the other day, had some valid points: p2p networks are not indestructible. Plus, it wouldn't take complete BTC-network destruction to ruin public confidence in it and devalue it, perhaps, forever...

http://thinkingliberty.net/podpress_trac/web/590/0/Thinking_Liberty_-_2011-01-11.mp3

I think what we as a community need most of all for fast Bitcoin adoption and parity is an army of whitehats involved in it - testing, hacking, reviewing code, brainstorming attack response scenarios, etc.

If and when Bitcoin hits the mainstream, just one successful attack on it could delay complete adoption for years, or worse...

...Maybe BTCs velocity goes so high that Amazon could earn US $31 billion worth of BTC with BTC valued at only $10/BTC.

Let's say by that time there are 10M bitcoin in circulation, 10M x 10= $100M.

By comparison, Amazon's 2010 revenue is 31B, 310 times bigger.

To be a viable online transaction media, the size of bitcoin economy has to be comparable and the exchange rate needs to reach $1000/BTC

To be a viable online transaction media, the size of bitcoin economy has to be comparable and the exchange rate needs to reach $1000/BTC

I believe the idea is to simply handle division with better naming, like sending 35uBTC (that's micro btc or 0.000035).