This is all hypothetical, the sort of thing that might be on the hard-fork wish list: As others have mentioned though, there's not really a need until sub-satoshi amounts have any real-world value.
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.
|
|
|
What is this I don't even...
I'm trying to make sense of what he's saying so I can respond properly, but it sounds like he doesn't know what he's talking about... There are a lot of people participating in the discussion (who know nothing about technology/cryptography) who might be lead astray by tossing around a few $2 words (or I should say 0.148 BTC words lol). 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). But as far as I understand it, in the current implementation you need to trust the issuer. What I'm proposing would mean that not even the issuer has access to your coins. The issuer would be the only entity that can decrypt the bitcoin private key in the token. But they don't have acces to the tokens except when someone wants it redeemed.
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.
|
|
|
Will it be possible for a US citizen to open an account and use direct deposit to buy bitcoins?
Congratulations. Sounds amazing. To use the services mentioned, debit card etc, do I have to live in the EU, or France, or is it available to everyone?
We won't have limitations regarding the citizenship of our clients. 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?
|
|
|
CPU profiling of pynode indicates that the vast majority of CPU time -- a significant, noticeable slowdown -- occurs in simple Python data structure copying. Bitcoin's SignatureHash function requires copying an entire CTransaction, modifying it a bit, then hashing the serialized result. This would not be noticeable in a lightweight client, but it is the #1 cause of slowdown when verifying a bitcoin block. 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.
|
|
|
If you give me the code, I'll run it and share half the prize with you if I find it.
Why should he believe you? What if I said that if I was given the code, and I found it, I'd give him 2/3 of the prize? Why should he believe me? 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 I google the password, I get no meaningful results, just websites dedicated to listing every possible 5-character combination.
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 and Open Transactions are more probably competitors 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
|
|
|
AES encryption is applied to the wallet. Passphrase is specified via environment variable PICOCOIN_PASSPHRASE. Is this secure? My understanding is that the environment isn't a safe place to store/transmit information. That's temporary. It will input via fd like GPG soon. 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?
|
|
|
I said it before and I'll say it again: reward halving has been factored into the price of btc/usd for months now.
Let us wait 'till december has passed with judging this. I doubt it's been priced in correctly. I agree with molecular; The production has just halved, if the demand stays the same and no extra reserves are being used, the price should double. Of course, when the price rises, some reserves are taken in to markets which slows down the rise. But this is just speculating. We'll see. 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.
|
|
|
|