Search content
Sort by

Showing 16 of 16 results by QuinnHarris
Post
Topic
Board Bitcoin Discussion
Re: Why do people fear regulation so much?
by
QuinnHarris
on 26/02/2014, 23:45:47 UTC
It depends what you mean by regulation.  Most likely you mean the modern government variety.  So as related to an exchange it would mean some set of rules some bureaucrats devise to attempt to solve past problems.  What do you think the chance the bureaucrat will consider tools so customers can personally validate their holdings or mechanisms for multiple parties to check each other in real time.  All technically possible.  Or better yet distributed exchanges.  Instead they will use the limited technology they know and government force to impose a less efficient and effective set of rules that can't be easily avoided by those who develop better methods.  It will also create the pretense the problem has been solved reducing the motivation and profit for providing superior solutions.  It might seem to help in the short term but the long term results will be a system in the general sense in less well regulated.

It also creates an incentive for regulatory capture where powerful parties supposedly regulated by government have an incentive to collude with the regulators to have regulations or laws changed to favor them over less powerful competition or even new entrants.  This essential gives private organization indirect access to government force.
Post
Topic
Board Bitcoin Discussion
Re: Reasons a business should accept bitcoin
by
QuinnHarris
on 05/12/2013, 17:04:44 UTC
From a merchant perspective bitcoin should be better than credit cards.  Lower fees and services like bitpay take 1 day to give you dollars vs the 2-5 days for credit cards.  And no charge backs.

Most businesses couldn't get away with just accepting bitcoin today but having that option won't hurt.

Fundamentally bitcoin can be more secure than credit cards.  Unlike credit cards, sending someone bitcoins in no way allows them to take more of your bitcoin than you authorize.  You don't have to worry about merchants securing their systems, only securing your own.

The customer is the one who might find bitcoin worse than credit cards today.  Notably there are no charge backs so you have to trust the merchant.  This can be fixed using 2-3 signature transactions with an escrow service but the software to easily use this isn't available though the network supports it.  Today there are no established organization that provide this escrow service.

From a fundamental design standpoint bitcoin has the existing payment methods like credit cards beat but some of the software and organizations to make it work well have not yet been developed.
Post
Topic
Board Development & Technical Discussion
Re: Why doesn't Bitcoin use a tiebreaking rulewhen comparing chains of equal length?
by
QuinnHarris
on 04/12/2013, 17:39:52 UTC
The assumption that the selfish miner could propagate their block faster than the rest of the network is a bit contrived.

But, if a deterministic block choice is used that allows the selfish miner to determine if their block is more likely to be chosen over the yet unknown competing block the situation becomes less contrived.

That said, I think this problem can be fixed or at least mitigated by choosing a block choice algorithm that doesn't allow the selfish miner to predict if their block will win.

I had suggested the following approach taking into account the current difficulty on the dev mailing list.

Assuming
a = hash of block A
b = hash of block B
difficulty = current difficulty such that A < difficulty and b < difficulty

Code:
uint256 choose_block(uint256 a, uint256 b, uint256 difficulty)
{
  bool choice = false; // false for lower hash, true for greater hash
  uint256 am = (a + d/4) % difficulty;
  uint256 bm = (b + d/4) % difficulty
  if (a + d/4 >= d)
    choice = b > a || b < am || bm > a || bm < am;
  else
    choice = (b > a && b < am) || (bm > a && bm < am);
  return choice ? (a > b ? a : b) : (a > b ? b : a);
}

Given any hash a you can't know if any other hash value b is more or less likely to be chosen.  There are many other methods like an exclusive or between 1 bit on the hash of the hash value.


I strongly expect if a deterministic block choice is used, this approach is better than just choosing the block with the lowest POW hash value or the chain with the lower POW sum.

