Bitcoin Forum
January 20, 2025, 04:45:02 PM *
News: Community Awards voting is open
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 54 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 »
2061  Bitcoin / Development & Technical Discussion / Bitcoin Payment Request mime type (instead of bitcoin:URI) on: September 17, 2010, 06:16:14 PM
The bitoin URI thread has died down, but bitcoinmarket and MtGox's spiffy "click to pay" features prompted me to think some more about payment links on web pages.

The problem with the MtGox/Bitcoinmarket solutions is that they still require you to copy&paste an address if you want to pay directly from the bitcoin client running on your machine.  My computer-phobic relatives just won't be able to do that (I can hear them saying "...BUT I DON'T HAVE A COPY BUTTON...").

But a bitcoin: URI has problems, too:
 1. It is hard to implement-- every browser has a different way of registering protocol handlers.
 2. If you don't have the protocol handler installed, clicking on the link doesn't give you any help on what to do to make it work.  (try it here)
 3. Looks like some software (like this forum) don't like bitcoin URIs: Donate to the Faucet (that URI is bitcoin:15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC, the forum software is truncating it and adding http://).

Maybe a bitcoin payment request MIME type would work better; you click on a link and the web server returns a little file of type "application/bitcoin-payment-request".  Like this. Or the links on this page.

If you're running Firefox, you get this dialog box if it doesn't know about application/bitcoin-payment-requests:


On PCs, an app can add stuff to the registry to associate itself with a mime type (anybody know if browsers other than IE pay attention to those registry settings?).

Macs are similar (although I don't know the details; gotta set the mime type in the App's Info.plist, I believe...).  Anybody know about Linux?

Teaching the Bitcoin application to read the bitcoin-payment-request file would be easy, and it shouldn't be terribly hard to get it to ask an already-running Bitcoin to popup a "Send Payment To..." dialog box with fields filled in (OR get it to start itself running and then popup the dialog box).

So: whaddya think?
2062  Bitcoin / Bitcoin Technical Support / Re: DNS name tx on: September 16, 2010, 02:15:21 AM
What is the use case for this?

Is it just to make it easier to send anonymous donations by typing in Pay To: "redcross.org" instead of copying&pasting a bitcoin address?

If something like that were implemented, seems like it would just invite the same kind of abuse we see with misspelled-domain-squatters-- setup a domain record for "redcros.org" pointing to a non-Red Cross bitcoin address and take advantage of people's fat-fingered misspellings.  One big advantage of bitcoin addresses is that they have a built-in checksum, so if you misspell them (or screw up the copy&paste) your attempted transaction will be immediately rejected.
2063  Bitcoin / Bitcoin Discussion / Re: History of Bitcoin on: September 15, 2010, 08:24:50 PM
I added some information on the "OP_RETURN" bug that triggered the 0.3.5 release (and that we weren't talking about because we didn't want it to get exploited on the main network before people had a chance to upgrade).
2064  Other / Off-topic / Re: SSL Certificates on: September 15, 2010, 05:20:59 PM
Picking up from the original thread...

Bitcoin-related sites that have self-signed or CACert certificates (like mybitcoin.com) look unprofessional and un-trustworthy to clueless non-techies.

I know, I know, a Verisign-certified certificate isn't really any guarantee of security, but that doesn't matter-- if you want ordinary users to start trusting your website, get a certificate that doesn't popup any scary-looking security warnings.
2065  Bitcoin / Development & Technical Discussion / Re: HTTPS support for bitcoin JSON-RPC on: September 15, 2010, 03:16:41 PM
Implementation was easy, once I figure out how boost::asio::ssl::stream worked...

Anyway, I've created a git branch for anybody who's willing to help test:
  http://github.com/gavinandresen/bitcoin-git/tree/jsonhttps

Documentation for what I done did:

Communicating with the Bitcoin JSON-RPC interface over SSL (https)

By default, bitcoin allows JSON-RPC commands to be sent to
http://localhost:8332/, and accepts connections only from the local
host.

