Is mandatory transaction inclusion possible?

[phillipsjk]

I am considering starting an alternate block-chain that would be complementary to bitcoin (or possibly overtake it according to some economists Read: high, stable inflation).

However I had an idea that may kill the currency if poorly implemented, regardless of the actual merits of the core concept.

I want to make the inclusion of all transactions (meeting certain criteria) mandatory. Transaction fees would be fixed at 0.1%, so fees are not used to prioritzie transactions. Instead, transactions are prioritized by size. Miners would advertise a minimum Input/Output value(s) for transactions they process. Miners would be required to include all valid transactions they see meeting their advertised criteria.

The difficulty I see is that it would be difficult or impossible to prove a specific miner "ought to have known" about a valid transaction in a distributed way. One easy test is how old the orphan transaction is. For a well-connected miner, they "ought to know" about transactions at least two blocks old. However, if poorly connected miners face having their blocks invalidated by the network, that may provide an incentive for well-connected miners to keep transactions to themselves. On the other hand, that strategy may back-fire because the network, not knowing about this non-broadcasted transaction, may accept the block missing the transaction anyway. Edit: network splits would cause forking too.

I also see a potential loop-hole. Miners may advertize one value, but in practice, pose as another miner when publishing blocks. I don't think miners would have an incentive to do this in practice: miners will see bandwidth usage proportional to the minimum values they advertise. Similarly, the bandwidth usage of the final block should be proportional to transactions "seen". With fixed transactions fees, there is no incentive to drop transactions (that fit in the block).
 
Because the actual idea behind my (yet to be) proposed alternate block-chain is not my own, I need to read more about it before giving further details. I am also not sure when/if I will find time for coding. I still have not done much work for that Open Hardware FPGA board I was interested in

[DeathAndTaxes]

Fixed percentile fees are also impossible (at least in Bitcoin and any derivative).

Requiring tx to be included would ultimately lead to entities gaming it to disadvantage other miners.  Given mining is a zero sum game the less efficient your make your competitors the more profitable you are for the same amount of raw hashing power.

Imagine a large pool X.  When they detect a new block they spam the network with "old" (based on timestamp) tx which make the new block invalid.  Their attempted blocks already have the "old" (but not broadcasted) tx so their blocks are never non-compliant.

Depening on the number of connections they have and propogation delays they may successfully orphan a small but significant portion of blocks.  The pool (or consortium of pools) could even be more evil by having "secret" tx which are only shared to other pools who pay an "information services fee".  Pools who refuse will be missing a require component of valid blocks and thus being oprhaned.  A pool collecting fees on other pool's miners.

[phillipsjk]

The proposal will use floating point to store value (makes sense in context), so percentile fees are no problem.

Transactions don't have timestamps, blocks do. In my proposal, if a miner "saw" a transaction two blocks ago, it assumes all other well-connected miners have also seen it. This may lead to disagreement if some miners think a transaction was 2 blocks old, while others think it is only 1 block old. If all transactions are included anyway, it should not be a problem.

The difficulty of course, is what will happen if/when those edge cases come up.

Edit: for technical reasons related to the GMWG proposal (linked below), and my transaction resolution filtering not-yet-proposal: transactions do need block-based time stamps. The miners will not trust such time-stamps for "ought to have known" purposes.

[DeathAndTaxes]

Floating point doesn't matter and I question the logic of using floating point due to the variety of rounding errors that introduces.  Still  % fees are not possible on a Bitcoin derived system.

Bitcoin has no concept of the value of the "spend" just the total input and total output.

So 0.1% fee.  Paying merchant 1 BTC.  1000 BTC input.  
1 BTC -> merchant, 999 BTC -> change  
0.1% * 1000 = 1 BTC fee?  
1BTC fee on 1 BTC "spend"?

Transactions don't have timestamps, blocks do. In my proposal, if a miner "saw" a transaction two blocks ago, it assumes all other well-connected miners have also seen it. This may lead to disagreement if some miners think a transaction was 2 blocks old, while others think it is only 1 block old. If all transactions are included anyway, it should not be a problem. The difficulty of course, is what will happen if/when those edge cases come up.

Its no a question of IF.  You have given a direct financial incentive to ensure those edge cases come up.  The system will be gamed.  Large pools (or consortion of pools) can keep hidden tx and use them to invalidate blocks of miners who aren't part of the cartel (or unwilling to pay fees to gain knowledge of the hidden txs).  It doesn't matter what a miner thinks is valid if 51% of the hashing power disagrees.

You are creating a system where the profitability of large pools is enhanced by witholding information from other miners which makes the system less secure.  Y

[Etlase2]

The proposal will use floating point to store value (makes sense in context), so percentile fees are no problem.