That said, I don't think the selfish miner problem is big enough to warrant significant concern and I am not certain any change won't have other problems like the ability for a powerful adversary to cause the network to imprudently reject good blocks.
Post
Topic
Board Development & Technical Discussion
Re: Why doesn't Bitcoin use a tiebreaking rulewhen comparing chains of equal length?
by
QuinnHarris
on 04/12/2013, 01:08:00 UTC
There really isn't a reasonable notion of more work done on one block.  A lower proof of work hash value doesn't mean the miner worked harder, it just happened to land on that value.  All output values have an equal probability, but the greater the network difficulty the fewer hash outputs will be accepted.  Under a vast majority of cases each block in equal length chains will be expected to have the same difficulty.

Some have suggested broadcasting lower POW block headers when found, something like 1/64th the current difficulty.  If miners switched to the chain with the most POW headers it should quickly move the network to one chain.

Any scheme that allows a malicious miner who withholds blocks to determine if their chain will be chosen over another can game the network in a way similar to what is described by this recent paper http://arxiv.org/pdf/1311.0243v1.pdf

I think deterministic block choices makes this type of attack even more problematic as it removes the need for the malicious miner to propagate their block faster than the competing block.

But I am not absolutely certain about this.  Need to think this through more.  This is can be tricky to figure out, any scheme you think of to fix one problem seems to cause another.
Post
Topic
Board Development & Technical Discussion
Re: Reducing the need for cold storage through self-blacklisting
by
QuinnHarris
on 03/12/2013, 23:50:31 UTC
I am going to restate what I think you want as an addition to transaction scripts.

This is a transaction output (scriptPubKey) that can be spent (used by a transaction input) in one of two ways with different keys for each way.  One key could be used in an input (scriptSig) immediately as we normally expect, this key would be held in cold storage.  The other key would require a special transaction be committed to the blockchain some number of blocks ago before it would be accepted (unblock transaction).  This special earlier transaction could be signed by the same key used in the later transaction.  In this case blacklisting is just a particular transaction output (scriptPubKey).

This could be done by adding an script op that would check for the special transaction already committed to the blockchain, or possibly require a certain special input in the spending transaction.  Both are predicated on information outside scriptSig and scriptPubKey unlike all existing ops.

The waiting period is not an insignificant impediment.  Other parties would have to wait the full unblacklist time before they could trust anything you send them.

I think this is plausible but I question if this is better than alternative options to protect against theft.

For this to be effective some system must be online monitoring the unblacklist transaction.  This system should differentiate between good and bad unblacklisting.  If the attacker compromised the private keys could they compromise the monitoring system?  If its a 3rd party service you still have to communicate the good unblacklisting likely requiring some authentication that could be compromised with the key.  Anything like passwords protecting access to the monitoring system could also just be used to protect the keys.

If the monitoring system doesn't differentiate between good and bad and notifies you about everything, wouldn't it be better to queue up the pending transactions and approve all the transactions periodically on some secure system like a trezor, offline computer or a 3rd party service.
Post
Topic
Board Development & Technical Discussion
Re: Proposal: New RPC interface for bitcoind
by
QuinnHarris
on 17/07/2013, 17:18:58 UTC
Is there agreement that ideally a bitcoin daemon handing the public block chain and a bitcoin GUI should have a complete and well defined interface between them that could work over a network and allow different daemon and client implementations to work together?

Is it worthwhile to separate the daemon and GUI part of bitcoin-qt so the daemon operates in one process and the GUI in another and communicate over a well defined interface?  In this case the daemon would not handle private keys in any way, but the GUI would use the interface to observer transactions for specific public keys.

I am especially interested in this because I have recently implemented accepting bitcoins on my website and found the current JSON-RPC interface lacking.  Notably I do not want to store private keys on my web server yet I saw no way to use bitcoind to observe the relevant transactions when they came in short of implementing the bitcoin protocol.  I think a good solution to this problem would be a library with bindings for many languages that connects to bitcoind providing an interface where I can supply a public key and chain code for HD wallets and it will provide new keys in the chain and notification when transactions show up matching these keys.  This library/interface could provide all functionality needed by a bitcoin GUI.  This should significantly reduce the programming effort to implement new software using bitcoin which I think is essential for wide spread adoption for ecommerce in a decentralized way.

I realize BitPay and other services make this process easier which is great but we have an opportunity to make handling bitcoins much easier without relying on a central service.

