|
I'll be happy to explain to journalists how Bitcoin works, but I don't really like to get my name in print. I don't know if that is any help.
|
|
|
|
Governments can force exchanges underground but they cannot kill Bitcoin or prevent people exchanging Bitcoins between themselves or prevent people to send or receive Bitcoins in exchange for products and services.
Ripple will be one such system for exchanging cryptocurrencies for cash. Governments cannot ''shutdown'' Bitcoin. But they can easily ''shutdown'' Ripple due to its centralized nature.
Only if Ripple stays centralised, which is not the plan and which would not be in their interests. |
|
|
|
If the social lending catches on (unlikely in the near term, imho) then you don't even need to depend on gateways in order to buy bitcoins, it would just facilitate trades through peer networks.
Social payment might be enough, with relatively small trust limits. |
|
|
|
|
So do you think there is still a role for hashcash as a separate (pseudo-)currency, albeit a merge-mined one, rather than using a hashcash-derived system with BTC postage?
|
|
|
|
legal issues may bring the whole thing down eventually.
Why do you think that? Ripple looks more resilient to repression than Bitcoin. Governments could force exchanges underground, maybe mostly to the level of informal P2P networks of single individuals, but that would still allow exchange between cash and XRP, BTC etc. |
|
|
|
It's two parts: Coinbase TxOut Hashcash and the PowPay system.
Sorry, I still don't understand what that means. |
|
|
|
It has been previously(1) proposed that hashcash using the same PoW
function as the Bitcoin block hashing algorithm be used to create
hashcash whose value is denominated in Bitcoins.
What was the goal of that proposal? It reminded me of the idea of using Bitcoin postage for Bitmessage, but in the rest of your post you appear to be talking about something else. |
|
|
|
Well, the lack of a user-friendly UI for it is still a serious issue. |
|
|
|
That would work, but how would they initiate such a thing? I don't believe bitcoin-qt or even any wallet supports this feature. I'm making a service for everyone. It has to be easy to use.
Absolutely, the UI is the thing to solve, everything else is already part of Bitcoin. The command line / JSON - RPC interface to bitcoind already lets you deal with raw transactions, but it's not user-friendly. If I were to do such a thing on my side, seems I would need their wallet's public key and private key, which isn't going to work.
Well, there are plenty of parties that will manage other people's wallets online, but I understand that's not what you want to do. The solution may be a custom client or additions to existing clients. |
|
|
|
So, sadly, multi-sign transactions/addresses cannot be used for this purpose. I may not be seeing a solution to above two problems, so if anyone finds a solution to above two problems, please let me know. I will implement multi-sig then.
Multi-signature is only one part of the problem, but the other part is almost trivial, except for making the UI for it user-friendly. You could use a single transaction that transfers the money from both parties' accounts to the multi-signature risk account. The transaction would specify two inputs, one for each party, in the amount agreed as risk + half of transaction fees, and one multi-signature output. To do this, the parties need to agree which UTXOs in the right amount they would use as inputs for this. Once they do this, Alice constructs the partial transaction, adds her own signature to her transaction input, and sends the partial, as yet invalid, transaction to Bob. Once Bob receives it, he adds his own signature to his own input and sends the now potentially valid transaction to the network. Only then does the combined transaction go into effect, provided the inputs exist and haven't been spent yet. Done this way, both parties will pay simultaneously or not at all. |
|
|
|
I don't think doing it off network changes anything about one party always being exposed to risk of having to sign first.
There's no risk of signing first. Both signatures have to be valid before the transaction is accepted by the network. There is of course still the risk of sending any physical goods first however. |
|
|
|
|
Why would there be regular destruction? If it works, that ought to be rare.
|
|
|
|
Super awesome, i just need to find a client that supports this then.
Turns out the Satoshi client does support it, but only through the command line / JSON-RPC interface. Geek-only for now. |
|
|
|
Bitcoin merges these 2 functions. The block chain creates a well defined ordering of blocks and also confirms that they are verified.
The timestamp chain would timestamp a merkle root. The leaf nodes would have no specific meaning. It would only create an ordering of leaf nodes, rather than specify the exact time. There is no verification performed on the timestamp chain, except that it meets POW.
Why would the timestamp chain even contain the leaf nodes? Why not make it a generic timestamping chain for more than just currencies? |
|
|
|
|
If I understand things correctly, you can already do this with Bitcoin. The protocol supports it, but not all clients / miners (or any at all) support it.
|
|
|
|
|
That looks like Objective C, not C++.
|
|
|
|
Nothing (except resource limits) stopping you from running multiple protocols over the same pipe...
And the more protocols, the more users and therefore the bigger the pipes and the greater the outcry against attempts to block those pipes. And since some protocols are more controversial than others, it will be easier to work on the shared parts. |
|
|
|
|
I just had a quick look at the oldest known version of the Satoshi source code and noticed the presence of market.h and .cpp. Does anyone here know the story of what happened to these files? I could try to search SF, but maybe people here have interesting stories to tell about it. Was this intended to be something like SilkRoad? If so, does it lend credence to the Satoshi = Dread Pirate Roberts theory?
|
|
|
|
Why don't we develop a coin where the proof of work is general purpose problem solver ?
One does not simply develop a coin where the proof of work is a general purpose problem solver. It would be very useful if that could be done, but as far as I know no one has found such a proof of work algorithm. It would have to be expensive to compute, with difficulty adjustable over a large range of values, easy to verify and capable of being tied to the hash of a specific block in the chain. |
|
|
|
Learn what an ASIC is please
Maybe you should learn what scrypt is. |
|
|
|
|
Show Posts
