Bitcoin Forum
November 24, 2017, 10:04:40 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 106 »
1  Bitcoin / Development & Technical Discussion / Re: Bitcoin Script language grammar? on: November 18, 2017, 08:09:46 PM
Thanks for your explanation, do you think it'll be worth trying to do it for the ethereum solidity language ??
Yeah, with Solidity the context-free grammars are the proper tool-set to for the problem domain.

You'd really will have to discuss this with your scientific advisor at your school. They will need to help you select a project with the proper difficulty level for your school and your degree. My advice is: prepare a palette of possible projects, some too trivial (like your original idea), some too complex, and have have a discussion with the a teacher at your school who knows you and who will grade your coursework.
2  Bitcoin / Development & Technical Discussion / Re: Bitcoin Script language grammar? on: November 18, 2017, 07:02:05 PM
The context-free grammar is trivial, just a concatenation of lexical elements (alphabet symbols). All the expressive power is contained in the context (in this case, the contents of the stacks). It is equivalent to a simple RPN (reverse-polish notation) calculator, it doesn't even use parentheses for disambiguating the order of operations.

Since you've mentioned "university course": the formal languages aren't a good tool to analyze simple stack machines like the one in Bitcoin. You would just waste time trying to analyze it at this level. Search for another, more productive, subject for your coursework.
3  Bitcoin / Development & Technical Discussion / Re: Whole Bitcoin Core 0.15 blockchain database on Google Drive on: October 28, 2017, 07:47:35 AM
OK, it seems like all parts are available now for a total of 131.62GB. Google seems to be throttling download to below 100 megabits per second, so I get the ETA of over 3 hours. I'll post again when its done, but otherwise it looks good: JDownloader recognized all 9+1+2 parts, correctly recognized their sizes and availability.

Maybe not as fast as that "axel" mentioned by the other poster, but otherwise seems flawless.

Edit: OK, I forgot about this download. It finished properly, uncompresses properly without password, there wasn't any strange files in it and the Bitcoin client started off this directory properly and resumed syncing without problem.

Also a reminder: decompression utilities restore the files in a fairly fragmented state. Defragment the uncompressed directory to improve overall performance.
4  Bitcoin / Development & Technical Discussion / Re: Whole Bitcoin Core 0.15 blockchain database on Google Drive on: October 28, 2017, 04:55:58 AM
Part 11 seems to be missing from the 3rd link.
5  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: October 28, 2017, 04:27:21 AM
From what I can tell there isn't much interest in downloading bootstrap.dat or a pre indexed blockchain. I had my indexed blockchain directly downloadable for a time and I only got a couple hits a week and that was free of charge!
The lack of interest you observing is probably related to your choice of protocol (GNUtella). Bittorrent is way more popular and I could nearly always seen somebody downloading the torrents that are published in various threads here. Currently there are about six leechers in the swarm. I never bothered to keep accurate statistics, but I would estimate that my old computer would push around 1TB (terabyte) per month in various Bitcoin torrent throughout this year. My statistics are very approximate because that old machine also seeds other things, but Bitcoin torrents are by far the biggest and nearly constantly active.
6  Bitcoin / Development & Technical Discussion / Re: Bitcoin core and Bitcoin ABC on the same Linux machine on: September 22, 2017, 05:32:26 PM
Thank you. What is the correct config line in bitcoin.conf to set a different port than 8333? Can't seem to find it.
Later edit: found it, it is port=12345... Smiley
Also, don't forget about "rpcport"!
7  Bitcoin / Development & Technical Discussion / Re: Bitcoin core and Bitcoin ABC on the same Linux machine on: September 19, 2017, 07:01:37 PM
Guys, Linux is a multiuser system.

Just create additional user accounts, one each for each coin. They won't step on each other files. The only thing you will have to worry is to set each of the Bitcoin forks to run on a separate network ports, because each of them will try to claim ports 8332 and 8333 for themselves.

If you are thoughtful about setting up user permissions you will be safe even if you accidentally install trojaned software, because they will have no access to each other wallets.

No need to play with tar files or other non-default installation methods.