While I realize this is a significant undertaking I would consider this an important feature.  Is anyone else working on this?  Is there a better approach or a reason this is a bad idea?  Are there other clearly more important features?

I noticed an email on the bitcoin mailing list on 5/16 titled "Modularizing Bitcoin" that seems to suggest something along this lines.
Post
Topic
Board Development & Technical Discussion
Topic OP
Proposal: New RPC interface for bitcoind
by
QuinnHarris
on 15/06/2013, 20:26:21 UTC
This is the beginning of a proposal for a new RPC interface for bitcoind to query and receive notifications about the daemon status, block chain or specific transactions.  This is incomplete but I am seeking comments if this is a good idea and worth the effort to implement.

This is intended to address the following issues
  • Allow separating the bitcoin-qt GUI and wallet code from the daemon code
     
    • Allows multiple instances of a modified bitcoin-qt with wallet code (and other clients) to interact with one instance of the daemon.  This is useful for multiple users on the same system or to allow a small set of daemons to be used by other computers on a trusted network.  This also makes it easier for users to run the daemon all the time while running the GUI on demand.
    • Removes all private keys from the daemon process space.  This implementation would allow only having interested public keys (addresses) in the address space of the daemon for a short period of time for the extra paranoid.
  • Provide a robust mechanism to receive updates for anything relevant including new blocks and transactions.
  • Allow receiving all updates relevant to a specific wallet very quickly assuming the bitcoind is trusted by the connecting client.

The current JSON-RPC interface does not provide a mechanism for real time updates or to request specific transactions matching some criteria notably spendable by a certain keys or having a specific scriptPubKey. This proposal is primarily a description of messages between the client and server where the server is bitcoind.  Google protocol buffers will be used here though it would be possible to provide similar functionality with JSON, XML or some other format.  This proposal does not define the exact mechanism for sending these messages. Accordingly it can be integrated as new calls to the existing interface though this proposal does overlap with some of the existing RPC functions and has distinctly different conventions.

This interface allows a client to create, query and get notifications for a context containing a list of public keys, scriptPubKeys or transactions ids the client is interested in.  A context is identified by an arbitrary byte string (should it be fixed or limited length) context identifier that could be derived from the keys in the context.  This allows multiple clients to share the same context.

A single Context message can represent the full state of a context.  A notification Context message contains a subset of a full Context message containing all new data.  The message is structured so all changes can be represented by either updating a fixed field or adding a new message to a repeated field.  An object is removed from a repeated field by adding it to another repeated field that is mutually exclusive from the original.  The same message is also used to specify which aspects of the context the client will need notifications for.  This enables a client to request just the required information for example allowing a client to receive an account balance without receiving the specific transactions.

In addition to client defined contexts each bitcoind will have single Global context containing connected peers, general block chain information or anything else not predicated on something specified by the client.

Code:
service Bitcoin {
  // AddtoContext either creates or updates a context specified by past Context messages.
  // The Context message sent can only contain fields labelled Load below.
  rpc AddtoContext(Context) returns Context;

  // Returns a Context message containing all data needed to restore the context without scanning the block chain
  rpc DumpContext(context_id) returns Context;

  // Remove all data associated with a context from memory.
  rpc RemoveContext(context_id);

  // SetContext specified what fields the client would like notifications for.  Every field that is included in the passed Notification message will be set to receive notifications.  This replaces the current notification set each time called.
  rpc SetNotify(Notification);

  // Get the complete context data filtered by SetNotify, commonly called before GetNotifications
  rpc GetContext(context_id) returns Context;

  // One mechanism to receive notifications.  Each call would return a Notification message containing all data that has changed since the last call.
  rpc GetNotifications() returns Notification;
}


message Notification {
  optional Global global;
  repeated Context contexts;
}

message Global {
  optional PeerInfo peers;
  optional BlockChain chain;
}

message Context {
  required bytes context_id;

  repeated PublicKey keys;
  repeated PublicKey keys_delete;
  repeated scriptPublicKey scripts;
  repeated scriptPublicKey scripts_delete;
  repeated Transaction transactions;
  repeated Transaction transactions_delete;
  // Add more repeated fields for additional transaction criteria

  // For setting notifications (SetNotify) the deleted fields are not valid and each item can only be specified once making it equivalent to optional instead of repeated in that case.
}

