Thanks for the replies, it is good to see a better version of my idea is already available.

Because it is based on the idea of being Peer-to-Peer and just like any other P2P network peers are not thinking about money when they are sharing data with each other.

For example right now Ubuntu 16.04.1 torrent has over 4000 active seeds and even more peers and they are not getting paid to share this file like millions of other files they are sharing over torrent network.

I am not an expert and I have no C++ knowledge to do that, I did this in C# and this is more of an idea open for discussion and I want to know the experts opinion on pros and possible cons of this kind of change in transaction structure.

TL;DR. Changing all Numbers to CompactSize can effectively clean up 3.5%-5.5% (up to 50 KB) of wasted block sizes and open up room for additional transactions.

Ever since I saw this irrelevant question I have been working on this theory that transactions are wasting some space the way they are.

For instance, the first field is Version which is wasting 3 bytes where it only needs 1 byte. Ever since the first transaction in 2009 version was 1 and any change will not shoot it up to 253 (the first value which needs 3 bytes in CompactSize)
The same goes for the following:

• Version: for the past 7 years version was 1
• lock_time: Almost all transactions are using 0
• index (in Outpoint): Most transactions are 0 and are less than 253
• Block version: Blocks start with 2

And the thing is that these numbers can be defined as a CompactSize Unsigned Integers freeing up those extra bytes.

I ran some statistical analysis on some random blocks between 440300 and 441300 heights and medium results are as follows:
Note: These numbers of average of about 20 random blocks.

---

Tx Count:      2,298
Average TxSize:   541 (bytes)
Clean Up Size:   46501 (bytes)
Clean Up %:   4.16%
Additional Tx that can be added after clean up:   94

---

NOTE: This is not limited to current block size but it is applicable to now and the possible future and the bigger the block size the bigger the effect of this change.
DOWNSIDE: I believe it requires a hardfork which will also be not-backforward-compatible.

p.s. I have created this topic to get some feedback on this opinion before I go ahead and increase the number of blocks I analyze. Each block is 2 MB raw data
p.p.s. I can also share the code I used for this whole Analysis and Changing.
Coded in C♯
https://github.com/Coding-Enthusiast/BitcoinBlockSizeChange

I am updating this with an example transaction which contains those CompactSize Unsigned Integers that we were talking about for someone who may be interested in a real tx example.

https://blockchain.info/tx/ef492f5dd516f51061a77bc148b8925e74557b1f31a42ca51098f26b82c23fb0?format=hex
This tx that I have found has 290 inputs (tx_in count) which is shows with 0xfd2201

Then what is your explanation for this: http://docs.electrum.org/en/latest/faq.html#what-encryption-is-used-for-wallets
I will add the link to code on GitHub if I can find it since I am bad at python.

Also the picture you have included here is out of context and does not say anything.
What is this result of?
Is it result of brute forcing encrypted wallet files?
How old is this?
How strong or weak was the passwords which were used? (the length of the password for example was it "123" or was it "2Fd#4dlR&jfh8"?
How many tests were performed on how many variations of passwords?

This part is not right. Electrum uses AES-256-CBC which is, to my knowledge, a pretty strong way of encrypting the wallet file for security.

The max value is 4294967295 = 2106-02-07T06:28:15+00:00 (in ISO 8601)

(my personal opinion) And the solution can be turning it into a Compact size UInt like the rest of the numbers in a transaction. That way it can be as big as 0xffffffffffffffff (8 Bytes with 9 Bytes used) and maybe don't break much of the code.

Well I am not 100% sure about your problem buy as I said my guess is that the transaction you were trying to create and send had a couple of other inputs which were not confirmed and as long as those are have zero confirmation you can not (technically) spend them.

All you can do right now is to wait for them to be confirmed or double spends drop out of mempool and then spend them.

Those two numbers are tx-index on blockchain.info
https://blockchain.info/tx-index/192230192
https://blockchain.info/tx-index/192237304

My guess is that f27bfc80a1dd9774506fe41a4... transaction was using the same inputs as those two (aka Double spend) that is why it was rejected.

Possibly it is because the "Previous Tx" is not yet confirmed, or is already spent by another transaction. If so, you can manually create the transaction and use your Private Key to sign it and then broadcast.

Can you post the TxId of the transaction that you are trying to spend?

Yeah, I have been getting that a lot. I will think of adding additional platforms in the future.


I don't know what you mean by third party, it is a bot that uses the Public and Private exchanges API.
The project is supposed to be like an advanced all-in-one bot (emphasis on supposed to be since it is in the very early stages and I don't have much time to work on it). I posted a screenshot of it once last month and not much has changed about it ever since, I have done about 1000 lines of code so far and I believe it is only 10% of the work.

Don't hold your breath

Reserved in case i needed this space.

If you are so interested in that particular bug you can read about it here: https://github.com/keepkey/multibit/issues/661 and https://multibit.org/blog/2015/02/02/wallet-forensics.html and it seems to me that the problem was with the user not the wallet and because he had imported private keys and messed up things in his wallet.

You are talking about generating a private key with bitaddress not a wallet with multibit

https://bitcoin.org/en/developer-reference#address-conversion
https://en.bitcoin.it/wiki/Base58Check_encoding

Also I think the following can be helpful to look at:

http://chimera.labs.oreilly.com/books/1234000001802/ch04.html#base58

There is no such rule. It just happens so that "usually" the "average" time between blocks are 10 minutes.


That is what happens when there is no block to contain the transactions!


Your assumption is right.
This happens rarely but it happens nonetheless. I am not going to try and explain why because I would like to leave that to the experts but it has something to do with difficulty.

Edit: Good to read if you are interested.
https://bitcoin.stackexchange.com/questions/855/what-keeps-the-average-block-time-at-10-minutes?rq=1
https://bitcoin.stackexchange.com/questions/3909/what-is-the-expected-time-until-the-next-block-is-found?rq=1

How is it not designed to?!!
The only thing you need is a code that is capable of signing a raw unsigned transaction and for that you can use any wallet that has this ability. And with core you use signrawtransaction to do so.

The rest are additional features to improve user experience and also (like what CIYAM did with QR) improve security.