Bitcoin Forum
December 12, 2024, 04:31:56 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Questions about Transaction Protocol Rules  (Read 1081 times)
bitcoinandroid (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
October 05, 2011, 06:29:19 AM
 #1

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!
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5404
Merit: 13498


View Profile
October 05, 2011, 06:50:36 AM
 #2

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?

This is the case. If you fail to apply the restriction, you'll end up on a separate network.

Quote
generally seeing if all the fields can be parsed without an error?

Yes.

Quote
I haven't seen any other formal discussion around what a valid range is for an amount.

0-21 million. 0 is valid.

The precision is part of "syntactic correctness".

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
bitcoinandroid (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
October 05, 2011, 07:00:42 AM
Last edit: October 06, 2011, 07:11:15 AM by bitcoinandroid
 #3

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!
bitcoinandroid (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
October 06, 2011, 07:08:47 AM
 #4

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!
log0s
Newbie
*
Offline Offline

Activity: 43
Merit: 0


View Profile
October 06, 2011, 05:35:48 PM
 #5

> 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?

There is no network enforced minimum fee (though it must not be negative).  Individual miners can choose their own minimum fees, however.


Also, is COINBASE_MATURITY still = 100 ?

Yes, the network enforced value is 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!

A lot of the values you asked about will likely not be changed for a while, if ever, as most of them would be changes that fork the blockchain (something the main bitcoin developers go to great lengths to avoid).  I think the best places to find this information is probably the wiki and the source code, otherwise just asking people in the forum or in irc.
bitcoinandroid (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
October 16, 2011, 01:30:51 AM
 #6

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.
bitcoinandroid (OP)
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
October 16, 2011, 01:43:46 AM
 #7

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.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4284
Merit: 8816



View Profile WWW
October 16, 2011, 06:53:32 PM
 #8

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.

The anti-DOS rule is:

A 0.0005 fee is required if any output is smaller than 0.01 (not the sum of the inputs)  or if the priority is less than 51,000,000.
You calculate the priority as sum(input value * confirmations)/tx_data_size

If your change would be smaller than the fee 0.0005 the wallet is smart enough to give it up as fee to avoid the 0.0005 fee— but it's not generally smart enough to always pick the mixture of inputs required to avoid a fee and could be improved.  What it currently does is tries to find the smallest set of inputs that sum to at least your transaction value, first using only input txn which have 6+ confirms, then 1+ confirms (and your own zero confirm txn), then using unconfirmed inputs.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!