Oh wow - just found this and have been reading through it:

https://en.bitcoin.it/wiki/Satoshi_Client_Block_Exchange

It describes exactly what I was wondering.

Interesting...is the "tips" of the chains part documented?

From reading this that doesn't appear to be the case:
https://en.bitcoin.it/wiki/Protocol_specification#getblocks

It looks like it gives you the 10 most recent hashes and then starts skipping in greater and greater intervals back to the genesis.  It gives a pseudo code implementation there.

Hi, I'm working on coding up a prototype client to better understand bitcoin.

I understand the first steps as:
1. send initial "getblocks" (I only have the genesis block preloaded to start)
2. peer sends me "inv" with 500 blocks
3. I call "getdata" on each

I know I need to call getblocks again, but does it make sense to queue up another "getblocks" again after every "inv"?  My implementation for inv handling is generalized so it's not just for the initial blockchain download, so I wasn't sure if this was the best route.

Ok great, thanks for the feedback guys!

Thanks theymos!  I thought that might be it.

As a follow up, on https://en.bitcoin.it/wiki/Transactions#Generation it says:

"The data in "coinbase" can be anything; it isn't used"  So why the check for between 2 and 100 characters?  Is this just to prevent too much data from being stuffed in there?  Just trying to understand the reason behind it.

Also, this block looks like it has a really long coinbase field (130 characters).  How was it allowed?
http://blockexplorer.com/rawblock/00000000000009e6e9b08e2ced87f48e08654d03bbd0027ef0f5d1da803522a3

Thanks I really appreciate the help!

On the protocol rules here https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages

it states: "8. For the coinbase (first) transaction, scriptSig length must be 2-100"

But it looks like the coinbase transaction doesn't have any scriptSig param at all, for example:
http://blockexplorer.com/rawblock/000000000000073ab0ea030440998db75d5c74393c6a0875a37fc4f00f1539e8

What am I missing?

Thanks!

I'm requesting a whitelist for username brian_armstrong

He is a developer working bitcoin related projects, and I can vouch for him.  Thanks!

Hi,

I'm the developer of the bitcoin android project: https://github.com/barmstrong/bitcoin-android

I'm coding up a new bitcoin related project, and I was just curious if there are any other developers around San Francisco, CA especially any with bitcoin or Ruby experience.

If so I'd be interested in chatting more.  Please only other developers at this point - looking for technical folks.

I can be reached at bitcoinandroid at Google's web based email system dot com. (Gmail)

If you can send me a few lines about your background and or experience, I'll send you some more details about the project and see if a follow up call or meetup makes sense.  Thanks!

Thanks genjix!  That was what I was looking for.  Much appreciated.   

I have a beginner question on this rule:

"12. Check that nBits value matches the difficulty rules"
https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages

I understand how to convert the nBits to a difficulty.  But what does "match the difficulty rules" means?

I'm assuming this means check if the difficulty the block is using seems reasonable.  But do we have to calculate what the difficulty should be for any given block, and if so how?  I was trying to find some sample code for this but came up empty handed.

Google turned up this but I'm afraid I'm not really understanding what it does:
https://github.com/bitcoin/bitcoin/blob/master/src/bitcoinrpc.cpp#L203

Many thanks for a point in the right direction!

Good point - the test of "would it fork the blockchain" makes sense.  Not sure if the wiki is the right place.

This forum has been super helpful as a newer developer trying to understand the pieces better.

One more I was just thinking about: when selecting coins to create a new transaction, does it make sense to use transactions which are not yet in a block?  Gavin's naive implementation above deemphasizes these, but in a worst case I'm guessing it is still ok to include a tx not in a block because the protocol rules will prevent the double spend?

Similarly, does the official client clear out orphan transactions after some period if they haven't made it into a block?

I very much appreciate the help.  It's taking me a long time to wrap my head around it but I feel like I'm slowly getting there.

This is a big request, but I'll throw it out there anyway.

Having some sort of writeup like this: https://en.bitcoin.it/wiki/Protocol_rules
but for the process of creating a new transaction could be useful.

It seems like there are a few pitfalls to be aware of with fees, selecting coins, etc.

Great info, thanks guys!

Yep I remember the knapsack problem from back in the day.  Looks like there are some implementations here:
http://rosettacode.org/wiki/Knapsack_problem/0-1

Gavin, your naive implementation seems like a great start.  I was a little confused why you used num confirmations * amount as the priority, but after reading this (technical info at the bottom) it makes more sense: https://en.bitcoin.it/wiki/Transaction_fees

And yes, at this point I'm optimizing for ease of implementation.

I'm slowly understanding more of it, thanks guys!

Hi,

I am trying to understand the SelectCoins function (at least at a high level):
https://github.com/bitcoin/bitcoin/blob/master/src/wallet.cpp#L746

It looks like it has a bunch of optimizations, but I'm wondering if something simple like this would work as a naive implementation:

1. find all tx outputs that meet the following conditions
 - sent to me (have a hash160 belonging to a key in my wallet)
 - have not been spent yet
 - are in a confirmed block
2. sort the outputs smallest to largest amount
3. for each output
  - create an input that references it and add to current_amount
  - break if current_amount > amount i want to send
4. create one output (change) sending the difference back to me at a new address

Does something like this make sense or am I missing any pieces?  Also, does it make sense to use the smallest coins first to prevent fragmentation or is there a better way?

Thanks!  Haven't seen a good writeup on this elsewhere, but if I missed it feel free to link me to it.

Also, something I was a little confused about.  When receiving a broadcasted transaction, you don't actually know which part is change right?  So can you even tell the net amount of the transaction, or are you really just basing the threshold off the sum of the inputs?

For example
1 input with 50 coins

2 outputs, first for 0.01 second for 49.99

You don't know if the 1 cent or 49.99 goes back to the sender right?

Obviously if the transaction was being generated from within your client, then you could tell.  But for broadcasted transactions I wasn't sure how to make the rejection rule.

Thanks log0s!

So for that rule #17, I think just to prevent DOS I will make a simple rule: if the sum of inputs is < 0.01 and transaction fee is < 0.0005 then reject it.  Hopefully something like that is reasonable as a start.

Hi, I'm back with a few more!  Slowly making my way through.

> 17. Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block

Last I saw 0 transaction fees are allowed.  Is this correct as a minimum?

Also, is COINBASE_MATURITY still = 100 ?

What's the best place to find the current value of these magic numbers and get notified when they change?  I've been able to google some of them in the official client code on github, but was just curious.

Thanks for the help!

Awesome!  This is super helpful.  I really appreciate you taking the time to make some of this more clear to newer developers.

I may have a few more questions going forward as I make progress.  Thanks again!

Hi folks,

I'm currently going through the protocol rules coding up a simple example to try and better understand bitcoin.  Specifically, the transaction rules:
https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages

Apologies if some of these are simple questions - I am still somewhat new to this.

> 1. Check syntactic correctness

Is there a formal way to do this or just generally seeing if all the fields can be parsed without an error?

> 3. Size in bytes < MAX_BLOCK_SIZE

I saw in a discussion somewhere this 1,000,000 bytes?  Not sure if this is still the case.  I assume this isn't too important and just to prevent ddos attacks on smaller clients?

> 4. Each output value, as well as the total, must be in legal money range

Does this just mean can't be < 8 decimals places?  I haven't seen any other formal discussion around what a valid range is for an amount.


Thanks for your help!

Ahh, makes sense - I should have caught that.  Sorry for the newbie question and thanks for the help!