[7.3 btc bounty] Implement demurrage in an alternative chain with merged mining

[jtimon]

After many discussions in the forum about Silvio Gesell I have decided to take a little step fordward for freicoin.

I think the task is not hard and that (even if I'm the only one to contribute to the bounty) the reward can get sufficiently encouraging with time and bitcoin rises in prices. I just don't have the time right now.
It would be interesting to integrate it on multicoin.

The winner will be the first to implement a bitcoin-like currency with built in demurrage and that can be merged mined like namecoin will be.

I hold the coins now, but if a moderator of the forum or just someone with more reputation does me the favor of holding them, probably more people will be willing to put their coins for the bounty.

You can donate by sending you contribution here:

1N9u8az3nkztXP3xUcYFhoFsNAvARxBowq

http://www.freicoin.org/

[1713867738]

1713867738

[1713867738]

1713867738

[vector76]

How would you want to handle the problem of rounding?

Not that I think it will have a lot of financial significance, but it is possible to get into situations where multiple txouts could yield slightly different total value depending how they are spent.

There is also the problem of agreeing on time, and even the time between when a transaction is issued and when it is included in the block chain could make a transaction over-spend its (now shrunken) inputs, or create other sorts of "slightly off" errors.  It might make sense to define the demurrage time in terms of the block chain and not in terms of 'wall clock' time.

An alternative is to have the underlying implementation store non-shrinking coins as they are now, with no demurrage, and to change the user interface to map a nominal demur-coin to the underlying non-shrinking coin according to a formula.  Then the underlying implementation would be represented in terms of coins-at-a-particular-point-in-time which are converted to present nominal demur-coins by a pre-determined time-dependent ratio.  There is still the problem of 'slightly off' errors if someone is asking 1 DMC in payment and you make the 1 DMC payment but by the time they receive it they get only 0.99999999 DMC.  If this is a human recipient it makes no difference but an automated payment processor could reject it.

[jtimon]

How would you want to handle the problem of rounding?

Not that I think it will have a lot of financial significance, but it is possible to get into situations where multiple txouts could yield slightly different total value depending how they are spent.

I have to admit that I haven't though much about problems related with rounding errors. Can you give an example of a problem that could raise?

There is also the problem of agreeing on time, and even the time between when a transaction is issued and when it is included in the block chain could make a transaction over-spend its (now shrunken) inputs, or create other sorts of "slightly off" errors.  It might make sense to define the demurrage time in terms of the block chain and not in terms of 'wall clock' time.

Like I said here I was thinking in account the demurrage by blocks instead of years. This way we take advantage of the "internal clock" of the network.

An alternative is to have the underlying implementation store non-shrinking coins as they are now, with no demurrage, and to change the user interface to map a nominal demur-coin to the underlying non-shrinking coin according to a formula.  Then the underlying implementation would be represented in terms of coins-at-a-particular-point-in-time which are converted to present nominal demur-coins by a pre-determined time-dependent ratio.  There is still the problem of 'slightly off' errors if someone is asking 1 DMC in payment and you make the 1 DMC payment but by the time they receive it they get only 0.99999999 DMC.  If this is a human recipient it makes no difference but an automated payment processor could reject it.

Yes, the idea is to not touch the blocks once they're hashed and just interpret the balance of each output taking demurrage into account.
All the inputs less their demurrage have to be greater or equal than all the outputs for a given transaction to be valid.

I didn't saw the problem of specifying an exact amount. Even if the change (the one that goes back to the sender) takes the losses from demurrage, you have to specify what is the "change" output. You also have to specify either the block count when the transaction was created or the transaction fee explicitly if you want to ensure you pay a transaction fee.
If we consider the later option, it could be an example:
Output 1: 50 (to the recipient)
Output 2: 49.98 (your change back to you)
Output 3: 0.01 [tx fee] (to the miner)
Output 4: 0.005 [losses from demurrage] (back to you if is not all spent)
Output 5: 0.005 [tx fee] [losses from demurrage] (to the miner if is not all spent)

Probably output 5 can be removed and any input freicoins not redeemed in an output are considered a transaction fee if they're not consumed before starting to charge output 4.
If both output 4 and 5 (or frc not claimed by any output) are spent, the transaction becomes invalid and will no longer be able to appear in the chain.
The unclaimed coins are the first that are going to perish by demurrage, so if you want to ensure you add a transaction fee the indicator is needed for a special type of output (maybe just sending the coins to a null address known by the network).
To indicate what is going to be the losing output, the convention could be that it is the last output. If you want to limit the minimum change you're going to receive you can add two outputs to the same address.

This demurrage is only to be applied if the inputs are less than the outputs and until the transaction is in the chain. After that all outputs suffer from demurrage in the same proportion.

Thank you for pointing out the problem.

[jtimon]

I came up with a solution for the "exact payment problem" that I think is more elegant. It doesn't need new fields but constants for the fields address and value/amount of the output.

1) A constant destination address TO_MINER (= 0 ?) which allows you to specify the transaction fee explicitly within an ordinary output.

