Bitcoin Forum
July 28, 2017, 04:34:10 AM *
News: BIP91 seems stable: there's probably only slightly increased risk of confirmations disappearing. You should still prepare for Aug 1.
 
  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 ... 105 »
1  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: https://en.wikipedia.org/wiki/Virtual_file_system . 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: https://bitcointalk.org/index.php?topic=2006262.0 .
2  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.
3  Bitcoin / Development & Technical Discussion / Re: Berkeley Database version 4.8 requirement unsustainable on: June 26, 2017, 08:32:41 AM
@2112:
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.
4  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).
5  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. Mega.nz .
6  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.
7  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" http://www.imdb.com/title/tt0268978/ . 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.
8  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 http://rpcdram.com/ .

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 http://www.nothingisreal.com/mentifex_faq.html 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.
9  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:

http://math.ucr.edu/home/baez/crackpot.html

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:

http://www.eevblog.com/forum/microcontrollers/intelaltera-brings-fpga-to-xeon-broadwell-chip/msg896237/#msg896237

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

https://aws.amazon.com/blogs/aws/ec2-f1-instances-with-fpgas-now-generally-available/

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.

https://www.amazon.com/Big-Story-Confidence-Man/dp/0385495382
10  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.
11  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:

https://bitcointalk.org/index.php?topic=144015.0

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.
12  Bitcoin / Bitcoin Discussion / Re: of whales and forks on: June 11, 2017, 10:01:04 PM
thebitcoin.foundation has its own team of developers and they can deal with scaling should it become an issue.
they don't like all the stuff already added to versions 0.6 or so onwards (roughly), or the proposed stuff like segwit, and they don't use it.
This is very questionable statement. They are more of "software museum curators" than "developers".

They already tried to deal with scaling and failed badly when working on the "low-end pre-configured node" using some ARM development board. The type of mistakes they made shows that their skill level is at most baccalaureate, certainly not someone who had master's degree at anything related to modern computing and information retrieval. Seriously, I've seen more knowledgeable people among high school graduates that studied and got certified for some proprietary database administration courses. I mean, if you continue to use Berkeley DB for bulk data at least read the fine manual!
13  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 11, 2017, 09:31:50 PM
i will create torrent as well shortly for latest blockchain with 1Gbps uplink
If you want to do it and have fast hardware do it properly: initialize an instance isolated from the Internet syncing to a single node in a reproducible way. Trim that single node to the exact height as the most recent checkpoint in the source code for that version.

Lots of people post torrents than have few seeders because their torrents are barely useable: created with multiple restarts of the Bitcoin client, needlessly keep track of orphaned blocks, keep track of transactions in somebody's wallet, etc.

This is especially important if you're using some web-server-grade cloud hardware without ECC memory or DDR3 memory susceptible to row hammer. People then wonder why their block storage doesn't pass self verification.

Edit: Oh and one more thing: don't compress it with RAR. The RAR decompression utilities create severely fragmented files. Both Bitcoin Core client and most of Bittorrent clients at least create files in a way to avoid fragmentation.
14  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 11, 2017, 09:19:08 PM
It's not longer recommended to download the bootstrap file for sometime now, having the latest bitcoin core version will make you download the files much faster.
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.

Depending on ones own level of paranoia there are two most common ways of initialization:

1) low-paranoia: download and unpack the pre-initialized "blocks" and "chainstate" directories

2) high-paranoia: download "bootstrap.dat" and do initialization and verification with local disks or LAN disk mounts

3) extreme-paranoia: do (1) or (2) and initialize new secure node totally over LAN without allowing Internet access from the secure node.
15  Bitcoin / Development & Technical Discussion / Re: How is it possible to measure the amount of nodes that are just "listening" ? on: June 09, 2017, 08:30:42 PM
A very different number is shown at:
https://bitnodes.21.co/
This site is buggy and undercounts the nodes. I still occasionally use it, but the numbers there are not even statistically reliable, they are skewed downwards.

Part of it is because of simple bugs (e.g. incorrect pruning of inactive nodes) or routing problems on their end.

Part of it is because of some rather strange ways it attempts to deal with Sybil attacks and cannot reliably distinguish them for legitimate address reuse (e.g. CG-NAT or certain forms of IPv6 deployment like DS-Lite).
16  Bitcoin / Development & Technical Discussion / Re: Blockchain download on: June 09, 2017, 05:38:50 PM
Of course if would be beneficial. The problem is that people tend to attack those hosting Bitcoin torrents.

Try to make a post in the historical one of the historical, more popular threads:

https://bitcointalk.org/index.php?topic=1310261.0

You'll get the quickest uptake if you trim your bottstrap.dat to the exactly same height as the torrent posted there on May 30th. That torrent already has at least 10 leechers.
17  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 09, 2017, 02:48:11 PM
the torrent does not work anymore. Sad
The torrent from the previous page, made on May 30th does work just fine. Another working torrent is from May 18th from the post that somebody deleted, but the web link still works.

http://blockchainbootstrap.com/index.html

Those are respectively 110.46 GB and 126.39 GB, unlike the torrent in the original post that was less than half of those.

 
18  Bitcoin / Development & Technical Discussion / Re: Can we validate all the blocks created till date with the first Satoshi client? on: June 03, 2017, 05:48:36 PM
You can't. I know for certain that all versions of Bitcoin/Bitcoin-qt 0.7.2 and earlier will not be able to sync with the network due to an insufficient number of Berkeley DB locks which then essentially imposed a block size limit at around 500kB. This issue is what caused the March 2013 fork. Because of this, all versions of Bitcoin/bitcoin-qt 0.7.2 and earlier will be unable to fully sync the blockchain.
This is bullshit. Not just garden-variety bullshit, but military-grade weaponized bullshit.

