Until there is a better fix... after a very small amount of testing this seems to work: --- a/main.h
+++ b/main.h
@@ -473,8 +473,12 @@ public:
// Check for negative values
foreach(const CTxOut& txout, vout)
+ {
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
+ if (txout.nValue > 21000000*COIN)
+ return error("CTransaction::CheckTransaction() : txout.nValue over-max");
+ }
if (IsCoinBase())
{
@@ -520,6 +524,8 @@ public:
int64 nValueOut = 0;
foreach(const CTxOut& txout, vout)
{
+ if (txout.nValue > 21000000*COIN)
+ continue; // ignore over-max-value...
if (txout.nValue < 0)
throw runtime_error("CTransaction::GetValueOut() : negative value");
nValueOut += txout.nValue;
You'll need to re-download the part of the block chain before the bad block-- remove the blkindex.dat and blk0001.dat files. I started with knightmb's blockchain snapshot. |
|
|
|
Also, there could be a lot of cpu power on Mars as well. So, the New York vending machine shouldn't accept a Mars coin within several hours.
My point is that if there is a lot less cpu power on Mars, then the Mars nodes will ALWAYS lose the "create the longest block chain" race. So the New York nodes will ALWAYS have the advantage. And it is nice to say the New York vending machine "shouldn't accept a Mars coin within several hours," but, in my experience, "shouldn't" doesn't cut it. If the New York candy machine CAN make the sale and keep the coins, it WILL. |
|
|
|
|
I'm better at thinking through things using specific examples, so bear with me: let's use Mars as the extreme case, and say I'm on Mars and want to double-spend some bitcoins.
I talk to my cousin in New York, and send him some coins with the "Mars" locality. We agree that we'll use the same coins to buy candy bars on January 1, 2040, 10:00:00 UTC, me on Mars and him in New York.
So the New York candy machine just rejects my cousin's transaction OR makes him wait the 40 minutes for communication between Earth and Mars? Wouldn't it be more likely that the New York candy machine just accepts the transaction after seeing no double-spends after, oh, I dunno, maybe two seconds?
After all, Bitcoin+ Payment Verification Systems, Incorporated knows it is highly connected into the majority Bitcoin network with very low latency, so it knows that if it blasts a transaction into the network and doesn't see a double-spend after two seconds the chances are very, very, very good that it will be declared the first spend.
If the New York payment system accepts the transaction every time, then the Mars verifier will lose every time. I'm pretty sure the New York folks will tell the Mars folks "tough cookies, you should set up MarsCoin for low-latency transactions up there."
I don't know much about high speed trading with millisecond latency, and, frankly, don't care much about high speed trading with millisecond latency. It wouldn't bother me at all if you can't use Bitcoin for that (and you have to set up a SpeedyCoin system for doing that sort of thing).
|
|
|
|
|
Your proposal seems needlessly complicated.
How about:
The vending machine talks to a "Bitcoin+ Payment Verification Systems, Incorporated" server.
The Bitcoin+ Payment Verification System is basically just a bitcoin node, with really fast international network connections and a little extra code to detect attempted double-spends. If it detects a double-spend attempt, it rejects the transaction. Otherwise, it accepts the transaction and blasts the transaction into the payment network over its really fast, as-low-latency-as-possible connections.
If it later turns out that the transaction actually WAS invalid, Bitcoin+ Payment Verification Systems, Incorporated absorbs the cost of the fraud.
Bitcoin+ Payment Verification Systems, Incorporated, of course, charges the vending machine merchant a fee for providing such excellent service. They're constantly competing with their arch-rivals, "Better Merchant Services, Incorporated" to balance latency, fees, and fraud to maximize profit.
|
|
|
|
|
The naming is getting messy: 'txn_id' and 'tx_time' mismatch for no good reason.
tx as short for 'transaction' is fine (bitcoin source uses that abbreviation all over the place), but the rest of the JSON-RPC API doesn't use underscores, so they aught to be txid and txtime.
|
|
|
|
|
Nah, satoshi uses <foo> to mean "replace this placeholder with the actual thingy."
It'd be annoying to constantly strip the < and > from the txid.
|
|
|
|
|
1) Have you been using bitcoin for more than two months?
Yes, almost 3 months now.
2) Are you currently attempting to generate coins?
No (well, not on the production network; I am generating blocks on the TEST network)
3) If not currently generating, have you attempted in the past? If generating, how long have you been generating?
Yes, before the big slashdot interest influx I was generating.
4) Have you ever succeeded in generating a block? Many blocks?
Probably around 10 blocks while I was generating.
5) Why or why not do you generate?
I'm a big believer in the power of division of labor and comparative advantage to make the world a better place. I don't have any particular advantage for mining bitcoins, and I bet people who _do_ (who have access to lots of cheap CPU cycles) will be more efficient at mining than me.
|
|
|
|
So you have a theory of distribution and need a currency to implement it? I suppose a Bitcoin-like currency could be modified to behave in this manner.
I see two fundamental problems with using a Bitcoin-like system to implement a Universal-Dividend-like system: 1. How does the system identify "individuals" ? If you've got a completely automated way of doing that I really want to know about it! freebitcoins.appspot.com could really use a foolproof system for identifying individuals. 2. If everybody gets a dividend, why would anybody bother running a block-generating node? What is the incentive for doing the work needed to support the system? |
|
|
|
It's too soon to start junking up the API for backward compatibility at all costs.
Just return "<txid>".
You'll never hear me argue with "keep it simple." Patch for that is trivial: diff --git a/rpc.cpp b/rpc.cpp
index 920fe90..35a336f 100644
--- a/rpc.cpp
+++ b/rpc.cpp
@@ -364,7 +364,7 @@ Value sendtoaddress(const Array& params, bool fHelp)
string strError = SendMoneyToBitcoinAddress(strAddress, nAmount, wtx);
if (strError != "")
throw runtime_error(strError);
- return "sent";
+ return wtx.GetHash().ToString();
}
|
|
|
|
What happens when we desire to return additional information, beyond tx-id?
For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current 'sent', or (b) a JSON map containing tx-id, and perhaps other things.
A 'gettransaction tx_id' API call is on my short list. What do other folks think; should sendtoaddress .... true return just the tx_id, and you have to make another API call to get details if you need them? Or should it return an Array? |
|
|
|
RE: adding a flag: great idea! If you set the flag, I don't see any reason to prepend 'sent' to the transaction ID; better to just return the transaction ID on successful send. Patches: diff --git a/rpc.cpp b/rpc.cpp
index 920fe90..8714b7e 100644
--- a/rpc.cpp
+++ b/rpc.cpp
@@ -342,10 +342,11 @@ Value getaddressesbylabel(const Array& params, bool fHelp)
Value sendtoaddress(const Array& params, bool fHelp)
{
- if (fHelp || params.size() < 2 || params.size() > 4)
+ if (fHelp || params.size() < 2 || params.size() > 5)
throw runtime_error(
- "sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]\n"
- "<amount> is a real and is rounded to the nearest 0.01");
+ "sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] [return-tx-id-flag]\n"
+ "<amount> is a real and is rounded to the nearest 0.01\n"
+ "returns string 'sent' if return-tx-id-flag is false (default), otherwise returns transaction id.");
string strAddress = params[0].get_str();
@@ -361,9 +362,15 @@ Value sendtoaddress(const Array& params, bool fHelp)
if (params.size() > 3 && params[3].type() != null_type && !params[3].get_str().empty())
wtx.mapValue["to"] = params[3].get_str();
+ bool fReturnTxID = false;
+ if (params.size() > 4)
+ fReturnTxID = params[4].get_bool();
+
string strError = SendMoneyToBitcoinAddress(strAddress, nAmount, wtx);
if (strError != "")
throw runtime_error(strError);
+ if (fReturnTxID)
+ return wtx.GetHash().ToString();
return "sent";
}
@@ -1103,6 +1110,7 @@ int CommandLineRPC(int argc, char *argv[])
if (strMethod == "setgenerate" && n > 0) ConvertTo<bool>(params[0]);
if (strMethod == "setgenerate" && n > 1) ConvertTo<boost::int64_t>(params[1]);
if (strMethod == "sendtoaddress" && n > 1) ConvertTo<double>(params[1]);
+ if (strMethod == "sendtoaddress" && n > 4) ConvertTo<bool>(params[4]);
if (strMethod == "listtransactions" && n > 0) ConvertTo<boost::int64_t>(params[0]);
if (strMethod == "listtransactions" && n > 1) ConvertTo<bool>(params[1]);
if (strMethod == "getamountreceived" && n > 1) ConvertTo<boost::int64_t>(params[1]); // deprecated
|
|
|
|
|
I'm proposing one small change to Bitcoin's JSON-RPC api: return a transaction ID when Bitcoins are successfully sent.
Why? Because I want to keep a complete audit trail for any coins going into or coming out of my application's wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes. The alternative is to call sendtoaddress and then call listtransactions, but that won't work properly if two similar transactions (same amount to same address) occur at about the same time.
So I propose doing the simplest thing possible: modify the JSON-RPC sendtoaddress call so it returns the string 'sent:' followed by the 256-bit-hexadecimal transactions id.
This could break any applications that look for exactly the string 'sent' (which is what sendtoaddress does now). The fix would be to modify the apps to see if the string began with 'sent'.
Alternatives I thought about but think I don't like:
+ make it a new api call so old apps do not break (sendtoaddress2 ? yuck)
+ return just the transaction id on successful send instead of 'sent:...'
+ return an array with more information (maybe [ "tx_id": "...", "fee" : 0.0 ] )
Comments/criticisms?
|
|
|
|
|
Very quick reply, I should be going to sleep:
I think it would be helpful to describe how much anonymity you can expect based on what you expect from a potential attacker.
There's a big difference between "I'm worried about somebody tracing transactions back to me by looking through the block chain" (easy solution: mix up your coins by sending them to and from a mybitcoin.com account a couple of times over a couple of days; send them in batches over time to be really safe) and "I'm worried about somebody tracing the transactions I'm making by watching all of the IP traffic coming from my machine (much, much harder to guard against).
|
|
|
|
+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).
Isn't that a brilliant idea? Like hashcash? You would be required to hash the string of the transaction, with a proof of work, that would say, take 5 seconds to calculate on a modern PC. Checking the POW just like in bitcoin would be easy and very quick for the receiving machines, but would stop a flood attack of random data without the attacker having limitless CPU power. I was actually thinking of a minute or three of proof-of-work on initial connection, not when submitting a transaction, but requiring some proof-of-work for every transaction submitted into the network IS a very interesting idea! Should be straightforward to implement, too (add a nonce and either a full or partial hash to the transaction)... |
|
|
|
Bitcoin's p2p network is subject to various kinds of denial of service attacks. There, I said it. Do you have constructive suggestions for how to fix it, or are you the kind of person who just enjoys breaking things because you can? Ideas that have been bouncing around my head that may or may not work: + have clients tell each other how many transactions per unit of time they're willing to accept. If a client sends you more (within some fuzz factor), drop it. Compile in a default that's based on estimated number of transactions for a typical user and estimate on the number of current users. + require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks). This is an active area of research; see, for example: http://scholar.google.com/scholar?q=ddos+attacks+by+subverting+membership |
|
|
|
The micro transaction fee only applies to the the 'out' side.
Right, but every TxIn has to have a corresponding TxOut (except for GENERATE/coinbase transactions, but those have their own rules). So if you want a 0 BTC TxIn, you've gotta first pay yourself with a 0BTC TxOut and that'll trigger the fee. TxIns don't contain a value, the value is in the corresponding TxOut... Anyone who is accepting 'bad' transactions and returning good coins deserves to give their money away.
But you agree that it wouldn't be OK for a 'refundtransaction' API call to make it easy to do that, right? |
|
|
|
Are transactions allowed to have input addresses with a zero balance?
If they are (I didn't see anything preventing them after a quick reading of the code), then they trigger the 0.01BTC micro-transaction fee. I'll be doing a lot of experimenting (on the TEST network, of course) with refunding transactions over the next few weeks. I think the UI issue can be resolved (it should be pretty straightforward to teach the UI to recognize refund transactions and show them as "refund from BLAH", where BLAH is either a BC address or a label from your address book. I've already implemented a "refundtransaction" api call, but it still needs work before it would be ready for standard bitcoin. In particular, it shouldn't be possible to create infinite 'refundtransaction' loops (where you accidentally or purposely refundtransaction a refunded transaction, probably triggering another refund, etc). And refunding a transaction should, ideally, use the same "coins" (... should have the same ancestor transactions, for anybody who's going to get all pedantic on me) as the original transaction, if possible, so if that original transaction is exactly as valid as the original transaction. Otherwise it might be possible to generate a bad transaction, send it somewhere you know it will get refunded immediately with different, valid transactions, and so "launder" your bad bitcoins for good. |
|
|
|
I very much doubt that any one entity will ever have 50% of the computational power. The botnet operators will bow to the whims of the community because it's the community that ultimately gives bitcoins value. What good is a giant load of bitcoins if you don't have anyone willing to give you something in exchange for them?
Eventually the largest merchants and money exchangers will control what is "standard" bitcoin. Take the "50-coiners" scenario, and imagine that they manage to get 75% of the CPU power on their side. But imagine that the biggest merchants and money exchangers are more conservative, and are in the 25% minority. I think they will be-- I don't think they'll be the ones in the business of generating coins (they'll be busy selling products or doing the exchange thing). What happens? Well, the block chain splits. Transactions using coins minted before the split will get added to both block chains, and accepted by everybody. Transactions involving "50-coins" (generated after the split) will be accepted on the 50-coin chain, rejected on the 25-coin chain. And vice-versa. "50-coiners" would quickly find out that they couldn't get rid of their newly minted money because who wants bitcoins that are rejected by the biggest money exchangers or merchants? If the big merchants and money exchangers disagreed, I bet you'd see Bitcoin clients that ONLY accepted pre-split coins and did no coin generation (since those transactions would be accepted by everybody). If it was never resolved, I think the number of Bitcoins at the time of the split would become "the number of Bitcoins, period," because most people will not want to use money that is accepted some places and not others. |
|
|
|
So, Bitcoin motivates behavior of stealing computing power from innocent computer owners.
Sure, in exactly the same way the existence of credit cards motivates behavior of stealing credit card numbers from innocent credit card users. Or the existence of bank accounts motivates hackers to try to break into your system to find out your bank account number. Or the existence of cars motivates some people to steal gasoline from innocent service station owners. I believe the benefits of Bitcoin will outweigh the harm, and I further believe that I am capable of making that moral judgment. I might be wrong, and I might regret I ever got involved, but if I only ever did things that I was 100% certain were going to work out for the best I would never accomplish anything new and interesting. |
|
|
|
Is the main thrust and incredulity in your argument because you think there CANNOT be a better solution than burning 100,000 CPU at 100% 24/7 and sending 100,000+ redundant messages per transaction?
No, not at all. Like I said when I jumped into this thread, I think using a DHT network to somehow distribute the work is a very interesting idea, it just seems to me any solution that partitions the network will be more vulnerable to attacks that insert malicious nodes. I think it would be fantastic to come up with less resource-intensive solution that actually works. How does Freenet generate node IDs? The only info I see in the latest Freenet paper is: When joining, nodes choose an identity at random, and then connect to those peers with whom they have a pre-established trusted relationship. .... and: The perhaps largest advantage that the trusted-connection model offers over traditional anonymity networks is protection against the Sybil attack [13], where a single attacker infiltrates the network by pretending to have many identities. Since the network depends on out of band trust relationships, an attacker gains strength only through the number of people he can fool into trusting him, and gains nothing by presenting multiple identities online. ...which doesn't sound like it would work very well for Bitcoin. |
|
|
|
|
Show Posts