Now the unclaimed coins don't go for the miner but to take the potential losses of demurrage during the transaction.

2) A constant amount of the output (= 0) to specify the address where the not claimed but not destroyed by demurrage coins must go. 

If no "demurrage change output" is specified, the unclaimed change goes to the miner. This way you can encourage miners to include it fast.
If various are specified, the coins are distributed proportionally. This way you can share the tx demurrage losses with the recipient in any proportion you want.

When the unclaimed coins are all "spent", the transaction becomes invalid and can not get into the chain anymore. This way you're effectively putting an upper limit on how long can (in blocks) take the transaction to be put in the chain without adding an expiry field.

Still we don't have to touch any structure from bitcoin, only how balances are interpreted.

[nodemaster]

I don't know if Freicoin ever will work on a large scale. But in fact no one knows since it has not been done before. In Germany I know about a few local clubs who have some sort of Gesells Freigeld and it seems people like it on a local scale. Furthermore I belong to the few people who are not interested in cryptocurrencies for making quick money. And I feel like we need to get this implemented just in order to see if it works. If it don't work on a global scale I guess there will be plenty of local adopters. Because as soon as freicoin is implemented we might see local clubs adopt this to get their Freigeld system online.

Added 2 BTC to the Bounty 

[jtimon]

I don't know if Freicoin ever will work on a large scale. But in fact no one knows since it has not been done before. In Germany I know about a few local clubs who have some sort of Gesells Freigeld and it seems people like it on a local scale. Furthermore I belong to the few people who are not interested in cryptocurrencies for making quick money. And I feel like we need to get this implemented just in order to see if it works. If it don't work on a global scale I guess there will be plenty of local adopters. Because as soon as freicoin is implemented we might see local clubs adopt this to get their Freigeld system online.

Added 2 BTC to the Bounty 

Thank you!

As you say, if it doesn't work on a global scale, each town can run its own freicoin chain.
If you or the people from the local clubs are interested, we're discussing some of the details of the implementation (the demurrage rate, the generation curve, etc) here:

http://www.freicoin.org/

[jtimon]

http://www.freicoin.org/implementations-details-and-bounty-t13.html#p129

For modifying the generation curve, the fuction we have to change for the generation is this:

main.cpp

Code:

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

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

    return nSubsidy + nFees;
}

to

Code:

int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy;
    if (nHeight > EQUILIBRIUM_BLOCK) {
		nSubsidy = EQUILIBRIUM_REWARD;
    } else {
	    nSubsidy = INTIAL_REWARD + ((nHeight - 1) * DECAY);
	}
    return nSubsidy + nFees;
}

The constants would be defined like this:

Code:

#define EQUILIBRIUM_REWARD 1000 * COIN //this can be changed
#define MAX_BASE 1000000000 * COIN //1 Billion, this can be changed
#define EQUILIBRIUM_BLOCK 250000 // 5 years, this can be changed
#define DEMURRAGE_RATE 0.0001 // 1 - 0.0001, ~5% annual, this can be changed 
#define DECAY 0.008 // can be changed
// MAX_BASE  = (EQUILIBRIUM_BLOCK/2) * ((2*INTIAL_REWARD) + ((EQUILIBRIUM_BLOCK - 1) * DECAY)) - DEMURRAGE_CHARGED_UNTIL_EQUILIBRIUM
#define INTIAL_REWARD ((((MAX_BASE + DEMURRAGE_CHARGED_UNTIL_EQUILIBRIUM) * 2) / EQUILIBRIUM_BLOCK) - ((EQUILIBRIUM_BLOCK - 1) * DECAY)) / 2 