It can be configured to allow https connections from other hosts;
three things must be setup for this to work properly:

1. You must setup a server certificate and private key.  A self-signed
certificate will work, you don't need a certificate signed by Verisign
or another certificate authority.

By default, bitcoin looks for the server's private key file in a
"server.pem" in the bitcoin data directory (e.g. ~/.bitcoin/server.pem
on unix), and the server certificate file in "server.cert".  To
generate them using the openssl command-line program, run:

  cd ~/.bitcoin
  openssl genrsa -out server.pem 2048
  openssl req -new -x509 -nodes -sha1 -days 3650 -key server.pem > server.cert

You should NOT enter a passphrase.

2. Specify the IP addresses of clients that are allowed to connect using
"rpcallowip" configuration file options.

Edit the bitcoin.conf file (in the bitcoin data directory), and add a
line for each IP address allowed to connect:
  rpcallowip=10.11.13.15
  rpcallowip=10.11.13.16
You may also allow connections from any IP address in a subnet using *:
  rpcallowip=192.168.1.*
  rpcallowip=10.1.*.*
You can also specify 'rpcallowip=*' to allow all IP addresses.

Connections from the local host (127.0.0.1) are always allowed.

3. You must tell bitcoin to use ssl using the "rpcssl" configuration file option.

Edit the bitcoin.conf file, and add:
  rpcssl=true

Restart bitcoin or bitcoind to make these changes take effect.  You
can test bitcoin's ssl functionality using the openssl s_client command:

  openssl s_client -connect localhost:8332

The connection should be successful and you should see the server's
certificate details.  If you press return twice, you should get a
'HTTP/1.0 401 Authorization Required' response.


Client setup

Once the server is accepting https connections, to be secure you should
make sure the client is actually connecting to the bitcoin server and
not an attacker trying to hijack the connection.

If you can, you should copy the server.cert certificate chain file to
the client machine and use it to validate the OpenSSL connection.
For example, in php you would call stream_context_create() with
the 'verify_peer' and 'ca_file' options and then call
stream_context_set_default().

If you can't validate using the server certificate, you should connect
to the server using its IP address instead of its host name.


All HTTPS-JSON-RPC-related bitcoin.conf options:

rpcport      : default: 8332  Listen for connections on this port
rpcuser      : user for HTTP BASIC authentication
rpcpassword  : password for HTTP BASIC authentication
rpcssl       : Not set by default, if set bitcoin will only accept SSL
               connections
rpcallowip   : Allow a client at this IP address to connect
               (may be specified multiple times)
rpcsslciphers: default "TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH"
               (see the openSSL documentation for syntax)
rpcsslcertificatechainfile : default "server.cert"
rpcsslprivatekeyfile       : default "server.pem"

2066  Bitcoin / Bitcoin Discussion / Re: Message Encryption as a built-in feature? on: September 14, 2010, 07:35:34 PM
encrypt by default, with payee's public key
... but a payer typically has only the bitcoin address, and not the payee's full public key.  There'd have to be some way to get the full public key for a bitcoin address.

I like the idea of being able to send encrypted messages to "whoever has bitcoin address BLAH", but I'm not sure that functionality should be piggybacked on the "send BLAH X.YZ bitcoins".

If they were implemented under the covers as separate functions, then a "Send a message along with payment" could easily be implemented as:
  1. Send BLAH X.YZ bitcoins, and note the transaction ID.
  2. Send BLAH an encrypted message:   "txid:{transaction_id}:Please send the sixteen My Little Pony DVDs to..."
2067  Bitcoin / Development & Technical Discussion / Python code for validating bitcoin address on: September 13, 2010, 12:38:24 PM
This bitcoind address validator is a subclass of the Django forms.CharField class, but could easily be adapted to other frameworks or to be standalone code.

It does a "deep" validation, checking that the checksum built into every bitcoin address matches the address. It needs the PyCrypto library for the SHA256 function.

I hereby release this code into the public domain, do with it what you will.  And please let me know if you find any bugs in it.