Same thing is true for Windows and macOS.
8  Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin blockchain data torrent on: August 22, 2017, 10:59:08 AM
You do realize, that data in torrent are WAY outdated and new node need get lots of data anyway?
So what? It is and it forever will be a proper subset of the valid data. This torrent is sufficient to reliably trigger bugs in certain popular/cheap flash storage devices. This alone would make it an useful test case for at least decade, maybe more.

Also, there are (non-English language) papers that use this torrent for performance comparison of various file systems, alternate storage engines and file/partition layouts.

It is NOT good way to bootstrap node.
This is just your personal limitation that you can't or won't understand why separating over-the-WAN download from over-the-LAN initialization is and will be useful troubleshooting and testing tool.
9  Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin blockchain data torrent on: August 18, 2017, 07:43:29 PM
This topic can be closed? Some people still asking about thing that is not need for like year.
Please don't close it. Lots of people with unreliable hardware or network problems are still better off downloading separately from initializing the blockchain storage.

There are many people with non-flat-rate network hookups or with over-the-radio hookups with shared IPv4 addresses that continue to download the torrents from this thread.
10  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit2x agreement with >80% miner support. on: July 06, 2017, 04:13:27 PM
Now you're seriously offtopic in my opinion (and since this is my thread my opinion gets final word). Complain all you like about the core code (I'm not a fan of its performance either), but do it elsewhere please. Let's stick to segwit2x discussions or I'll start deleting posts.
I hope you'll not delete my post. The reason why technical arguments are important in a political discussion is that they are the simplest way to do distinguish between empty politicking and true long-term planing. Even non-technical people can understand those arguments.

Even then I still don't get why they are stuck with LevelDB, RocksDB is clearly far superior.

This is the type of gang-warfare argumentation: LevelDB-s contra RocksDB-s.

It is my understanding that -ck was involved in the Linux kernel development. Long time ago Linux was mired in the internecine warfare of various gangs of fanboi-s for the various file systems. The strategic choice wasn't to choose one over the other, it was to implement an abstraction layer for any file system underneath: . That's because there isn't a single universal best file system, there are however best filesystems for various usage scenarios.

The same approach is the correct one for any Bitcoin client implementation: there is a need to implement an abstraction layer(s) for the blockchain and transaction storage. And remember: mempool is also a database, although rather trivial.

Some supporters of segwit2x (and other proposal) make political arguments about decentralization of Bitcoin client development. It could be fairly easy to see if they really support decentralization by asking them about their stance about abstracting the storage engines used by the Bitcoin clients.