Help me out with this DEMURRAGE_CHARGED_UNTIL_EQUILIBRIUM, please.

[jtimon]

Maybe we should wait for an alternative full bitcoin client to modify it instead of the current code, or we could wait for the lib to be developed.
https://gitorious.org/libbitcoin

If we chose to fork bitcoin directly, for the demurrage, we should do the following:

1) Encapsulate CTxOut properly, making nValue private and creating get/set methods
This change will make errors appear in every place where we need to change the code.

2) CTxOut should have a block_number field or a way to access it.

3) We change int64 CTxOut::getValue() for
int64 CTxOut::getValue(int nHeight) {
   return this.nValue - (this.nValue * DEMURRAGE_RATE * (nHeight - this.blockNumber));
}

I think that (and changing GetBlockValue) should be enough.
No one willing to take the bounty ?

[maaku]

I'm finally out of newbie status and able to post. Here's the discussion that's been going on over on the freicoin forums (I've just copied over my posts, I hope it's still readable):


Well, I believe this is the opportune time for me to announce that my startup is working on an alternative full* bitcoin client. We will support a block chain with demurrage from day one, and we would like very much to work with you to get your support in making this the “official” freicoin block chain on freicoin.org.

(*To clarify, it's a implementation of the bitcoin protocol, as defined in the original bitcoin whitepaper, on top of a different peer-to-peer overlay network. It is intended for new alternative block chains, and it's not bit-compatible with the mainline bitcoin block chain or network protocol.)

We will be implementing our own general currency for exchange, and we expect a general currency should incentivize spending, discourage hoarding, and maintain stable, fixed prices. Naturally your freicoin proposal fits the bill, and to my eyes at least it does so better than anything else (and in the past few weeks I think I've read every other alternative block chain proposal out there).

It will *not* be merge-mining capable, however. Merge mining requires inter-dependence between the associated block chains, which is simply unacceptable from a technical perspective and with regards to the long-term security of the network.

As a working schedule--keeping in mind that this *will* change--we'll probably have a version for internal testing by the end of September/early October, and a public beta in the November/December timeframe. If everything goes well, the beta will be become the freicoin testnet, and a new freicoin block chain generated for the official release in early 2012.

Here's the breakdown of how our demurrage block chain will differ from bitcoin:

1. 10 second blocks (EDIT: we've changed back to 10-minute blocks!)
2. 10bn freicoins (1e18 monetary units) total circulation
3. 2 hour difficulty retarget (every 720 blocks)
- Up to +10% adjustment up (EDIT: this is back to the standard 4x.. I shouldn't have lendt any credence to solidcoin)
- Up to -400% adjustment down
4. 1% demurrage per annum (but calculated per-block) (EDIT: this has been adjusted to 4%)
5. 32 freicoins issued per block

Some notes on why these numbers are chosen:

1) This may seem out of left field, but we also have to consider building a protocol that will survive humanities expansion into space, where the speed of light becomes a limiting concern. Round-trip to the moon is just under 3 seconds. Round-trip time to L4/L5 is on the order of about 17 minutes, and RTT to the orbit of Mars, Mars' moons, and NEOs is similar, albeit fluctuating. Anything further out would of course take longer. Current bitcoin network performance shows that round times on the order of a second could work. Choosing 10 seconds per block allows for a crypto-currency that comfortably includes all of cislunar space, provides a 60x improvement in verification time over bitcoin, and is within an order of magnitude of the best the current bitcoin network can do.

2) Comparisons were made with the per-capita size of the USD monetary pool, then extrapolated to an estimated 20bn residents of cislunar space in the mid 22nd century.

3) I'll simply point to solidcoin for this. I'd be curious to know if anyone has done some research on what the optimal numbers for this should be.

4) Roberto M. Billi & George A. Kahn, 2008. "What is the optimal inflation rate?," Economic Review, Federal Reserve Bank of Kansas City, issue Q II, pages 5-28.

The authors estimate that between 0.7% and 1.4% is ideal. 1% is comfortably in the middle and easy to work with. The demurrage will be paid as mandatory transaction fees (transactions will not be accepted unless the transaction fee meets or exceeds the required demurrage).