BCAddressField.py:
Code:
#
# DJango field type for a Bitcoin Address
#
import re
from django import forms
from django.forms.util import ValidationError
from Crypto.Hash import SHA256

class BCAddressField(forms.CharField):
  default_error_messages = {
    'invalid': 'Invalid Bitcoin address.',
    }

  def __init__(self, *args, **kwargs):
    super(BCAddressField, self).__init__(*args, **kwargs)

  def clean(self, value):
    value = value.strip()
    if re.match(r"[a-zA-Z1-9]{27,35}$", value) is None:
      raise ValidationError(self.error_messages['invalid'])
    version = get_bcaddress_version(value)
    if version is None:
      raise ValidationError(self.error_messages['invalid'])
    return value

import math

__b58chars = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
__b58base = len(__b58chars)

def b58encode(v):
  """ encode v, which is a string of bytes, to base58.                                                                                                              
  """

  long_value = 0L
  for (i, c) in enumerate(v[::-1]):
    long_value += (256**i) * ord(c)

  result = ''
  while long_value >= __b58base:
    div, mod = divmod(long_value, __b58base)
    result = __b58chars[mod] + result
    long_value = div
  result = __b58chars[long_value] + result

  # Bitcoin does a little leading-zero-compression:                                                                                                                  
  # leading 0-bytes in the input become leading-1s                                                                                                                  
  nPad = 0
  for c in v:
    if c == '\0': nPad += 1
    else: break

  return (__b58chars[0]*nPad) + result

def b58decode(v, length):
  """ decode v into a string of len bytes                                                                                                                            
  """
  long_value = 0L
  for (i, c) in enumerate(v[::-1]):
    long_value += __b58chars.find(c) * (__b58base**i)

  result = ''
  while long_value >= 256:
    div, mod = divmod(long_value, 256)
    result = chr(mod) + result
    long_value = div
  result = chr(long_value) + result

  nPad = 0
  for c in v:
    if c == __b58chars[0]: nPad += 1
    else: break

  result = chr(0)*nPad + result
  if length is not None and len(result) != length:
    return None

  return result

def get_bcaddress_version(strAddress):
  """ Returns None if strAddress is invalid.  Otherwise returns integer version of address. """
  addr = b58decode(strAddress,25)
  if addr is None: return None
  version = addr[0]
  checksum = addr[-4:]
  vh160 = addr[:-4] # Version plus hash160 is what is checksummed                                                                                                    
  h3=SHA256.new(SHA256.new(vh160).digest()).digest()
  if h3[0:4] == checksum:
    return ord(version)
  return None
October 20: Fixed bug with bitcoin addresses with leading-1's.
2068  Bitcoin / Development & Technical Discussion / Re: HTTPS support for bitcoin JSON-RPC on: September 08, 2010, 01:27:16 PM
Unlike a public HTTPS web server, which accepts connections from anybody, the bitcoin HTTPS JSON-RPC server will only accept connections from trusted clients, and you'll almost certainly be your own root certificate authority-- there is no reason to pay for a Verisign certificate, you should generate your own and deploy it with the code that is talking JSON-RPC to your server.

Or, in other words, since you'll control both ends of the conversation (as opposed to a web server, where you typically control EITHER the server OR the web browser) you can make it completely secure.
2069  Bitcoin / Development & Technical Discussion / Re: HTTP status codes from the JSON-RPC api on: September 06, 2010, 07:18:04 PM
Speak now about this change or forever hold your peace...  Satoshi will be including this functionality in the next version of Bitcoin (0.3.12).

If you use the JSON-RPC api, you should check your error-condition-handling code; again, the changes are that the error member will be an Object (with 'code' and 'message' fields) instead of a String, and the HTTP status code may be 404 instead of 500 for method-not-found.
2070  Bitcoin / Development & Technical Discussion / Re: HTTPS support for bitcoin JSON-RPC on: September 06, 2010, 04:48:32 PM
Bear with me, this is a brain dump to try to organize my thoughts on securing the client <--> bitcoin JSON-RPC connection:

First: Preventing man-in-the-middle attacks:

HTTPS only prevents man-in-the-middle attacks if it is implemented properly by the client.  Example attack scenario against a lazy client:
  • Client connects to "https://bitcoinservice.org:8332/"
  • Attacker intercepts connection (e.g. via a DNS poisoning attack), and connects to the client using it's certificate.
  • Client gets certificate and doesn't bother to verify that the connection certificate is for bitcoinservice.org.  Completes SSL handshake.
  • Client then continues conversation by sending JSON-RPC request containing unencrypted rpcuser/rpcpassword.
  • Attacker now has rpcuser/rpcpassword and can mount a man-in-the-middle attack against the bitcoin server.

The "correct" way to prevent this is for clients to properly authenticate the server's certificate, but I don't think that's practical-- the default behavior for most url-opening libraries (used by the various JSON-RPC libraries) is to NOT validate server certificates.  You have to write extra code to install certificate authorities and/or write callbacks to examine the certificate and determine whether or not it is the certificate you expect.

I think a more practical way for the client to prevent a man-in-the-middle attack is for the client to hard-code the bitcoin server's IP address and avoid any DNS lookups-- connect to http://111.11.11.111:8332/ (if bitcoinservice.org is at IP 111.11.11.111).  It is much, much harder to successfully IP spoof a TCP connection than it is to successfully poison a DNS cache.

"Security in depth" is a good idea, and I've thought about layering other mechanisms for making the client->server connection secure, but I think we'd just be duplicating SSL functionality.  For example, I can imagine encrypting the whole JSON-RPC request string with a pre-shared key known to the clients and the server, but that's just a lame version of the strong encryption you get from SSL if the client is properly validating server certificates.  I think the security-in-depth will come from having the server authenticate clients, which brings me to:

Second: Authenticating clients:

The whole point of implementing HTTPS on the bitcoin JSON-RPC port is to allow connections from IP addresses other than 127.0.0.1.  But the "security-in-depth" idea means we almost certainly don't want to allow just anybody to connect and start sending bitcoins from our wallet.  Even if an attacker manages to steal the rcpuser/rpcpassword, we'd like to prevent them from emptying out our wallet if they try to connect from an unauthorized machine (if they can connect from an authorized machine you're already screwed).

Again, the "correct" way to authenticate clients is to do the public-key-infrastructure thing (... create a master bitcoin certificate you'll use as your certificate authority, then create public/private keys and certificates signed by that authority and require the clients and server to accept only connections properly signed with the right keys...).   And I think bitcoin should definitely support validating client certificates (that's just a couple of lines of OpenSSL library calls).

But again, I'm worried that some people deploying bitcoin either won't bother or will be using languages/libraries/systems that make it difficult or impossible to send a client certificate when connecting.

Hard-coding the IP addresses of clients that are allowed to connect via HTTPS (maybe allowing wild-carding of IP ranges) is a much easier-to-setup, almost-as-secure, way to authenticate clients.

So, to summarize my current thoughts on all this:

Recommendation for clients will be to:
  • Connect to the bitcoin JSON-RPC port via IP address and/or:
  • Properly validate the bicoin server certificate

The bitcoin JSON-RPC-https server will require:
  • Server private/public keys (generated using openssl, filename/path specified in bitcoin.conf file)
  • IP addresses (or ranges) of clients that are allowed to connect in the bitcoin.conf file
  • (optional)Certificate authority file used to validate clients (they must connect using a certificate signed by that authority)

What do y'all think-- sound reasonable?
2071  Bitcoin / Development & Technical Discussion / Re: HTTPS support for bitcoin JSON-RPC on: September 03, 2010, 11:41:13 PM
Nobody volunteered, but the boost ssl LOOKS like it will make it easy... so I've started playing around with it.

After much wrestling with the (sucky) OpenSSL and boost::asio::ssl docs, I've got a standalone, dumb, Satoshi-style-c++ https server running (code below).

Are there any real OpenSSL experts here who can review the code and answer questions like:

 + I understand the temp Diffie-Hellman file contains large prime numbers used to do public key exchange.  Everything works just fine if I leave out the call to context.use_tmp_dh_file; what are the security implications?  Will it matter for what we'll be doing (securing the JSON-RPC channel from eavesdropping/man-in-the-middle attacks)?

 + I'm following the advice from here, excluding old, low-security ciphers using:
    SSL_CTX_set_cipher_list(context.impl(), "TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH");
    Am I correct in assuming that any sane JSON-RPC/HTTP/HTTPS library will support the higher-strength ciphers?  Or does Java on a PC do something braindead and support only DES-MD5?  (and yeah, I'll make this overridable via a config file param, but I want to get the defaults right)

+ Oh, and a C++ expert question:  what magic incantation will turn the boost::asio::ssl::stream into an iostream that understands << and >> ?

And thumbnail sketch of how I imagine this working with bitcoin:

+ config file setting to turn on ssl/tls rpc  ( maybe rpcssl=true ... or should it be rpctls=true ? )
+ if turned on, only ssl connections accepted on the rpcport
+ if turned on, bitcoin binds rpcport to all addresses (not just 127.0.0.1)

Code:
#include <boost/asio.hpp> 
#include <boost/asio/ssl.hpp>
#include <boost/foreach.hpp>
#include <iostream>
#include <sstream>
#include <string>

using namespace std;
using namespace boost;
using boost::asio::ip::tcp;

typedef boost::asio::ssl::stream<boost::asio::ip::tcp::socket> ssl_stream;

string HTTPReply(int, const string&);

int main()
{
    // Bind to loopback 127.0.0.1 so the socket can only be accessed locally                                           
    boost::asio::io_service io_service;
    tcp::endpoint endpoint(boost::asio::ip::address_v4::loopback(), 1111);
    tcp::acceptor acceptor(io_service, endpoint);

    boost::asio::ssl::context context(io_service, boost::asio::ssl::context::sslv23);
    context.set_options(
        boost::asio::ssl::context::default_workarounds
        | boost::asio::ssl::context::no_sslv2);
    context.use_certificate_chain_file("server.cert");
    context.use_private_key_file("server.pem", boost::asio::ssl::context::pem);
    context.use_tmp_dh_file("dh512.pem");
    SSL_CTX_set_cipher_list(context.impl(), "TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH");

    for (;;)
    {
        // Accept connection                                                                                           
        ssl_stream stream(io_service, context);
        tcp::endpoint peer_endpoint;
        acceptor.accept(stream.lowest_layer(), peer_endpoint);
        boost::system::error_code ec;
        stream.handshake(boost::asio::ssl::stream_base::server, ec);

        if (!ec) {
            boost::asio::write(stream, boost::asio::buffer(HTTPReply(200, "Okely-Dokely\n")));
        }
    }
}

string HTTPReply(int nStatus, const string& strMsg)
{
    if (nStatus == 401)
        return "HTTP/1.0 401 Authorization Required\r\n"
            "Server: HTTPd/1.0\r\n"
            "Date: Sat, 08 Jul 2006 12:04:08 GMT\r\n"
            "WWW-Authenticate: Basic realm=\"jsonrpc\"\r\n"
            "Content-Type: text/html\r\n"
            "Content-Length: 311\r\n"
            "\r\n"
            "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\"\r\n"
            "\"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd\">\r\n"
            "<HTML>\r\n"
            "<HEAD>\r\n"
            "<TITLE>Error</TITLE>\r\n"
            "<META HTTP-EQUIV='Content-Type' CONTENT='text/html; charset=ISO-8859-1'>\r\n"
            "</HEAD>\r\n"
            "<BODY><H1>401 Unauthorized.</H1></BODY>\r\n"
            "</HTML>\r\n";
    string strStatus;
    if (nStatus == 200) strStatus = "OK";
    else if (nStatus == 400) strStatus = "Bad Request";
    else if (nStatus == 404) strStatus = "Not Found";
    else if (nStatus == 500) strStatus = "Internal Server Error";
    ostringstream s;
    s << "HTTP/1.1 " << nStatus << " " << strStatus << "\r\n"
      << "Connection: close\r\n"
      << "Content-Length: " << strMsg.size() << "\r\n"
      << "Content-Type: application/json\r\n"
      << "Date: Sat, 09 Jul 2009 12:04:08 GMT\r\n"
      << "Server: json-rpc/1.0\r\n"
      << "\r\n"
      << strMsg;
    return s.str();
}
2072  Bitcoin / Development & Technical Discussion / HTTPS support for bitcoin JSON-RPC on: September 01, 2010, 10:06:42 PM
But, use of HTTP-Basic is just a crime, because it is so trivial to obtain the shared secret.  If HTTP-Basic is to be kept, at least require SSL connections?
It isn't trivial to obtain the secret unless you patch the code to bind to interfaces other than loopback....

SSL connections are The Right Answer.

If I had any OpenSSL programming experience I'd volunteer to implement it.  Anybody willing and able to teach bitcoin to speak https?

And for extra credit, support SSL client certificates for authentication either instead of or in addition to HTTP-Basic...
2073  Bitcoin / Development & Technical Discussion / HTTP status codes from the JSON-RPC api on: September 01, 2010, 08:28:15 PM
I just submitted a patch to Satoshi to make bitcoin follow the JSON RPC over HTTP spec, and to use the standardized error codes from the JSON-RPC 1.1/2.0 specs.

If you talk directly to bitcoin via JSON-RPC calls, you might need to change your code to recognize the new HTTP status codes and the new format for the 'error' member of the JSON response.  For example:

BEFORE, send {"id":"123", "method": "nosuchmethod", "params": [] } , get response:
Code:
HTTP/1.1 500 Internal Server Error
...

{"result":null,"error":"Method not found.","id":"123"}
AFTER:
Code:
HTTP/1.1 404 
...

{"result":null,"error":{"code":-32601,"message":"Method not found"},"id":"123"}

I also removed the broken 'Batch' support, to simplify the code.  I had JSON-RPC-2.0 batch support working properly, but backed those changes out because JSON-RPC 2.0 is way too cutting-edge for bitcoin to support right now (none of the JSON-RPC glue libraries support it yet, and the spec is still changing a bit).
2074  Bitcoin / Development & Technical Discussion / Re: [PATCH] implement 'listtransactions' on: September 01, 2010, 07:35:27 PM
RE: binding to any/all IPs:  DANGER! Make sure you have good firewall rules for port 8332 or you are likely to find yourself with an empty wallet!  Bitcoin is using HTTP BASIC authentication, so anybody who can eavesdrop on the connection between your JSON-RPC client and the bitcoin server can see the password (it is NOT encrypted).
I was thinking about adding support for Digest auth...
I wouldn't bother-- HTTP Digest auth is vulnerable to man-in-the-middle attacks, it'd be a lot of work for a probably false sense of security.
2075  Bitcoin / Development & Technical Discussion / Re: [PATCH] implement 'listtransactions' on: September 01, 2010, 06:33:54 PM
  • Slight change so that JSON-RPC returns 200 instead of a 500 error with invalid methods/params.
  • Slight change so that JSON-RPC binds to all/any IPs instead of just the loopback.
RE: JSON-RPC error / HTTP status codes:  I'm about to submit a patch to Satoshi so bitcoin better follows the JSON standards.  I'll create a new thread describing the changes.

RE: binding to any/all IPs:  DANGER! Make sure you have good firewall rules for port 8332 or you are likely to find yourself with an empty wallet!  Bitcoin is using HTTP BASIC authentication, so anybody who can eavesdrop on the connection between your JSON-RPC client and the bitcoin server can see the password (it is NOT encrypted).
2076  Bitcoin / Wallet software / 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.
2077  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.
2078  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.

2079  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).
2080  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...
Pages: « 1 ... 54 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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!