To achieve percentile fees, you need to use a balance sheet or account ledger or whatever you want to call it. This can be done in a bitcoin-derived protocol. It will just require a bit more than changing a value here and there.

I described in light detail most of what you are looking to achieve in this thread: https://bitcointalk.org/index.php?topic=64637.0

Instead of requiring txes to be included, block selection is done based on blocks that have the most weight, and weight would come from a mechanic similar to bitcoin days destroyed.

I would suggest, however, instead of trying to reinvent the wheel to start contributing to the Encoin project. This: https://bitcointalk.org/index.php?topic=76750.0 is the latest thread to help flesh out some details as MoneyIsDebt has agreed to help program this project.

[FreeMoney]

The proposal will use floating point to store value (makes sense in context), so percentile fees are no problem.

To achieve percentile fees, you need to use a balance sheet or account ledger or whatever you want to call it. This can be done in a bitcoin-derived protocol. It will just require a bit more than changing a value here and there.

I described in light detail most of what you are looking to achieve in this thread: https://bitcointalk.org/index.php?topic=64637.0

Instead of requiring txes to be included, block selection is done based on blocks that have the most weight, and weight would come from a mechanic similar to bitcoin days destroyed.

I would suggest, however, instead of trying to reinvent the wheel to start contributing to the Encoin project. This: https://bitcointalk.org/index.php?topic=76750.0 is the latest thread to help flesh out some details as MoneyIsDebt has agreed to help program this project.

You have one address containing 10 coins. you send 4 coins. What is the fee? Instead you send 6 coins. What is the fee?

[Etlase2]

there is no need for a change transaction when using a balance sheet. coin "mixing" is also significantly easier, so if for some reason you feel your anonymity has been compromised, you can always do that.

[phillipsjk]

Floating point doesn't matter and I question the logic of using floating point due to the variety of rounding errors that introduces.  Still  % fees are not possible on a Bitcoin derived system.

Bitcoin has no concept of the value of the "spend" just the total input and total output.

So 0.1% fee.  Paying merchant 1 BTC.  1000 BTC input. 
1 BTC -> merchant, 999 BTC -> change 
0.1% * 1000 = 1 BTC fee? 
1BTC fee on 1 BTC "spend"?

Your analysis is correct. I did not consider "change transactions", thank-you for the clarification. I initially thought (as Etlase2 apparently does) that change to the originating address can be exempt. However, this is not possible for two reasons:

• Some transaction have multiple inputs. I suppose it can be assumed all inputs are in the same "wallet" (due to proof of ownership).
• More importantly, with mandatory transactions, the transaction fees are an important anti-spam measure. If intra-wallet transactions were "free", somebody could use them to inject arbitrary data into the block-chain.

I have determined that transaction fees on change are probably not a problem for the alternate block-chain I am considering. I have also realized that transaction fees and explicit rounding errors are integral to the yet-to-be-proposed block-chain. I will have to go over the logic carefully, possibly with Satoshi paper-style diagrams. The real sticking point is that hosts with different block-chain resolutions may disagree what balance an address has. The protocol has to be designed such that hosts using the same resolution always agree.

Its no a question of IF.  You have given a direct financial incentive to ensure those edge cases come up.  The system will be gamed.  Large pools (or consortion of pools) can keep hidden tx and use them to invalidate blocks of miners who aren't part of the cartel (or unwilling to pay fees to gain knowledge of the hidden txs).  It doesn't matter what a miner thinks is valid if 51% of the hashing power disagrees.

You seem to be saying my proposal is vulnerable to a 51% attack. I will try to figure out what happens in the event of a net-split. The case were one half has at least 51% is actually more complicated

Because this discussion probably can't proceed without context:
I mis-read this MintChip Challenge Idea submission as sarcastically suggesting that digital (meaning in my mind having discrete values, like the penny) currency can be used to suppress more "analog" currencies: such as the given example of the Green Money Working Group.

After skimming that page, I decided that even though I did not like the idea, it can probably be implemented in a Bitcoin-style block chain. The high inflation (not sure if that is the correct term (devaluation?)) solves the hording problem that many (trolls?) complain about. It also solves the "early adopter" problem as well.

On the assumption that the "RkWhs as a monetary unit of value" was an analog unit, I started working though the implication of using floating point values as an approximation. I realized that I can solve the bandwidth and block-chain pruning problem at the same time: by having miners declare how much resolution they will process. Ironically, the small (P2P pool) miners on home Internet connections would only be able to process large transactions. Conversely, only large miners in well connected data-centers would be able to process small transactions. As a result, the larger transactions actually get more hashing power. Because both types of transaction share the same difficulty, the large transactions simply get processed faster on average. Note: I have not been careful to distinguish between large values and large bandwidth. By "large", I mean value.