5) That this coincides with solidcoin's choice is pure coincidence. With 1% demurrage per annum, one can expect roughly 32 freicoins of demurrage per block in the steady-state. While freicoins are still being mined, the yield (new coins + demurrage + tx fees) will be between 32 and 64 freicoins, on average.

[maaku]

On 10 second rounds:

In the past two months there have been 15 reorgs of the blockexplorer.com data-collection node. Assuming that a fork of the block chain resulted in only two branches, and that blockexplorer.com had just a 50% chance of selecting the “correct” branch, that means there has been 30 forks of the block chain in the last two months. That's 30 out of 8928 blocks for July and August, or about 0.336% chance for a given block. Now assuming that the network was not subject to malicious action during this time*, that means that in those 30 instances two blocks were generated close enough in time to be within the network latency. Or put differently, we can calculate the network latency of the current, existing bitcoin network to be: 10min/0.336% = 2.02 seconds.

*If it was, that would only lower the resulting latency.

Extrapolating into the future, we can expect this number to go down, not up. That may be somewhat counter-intuitive, but what we are seeing now is the worst-case possibility. The bitcoin peer-to-peer overlay is not optimized, at all. It is also conceivable that when a crypto-currency goes mainstream, we may see the emergence of fiber-optically connected payment processing nodes that can relay blocks and transactions to disparate parts of the network very quickly.

Further, it's not very clear that an increase in the number of forks would even been an issue. Bitcoin has defenses built into the protocol for resolving such conflicts. It is only when the probability of a split exceeds 50% that the block chain becomes divergent. On the current bitcoin network, that means round times must be no shorter than 4 seconds.

10 seconds is more than twice that lower limit, and as I said that limit will only get *smaller* as the network gets smarter.
On demurrage rates:

Ultimately inflation vs. deflation will probably depend more on supply and demand on the exchanges. But short of falling back to a fiat currency, I don't know how that can be credibly regulated.

However there has been considerable research into the effects of inflation on the economy, and what an “ideal” inflation rate would be. The paper I linked to is from the Federal Reserve Bank of Kansas City, and is the best and most recent report on an ideal interest rate. It is the source of the 1% number.

Demurrage doesn't need to fully compensate against other market effects to discourage hoarding, it simply needs to be enough to make other forms of wealth building (investment, loans, etc.) more desirable. This is the exact analogue to inflation in fiat currencies, and the Fed says 1% has been good enough for them.


On tx fee vs automatic withdraws:

I'm not sure I understand you; withdraws have to be made somehow. Are you suggesting that every block assay demurrage fees for every account? That would unnecessarily grow the block chain but a ridiculous amount. Or maybe it's just done on specific intervals, every X number of blocks? That would lead to other problems as people attempt to unload their coins before a drop, then buy back in afterwards.

Or maybe it's hardcoded into the client and not explicit in the block chain, that usable account balances decrease by a small amount every time a new block is generated? I'll argue that is both more complicated to implement, and less desirable.

If, on the other hand, your point is that the user should see a number that reflects their spendable balance, then I agree. But that is a UI issue divorced from the technical implementation.

If demurrage is assessed as mandatory transaction fees, then the user still retains some benefit: transactions from their accounts are seen as more valuable, and will be processed quickly. It is also technically very simple to implement, and if the context demands it can be hidden from the user by the UI.

[maaku]

Made a thread about this on bitcointalk to make the discussion available to more people, so drop by if you'd like.

There are some points there I would like to address, but I'm still waiting for my newbie status to be lifted

Actually disregard what I said above because I just converted to your method. Totally slipped my mind that tx fees give higher priority.

We're on the same page then. But for completeness sake, there are two trade-offs that I glossed over:

First, having automatic withdraws is more convenient for miners as it results in consistent and predictable yields. Using transaction fees as the method makes mining a bit like playing the lottery--some miners will be fortunate enough to generate blocks containing transactions with large fees, others will not. However pooled mining will greatly alleviate this, and the total/average yield will be approximately the same as in the automatic withdraw case. IMHO this makes it a non-issue in practice.

Second, automatic withdraws correctly handle lost coins in a way that transaction fees do not. In the automatic withdraw case, lost wallets continue to depreciate in value with the proceeds slowly returning to the economy over time. However with transaction fees, if a wallet is lost those coins will never be used in a transaction and so the demurrage fees will never be assessed. A reasonable compromise that I am considering is creating a special transaction type that allows miners to proactively claim fees from inactive accounts at certain thresholds (for example, each time the account has halved in value). In that way, we get the best of both solutions.

