This is all hypothetical, the sort of thing that might be on the hard-fork wish list:


There may be other valid alt-chain uses however (such as colored coins).

Clearly we must be talking about different arithmetic types. I'm talking about arbitrary-precision rational arithmetic of the type provided by mpq_t in the GNU multi-precision library, for which "2/1" + "2/1" = "2/1" * "2/1" = "4/1" (exact rationals with no concept of uncertainty).

It's already needed in Freicoin due to the presence of demurrage--decayed inputs may have sub-satoshi amounts which accumulate and need to be tracked to enable claiming the accumulated satoshis. Take a transaction which has two separate 3-satoshi inputs that have decayed to each be 2.6 satoshis in value and has a 5-satoshi output. A mp-aware implementation would correctly validate the transaction and pass on the remaining 0.2 satoshi to the miner as a fee.

Software implementation is advisable because many details of hardware floating point is implementation-dependent, which will inevitably lead to distinguishing implementations based on what transactions they validate and which they do not (due to differences in rounding, usable precision, bugs, etc.) and hard-forks. If you're doing software math anyway, you might as well do exact arithmetic since it's actually less complicated and efficient libraries exist.

That, and I've already done all the hard work for you in Freicoin (which handles amounts internally as mpq values with infinite precision instead of int64).

BID is trivially simple. It's basically a sign bit, a binary integer exponent, and a binary integer mantissa (value). Serialization is as simple as a few shifts and bitwise operations.

Yes, but without being partisan BID is the only format that really makes sense for this application. DPD is added complexity but allows easy conversion to BCD in hardware, for hardware accelerated decimal arithmetic. But being a financial application all internal arithmetic would have to be exact, arbitrary-precision rational rather than truncated floating point anyway, so the decimal64 format would only be used for serialization, making the hardware efficiency gains (and associated complexity) rather pointless.

Well there are other uses - colored coins, for example. A single satoshi could represent an entire asset type, for example, if sub-satoshi amounts were representable. It's not a very strong need though.

Actually the fact that all bitcoins fit within 2**53 is quite a happy accident. It means that integer-satoshi amounts can be represented exactly by the IEEE decimal64 type, which provides one route towards practically infinite divisibility by using exact arbitrary-precision rational arithmetic and decimal64 for serialization.

Freicoin already implements arbitrary-precision internal arithmetic, and decimal64 support could be added by a new transaction serialization version. As others have mentioned though, there's not really a need until sub-satoshi amounts have any real-world value.

He doesn't know what he's talking about. The algorithms we know for reversing ECDSA are not polynomial time. Unless he knows something about computational theory that the rest of the world does not, there is no reason to believe that it is even possible for there to exist a polynomial time solution. And with the exponential time solutions which are currently the best we know about, you could literally turn the entire observable universe into a 100% efficient computer and run it until the heat death of the universe, and you you're not likely to find a solution. Moore's law does not apply here.

I'm not sure about the specific application you propose (I'm too hopped up on cold medicine to wrap my head around it tonight).


This is exactly what Open-Transactions does, I believe.

When it's said that the issuer must be trusted, we're talking economically not cryptographically. In Open-Transactions, nobody--not the server operator, not the issuer, not anybody but you--may change account balances or token ownership. That's a cryptographic guarantee. However since the issuer is allowed to generate at will and without cost as many new tokens as they want, for existing tokens to have any value you have to trust that the issuer will live up to their contractual promises (backing, redemption, etc.). But that's a separate issue from existing account balances/token ownership which is protected from tampering.

You can already do that. In Open-Transactions, issuers and the server are distinct entities.

He asked because the U.S. certainly does place requirements (on banks) for its citizens getting foreign accounts. Mostly it involves getting copies of copious identity documentation and reporting end-of-year summaries to the IRS (U.S.'s tax collection agency). Are you in compliance with these laws specific to U.S. citizens?

This could be mostly eliminated by refactoring how serialization occurs in transaction validation (serialize directly to sighash format without intermediary copying). It's something I'd been planning to add, but haven't gotten around to yet

P2Pool is incredibly easy to fork for an altchain.

SgtSpike has a long-time presence here, 5452 posts to his name, and a reputation that is probably worth more than 5 btc. You do not.


If only I worked at Google search, I could look for 5-letter random sequences searched in the last few days. Easier if I knew your IP

That is correct.

For any two chains with unequal difficulty, it's possible that the proof-of-work meets the difficulty requirement for neither chain, the chain with lower difficulty, or both simultaneously.

This is because proof of work is transitive, as essentially you're checking if the number represented by hash(block-header) is less than the target number represented by the current difficulty/nBits, and “less-than” comparison of integers is transitive. If hash(block) <= bitcoin-target, and bitcoin-target <= namecoin-target, then it MUST also be true that: hash(block) <= namecoin-target and therefore it meets both chain's requirements. Make sense?

Blockchain pruning is what reduces storage requirements. The UTxO meta-chain proposal merely makes it easier for a fully validating but pruned client to get up to speed without downloading the entire block chain, and without having to trust any specific peer. Rather the hypothetical client places its trust in hashpower securing the meta-chain, which presumably they're doing anyway if they're using bitcoin at all.

(The UTxO proposal also greatly improves the security model of light nodes, but that's a separate issue from your question.)

I don't know what the best place is to get up to speed with blockchain pruning, but “ultraprune” is the name of the recently-merged fork that does all the prep work for pruning. Search on that keyword and you should find stuff.

Bitcoin is scarce-money, Ripple is credit-money. They serve very different purposes.

Ripple is a higher-level framework to be placed on top of a more generic, lower-level framework like Open Transactions. Here's how you could implement Ripple on top of Open-Transactions:

https://github.com/FellowTraveler/Open-Transactions/issues/50

Please leave the environment-specified password as an option, however. In some environments (12-factor stacks like Heroku, for example) that remains the best available option.


I'm a little confused, does this project do full validation or not? Am I understanding it correctly that picocoin is and will remain a SPV thin-client, but libccoin implements (or will implement if it doesn't already) everything required to build a full validating node?

No, you're misunderstanding merged-mining (and btw, if you needed the same nonce to satisfy both proof-of-works, you'd need to do *a lot* more than twice as many hashes).

The hash of the auxiliary block header is included as data somewhere in a transaction of the parent chain. The aux proof of work then is the auxiliary block header for the sub-chain, a bitcoin transaction which contains the auxiliary block header's hash as data somewhere in one of its scripts, a valid bitcoin block header which meets at least the sub-chain's difficulty requirement, and the Merkle path linking the bitcoin transaction to the header. So the only header that ever has to meet a difficulty requirement is the bitcoin header, and the sub-chain aux value doesn't really matter. Make sense?

Yeah but guess what: you're not the only one who came to that conclusion. And lots of people bought-in anticipating the rise in price... which itself caused the price to rise. That's what I mean by being "already factored into the price." Look at the price 6 mo ago vs today. Hey, it doubled! Coincidence? Only partly.

I said it before and I'll say it again: reward halving has been factored into the price of btc/usd for months now.