message PublicKey {
  // All PublicKey messages must contain either a public_key or i if the message is a child of another PublicKey message.
  optional bytes public_key;        // Load, not required if included as child in other PublicKey message
  optional bytes chain_code;      // Load, Specified for BIP 32 addresses

  optional int32 i;                        // Load, Specified for BIP 32 addresses

  optional int32 i_look_ahead;    // Load, Specified for BIP 32 addresses

  repeated PublicKey children;    // Load, Only used for BIP 32 addresses, this field is not accepted to set notifications.

  repeated Transaction tx_received;
  repeated Transaction tx_sent;

  repeated Transaction tx_received_defunct;
  repeated Transaction tx_sent_defunct;
  // Defunct list is mutually exclusive with regular list of transactions.  If a transaction is made invalid (e.g. double spend) a notification will be sent with that transaction in the defunct list to signify it has been removed from the regular list.

  // Contains total balance from all transactions including child transactions
  optional int64 balance;
  optional int64 received;

  optional int32 confirmations;  // Minimum confirmations of all transactions including children

  optional int32 scan_progress;
}

message scriptPublicKey {
  optional bytes script;
  optional bytes script_hash;

  repeated Transaction tx_received;
  repeated Transaction tx_sent;

  repeated Transaction tx_received_defunct;
  repeated Transaction tx_sent_defunct;
  // Defunct list is mutually exclusive with regular list of transactions.  If a transaction is made invalid (e.g. double spend) a notification will be sent with that transaction in the defunct list to signify it has been removed from the regular list.

  // Contains total balance from all transactions including child transactions
  optional int64 balance;
  optional int64 received;

  optional int32 confirmations;  // Minimum confirmations of all transactions including children

  optional int32 scan_progress;
}


message Transaction {
  optional bytes raw_transaction;

  // Identify transaction
  optional bytes txid;                // Load, used to allow daemon to quickly find relevant transactions when loading context
  optional bytes block_hash;    // Load
  optional int32 transaction_no;  // Load, Transaction location in block

  optional int32 confirmations;

  optional int64 amount;
  optional int64 fee;
}

message BlockChain {
  optional uint32 height_from_peers;  // Best block height based on response from peers
  optional uint32 backtrack; // Used to fetch a specified number of blocks from the main chain to the current best block
  repeated Block main_chain;
  repeated Block orphaned;
  // main_chain and orphaned is mutually exclusive so adding the same block to one implies it is not included in the other
}

message Block {
  optional bytes raw_block;
  optional uint32 height
  optional byte hash;
  optional byte previous;
  optional byte root;

  // More block info
}

message PeerInfo {
  optional int32 count;
  Peer {
    optional bytes address;
    optional int32  services;
    optional int64 lastsend;
    optional int64 lastrecv;
    optional int64 conntime;
    optional int32 version;
    optional string subver;
    optional bool inbound;
    optional int64 releasetime;
    optional int32 startingheight;
    optional int32 banscore;
  }
  repeated Peer peers;
}


Examples

Setup context for a set of keys to match a current wallet implementation

Send the follow message to AddToContext RPC.
Code:
Context: {
  context_id: Unique id for wallet possibly first key in pool
  keys: [{
    public_key: Public key matching wallet private key
  }] // Repeat for each key in the wallet
}