The rest of the technical arguments will be in a parallel thread: .
11  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit2x agreement with >80% miner support. on: July 06, 2017, 04:28:57 AM
Saves at least 10-20G out of a 150G blockchain just by switching.
No way. Blockchain isn't stored in LevelDB. It is stored in raw data files (blk*.dat) and raw undo files (rev*.dat). LevelDB is used only to store indices into those raw files. "Just switching" wouldn't change the situation much, it takes rather substantial rewrite to change the storage engine in Bitcoin Core.
12  Bitcoin / Development & Technical Discussion / Re: Berkeley Database version 4.8 requirement unsustainable on: June 26, 2017, 08:32:41 AM
The issue isn't really one of distribution as much as it's an issue of usage. Reliance upon a library that is antiquated (even by the library's own standards) is pure nonsense. It's akin to a major car company using the seats of the 1923 model of someone else's truck in their 2018 model sports car. Undecided
What a dumb comparison!

Bitcoin is, for better and for worse, effectively married to BerkeleyDB. It is used to operate on the keys stored in the wallet.dat. It will have to be supported probably forever, at least in the read-only mode, to safely import the content of legacy wallet.dat into some more modern storage layer that is both better designed and easier to integrate with.

Dumb fanboism and upgrade treadmill is a job safety trick that the open source people learned from the best ones in Redmond and Cupertino. Not that BerkeleyDB is perfect, but it is stable, and will have to be supported practically forever, even if only in a separate legacy import module.
13  Bitcoin / Development & Technical Discussion / Re: Berkeley Database version 4.8 requirement unsustainable on: June 25, 2017, 03:01:11 PM
Secondly, I'd like to point out that: 3 years and 5 major versions of Core after that quote, we're still stuck with trying to make a version of BDB from 2010 work in a 2017 operating system (despite the fact that both Core and BDB have had dozens of releases since that time); I'd say there's definitely no one "rushing into it".  Roll Eyes
The BerkeleyDB is a special case for compatibility of their binary files. Having the correct version of source code doesn't make the binary files fully compatible. IIRC BerkeleyDB intentionally stores somewhere a hash of concatenation of sizeof's of certain structures. That hash value is very dependent on the exact compilation flags and other details of the compilation environment. Since the official Bitcoin Core client is not built in the default environment but in Gitian, the default BerkeleyDB (utilities and shared libraries) available in the Linux distribution will not be fully compatible with the one build under Gitian.

To achieve full compatibility with the user's code the Bitcoin Core distribution should probably distribute their own internal Gitian build of BerkeleyDB (utilities and archive libraries) in a separate, optionally downloadable file. Single zip file would do for all platforms built with the Gitian, it is of somewhat limited interest, only for a subset of developers.

Trying to operate on BerkeleyDB binary files with the default shared library and default utilities creates some hard to understand and debug special cases/problems in the 3rd party software. The number of hidden ways to shoot yourself in the foot is bewildering. Even before Oracle acquired them SleepyCat made some unusual decisions in their design. My best guess is that instead of binary compatibility their optimized for minimum size of the executable code.

Trying to undo those SleepyCat decisions would probably require maintaining a separate fork of BerkeleyDB somewhere in the Bitcoin Core's source tree. This would somewhat parallel the situation with LevelDB, where separate fork is being maintained to improve its ACID resilience from hardware/OS crashes.

In summary, I agree with the decision to "proceed with caution". I definitely think that using the distribution's default build of BerkeleyDB is not the "best" way. The Linux distributions (or MacOSX builds) are made that way to optimize/minimize total disk and memory footprint of the entire distribution. Bitcoin Core is such a special case that for the sake of safety it is better to optimize for another goal and don't rely on the pre-distributed code (source and binaries).
14  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 23, 2017, 06:30:27 PM
I tested the link plus installing it into new wallet on different PC, should work if you have winRAR
Yeah, I can confirm it "works", i.e. downloads in full and restores correctly.

The question is "how much effort is required to use it on a clean computer, especially Windows?" When somebody doesn't already have Google Chrome and payware RAR utility this isn't so easy.

Depending on the country the attempt to use of directory-level Google Drive link in Microsoft Internet Explorer one ends up with either a hang (described above) or a prompt to upgrade browser.

I don't know if payware RAR utility is smarter, but the freeware unrar restores those directories in a heavily fragmented state. It doesn't make sense for anyone to pay for full RAR license (or lookup the ever-popular cracks) when all that's required is a one-time uncompressing. With heavily fragmented store Bitcoin Core client works much slower then when it would do the download itself.

Yeah, but it makes everything go much faster, especially for users of the ISPs which don't have fully routable IP addresses but have to use to use CG-NAT-ed shared IP addresses. Google Drive doesn't seem to do per-IP throttling unlike e.g. .
15  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 23, 2017, 01:48:33 AM
Does anyone require this link anymore? We currently have duplicates, probably not necessary.
Yours has a distinction of actually working. The one posted lkloon123 don't seem to work. They seem to hang on: Preparing download: zipping 1 file: progress circle gets stuck below 25%. In a dedicated Google Drive download utility they show as "files offline".

So maybe keep your until somebody confirms successful use of the other links?

Edit: Further research shows that barto123 posted hyperlink to a file, but lkloon123 posted link to a directory of subdirectories (named with a date) that contain the actual RAR files. Google Drive must have different special cases for different browsers. I managed to start download of lkloon123's post by starting it in "Google Internet Explorer Chrome", pausing the download and then copy-pasting the end-file link to a browser not approved by Google.

Pain in the neck, but it could be made to work. I'll update one the RAR download finishes and passes verification in unrar.
16  Bitcoin / Hardware / Re: ASIC fabrication tools on: June 15, 2017, 04:22:27 PM
If you are an autodidact in English that's even better. It mean that you yourselves as your own teacher are very intelligent and very effective. The communication barrier you are experiencing has nothing to do with your language skills. It stems from the fact that you concoct a fake reality where you believe that you have some skills, discovered profitable market segments and could achieve certain business success. But people sooner or later see through your lies and you start getting ignored. That in turn makes you angry and you redouble in your lies until you are getting lost in them.

What I would suggest is to see the movie "A Beautiful Mind" . It is loosely based on life of John Nash. The key takeaway for you is to see how he used his intelligence (not medications) to to cure himself from his psychological problem, to build up his mental strength to be brave enough and ask other people whether they see the people he had seen (that was in the movie, in reality he only hear voices, but that would be hard to show in a film.)

What you could do is to put your dream project on hold. Find something that would be still interesting to you and immediately useful to somebody else. "Somebody" means here both a person and an existing company that needs help in developing their own ideas. Use that to build up your own real experience and real business development skills. Your own current argumentation for your dream project could be summed up: "During a hurricane even pigs could fly."

Note to the moderators:

This thread has nothing to do with Bitcoin mining, not even the mining of altcoins. As such it should probably belong in the off-topic sub-forum. But you can leave it here if you think some reader could use the links I provided to learn something about developing and prototyping custom mining hardware.
17  Bitcoin / Hardware / Re: ASIC fabrication tools on: June 14, 2017, 11:21:56 PM
Well, Andrew, you can congratulate your English teacher, you've fooled me (and at least one other person) into thinking that you are at least fluent English writer even if not a good English reader. I apologize I made certain incorrect assumptions about your goals, but you've provided very little information about yourself or your dream project .

I believe that before anyone can help you'll need to answer a number of questions:

1) Are you a young person or are you already a mature person looking for a change in life?
2) What can you say about your educational background? How did you found yourself in a situation where the school didn't provide you with the basic knowledge in the field you have so much interest in?
3) Please read and describe to us why you feel that you are different from Arthur T. Murray?