This is exactly what happens when people willfully don't read documentation as a matter of development policy.

It is exactly like the proverbial "giving people just enough rope to hang themselves".

I posted about this on the same night it happened because I was driving long distance and couldn't really stop for a full post earlier.

https://bitcointalk.org/index.php?topic=152208.0
https://bitcointalk.org/index.php?topic=152030.msg1616542#msg1616542
The "manual tweak" is exactly two lines. Anyone can apply it, because the recompilation is not necessary. All it takes is to create a short text file and restart the bitcoin client.

Those threads are interesting read for anyone wondering how Bitcoin ended up with a fragmented development community that we have now. You'll understand how the division lines were drawn and what methods of disinformation were applied. I certainly was enlightened on that very afternoon-evening-night about what was really going on amongst the leading developers and pool operators.
19  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit agreement with >80% miner agreement. on: June 01, 2017, 09:24:48 PM
We need to remember to be patient here. Consensus is very hard and takes time as does testing and vetting of code. Bitcoin itself has no inherent value. Its value comes from the consensus network of individuals that transact in and use it. Fracture that network into pieces and the value of the parts will not add up to the whole as scope of possible economic interactions will narrow.

Think of the internet. If the early internet had fractured into a western hemisphere internet and a competing eastern hemisphere internet that used incompatible protocols the overall value and usefulness of the internet as a global communications medium would be reduced.

A fractured bitcoin would damage the core of what bitcoin is. Bitcoin is an overarching consensus system organized around the concept of sound money. Those voluntarily participating in this consensus are required to behave transparently and do work with the ultimate aim of ensuring all network participants abide by the greater consensus. Nodes who choose not to follow the protocol, miners who submit invalid proof of work, and users who try to spend bitcoins without verified private keys, are simply ignored by the greater consensus.
Another attempt at rewriting the history of the Internet.

Consensus was and is quite easy to achieve within the framework of cooperation. Internet didn't split into incompatible islands because from the start the architects intended to cooperate. To debunk comparisons between the Internet and Bitcoin it is sufficient to quote the legacy RFC 1025 "TCP and IP Bake Off":

Procedure

   This is the procedure for the TCP and IP Bake Off.  Each implementor
   of a TCP and IP is to perform the following tests and to report the
   results.  In general, this is done by using a test program or user
   Telnet program to open connections to your own or other TCP
   implementations.

   Some test are made more interesting by the use of a "flakeway".  A
   flakeway is a purposely flakey gateway.  It should have control
   parameters that can be adjusted while it is running to specify a
   percentage of datagrams to be dropped, a percentage of datagrams to
   be corrupted and passed on, and a percentage of datagrams to be
   reordered so that they arrive in a different order than sent.

   Many of the following apply for each distinct TCP contacted (for
   example, in the Middleweight Division there is a possibility of 20
   points for each other TCP in the Bake Off).

   Note Bene: Checksums must be enforced.  No points will be awarded if
   the checksum test is disabled.

      Featherweight Division

         1 point for talking to yourself (opening a connection).

         1 point for saying something to yourself (sending and receiving
         data).

         1 point for gracefully ending the conversation (closing the
         connection without crashing).

         2 points for repeating the above without reinitializing the
         TCP.

         5 points for a complete conversation via the testing gateway.

      Middleweight Division

         2 points for talking to someone else (opening a connection).

         2 points for saying something to someone else (sending and
         receiving data).

         2 points for gracefully ending the conversation (closing the
         connection without crashing).

         4 points for repeating the above without reinitializing the
         TCP.

         10 points for a complete conversation via the testing gateway.

      Heavyweight Division

         10 points for being able to talk to more than one other TCP at
         the same time (multiple connections open and active
         simultaneously with different TCPs).

         10 points for correctly handling urgent data.

         10 points for correctly handling sequence number wraparound.

         10 points for correctly being able to process a "Kamikaze"
         packet (AKA nastygram, christmas tree packet, lamp test
         segment, et al.).  That is, correctly handle a segment with the
         maximum combination of features at once (e.g., a SYN URG PUSH
         FIN segment with options and data).

         30 points for KOing your opponent with legal blows.  (That is,
         operate a connection until one TCP or the other crashes, the
         surviving TCP has KOed the other.  Legal blows are segments
         that meet the requirements of the specification.)

         20 points for KOing your opponent with dirty blows.  (Dirty
         blows are segments that violate the requirements of the
         specification.)

         10 points for showing your opponents checksum test is faulty or
         disabled.
Whereas very early shifted from cooperation to aggression and competition. I don't even really know how the fights started. i first observed it in the intensive and extensive efforts to derail any clone/alt-coins. It then shifted more intensely into internal infighting by derailing any possibility of alternative implementations or even relatively trivial and not externally visible changes like supporting alternate database engines.

Bitcoin is a fine example of "live by the sword, die by the sword".
20  Bitcoin / Hardware / Re: Antminer S7, S9 Rackmount Shelf on: June 01, 2017, 02:53:30 AM
I am just wondering if this company is legit because i have sent numerous emails and before spending over 6 grand with them on mining racks i would like to know there is a great guarantee that it will be delivered...
Are you nuts? Or are you under influence of some substance? Why are you sending private messages to me?
Hi I have tried sending multiple messages to your miningrigs.net email for sales but have never gotten a response..  I need to buy at least 10 grand in mining racks for the s9 but I dont even know if this company is real or not but just wanted to check, thank you so much.
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 ... 105 »
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!