Setup server to send notifications to the client by sending the following message to the NotifyContext RPC.
The presence of any value in a field signifies a notification is desired.
Code:
Notification {
  global: {
    peers: {
      count: 1  // Receive notification anytime the number of peers changes
    }
    chain: {
      height_from_peers: 1  // Receive notification of the expected newest block high in the chain
      main_chain: {
        height: 1  // Receive notification of the newest block height after that new block is accepted
      }
    }
  }
  contexts: [{
    context_id: same context from AddToContext
    keys: [
    {
      public_key: 1  // Include public key so the notification can be identified
      tx_in: {
        raw_transaction: 1  // Send full transaction when its output matches the public_key
        // Could receive notification for other fields describing the transaction.
      }
      tx_out: {
        raw_transaction: 1  // Send full transaction when its input matches the public_key
      }
    }]
}

Typical notification message would look like
Code:
Notification {
  global: {
    peers: {
      count: 16 // Number of peers changed
    }
  }
  contexts: [{
    context_id: same context from AddToContext
    keys: [
    {
      public_key:
      tx_in: [{
        raw_transaction: raw transaction data
      }]
      tx_out: [{
        raw_transaction: raw transaction data
      }]
    }]
  }]
}


Notifications on new best blocks, similar functionality to -blocknotify

Set the following notifications with SetNotify
Code:
Notification {
  global: {
    blocks: {
      main_chain: {
        hash: 1     
      }
    }
  }
}

Notifications will be sent like below for each new best block
Code:
Notification {
  global {
    blocks: {
      main_chain: {
        hash: Best block hash
      }
    }
  }
}


Ecommerce site using Hierarchical Deterministic Wallets without any private keys.  Only needs to know when coins are sent to specific accounts and how many confirmations.

Send the follow message to AddToContext RPC.
Code:
Context: {
  context_id: Unique id for wallet possibly first key in pool
  keys: [{
    public_key: master node key
    chain_code: chain code
    children: [{
      i: 0  // Look at the 0 chain
      i_look_ahead: 0 // Don't look for any other keys at this level
      children: [{
        i: 0  // External Chain by BIP 32
        children: [{
          i: 0
          i_look_ahead: 2
        }]
      }, {
        i: 1  // Internal Chain by BIP 32
      children: [{
          i: 0
          i_look_ahead: 2
        }]
      }]
    }]
  }] // Repeat for each key in the wallet
}
The 0 chain key could have been used in place of the master node key instead of deriving it from the master node key

Set notifications with SetNotify
Code:
Notification {
  contexts: [{
    context_id: same context from AddToContext
    keys: {
      i: 1

      // We are only interested in the amount received for each key, not the full transactions
      received: 1
      confirmations: 1
    }
  }]
}

Typical notification message would look like
Code:
Notification {
  contexts: [{
    context_id: same context from AddToContext
    keys: [
    {
      children: [{
        i: 0  // Internal chain
        received: 100000000  // One bitcoin received.
        confirmations: 0  // New notification will be sent each time confirmations changes
        children: [{
          i: 0 // Transaction on first address on Internal chain
          received: 100000000  // One bitcoin received.
          confirmations: 0
        }]
      }]
    }]
}



bitcoin library
I think it would be advantageous to develop a bitcoin library that uses an interface to the daemon like this in addition to providing tools to manage the private keys either through a local file store or another RPC interface to a private key daemon (TPM secured process, specialized hardware).  Ideally this library would be the preferred interface to bitcoin.


0mq

This could be implemented over 0mq.  It isn't evident to me if there are real world use cases to broadcast (PUB-SUB) notifications for specific contexts (small number of specific transactions).  I see there is a 0mq pull request that publishes blocks, transactions and new host notifications and uses REQ-REP to provide access to the JSON-RPC.  An ideal 0mq implementation would probably be capable of sending the same context notification messages to multiple hosts but would this ever be needed?

My current inclination is to implement this with 0mq and google protocol buffers.  The result would be harder to understand on the wire than something like JSON-RPC but would be a little easier to implement and run faster.  I would expect such an implementation would scale to anything needed.  That said, authentication and encryption would be more important than just about anything offered by 0mq alone and will be a easier with an openssl secured TCP socket just like the current JSON-RPC.
Post
Topic
Board Bitcoin Technical Support
Re: monitor all transactions
by
QuinnHarris
on 01/06/2013, 20:10:33 UTC
You can use getrawmempool to get a list of all the transactions in the memory pool which should be everything the node knows about that is not in a block in the current chain.  getrawtransaction will then give you the unparsed transaction data.

If you want to process all new transactions immediately you will probably need something that connects as a peer into the network (a node you trust) to get broadcasted transactions and new blocks.  Clients like Armory do this now.  There might already be some code around to do this depending on the language you are using.

I think bitcoind needs an interface to request transactions and notifications of specified addresses or with specific outputs.  Do you actually need every transaction or just all transactions associated with some set of addresses?
Post
Topic
Board Development & Technical Discussion
Re: Please do not change MAX_BLOCK_SIZE
by
QuinnHarris
on 01/06/2013, 18:55:35 UTC
I expect at this time bandwidth is the major bottle neck.  At least in the US I think we can expect someone wishing to run a full node to have at least 1Mbps of bandwidth.

All transactions will be first broadcast then transmitted again in a block.  There is also overhead for the inventory notify messages.  I will guess that protocol overhead, inventory and addresses take up about as much bandwidth as transactions so needed inbound bandwidth is about 3x what is needed to just transmit the blocks.  Slow connections would naturally limit outbound traffic as nodes would fetch inventory from other hosts that advertise that inventory sooner.  That said it might be worth improving the client to take into account connection speed between nodes.

1Mbps of bandwidth is 75MB per 10 minutes.  I would expect someone would want bandwidth for other things so lets assume 30MB available.  This means someone with 1Mbps of bandwidth should be able to handle up to about 10MB blocks.

Given this I wouldn't expect raising the limit to 10MB would have a significant centralizing effect but significantly higher would.  This doesn't account for tor.

Bitcoin does have the potential to grow significantly faster than network and computer speed increases so transaction growth to a point where block size would become prohibitive is a real future possibility.  I expect we have a little time before this becomes an a significant issue but its clearly best to have a solution prepared before its absolutely necessary.

Could we get decent statistics on the bandwidth of internet connections through the world and basically set the block size to ensure something like 95% of the fixed internet connections would be able to run a full node?  Lots of fudge factors in this calculation but its still less arbitrary than 1MB.

As soon as the block limit is hit it will raise transaction fees and there will be a significant need to justify the limit.  The more objective and reasonable the way that limit is set the better.
Post
Topic
Board Marketplace
Topic OP
Custom Printed Promotional Products/Ad Specialities for Bitcoins
by
QuinnHarris
on 01/06/2013, 02:12:57 UTC
Now you can buy custom printed promotional products with Bitcoins at http://www.mountainofpromos.com/

Over 16,000 products listed on the site that can be either printed, debossed, embroidered or engraved including:
* Bags (Tote Bags, Backpacks, Computer Bags, etc..)
* Drinkware Items (Plastic, & Metal Bottles, Mugs, Coasters)
* Journals, Jotters, Portfolios and Writing Pads
* Computer Accessories (USB Drives, Cases, Hubs)
* Tools (Bottle Openers, Flashlights, Lighters, Tape Measures ...)
* Food Items (Chocolates, Gum, Mints ...)
* Pens

Most products are also available without an imprint.
Post
Topic
Board Beginners & Help
Re: Whitelist Requests (Want out of here?)
by
QuinnHarris
on 16/05/2013, 18:07:01 UTC
Requesting full form access as I believe I have met the requirements of 5 posts and at least 4 hours online.

Thanks
Post
Topic
Board Beginners & Help
Re: Economists think they know it all
by
QuinnHarris
on 16/05/2013, 18:04:44 UTC
The very problem of deflation he speaks to is only a problem if the deflation isn't predictable.  If a currency deflates at a few percent per year as I would expect bitcoin would if it had wide spread use, the interest rates charged would be adjusted accordingly just as they are with persistent inflation.

The deflationary spirals is largely the symptom of excessive debt creation and the deflation is caused by that debt not being paid (default) which basically reduces the money supply in a fractional reserve system.  When the federal reserve prints money to buy mortgage backed securities to prevent this deflation it does address the symptom, but it doesn't change the fact those debt instruments never properly reflected the underlying economic reality.  This causes a distortion in markets where the asset prices (morgage backed securities, US treasuring etc) appears to reflect greater future production than will actually be available.  Let alone the huge moral hazard caused by telling well colluded banks that if they make bad investments they won't have to suffer the losses.

We will see a lot more stuff like this.  But in the end real world results are what matter.  I hope if we push forward developing BitCoin and successive and related technologies in time the empirical reality will overwhelm this Keynesian non sense.  Keynesianism is better understood as an excuse for government spending and monetary manipulation for those that pay the salaries of those economists than a useful model to understand economic reality.
Post
Topic
Board Beginners & Help
Re: Bitcoin as a savings account
by
QuinnHarris
on 15/05/2013, 00:03:59 UTC
Is it possible to setup a special needs trust where assets are placed in a trust possibly managed by you that can be used for specific medical reasons but won't be considered for Medicaid.
http://en.wikipedia.org/wiki/Supplemental_needs_trust

A printed wallet can work.  I personally wouldn't find it to be significantly more secure or reliable than a flash drive.  Personally if I was paranoid I would use both.

Bitcoins at this point is a risky investment and I wouldn't suggest buying more bitcoins than you can afford to loose.  I expect it will either be a very good savings method or go to zero with little in between.
Post
Topic
Board Beginners & Help
Re: how to program bitcoin wallet or exchange progm
by
QuinnHarris
on 14/05/2013, 15:25:53 UTC
If you intend to be a serious programmer I would suggest learning a few languages so you know about various methods of programming and solving problems.  This would be my list
C - Low level requiring greater understanding of the computer architecture.  For most part C will give all the power of assembly without as much work.  Easy to understand how C code translates to assembly.  C++ adds a bunch of features but most features over C can be found in other languages.  The most common Satoshi client is programmed in C++
Ruby - Good way to learn object oriented programming dynamic typing and closures (aka blocks).  Generally useful language to.  Typical use of this language covers more conceptual ground than Python, Perl, PHP.  I would suggest to learn a little LISP
Haskel or Ocaml - Functional programming languages with pattern matching functionality not seen in above languages.  These languages aren't that commonly used but do have some unique features worth some time to be familiar with.  I am personally weakest on these languages

If you learn these you would be hard pressed to find another programming language with a feature you haven't seen before.

SQL isn't a full programming language but good to know especially for writing web applications or most business programs.  Relational algebra/calculus is good to know for any serious programming.

Javascript is becoming more popular and needed to write alot of web stuff.  As just a language I think its preferable to PHP but not Ruby.

C# and Java have a lot in common and if you know C++ well there will be little new in those languages.  Popular for modern business applications.

Post
Topic
Board Beginners & Help
Topic OP
Thoughts on double spend notification
by
QuinnHarris
on 12/05/2013, 22:25:22 UTC
As I understand it, current implementation is susceptible to a relatively low cost 0-confirmation double spend attack.  Notably this attack is as simple as running two bitcoind instances with the same wallet data connected to different hosts.  The json-rpc interface could then be used to do a simultaneous spend of the same address from the two instances.  If the receiver doesn't see the transaction you want them to see just redo from a different address but switch which daemon is sending the "legitimate" transaction.  This its a very viable attach requiring relatively limited technical knowledge that could be further reduced if someone released a version of the daemon for just this purpose.  If you are able to determine and connect directly to the host of the receiver this attack can be made to work with a high degree of success otherwise it has about a 50% (based on what transaction the successful miner receives) chance of working each time attempted.

If a proper double spend notification feature is implemented, this attack becomes much more expensive.  Notably it would require collusion with powerful miners to be viable.  It seems to me such a feature is worthwhile even though it will not eliminate the need to wait for confirmations under all circumstances.

These are the counter arguments I have seen in the forms
* Miners self interest will be to include the transaction with the highest fee.
I expect even today most hosts in the bitcoin network are not miners and they have no interest in breaking the current policy of dropping the second transaction of a double spend.  This means that if two double spend transactions are sent simultaneously, double spend notification would quickly notify the receiving party or if the two transactions are sent with a significant delay (10s) most miners will never see the second transaction.  A proper double spend notification should not transmit the full second transaction as it would exacerbate the double spend problem.  But if the double spend notification contains the simplified hash of the transaction (not the full transaction) used in the signature verification and the input script (scriptSig) this would provide proof there was a double spend without the full transaction.  Requiring proof of a double spend should ensure a double spend would have no more burden on the network than any other single transaction.

* Adversaries could collude with miners (or be miners) to include the "illegitimate" transaction
This is possible but much more difficult than double spending is now.  The second transaction can not be quickly submitted on the normal bitcoin network as it would produce a double spend notification.  But it only takes one good guy in the nefarious mining pool to forward the second transaction.  The larger the pool the more likely you will have a good guy.  The smaller the less likely that pool will mine the next block.  Most people will do the right thing if it doesn't cost much.  If it never becomes viable to get away with double spends, miners won't bother to change the implementation to take advantage of it.  Making double spends harder now could stop nefarious software, miners and social networks from forming or at least slow their progress.

* This doesn't address the Finney attach.
True, but the Finney attack is significantly more expensive than a simple double spend is today.  I would consider a Finney attach to be a particular form of colluding with miners.  This attack can be significantly mitigated if the receiving end specified the time the transaction should be submitted.  I am hard pressed to think of a real world transaction that is sizeable enough to make a Finney attack worthwhile yet you can't either wait for a few confirmations or just specify within a few minutes when the transaction should be sent.  On the other hand, for small transactions like purchases at most stores, it can be cost effective to do a double spend today but not worthwhile to do a Finney attack.

* You can detect double spends with services like blockchain.info
The point of bitcoin is to be distributed and decentralized and if double spend notification is widely adopted it would have better coverage than any central service.

* The only proper solution to 0-conf spends is to add some trusted 3rd party
Yep.  A trusted 3rd party absolutely can make 0-conf spends more trustworthy and I hope we see organizations established to do this especially related to escrowing online purchases.  This doesn't eliminate the value of a 3rd party but does provide a significant improvement if one chooses to not use a centralized 3rd party as most bitcoin transactions are done today.

Double spend notification isn't a perfect solution to 0-conf transactions but I expect does provide sufficient additional integrity to be worth implementing.  Is this not implemented because of some issue I am missing or because nobody has bothered to do the work?
Post
Topic
Board Beginners & Help
Topic OP
Separate Bitcoin-qt/bitcoind into public daemon, wallet code and GUI
by
QuinnHarris
on 12/05/2013, 21:09:50 UTC
It would seem prudent to restructure the Bitcoin-QT/bitcoind implementation to have the following distinct components.

* A daemon much like the current bitcoind daemon but without any wallet code.  Notably everything in the process address space will be public information.
* Wallet code library and possibly daemon implementation.
* The GUI using the wallet library that connects to the daemon and launches it if needed.

Doing this has the following advantages
* Removing all wallet code and data from the core daemon that processes messages and tracks the block chain decreases the chance wallet data (private keys) will be compromised as the result of an exploit in any of the daemons other code.  OS file system security could be used to ensure the bitcoin message/blockchain daemon couldn't access any wallet files.
* The current implementation where the daemon and GUI run in the same process is not very conducive to multi user systems.  Notably each user that runs Bitcoin-Qt ends up with there own copy of the blockchain and I expect by default you can't run two copies of bitcoin-QT as different users on the same system at the same time (port conflict).  If the daemon was always in a different process (with very restrictive permissions) that the GUI connects to, it wouldn't be an issue to have many instances of the GUI running for many different users.  Each GUI instance would run as the appropriate user and only have access to the appropriate wallet files.
* The same multiuser ability can be extended to trusted networks so each computer doesn't need to run the full daemon just the GUI that connects to the daemon on a "server".
* The daemon can be run all the time and still appear to function as it does now.  This could be an installation option.
* Ensuring the interface between the daemon and GUI is clean and well documented will allow for more innovation in the GUI and daemon by allowing different implementations to interact with each other.  You shouldn't have to mess with or recompile the daemon to change the GUI.  Ideally this interface is standardized so completely different GUI and daemon implementations could be compatible with each other.

Let me know if this idea has already been discussed but I missed it or if there is some reason other that the work involved that its not done this way now.