Yeah, the Fed advocates a target 1% price inflation, but a 1% demurrage is the homologue of a 1% increase of the money supply, not a 1% price inflation. You have to take GDP growth into consideration. The real homologue of a 1% price inflation would be 1% demurrage over the GDP growth rate, so if GDP growth is 3% then demurrage would have to be 4%.

It occurs to me that we would also have to take into consideration population growth in the steady-state (or growth of the network in initial stages) as well as productivity growth of the overall economy...

(At this point I must say that I am a programmer by training and profession, though I read the Economist on weekends. I just spent a half hour trying to analyze all the contributing factors to price inflation, at which point the complexity of it caused me to believe that this might not be the right path. So please bear with me as I attempt to reason this out, and tell me if I'm getting any part of it wrong:)

What my company and I are seeking with a demurrage currency is all the economic benefits of low, positive inflation currency, with the added benefit of long-term price stability. So I'm trying to design a system in which price inflation is stable at zero, but with a demurrage rate set so as to have the same positive effects as the Fed's 1% price inflation target.

However in designing this system I have fallen victim to the incorrect thinking that demurrage is equivalent to a corresponding price inflation. It may look that way from the consumer's perspective, but I have run some numbers to verify what you said, and now I see that macro-economically it is exactly analogous to increasing the monetary supply (which all things being equal will cause inflation, but there are other factors at work as well).

Taking this as a chance to think about what it is that we (my company) are trying to accomplish, I realize now that what we want to achieve at the most basic level is an increase in the velocity of crypto-token money, by incentivising spending and discouraging hoarding. Worrying about price inflation/deflation was attacking a correlated symptom rather than the root cause.

That simplifies things considerably because demurrage of any non-zero amount will naturally increase the velocity of money. So the only questions then are: by how much, and with what consequences?

Which puts me back at square one, and I need to think about it some more. Is this something anyone here has looked into?

[maaku]

So any ETA on your fork maaku?

Hi, I was at a conference all week. I got plenty of code written, but didn't have time to check the forum It's coming along, although I will refrain from making any further public announcements regarding schedule until we are close to a public beta.

I've finalized our block header and transaction formats. It *will* be merge-mine capable, but only with future currencies based on our crypto-token system. It will *not* be merge-mine compatible with bitcoin, namecoin, or any of its derivatives. I'm sorry, but the system we've come up with is simply too clean, elegant, and future-proof to give up.

We've substituted s-expressions (Lisp) for bitcoin's Forth-like scripting language. This is in part for simplicity of implementation and testing, but also because we expanded the use of the scripting language to definition of how the currency works. In effect, the behavior of the crypto-token system is governed by programmable and pluggable hooks written in the scripting language.

That's perhaps delving too deep into implementation than is necessary. Here's some updates to the user-level features of the currency:

1. Back to 10 minutes blocks
2. 1 week difficulty retargets (+/- 4x up/down)
3. 4% demurrage per annum
4. Coin generation rate... TBD

On my contentious 10-sec blocks:

I maintain that it would work, and in fact would provide more security (because the work of the network is manifested more regularly, there is a compounding effect wherein the number of confirmations matters--so 60 confirmations at 10s intervals *is* more secure than one confirmation at 10min intervals). However my project manager made me realize that the benefits are marginal, there is associated risk, some downsides (larger block-chains), and it doesn't gain us anything that we couldn't get through other means. So we're back to a conservative 10-minute round.

Difficulty retargets:

I maintain that bitcoin's two weeks is simply too long--especially if there is a drop in hashrate like we saw with namecoin. For the security of the network, it would be best if difficulty retargets occurred more quickly than a distributed, uncoordinated mining network could respond. I felt 2 hours was the right compromise in this regard--if miners collectively but individually decided to pull out, it might take a full day (given differences in timezones and reaction time). That would be enough time for one or two retargets, so hopefully the utility of the network would not be compromised.

Unfortunately, one also needs to account for statistical variance. Bitcoin is effectively using an inherently random Poisson process (the proof of work) as a clock. Only if the sample size is large enough can this be a reliable timekeeping measure. If the target interval is 10 minutes, 2 hours would be only 12 samples, which is definitely too small. 2 weeks is 2016 samples, which is certainly very conservative. 1 week would be 1008 samples, which is probably enough. 1 day would be better IMHO, but at 144 samples I need to do some math/run some simulations to see if that would still work.

The demurrage rate:

I assume there are some simplifying assumptions in the equation that you gave me, as it doesn't match the first derivative of the equation on Wikipedia. But assuming that's correct, I would target 1% price inflation for the reasons given before, and 3% GDP growth, which is also a number the Fed has consistently targeted. By your form of the exchange equation that would mean a 4% increase in the monetary supply/4% demurrage.

On coin generation:

The previous rate would have been comparable, albeit in addition to the 4% target. However it would have taken over a century to generate all the coinage! Actually, there's nothing inherently wrong with that, but it is different from bitcoin. And it indirectly raises the issue of reward for early adopters.

EVERY alt-chain so far, except namecoin, has proven to be a scammy get-rich-quick scheme. Right or wrong, the community will perceive freicoin as more of the same unless steps are taken to eliminate or compensate for unfair distribution to early adopters.

This I don't have a solution for yet, but I'm open to suggestions and interested the opinion of others here.

[jtimon]

Or maybe it's hardcoded into the client and not explicit in the block chain, that usable account balances decrease by a small amount every time a new block is generated? I'll argue that is both more complicated to implement, and less desirable.

I think this is the simplest way to implement it. Why is it less desirable?

If we chose to fork bitcoin directly, for the demurrage, we should do the following:

1) Encapsulate CTxOut properly, making nValue private and creating get/set methods
This change will make compile errors appear in every place where we need to change the code.