I think I can feel your pain, but please help us help you.
18  Bitcoin / Hardware / Re: ASIC fabrication tools on: June 14, 2017, 04:33:07 PM
Even the 10+ year old books will help you formulate your thoughts better. You seem to be either native English speaker or at least have long experience in English. Yet you've used the phrase "integrated dynamic memory matrix" which for me made you sound like a crackpot. Why would "idea" be a "dynamic memory device"?

Please don't immediately get offended by my use of the word crackpot. Here is a better explanation of crackpots in physics:

There's no ready-made crackpot index for microelectronics and ASIC design field, you'll have to use your intelligence to apply it to yourself and your chosen field of endeavor.

Anyway your "integrated dynamic memory matrix" is called eDRAM. First result in my Google search for "FPGA eDRAM" explains why it isn't some panacea to everybody's problems:

Our initial conversation was in early April. Couple of weeks later Amazon announced that their EC2 FPGA instances are generally available for rent.

What's wrong with prototyping your "idea" on one of those? Why can't you use Intel Quick Path Interconeect to at least approximate eDRAM?

I already answered your further questions from the today's message of yours. If you want me to reword my advice to match your reworded question it will be: the free advice you'll get will be worth every penny you've paid for it. Now that you've mentioned a "business expert" and the need of secrecy to protect your "idea" it all begins to look very much like a version of some "long con" updated for the XXI century.
19  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 14, 2017, 02:13:08 AM
Kinda newb here, but what's the purpose of this? Can't you simply download it the "normal" way? And I would imagine it would be hard to keep seeders seeding the torrent if you update it all the time.
The purpose is (mostly) to save time and (possibly) wear and tear on the storage hardware.

Bitcoin Core uses extremely primitive methods for maintaining the blockchain storage: it is quite slow and needlessly, extremely, write-intensive: to write effectively about 125GB of data to disk it will actually write multiple terabytes more in the process of internal reorganizations and pointless optimizations.

Good quality SSD devices have no problem handling it, but cheap eMMC or SD-card devices can be completely worn out before the initial synchronization finishes. Flash storage is always limited by the write endurance: how many times the storage cell can be erased and rewritten.
20  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 12, 2017, 03:01:59 AM
Please don't listen to bullshit from non-technical people. Bitcoin Core does initial download faster only in certain conditions, that nowadays could be considered laboratory-like. With the real user environments (especially technical newbies or people outside USA) it is much more reliable and oftentimes faster to do this using Bittorrent or cloud file storage.
This is simply untrue.

