|
I think some of bytemaster's BitShare ideas could work with this. Let's take NameCoin as a starting point and see what needs to change. I think the block reward would have to become variable so the prices in NameCoin can remain fixed, with the exchange rate adjusting to arrive at the market price for domain name services. This may need a minting rule coupled to a blockchain-based distributed exchange, where new coins are minted in response to bids that cannot be filled.
|
|
|
|
Just another thought ... would this go some way to achieving a stableish alt-coin/USD exchange rate?
That's a very interesting idea! The same might be true of other real-world blockchain-based services like domain name registration (like NameCoin if it ever gains wide adoption), timestamping, and - ironically - bytemaster's idea for a payment system for P2P communication services. A basket of a number of such alt-coins (or coloured coins?) could track fiat currencies, but would compensate for inflation. |
|
|
|
|
I saw a good suggestion the other day: if you intend to cash out your BTC, check if there are any goods or services you can buy with that BTC first.
|
|
|
|
|
Solo miners using ASICs who are selling off their newly minted coins each weekend?
|
|
|
|
|
In addition to using memory-hard hashing algorithms, would it be useful to investigate choosing a hashing function that requires the hashing core to be of similar complexity as a typical CPU execution unit? I'm thinking of something that uses multiplication, division and modular reduction relative to some large prime number, and elliptic curve group operations rather than the typical rotate, xor and addition modulo 2^n operations. If necessary we could always xor the result with an ordinary SHA256 hash.
|
|
|
|
Not many worthy causes accept bitcoins
There are a few, and more might follow if they saw what happened. Of course, I have no reason to believe Satoshi intends to do this, but I think it would be more useful than having the coins just sit there. It is true that having them sit there would increase the value of the remaining coins, but the publicity might have a greater effect. |
|
|
|
It's highly unlikely for him to spend the coins mined from the early blocks because doing so may reveal his identity.
He could safely donate them to worthy causes though. It might draw a lot of attention to both Bitcoin and the chosen causes. |
|
|
|
|
In light of the recent revelations about the massive warrantless surveillance by the NSA, some people have speculated that the NSA may have direct access to the private keys of some root certificate authorities. If that is true, then they can perform a man-in-the-middle attack against everyone. Would a blockchain structure help provide a distributed alternative that cannot easily be compromised by the NSA?
|
|
|
|
|
Not again, he already has his own thread.
|
|
|
|
|
Well done, a great initiative.
|
|
|
|
|
They are, but it's possible to be interested in the fiat payment system without the exchange functionality. It's true that the fiat system will silently make use of the exchange system if that leads to the cheapest path, but it doesn't need it. The exchange system does need the fiat system.
|
|
|
|
On further reflection, Ripple is actually composed of three systems, not two: - an alternative currency (XRP)
- a fiat IOU payment system
- a distributed exchange
I'm mainly interested in the fiat IOU payment system in order to use the distributed exchange functionality, and therefore I treated them as one, but it is of course possible to use just the payment functionality without ever using the exchange functionality. The payment system used alone could be seen as a rival to Bitcoin. Consequently, only the distributed exchange belongs in the Economy > Marketplace > Currency exchange section, while discussion of XRP and the fiat IOU payment system should go to the alt-coin section. |
|
|
|
|
The highly distilled idiocy that is often displayed here is astonishing. In all the years of fiery discussion on nasaspaceflight.com I've only ever put a single person on ignore. In the couple of weeks I've been here I've amassed over 200.
|
|
|
|
Here's a concrete example of how a more flexible Bitcoin scripting language would allow the creation of a system with properties between Zerocoin, and conventional chaum banking systems. Credit goes to Gregory Maxwell for the basic concept:
Is there a write-up of this somewhere? I need a lot more detail to understand what you are describing. First you deposit your funds with the chaum bank, and receive a chuam token back.
blinded chaum token = random "serial number" generated by you, encrypted with secret key known only to you, then signed with private key corresponding to well-known public key by bank? The bank maintains a txout on the blockchain with funds >= all outstanding tokens, and with a scriptPubKey of the following form:
Maintains a single txout rather than a Bitcoin address with the required amount in several transactions? Is this to sever any link between a specific txout and a redemption? How does the bank update this single txout when it issues a new token? I see nothing about this in your proposed script. if scriptSig contains proof of a valid token
and spending transaction contains a txout with the same restrictions:
return True
proof = random "serial number" generated by you, directly signed with private key corresponding to well-known public key by bank through the magic of a blind signature and not already redeemed in a previous transaction? same restrictions = new txout contains more than is necessary to cover all remaining oustanding tokens (i.e. previous amount minus what was just validly withdrawn) and requires a new not-yet-redeemed token? Totally off-chain transactions, IE chaum-for-chaum exchanges, can be handled as well by having the bank include all outstanding tokens in a merkle tree, and signing the tip of that tree along with an ever increasing serial number: if signature of the tip of the tree is valid:
let n = serial number in the signature
let m = existing serial number
if n > m
and spending transaction contains a txout with similar conditions, but n as the serial number:
return True
else if block height > y:
if spending transaction contains the redemption code (first example):
return True
tip =  similar conditions = |
|
|
|
|
Switching to another codebase is certainly one possibility, but refactoring the existing code is also a realistic option. Starting with a good test harness around bitcoind would be a good start for both options. And the existence of an API makes this a lot easier.
|
|
|
|
|
We're far beyond that point. The code needs very thorough restructuring. That can be done incrementally, even while others are adding functionality, but I think it is going to be very hard to get a consensus on the needed changes.
|
|
|
|
|
Let's not turn this into a C++ coding standards discussion.
|
|
|
|
|
Adam is justifiably proud of Hashcash, and it was an important influence on Bitcoin.
|
|
|
|
|
Gavin has said that the genius doesn't lie in the code base, but in the algorithms and that the code is crap. I agree with that assessment. There's a somewhat refactored version available that can also be used for alt coins, but I don't have a link handy right now. I've been thinking about refactoring the code myself. Everybody is afraid of breaking it since it appears to work, and that is reasonable to an extent, but on the other hand this code base is utterly unsuitable for serious work.
|
|
|
|
|
Show Posts