2) CTxOut should have a block_number field or a way to access it.

3) We change int64 CTxOut::getValue() for
int64 CTxOut::getValue(int nHeight) {
   return this.nValue - (this.nValue * DEMURRAGE_RATE * (nHeight - this.blockNumber));
}

I think that (and changing GetBlockValue) should be enough.

Having it demurrage charged explicitly in the block chain only leads to complications.
For example, How do you warranty that the total demurrage charged with each block is equal to the reward?

[maaku]

Or maybe it's hardcoded into the client and not explicit in the block chain, that usable account balances decrease by a small amount every time a new block is generated? I'll argue that is both more complicated to implement, and less desirable.

I think this is the simplest way to implement it. Why is it less desirable?

...

Having it demurrage charged explicitly in the block chain only leads to complications.
For example, How do you warranty that the total demurrage charged with each block is equal to the reward?

It amounts to the same thing--in either case the client would have to add a little extra transaction fee on top of the demurrage--if the transaction doesn't make it into the next block, some of that fee will convert into demurrage. If time goes by and that transaction still isn't confirmed, eventually the fee will run out and the transaction will be marked as invalid (not enough demurrage).

So far, that's the same for either my or your implementation. Where we differ is what we do with that demurrage fee. I say give it to the miners along with the transaction fee. You say destroy those coins, and give the miners a fixed amount per block which amortizes lost coins over time. My solution has the benefit of faster processing for the user (as the demurrage fees are treated as transaction fees), whereas your solution results in more consistent block rewards for miners. In the end, that is the only difference between my suggested approach and yours.

[jtimon]

It amounts to the same thing--in either case the client would have to add a little extra transaction fee on top of the demurrage--if the transaction doesn't make it into the next block, some of that fee will convert into demurrage. If time goes by and that transaction still isn't confirmed, eventually the fee will run out and the transaction will be marked as invalid (not enough demurrage).

Actually I had another idea: https://bitcointalk.org/index.php?topic=36190.msg453112#msg453112
This way you could specify the exact fee to the miner.

So far, that's the same for either my or your implementation. Where we differ is what we do with that demurrage fee. I say give it to the miners along with the transaction fee. You say destroy those coins, and give the miners a fixed amount per block which amortizes lost coins over time. My solution has the benefit of faster processing for the user (as the demurrage fees are treated as transaction fees), whereas your solution results in more consistent block rewards for miners. In the end, that is the only difference between my suggested approach and yours.

I don't understand why your solution results in faster processing for the user. My CTxOut::getValue(int nHeight) method seems very fast to me.
You need to make a very similar method for calculating the fee. Actually users still need my method to check their current balance (or the balance of any given address). You cannot explicitly represent the real balances in the block chain because they change with each new block.

