|
Thanks eurekafag, Russian translation added to SVN rev 160.
|
|
|
|
|
Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41.
|
|
|
|
|
You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.
IRC seems to be working. It ought to have other nodes to try.
There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.
You can try moving addr.dat aside. Maybe there's something wrong in it.
Are you using -addnode?
|
|
|
|
|
ShadowOfHarbringer, is yours faster with -4way?
If it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.
The specialbuild version I posted here looks for model 4 or higher. If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit.
|
|
|
|
Can you tell more about it:
"they have to do weird things with extraNonce, which increases the size of the block header".
When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception. This is the point of confusion. extraNonce is not part of the block header, it is part of the first transaction. It does not slow down your hashing. It does not change the size of the header. We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed. It doesn't. extraNonce never needs to be very big. We could reset it every second whenever the time changes if we wanted. Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible. Separate machines are automatically collision proof because they have different generated public keys in the first transaction. That also goes for each thread too. |
|
|
|
Applying this patch will make you incompatible with other Bitcoin clients.
+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment. We can phase in a change later if we get closer to needing it. |
|
|
|
ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm.
Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain. Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours. If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them. The person who originally sent the broken transactions deleted his wallet
Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet. It's running. Should find a block within 3 hours.
It may take a while to collect re-broadcast transactions. It'll help if you can accept inbound connections so you'll be listening to more nodes. Even if you find a block in 3 hours, keep it running continuously for a few days at least. |
|
|
|
diff -u old\main.cpp new\main.cpp
--- old\main.cpp Sun Oct 03 20:57:20 2010
+++ new\main.cpp Sun Oct 03 20:57:54 2010
@@ -2831,6 +2831,10 @@
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));
+ // AMD reports a lower model number in 64-bit mode
+ if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)
+ fUseSSE2 = true;
+
static bool fPrinted;
if (!fPrinted)
{
@@ -2989,6 +2993,17 @@
// Transaction fee based on block size
int64 nMinFee = tx.GetMinFee(nBlockSize);
+ //////// temporary code
+ if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings("statusbar") == "")
+ {
+ if (nBestHeight < 91000)
+ nMinFee = 0;
+ if (nBestHeight < 100000 && nTxSize < 2000)
+ nMinFee = 0;
+ if (nBestHeight < 110000 && nBestHeight % 10 == 0)
+ nMinFee = 0;
+ }
+ //////// temporary code
map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
diff -u old\serialize.h new\serialize.h
--- old\serialize.h Sun Oct 03 20:57:45 2010
+++ new\serialize.h Sun Oct 03 20:57:54 2010
@@ -22,8 +22,8 @@
class CAutoFile;
static const unsigned int MAX_SIZE = 0x02000000;
-static const int VERSION = 31300;
-static const char* pszSubVer = "";
+static const int VERSION = 31301;
+static const char* pszSubVer = " test1";
|
|
|
|
983 Mhash/s box.
Seriously? What hardware is that? |
|
|
|
Could a few people please run this special build? It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now. We really just need one block letting them through to clear up the previous transactions. Post if you generate a block with this. These are binaries only. The linux version is 64-bit only. http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gzSHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz The linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better. |
|
|
|
That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.
I still have to add the "-4way" switch.
Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode. Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have? Do all AMDs that support 64-bit have the better SSE2 hardware also? |
|
|
|
Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2. Changes: - Don't count or spend payments until they have 1 confirmation. - Internal version number from 312 to 31300. - Only accept transactions sent by IP address if -allowreceivebyip is specified. - Dropped DB_PRIVATE Berkeley DB flag. - Fix problem sending the last cent with sub-cent fractional change. - Auto-detect whether to use 128-bit 4-way SSE2 on Linux. Gavin Andresen: - Option -rpcallowip= to accept json-rpc connections from another machine. - Clean shutdown on SIGTERM on Linux. Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/(Thanks Laszlo for the Mac OSX build!) Note: The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right: http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gzYou can still control the SSE2 use manually with -4way and -4way=0. Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it: http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe |
|
|
|
|
Too late for 0.3.13, but I'll try to find time to add it to the next version.
|
|
|
|
|
True, the switch should be something more dynamic that pays per KB. It's harder to think of how to explain it.
|
|
|
|
|
It ramps up the fee requirement as the block fills up:
<50KB free
50KB 0.01
250KB 0.02
333KB 0.03
375KB 0.04
etc.
It's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers.
Just including the minimum 0.01 goes a long way.
|
|
|
|
|
If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is.
I wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of.
The article could be as simple as something like:
"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/."
The more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is.
|
|
|
|
0.3.13 release candidate, to be released soon so please test: http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe- don't count or spend payments until they have 1 confirmation http://bitcointalk.org/index.php?topic=1306.0- internal version number from 312 to 31300 - only accept transactions sent by IP address if -allowreceivebyip is specified - dropped DB_PRIVATE Berkeley DB flag - fix problem sending the last cent with sub-cent fractional change - auto-detect whether to use 128-bit 4-way SSE2 on Linux Gavin Andresen: - option -rpcallowip= to accept json-rpc connections from another machine - clean shutdown on SIGTERM on Linux |
|
|
|
|
As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.
I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending. This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.
I didn't make it (+1.23) because parenthesis in accounting means negative. I hope square brackets is different enough to be clear what is meant.
The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.
I uploaded the changes to SVN rev 158. I will post a 0.3.13 RC shortly.
If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.
If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.
change:
if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)
continue;
to:
if (pcoin->GetDepthInMainChain() < 1)
continue;
|
|
|
|
|
Show Posts
