|
vpncoin (OP)
|
 |
July 07, 2016, 12:27:57 PM |
|
Hashes and encryption are extremely resistive to ASCII based compression algorithms so it is likely you are at best compressing the script and small transactions may actually get bigger. Have you reached out the the UPX developers for a look at binary compression?
Our compression algorithm is binary compression, The core algorithm is LZMA, it is better than LZ4. |
|
|
|
|
|
|
|
|
|
|
|
|
"There should not be any signed int. If you've found a signed int
somewhere, please tell me (within the next 25 years please) and I'll
change it to unsigned int." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
icey
Legendary
 Offline
Activity: 1578
Merit: 1000
May the coin be with you..
|
|
July 07, 2016, 08:11:14 PM |
|
But is it better than Pied Piper's compression algorithm?
 Not sure he got it |
|
|
|
|
cloverme
Legendary
Offline
Activity: 1512
Merit: 1054
SpacePirate.io
|
|
July 08, 2016, 07:30:49 PM |
|
But is it better than Pied Piper's compression algorithm?
Best thing I read all day lol I bet Hooli did an under the table deal with Lempel–Ziv on this lossless algo we're seeing here  |
|
|
|
|
|
vpncoin (OP)
|
|
July 08, 2016, 11:03:48 PM
Last edit: July 09, 2016, 12:39:45 AM by vpncoin |
|
But is it better than Pied Piper's compression algorithm?
Best thing I read all day lol I bet Hooli did an under the table deal with Lempel–Ziv on this lossless algo we're seeing here Our compression algorithm is also a lossless compression, We tested on the bitcoin, compression and decompression about 200,000 blocks without any problem, And Blockchain compression rates may be the highest, And it's not just compression. |
|
|
|
cr1776
Legendary
Offline
Activity: 4018
Merit: 1299
|
|
July 09, 2016, 02:30:43 AM
Last edit: July 09, 2016, 03:14:05 PM by cr1776 |
|
But is it better than Pied Piper's compression algorithm?
Best thing I read all day lol I bet Hooli did an under the table deal with Lempel–Ziv on this lossless algo we're seeing here Our compression algorithm is also a lossless compression, We tested on the bitcoin, compression and decompression about 200,000 blocks without any problem, And Blockchain compression rates may be the highest, And it's not just compression. Like knightdk said, the best way to get it into Bitcoin Core is to do a pull request. A few other suggestions: 1. If you create unit-tests and/or other tests that will also increase the speed at which it is evaluated and potentially merged. 2. If you were to create an option to enable it conditionally for both disk compression and network compression, so that it could be running on some nodes that were testing it vs an all-or-nothing approach to test it, I also think that would increase the likelihood of adoption. 3. Similarly, for the network bandwidth there might need to be a way for nodes running this compression code to identify each other so that it could serve compressed data when possible and uncompressed data (e.g. for non-upgraded nodes) at other times (this may already be implemented, I didn't check the code). Or alternatively be able to send either compressed or uncompressed dynamically through some type of negotiation. 4. You might also consider that some people (e.g. miners) might choose to serve uncompressed blocks when they have found a new block so as to minimize latency. e.g. I would serve compressed blocks for old blocks, but for one I just found, I might just send it uncompressed to avoid the time taken to compress it. It could be a trade off - is it faster to send an uncompressed block or to compress and then send. Much would depend on the network speed of connected nodes and I am not sure if anyone has tested which is faster to do. In short, the more groundwork that is done, the better. In general, on disk and sending old blocks that are compressed is a nice feature. My thoughts. |
|
|
|
|
Velkro
Legendary
Offline
Activity: 2296
Merit: 1014
|
|
July 09, 2016, 09:54:42 AM |
|
Very interesting stuff. There are cases where hdd space for node is not a problem as someone mentioned above, but there are cases this is problem. Same with traffic, some have problem with it, some don't.
It would be great to allow to choose in configuration to use compression on your node (if hdd space is problem) or not (if you have a lot of free hdd space). Similiar to GZIP in web/browser traffic.
|
|
|
|
|
AlexGR
Legendary
Offline
Activity: 1708
Merit: 1049
|
|
July 09, 2016, 06:31:32 PM |
|
In the windows environment, the impact of CPU can be ignored,
It can save 20%~25% and even more disk space, My harddisk is 1TB Right now 328 GB is free space. I think that this would be enough for 3-5 years for me. What is a reason to compress blockchain and increase the work for CPU? I see no reasons for compressing data on disk. Fast compression algorithms can trade very slow I/O time, for much faster cpu time - thus speeding things up in general. For example, if 100 mb can go down to 80, reducing read, write, seek operations, the overall time of a process involving disk I/O on these 80mb can be sped up significantly. Now if you have a much better compression algorithm that takes 100mb to 60mb but takes a couple seconds instead of msecs to do the job in order to gain the extra -20mb of compression - that doesn't work to speed things up in local operations. It could be still useful though for network transmission because those 20mbs could take more than a few seconds to get transmitted. Another reason is that if you are marginal with the blockchain in a particular storage medium, especially SSDs, you can then fit the blockchain after compressing it. That will allow you to exploit the faster SSD instead of going with the slower mechanical. The blockchain won't fit in a 64gb SSD right now, but it can fit compressed (say a BTRFS partition with compression) - although it doesn't have much headroom for SSD operations that require some free space. In some time, it won't fit in a properly configured 120gb ssd running an OS (assuming it has like 40gb for linux, swap, and free space that SSDs require) but it will fit if the data is compressed. The gains there are exclusively from using the faster SSD over the mechanical disk. In any case, from searching the dev mailing list in older discussions I think some devs are reserved in using popular compression algorithms due to security concerns and exploits. |
|
|
|
|
|
vpncoin (OP)
|
|
July 14, 2016, 07:00:09 AM |
|
But is it better than Pied Piper's compression algorithm?
Best thing I read all day lol I bet Hooli did an under the table deal with Lempel–Ziv on this lossless algo we're seeing here Our compression algorithm is also a lossless compression, We tested on the bitcoin, compression and decompression about 200,000 blocks without any problem, And Blockchain compression rates may be the highest, And it's not just compression. Like knightdk said, the best way to get it into Bitcoin Core is to do a pull request. A few other suggestions: 1. If you create unit-tests and/or other tests that will also increase the speed at which it is evaluated and potentially merged. 2. If you were to create an option to enable it conditionally for both disk compression and network compression, so that it could be running on some nodes that were testing it vs an all-or-nothing approach to test it, I also think that would increase the likelihood of adoption. 3. Similarly, for the network bandwidth there might need to be a way for nodes running this compression code to identify each other so that it could serve compressed data when possible and uncompressed data (e.g. for non-upgraded nodes) at other times (this may already be implemented, I didn't check the code). Or alternatively be able to send either compressed or uncompressed dynamically through some type of negotiation. 4. You might also consider that some people (e.g. miners) might choose to serve uncompressed blocks when they have found a new block so as to minimize latency. e.g. I would serve compressed blocks for old blocks, but for one I just found, I might just send it uncompressed to avoid the time taken to compress it. It could be a trade off - is it faster to send an uncompressed block or to compress and then send. Much would depend on the network speed of connected nodes and I am not sure if anyone has tested which is faster to do. In short, the more groundwork that is done, the better. In general, on disk and sending old blocks that are compressed is a nice feature. My thoughts. Thanks |
|
|
|
|
vpncoin (OP)
|
|
July 14, 2016, 07:06:29 AM |
|
Recently I will upload the complete source code to GitHub,
It is integrated in the bitcoin version 0.8.6 .
|
|
|
|
|
|
|
MadCow
|
|
July 23, 2016, 07:18:13 AM |
|
Recently I will upload the complete source code to GitHub,
It is integrated in the bitcoin version 0.8.6 .
is the new wallet ready yet? |
|
|
|
|
|
vpncoin (OP)
|
|
July 24, 2016, 08:52:54 AM |
|
is the new wallet ready yet?
Bitcoin version 0.8.6 integrated blockchain compression algorithm source code has been upload: https://github.com/Bit-Net/Bitcoin-0.8.6These source code just for test, it can compile and run in ubuntu and windows, And it is compatible with the bitcoin, does not fork bitcoin. |
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
July 24, 2016, 01:16:23 PM |
|
is the new wallet ready yet?
Bitcoin version 0.8.6 integrated blockchain compression algorithm source code has been upload: https://github.com/Bit-Net/Bitcoin-0.8.6These source code just for test, it can compile and run in ubuntu and windows, And it is compatible with the bitcoin, does not fork bitcoin. Why don't you try integrating this into the master branch of Bitcoin? 0.8.6 is incredibly old and outdated software and should not be used anymore. |
|
|
|
gmaxwell
Staff
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
July 24, 2016, 07:19:22 PM |
|
0.8.6 is what most altcoins are based on, it is an old codebase with many vulnerabilities. Also look at the screenshots. This is in the wrong subforum.
|
|
|
|
|
|
JohnnyBTCSeed
|
|
July 24, 2016, 07:47:09 PM |
|
0.8.6 is what most altcoins are based on, it is an old codebase with many vulnerabilities. Also look at the screenshots. This is in the wrong subforum.
 You got served |
|
|
|
|
|
vpncoin (OP)
|
|
July 25, 2016, 12:21:59 AM |
|
is the new wallet ready yet?
Bitcoin version 0.8.6 integrated blockchain compression algorithm source code has been upload: https://github.com/Bit-Net/Bitcoin-0.8.6These source code just for test, it can compile and run in ubuntu and windows, And it is compatible with the bitcoin, does not fork bitcoin. Why don't you try integrating this into the master branch of Bitcoin? 0.8.6 is incredibly old and outdated software and should not be used anymore. As you know, a new code need more time to study, I am familiar with the 0.8.6 version, it is easy to transplant the compression algorithm code to 0.8.6 version. |
|
|
|
|
vpncoin (OP)
|
|
July 25, 2016, 12:33:50 AM |
|
0.8.6 is what most altcoins are based on, it is an old codebase with many vulnerabilities. Also look at the screenshots. This is in the wrong subforum.
You guy hurt my heart,  I offer my ideas for free, and provide the source code that can be compiled, It is used to test and prove that this compression algorithm is possible, I'm doing this for free, I just hope to help bitcoin, make it better. |
|
|
|
|
MadCow
|
|
July 25, 2016, 02:51:01 AM |
|
0.8.6 is what most altcoins are based on, it is an old codebase with many vulnerabilities. Also look at the screenshots. This is in the wrong subforum.
You guy hurt my heart, I offer my ideas for free, and provide the source code that can be compiled, It is used to test and prove that this compression algorithm is possible, I'm doing this for free, I just hope to help bitcoin, make it better. Don't be put off, everyone in crypto has their own bias & agenda depending on what coins they own, what projects they're following, and who pays their wages. Keep doing your own stuff! |
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3374
Merit: 6535
Just writing some code
|
|
July 25, 2016, 02:57:06 AM |
|
As you know, a new code need more time to study,
I am familiar with the 0.8.6 version, it is easy to transplant the compression algorithm code to 0.8.6 version.
Well if you want this to be adopted by Bitcoin Core, you will have to put it into the master branch. As I said earlier, 0.8.6 is old and outdated. It is 5 major releases behind, during which time the code has been refactored, changed, and shuffled around. Furthermore 0.8.6 has some vulnerabilities in it that were solved in later releases. If you want to be taken seriously, make it for the latest master. No one cares about what you can do, clearly you can program and read code, it shouldn't be hard to figure out where to put it in the master branch. Bitcoin Core is very well documented and commented. 0.8.6 is what most altcoins are based on, it is an old codebase with many vulnerabilities. Also look at the screenshots. This is in the wrong subforum.
You guy hurt my heart, I offer my ideas for free, and provide the source code that can be compiled, It is used to test and prove that this compression algorithm is possible, I'm doing this for free, I just hope to help bitcoin, make it better. Almost everyone who contributes to Bitcoin Core does it for free. Sure the compression algo is possible on 0.8.6, but will it still work on master? Why don't you try it out. I do agree though that gmaxwell shouldn't have moved this as it is about Bitcoin Core, albeit an old version. |
|
|
|
|