I'm curious about your project. Is it also written in C++ ? Is it very different from bitcoin or is just a cleaner and more readable implementation?

[maaku]

I don't understand why your solution results in faster processing for the user. My CTxOut::getValue(int nHeight) method seems very fast to me.

I didn't mean computationally faster. If demurrage fees are counted as transaction fees, the transaction is more likely to be accepted for the next block, and therefore the transaction will be confirmed more quickly, on average.

I'm curious about your project. Is it also written in C++ ? Is it very different from bitcoin or is just a cleaner and more readable implementation?

The core functionality is in Python, with block-chain specific hooks written in a Python-interpreted Lisp variant. The peer-to-peer overlay network is in C++. We follow the original bitcoin whitepaper rather strictly, but it is not compatible with the bitcoin wire protocol. The block and transaction formats are modified quite heavily, the scripting language is new, and the peer-to-peer overlay network and message protocol is entirely different from bitcoin.

EDIT: And I would like to think that it is cleaner and more readable, but I suppose that is in the eye of the beholder

[jtimon]

I don't understand why your solution results in faster processing for the user. My CTxOut::getValue(int nHeight) method seems very fast to me.

I didn't mean computationally faster. If demurrage fees are counted as transaction fees, the transaction is more likely to be accepted for the next block, and therefore the transaction will be confirmed more quickly, on average.

Yes, transactions from "old accounts" will be processed faster even with no transaction fees. But I don't see how that's desirable.
With my proposal, the user will add more funds than needed to the transaction to pay the demurrage charged from the creation of the transaction to its inclusion in the chain. With the change if this extra coins he can do:

1) Keep it to himself
2) Give it to the miner
3) Give it to the recipient
4) A combination of the three

He can also specify a transaction fee to the miner. My proposal (apart from maintaining demurrage revenues for miners constant), gives more freedom to the users to decide what is better for them.

[Cosbycoin]

I don't understand why your solution results in faster processing for the user. My CTxOut::getValue(int nHeight) method seems very fast to me.

I didn't mean computationally faster. If demurrage fees are counted as transaction fees, the transaction is more likely to be accepted for the next block, and therefore the transaction will be confirmed more quickly, on average.

Yes, transactions from "old accounts" will be processed faster even with no transaction fees. But I don't see how that's desirable.
With my proposal, the user will add more funds than needed to the transaction to pay the demurrage charged from the creation of the transaction to its inclusion in the chain. With the change if this extra coins he can do:

1) Keep it to himself
2) Give it to the miner
3) Give it to the recipient
4) A combination of the three

He can also specify a transaction fee to the miner. My proposal (apart from maintaining demurrage revenues for miners constant), gives more freedom to the users to decide what is better for them.

I have recently seen this thread as well as the freicoin page and ripple page.

I understand that planning is a must but when will implementation and testing begin?

You can only discuss something so much before it becomes a circled discussion.

[jtimon]

I have recently seen this thread as well as the freicoin page and ripple page.

I understand that planning is a must but when will implementation and testing begin?

You can only discuss something so much before it becomes a circled discussion.

Well it seems that maaku is already implementing it. I'm trying to change some of their design decisions.
I would prefer to directly fork bitcoin to take advantage of its code updates when it's possible. I won't code anything until I finish my college final project, until the algorithm learns how to play Reversi/Otello on its own (neural networks + genetic algorithms + GPGPU).

But even if I could, I think some issues have to be addressed first. For example, the formula for the coins to generate. Since the freicoin community is still tiny, I'm not really in a hurry, but if someone wants to take the bounty, the sooner we have the code to test it the better. I also wanted to see merged mining in production before launching freicoin, but now it seems that maybe that won't happen soon (because of ArtForz/btcExpress attack).

About Ripple, I don't know if Ryan is currently improving ripplepay or already implementing distributed ripple. I think he's improving ripplepay while editing the protocol draft. I would want to have more general conditions (an scripting language like in bitcoin) instead of only registries. But since most people don't like the registries idea, Ryan has taken it out of the base protocol.
I've also proposed to fellow traveler a way to implement ripple inside OT, but I'm still waiting an answer about its feasibility.

I really want to have the code for both freicoin and distributed ripple right now, but I still think there's some design issues to be solved.

[mokahless]

So is Freicoin dead now?