Unless your internet connection is very slow the vast majority of time is spent in validation and data handling even on a 24 core host.  

If you download separately you cannot overlap the download and validation.  So unless your download is nearly infinitely fast it must be slower.

This experiment is conducted regularly in real conditions at least with every release (since we benchmark for synchronization performance regressions).
Dude, you are so disconnected from reality that it isn't funny anymore.

Your "real conditions" consist of:

1) Not running Windows natively on the hardware as a matter of core dev team policy, but on virtualized high-end hardware.

2) Using well tested hardware, probably with ECC RAM and SSD storage.

3) Using static (or nearly static) IPv4 address that isn't shared with other users of the ISP providing cabled/fixed service.

The real users' conditions are vastly different:

1) Windows running natively, frequently on cheap computers or external drives connected with USB.

2) Untested hardware that had never run any sort of database application, only web browsers and games. Most users will try to put Bitcoin on a mechanical drive and to compound problems will run various online anti-virus and other lame security applications.

3) Outside of the USA static IPv4 are quite rare commodity, most users have either forcibly changed dynamic IPv4, shared IPv4 through CG-NAT or dual-stack-lite IPv6 deployments where only IPv6 is static and IPv4 is shared. Large fraction of Bitcoin users use various non-cabled ISPs either radio-line or cellular. Bittorrent deals with those much better than Bitcoin Core.

4) In practice the beginning users have to attempt initial synchronization several times until their resolve problems with their configuration following the usual recipe: blow away everything except wallet.dat and restart from scratch, very much in the days of MS-DOS on a PC-compatible. Downloading the data separately at least allows them to start cleanly in an reproducible configuration that allows sensible troubleshooting.

5) For many users the proper metric to optimize is not "minimum total time" but "minimum total costs". Especially those users on non-cabled ISPs have non-metered, well-performing connections only through 8 to 12 hours during night time. For them separating download (via Bittorrent or cloud file locker) and local synchronization makes obvious sense.
created with multiple restarts of the Bitcoin client, needlessly keep track of orphaned blocks, keep track of transactions in somebody's wallet, etc.
Orphaned blocks are about 1% -- who cares if there is 1% of overhead in the files?  The linearize tool in the contribs directory will create block files without them-- sure, but they're not a big deal. The main reason to exclude them is to get a reproducible file.  The wallet _never_ has any effect on the content of the block files.

The risk with copying a chainstate, beyond the risk of being tricked onto a fork where the attacker has created a bunch of coins out of thin air is that the leveldb database files are not a safe external interface and it may well be possible to get remote code execution with a specially crafted database.  BDB (used for the wallets) can easily be caused to crash with out of bounds memory accesses from crafted database files, for example.

I'm pretty sure that that a UTXO assume-valid type sync will be supported (even a default) in the future-- but that doesn't mean that copying database files from third parties is safe-- personally I'd never do it.
It isn't the 1% waste that is the problem. It is lack of reproducibility and lack of possibility of making sensible incremental backups and incremental synchronization amongst multiple machines.

Your paranoia is largely unfounded for two reasons:

1) even if you (or your friends stateside) don't know the providers of pre-initialized state directories, those people are frequently quite well-known outside of the USA and can be reasonably trusted.

2) most of the users desiring shortcuts to initialize don't have any coins in their wallet and don't plan on putting any just yet. They are planning on learning or demonstrating the technology.

3) the "crafted leveldb exploit to put user on a fake fork" is largely theoretical so far, whereas the practical exploits were social engineering related to fraudulent technical help with extremely fragile and problematic Bitcoin Core that has almost no internal RAS features (reliability - availability - serviceability) and laughable error messages like "there was checksum error, aborting".

Don't even get me started on using sensible storage architecture for Bitcoin Core. I tried to explain the benefits of storage layer abstraction to etotheipi in 2013:

His position was that he rather have his company fail than use a database engine that is more than an educational toy. By the time they tried to switch to LightningDB he was out of money and out of patience from the prospective enterprise customers.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 106 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!