Bitcoin Forum
May 09, 2016, 01:11:19 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 [105] 106 107 108 109 110 111 112 113 114 »
2081  Bitcoin / Alternative clients / Re: Python client on: August 30, 2010, 10:23:34 PM
I agree with the sentiment that a small reference client would be hugely helpful. I would like one that ran on Google App Engine, for instance, and as you say, a reference javascript version would be totally fabulous.
Neither of those are feasible-- both App Engine and Javascript don't allow arbitrary socket connections, and a full bitcoin client needs to maintain a persistent connection to at least one other bitcoin client to get transaction messages.

"Background servers capable of running for longer than 30s" is a feature on Google's roadmap, so maybe a 100% App Engine bitcoin client will be possible in the future.
2082  Bitcoin / Development & Technical Discussion / Re: Hiding the recipient and amount until the money is spent on: August 16, 2010, 08:30:27 PM
I just want to correct one little thing; excuse me for being nit-picky, I'll shut up after this:

Also, this: "All the network nodes try to decrypt the message with each of their public keys" ... won't scale.
... The equivalent scaling problem you mention applies with regards to the network checking normal transactions as the useage ramps up.
Assuming you have enough memory to store all your public keys in a hash table in memory, there is no scaling problem with normal transactions.  Since the TxOut contains the public key (well, the hash of the public key), it is constant time to figure out whether or not the TxOut is your public key.  You do NOT have to loop through all your public keys to see which one matches.
2083  Bitcoin / Development & Technical Discussion / Re: Hiding the recipient and amount until the money is spent on: August 16, 2010, 02:11:38 PM
RE: could you make through adroit use of the scripting language:  you could hide the receiving address, but not the amount.

Bitcoin needs to see TxOut amounts so it can add them up and make sure the transaction includes any necessary fees.

And to make sure the transaction is valid, although I suppose it could allow invalid-but-not-yet-decrypted transactions into the block chain, and just not allow them to be ever spent (it'd be a complicated way of deleting BTC).  But that makes me extremely nervous-- it seems to me it just makes things more complicated and more likely to be exploited.

Also, this: "All the network nodes try to decrypt the message with each of their public keys" ... won't scale.  Busy nodes will have more and more public keys over time (as they give out different receiving addresses for each purchase transaction), and trying them all whenever an encrypted transaction comes over the wire will take an ever-increasing amount of time.

2084  Bitcoin / Bitcoin Discussion / Re: Proposed solution to the latency problem (vending machine problem). on: August 15, 2010, 09:22:37 PM
.... This system requires that the majority work according to the protocol in any case.
...
The NY vending machine can only take the coin if it controls a lot of CPU power and can generate a block, but the whole bitcoin system is built on the assumption that the vast majority of CPU power is honest. And being honest with my proposal means following the pseudocode above.
Right, that's my issue with your proposal:  what incentive does the NY vending machine have to be honest?  It can be "dishonest", ignore verifiers all-together, and accept more transactions (better for it) with less work (also better for it).
2085  Bitcoin / Development & Technical Discussion / Re: overflow bug SERIOUS on: August 15, 2010, 09:10:33 PM
Looks good to me.

Can you easily hardcode a check for the bad block's hash at startup and orphan it and subsequent blocks if they're on the best-block chain?
It's painful to have to re-download all or most of the chain to fix this...
2086  Bitcoin / Development & Technical Discussion / Re: overflow bug SERIOUS on: August 15, 2010, 08:39:42 PM
Until there is a better fix... after a very small amount of testing this seems to work:
Code:
--- 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.
2087  Bitcoin / Bitcoin Discussion / Re: Proposed solution to the latency problem (vending machine problem). on: August 15, 2010, 07:43:09 PM
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.
2088  Bitcoin / Bitcoin Discussion / Re: Proposed solution to the latency problem (vending machine problem). on: August 15, 2010, 04:55:20 PM
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).
2089  Bitcoin / Bitcoin Discussion / Re: Proposed solution to the latency problem (vending machine problem). on: August 15, 2010, 01:08:59 PM
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.
2090  Bitcoin / Development & Technical Discussion / Re: [PATCH] implement 'listtransactions' on: August 15, 2010, 12:01:07 AM
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.
2091  Bitcoin / Development & Technical Discussion / Re: Proposed change to sendtoaddress API call on: August 14, 2010, 11:57:01 PM
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.
2092  Bitcoin / Bitcoin Discussion / Re: Coin generation participation survey on: August 14, 2010, 08:11:43 PM
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.
2093  Economy / Economics / Re: Universal Dividend on: August 14, 2010, 02:19:22 PM
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?
2094  Bitcoin / Development & Technical Discussion / Re: Proposed change to sendtoaddress API call on: August 14, 2010, 01:46:17 PM
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:
Code:
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();
 }
2095  Bitcoin / Development & Technical Discussion / Re: Proposed change to sendtoaddress API call on: August 13, 2010, 08:26:06 PM
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?
2096  Bitcoin / Development & Technical Discussion / Re: Proposed change to sendtoaddress API call on: August 13, 2010, 08:01:17 PM
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:
Code:
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
2097  Bitcoin / Development & Technical Discussion / Proposed change to sendtoaddress API call on: August 13, 2010, 07:28:23 PM
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?
2098  Bitcoin / Bitcoin Discussion / Re: Level of Anonymity on: August 13, 2010, 03:50:28 AM
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).
2099  Bitcoin / Development & Technical Discussion / Re: Where is the separate discussion devoted to possible Bitcoin weaknesses. on: August 11, 2010, 04:40:07 PM
+ 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)...
2100  Bitcoin / Development & Technical Discussion / Re: Where is the separate discussion devoted to possible Bitcoin weaknesses. on: August 11, 2010, 04:10:56 PM
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
Pages: « 1 ... 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 [105] 106 107 108 109 110 111 112 113 114 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!