If the money stored in the network is forgotten because it is not "large enough", that is rounding error. For the specific GMWG proposal, that should not be too much of a concern since the "money" devalues so rapidly. However, before posting a detailed "Green Money" alternate block-chain proposal, I want to make sure I properly understand the concept, so as not to mis-represent it.

Intuitively, I would say nobody would be interested in rapidly devaluing money. But what if those economists are correct that "bad money displaces good money"? If that is true, people may prefer to use the "green money" (over Bitcoin) as an intermediate currency. It would also provide a leverage-free hedge if you see a Bitcoin bubble forming (ie: the devaluing currency may out-perform Bitcoin in the shot-term).

[Etlase2]

Your analysis is correct. I did not consider "change transactions", thank-you for the clarification. I initially thought (as Etlase2 apparently does) that change to the originating address can be exempt. However, this is not possible for two reasons:

*le sigh*

[MoneyIsDebt]

Intuitively, I would say nobody would be interested in rapidly devaluing money.

Isn't there a problem in that your proposed currency will start with zero value, and rapidly devalue from there?

[phillipsjk]

Intuitively, I would say nobody would be interested in rapidly devaluing money.

Isn't there a problem in that your proposed currency will start with zero value, and rapidly devalue from there?

No, the value can never drop below zero. Just like bitcoin, the value will "float". Initially, a pizza may be worth something like 230 Giga Green money credits. If it becomes the default currency for credit default swaps, pizza may be only worth 6.7 micro Green money credits.

Devaluation means that by the end of the year, your 230 Giga Green money credits may be worth only 50 Kilo Green credits or so.

Etlase2: I am not doing a transaction ledger. My proposal is going to be complicated enough as it is.
Need sleep. Isn't the block-chain a transaction ledger?

[Etlase2]

Yes, the block chain is a transaction ledger. That's why you need an account ledger. It would actually be pretty simple to implement in a bitcoin-derivative, and it obviates the need for merkle trees and pruning and all the bloat. And you could safely delete an entire chunk of the block chain after it is buried deep enough.

You add a big, secure hash of a balance of all accounts to each block. Transactions do not need to reference inputs, only {amount, from, to, signature}. Things are slightly more complicated if you wish to continue to use RIPEMD160 on the ECDSA public keys, but not much at all. When adding a transaction to a block, a miner references the account ledger that they keep locally (and update via the tx log in each block, and ensure their hash agrees with the balance hash) and puts the tx in the block if the account has enough available. Txes simply add and subtract from balances. No change required, insanely less data used per transaction, a lot less data needed for the block chain, etc.

Now I don't know what you are trying to accomplish with this proposal, but I spent a lot of time addressing issues like deflation, early adopter problem, transaction acceptance problem, scalability problem, waste of electricity, and combined all this into the proposal for encoin. I don't particularly see the value of a currency where 230G credits becomes worth 50k credits in a year. If you like the idea of money having a price to store (like GMWG), this is called demurrage and freicoin is working on implementing this. But, encoin promotes a system similar to what demurrage tries to achieve by "threatening" hoarders with new coin creation when the value of coins exceed their cost to produce. And this is without charging a fee for holding on to money, which is I think a significant hindrance to adoption by the general public.

Perhaps your proposal is the next big thing. But you've got your work cut out for you, especially when you talk about using floating points in the block chain.

[MoneyIsDebt]

No, the value can never drop below zero. Just like bitcoin, the value will "float". Initially, a pizza may be worth something like 230 Giga Green money credits.

My point was not that it drops below zero. It's that initially it's worth zero.
Why would you assume you can buy a pizza for it in the first place? If you simply create a currency backed by nothing it will initially buy you nothing.
My question was then whether you see a problem in that it starts with no value, and a tendency to devalue (or stay at zero) built in.

[phillipsjk]

My question was then whether you see a problem in that it starts with no value, and a tendency to devalue (or stay at zero) built in.

When I read the GMWG proposal I didn't like it. However I found it interesting enough thatI think it may deserve its own block-chain, just to see what would happen. I don't see starting at zero value as a problem. The Pizza example was a direct reference to 10,000 BTC Pizzas. I don't expect people to hold a devaluing currency for long. As I mentioned, that may encourage a more stable economy. Or it may fail catastrophically. I don't know. The person(s) proposing GMWG probably don't know much about Bitcoin. Their proposal comes from an economic viewpoint.

I am also not sure floating point is the best way to implement it, but as I have said, it has some interesting properties. With demurrage, you can "forget" balances too small for people to care about (as measured by the minimum transaction input/output value in my yet-to-be proposal).

Thank-you Etlase2 for the pointers. I don't follow the alternate block-chains much. I am most interested in "namecoin", but have not had time to do anything with that either.