Well this seems to be some bad news: http://msdn.microsoft.com/en-us/library/1kt27hek(v=vs.80).aspxWrite formatted output using a pointer to a list of arguments. These functions are deprecated because more secure versions are available; see vsnprintf_s, _vsnprintf_s, _vsnprintf_s_l, _vsnwprintf_s, _vsnwprintf_s_l. Apperently bitcoin is using "unsecure" (less secure) routine versions !   Maybe it's a little problem which can be quickly corrected, ofcourse I am not sure yet. The link goes on about preventing "buffer overruns" lol =DDDDD |
|
|
|
Something goes wrong in this function of bitcoin: nFile parameter is 1 nBlockPas parameter is 786228988 pszMode parameter is 0x01d9ea2c pointer to "rb" file variable is uninitialized and/or contains garbage and/or it's it's location: 0xcccccccc which seems to match the values in the exception... FILE* OpenBlockFile(unsigned int nFile, unsigned int nBlockPos, const char* pszMode) { if (nFile == -1) return NULL; // *** Begin of CRASH *** FILE* file = fopen(strprintf("%s/blk%04d.dat", GetDataDir().c_str(), nFile).c_str(), pszMode); // *** End of CRASH *** if (!file) return NULL; if (nBlockPos != 0 && !strchr(pszMode, 'a') && !strchr(pszMode, 'w')) { if (fseek(file, nBlockPos, SEEK_SET) != 0) { fclose(file); return NULL; } } return file; } strprintf looks a bit suspicious to me, it's routine is: util.cpp a bitcoin file: string strprintf(const std::string &format, ...) { char buffer[50000]; char* p = buffer; int limit = sizeof(buffer); int ret; loop { va_list arg_ptr; va_start(arg_ptr, format); ret = _vsnprintf(p, limit, format.c_str(), arg_ptr); va_end(arg_ptr); if (ret >= 0 && ret < limit) break; if (p != buffer) delete[] p; limit *= 2; p = new char[limit]; if (p == NULL) throw std::bad_alloc(); } string str(p, p+ret); if (p != buffer) delete[] p; return str; } Confirmed, there appears to a bug in this routine, not yet sure what the exact bug is but it's too funny ! =D I suspect this string printing function is trying to scan some input strings in ... or perhaps it's trying to make sense of the format specifier. Whatever the case may be it's first parameter is: format = "%s/blk%04d.dat" ^ this looks a bit suspicious, perhaps the function is getting confused hmm.. Perhaps it's not a problem with the bitcoin function. I kinda suspected that already, since it must compile and build and work properly otherwise bitcoin could never work So my first suspicion that this is indeed a microsoft problem appears to be true, the problem is with this function call: ret = _vsnprintf(p, limit, format.c_str(), arg_ptr); which seems to be some Microsoft function, I am not yet sure, if this is indeed a microsoft function. I am also not yet sure if the parameters passed are valid or wrong, perhaps in a wrong format. But let's suppose for a moment that it is valid, then this is pretty hilarius that would mean Microsoft has big fat bug in their poop But format.c_str() looks very suspicious to me. It's probably returning an AnsiString ? And perhaps vsn expects a unicode string ?!? And thus something screw up... hmmm.... It not seems to be getting hard to debug this further: Not yet sure what this is and if it can be stepped into further: stdio.h: #pragma warning(disable:4793) __DEFINE_CPP_OVERLOAD_STANDARD_NFUNC_0_2_ARGLIST_EX(int, __RETURN_POLICY_SAME, _CRTIMP, _snprintf, _vsnprintf, _Pre_notnull_ _Post_maybez_ char, _Out_cap_(_Count) _Post_maybez_, char, _Dest, _In_ size_t, _Count, _In_z_ _Printf_format_string_ const char *, _Format) ^ stdio.h is used a lot, so this could be major bug, or perhaps wrong parameters as described above... interesting... |
|
|
|
|
As I thought it happens again, kinda weird:
Bitcoin version -858993460.-858993460.-858993460.-858993460-beta
Default data directory C:\Users\Skybuck\AppData\Roaming\Bitcoin
Bound to port 8333
Loading addresses...
dbenv.open strLogDir=C:\Users\Skybuck\AppData\Roaming\Bitcoin/database strErrorF
ile=C:\Users\Skybuck\AppData\Roaming\Bitcoin/db.log
Loaded 88254 addresses
addresses 45876ms
Loading block index...
Unhandled exception at 0x5e0313af (msvcr100d.dll) in BitcoinDatabaseExporter.exe: 0xC0000005: Access violation reading location 0xcccccccc.
Hmmm...
|
|
|
|
I see it has a hidden option: fPrintToConsole = GetBoolArg("-printtoconsole"); I shall try and use that |
|
|
|
|
Maybe this dll got linked because I added:
#ifdef _MSC_VER
#include "stdafx.h"
I thought maybe stdafx.h is needed to make console work.
I shall remove it again, and see if the exception happens again... there's probably something in there which is causing exceptions even without this include.
Gonna be interesting...
|
|
|
|
Hello, This is a bit strange: This code seems to produce an unhandled exception when trying to load the block database: output.c: #else /* _UNICODE */ if (flags & (FL_LONG|FL_WIDECHAR)) { if (text.wz == NULL) /* NULL passed, use special string */ text.wz = __wnullstring; bufferiswide = 1; pwch = text.wz; while ( i-- && *pwch ) ++pwch; textlen = (int)(pwch - text.wz); /* textlen now contains length in wide chars */ } else { if (text.sz == NULL) /* NULL passed, use special string */ text.sz = __nullstring; p = text.sz; while (i-- && *p) ++p; // Skybuck: problem is here. textlen = (int)(p - text.sz); /* length of the string */ } #endif /* _UNICODE */ This could be a buffer overrun in some kind of ms*.dll file... Pretty scary ! =D More details: Unhandled exception at 0x5db313af (msvcr100d.dll) in BitcoinDatabaseExporter.exe: 0xC0000005: Access violation reading location 0xcccccccc. (BitcoinDatabaseExporter.exe is actually just bitcoind.exe) hmm... |
|
|
|
|
Hello,
I am trying to debug bitcoin 0.5 but nothing is being printed to screen ?
Is this perhaps bug, or is printf re-directed to something else ?
If so can I somehow redirect it to screen ?
(Visual Studio 2010)
Bye,
Skybuck.
|
|
|
|
Wow, I just succeeded in building the bitcoin console client, I simply commented out my database exporter test code, and simply build bitcoin file by file until all files where found. And now that I know how to link libraries the linking problems have been solved, which is pretty cool. The linking problems were solved as follows: These three dependencies must be added in the options as previously described: libdb48d.lib libboost_thread-vc100-mt-gd-1_48.lib libeay32.lib And their folders must be added to as previously described. Now it builds and runs... vs2010 was even nice enough to copy the necessary dll's to the output folder ?!? Hmmm the console program just seemed to crash... interesting. I had to solve one little bug: add int pid_t. Ok, now I go debug it... Maybe later I post some warnings from the c/c++ compiler ! |
|
|
|
Ok, Now I am slowly getting somewhere. This website/page explains how to get the linking working in VS 2010: http://www.steptools.com/support/stdev_docs/help/settings_vc10.htmlIt involves 3 steps: 1. Adding the include folder to "additional include folders" under c/c++ options (general). 2. Adding the library file name to "additional depedencies" under linker options (input). 3. Adding the library path to the "additional library directories" under linker options (general). 1>------ Build started: Project: BitcoinDatabaseExporter, Configuration: Debug Win32 ------
1>Build started 12/13/2011 5:09:45.
1>InitializeBuildStatus:
1> Creating "Debug\BitcoinDatabaseExporter.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> BitcoinDatabaseExporter.cpp
1>ManifestResourceCompile:
1> All outputs are up-to-date.
1>Manifest:
1> All outputs are up-to-date.
1>LinkEmbedManifest:
1> All outputs are up-to-date.
1> BitcoinDatabaseExporter.vcxproj -> U:\SkycoinSourceCode\Applications\BitcoinDatabaseExporter\version-0.02\BitcoinDatabaseExporter\Debug\BitcoinDatabaseExporter.exe
1>FinalizeBuildStatus:
1> Deleting file "Debug\BitcoinDatabaseExporter.unsuccessfulbuild".
1> Touching "Debug\BitcoinDatabaseExporter.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:01.59
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
First for step 2 I tried with the static version which is 4 MB but this didn't work: libdb_stl48sd.lib I don't know why the static version did not work, maybe I should recompile it since I copied it from some other drive. Anyway then I tried the dynamic version which is: libdb48d.lib There are also other file names ending on *.lib, but this one seems most likely to me ?!? How the frack am I to know which LIB to include  ? Just guessing here... Now it will need libdb48d.dll to actually run/work... I just copied the dll to the app folder and run a debug session, this happens, so far it seems to work, but it cannot yet find all needed debug files... hmm, maybe I should set another path somewhere so it can find all these files better: 'BitcoinDatabaseExporter.exe': Loaded 'U:\SkycoinSourceCode\Applications\BitcoinDatabaseExporter\version-0.02\BitcoinDatabaseExporter\Debug\BitcoinDatabaseExporter.exe', Symbols loaded. 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'U:\SkycoinSourceCode\Applications\BitcoinDatabaseExporter\version-0.02\BitcoinDatabaseExporter\Debug\libdb48d.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\ws2_32.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\nsi.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded. 'BitcoinDatabaseExporter.exe': Loaded 'C:\Windows\SysWOW64\msvcp100d.dll', Symbols loaded. The program '[4896] BitcoinDatabaseExporter.exe: Native' has exited with code 0 (0x0). |
|
|
|
|
Apperently Visual Studio 2010 has a MSBuild utility which might be able to use makefile.vc, I tried it, this is the result:
"
U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src>msbuild makefile.vc
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.239]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 12/13/2011 4:52:22.
Project "U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src\makefile.vc
" on node 1 (default targets).
U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src\makefile.vc(1,1): er
ror MSB4025: The project file could not be loaded. Data at the root level is in
valid. Line 1, position 1.
Done Building Project "U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\s
rc\makefile.vc" (default targets) -- FAILED.
Build FAILED.
"U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src\makefile.vc" (defau
lt target) (1) ->
U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src\makefile.vc(1,1):
error MSB4025: The project file could not be loaded. Data at the root level is
invalid. Line 1, position 1.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.34
U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src>
"
Maybe I need to specify target or so ?
|
|
|
|
Microsoft sux bad, they cannot even explain/describe the most basic action of adding a static library to a project: Simple berkeley db test program: // BitcoinDatabaseExporter.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "db_cxx.h"
#define DATABASE "access.db"
int _tmain(int argc, _TCHAR* argv[])
{
DB *dbp;
int ret;
ret = db_create(&dbp, NULL, 0);
if (ret != 0)
{
fprintf(stderr, "db_create: %s\n", db_strerror(ret));
exit (1);
}
ret = dbp->open(dbp, NULL, DATABASE, NULL, DB_BTREE, DB_CREATE, 0664);
if (ret != 0)
{
dbp->err(dbp, ret, "%s", DATABASE);
}
return 0;
}
I try following this little tutorial, it don't work (the references dialog displays nothing ?!?): http://msdn.microsoft.com/en-us/library/ms235627.aspx" To create a console application that references the static library 1. To create an application that will reference and use the static library that was just created, from the File menu, select New and then Project. 2. On the Project types pane, under Visual C++, select Win32. 3. On the Templates pane, select Win32 Console Application. 4. Choose a name for the project, such as MyExecRefsLib, and type it in the Name field. Next to Solution, select Add to Solution from the drop-down list box. This will add the new project to the same solution as the static library. 5. Click OK to start the Win32 Application Wizard. On the Overview page of the Win32 Application Wizard dialog box, click Next. 6. On the Application Settings page of the Win32 Application Wizard, under Application type, select Console application. 7. On the Application Settings page of the Win32 Application Wizard, under Additional options, clear Precompiled header. 8. Click Finish to create the project. To use the functionality from the static library in the application 1. After you create a console application, the wizard creates an empty program for you. The name for the source file will be the same as the name that you chose for the project earlier. In this example, it is named MyExecRefsLib.cpp. 2. You must reference the static library you created to use its math routines. To do this, select References from the Project menu. From the MyExecRefsLib Property Pages dialog box, expand the Common Properties node and then click Add New Reference. For more information about the References dialog box, see Framework and References, Common Properties, <Projectname> Property Pages Dialog Box. 3. The Add Reference dialog box is displayed. The Projects tab lists the projects in the current solution and any libraries that you can reference. On the Projects tab, select MathFuncsLib. Click OK. 4. To reference the MathFuncsLib.h header file, you must modify the include directories path. In the MyExecRefsLib Property Pages dialog box, expand the Configuration Properties node, expand the C/C++ node, and then select General. In the Additional Include Directories property value, type the path of the MathFuncsLib directory or browse for it. To browse for the directory path, in the property value drop-down list box, click Edit. In the Additional Include Directories dialog box, in the text box, select a blank line and then click the ellipsis button (…) at the end of the line. In the Select Directory dialog box, select the MathFuncsLib directory and then click Select Folder to save your selection and close the dialog box. In the Additional Include Directories dialog box, click OK. 5. You can now use the MyMathFuncs class in this application. To do this, replace the contents of MyExecRefsLib.cpp with the following code. Copy // MyExecRefsLib.cpp // compile with: /EHsc /link MathFuncsLib.lib #include <iostream> #include "MathFuncsLib.h" using namespace std; int main() { double a = 7.4; int b = 99; cout << "a + b = " << MathFuncs::MyMathFuncs::Add(a, b) << endl; cout << "a - b = " << MathFuncs::MyMathFuncs::Subtract(a, b) << endl; cout << "a * b = " << MathFuncs::MyMathFuncs::Multiply(a, b) << endl; cout << "a / b = " << MathFuncs::MyMathFuncs::Divide(a, b) << endl; return 0; } 6. Build the executable by selecting Build Solution from the Build menu. " |
|
|
|
|
How compatibile are Berkley DB files with different versions of itself ?
For example:
Are all Berkeley DB 4.x file versions compatible with each other ?
Or is for example Berkeley DB 4.8.30 only compatible with it's own version 4.80.30 ?
So for example could Berkeley DB 4.05.20 access 4.80.30 files ??
|
|
|
|
|
Perhaps little change is needed to implement it, I am not sure...
Bitcoin/transactions/blocks seem to have these "operation codes".
Perhaps a "duplex link" operation code could be introduced which links transactions to each other. (dual link).
Which means the transaction is only accepted if it's counter-transaction is also in the same block.
Perhaps this concept could even be extended to "multi link".
All transactions linked together need to be in the same block for them to occur/be accepted by the network, otherwise they are rejected.
|
|
|
|
|
Hello,
Mixing bitcoins in a hopefully sufficient way could be done as follows:
The bitcoin client subtracts small ammounts of money/bitcoins from it's own bitcoin addresses.
These are then sent into some uncompleted transactions to other bitcoin clients.
Those other bitcoin clients will complete the transaction but receiving those small ammount of bitcoins and sending them back and re-encoding them with their own bitcoin addresses.
Preferably also mixing bitcoins which they received from as many other clients/bit coin addresses as possible.
The only rule is that the input and the output cannot come from the same bitcoin address, therefore money cannot be send back directly, so there is no direct link.
This way the entire bitcoin network starts to mix small ammounts of bitcoins/money, so that it becomes practically untraceable.
There would be so many links/paths/transactions to follow that it makes no sense for super computer to analyze.
An example of how a certain ammount of money is mixed:
BitCoinAddressA has 100 bitcoins.
BitCoinAddressA splits this up into 10000 transactions over time with empty destination addresses, these are broadcasted to the network.
BitCoinAddress0 to 9999 pickup these empty transactions and put their own BitCoinAddress0 to 9999 into it.
BitCoinAddress0 to 9999 create a new transaction where they transfer money/bitcoins for the same ammount from BitCoinAddress0 to 9999 back to BitCoinAddressA in such a way that the bitcoins that were selected for this transfer did not originate from any BitCoinAddress owned by BitCoinAddress0 to 9999 to prevent local cycles. This ensures more mixing from BitCoinAddresses which served as true inputs from outside the client.
To add to the mix, the bitcoins which will be selected should be as many as possible and subtract small ammounts from their bitcoin addresses where they received money on, not originating from BitCoinAddressA.
There is some potential for small cyclic links to occur in the order of 2 or 3 indirect links, however ultimately as more clients perform this behaviour the mixing will become longer and better and deeper.
This leaves the problem of making sure that BitCoinAddressA gets a transfer back for his splitted up money.
They way this could work is as follows:
The bitcoin client which offered the mixing services sends back the completed transaction to BitCoinAddressA plus the transaction which transfers the money back to BitCoinAddressA.
I think it's pretty clear that that bitcoin client technology needs a new form of transaction to facilitate this behaviour.
These transactions could be called "duplex transactions" where a money transfer can only occur if the same ammount of money flows in both directions but from different addresses as to mix it.
The duplex transaction is only accepted by the network if both keys from A and the helper are used to sign it.
These duplex transactions will need to be something special and cannot consist out of 2 normal transactions, since one of them could betray the other and not come through with one of the transactions.
So the duplex transaction prevent that from occuring, it's an all or nothing deal, both direction transfers happen or not at all.
Introducing a duplex transaction makes following/analyzing mixing a bit more easy, but because of the design above this will be futile, the transactions are so small, and so many that ultimately it becomes more like water, it's totally mixed after a while, this mixing could continue endlessly.
Currently some estimate: 100.000 bitcoin clients, mixing 10.000 transactions over time, perhaps some weeks or months, is 1.000.000.000 mixes per weeks or months.
This is not a large number for a super computer, however the mixing is so intense that no logic can probably make sense of it, as bitcoin becomes more populair this mixing will intensivy.
The drawback is that the blockchain's size will grow even faster. This could be a positive thing, this will also force a balance sheet approach/solution to be used, which might be somewhat more efficient.
By expanding/growing/inflating the blockchain at such a rapid paste it could become unfeasible even for a super computer to store it, or to keep track of information. So there is some interesting value in expending the size of the block chain as fast as possible.
Bye,
Skybuck.
|
|
|
|
It's hard to tell how the protocol works exactly.
The best thing to do is to go read the software. It's the true specification: It's in a (mostly) precise, meaningful, mathematical language— and should it differ from any prose description then it's the one that wins. Skill in code reading varies, but I think the bitcoin 'official client' code is fairly clear. Yeah some parts of the protocol are easy to understand, strangely enough it's the database reading/writing which still mystifies me. However when it comes to the checksum these kind of things also scare me off a little bit: From main.cpp: // Checksum
if (vRecv.GetVersion() >= 209)
{
uint256 hash = Hash(vRecv.begin(), vRecv.begin() + nMessageSize);
What the hell does vRecv.begin() do ? One has to be a boost "expert" to understand that Is that some kind of pointer ? And why does it need to know the beginning of a message ? It's probably something stream related Still by looking at the code it's not immediately apperent that this is the overal message structure, at least the message structure between clients it seems. "ProcessMessages" is it's routine. This could mean anything... is this "process irc messages" ? is this "client messages", is this something special like "block messages". IRC uses it's own protocol and also uses messages, even TCP could be considered messages, though usually considered "streams" (or segments). Then there is http ? And perhaps even other stuff I don't know about and could be in there... for all I know the database could be communicating with "messages" Even windows communicates with "messages" =D Strange but true. Ofcourse from viewing it it does seem to have something to do with some kind of communication protocol. With some help from the docs, the code, and you guys on the forum, it's starting to make some sense Also sometimes the filename helps, irc.cpp and irc.h is pretty obvious ! =D |
|
|
|
This is the reason why bittorrent uses sha hashes to protect the segments against bit errors or malicious bit errors. So this is a good question: How does bitcoin protect against bit errors, or malicious bit errors ? Is there a hash which is calculated over the entire block ? Meaning every bit Why don't you spend some time reading up on it instead of wasting everyone's time with weakly informed theories? The protocol is protected, and the individual blocks are hashed and just dropped if the hash doesn't have the required form. This works on a block by block basis and is complimented for older blocks where malicious changes might be possible with periodic checkpoints. It's hard to tell how the protocol works exactly. However you seem to hint at this section: https://en.bitcoin.it/wiki/Protocol_specificationIt contains a message structure under title "common structures". Assuming all messages use that structure then the protocol would be protected with a sha hash which is good, one problem less to worry about though there could be exceptions ? It would help if the protocol specification would contain some diagrams/lines/arrows to visually show how the fields link into other structures. Now it's slowly starting to make sense to me at least |
|
|
|
This problem could much more easily be solved- without Bittorrent or repositories- simply by downloading blocks in a round-robin fashion through different connections.
Suppose Connection 1 is painfully slow.
The client would use connection 1 to transfer block 1. Connection 2, block 2 and so on.
(assume 8 connections)
The first connection to finish downloading a block would download block 9, the next block 10, and so on. To process blocks, you need them in order so you still would be waiting on an earlier block (like block 1 in this case). If 50 blocks are downloaded and stored (blocks 2 through 51 in this case) while still waiting on a prior block to download, further downloads are paused. If the data transfer speed of this connection is less than 10% of the average of all connections, then the transfer is abandoned and the block is re-requested through another connection.
This solution
* is secure
* is decentralized
* does not require us to implement bittorrent.
* prevents malicious slow connections from having any impact
* is tolerant of the occasional enormous block even if it happens to come through the slow connection
-Atheros
This is not enough, even the current implementation of bitcoin could be vunerable to bit errors. I am not sure if bitcoin adds extra integrity checking on top of tcp. Just tcp alone is not enough to transfer data intact over dialups. I have seen dialups introduce bit errors which were not detected in udp protocols, I would expect the same to happen in tcp, since it uses the same error checking, which is very weak: summations only. Ethernet is a different matter since it has crc32 build in, even crc32 is not enough to protect against all bit errors, this does not even go into the issue of malicious bit errors. This is the reason why bittorrent uses sha hashes to protect the segments against bit errors or malicious bit errors. So this is a good question: How does bitcoin protect against bit errors, or malicious bit errors ? Is there a hash which is calculated over the entire block ? Meaning every bit I am not completely sure but I think bitcoin does this with the block hashes, and the block chain... If so then it's clear that processing can only be done after all blocks from the genesis block have been downloaded and check etc... I think the merkle hash tree idea for downloading which I mentioned was to allow the blocks to be verified, even if not all of them or even if the genesis block has not been downloaded yet. So the merkle hash tree idea could be used for out-of-order block verification which could then also allow the client to immediatly upload to others... But indeed this idea would be much more complex then simple round robin... however the more complex idea could have performance advantages... The idea was to prevent a single connection from slowing things down. I think your solution to simply dump the connection and switch to another one, might be a more easilier solution, this solution does assume that all blocks can be ultimately downloaded from some kind of genesis block. However in the future perhaps the block chain will switch to something else like a ledger/balance sheet, perhaps some clients might be in different states... and then perhaps this round robin idea might start to fail if they are in different states, perhaps the tree idea could have some adventages here, since it can be more easily pruned... not sure though... |
|
|
|
Tried nmake this is what I get, I did fiddle a bit with the folder and files so not sure if that is the cause of it, I don't think so though: U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src>dir
Volume in drive U is SkycoinSourceCode
Volume Serial Number is 6CCF-6984
Directory of U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src
12/01/2011 18:27 <DIR> .
12/01/2011 18:27 <DIR> ..
11/20/2011 12:37 9,049 base58.h
11/20/2011 12:37 14,823 bignum.h
11/20/2011 12:37 87,674 bitcoinrpc.cpp
11/20/2011 12:37 310 bitcoinrpc.h
12/01/2011 18:28 <DIR> cpp-builder
11/20/2011 12:37 4,558 crypter.cpp
11/20/2011 12:37 3,177 crypter.h
11/20/2011 12:37 32,851 db.cpp
11/20/2011 12:37 12,648 db.h
11/20/2011 12:37 2,053 headers.h
11/20/2011 12:37 16,540 init.cpp
11/20/2011 12:37 425 init.h
11/20/2011 12:37 11,891 irc.cpp
11/20/2011 12:37 432 irc.h
11/20/2011 12:37 <DIR> json
11/20/2011 12:37 12,390 key.h
11/20/2011 12:37 5,273 keystore.cpp
11/20/2011 12:37 3,896 keystore.h
11/20/2011 12:37 102,840 main.cpp
11/20/2011 12:37 39,857 main.h
11/20/2011 12:37 2,317 makefile.linux-mingw
11/20/2011 12:37 2,233 makefile.mingw
11/20/2011 12:37 2,898 makefile.osx
11/20/2011 12:37 4,193 makefile.unix
11/20/2011 12:37 2,761 makefile.vc
11/20/2011 12:37 60,258 net.cpp
11/20/2011 12:37 19,131 net.h
11/20/2011 12:37 2,441 noui.h
11/20/2011 12:37 <DIR> obj
11/20/2011 12:37 8,063 protocol.cpp
11/20/2011 12:37 4,305 protocol.h
11/20/2011 12:37 <DIR> qt
11/20/2011 12:37 2,206 qtui.h
11/20/2011 12:37 39,360 script.cpp
11/20/2011 12:37 20,115 script.h
11/20/2011 12:37 45,358 serialize.h
11/20/2011 12:37 2,501 strlcpy.h
11/20/2011 12:37 <DIR> test
11/20/2011 12:37 24,788 uint256.h
11/20/2011 12:37 30,889 util.cpp
11/20/2011 12:37 19,768 util.h
11/20/2011 12:37 46,322 wallet.cpp
11/20/2011 12:37 18,489 wallet.h
38 File(s) 719,083 bytes
7 Dir(s) 6,157,841,408 bytes free
U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src>nmake /f makefile.vc
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1073: don't know how to make 'obj\nogui\crypter.o'
Stop.
U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src>
Hmm... |
|
|
|
Ok, lol, thanks for the hint, I try the make method sometime, for now, it's not working, wrong make called, as usual: U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src>make -f makefile.vc
MAKE Version 5.4 Copyright (c) 1987, 2010 Embarcadero Technologies, Inc.
Fatal: 'obj\nogui\crypter.o' does not exist - don't know how to make it
U:\SkycoinSourceCode\Applications\Skycoin\version-0.01\src>
^ Seems to call embarcadero thingy, instead it should use vc thingy... I did open a vc ms-dos prompt... I'll try and exclude embarcadero thingy from path and see if that helps As far as I can tell, vc perhaps doesn't have a make thingy... but it does have nmake thingy... have seen it before, so I'll try that |
|
|
|
|
Show Posts
