Quote from: Stephen Gornick on June 17, 2011, 03:20:08 AM

Quote from: luxgladius on June 17, 2011, 12:18:11 AM

1. The ten-minute limit: The Bitcoin system is designed so that a block is produced, on average, every ten Most restaurants aren't going to want to wait 30 minutes to make sure your money's good before giving you your cup of coffee.

Perhaps a move to a block per minute or two,

Bitcoin wasn't meant to allow instant confirmation. That 10 minute wait was determined as the length necessary due to latency on a global network.

I guess that's my question. How was this 10 minute wait chosen? It has the feel of a number that was just picked out of the air, and obviously it couldn't be tested as the network exists today, because the network didn't exist. Is it agreed that higher block volume would be more advantageous in the long run? Aside from the headers, I don' think it would increase the bandwidth requirement of the network. There would be more blocks, but they would contain fewer transactions. If the study hasn't been done yet, maybe I can do some parsing magic and see how long on average a block takes to get to me from the time it claims it was originated. Not perfect since the clients aren't guaranteed to have synchronized clocks, but better than nothing.

Quote

Obviously, that type of payment represents a lot of payment volume that bitcoin is leaving on the table. There have been multiple ideas on how to allow bitcoin to serve this function. None of the ideas address reducing the length of time to confirm blocks as there's no lower value that would solve the "point of sale" problem yet would still allow Bitcoin to work. As [Mike] from the forum put it, you either are "< 5 seconds or > 5 seconds". So neither 1 minute nor 10 minutes to confirm makes a difference for making point of sale more possible.

Fair enough. Though it seems like an escrow system could work in this case with a 2-3 minute wait being acceptable.

Scenario: Alf walks into Bernie's restaurant. Bernie seats him and asks for a proof of credit. Alf authorizes a transaction on his NiftyBitcoin(TM) device for some amount that's sure to be enough to cover his meal, keyed to require both his and Bernie's signature to unlock. (This kind of transaction is actually possible with the existing system, which is a credit to Satoshi for having foresight. Of course, the official client doesn't support it yet, but the protocol does.) He then proceeds to place his drink order. Bernie brings by his drink, and while he does so, he receives confirmation that the transaction is now three blocks into the network, which is possible because of the average 1 minute block time. Bernie then takes his meal order, Alf eats his food, and at the end, they both authorize a transaction from the escrow account into their own respective accounts. (The bill amount and the "change", respectively.) If anything goes wrong and Bernie proves untrustworthy, then Alf is only out the cost of an expensive meal and Bernie gets nothing. Likewise if Alf refuses to pay, Bernie is out only the cost of the food and Alf has at least lost his money. (And he'll be subject to standard dine-and-ditch laws.)

Quote

Right now, there is a solution. As long as both the merchant and customer use the same ewallet provider, transactions can be instantaneous. MyBitcoin works this way already today. Similarly, another solution might be simply to advance some amount to an account with the merchant or with some other intermediary. Consider if the mobile point of sale vendor Tabbed Out were to add bitcoins as a payment method, for example. They would hold your coins in their wallet so those coins would be spendable instantly regardless of which restaurant you dined at. With those solutions, however, you have the drawbacks where you must extend trust to an intermediary and lose some privacy.

One other idea includes a pure bitcoin method where low value transactions might be allowed on receipt by the merchant with no confirmations. This method assumes however that there are listening posts on the network that would monitor for double spends and alert the merchants after any double spend attempts were discovered.

Additionally, there have been reports that work is underway to integrate bitcoin with the Open Transactions platform to allow transactions that are both anonymous (as far as the merchant knowing the buyer) and also are instant, requiring no confirmations. This too requires pre-paying bitcoins to the OT account that will be used for spending.

It seems like all of these scenarios require a trusted third party, which seems somewhat counter to what Bitcoin's vision is. With a central point of confirmation, you're still having a central point at which skullduggery can take place, funds can be seized, accounts can be frozen, etc. The requirement that both have the same merchant just exacerbates this problem, as this means that the system will gravitate towards centralization with powerful merchants (VISA, AMEX, etc.) having de facto control of your Bitcoins.

Quote

Quote from: luxgladius on June 17, 2011, 12:18:11 AM

2. It seems like having a drastic drop like that could lead to some nasty effects.

With that drop, it's hard to imagine a substantial fraction not taking their machines offline and scaling down.

When it happens the drop from 50 to 25 will not come as a surprise.

Considering the worst case you describe (50% of mining capacity drops in response), instead of 14 days of 10 minute block confirmations it is 28 days of 20 minute block confirmations. Since transaction fees reflect a growing part of the block bounty, a 50% reduction in currency issued will not have a 50% reduction of income to the miners. Eve so, is this big drop to the miners going to be felt? Yes. Is it a serious enough problem to force a change to the protocol? I wouldn't think so.

The fact that miners "get hit" is really not a concern. Bitcoin is likely already well beyond the amount of mining necessary to be protected from an attacker with lots of hashing power. It likely could survive just fine if half the the miners it currently has were to disappear at any point in time.

I'm less concerned about the miners "getting hit" rather than the effect that will have on the system in terms of a dynamic response. As I said, yes, the market will find a new equilibrium eventually, but in the meantime, the rate of incoming blocks will be reduced and each block will produce less, so the system will become clunky. Miners may panic and pull out. The network rate drops more. However, this causes the cost of Bitcoins to rise, so after the next difficulty correction, miners get back into it at some level. The increased power requires another drastic correction to difficulty, and the network gets clunky again. Repeat ad (market) nauseam.

My point is, if we can avoid this underdamped response to the change by making it gradual rather than abrupt, I would think it would be better for the system as a whole.

Quote

Quote from: luxgladius on June 17, 2011, 12:18:11 AM

I'm aware that these limits and algorithms are hardcoded into the system now, and would require a change to every client in existence. However, that's not a sufficient reason to not have them implemented.

it's part of the algorithm, it can't be changed. :-)

Stand back, I'm about to do the impossible!

Old code:

Code:

int64 GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 50 * COIN;

// Subsidy is cut in half every 4 years
nSubsidy >>= (nHeight / 210000);

return nSubsidy + nFees;
}

New code:

Code:

#define RAMPTHRESHOLD 185000
// Make sure RAMPTHRESHOLD divides evenly, or something bad might happen
#define RAMPINCREMENT (25*COIN/(210000-RAMPTHRESHOLD))
int64 GetBlockValue(int nHeight, int64 nFees)
{
assert(nHeight >= 0);
int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 4 years (but with a gradual rampdown)
nSubsidy >>= (nHeight / 210000);
int nHeightInInterval = nHeight % 210000;
if(nHeightInInterval >= RAMPTHRESHOLD)
{
nSubsidy -= (RAMPINCREMENT*(nHeightInInterval-RAMPTHRESHOLD)) >> (nHeight/210000);
}

return nSubsidy + nFees;
}

MtGox and other assorted major exchanges/vendors with foresight: We will only honor Bitcoins generated with the new code after block 185000.
Community: Does it affect anything we're doing in our money-crazed ways right now? No? Then ok.