Topic: Size of raw transaction? (Read 1980 times)

DannyHamilton++

Seriously you other fools, how hard is it to say...

Try your equations with:
Q=10
Y=34
X=147 to 181 mostly 147 to 149.

I hate ppl on the internet for assuming they need to know intimate details of my sex life in order to solve for X.  If I didn't say why I needed some of these variables filled in it's likely because it's private and none of you god dam business.

Doof, impressive that you managed a response even less useful than mine.

this made me laugh , quite alot honestly. I belive i just woke up the whole house man , but that's really not an issue because its apparently 7 AM. But i'd like to tell you before i go to sleep Maxwell that you've spread joy , to my heart and hopefully somebody else's what you typed was both romantic and funny at the same time. I'd like to thank you on the behalf of my heart and other's because im sure there's other people out there that did the same thing that i did. but just dont have the courage to reach out to you and say it. I hope you appreciated my text , because my keyboard is so loud i woke up my neighbors as well now... oh well
Goodnite.

Well, you've given no information there. I'm afraid you may be mistaking the human participants on the forum for a search engine or mechanical turk. We don't generally answer questions in a vacuum.

You can insult people on the forum and provide inadequate information but that isn't likely to get your questions answers. Congrats on the self-defeat there.

You can set all the design goals you want, but no matter how many insults you hurl that isn't going to change the design of the Bitcoin system and so if it happens that what you're trying to accomplish turns out to be at odds with it, it's not going to work well, or will result in funds loss, etc.  It sounds like your understanding is currently pretty limited (e.g. not knowing how the size of a transaction works), you might want to attempt to understand the system a bit better before setting immutable design constraints and defending them with insults.  Just a thought.

I'll assume you are talking about the Bitcoin Core wallet?

All transactions have "specific outputs" when sending the transaction.  A transaction wouldn't make sense if it didn't.  Most people just let the wallet handle the transaction fee and change output for them, but if you prefer to have individual control over that, you can do so either with the coin control features (which can be turned on in the "Wallet" section of the "Preferences" menu), or with the createrawtransaction API call.  I wouldn't expect anybody to "whine, bitch, complain, argue, stomp, stamp and even tantrum that this is some how wrong/bad/undesirable/etc".


The size of the transaction can't be computed until after you've already sent it if you're using the "sendtoaddress", "sendfrom", or the "sendmany" API calls.

If you use the "createrawtransaction" then you will need to know more than the "total value of all inputs", you will need to know exactly which unspent outputs you are going to use as inputs.  Once you know that, you'll need to know if the inputs were received at compressed key addresses, or at uncompressed key addresses.  Using all of the above information, you can calculate the maximum likely transaction size as follows:

• 10 bytes of required data for every transaction
• 34 bytes for each output (including all change outputs)
• Between 179 and 181 bytes inclusive for each input that was received at an uncompressed key address (exact size can't be computed until after the transaction is signed)
• Between 147 and 149 bytes inclusive for each input that was received at an uncompressed key address (exact size can't be computed until after the transaction is signed)

It's not enough to jsut "createrawtransaction".  You won't know the exact size until you "signrawtransaction".  If you then modify the change output, the size (in bytes) of the transaction might become different by up to 2X the number of inputs when you re-sign the transaction.  As such, depending on your particular use case, it might be easiest to just always assume that the inputs will contribute their largest size (149 bytes for compressed key and 181 bytes for uncompressed key).


Unfortunately, each input must be signed, and the size of the signature isn't known until after you've actually calculated the signature.  The signature consists of two 32 byte values, but if the first byte of either of those values is greater than or equal to 0x80 then an additional 0x00 byte is prepended to the value.

Hello,
  I'm working with the raw transaction JSON interface, my question is about the application(subtract) of fee to a change address.  At the time of having a list of outputs, a selection of new outputs one being flexible(change address) in value, a total value of all inputs, and the value of the non-change outputs.  How can the size of the transaction be calculated?

One thought I had was to issue this to createrawtransaction with a bogus(1Satoshi?) value for change and compute the size from the returned hex, device by 2.  Though I was hoping for a simpler method, say each input is X bytes and each output is Y add these together with the constant header size of Q.

For my project it's *imperative to use specific outputs when sending coins.

* You may whine, bitch, complain, argue, stomp, stamp and even tantrum that this is some how wrong/bad/undesirable/ect...  Though it won't change project design goals and the problem would still remain.