2010-08-11 22:40:25 UTC - Original Post

It doesn't have to be such a breaking change. New nodes could accept old
transactions for a long time until most nodes have already upgraded before starting
to refuse transactions without PoW. Or, they could always accept old
transactions, but only a limited number per time period.I've thought about PoW on
transactions many times, but usually I end up thinking a 0.01 transaction fee is
essentially similar and better. 0.01 is basically a proof of work, but not
wasted. But if the problem is validating loads of transactions, then PoW could be
checked faster.A more general umbrella partial solution would be to implement the
idea where an unlikely dropoff in blocks received is detected. Then an attacker
would still need a substantial portion of the network's power to benefit from a DoS
attack.Quote from: gavinandresen on August 11, 2010, 04:10:56 PMBitcoin's p2p
network is subject to various kinds of denial of service attacks.There, I said it.
+1Any demonstration tests at this point would only show what we already know, and
divert dev time from strengthening the system to operational fire fighting./nRe:
Flood attack 0.00000001 BC

Bitcointalk

2010-08-11 23:28:50 UTC - Original Post

It would be nice to keep the blk*.dat files small as long as we can.The eventual
solution will be to not care how big it gets.But for now, while it's still small,
it's nice to keep it small so new users can get going faster. When I eventually
implement client-only mode, that won't matter much anymore.There's more work to do
on transaction fees. In the event of a flood, you would still be able to jump the
queue and get your transactions into the next block by paying a 0.01 transaction
fee. However, I haven't had time yet to add that option to the UI.Scale or not,
the test network will react in the same ways, but with much less wasted bandwidth
and annoyance./nRe: BSD detection

Bitcointalk

2010-08-12 00:02:06 UTC - Original Post

Quote from: dkaparis on August 11, 2010, 11:00:16 PMThere is this piece of code
in headers.h:#ifdef __WXMAC_OSX__#define __WXMAC__ 1#define __WXOSX__ 1#define
__BSD__ 1#endif#endifThat code was a bad idea anyway, I'm deleting it. Any Mac
code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop
using __BSD__.Quote#if (defined(__unix__) || defined(unix)) && !
defined(USG)#include <sys/param.h>#endifWill that definitely cause BSD to be
defined on Mac?/nRe: Not a suggestion

Bitcointalk

2010-08-12 02:46:56 UTC - Original Post

Quote from: Red on August 12, 2010, 01:10:19 AMQuote from: satoshi on August 11,
2010, 09:07:59 PMI believe the clients would have to keep the entire history back
to the original generated coins. Â The fact that clients have to keep the entire
history reduces the privacy benefit. Â I thought this too at first. But then I
convinced myself otherwise.Are you back to talking about the existing Bitcoin
system here?I was talking about in the hypothetical system I was describing, if the
network doesn't know the values and lineage of the transactions, then it can't
verify them and vouch for them, so the clients would have to keep the history all
the way back.If a client wasn't present until recently, the two ways to convince it
that a transaction has a valid past is:1) Show it the entire history back to the
original generated coin.2) Show it a history back to a thoroughly deep block, then
trust that if so many nodes all said the history up to then was correct then it
must be true.But if the network didn't know all the values and lineage of the
transactions, it couldn't do 2), I don't think./nRe: BSD detection
 Bitcointalk

2010-08-12 21:14:20 UTC - Original Post

This is in SVN rev 130. Â Check that it compiles right.Code:#if
(defined(__unix__) || defined(unix)) && !defined(USG)#include <sys/param.h> Â // to
get BSD define#endif#ifdef __WXMAC_OSX__#ifndef BSD#define BSD
1#endif#endif/nBugfixes in SVN rev 130

Bitcointalk

2010-08-12 21:20:31 UTC - Original Post

Misc bugfixes in rev 130:fix -datadir with relative pathautostart is now off by
default except on windowsfix occasional "vector iterator not dereferencable"
assertion when compiled with msvcfix readlink compile warning on linux builduse
sys/param.h and BSD define instead of __BSD__-paytxfee switch, e.g. -
paytxfee=0.01/nRe: Bitcoin Watchdog Service

Bitcointalk

2010-08-12 21:34:44 UTC - Original Post

True, there would probably be someone with a dial-up modem or satellite dish
internet. Rarer would be someone who has both that and the wired internet that
has the outage, but if it's a big enough segment to matter, out of a million people
there's bound to be a multi-home geek.ISP network cuts are just your local area.
 If you still have communication with the rest of your area, it would probably be
something like 1/1000 of the world or less. Â Block generation in the segment would
take several hours per block.I favour the plan to monitor if the frequency of
blocks received drops too slow. Â That covers a large range of possibilities./nRe:
Payment server

Bitcointalk

2010-01-28 23:26:09 UTC - Original Post

That's the right way to do it as riX says. The software can generate a new
bitcoin address whenever you need one for each payment. "Please send X bc to
[single-use bitcoin address] to complete your order"Â When the server receives
that amount to the bitcoin address, that could trigger it to automatically fulfil
the order or e-mail the shop owner.Adding command line support is a high
priority. It's just a matter of getting the time to code it./nRe: Having problems
specifing -datadir

Bitcointalk

2010-08-12 21:43:29 UTC - Original Post

Fixed in SVN rev 130./nRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Bitcointalk

2010-08-12 22:07:23 UTC - Original Post

That big of a difference in speed, by a factor of 4 or 6, feels like it's likely
to be some quirky weak spot or instruction that the old chip is slow with. Â Unless
it's a touted feature of the i5 that they made SSE2 six times faster.A quick
summary:Xeon Quad     41% slowerCore 2 Duo     55% slowerCore 2 DuoÂ
   same (vess)Core 2 Quad    50% slowerCore i5       200%
faster (nelisky)Core i5      100% faster (vess)AMD Opteron   105%
fasteraceat64:My system went from ~7100 to ~4200.This particular system has dual
Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.impossible7:on an Intel Core 2 Duo
T7300 running x86_64 linux it was 55% slower compared to the stock version
(r121)nelisky:My Core2Quad (Q6600) slowed down 50%, my i5 improved ~200%,
impossible7:on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement
(!)/nRe: Bugfixes in SVN rev 130

Bitcointalk

2010-08-13 03:15:23 UTC - Original Post

No, that's not what it is.-paytxfee allows you to include a transaction fee with
your transactions. Â If transaction confirmations become slow, you can get priority
by using "-paytxfee=0.01". Â Any transactions you send would cost an extra 0.01.
 There's no reason to use more than 0.01.It's just there in case we need it.  It
probably won't be needed, and it can be explained more if we do./nRe: Bitcoin
Watchdog Service

Bitcointalk

2010-08-13 17:09:27 UTC - Original Post

QuoteBut there will be no irc server to bootstrap from.Which doesn't matter
because you can't access sourceforge to download the software either.If you've ever
been connected before, you don't need IRC to bootstrap anymore. Â Even if you
haven't, you can bootstrap from seed nodes. Â IRC is completely redundant since
0.3.0./nVersion 0.3.9 rc1, please test

Bitcointalk

2010-08-13 17:40:00 UTC - Original Post

Here's a test build if you'd like to help test before 0.3.9 is released.(or if
you'd rather get upgrading out of the way now instead of waiting)Downloads:
 (binaries only)http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-
win32.zip(http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz)SHA1
a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zipSHA1
bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gzEdit:Linux
please test rc2 instead. This adds a -4way switch for tcatm's 4-way SSE2. This
will only be for Linux:http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-
linux.tar.gzSHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-
linux.tar.gzPlease report back your resultshttp://bitcointalk.org/index.php?
topic=820/nRe: Not a suggestion

Bitcointalk

2010-08-13 19:28:47 UTC - Original Post

I'm not grasping your idea yet. Does it hide any information from the public
network? What is the advantage?If at least 50% of nodes validated transactions
enough that old transactions can be discarded, then everyone saw everything and
could keep a record of it.Can public nodes see the values of transactions? Can
they see which previous transaction the value came from? If they can, then they
know everything. If they can't, then they couldn't verify that the value came
from a valid source, so you couldn't take their generated chain as verification of
it.Does it hide the bitcoin addresses? Is that it? OK, maybe now I see, if
that's it.Crypto may offer a way to do "key blinding". I did some research and it
was obscure, but there may be something there. "group signatures" may be
related.There's something here in the general
area:http://www.users.zetnet.co.uk/hopwood/crypto/rh/What we need is a way to
generate additional blinded variations of a public key. The blinded variations
would have the same properties as the root public key, such that the private key
could generate a signature for any one of them. Others could not tell if a
blinded key is related to the root key, or other blinded keys from the same root
key. These are the properties of blinding. Blinding, in a nutshell, is x = (x *
large_random_int) mod m.When paying to a bitcoin address, you would generate a new
blinded key for each use.Then you need to be able to sign a signature such that you
can't tell that two signatures came from the same private key. I'm not sure if
always signing a different blinded public key would already give you this
property. If not, I think that's where group signatures comes in. With group
signatures, it is possible for something to be signed but not know who signed it.As
an example, say some unpopular military attack has to be ordered, but nobody wants
to go down in history as the one who ordered it. If 10 leaders have private keys,
one of them could sign the order and you wouldn't know who did it./nRe: Proposed
change to sendtoaddress API call

Bitcointalk

2010-08-13 23:39:14 UTC - Original Post

It's too soon to start junking up the API for backward compatibility at all
costs.Just return "<txid>"./nRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Bitcointalk

2010-08-14 00:49:18 UTC - Original Post

MinGW on Windows has trouble compiling it:g++ -c -mthreads -O2 -w -Wno-invalid-
offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH
-I"/boost" -I"/db/build_unix" -I"/openssl/include" -I"/wxwidgets/lib/gcc_lib/mswud"
-I"/wxwidgets/include" -msse2 -O3 -o obj/sha256.o sha256.cppsha256.cpp: In function
`long long int __vector__ Ch(long long int __vector__, long long int __vector__,
long long int __vector__)':sha256.cpp:31: internal compiler error: in
perform_integral_promotions, at cp/typeck.c:1454Please submit a full bug
report,with preprocessed source if appropriate.See
<URL:http://www.mingw.org/bugs.shtml> for instructions.make: *** [obj/sha256.o]
Error 1/nRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Bitcointalk

2010-08-14 04:22:29 UTC - Original Post

If you haven't already, try aligning thash. Â It might matter. Â Couldn't
hurt.Quote from: tcatm on August 14, 2010, 12:53:07 AMLooks like we're triggering a
compiler bug in the tree optimizer. Can you try to compile it -O0?No help from -O0,
same error.MinGW is GCC 3.4.5. Probably the problem.I'll see if I can get a newer
version of MinGW./nRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Bitcointalk

2010-08-14 17:55:37 UTC - Original Post

Got the test working on 32-bit with MinGW GCC 4.5. Exactly 50% slower than
stock with Core 2./nRe: A newb's test - anyone want to buy a picture for $1?

Bitcointalk

2010-01-29 00:22:13 UTC - Original Post

The recommended ways to do a payment for an order:1) The merchant has a static
IP, the customer sends to it with a comment.2) The merchant creates a new bitcoin
address, gives it to the customer, the customer sends to that address. Â This will
be the standard way for website software to do it.RSA vs ECDSA: it's not the size
of the executable but the size of the data. Â I thought it would be impractical if
the block chain, bitcoin addresses, disk space and bandwidth requirements were all
an order of magnitude bigger. Â Also, even if using RSA for messages, it would
still make sense to do all the bitcoin network with ECDSA and use RSA in parallel
for only the message part. Â In that case, everything that's been implemented up to
now would be implemented exactly as it has been.We can figure out the best way to
do this much later. Â It could use a separate (maybe existing) e-mail or IM
infrastructure to pass messages, and instead of RSA, maybe just put a hash of the
message in the transaction to prove that the transaction is for the order described
in the message. Â The message would have to include a salt so nobody could brute
force the hash to reveal a short message./nRe: 4 hashes parallel on SSE2 CPUs for
0.3.6

Bitcointalk

2010-08-14 22:06:13 UTC - Original Post

MinGW GCC 4.5.0:Crypto++ doesn't work, X86_SHA256_HashBlocks() never returnsI
only got 4-way working with test.cpp but not when called by BitcoinMinerMinGW GCC
4.4.1:Crypto++ works4-way SIGSEGVGCC is definitely not aligning __m128i. Even if we
align our own __m128i variables, the compiler may decide to use a __m128i behind
the scenes as a temporary variable.By making our __m128i variables aligned and
changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0
only:#define Ch(b, c, d) Â ((b & c) ^ (~b & d))#define Maj(b, c, d) Â ((b & c) ^ (b
& d) ^ (c & d))#define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 -
n))#define SHR(x, n) Â _mm_srli_epi32(x, n)But that's with -O0./nRe: 4 hashes
parallel on SSE2 CPUs for 0.3.6

Bitcointalk

2010-08-15 03:40:29 UTC - Original Post

On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV
when called by BitcoinMiner. Â So now it doesn't look like it's the version of GCC,
it's something else, maybe just the luck of how the stack is aligned.I have it
working fine on GCC 4.3.3 on Ubuntu 32-bit.I found the problem with Crypto++ on
MinGW 4.5.0. Â Here's the patch for that:Code:--- \old\sha.cpp Mon Jul 26
13:31:11 2010+++ \new\sha.cpp Sat Aug 14 20:21:08 2010@@ -336,7 +336,7 @@Â
ROUND(14, 0, eax, ecx, edi, edx)Â ROUND(15, 0, ecx, eax, edx, edi)Â -
ASL(1)+ Â Â ASL(label1) Â // Bitcoin: fix for MinGW GCC 4.5Â AS2(add
WORD_REG(si), 4*16)Â ROUND(0, 1, eax, ecx, edi, edx)Â ROUND(1, 1, ecx, eax,
edx, edi)@@ -355,7 +355,7 @@Â ROUND(14, 1, eax, ecx, edi, edx)Â ROUND(15, 1,
ecx, eax, edx, edi)Â AS2( cmp WORD_REG(si), K_END)- ASJ( jne, 1, b)+
  ASJ(   jne,   label1,  )  // Bitcoin: fix for MinGW GCC 4.5 Â
AS2( mov WORD_REG(dx), DATA_SAVE)Â AS2( add
WORD_REG(dx), 64)/ntcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Bitcointalk

2010-08-15 15:52:09 UTC - Original Post

0.3.10 has tcatm's 4-way SSE2 as an option switch.Use the switch "-4way" to turn
it on. Â Without the switch you get Crypto++ ASM SHA-256.I could only get this
working with Linux.Download:Get 0.3.10 from http://bitcointalk.org/index.php?
topic=827.0Please report back your CPU and results! Â I think it's pretty clear
that Core 2 and lower are slower, i5 faster. Â I don't think we've heard any i7
results yet. Â We need to know about the different models of AMD or other less
common CPUs./nRe: Potential disaster scenario

Bitcointalk

2010-08-15 16:37:16 UTC - Original Post

Some places where generation will gravitate to:1) places where it's cheapest or
free2) people who want to help for idealogical reasons3) people who want to get
some coins without the inconvenience of doing a transaction to buy themThere are
legitimate places where it's free. Â Generation is basically free anywhere that has
electric heat, since your computer's heat is offsetting your baseboard electric
heating. Â Many small flats have electric heat out of convenience.How expensive is
heating oil? Â With the price of oil so high, if it's actually more expensive than
electric, then generating would have negative cost.There's also kids putting it on
their parent's power bill, employees their employer, botnets, etc.Case 3 comes into
play for small amounts. Â The overhead of doing an exchange doesn't make sense if
you just need a small bit of pocket change for incidental micropayments. Â I think
this is a nice advantage vs fiat currency, instead of all the seigniorage going to
one big entity, let it go in convenience amounts to people who need to scrape up a
small amount of change./nRe: Version 0.3.9 rc1, please test

Bitcointalk

2010-08-15 18:11:41 UTC - Original Post

Quote from: jgarzik on August 15, 2010, 05:46:27 PMthe extended-help might have
been based on my idea, but the code was somewhat different.The idea was the main
part. When you posted your patch, I realized it should have been done that way
instead of "-?". I always had reservations about "-?" because it intrudes on the
possible parameter values, and the help response is based on the version of the
caller instead of the server./nRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Bitcointalk

2010-08-15 18:23:26 UTC - Original Post

I hope someone can test an i5 or AMD to check that I built it right. I don't
have either to test with.I'm also curious if it performs much worse on 32-bit linux
vs 64-bit./nRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Bitcointalk

2010-08-15 18:43:27 UTC - Original Post

I just uploaded a quick build so testers can check if I built it right. (I
don't have an i5 or AMD)Â If it checks out, I'll put together the full package and
do all the release stuff./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-15 20:59:09 UTC - Original Post

Here's the preliminary change. Look right? I have more changes to make, this
isn't all of it. Will SVN shortly.Code:  bool CheckTransaction() const Â
{    // Basic checks that don't depend on any context    if
(vin.empty() || vout.empty())Â Â Â Â Â Â return
error("CTransaction::CheckTransaction() : vin or vout empty");Â Â Â Â // Check
for negative and overflow values    int64 nTotal = 0;   Â
foreach(const CTxOut& txout, vout)Â Â Â Â {Â Â Â Â Â Â if (txout.nValue <
0)Â Â Â Â Â Â Â Â return error("CTransaction::CheckTransaction() :
txout.nValue negative");Â Â Â Â Â Â if (txout.nValue > 21000000 * COIN)Â Â
      return error("CTransaction::CheckTransaction() : txout.nValue too
high");Â Â Â Â Â Â nTotal += txout.nValue;Â Â Â Â Â Â if (nTotal >
21000000 * COIN)Â Â Â Â Â Â Â Â return
error("CTransaction::CheckTransaction() : txout total too high");Â Â Â Â }Â Â
  if (IsCoinBase())    {      if (vin[0].scriptSig.size() <
2 || vin[0].scriptSig.size() > 100)Â Â Â Â Â Â Â Â return
error("CTransaction::CheckTransaction() : coinbase script size");Â Â Â Â }Â Â
  else    {      foreach(const CTxIn& txin, vin)   Â
    if (txin.prevout.IsNull())          return
error("CTransaction::CheckTransaction() : prevout is null");Â Â Â Â }Â Â Â
 return true;  }Don't sticky the topic, nobody looks up there. There'll be
enough posts to bump./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-15 21:06:45 UTC - Original Post

 It would help if people stop generating. We will probably need to re-do a
branch around the current one, and the less you generate the faster that will be.A
first patch will be in SVN rev 132. It's not uploaded yet. I'm pushing some
other misc changes out of the way first, then I'll upload the patch for this./nRe:
overflow bug SERIOUS

Bitcointalk

2010-08-15 21:23:55 UTC - Original Post

Once you have an update, you could download knightmb's block chain. Â You'll want
one that's old enough that it ends before block 74000 so the most recent security
lockin will check it.  Can someone find the link for that? /nRe: 64bit support

Bitcointalk

2010-01-29 00:42:49 UTC - Original Post

I committed a fix for 64-bit compile and some fixes to support wxWidgets
2.9.0.There was one compile error in serialize.h with min(sizeof()) that I fixed
for 64-bit. The rest of the 64-bit compile errors I was getting were in wxWidgets
2.8.9, so I started working on supporting wxWidgets 2.9.0.wxWidgets 2.9.0 is UTF-
8. We've been using the ANSI version of wxWidgets 2.8.9 in anticipation of
wxWidgets UTF-8 support.I compiled and ran on 64-bit Ubuntu 9.10 Karmic.I think the
only bug left is where the status number is mashed up. I'm not sure why, I have
to suspect it's a UTF-8 thing, but no idea how that could happen. Haven't looked
into it.build-unix.txt is updated and two makefiles on
SVN:makefile.unix.wx2.8makefile.unix.wx2.9Unfortunately there's still no debian
package for either version of wxWidgets we use. They only have the wchar
("unicode") version of wxWidgets 2.8, which is a disaster because wchar wxString
doesn't convert to std::string. We use either ANSI wxWidgets 2.8, or wxWidgets
2.9. So you still have to get it and build it yourself./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-15 21:40:19 UTC - Original Post

Patch is uploaded to SVN rev 132! For now, recommended steps:1) Shut down.2)
Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat
files)3) Upgrade.4) It should start out with less than 74000 blocks. Let it
redownload the rest.If you don't want to use knightmb's files, you could just
delete your blk*.dat files, but it's going to be a lot of load on the network if
everyone is downloading the whole block index at once.I'll build releases
shortly. /nRe: overflow bug SERIOUS

Bitcointalk

2010-08-15 22:58:08 UTC - Original Post

Don't update the block chain download. Â When you take someone's block chain
download, you don't want it right up to the end. Â A somewhat old one is better so
it can download and verify the most recent blocks.tcatm's 4-way SSE2 SHA-256 is in
the file sha256.cpp and already uploaded a few revs ago.I just now uploaded rev 134
which is the makefile.unix that enables building with it on Linux. Â If you build
rev 134 on Linux now you'll get the -4way switch.If you have problems building
because of it, then edit makefile.unix and:- remove -DFOURWAYSSE2- remove
obj/sha256.o from the end of these lines:bitcoin: $(OBJS) obj/ui.o obj/uibase.o
obj/sha256.obitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.oThe 0.3.10 linux build
will have the -4way option when I build it.Here are the patch downloads for
Windows:http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exehttp://
www.bitcoin.org/download/bitcoin-0.3.10-win32.zipSHA1
16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exeSHA1
4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zipSteps:1) Shut
down.2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat
files.http://knightmb.dyndns.org/files/bitcoin/blocks/http://rapidshare.com/files/
413168038/BitcoinBlocks.torrent3) Upgrade to 0.3.10.4) It should start out with
less than 74000 blocks and redownload the rest.Or if you don't want to mess with
downloading blk files, you can just do this:1) Shut down.2) Delete (or move)
blk*.dat3) Upgrade to 0.3.10.4) It redownloads all blocks, probably take about an
hour./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-15 23:17:24 UTC - Original Post

Quote from: knightmb on August 15, 2010, 10:59:04 PM[edit] Just saw your post,
I'll build one to less than 74,000 then, should at least save you technical people
a few minutes of downloading the new chain. Â Just leave the old one alone! Â Older
is better.  What block number is it?  Anywhere from 60000-74000 is good. The
one that you've had available for a while has been vetted and is the best
choice./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-15 23:36:10 UTC - Original Post

Starting at 67000 is perfect. Â Yeah, at the moment you'll stop at 74638. Â It
should start slowly creeping up as more nodes upgrade and generate.Linux build
links below.The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes
generating faster on i5 and AMD CPU's. Â Use the "-4way" switch to enable it and
check if it's faster for you.Download
links:http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exehttp://
www.bitcoin.org/download/bitcoin-0.3.10-win32.ziphttp://www.bitcoin.org/download/
bitcoin-0.3.10-linux.tar.gzSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-
0.3.10-win32-setup.exeSHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-
win32.zipSHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-
linux.tar.gz/nRe: overflow bug SERIOUS

Bitcointalk

2010-08-15 23:37:07 UTC - Original Post

Quote from: Joozero on August 15, 2010, 11:32:43 PMI think that you should add
something about this: http://bitcointalk.org/index.php?topic=259.0There must be a
label on the client that show a warning message if needed Now everyone have always
to check the website, and I think that this is bad.Agree, wanted to do that for a
long time, haven't had time to do it.For now, you could also subscribe to the
bitcoin-list mailing list. It rarely gets used except for announcements like this
and major new versions.Subscribe/unsubscribe
page:http://lists.sourceforge.net/mailman/listinfo/bitcoin-list/nVersion 0.3.10 -
block 74638 overflow PATCH!

Bitcointalk

2010-08-15 23:48:22 UTC - Original Post

Version 0.3.10 patches the block 74638 overflow bug. Â
http://bitcointalk.org/index.php?topic=823The Linux version includes tcatm's 4-way
SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD
CPU's. Â Try the "-4way" switch to enable it and check if it's faster for you.Â
Download from sourceforge:http://sourceforge.net/projects/bitcoin/files/Bitcoin/
bitcoin-0.3.10/SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-
setup.exeSHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zipSHA1
e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gzSHA1
b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zipIt is no longer
necessary to delete blk*.dat. The good block chain has overtaken the bad block
chain, so you can just upgrade and it'll automatically reorg away the bad block
chain./nRe: 0.3.10.1 Question on where block should be

Bitcointalk

2010-08-16 00:28:28 UTC - Original Post

I suspect there's some difficulty receiving blocks if all the nodes you're
connected to are 0.3.9 or lower. We need enough of us so that at least one node
you connect to will be 0.3.10. The problem will start to go away when we make up
more than 1/8th of the network.It'll help if you port forward so you can get lots
of connections./nRe: 0.3.10.1 Question on where block should be

Bitcointalk

2010-08-16 00:37:20 UTC - Original Post

For now, can some people running 0.3.10 with static IP who can receive incoming
connections post their IP? Then we can -addnode= them and make sure to connect to
at least one 0.3.10 node./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-16 01:00:45 UTC - Original Post

Quote from: Ground Loop on August 16, 2010, 12:29:55 AMQuestion about fallout:
 I had a transaction that I submitted after the bad block, using the bad block
chain.What is the status of that transaction?From what I can tell, my (updated)
sending client wallet shows the deducted amount.Will it get reincorporated into the
fixed chain, and will the recipient be able to spend it?Right, it will get
reincorporated into the fixed chain. Â The transaction won't disappear, it'll still
be visible on both sides, but the confirmation count will jump back to 0 and start
counting up again.It's only if you generated a block in the bad chain after block
74638 that the 50 BTC from that will disappear. Â Any blocks in the bad chain
wouldn't have matured yet. /nRe: overflow bug SERIOUS

Bitcointalk

2010-08-16 01:02:24 UTC - Original Post

Quote from: kosovito on August 16, 2010, 12:39:17 AMI did all steps, now my
client is 0.3.10 and it stopped at block 74638. Is all fine?If you still show 74638
blocks then you aren't connected to any 0.3.10 nodes. Â For today, try adding these
parameters:Â -addnode=75.158.131.108 -addnode=99.27.237.13 -
addnode=68.68.99.14Seehttp://bitcointalk.org/index.php?topic=828/nRe: Bitcoin crash
when sending coins

Bitcointalk

2010-02-03 23:29:57 UTC - Original Post

I uploaded this fix to the SVN. It watches for spent coins and updates your
wallet on load and also continuously as blocks come in. I also put a better error
message, but it should never hit it because it always finds spent coins ahead of
time, unless you spent the same money at the same time on two computers at once.If
you want to try it, PM or e-mail me your e-mail address where I can send it as an
attachment and also what OS (win, linux 32-bit, linux 64-bit)./nRe: overflow bug
SERIOUS

Bitcointalk

2010-08-16 01:12:05 UTC - Original Post

Quote from: trebronics on August 16, 2010, 01:02:35 AMMost people running clients
are not reading this message thread. Â So... Â Silly questions:1) How will this
continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?2)
How will this affect clients that upgrade to 3.8.10 but don't remove their block
chain files?1) Once more than 50% of the node power is upgraded and the good chain
overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to
get any confirmations. 2) If you didn't remove your blk*.dat files, you're not
helping to contribute to that 50%, and you'll still show bad transactions until the
good chain overtakes the bad chain./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-16 02:16:10 UTC - Original Post

The bad chain is also slowed down as more nodes upgrade.We've already generated
14 blocks since 74638. Â The builds of 0.3.10 were uploaded about 2 and 3 hours
ago. Â Of the nodes I'm connected to, more than half are already 0.3.10. Â I would
say we probably already have more power than the bad chain./nRe: overflow bug
SERIOUS

Bitcointalk

2010-08-16 02:38:21 UTC - Original Post

On Windows, findstr /c:"version message" debug.logIt looks like the bad chain was
on block 74678 recently. Â Can't wait to overtake it.On the stats at
http://nullvoid.org/bitcoin/statistix.php there's been 5 blocks per hour in the
last 3 hours. Â We had a difficulty adjustment about a day ago that should have put
it back to 6 blocks per hour./nRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Bitcointalk

2010-08-16 02:57:57 UTC - Original Post

Quote from: tcatm on August 16, 2010, 12:43:39 AMI propose to compile sha256.cpp
with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting
this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll
improve performance by ~9%.GCC 4.3.3 doesn't support -march=amdfamk10. I
get:sha256.cpp:1: error: bad value (amdfamk10) for -march= switchQuote from:
NewLibertyStandard on August 16, 2010, 01:49:01 AMWith 4way, I get significantly
better performance when I have all my virtual cores enabled. I think I get about
the same amount of hashes when hyper threading is turned off with or without
4way.Hey, you may be onto something!hyperthreading didn't help before because all
the work was in the arithmetic and logic units, which the hyperthreads
share.tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2
instructions, so while one is doing x86 code, the other can do SSE2.How much of an
improvement do you get with hyperthreading?Some numbers? Â What CPU is that?/nRe:
tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Bitcointalk

2010-08-16 03:23:04 UTC - Original Post

Quote from: Vasiliev on August 16, 2010, 03:17:07 AMtry -march=amdfam10That
works.That's strange... are we sure that's the same thing? tcatm, try amdfam10
and make sure you get the same speed measurement./nRe: tcatm's 4-way SSE2 for Linux
32/64-bit is in 0.3.10

Bitcointalk

2010-08-16 04:36:59 UTC - Original Post

Quote from: jgarzik on August 16, 2010, 03:35:28 AMCode:cpu family : 6model
: 26model name : Genuine Intel(R) CPUÂ Â Â Â Â Â Â 000Â @
3.20GHzstepping : 4cpu family 6 model 26 stepping 4 is an Intel Core i7.That's a
23% speedup with -4way, 63% total speedup with -4way + hyperthreading.33% faster
with hyperthreading than without it./nRe: overflow bug SERIOUS

Bitcointalk

2010-08-16 12:59:38 UTC - Original Post

It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower
nodes have been responding with the current block number for some hours now.That
means it's no longer necessary to delete blk*.dat before upgrading. You can just
upgrade and it'll reorg away the bad block chain.Thanks to everyone for the quick
response!/nRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Bitcointalk

2010-08-16 13:38:01 UTC - Original Post

I wrapped sha256.cpp in #ifdef FOURWAYSSE2#endif // FOURWAYSSE2try it now./nRe:
[PATCH] Automatic block validation

Bitcointalk

2010-08-16 15:25:54 UTC - Original Post

That's a difficult approach.We need to cause a reorg, which will disconnect the
invalid chain.This is code that will rarely ever get tested, and is fairly
intricate, so something simple and safe is best.Here's what I was thinking of. Â (I
haven't tested this yet) Â It checks all the blocks in the main chain. Â If it
finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best
chain again, and it reduces best chain work to the fork level so any new block
after the fork will cause a reorg. Â (It can't change pindexBest without actually
doing a reorg)This isn't perfect yet. Â It still needs to receive one valid block
to trigger the reorg. Â It would probably be possible to initiate an
AddToBlockIndex or Reorganize after the check, but it would require a lot more
careful attention. Â I probably should break out part of AddToBlockIndex that sets
the new best block. Â I'll probably end up doing that instead of the code
below.Code:bool CTxDB::LoadBlockIndex(){   ...   // Verify blocks in the
main chain   vector<CBlockIndex*> vChain;   for (CBlockIndex* pindex =
pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)Â Â Â {Â Â Â Â
 vChain.push_back(pindex);     CBlock block;     if (!
block.ReadFromDisk(pindex))Â Â Â Â Â Â Â return error("LoadBlockIndex() :
block.ReadFromDisk failed");Â Â Â Â Â if (!block.CheckBlock())Â Â Â Â Â {Â Â
     bnBestChainWork = pindex->pprev->bnChainWork;     Â
 foreach(CBlockIndex* pindex2, vChain)         pindex2-
>bnChainWork = 0;Â Â Â Â Â }Â Â Â }Â Â Â return true;}/nblocks minus 1

Bitcointalk

2010-08-16 15:59:25 UTC - Original Post

I'd like to reduce the number of blocks displayed in the status bar by 1.Â
 When you first load the program, it'll display 0 blocks instead of 1:"0
connections  0 blocks   0 transactions"It's always been "nBestHeight + 1"
because it's counting the genesis block. Technically, yes, the genesis block is a
block. It's a hardcoded block that you start out with. You can't not have the
genesis block. Maybe think of it as a reference coin that you measure other coins
against. The block count people are looking for is the number of blocks they've
downloaded.The main benefit is that blocks will be equal to the block number of the
current best block. If blocks is 10, then the highest block number you have is
10. It means you have block 10 and you don't have block 11.It would reduce the
confusion we had here:Quote from: kencausey on August 15, 2010, 11:45:26 PMQuote
from: davidonpda on August 15, 2010, 11:31:37 PM... It already is on block 74638. I
assume that means that block is now a good one?I had some confusion on this myself
and got clarification in #bitcoin-dev:The bad block was number 74638, the last good
one was 74637. The numbers start at 0, so when your client shows there are 74638
blocks then that means you have up to block number 74637, the last good one./nRe:
Win32 CPU Cycles vs 'Live Protection' Engines ?

Bitcointalk

2010-02-03 23:36:54 UTC - Original Post

Thanks for that. Which version of Windows?/nRe: blocks minus 1

Bitcointalk

2010-08-16 17:06:27 UTC - Original Post

Done in SVN rev 137/nRe: [PATCH] Automatic block validation

Bitcointalk

2010-08-16 17:08:02 UTC - Original Post

Quote from: satoshi on August 16, 2010, 03:25:54 PMIt would probably be possible
to initiate an AddToBlockIndex or Reorganize after the check, but it would require
a lot more careful attention. Â I probably should break out part of AddToBlockIndex
that sets the new best block. Â I'll probably end up doing that instead of the code
below.This is what I ended up doing in SVN rev 139.Instead of deleting the bad
chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back
into the best chain once they're kicked out./nChecking the block chain on load

Bitcointalk

2010-08-16 20:07:46 UTC - Original Post

SVN rev 139 does a basic check of the block chain after loading.With this we
wouldn't have needed to delete blk*.dat, it would have automatically done a reorg
back to the fork. There wasn't time to do a careful implementation of this at the
time.It might take longer than we want, since it has to load all the blocks. If
it's too slow, we could have it only go back to a certain block number./nRe:
checkpointing the block chain

Bitcointalk

2010-08-16 20:20:53 UTC - Original Post

There is no way for the software to automatically know if one chain is better
than another except by the greatest proof-of-work. In the design it was necessary
for it to switch to a longer chain no matter how far back it has to go.The only
exception to that is the manual checkpoints I've added. If it weren't for those,
it would be able to reorg all the way back to the first block./nRe: overflow bug
SERIOUS

Bitcointalk

2010-08-16 22:54:55 UTC - Original Post

Un-upgraded nodes have the correct chain most of the time, but they are still
trying to include the overflow transaction in every block, so they're continually
trying to fork and generate invalid blocks. If an old version node is restarted,
its transaction pool is emptied, so it may generate valid blocks for a while until
the transaction gets broadcast again. 0.3.9 and lower nodes still must
upgrade.The SVN now has the code we needed to automatically reorg the block chain
without having to delete the blk*.dat files manually. I knew I couldn't write
that code fast and carefully enough yesterday, so I went with the quick manual
option./nRe: checkpointing the block chain

Bitcointalk
 2010-08-16 23:01:48 UTC - Original Post
Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PMHow is the strength
of the chain calculated?Total proof-of-work./nRe: New screenshots to the front
page?

Bitcointalk

2010-08-18 16:58:44 UTC - Original Post

Definitely. The old screenshots of 0.1 are very outdated.Windows Aero is a good
choice. Windows is still the largest user group. Mind what's behind it for the
transparent parts.What to have displayed in the transaction list? Not completely
filled up with stuff, just a few things./nRe: Difficulty: More nodes active, or
faster nodes?

Bitcointalk

2010-08-18 18:01:40 UTC - Original Post

The performance numbers posted from a VIA C7's hardware SHA-256 weren't
astronomical. Only in the 1500 khash/s range. If you think about it, just
because it's implemented in hardware doesn't mean it's crazy fast. It still has
to do all the steps. It's only if simplifying it down to single-purpose hardware
makes it small enough to fit many in parallel. That's not necessarily easy or a
given./nRe: Checking the block chain on load

Bitcointalk

2010-08-18 18:28:28 UTC - Original Post

In the next SVN rev, I'll make it only go back to the last checkpoint at block
74000. If we need to correct a problem in the future, we can always make sure it
goes back at least as far back as the problem. Also, I'm adding code to verify
the block index, which means the proof-of-work chain is checked.Still, the system
won't be entirely secure against your blk*.dat files. You are trusting someone if
you use a copy of their blk files./nRe: Convert Bitcoin to GTK: Yes? No? wx is
better?

Bitcointalk

2010-08-19 18:44:36 UTC - Original Post

Quote from: BioMike on August 19, 2010, 08:05:18 AMWxWidgets is not really a
problem. My problem is the version that is used (2.9), which is considered unstable
by many distro packagers (although the WxWidgets devs say it isn't). On the other
side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff
and makes it for the bitcoins devs easy to make things cross platform.wxWidgets 2.9
is their first UTF-8 version. We are UTF-8 on all platforms including Windows.The
distro packages of 2.8 are UTF-16, so they just trip people up. People had
endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build
options until we standardized on 2.9. Also, to use 2.8, we were using ANSI, which
was just a temporary stopgap until wxWidgets supported UTF-8.This is a problem that
will solve itself. With time, 2.9 will become a more mainline release./nWelcome
to the new Bitcoin forum!

Bitcointalk

2009-11-22 18:04:28 UTC - Original Post

Welcome to the new Bitcoin forum!The old forum can still be reached
here:http://bitcoin.sourceforge.net/boards/index.phpI'll repost some selected
threads here and add updated answers to questions where I
can.FAQhttp://bitcoin.sourceforge.net/wiki/index.php?page=FAQDownloadhttp://
sourceforge.net/projects/bitcoin/files//nRe: Questions about Addresses

Bitcointalk

2010-02-04 00:07:07 UTC - Original Post

Port forwarding forwards a port to one computer. It tells the router which
computer handles connections to that port. So that's the computer receiving.If
you didn't set up port forwarding, then incoming connections won't go to any
computer, and attempts to send to that IP would just say it couldn't connect to the
recipient and nothing is sent. When sending by IP, you still send to a bitcoin
address, but your computer connects to that IP, gets a new bitcoin address from it,
gives the transaction directly to the them and confirms that it was received and
accepted.Someone should post their static IP so people can try out sending by IP
and also give that user free money.There's a 32-bit checksum in bitcoin addresses
so you can't accidentally type an invalid address.If 4) you send to a recipient who
has abandoned or lost their wallet.dat, then the money is lost. A subtle point
can be made that since there is then less total money in circulation, everyone's
remaining money is worth slightly more, aka "natural deflation"./nRe: HOWTO:
Compiling Bitcoin on Ubuntu 10.04 (Karmic)

Bitcointalk

2010-08-19 18:55:48 UTC - Original Post

That's a really well written walkthough. Someone should confirm if they
followed it and didn't run into any snags./nRe: tcatm's 4-way SSE2 for Linux 32/64-
bit is in 0.3.10

Bitcointalk

2010-08-19 19:07:43 UTC - Original Post

Quote from: Ground Loop on August 18, 2010, 11:14:26 PMAny non-Mac i5 love?
Windows i5 64-bit got slower here.That's the first I've heard anyone say i5 was
slower. Â Everyone else has said 4way was faster on i5. Â Moreso with
hyperthreading enabled.Quote from: nelisky on August 18, 2010, 11:02:25 PMAnd i5,
at least on my macbookproGood, so I take it that's a confirmation that it's working
on Mac as well?Laszlo told me he did compile in the -4way stuff on Mac, so the -
4way switch is also available to try on Mac. I don't think makefile.osx on SVN
has it yet, just the built version./nRe: 28 days without generation, i have
4200khash/s

Bitcointalk

2010-08-19 19:40:30 UTC - Original Post

Make sure your computer's date and time are correct./nNeed a post writing up some
things users should know

Bitcointalk

2010-08-19 20:14:01 UTC - Original Post

I'm not sure what to call it, but we could use a post that lists these things
users should know. Â If someone has time to write it, here's the list:- Make sure
your clock is set correctly. - Microsoft Security Essentials. Â This never got
written up proper.- Warning not to mess around with your wallet.dat file. Â It's a
database file, it's not as simple as you think. Â In this Beta version, we haven't
had time to try and tinker-proof it yet. Â It may not work as expected if you start
swapping it around./nRe: Hypothetical question on lost coins / transfers

Bitcointalk
 2010-08-19 20:28:50 UTC - Original Post
That's right. You don't need to be re-broadcasting your transactions for it to
work.When any node disconnects a fork, it dumps all the transactions from the fork
back into the transaction pool to add to the new chain. The entire network is
making sure to re-integrate your transactions again. All you should see is that
your number of confirmations starts over from 0.In some types of forks, your
transaction would have gotten into both forks already, so you're already good
either way./nRe: Need a post writing up some things users should know

Bitcointalk

2010-08-22 22:51:00 UTC - Original Post

The clock part will be covered in the next release (0.3.11 or higher). SVN rev
141 pops up a message box if your clock is too far off./nRe: 28 days without
generation, i have 4200khash/s

Bitcointalk

2010-08-22 23:01:02 UTC - Original Post

Search debug.log for "proof-of-work found". If you find any, then check for any
errors right after that.Quote from: davidonpda on August 19, 2010, 07:43:01 PMHow
big of a margin on the time is allowed for things to work right.The margin is 2
hours.This should be solved in SVN rev 141 and the next release (0.3.11+). It'll
pop up a message box alerting you if your clock is off by more than an hour./nRe:
tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Bitcointalk

2010-08-22 23:21:50 UTC - Original Post

Thanks for clearing that up. Â I read the link someone posted about AMD making
that change around 2007, but I didn't know what the story was for Intel.There's no
hope for Core/Core2 then. They only have half the SSE2 hardware.Strange that
Intel has 3 128bit units, but AMD with 2 128bit units is the faster
one./nDevelopment of alert system

Bitcointalk

2010-08-22 23:55:06 UTC - Original Post

I've been working on writing the alert system. Â Alerts are broadcast through the
network and apply to a range of version numbers. Â Alert messages are signed with a
private key that only I have.Nodes can do two things in response to an alert:- Put
a warning message on the status bar.- Make the money handling methods of the json-
rpc interface return an error.In cases like the overflow bug or a fork where users
may not be able to trust received payments, the alert should keep old versions
mostly safe until they upgrade. Â Manual users should notice the status bar warning
when looking for received payments, and the json-rpc safe mode stops automated
websites from making any more trades until they're upgraded.The json-rpc methods
that return errors during an alert
are:sendtoaddressgetbalancegetreceivedbyaddressgetreceivedbylabellistreceivedbyaddr
esslistreceivedbylabel/nRe: integrating digital payments into p2p protocols

Bitcointalk

2010-08-22 23:57:32 UTC - Original Post

Hey Zooko!I wanted to thank you for posting about Bitcoin on your blog a year or
two ago, back when I announced it on the Cryptography mailing list./nRe: TOR and
I2P

Bitcointalk
 2010-02-04 00:30:50 UTC - Original Post
When using proxy port 9050, it will only make one attempt to connect to IRC, then
give up, since it knows it will probably always fail because IRC servers ban all
the TOR exit nodes. If you're using another port, it would assume it might be a
regular old normal proxy and would keep retrying IRC at longer and longer
intervals. You should not use Polipo or Privoxy as those are http filters and
caches that would corrupt Bitcoin's messages if they make any changes. Bitcoin
might be trying to overcome it by reconnecting. You should use port 9050.As riX
says, the "is giving Tor only an IP address. Apps that do DNS..." warnings are
nothing to worry about. Â Bitcoin doesn't use DNS at all in proxy mode.Since
Bitcoin can't get through to IRC through Tor, it doesn't know which nodes are
currently online, so it has to try all the recently seen nodes. Â It tries to
conserve connection attempts as much as possible, but also people want it to
connect quickly when they start it up and reconnect quickly if disconnected. Â It
uses an algorithm where it tries an IP less and less frequently the longer ago it
was successful connected. Â For example, for a node it saw 24 hours ago, it would
wait 5 hours between connection attempts. Â Once it has at least 2 connections, it
won't try anything over a week old, and 5 connections it won't try anything over 24
hours old./nRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Bitcointalk

2010-08-24 22:43:56 UTC - Original Post

Quote from: ArtForz on August 21, 2010, 04:56:31 PMAMD K10: 2 128bit unitsintel
nehalem: 3 128bit unitsThis probably explains why hyperthreading increases
performance with -4way. If three SSE2 units is excessive, then hyperthreading
would help keep them all busy./nRe: Development of alert system

Bitcointalk

2010-08-24 23:51:12 UTC - Original Post

If you're so paranoid that you're getting hysterical over this, then surely
you're paranoid enough that if a warning message displays on the status bar, you'll
check the website and forum.I think if another bug like the overflow bug occurs,
it's important that automated websites stop trading until their admins can check
out what's going on and decide what to do. Â If you decide it's a false alarm and
want to take your chances, you can use the "-disablesafemode" switch./nRe:
Development of alert system

Bitcointalk

2010-08-25 00:06:36 UTC - Original Post

This is in SVN rev 142 as version 0.3.11./nRe: Development of alert system

Bitcointalk

2010-08-25 15:17:37 UTC - Original Post

It can't do arbitrary actions remotely. Â Maybe some of you are responding to
other posters who suggested the alert system should do more?If there is an alert,
the following json-rpc methods return an
error:sendtoaddressgetbalancegetreceivedbyaddressgetreceivedbylabellistreceivedbyad
dresslistreceivedbylabelThe remaining 14 methods function as normal. I believe the
safer option should be enabled by default. Â If you want your server to keep
trading and ignore an alert saying the money its receiving might be like the money
from the overflow bug, then you can use the switch and not blame anyone else if you
lose your money.Worst case if you leave alerts enabled, your site stops trading
until you upgrade or add the -disablesafemode switch.Getting surprised by some
temporary down time when your node would otherwise be at risk is better than
getting surprised by a thief draining all your inventory.Someday when we haven't
found any new bugs for a long time and it has been thoroughly security reviewed
without finding anything, this can be scaled back. Â I'm not arguing that this is
the permanent way of things forever. Â It's still beta software./nRe: Development
of alert system

Bitcointalk

2010-08-25 16:40:20 UTC - Original Post

I changed the switch name to -disablesafemode./nRe: Development of alert system

Bitcointalk

2010-08-25 16:56:15 UTC - Original Post

Quote from: jimbobway on August 25, 2010, 04:45:22 PMQuote from: BioMike on
August 23, 2010, 05:15:43 AM@mizerydearia, I think the quote button is easier to
find then the reply one. So, theoretical this is a first control system where <some
goverment> can arrest satoshi and demand that he hands over his key (or get it from
his computer) and shut down the complete network?Or is that not possible? How far
would <some goverment> get?A few rhetorical questions for satoshi:Can you resist
waterboarding?Can you endure electric shock?All forms of torture?Lastly, are you
Jack Bauer by any chance? Â Seriously.WRT the alert system, who cares? Â The most
the key can do is temporarily disable six json-rpc commands until the site owners
either add the -disablesafemode switch or upgrade. Â All nodes keep running and
generating, the network stays up. Â If I'm not available, any script kiddie can
figure out how to add two characters and make a new version that disables the alert
system. Â It would be a temporary inconvenience only.Quote from: BioMike on August
23, 2010, 05:15:43 AMSo, theoretical this is a first control system where <some
goverment> can arrest satoshi and demand that he hands over his key (or get it from
his computer) and shut down the complete network?This is what makes me think the
people objecting don't know what they're talking about. Â It can't "shut down the
complete network". /nRe: Development of alert system

Bitcointalk

2010-08-25 17:59:30 UTC - Original Post

Quote from: nelisky on August 25, 2010, 01:28:32 AMSo what kind of warning do
admins get from bitcoind? Is there something we can grep from debug.log? Or will
rpc calls raise some specific error? Is there a way to locally force this to
happen, for unittesting services?getinfo has a new field that shows any alert
messages or other errors that would be displayed on the status bar.The rpc methods
return a json-rpc error with the error description "Safe mode: " followed by
additional text specified by the alert.I added the switch "-testsafemode" for you.
 SVN rev 145.This stuff is very new and may still be subject to change.Quote from:
mizerydearia on August 25, 2010, 12:11:50 AMI just discovered
http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -
disablesafemode. Â Perhaps it should be added! Â Also others liek -4way should be
added as well.Many switches are intentionally undocumented, like if their
functionality is still under construction or I haven't settled on their name yet,
or just test code not intended for release.-4way should eventually be replaced by
an auto-detect./nRe: Development of alert system

Bitcointalk

2010-08-26 00:08:12 UTC - Original Post

Quote from: BioMike on August 25, 2010, 06:23:45 PMQuote from: satoshi on August
25, 2010, 04:56:15 PMQuote from: BioMike on August 23, 2010, 05:15:43 AMSo,
theoretical this is a first control system where <some goverment> can arrest
satoshi and demand that he hands over his key (or get it from his computer) and
shut down the complete network?Or is that not possible? How far would <some
goverment> get?This is what makes me think the people objecting don't know what
they're talking about. Â It can't "shut down the complete network". I've never
objected this change/idea, just asking if this was possible and to what
extent.What's wrong with getting informed? My apologies, your post was indeed a
question not a statement./nRe: RFC: remove DB_PRIVATE flag

Bitcointalk

2010-08-26 00:33:28 UTC - Original Post

Can you provide more details about what removing DB_PRIVATE does?I can't remember
if I had a specific reason for DB_PRIVATE, or if I just copied the flags from some
example code. Does removing DB_PRIVATE make it safe for other processes to open
the database simultaneously? That may be an improvement, depending what the side
effects are. Does it substantially reduce performance by making it have to write
out every change immediately or do other coordination? Are there additional
locking or coordination files then? What else changes? You could test by timing
an initial block download with and without DB_PRIVATE, preferably -connect-ing to a
local machine so network isn't a factor.Apparently, DB_PRIVATE doesn't do what you
would hope it would do, which is prevent other processes from being able to open
the database. It still lets them, it just screws up if they do. Another option,
if there's a way, would be to make it lock the database files so they can't be
accessed by other processes./nRe: Need a post writing up some things users should
know

Bitcointalk

2010-08-26 00:44:05 UTC - Original Post

Any backup process/procedure would just be a stopgap until there's time to
properly work on coding solutions in software. We can try to use words to help
the situation until code gets there.The main backup improvement will be pre-made
pool of keys, and a rescan at load to scrape missed transactions from the block
history. Then a backup will last forward for a long time./nProof-of-work
difficulty increasing

Bitcointalk

2010-02-05 19:19:12 UTC - Original Post

We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec
2009. Â The minimum difficulty is 32 zero bits, so even if only one person was
running a node, the difficulty doesn't get any easier than that. Â For most of last
year, we were hovering below the minimum. Â On 30 Dec we broke above it and the
algorithm adjusted to more difficulty. Â It's been getting more difficult at each
adjustment since then.The adjustment on 04 Feb took it up from 1.34 times last
year's difficulty to 1.82 times more difficult than last year. Â That means you
generate only 55% as many coins for the same amount of work.The difficulty adjusts
proportionally to the total effort across the network. Â If the number of nodes
doubles, the difficulty will also double, returning the total generated to the
target rate.For those technically inclined, the proof-of-work difficulty can be
seen by searching on "target:" in debug.log. Â It's a 256-bit unsigned hex number,
which the SHA-256 value has to be less than to successfully generate a block. Â It
gets adjusted every 2016 blocks, typically two weeks. Â That's when it prints
"GetNextWorkRequired RETARGET" in debug.log. minimum Â
 00000000ffff000000000000000000000000000000000000000000000000000030/12/2009
00000000d86a000000000000000000000000000000000000000000000000000011/01/2010
00000000c428000000000000000000000000000000000000000000000000000025/01/2010
00000000be71000000000000000000000000000000000000000000000000000004/02/2010
000000008cc3000000000000000000000000000000000000000000000000000014/02/2010
000000006546570000000000000000000000000000000000000000000000000024/02/2010
0000000043b3e50000000000000000000000000000000000000000000000000008/03/2010
00000000387f6f0000000000000000000000000000000000000000000000000021/03/2010
000000003813750000000000000000000000000000000000000000000000000001/04/2010
000000002a11150000000000000000000000000000000000000000000000000012/04/2010
0000000020bca70000000000000000000000000000000000000000000000000021/04/2010
0000000016546f0000000000000000000000000000000000000000000000000004/05/2010
0000000013ec530000000000000000000000000000000000000000000000000019/05/2010
00000000159c240000000000000000000000000000000000000000000000000029/05/2010
000000000f675c0000000000000000000000000000000000000000000000000011/06/2010
000000000eba640000000000000000000000000000000000000000000000000024/06/2010
000000000d31420000000000000000000000000000000000000000000000000006/07/2010
000000000ae4930000000000000000000000000000000000000000000000000013/07/2010
0000000005a3f40000000000000000000000000000000000000000000000000016/07/2010
000000000168fd0000000000000000000000000000000000000000000000000027/07/2010
00000000010c5a0000000000000000000000000000000000000000000000000005/08/2010
0000000000ba180000000000000000000000000000000000000000000000000015/08/2010
0000000000800e0000000000000000000000000000000000000000000000000026/08/2010
0000000000692000000000000000000000000000000000000000000000000000date, difficulty
factor, % change2009 Â Â Â Â Â 1.0030/12/2009 Â Â 1.18 Â +18%11/01/2010 Â
 1.31  +11%25/01/2010   1.34   +2%04/02/2010   1.82 Â
+36%14/02/2010 Â Â 2.53 Â +39%24/02/2010 Â Â 3.78 Â +49%08/03/2010 Â Â 4.53
 +20%21/03/2010   4.57   +9%01/04/2010   6.09  +33%12/04/2010  Â
7.82 Â +28%21/04/2010 Â Â 11.46 Â +47%04/05/2010 Â Â 12.85 Â +12%19/05/2010 Â
 11.85   -8%29/05/2010   16.62  +40%11/06/2010   17.38 Â
 +5%24/06/2010   19.41  +12%06/07/2010   23.50  +21%13/07/2010 Â
 45.38  +93%16/07/2010  181.54  +300%27/07/2010  244.21  +35%05/08/2010
 352.17  +44%15/08/2010  511.77  +45%26/08/2010  623.39  +22%/nRe:
auto backing up of wallet.dat

Bitcointalk

2010-08-26 00:57:40 UTC - Original Post

I started posting in the other topic but I'll repeat here, this thread seems more
specific to the topic.The main backup improvement will be a pre-generated pool of
keys and a rescan at load to scrape missed transactions from the block history.Â
Then a backup will last forward for a long time.I was starting to post the same
idea you said nelisky.How about a json-rpc command that locks the wallet, flushes
it, copies wallet.dat to a location you specified, then unlocks it? That would be
a smaller project than the pooled keys, so maybe it could be done first.What's the
simplest portable way to copy a file? Is there something in Boost?What should it
be named? maybe:backupwallet <destination>/nRe: Gentoo Linux Ebuild

Bitcointalk

2010-08-27 00:49:43 UTC - Original Post

Try -datadir=Last time I tried $(shell /usr/bin/wx-config), there was immediate
hollering about build problems with it. Â There wasn't time to investigate at the
time.One problem with $(shell /usr/bin/wx-config) is it will pick up any version
(wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there.
 -lwx_gtk2ud-2.9 only matches the right configuration.  It fails if wxWidgets was
built with the wrong configuration. QuoteIirc, chatting in #wxwidgets on freenode,
the devs there were baffled why that was used.Did they say why they were baffled?
QuoteThis is because on my system the path is /usr/include/wx-2.9/wx/wx.hWhy is it
there? Â Was it included by the OS, or did you have to build it? Â If you built it,
I wonder why it would put itself in a different place.Has wxWidgets 2.9 finally
started to become available as a debian package?Maybe we should do
this:INCLUDEPATHS= \Â -I"/usr/local/include/wx-2.9" \
 -I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \
 -I"/usr/include/wx-2.9" \ -I"/usr/lib/wx/include/gtk2-unicode-debug-static-
2.9"Again, those paths help make sure it's only 2.9 and will fail with
2.8.wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us. Â It's tempting
because it's so easily available as a package; a lot of people were frustrated by
it until we started hardcoding 2.9 into the makefile./nRe: auto backing up of
wallet.dat

Bitcointalk

2010-08-27 01:13:42 UTC - Original Post

If you read it into memory and write it out, it could fail in tight memory
situations. I'm looking for something like copyfile(const char* from, const char*
to) or copyfile(path from, path to), preferably something in Boost if it has it.Â
If you find it for me, it's more likely I'll get to implementing it.Quote from:
nelisky on August 26, 2010, 01:21:57 AMAs for the file copy, why add to the boost
dependency? I for one would love to get a core lib with very little deps.We require
Boost for JSON and a dozen things replacing dependencies on wxWidgets. Boost is
good, portable stuff, we should not shy away from it./nRe: auto backing up of
wallet.dat

Bitcointalk

2010-08-27 02:54:07 UTC - Original Post

I doubt there's an mmap(2) on Windows. I'd rather call an existing file copy
function than make and test my own.Quote from: nelisky on August 27, 2010, 01:21:09
AMBut if you are already using features from boost::filesystem you can use
copy_file from that. I just think that, if not already required for something else,
it's a tad overkill.Thanks. I thought it would be in there somewhere.We already
use boost::filesystem in a dozen places. It's not a new added dependency. It
gives us a lot of portable stuff that we would otherwise have to have a #ifdef for
each OS and test everywhere./nRe: auto backing up of wallet.dat

Bitcointalk

2010-08-27 15:47:57 UTC - Original Post

Sorry, I've been so busy lately I've been skimming messages and I still can't
keep up.We want to avoid Windows API calls whenever possible. Â They usually take
about 6-8 parameters and a lot of testing to get right, it takes a page of code to
do something simple.I usually shy away from iostreams. Â Seems like I too often hit
limitations. Â They kind of botched the C++ streams standard in the 90's, which is
too bad, streams can be very powerful and useful when done right. Using it in
rpc.cpp may still turn out to be a mistake.Bottom line is I'd rather call an
existing file copy function than make and test my own./nRe: New web service: obtain
dump of bitcoin block NNNN

Bitcointalk

2010-08-27 16:13:16 UTC - Original Post

That's kind of interesting as an upside-down bar chart of how many blocks were
produced each day. The target is 144 blocks per day./nRe: Bitcoins are most like
shares of common stock

Bitcointalk

2010-08-27 16:39:26 UTC - Original Post

Bitcoins have no dividend or potential future dividend, therefore not like a
stock.More like a collectible or commodity./nRe: Bitcoin does NOT violate Mises'
Regression Theorem

Bitcointalk
 2010-08-27 17:32:07 UTC - Original Post
As a thought experiment, imagine there was a base metal as scarce as gold but
with the following properties:- boring grey in colour- not a good conductor of
electricity- not particularly strong, but not ductile or easily malleable either-
not useful for any practical or ornamental purposeand one special, magical
property:- can be transported over a communications channelIf it somehow acquired
any value at all for whatever reason, then anyone wanting to transfer wealth over a
long distance could buy some, transmit it, and have the recipient sell it.Maybe it
could get an initial value circularly as you've suggested, by people foreseeing its
potential usefulness for exchange. Â (I would definitely want some) Â Maybe
collectors, any random reason could spark it.I think the traditional qualifications
for money were written with the assumption that there are so many competing objects
in the world that are scarce, an object with the automatic bootstrap of intrinsic
value will surely win out over those without intrinsic value. Â But if there were
nothing in the world with intrinsic value that could be used as money, only scarce
but no intrinsic value, I think people would still take up something.(I'm using the
word scarce here to only mean limited potential supply)/nVersion 0.3.11 with
upgrade alerts

Bitcointalk

2010-08-27 21:54:12 UTC - Original Post

Version 0.3.11 is now available.Changes:- Some blk*.dat checking on load- Built
the -4way code with -march=amdfam10, which makes it a little faster- Warning if
your clock is too far off- Warnings/errors/alerts can also be seen in the getinfo
command- Alert systemThe alert system can display notifications on the status bar
to alert you if you're running a version that needs to be upgraded for an important
security update.In response to an alert, your node may also go into safe mode,
which disables the following json-rpc commands (used by automated websites) to
protect it from losing money until you get a chance to
upgrade: sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel list
receivedbyaddress listreceivedbylabelIf you decide it's a false alarm and want to
take your chances, you can use the switch -disablesafemode to re-enable them.This
is an important safety improvement. Â For a large segment of possible problems,
this can warn everyone immediately once a problem is discovered and prevent them
from acting on bad information.Nodes keep operating and do not stop generating in
response to an alert, so old versions may still try to make a fork, but the alert
system can make sure users are warned not to act on anything in the
fork.Download:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.3.11//nRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Bitcointalk

2010-08-28 14:27:15 UTC - Original Post

The simplification is intentional. Â There will only be more than one thash[7]=0
in one out of 134,217,728 cases. Â It only makes it 0.0000007% slower./nRe:
Questions about Addresses

Bitcointalk

2010-02-05 19:44:46 UTC - Original Post

Quote from: Sabunir on February 05, 2010, 05:31:30 PMPerhaps there should be a
feature against this? For instance, if a transaction isn't accepted by the
recipient for a long period of time (a month?), the transaction will be canceled
and the coins returned to the one who sent them?That's not possible. You've
handed control of the money over to the recipient's keypair. Only that key can
control it.It's similar to if you encrypt a file with AES and a strong password,
and you lose the password. The data is lost./nRe: Version 0.3.11 with upgrade
alerts

Bitcointalk

2010-08-28 14:54:04 UTC - Original Post

Quote from: torservers on August 28, 2010, 01:00:37 PMThe "About" dialog still
shows 0.3.10.1 beta.What OS? I ran the Windows and 64-bit Linux version and
checked the about dialog.The Mac version is still 0.3.10.1.Quote from: pavelo on
August 28, 2010, 07:36:07 AMiirc, it is possible to specify -march on a per-
function basis using some gcc __attribute__. That way, only the function in
question would be optimized, and if the user doesn't specify -4way, everything else
should be ok.I updated the first post to be more specific. Only the -4way code is
compiled this way./nRe: Big endian code problems

Bitcointalk

2010-08-29 22:14:36 UTC - Original Post

The code assumes little-endian throughout and was written with the intention of
never being ported to big-endian. Â Every integer that is sent over the network
would have to be byte swapped, in addition to many dozens of other places in code.
 It would not be worth the extra sourcecode bloat.Big-endian is on its way out
anyway./nRe: CryptoPP Assertion Error

Bitcointalk

2010-09-05 23:25:32 UTC - Original Post

You can probably just comment out the linecryptopp/secblock.h:187Â
//assert(false);Let me know if it works, and watch if it memory leaks. It looks
like a template class to make sure the derived class defines its own version of
allocate and deallocate. It would be weird if that was the actual problem and it
made it all the way to release. Probably a false alarm./nRe: Warning : Check your
system ( Help me )

Bitcointalk

2010-09-05 23:36:20 UTC - Original Post

Any suggestions for better text to put for this error message so the next person
will be less likely to be confused?It's trying to tell them their clock is wrong
and they need to correct it.It's relying on 3 time sources:1) the system clock2)
the other nodes, if within an hour of the system clockif those disagree, then3) the
user (asking the user to fix the system clock)I've thought about NTP, but this is
more secure./nRe: HTTP status codes from the JSON-RPC api

Bitcointalk

2010-09-06 21:21:21 UTC - Original Post

This is in SVN rev 147.This is more standard, and although json-rpc 1.0 didn't
specify the format of error objects, it did specify that they would be objects not
strings or other values, so we needed to change this to be correct. The
code/message members have become standard in later json-rpc specs.If you have code
that checks the error and expects a string, you'll need to change it. When there
is an error, the error member is now an object not a string.Also in SVN rev 147:-
The command line json-rpc returns the error code as its exit code. Exit codes can
only be 0-255 on unix, so it's abs(code)%256.- The "backupwallet <destination>"
command that was discussed in another thread. It locks the wallet and copies it,
so you can be sure you get a correct copy./nRe: Warning : Check your system
( Help me )

Bitcointalk
 2010-09-06 21:41:06 UTC - Original Post
Quote from: Insti on September 06, 2010, 12:51:37 PMQuote from: satoshi on
September 05, 2010, 11:36:20 PMAny suggestions for better text to put for this
error message so the next person will be less likely to be confused?"Please check
that your computer's date and time are correct. If your clock is wrong Bitcoin will
not work properly."Thanks./nRe: auto backing up of wallet.dat

Bitcointalk

2010-09-06 21:45:10 UTC - Original Post

rpc backupwallet <destination> is in SVN rev 147./nRe: bitcoind as daemon in OSX

Bitcointalk

2010-09-06 21:52:45 UTC - Original Post

Can you build?Try changing line 78 of init.cpp from:#ifdef __WXGTK__to:#ifndef
__WXMSW__If that works, I'll change the source. It should work./nRe: Always pay
transaction fee?

Bitcointalk

2010-09-07 16:32:21 UTC - Original Post

Another option is to reduce the number of free transactions allowed per block
before transaction fees are required. Â Nodes only take so many KB of free
transactions per block before they start requiring at least 0.01 transaction
fee.The threshold should probably be lower than it currently is.I don't think the
threshold should ever be 0. Â We should always allow at least some free
transactions./nVersion 0.3.12

Bitcointalk

2010-09-07 19:17:55 UTC - Original Post

Version 0.3.12 is now available.Features:- json-rpc errors return a more standard
error object. (thanks to Gavin Andresen)- json-rpc command line returns exit
codes.- json-rpc "backupwallet" command.- Recovers and continues if an exception is
caused by a message you received. Â Other nodes shouldn't be able to cause an
exception, and it hasn't happened before, but if a way is found to cause an
exception, this would keep it from being used to stop network nodes.If you have
json-rpc code that checks the contents of the error string, you need to change it
to expect error objects of the form {"code":<number>,"message":<string>}, which is
the standard. Â See this thread:http://bitcointalk.org/index.php?
topic=969.0Download:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.3.12//nRe: Repost: Request: Make this anonymous?

Bitcointalk

2010-02-06 21:06:32 UTC - Original Post

When you send to a bitcoin address, you don't connect to the recipient. You
send the transaction to the network the same way you relay transactions. There's
no distinction between a transaction you originated and one you received from
another node that you're relaying in a broadcast. With a very small network
though, someone might still figure it out by process of elimination. It'll be
better when the network is larger.If you send by IP, the recipient sees you because
you connect to their IP. You could use TOR to mask that.You could use TOR if you
don't want anyone to know you're even using Bitcoin.Bitcoin is still very new and
has not been independently analysed. If you're serious about privacy, TOR is an
advisable precaution./nRe: Always pay transaction fee?
 Bitcointalk

2010-09-08 17:30:14 UTC - Original Post

Currently, paying a fee is controlled manually with the -paytxfee switch. It
would be very easy to make the software automatically check the size of recent
blocks to see if it should pay a fee. We're so far from reaching the threshold,
we don't need that yet. It's a good idea to see how things go with controlling it
manually first anyway.It's not a big deal if we reach the threshold. Free
transactions would just take longer to get into a block.I did a rough tally of 4000
blocks from around 74000-78000. This is excluding the block reward
transactions:There were average 2 transactions per block, 17 transactions per hour,
400 transactions per day.Average transaction bytes per block was 428 bytes, or 214
bytes per transaction.The current threshold is 200KB per block, or about 1000
transactions per block. I think it should be lowered to 50KB per block. That
would still be more than 100 times the average transactions per block.The threshold
can easily be changed in the future. We can decide to increase it when the time
comes. It's a good idea to keep it lower as a circuit breaker and increase it as
needed. If we hit the threshold now, it would almost certainly be some kind of
flood and not actual use. Keeping the threshold lower would help limit the amount
of wasted disk space in that event./nRe: Version 0.3.12

Bitcointalk

2010-09-08 18:06:04 UTC - Original Post

Bitcoin clients currently only create and recognize transactions that match two
possible templates. Those are some quick tests that loosely check if transactions
fit some general metrics that those standard transactions fit. Nodes will only
work on adding those transactions to their block.In the future, if we add more
templates to the existing 2 types of transactions, we can change the "rather not
work on nonstandard transactions" test to accept them./nRe: Bitcoin Blogger: Is It
Better To Buy Or Generate Bitcoins?

Bitcointalk

2010-09-08 20:27:39 UTC - Original Post

Quote from: BitLex on September 07, 2010, 08:10:54 PMAMD X3 @2.8ghz->stock
client~3800khs ~150WattDid you try -4way?QuoteHow many hashes can I expect with a
24 core machine? I have a quad-core generating 4,300 hashes-per-second, so I am
estimating a 24-core machine could mine bitcoins at 25,000 hashes-per-second.AMD
Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100%
speedup. Â 24 cores should get 66,000khps. Â AMD is the best choice because it has
the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his
code for that)There's been so much else to do that I haven't had time to make -4way
automatic. Â For now you still have to do it
manually.http://bitcointalk.org/index.php?topic=820.0/nAuto-detect for 128-bit 4-
way SSE2

Bitcointalk

2010-09-09 01:04:05 UTC - Original Post

SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2. Â We
need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and
not ones with 64-bit SSE2.It uses the CPUID instruction to get the CPU brand,
family, model number and stepping. Â That's the easy part. Â Knowing what to do
with the model number is the hard part. Â I was not able to find any table of
family, model and stepping numbers for CPUs. Â I had to go by various random
reports I saw.Here's what I ended up with:Code: Â // We need Intel Nehalem or AMD
K10 or better for 128bit SSE2  // Nehalem = i3/i5/i7 and some Xeon  // K10 =
Opterons with 4 or more cores, Phenom, Phenom II, Athlon IIÂ Â // Â Intel Core i5
Â family 6, model 26 or 30Â Â // Â Intel Core i7 Â family 6, model 26 or 30Â Â //
 Intel Core i3  family 6, model 37  //  AMD Phenom   family 16, model
10Â Â bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= Â 60026) ||Â Â Â Â
      (fAMD  && nFamily * 10000 + nModel >= 160010));I saw some
sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will
catch all capable AMDs.If it's wrong, you can still override it with -4way or -
4way=0.It prints what it finds in debug.log. Â Search on CPUID.This is only enabled
if built with GCC./nRe: Won't let me send coins because it requires a transaction
fee?

Bitcointalk

2010-09-10 00:23:24 UTC - Original Post

What version is the one where this happened? Release build, or built it
yourself? Which operating system? Were you sending by IP or by Bitcoin Address?
When you sent 49.99, did it prompt you to pay a 0.01 fee?There was a change in
GetMinFee, but I can't see how it would cause this. Â It only starts to apply when
a block gets huge. The reason for the difference in block number is the number
displayed was reduced by 1 in 0.3.11 because it made more sense that way./nRe:
Won't let me send coins because it requires a transaction fee?

Bitcointalk

2010-09-10 00:46:37 UTC - Original Post

I think I know what happened. Â Doubleclick on the generated transaction. Â It
probably has a sub-0.01 transaction fee in it.Someone has been paying a 0.00000010
transaction fee. Â I don't think you can even set that with -paytxfee, I think
you'd have to modify the code to do it. Â Your generated block is worth
50.00000010, so when you try to send the whole thing you have 0.00000010 left over
for the change, which triggers the dust spam 0.01 fee.It would normally be harmless
except in this corner case. Â I should add a special case to CreateTransaction to
handle this./nRe: Won't let me send coins because it requires a transaction fee?

Bitcointalk

2010-09-10 17:12:33 UTC - Original Post

The fix is in SVN rev 151.You will be able to send your stuck 0.01 (actually
0.01000010) when you next upgrade./nRe: Auto-detect for 128-bit 4-way SSE2

Bitcointalk

2010-09-10 18:11:06 UTC - Original Post

Quote from: teknohog on September 09, 2010, 07:32:05 PMSince the function
CallCPUID function contains x86 assembler, it breaks the build on other
architectures. I've changed line 2770 in main.cpp to#if defined(__GNUC__) &&
defined(CRYPTOPP_X86_ASM_AVAILABLE)to make it compile again, at least on ARM.Added
in SVN rev 152/nRe: Running on a port other than 8333

Bitcointalk

2010-09-12 17:40:20 UTC - Original Post

Quote from: lachesis on August 10, 2010, 03:24:55 PMAlso, does Bitcoin open the
BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my
own tests.Is there a way to open BerkeleyDB exclusive?DB_PRIVATE is the worst of
both worlds. Â DB_PRIVATE is not exclusive, but it does make it get screwed up if
another process tries to access it at the same time.I've dropped the DB_PRIVATE
flag in rev 153./nRe: RFC: remove DB_PRIVATE flag

Bitcointalk
 2010-09-12 18:00:39 UTC - Original Post
Trying it without the DB_PRIVATE flag in rev 153. Â We need to keep an eye on
what's different.On Windows at least, it creates six __db.001 - __db.006 files with
sizes from 24K to 4MB. Â It doesn't delete them on exit, it just leaves them
behind.The docs say it uses memory mapped files. Â I assume they have the same file
permissions as the database files, so the same user access restrictions apply.Tests
on Windows private LAN download of 78500 blocks:with DB_PRIVATE Â Â 20 minutes 51
secondswithout DB_PRIVATE Â 20 minutes 51 secondsI wasn't expecting them to come
out exactly the same./nRe: How divisible are bitcoins and other market/economic
questions

Bitcointalk

2010-02-06 23:25:53 UTC - Original Post

Eventually at most only 21 million coins for 6.8 billion people in the world if
it really gets huge.But don't worry, there are another 6 decimal places that aren't
shown, for a total of 8 decimal places internally. It shows 1.00 but internally
it's 1.00000000. If there's massive deflation in the future, the software could
show more decimal places.If it gets tiresome working with small numbers, we could
change where the display shows the decimal point. Same amount of money, just
different convention for where the ","'s and "."'s go. e.g. moving the decimal
place 3 places would mean if you had 1.00000 before, now it shows it as
1,000.00./nRe: Switch to GPL

Bitcointalk

2010-09-12 19:24:53 UTC - Original Post

If the only library is closed source, then there's a project to make an open
source one.If the only library is GPL, then there's a project to make a non-GPL
one.If the best library is MIT, Boost, new-BSD or public domain, then we can stop
re-writing it.I don't question that GPL is a good license for operating systems,
especially since non-GPL code is allowed to interface with the OS. Â For smaller
projects, I think the fear of a closed-source takeover is overdone./nRe: Memory
leak

Bitcointalk

2010-09-19 17:22:03 UTC - Original Post

Bouncing between 0 and 2 connections could be if it's connecting to itself. Are
you using the "-connect" switch?Did you compile it or is this a release build, and
what version? I'm not sure how the 200Kb/sec, since it waits at least a half second
between connection attempts. How fast is it flickering between 0 and 2
connections? Faster than twice a second?The wait function on linux is:inline void
Sleep(int64 n){Â Â boost::thread::sleep(boost::get_system_time() +
boost::posix_time::milliseconds(n));}If that doesn't work right, then it would be
possible for it to spin through the loop as fast as it can./nRe: Issues building
bitcoin on Windows 7

Bitcointalk

2010-09-19 18:46:46 UTC - Original Post

The lines it's tripping on:Code:ERROR extern map<string, string>
mapAddressBook;ERROR extern CCriticalSection cs_mapAddressBook;ERROR extern
vector<unsigned char> vchDefaultKey;OK extern bool fClient;OK extern int
nBestHeight;OK extern unsigned int nWalletDBUpdated;ERROR extern DbEnv dbenv;So
it's acting like nothing is defined, not even map and vector.Yet, db.h is included
by headers.h (and only there, nowhere else) which includes vector, map, util.h and
everything before db.h.Is VC trying to use precompiled headers and screwing it up?
Â Could there be some leftover precompiled header files in your directory from
previously failed attempts that it's finding and using?There's an installer package
now that makes it really easy to install MinGW. Don't use the latest version
4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0. A setup program
completely installs everything, it's not hard like it used to be. I think the
only thing I had to do was rename make*.exe something to make.exe.http://tdm-
gcc.tdragon.net/Off topic, but: It would be nice if someone would hack on getting
tcatm's 4-way 128-bit SSE2 code working on Windows. There's something with
MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on
the stack, that makes it segfault. With some fiddling, I was able to get his code
to work in a test program, but not in Bitcoin itself for some reason./nRe: Bug?
/usr/bin/bitcoind ""

Bitcointalk

2010-09-19 19:58:11 UTC - Original Post

I don't know anything about any of the bug trackers. If we were to have one, we
would have to make a thoroughly researched choice.We're managing pretty well just
using the forum. I'm more likely to see bugs posted in the forum, and I think
other users are much more likely to help resolve and ask follow up questions here
than if they were in a bug tracker. A key step is other users helping resolve the
simple stuff that's not really a bug but some misunderstanding or confusion.I keep
a list of all unresolved bugs I've seen on the forum. In some cases, I'm still
thinking about the best design for the fix. This isn't the kind of software where
we can leave so many unresolved bugs that we need a tracker for them./nRe: The case
for removing IP transactions

Bitcointalk

2010-09-19 21:49:30 UTC - Original Post

Probably best to disable receiving by IP unless you specifically intend to use
it. This is a lot of surface area that nobody uses that doesn't need to be open
by default.In storefront cases, you would typically only want customers to send
payments through your automated system that only hands out bitcoin addresses
associated with particular orders and accounts. Random unidentified payments
volunteered to the server's IP address would be unhelpful.In general, sending by IP
has limited useful cases. If connecting directly without a proxy, the man-in-the-
middle risk may be tolerable, but no privacy. If you use a privacy proxy, man-in-
the-middle risk is unacceptably high. If we went to all the work of implementing
SSL, only large storefronts usually go to the trouble of getting a CA cert, but
most of those cases would still be better off to use bitcoin addresses.I uploaded
this change to SVN rev 156. The switch to enable is "-allowreceivebyip".Senders
with this version will get the error "Recipient is not accepting transactions sent
by IP address". Older version senders will get "Transfer was not accepted".I used
a different name for the switch because "-allowiptransactions" sounds like it
includes sending. If there's a better name for the switch, we can change it
again./nRe: Message Encryption as a built-in feature?

Bitcointalk

2010-09-19 22:47:00 UTC - Original Post

Theymos already said this... ECDSA does not support encrypting messages. Only
digital signatures./nRe: Always pay transaction fee?

Bitcointalk

2010-09-23 16:08:35 UTC - Original Post

Quote from: satoshi on September 08, 2010, 05:30:14 PMThe current threshold is
200KB per block, or about 1000 transactions per block. Â I think it should be
lowered to 50KB per block. Â That would still be more than 100 times the average
transactions per block.I implemented this change in SVN rev 157.The reason I
previously made it so high was to allow very large transactions without hitting the
transaction fee. Â The threshold was around 26,000 BTC for transactions made of 50
BTC generated coins. Â Even though it was 100 times easier to generate back then,
only a few people ever encountered the fee at that level. Â The new threshold puts
it at around 11,000 BTC for sending generated coins. Â It would mostly only be
reached with generated bitcoins. Â If you bought your bitcoins, they'll be
denominated in larger transactions and won't be anywhere near the fee limit, unless
you bought them in several hundred separate transactions. Â Even if you do reach
the fee level, you only have to pay it once to bundle your little transactions
together./nInternal version number

Bitcointalk

2010-09-23 16:19:08 UTC - Original Post

In the next release (0.3.13), I'm going to change the format of the internal
version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last
number represents changes on the SVN between releases and ought to be properly
represented in the version number. Otherwise, it would be a pain if we had a
mistake or something in one of the sub versions that needed to be worked
around./nRe: Warning : Check your system ( Help me )

Bitcointalk

2010-09-23 16:28:25 UTC - Original Post

I don't understand, are you under the impression that the program sets the system
clock? It doesn't.Quote from: Cdecker on September 19, 2010, 08:14:08 PMWe
already have ways to synchronize (approximately) the clients, so why not make use
of that?We use an internal offset based on the median of other nodes' times, but
for security reasons we don't let them offset us by more than an hour. If they
indicate we're off by more than an hour, then we resort to alerting the user to fix
their clock./nRe: Porn

Bitcointalk

2010-09-23 17:56:55 UTC - Original Post

Bitcoin would be convenient for people who don't have a credit card or don't want
to use the cards they have, either don't want the spouse to see it on the bill or
don't trust giving their number to "porn guys", or afraid of recurring
billing./nRe: Make your "we accept Bitcoin" logo

Bitcointalk

2010-02-08 01:22:29 UTC - Original Post

No, sorry. I've been meaning to redo it. The largest icon that still looks
good is the 20x20 one which is used for the tray icon in GNOME. Any larger than
that looks bad. The 16x16 and 20x20 ones have quite a bit of hand tweaking to get
the pixels to work out right. If you just scale down a larger image, the pixels
end up blurred and awkward in places where the lines in "BC" don't land square on a
pixel.The best 16x16 with full alpha channel is in src/rc/bitcoin.ico. I don't
like the 32x32 version.I'm attaching bitcoin20x20.png, the 20x20 version with full
transparency./nRe: How divisible are bitcoins - the technical side

Bitcointalk

2010-09-23 18:39:56 UTC - Original Post

I would not encourage using the extra decimal places. They're only intended for
future use.You are correct that above 0.01 can still have additional precision, but
the recipient won't be able to see it. The UI will show it rounded down./nRe:
Internal version number

Bitcointalk

2010-09-23 18:46:20 UTC - Original Post

I don't think it should cause any problems for version comparisons. 31300 >
312./nRe: How To Make a Distributed BitCoin Escrow Service

Bitcointalk

2010-09-26 17:34:26 UTC - Original Post

It's not implemented yet, but the network can support a transaction that requires
two signatures. It's described here:http://bitcointalk.org/index.php?
topic=750.0It's absolutely safer than a straight payment without escrow, but not as
good as a human arbitrated escrow, assuming you trust the human enough.In this kind
of escrow, a cheater can't win, but it's still possible for you to lose. It at
least takes away the profit motive for cheating you. The seller is assured that
the money is reserved for him, while the buyer retains the leverage that the seller
hasn't been paid yet until completion./nRe: I broke my wallet, sends never confirm
now.

Bitcointalk

2010-09-30 16:38:53 UTC - Original Post

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;/nRe: I broke my wallet,
sends never confirm now.

Bitcointalk

2010-09-30 16:59:00 UTC - Original Post

0.3.13 release candidate, please test:http://www.bitcoin.org/download/bitcoin-
0.3.13-rc1-win32-setup.exe/n0.3.13 RC1 for Windows, please test

Bitcointalk

2010-09-30 17:04:15 UTC - Original Post

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
LinuxGavin Andresen:- option -rpcallowip= to accept json-rpc connections from
another machine- clean shutdown on SIGTERM on Linux/nRe: BitCoin Wikipedia page
DELETED!!!

Bitcointalk

2010-09-30 17:50:32 UTC - Original Post

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./nRe: Prioritized transactions, and tx fees

Bitcointalk

2010-09-30 18:11:56 UTC - Original Post

It ramps up the fee requirement as the block fills up:<50KB Â free50KB Â
0.01250KB Â 0.02333KB Â 0.03375KB Â 0.04etc.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./nRe: Prioritized transactions, and tx fees

Bitcointalk

2010-09-30 18:22:22 UTC - Original Post

True, the switch should be something more dynamic that pays per KB. It's harder
to think of how to explain it./nRe: Remote RPC access

Bitcointalk

2010-09-30 18:27:41 UTC - Original Post

It can be safe if you're using it over your own LAN, like if you have multiple
servers at a location that talk to each other.0.3.13 RC1 is available for
Windows:http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe/nBitcoin
client and website translation

Bitcointalk

2010-02-08 01:27:02 UTC - Original Post

Thank you for the offer to help translate. Â That is probably the best way you
could help.I will need to prepare the code for translation first. Â wxWidgets has
locale support, and most strings are in generated code that is already wrapped, so
it shouldn't be too hard. Â We also must finish upgrading to wxWidgets-2.9.0 to get
UTF-8 support. Â I've done test builds with 2.9.0 and there is one bug left to fix.
What operating system are you using? Â Windows, Linux 32-bit or 64 bit?Split from
another thread.sirius-m/nRe: 0.3.13 RC1 for Windows, please test

Bitcointalk

2010-10-01 00:32:46 UTC - Original Post

 Too late for 0.3.13, but I'll try to find time to add it to the next
version./nVersion 0.3.13, please upgrade

Bitcointalk

2010-10-01 00:34:35 UTC - Original Post

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/nRe: Version 0.3.13

Bitcointalk

2010-10-03 18:17:06 UTC - Original Post

Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PMThat'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?/nRe:
Version 0.3.13, please upgrade

Bitcointalk

2010-10-03 19:39:06 UTC - Original Post

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.zipSHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-
0.3.13.1-specialbuild-linux64.tar.gzThe 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./nRe: Version 0.3.13, please upgrade

Bitcointalk

2010-10-03 19:49:32 UTC - Original Post

Quote from: tcatm on October 03, 2010, 07:45:45 PM983 Mhash/s box.Seriously?Â
What hardware is that?/nRe: Version 0.3.13, please upgrade
 Bitcointalk

2010-10-03 20:02:24 UTC - Original Post

Code:
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";
/nRe: Version 0.3.13, please upgrade

Bitcointalk

2010-10-03 20:54:07 UTC - Original Post

Quote from: theymos on October 03, 2010, 08:09:51 PMArtForz 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.Quote from: theymos on
October 03, 2010, 08:09:51 PMThe person who originally sent the broken transactions
deleted his walletSigh... why delete a wallet instead of moving it aside and
keeping the old copy just in case? Â You should never delete a wallet.Quote from:
tcatm on October 03, 2010, 08:10:47 PMIt'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./nRe:
[PATCH] increase block size limit

Bitcointalk

2010-10-03 21:07:28 UTC - Original Post

 Quote from: theymos on October 03, 2010, 08:28:39 PMApplying 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./nRe: How to overthrow the GPU
Oligarchs

Bitcointalk

2010-10-03 21:30:04 UTC - Original Post

Quote from: theymos on October 02, 2010, 06:11:11 AMQuote from: lzsaver on
October 02, 2010, 05:49:47 AMCan 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./nRe:
Version 0.3.13, please upgrade

Bitcointalk

2010-10-03 21:43:20 UTC - Original Post

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./nBitcoin client and website
translation

Bitcointalk

2010-02-08 16:10:37 UTC - Original Post

It's much easier to have a single binary and multiple .mo files. It's too much
maintenance work to have lots of build variations. Once the software support is
implemented, anyone could contribute translations.wxWidgets uses the gettext
standard. You use the gettext tools or something like poedit to create a .po file
by scanning the sourcefiles for strings and editing the translations into the .po
file, then compile it into a .mo file. The program loads the .mo file at runtime
and reskins all the strings. Additional languages can be added to an existing
program by adding .mo files without recompiling the program.On Windows, the .mo
files would go in a lang subdirectory in the directory where the EXE is
located.Right now I'm working on JSON-RPC and command line support, but when I'm
finished with that I hope to do this next./nRe: Memory leak

Bitcointalk

2010-10-03 22:07:00 UTC - Original Post

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?/nRe: Version
0.3.13, please upgrade

Bitcointalk

2010-10-03 23:46:19 UTC - Original Post

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./nRe: Website and
software translations

Bitcointalk

2010-10-04 01:44:41 UTC - Original Post

Thanks eurekafag, Russian translation added to SVN rev 160./nRe: Website and
software translations

Bitcointalk

2010-10-04 19:21:01 UTC - Original Post

Quote from: eurekafag on October 04, 2010, 10:55:56 AMWhere can I find the latest
English .po file to keep the translation up-to-date?poedit does it. Â Either get
the src directory from a release, or download it with SVN. Â Place your .po file 3
directories deep under the src directory. Â Open it with poedit and do Catalog-
>Update from sources.So for example, you have:srcsrc\base58.hsrc\bignum.h...src\
util.cppsrc\util.hsrc\xpmsrc\locale\ru\LC_MESSAGES\bitcoin.poOpen bitcoin.po with
poedit, do Catalog->Update from sources. Â It looks for the sourcecode up 3
directories (..\..\..) from where bitcoin.po is.This updates your existing .po file
you already worked on and adds any news strings. Â It may try to match close
strings, so check things over and make sure it didn't make any bad guesses.Make
sure you use the .po file I uploaded to SVN or in a release, because I always fix
up at least a few things. I'm attaching your Russian one to this message./nRe:
[PATCH] increase block size limit

Bitcointalk

2010-10-04 19:48:40 UTC - Original Post

It can be phased in, like:if (blocknumber > 115000)Â Â Â maxblocksize =
largerlimitIt can start being in versions way ahead, so by the time it reaches that
block number and goes into effect, the older versions that don't have it are
already obsolete.When we're near the cutoff block number, I can put an alert to old
versions to make sure they know they have to upgrade./nRe: Website and software
translations

Bitcointalk

2010-10-06 15:42:39 UTC - Original Post

poedit reorganised the file for some reason. Â I re-ran update from sources and
it put it back in the original order so it's fine now. Â Did you run it on a drive
where files aren't sorted alphabetically, like a FAT drive or USB flash drive?
Strings aren't added or changed very often. Â It's months before enough changes
build up.I uploaded the changes.This Windows build has the Russian translation in
it:http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe/nRe: I broke my
wallet, sends never confirm now.

Bitcointalk

2010-10-06 16:54:23 UTC - Original Post

That's going to be more of a SelectCoins thing.SVN rev 161 has a refinement to
recursively determine if your own unconfirmed transactions can be spent. This is
needed because you should be able to spend your own change right away.The new
recursive determination is: 0/unconfirmed can be spent if it's yours and all its
dependencies are either in a block or also yours.Here's a Windows
build:http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exeThis version
is an improvement if you already had a 0/unconfirmed transaction and might have
already spent it. If you were the original creator of a 0/unconfirmed
transaction, you still need theymos' patch instead./nRe: Tor connections not
working reliably, many seednodes offline

Bitcointalk

2010-10-06 17:36:41 UTC - Original Post

Maybe you were just unlucky to have an exit node without reverse lookup.The IRC
server's response doesn't look like it was disconnecting you for that. It's
supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out.I
see the problem. The IRC code is looking for various phrases to see when the
server is ready to receive your NICK, but it's not looking for that particular
phrase. I'll fix it.I don't know if it's really required to wait for the server
to finish looking up hostname before sending nick.How long did it take to get
connected with TOR the first time, having to use the seed nodes?/nRe: The Niche
List

Bitcointalk

2010-10-06 23:10:31 UTC - Original Post

Quote from: kiba on September 23, 2010, 04:00:16 PM1. Download site like
rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin
can possibly take both roles and streamline the whole process.Repeating myself
here, but there is open source software for that, so it would just be a matter of
bolting on a Bitcoin payment mechanism. Â One good one I found was Mihalism Multi
Host. Â It's designed as a free host, so it would just need a few tweaks to loosen
up restrictions consistent with paid use./nKey pool feature for safer wallet backup

Bitcointalk

2010-10-09 20:19:33 UTC - Original Post

SVN rev 163 (ver 0.3.13.3) has the key pool feature. Â Pre-generated new keys are
aged in a queue before use, so that backups of wallet.dat hold keys you'll use in
the future.For now I made the default pool size 100. Â It can be configured with -
keypool=. Â Be aware, it takes a little time to increase the pool size, so don't go
crazy with it. Â Disk space is about 1K per key.I have not addressed the recovery
side of this yet. Â If you actually did restore an old wallet.dat, I think you may
have to delete blk*.dat to rediscover your own transactions during the
redownload.I've only tested this moderately. Â You might not want to use this for a
website server until it's had some more testing./nRe: Simple to implement feature
requests

Bitcointalk

2010-02-08 16:37:24 UTC - Original Post

There are command line options:bitcoin -addnode=1.2.3.4Â Â to tell bitcoin
about a node to connect tobitcoin -connect=1.2.3.4Â Â connect only to the
specified node(s)You can use more than one of these, for instancebitcoin -
connect=(first to try) -connect=(next to try) ...You can specify non-routable IPs
with -connect like 192.168.x.x, so if you had a server farm and you wanted one
server to connect to the world and the rest to connect to the one server, you could
do that.In particular, -addnode is needed if you're always going to connect through
TOR, since the IRC server blocks all the TOR exit nodes. To connect through TOR,
you could use:bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216/nVersion 0.3.14
 Bitcointalk

2010-10-21 16:39:27 UTC - Original Post

Version 0.3.14 is now
availablehttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/
Changes:- Key pool feature for safer wallet backupGavin Andresen:- TEST network
mode with switch -testnet- Option to use SSL for JSON-RPC connections on unix/osx-
validateaddress RPC commandeurekafag:- Russian translation/nRe: Website and
software translations

Bitcointalk

2010-10-21 22:50:47 UTC - Original Post

The order matters not to the program, but it matters to me maintaining it. Â If
it jumbles the order of the .po file then I can't diff for changes. Â I have to
update all 7 translation files when I change the English text in the program, and
it's easier when they're all in the same order.I can still put it back into normal
order by making poedit rescan it.It is normal that untranslated strings are shown
on top.Quote from: eurekafag on October 06, 2010, 07:39:36 PMBy the way, there are
some similar lines that possibly may be replaced by one. They are very close by
meaning and differs only by 1-2 words. Just a suggestion of course.I know, but not
easily without complicating the sourcecode./nRe: ERROR - PLEASE HELP ME!

Bitcointalk

2010-10-23 18:22:49 UTC - Original Post

Quote from: theymos on October 21, 2010, 10:00:26 PMhis block count remains
"stuck" at 1698.He was generating invalid blocks at difficulty 1.0. Â He must have
a corrupted entry in his blk0001.dat or blkindex.dat file. Â He just needs to
delete blk*.dat and let it redownload.The safety lockdown detected the problem and
was displaying "WARNING: Displayed transactions may not be correct!" because it saw
a longer chain existed that it was unable to accept. Â The safety lockdown cannot
stop generation or it would create an attack possibility.Quote from: gavinandresen
on October 22, 2010, 02:25:14 PMThe Bitcoin client really shouldn't allow coin
generation until you have all of the blocks up to the last block checkpoint.Good
idea, I made a change to make sure it won't generate before checkpoint block
74000./nRe: ERROR - PLEASE HELP ME!

Bitcointalk

2010-10-23 18:38:04 UTC - Original Post

OK, if it really won't get past block 1698 on redownload, then we're in stranger
territory.Yes, possibly he has antivirus software or even a router or filewall that
is pattern matching a sequence of bytes and censoring it.It would be instructive to
get knightmb's blk*.dat and see if that gets him past that point./nRe: Win7 64bit
since last patch Tues now crashes

Bitcointalk

2010-10-23 18:52:02 UTC - Original Post

Quote from: Odin on October 22, 2010, 09:24:38 PM Â Fault Module
Name:Â Â Â mingwm10.dllThis is the important clue. Â I believe it's saying it
crashed in that.  Maybe there are other versions of it to try. mingwm10.dll is
just a simple placeholder thing that satisfies some callback requirement for
multithreaded apps.Is anyone else running OK on Windows 64-bit?/nRe: Suggestion:
Allow short messages to be sent together with bitcoins ?

Bitcointalk
 2010-10-23 19:02:57 UTC - Original Post
ECDSA can't encrypt messages, only sign signatures.It would be unwise to have
permanently recorded plaintext messages for everyone to see. Â It would be an
accident waiting to happen.If there's going to be a message system, it should be a
separate system parallel to the bitcoin network. Â Messages should not be recorded
in the block chain. Â The messages could be signed with the bitcoin address
keypairs to prove who they're from./nRe: Multiple Wallets, one computer

Bitcointalk

2010-10-24 19:17:51 UTC - Original Post

I have the beginning of something like this. Â It's mostly like what Gavin
described.Some more rpc interface:move <fromaccount> <toaccount> <amount>Â Â Move
from one internal account to another. Â I think blank account name ("") will be
your default account. Â If you sell something to a user, you could do move
"theiraccount" "" 123.45.  Is "move" the best name for this?  I shied away from
"transfer" because that sounds too close to sending a transaction.I'm thinking a
new function getaccountaddress instead of overloading
getnewaddress:getaccountaddress <account>Â Â Gives you an address allocated from
getnewaddress <account>. Â It'll keep giving the same address until something is
received on the address, then it allocates a new address. Â (It automatically does
what the sample code I posted some time ago did)Would these commands make it
possible in simple cases to implement your website without needing a database of
your own?/nRe: Multiple Wallets, one computer

Bitcointalk

2010-10-25 16:53:53 UTC - Original Post

Here's some pseudocode of how you would use the account based commands. It sure
makes website integration a lot easier.print "send to " +
getaccountaddress(username) + " to fund your account"print "balance: " +
getbalance(username, 0)print "available balance: " + getbalance(username, 6)// if
you make a sale, move the money out of their accountmove(username, "", amount, 6)//
withdrawalsendfrom(username, bitcoinaddress, amount, 6)/nRe: Win7 64bit since last
patch Tues now crashes

Bitcointalk

2010-10-25 17:27:47 UTC - Original Post

The only thing I can think of is to see if there are other versions of
mingwm10.dll you can get. Â mingwm10.dll is a tiny little DLL that came with the
MinGW compiler that you need when you build for multi-thread. Â I don't know
exactly what it does, but it probably just says something like "yes Windows, see
I'm in a DLL like you insisted."The end of your debug.log file might show the last
thing it was doing before it crashed./nRe: New icon/logo

Bitcointalk

2010-11-13 00:55:51 UTC - Original Post

I'm happy if someone with artistic skill wants to contribute alternatives. Â The
icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. Â I
think it's the best program icon, but there's room for improvement at larger sizes
for a graphic for use on websites.It'll be a lot simpler if authors could make
their graphics public domain./nRepost: Bitcoin Maturation

Bitcointalk

2009-11-22 18:31:44 UTC - Original Post

 --------------------bitcoinbitcoin:Bitcoin MaturationPosted:Thu 01 of Oct, 2009
(14:12 UTC)From the user's perspective the bitcoin maturation process can be broken
down into 8 stages.1. The initial network transaction that occurs when you first
click Generate Coins.2. The time between that initial network transaction and when
the bitcoin entry is ready to appear in the All Transactions list.3. The change of
the bitcoin entry from outside the All Transaction field to inside it.4. The time
between when the bitcoin appears in the All Transfers list and when the Description
is ready to change to Generated (50.00 matures in x more blocks).5. The change of
the Description to Generated (50.00 matures in x more blocks).6. The time between
when the Description says Generated (50.00 matures in x more blocks) to when it is
ready to change to Generated.7 The change of the Description to Generated.8. The
time after the Description has changed to Generated.Which stages require network
connectivity, significant local CPU usage and or significant remote CPU usage? Do
any of these stages have names?--------------------sirius-m:Re: Bitcoin
MaturationPosted:Thu 22 of Oct, 2009 (02:36 UTC)As far as I know, there's no
network transaction when you click Generate Coins - your computer just starts
calculating the next proof-of-work. The CPU usage is 100% when you're generating
coins.In this example, the network connection is used when you broadcast the
information about the proof-of-work block you've created (that which entitles you
to the new coin). Generating coins successfully requires constant connectivity, so
that you can start working on the next block when someone gets the current block
before you./nRe: DEB Package?

Bitcointalk

2010-02-12 02:33:02 UTC - Original Post

Are you just trying to run the program or do you really need to compile it?Â
There's a 32-bit linux binary that can be run on 64-bit ubuntu if you "sudo apt-get
ia32-libs".http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-
linux.tar.gz/downloadI recently updated the SVN for building on 64-bit Karmic with
wxWidgets 2.9.0. This was after the 0.2.0 release. The 0.2.0 release did not
build on 64-bit yet.Unfortunately there currently isn't a -dev deb package of
either of the versions of wxWidgets that we can use. On Karmic they only have the
UTF-16 version. We need either the ANSI (libwxgtk2.8-ansi-dev) version or the
UTF-8 (wxWidgets 2.9.0) version. We're moving towards 2.9.0.I know you said you
didn't want VM, but as a last resort, last I checked the Windows version runs fine
in Wine./nRe: Some testing that I did on the testnetwork, my findings.

Bitcointalk

2010-11-13 23:25:26 UTC - Original Post

Thank you for limiting flood tests to the testnet.Version 0.3.15 combines several
features to help legitimate transactions jump the queue during a flood attack.Â
The key was Gavin's idea for prioritising transactions based on the age of their
dependencies. Every coin is entitled to turn over so often. The longer waited,
the more priority accumulates. Priority is sum(valuein * age) / txsize.Â
Transaction fee still takes precedence over priority, and priority determines the
order of processing within a fee strata.In support of the priority feature,
SelectCoins only uses your own 0 conf transactions only as a last resort if that's
all you have left. This helps keep you from turning your coins over rapidly
unless you're forcing it by actually turning all your coins over rapidly./nVersion
0.3.15

Bitcointalk

2010-11-13 23:26:40 UTC - Original Post

Version 0.3.15 is now available.Changes:- paytxfee switch is now per KB, so it
adds the correct fee for large transactions- sending avoids using coins with less
than 6 confirmations if it can- BitcoinMiner processes transactions in priority
order based on age of dependencies- make sure generation doesn't start before block
74000 downloaded- bugfixes by Dean Gores- testnet, keypoololdest and paytxfee added
to getinfo/nRe: Some testing that I did on the testnetwork, my findings.

Bitcointalk

2010-11-14 16:53:19 UTC - Original Post

Quote from: ByteCoin on November 13, 2010, 11:55:11 PMOf course, if the network
is not being flooded and you're not overly concerned about the current transaction
getting held up then it's probably worth preferring to use your 0 conf transactions
so that you can "save" the higher priority coins for when the network is being
flooded.You should use at least some priority in case a flood comes along before
the next block.As long as all dependencies have at least 1 conf, if the transaction
doesn't have enough priority at first, the dependencies will age until it
does.QuoteGaming the system  by including 1000 or so recently turned over BTC to
bump the priority as described in my post above still works of course! Or managing
how much priority you spend on a transaction. Â The software would have to know
your future plans to know whether to spend your priority now or save it for later.
 I don't think we'll need to get into that much detail though.  There's a wide
enough difference between normal users and flooders.Priority doesn't have to do
everything. Â Once you know there's a flood, you can add -paytxfee=0.01.Â
Hopefully with priority, your transactions before that should be at worst slow, not
stuck./nRe: Need OP_BLOCKNUMBER to allow "time" limited transactions

Bitcointalk

2010-11-15 18:37:44 UTC - Original Post

We can't safely do OP_BLOCKNUMBER. Â In the event of a block chain reorg after a
segmentation, transactions need to be able to get into the chain in a later block.
 The OP_BLOCKNUMBER transaction and all its dependants would become invalid.
 This wouldn't be fair to later owners of the coins who weren't involved in the
time limited transaction.nTimeLock does the reverse. Â It's an open transaction
that can be replaced with new versions until the deadline. Â It can't be recorded
until it locks. Â The highest version when the deadline hits gets recorded. Â It
could be used, for example, to write an escrow transaction that will automatically
permanently lock and go through unless it is revoked before the deadline. Â The
feature isn't enabled or used yet, but the support is there so it could be
implemented later./nRe: Transaction / spam flood attack currently under way

Bitcointalk

2010-11-19 23:50:24 UTC - Original Post

Quote from: creighto on November 19, 2010, 08:29:12 PMPerhaps in addition to the
age priority rule recently implimented, there should be a minimum age rule without
a transaction fee. Â Said another way, perhaps a generation rule that says that a
free transaction must be 3 blocks deep before it can be transfered again for free.
 This will still allow real users to immediately spend new funds if they have to,
while still permitting real users to reshuffle funds to suit their needs without an
overhead cost. Â I think that this would significantly inhibit the type of spamming
attack that is currently underway.I'm doing something like that. Â Priority is a
more formalised version of the concept you're describing.Quote from: FreeMoney on
November 19, 2010, 05:39:44 PMAs it stands now 3.15 has a lot of free transaction
space and that space is given first to transactions with the highest
[age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion
of the free space require [age]*[value]/[size] > C ?Maybe set C so that a standard
1BTC transaction can get into the main free area on the next block. And a .1 can
get in after waiting about 10 blocks. And make the area which allows
[age]*[value]/[size] < C to let in about a dozen transactions or so.Yes, like this.
 And the no-priority-requirement area is 3K, about a dozen transactions per
block.I just uploaded SVN rev 185 which has a minimal priority requirement for free
transactions. Â Transaction floods are made up of coins that are re-spent over and
over, so they depend on their own 0 conf transactions repeatedly. Â 0 conf
transactions have 0 priority, so free transactions like that will have to wait for
one transaction to get into a block at a time.Version 0.3.15 doesn't write
transactions using 0 conf dependencies unless that's all it has left, so normal
users shouldn't usually have a problem with this.I think this is a good compromise
short of making the default fee 0.01. Â It's not so much to ask that free
transactions can only be used to turn coins over so often. Â If you're using free
transactions, you're taking charity and there has to be some limit on how often you
can use it with the same coins.We've always said free transactions may be processed
more slowly. Â You can help ensure your transactions go through quickly by adding -
paytxfee=0.01./nRe: OpenCL miner for the masses

Bitcointalk

2010-11-20 17:24:20 UTC - Original Post

Quote from: m0mchil on November 20, 2010, 10:16:19 AMupdated to SVN 186Thanks
m0mchil for keeping up on the updates!GPU miners, please upgrade as soon as
possible to shut down the free transaction abuse! Â This version has the new
priority-based limit on free transaction spam.Quote from: m0mchil on November 16,
2010, 10:30:41 AMJust updated to SVN 181 and fixed getwork patch to wait 60 seconds
between rebuilding the block with new transactions. This is actually the behavior
of the original client, was forgotten in the patch by mistake. Â Fixes heavy CPU
usage on every getwork request (this became obvious with recent heavy transaction
spam). Please upgrade.Before SVN 184, compiling transactions into a block used an
n^2 algorithm. Â The new efficient single-pass algorithm is orders of magnitude
quicker. Â (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker)/nNew
getwork

Bitcointalk

2010-11-23 19:50:12 UTC - Original Post

I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version
31601)m0mchil's external bitcoin miner idea has solved a lot of problems. Â GPU
programming is immature and hard to compile, and I didn't want to add additional
dependencies to the build. Â getwork allows these problems to be solved separately,
with different programs for different hardware and OSes. Â It's also convenient
that server farms can run a single Bitcoin node and the rest only run getwork
clients.The interface has a few changes:getwork [data]If [data] is not specified,
returns formatted hash data to work on:Â Â "midstate" : precomputed hash state
after hashing the first half of the data  "data" : block data  "hash1" :
formatted hash buffer for second hash  "target" : little endian hash targetIf
[data] is specified, tries to solve the block and returns true if it was
successful. Â [data] is the same 128 byte block data that was returned in the
"data" field, but with the nonce changed.Notes: - It does not return work when you
submit a possible hit, only when called without parameter.- The block field has
been separated into data and hash1.- data is 128 bytes, which includes the first
half that's already hashed by midstate.- hash1 is always the same, but included for
convenience.- Logging of "ThreadRPCServer method=getwork" is disabled, it would be
too much junk in the log./nRe: New getwork

Bitcointalk

2010-11-23 20:55:27 UTC - Original Post

It's not an exact drop-in replacement. Â I wanted to clean up the interface a
little. Â It only requires a few changes.ScanHash_ functions aren't going away.
 BTW, the interface of this is designed to mirror the parameters of that
(midstate, data, hash1)./nRe: New getwork
 Bitcointalk

2010-11-24 17:21:01 UTC - Original Post

Quote from: jgarzik on November 24, 2010, 04:47:42 AMI suspect something weird
going on with ByteReverse (or lack thereof). Â It's quite unclear whether or not
'data' and 'nonce' must be byte-reversed, and in what way.getwork does the byte-
reversing. Â midstate, data and hash1 are already big-endian, and you pass data
back still big-endian, so you work in big-endian and don't have to do any byte-
reversing. Â They're the same data that is passed to the ScanHash_ functions. Â You
can take midstate, data and hash1, put them in 16-byte aligned buffers and pass
them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1,
nHashesDone). Â If a nonce is found, patch it into data and call getwork.I should
probably change the ScanHash_ functions to use pdata instead of pdata + 64 so
they're consistent.target is little endian, it's supposed to be the same as how
m0mchil's did it. Â (if it's not, then it should be fixed) Â That's the only case
where you would use byte reverse. Â I think you do it like: if
ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].Quote from: DiabloD3
on November 24, 2010, 11:31:11 AMSatoshi, please fix your implementation of getwork
so it complies with m0mchill's specificationThis is the new spec. It shouldn't be
hard to update your miner to use it.The changes are:- It does not return work when
you submit a possible hit, only when called without parameter.- The block field has
been split into data and hash1.- state renamed to midstate for consistency.-
extranonce not needed./nRe: OpenCL miner for the masses

Bitcointalk

2010-11-24 17:53:09 UTC - Original Post

A revised version of getwork is now in the official client, but the miners need
to be updated a little to use it./nRe: What's with this odd generation?

Bitcointalk

2010-02-12 03:08:08 UTC - Original Post

There's a small transaction fee for very large transactions. Â The node that
generates the block that contains the transaction gets the fee.If the same money
gets sent again, it won't incur the fee again. Â If all you have is generated coins
in your wallet, if you send them all in one huge transaction, it has to bundle
hundreds of 50 bc coins together. Â After that it's just one line to send the
combined unit./nRe: RFC: ship block chain 1-74000 with release tarballs?

Bitcointalk

2010-11-25 17:51:39 UTC - Original Post

It's not the downloading that takes the time, it's verifying and indexing
it.Bandwidthwise, it's more efficient than if you downloaded an archive. Bitcoin
only downloads the data in blk0001.dat, which is currently 55MB, and builds
blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the
disk activity.During the block download, it only flushes the database to disk every
500 blocks. You may see the block count pause at ??499 and ??999. That's when
it's flushing.Doing your own verifying and indexing is the only way to be sure your
index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted
source, there's no way to know if you can trust all the contents in them.Maybe
Berkeley DB has some tweaks we can make to enable or increase cache
memory./nVersion 0.3.17

Bitcointalk

2010-11-25 20:07:36 UTC - Original Post

 Version 0.3.17 is now available. Changes:- new getwork, thanks m0mchil- added
transaction fee setting in UI options menu- free transaction limits- sendtoaddress
returns transaction id instead of "sent"- getaccountaddress <account>The UI
transaction fee setting was easy since it was still there from 0.1.5 and all I had
to do was re-enable it.The accounts-based commands: move, sendfrom and getbalance
<account> will be in the next release. Â We still have some more changes to make
first.Downloads:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.3.17//nRe: RFC: ship block chain 1-74000 with release tarballs?

Bitcointalk

2010-11-26 17:32:01 UTC - Original Post

I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not
the bottleneck. Â Initial download took 1 hour 20 minutes.If it's taking a lot
longer than that, certainly 24 hours, then it must be downloading from a very slow
node, or your connection is much slower than around 15KB per sec (120kbps), or
something else is wrong. Â It would be nice to know what appears to be the
bottleneck when that happens.Every 10 minutes or so when the latest block is sent,
it should have the chance to change to a faster node. Â When the latest block is
broadcast, it requests the next 500 blocks from other nodes, and continues the
download from the one that sends it fastest. Â At least, that's how it should
work.Quote from: jgarzik on November 26, 2010, 02:07:43 AMQuote from: satoshi on
November 25, 2010, 05:51:39 PMMaybe Berkeley DB has some tweaks we can make to
enable or increase cache memory.Which of the ACID properties do you need, while
downloading?It may only need more read caching. Â It has to read randomly all over
blk0001.dat and blkindex.dat to index. Â It can't assume the file is smaller than
memory, although it currently still is. Â Caching would be effective, since most
dependencies are recent.Someone should experiment with different Berkeley DB
settings and see if there's something that makes the download substantially faster.
 If something substantial is discovered, then we can work out the
particulars.QuoteAdding BDB records is simply appending to a log file, until you
issue a checkpoint. Â The checkpoint then updates the main database file.We
checkpoint every 500 blocks./nRe: Version 0.3.17

Bitcointalk

2010-11-26 18:23:30 UTC - Original Post

Laszlo does them, but I haven't asked him to do one for a while because there
wasn't anything major. I'll ask him to do this version./nRe: New getwork

Bitcointalk

2010-11-26 21:31:13 UTC - Original Post

That's what it does, it returns true/false./nRe: New demonstration CPU miner
available

Bitcointalk

2010-11-26 22:02:41 UTC - Original Post

You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp. Â It compiles fine
as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in
simple tests on Windows, but not when linked in with Bitcoin. Â It may have a
better chance of working as part of a C program instead of C++.Currently it's only
enabled in the Linux build, so if you get it to work you could make it available to
Windows users. Â It's about 100% speedup on AMD CPUs./nRe: Cooperative mining

Bitcointalk

2010-11-28 16:03:30 UTC - Original Post

 ribuck's description is spot on.Pool operators can modify their getwork to take
one additional parameter, the address to send your share to.The easy way for the
pool operator would be to wait until the next block is found and divy it up
proportionally as:user's near-hits/total near-hits from everyoneThat would be
easier and safer to start up. Â It also has the advantage that multiple hits from
the same user can be combined into one transaction. Â A lot of your hits will
usually be from the same people.The instant gratification way would be to pay a
fixed amount for each near-hit immediately, and the operator takes the risk from
randomness of having more or less near-hits before a block is found. Either way,
the user who submits the hit that solves the block should get an extra amount off
the top, like 10 BTC.New users wouldn't really even need the Bitcoin software.
 They could download a miner, create an account on mtgox or mybitcoin, enter their
deposit address into the miner and point it at anyone's pool server. Â When the
miner says it found something, a while later a few coins show up in their
account.Miner writers better make sure they never false-positive near-hits. Users
will depend on that to check if the pool operator is cheating them. Â If the miner
wrongly says it found something, users will look in their account, not find
anything, and get mad at the pool operator./nRe: RFC: ship block chain 1-74000 with
release tarballs?

Bitcointalk

2010-11-28 17:13:01 UTC - Original Post

Despite everything else said, the current next step is:QuoteSomeone should
experiment with different Berkeley DB settings and see if there's something that
makes the download substantially faster. Â If something substantial is discovered,
then we can work out the particulars.In particular, I suspect that more read
caching might help a lot.Quote from: jgarzik on November 28, 2010, 02:33:29
AMAnother new user on IRC, Linux this time, was downloading at a rate of 1 block
every 4 seconds -- estimated total download time around 4 days.Then something more
specific was wrong. Â That's not due to normal initial download time. Â Without
more details, it can't be diagnosed. Â If it was due to slow download, did it speed
up after 10-20 minutes when the next block broadcast should have made it switch to
a faster source? Â debug.log might have clues. Â How fast is their Internet
connection? Â Was it steadily slow, or just slow down at one point?QuoteWe have the
hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so
there's no reason why we shouldn't be able to automatically download a compressed
zipfile of the block database from anywhere, unpack it, verify it, and start
running.The 74000 checkpoint is not enough to protect you, and does nothing if the
download is already past 74000. Â -checkblocks does more, but is still easily
defeated. Â You still must trust the supplier of the zipfile.If there was a "verify
it" step, that would take as long as the current normal initial download, in which
it is the indexing, not the data download, that is the bottleneck.Quote from:
jgarzik on November 28, 2010, 07:33:55 AMPresumably at some point there will be a
lightweight client that only downloads block headers, but there will still be
hundreds of thousands of those...80 bytes per header and no indexing work. Â Might
take 1 minute.Quoteuncompressed data using a protocol (bitcoin P2P) that wasn't
designed for bulk data transfer.The data is mostly hashes and keys and signatures
that are uncompressible.The speed of initial download is not a reflection of the
bulk data transfer rate of the protocol. Â The gating factor is the indexing while
it downloads./nRe: Is safe running bitcoins with the same wallet on more computers
simultaneously?

Bitcointalk

2010-11-28 18:06:39 UTC - Original Post

QuoteWill it be synchronized automatically?Very much not. Â Using multiple copies
of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed
to defeat that. Â Both copies will get screwed up.If you're trying to consolidate
your generated coins into one wallet, a better solution now is to run getwork
miners on the additional systems. Â jgarzik has a CPU miner, and it supports
tcatm's 4-way SSE2, so on Windows it's up to twice as fast as the built-in SHA if
you have an AMD or recent Intel (core 3, 5 or 7).New demonstration CPU miner
available:http://bitcointalk.org/index.php?topic=1925.0/nRe: RFC: ship block chain
1-74000 with release tarballs?

Bitcointalk

2010-11-29 20:19:12 UTC - Original Post

It seems like you're inclined to assume everything is wrong more than is actually
so.Writing the block index is light work. Â Building the tx index is much more
random access per block. Â I suspect reading all the prev txins is what's slow.
 Read caching would help that.  It's best if the DB does that.  Maybe it has a
setting for how much cache memory to use.Quote1) bitcoin should be opening
databases, not just environment, at program startup, and closing database at
program shutdown. Already does that. Â See CDB. Â The lifetime of the (for
instance) CTxDB object is only to support database transactions and to know if
anything is still using the database at shutdown.QuoteAnd, additionally, bitcoin
forces a database checkpoint, pushing all transactions from log into main
database.If it was doing that it would be much slower. Â It's supposed to be only
once a minute or 500 blocks:Â Â Â if (strFile == "blkindex.dat" &&
IsInitialBlockDownload() && nBestHeight % 500 != 0)Â Â Â Â Â nMinutes = 1;Â Â
 dbenv.txn_checkpoint(0, nMinutes, 0);Probably should add this:   if (!
fReadOnly)Â Â Â Â Â dbenv.txn_checkpoint(0, nMinutes, 0);Quote2) For the initial
block download, txn commit should occur once every N records, not every record. Â I
suggest N=1000.Does transaction commit imply flush? Â That seems surprising to me.
 I assume a database op wrapped in a transaction would be logged like any other
database op. Â Many database applications need to wrap almost every pair of ops in
a transaction, such as moving money from one account to another. (debit a, credit
b) Â I can't imagine they're required to batch all their stuff up themselves.In the
following cases, would case 1 flush once and case 2 flush twice?case
1:writewritewritewritecheckpointcase 2:begin transactionwritewritecommit
transactionbegin transactionwritewritecommit transactioncheckpointContorting our
database usage will not be the right approach. Â It's going to be BDB settings and
caching./nRe: DEB Package?

Bitcointalk

2010-02-12 15:57:37 UTC - Original Post

Quote from: soultcer on February 12, 2010, 02:31:50 PMIf you want, I can provide
you with a precompiled binary.Am I missing something? Is there something wrong
with the 32-bit linux precompiled binary on bitcoin.org?The bitcoin binary in the
distribution static links the wxWidgets library, and its shared links (openssl and
GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull
down dependencies.Since we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't
have a DEB package yet, we'll continue to need to static link it./nRe: Incompatible
wallet format with latest bitcoin-git ?

Bitcointalk

2010-11-30 19:02:31 UTC - Original Post

What was this wallet used with? Â An early accounts patch or git build?It's while
loading the wallet. Â I assume it must be in this:Â Â Â else if (strType ==
"acentry")Â Â Â {Â Â Â Â Â string strAccount;Â Â Â Â Â ssKey >>
strAccount;Â Â Â Â Â uint64 nNumber;Â Â Â Â Â ssKey >> nNumber;Â Â Â Â
 if (nNumber > nAccountingEntryNumber)       nAccountingEntryNumber =
nNumber;Â Â Â }You could check that with this:Â Â Â else if (strType ==
"acentry")Â Â Â {Â Â Â Â Â string strAccount;Â Â Â Â Â assert(!
ssKey.empty());Â Â Â Â Â ssKey >> strAccount;Â Â Â Â Â uint64 nNumber;Â Â Â
  if (ssKey.size() != 8 )       printf("***** %s %d\n",
strAccount.c_str(), ssKey.size());Â Â Â Â Â assert(ssKey.empty() == false);Â Â
   ssKey >> nNumber;     if (nNumber > nAccountingEntryNumber)  Â
    nAccountingEntryNumber = nNumber;   }Was there an interim version of
accounts on git at some point that had just ("acentry", "account") for the key?If
you have gdb, you could run it in gdb and do a backtrace. gdb --args
bitcoin ...run(wait for exception)bt/nRe: RFC: ship block chain 1-74000 with
release tarballs?

Bitcointalk

2010-12-01 21:25:39 UTC - Original Post

That's a good optimisation. I'll add that next time I update SVN.More
generally, we could also consider this:Â Â Â Â
dbenv.set_lk_max_objects(10000);Â Â Â Â
dbenv.set_errfile(fopen(strErrorFile.c_str(), "a")); /// debug   Â
dbenv.set_flags(DB_AUTO_COMMIT, 1);+Â Â Â Â dbenv.set_flags(DB_TXN_NOSYNC, 1);Â
   ret = dbenv.open(strDataDir.c_str(),           Â
 DB_CREATE   |             DB_INIT_LOCK |  Â
          DB_INIT_LOG  |We would then rely on
dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes./nRe:
Wikileaks contact info?

Bitcointalk

2010-12-05 09:08:08 UTC - Original Post

Quote from: RHorning on December 04, 2010, 10:17:44 PMBasically, bring it on.Â
Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or
fallout from that act.No, don't "bring it on".The project needs to grow gradually
so the software can be strengthened along the way.I make this appeal to WikiLeaks
not to try to use Bitcoin. Bitcoin is a small beta community in its infancy.Â
You would not stand to get more than pocket change, and the heat you would bring
would likely destroy us at this stage./nRe: JSON-RPC method idea: list transactions
newer than a given txid

Bitcointalk

2010-12-08 20:21:49 UTC - Original Post

It's not safe to use listtransactions this way.I know I've been criticized for
being reluctant about listtransactions. Â Let me explain my reluctance.Transactions
are dynamic. Â Past transactions can become unconfirmed, go away and come back,
become invalid and disappear, or be replaced by a different double-spend. Â Their
date can change, their order can change.Programmers are naturally inclined to want
to use listtransactions like this: feed me the new transactions since I last asked,
and I'll keep my own tally or static record of them. Â This will seem to work in
all regular use, but if you use the amounts for anything, it is highly
exploitable:1) How do you know if a past transaction becomes invalid and
disappears?2) When there's a block-chain reorg, it would be easy to double-count
transactions when they get confirmed again.3) A transaction can be replaced by a
double-spend with a different txid. Â You would count both spends.The model where
you assume you only need to see new transactions because you've already seen
previous transactions is not true. Â Old transactions can change at any time.Any
time you take an action based on payment amounts received, you always need to go
back to bitcoin and ask for a current balance total (or use move or sendfrom), and
be ready for the possibility that it can go down.Now that we have the Accounts
feature making it easier to do it the right way, we're better prepared to have
listtransactions./nRe: JSON-RPC method idea: list transactions newer than a given
txid
 Bitcointalk

2010-12-08 22:36:45 UTC - Original Post

Then how do you cope with the issues I listed in the message you quoted?/nVersion
0.3.18

Bitcointalk

2010-12-08 23:19:24 UTC - Original Post

Changes:- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17
and then upgraded again- IsStandard() check to only include known transaction types
in blocks- Jgarzik's optimisation to speed up the initial block download a
littleThe main addition in this release is the Accounts-Based JSON-RPC commands
that Gavin's been working on (more details at http://bitcointalk.org/index.php?
topic=1886.0). Â - getaccountaddress- sendfrom- move- getbalance-
listtransactionsDownload:http://sourceforge.net/projects/bitcoin/files/Bitcoin/
bitcoin-0.3.18//nRe: JSON-RPC method idea: list transactions newer than a given
txid

Bitcointalk

2010-12-09 00:12:17 UTC - Original Post

I'm not talking about the normal risk for a given minconf level, I'm talking
about additional pitfalls from listtransactions when used this way.Quote from:
satoshi on December 08, 2010, 10:36:45 PM2) When there's a block-chain reorg, it
would be easy to double-count transactions when they get confirmed again.The OP's
example of listtransactions <account> [count=10] [txid] seems to imply and it would
be very easy for programmers to assume that if they pass in the last txid of the
previous call to listtransactions, they will never see the same transaction more
than once, which is not the case. Â It would be very easy to double-count payments
if you don't maintain your own persistent map or dictionary to track which txid's
you've already accepted.It doesn't seem right to have a function that seems tailor
made to be used a certain obvious way, and that way is a non-obvious trap.Quote
from: jgarzik on December 08, 2010, 11:07:22 PMQuote from: satoshi on December 08,
2010, 10:36:45 PM3) A transaction can be replaced by a double-spend with a
different txid. Â You would count both spends. listtransactions does not add
anything to this problem, beyond that which is already vulnerable through
listreceivedbyaddress.Suppose both spends are to the same address.
 getreceivedbyaddress would always count only one or the other spend at any given
time, never both.Using listtransactions, it would be very easy to count both. Â You
see the first spend, you count it. Â You see the second spend, you count it.
 Total is double counted./nRe: Version 0.3.18

Bitcointalk

2010-12-09 14:37:05 UTC - Original Post

New transaction templates can be added as needed. Â Within a few days, there will
be plenty of GPU power that accepts and works on it. Â Network support will be
thorough long before there'll be enough clients who understand how to receive and
interpret the new transaction.Timestamp hashes are still already possible:txin:
0.01txout: 0.00 Â <appid, hash> OP_CHECKSIGfee: 0.01 If there's an actual
application like BitDNS getting ready to actually start inserting hashes, we can
always add a specific transaction template for timestamps.I like Hal Finney's idea
for user-friendly timestamping. Â Convert the hash of a file to a bitcoin address
and send 0.01 to it:Quote from: Hal on December 05, 2010, 11:43:56 PMI thought of a
simple way to implement the timestamp concept I mentioned above. Run sha1sum on the
file you want to timestamp. Convert the result to a Bitcoin address, such as via
http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that
address.The money will be lost forever, as there is no way to spend it further, but
the timestamp Bitcoin address will remain in the block chain as a record of the
file's existence.I understand that this is arguably not a good use of the Bitcoin
distributed database, but nothing stops people from doing this so we should be
aware that it may be done./nRe: Version 0.3.18

Bitcointalk

2010-12-09 15:17:53 UTC - Original Post

I came to agree with Gavin about whitelisting when I realized how quickly new
transaction types can be added.Quote from: nanotube on December 09, 2010, 06:19:05
AMwhy not make it easier on everyone and just allow say, 64 or 128 bytes of random
data in a transaction?That's already possible. Â <pubkey> OP_CHECKSIG. Â <pubkey>
can be 33 to 120 bytes.I also support a third transaction type for timestamp hash
sized arbitrary data. Â There's no point not having one since you can already do it
anyway. Â It would tell nodes they don't need to bother to index it./nRe: JSON-RPC
method idea: list transactions newer than a given txid

Bitcointalk

2010-12-09 18:08:08 UTC - Original Post

Quote from: jgarzik on December 09, 2010, 12:58:05 AMI agree with you and satoshi
about "txs after <txid>". Â My listtransactions (now xlisttransactions) patch
pointedly does not have that feature, and never has.As long as the interface is
designed for things like showing the user the last N transactions history, it's
fine, now that we have the Accounts feature making it easier to do payment
detection the right way.Gavin, could listtransactions have an option to list
transactions for all accounts?I'm not sure what the interface could be,
maybe:listtransactions <JSON null type> [count]It would be hard to do that from the
command line though. I can't think of a good solution for the interface, that's the
problem. Maybe "*" special case like "" is.  Everyone would have to make sure no
user can create account name "*".Quote from: jgarzik on December 09, 2010, 04:13:50
PMSure, and that's easy enough to track with transactions.I don't get how that's
"easy" to track with transactions./nRe: Repost: Request: Make this anonymous?

Bitcointalk

2010-02-12 17:28:32 UTC - Original Post

True, sending by IP through Tor trades one problem for another. The Tor exit
node can see the text of your message and potentially MITM you.Best to only send to
bitcoin addresses then. Payments by bitcoin address are broadcast over the
network as part of the normal network traffic. All communications with the
network are broadcasts of public information./nRe: Automated nightly builds

Bitcointalk

2010-12-09 18:28:45 UTC - Original Post

Thanks for setting this up Cdecker. Is there any chance of getting it to build
the GUI version also? If this is Ubuntu, if you get wxWidgets 2.9.0 it should
just be a matter of following the steps in build-unix.txt exactly. Is this an
environment where you can build wxWidgets once and leave it there and just keep
using it?/nRe: BitDNS and Generalizing Bitcoin

Bitcointalk

2010-12-09 21:02:42 UTC - Original Post

I think it would be possible for BitDNS to be a completely separate network and
separate block chain, yet share CPU power with Bitcoin. The only overlap is to
make it so miners can search for proof-of-work for both networks simultaneously.The
networks wouldn't need any coordination. Miners would subscribe to both networks
in parallel. They would scan SHA such that if they get a hit, they potentially
solve both at once. A solution may be for just one of the networks if one network
has a lower difficulty.I think an external miner could call getwork on both
programs and combine the work. Maybe call Bitcoin, get work from it, hand it to
BitDNS getwork to combine into a combined work.Instead of fragmentation, networks
share and augment each other's total CPU power. This would solve the problem that
if there are multiple networks, they are a danger to each other if the available
CPU power gangs up on one. Instead, all networks in the world would share
combined CPU power, increasing the total strength. It would make it easier for
small networks to get started by tapping into a ready base of miners./nRe: BitDNS
and Generalizing Bitcoin

Bitcointalk

2010-12-09 22:46:50 UTC - Original Post

Quote from: nanotube on December 09, 2010, 09:20:40 PMseems that the miner would
have to basically do "extra work". and if there's no reward from the bitdns mining
from the extra work (which of course, slows down the main bitcoin work), what would
be a miner's incentive to include bitdns (and whatever other side chains) ?The
incentive is to get the rewards from the extra side chains also for the same
work.While you are generating bitcoins, why not also get free domain names for the
same work?If you currently generate 50 BTC per week, now you could get 50 BTC and
some domain names too.You have one piece of work. Â If you solve it, it will solve
a block from both Bitcoin and BitDNS. Â In concept, they're tied together by a
Merkle Tree. Â To hand it in to Bitcoin, you break off the BitDNS branch, and to
hand it in to BitDNS, you break off the Bitcoin branch.In practice, to retrofit it
for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's
not a big deal. Â You've been talking about 50 domains per block, which would dwarf
that little 200 bytes per block for backward compatibility. Â We could potentially
schedule a far in future block when Bitcoin would upgrade to a modernised
arrangement with the Merkle Tree on top, if we care enough about saving a few
bytes.Note that the chains are below this new Merkle Tree. Â That is, each of
Bitcoin and BitDNS have their own chain links inside their blocks. Â This is
inverted from the common timestamp server arrangement, where the chain is on top
and then the Merkle Tree, because that creates one common master chain. Â This is
two timestamp servers not sharing a chain./nRe: Fees in BitDNS confusion

Bitcointalk

2010-12-09 23:58:54 UTC - Original Post

Not locktime.There's a possible design for far in the future:You intentionally
write a double-spend. Â You write it with the same inputs and outputs, but this
time with a fee. Â When your double-spend gets into a block, the first spend
becomes invalid. Â The payee does not really notice, because at the moment the new
transaction becomes valid, the old one becomes invalid, and the new transaction
simply takes its place.It's easier said than implemented. Â There would be a fair
amount of work to make a client that correctly writes the double-spend, manages the
two versions in the wallet until one is chosen, handles all the corner cases.
 Every assumption in the existing code is that you're not trying to write double-
spends.There would need to be some changes on the Bitcoin Miner side also, to make
the possibility to accept a double-spend into the transaction pool, but only
strictly if the inputs and outputs match and the transaction fee is higher.
 Currently, double-spends are never accepted into the transaction pool, so every
node bears witness to which transaction it saw first by working to put it into a
block./nRe: BitDNS and Generalizing Bitcoin

Bitcointalk
 2010-12-10 17:29:28 UTC - Original Post
Piling every proof-of-work quorum system in the world into one dataset doesn't
scale.Bitcoin and BitDNS can be used separately. Â Users shouldn't have to download
all of both to use one or the other. Â BitDNS users may not want to download
everything the next several unrelated networks decide to pile in either.The
networks need to have separate fates. Â BitDNS users might be completely liberal
about adding any large data features since relatively few domain registrars are
needed, while Bitcoin users might get increasingly tyrannical about limiting the
size of the chain so it's easy for lots of users and small devices.Fears about
securely buying domains with Bitcoins are a red herring. Â It's easy to trade
Bitcoins for other non-repudiable commodities.If you're still worried about it,
it's cryptographically possible to make a risk free trade. Â The two parties would
set up transactions on both sides such that when they both sign the transactions,
the second signer's signature triggers the release of both. Â The second signer
can't release one without releasing the other./nAccounts example code

Bitcointalk

2010-12-10 19:21:03 UTC - Original Post

Some sample pseudocode using the new Accounts based commands in 0.3.18.print
"send to " + getaccountaddress(username) + " to fund your account"print "balance: "
+ getbalance(username, 0)print "available balance: " + getbalance(username, 6)// if
you make a sale, move the money from their account to your "" accountif
(move(username, "", amount, 6, "purchased item"))Â Â Â SendTheGoods()//
withdrawalsendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user")You
can use listtransactions(username) to show them a list of their recent
transactions./nRe: BitDNS and Generalizing Bitcoin

Bitcointalk

2010-12-10 19:55:12 UTC - Original Post

Quote from: Hal on December 10, 2010, 07:14:04 PMadditional block chains would
each create their own flavor of coins, which would trade with bitcoins on
exchanges? These chain-specific coins would be used to reward miners on those
chains, and to purchase some kinds of rights or privileges within the domain of
that chain?Right, the exchange rate between domains and bitcoins would float.A
longer interval than 10 minutes would be appropriate for BitDNS.So far in this
discussion there's already a lot of housekeeping data required. Â It will be much
easier if you can freely use all the space you need without worrying about paying
fees for expensive space in Bitcoin's chain. Â Some transactions:Changing the IP
record.Name change. Â A domain object could entitle you to one domain, and you
could change it at will to any name that isn't taken. Â This would encourage users
to free up names they don't want anymore. Â Generated domains start out blank and
the miner sells it to someone who changes it to what they want. Â Renewal. Â Could
be free, or maybe require consuming another domain object to renew. Â In that case,
domain objects (domaincoins?) could represent the right to own a domain for a year.
 The spent fee goes to the miners in the next block fee./nRe: BitDNS and
Generalizing Bitcoin

Bitcointalk

2010-12-10 20:19:39 UTC - Original Post

I agree. All transactions, IP changes, renewals, etc. should have some fee that
goes to the miners.You might consider a certain amount of work to generate a
domain, instead of a fixed total circulation. Â The work per domain could be on a
schedule that grows with Moore's Law. Â That way the number of domains would grow
with demand and the number of people using it./nRe: BitDNS and Generalizing Bitcoin

Bitcointalk
 2010-12-11 13:08:30 UTC - Original Post
@dtvan: all 3 excellent points. 1) IP records don't need to be in the chain, just
do registrar function not DNS. Â And CA problem solved, neat.2) Pick one TLD, .web
+1.3) Expiration and significant renewal costs, very important.Quote from: joe on
December 11, 2010, 10:53:58 AMHowever, thinking more about this now I support
inclusion of additional coinbases / tracking systems in the main network. The
reason for doing this is so as not to water down CPU power into multiple networks.
We want one strong network, so the network should be versatile.Avoiding CPU power
fragmentation is no longer a reason. Â Independent networks/chains can share CPU
power without sharing much else. Â See: http://bitcointalk.org/index.php?
topic=1790.msg28696#msg28696 and http://bitcointalk.org/index.php?
topic=1790.msg28715#msg28715/nRe: Bitcoin and buffer overflow attacks

Bitcointalk

2010-12-11 13:32:37 UTC - Original Post

Quote from: da2ce7 on December 11, 2010, 05:49:22 AMdirect to IP address
transfers seems like a obvious surface area to attack.If you ever find anyone who
turned it on. It's disabled by default.Quote from: witchspace on December 11,
2010, 09:59:40 AMThere is no way to be absolutely sure that there are no buffer
overflow attacks. Although it would help to implement the client in a language that
doesn't have buffer overflows because it checks array indices (Python, Java,
C#, ...).It's all STL. There are almost no buffers./nRe: DEB Package?

Bitcointalk

2010-02-13 01:38:37 UTC - Original Post

I couldn't get wxWidgets 2.8.9 to compile on Karmic 64-bit either.I have been
compiling the latest SVN on Karmic 64-bit with wxWidgets 2.9.0, which compiles fine
on 64-bit. Â Read build-unix.txt and use the given ../configure parameters on
wxWidgets so you can use the makefile.unix.wx2.9 as supplied. Â (--enable-debug --
disable-shared --enable-monolithic)There's one cosmetic bug with 2.9.0 I still need
to fix where the status number display is bunched up for some reason. -- fixedThe
download link on the homepage is to the sourceforge tar.gz archive which contains
the 32-bit binary and the 0.2.0 sources, which were not yet buildable on 64-bit at
the time.The SVN was first buildable on 64-bit with wx2.9.0 on 28 January
2010.Hopefully they'll have a wxWidgets 2.9.0 debian package someday./nRe:
minimalistic bitcoin client on D language?

Bitcointalk

2010-12-11 22:07:04 UTC - Original Post

Quote from: Hal on December 11, 2010, 08:08:45 PMI'd like to hear some specific
criticisms of the code. To me it looks like an impressive job, although I'd wish
for more comments. Now I've mostly studied the init, main, script and a bit of net
modules. This is some powerful machinery.That means a lot coming from you, Hal.Â
Thanks./nRe: PC World Article on Bitcoin

Bitcointalk

2010-12-11 23:39:16 UTC - Original Post

It would have been nice to get this attention in any other context. WikiLeaks
has kicked the hornet's nest, and the swarm is headed towards us./nAdded some DoS
limits, removed safe mode (0.3.19)

Bitcointalk

2010-12-12 18:22:33 UTC - Original Post

 There's more work to do on DoS, but I'm doing a quick build of what I have so far
in case it's needed, before venturing into more complex ideas. Â The build for this
is version 0.3.19.- Added some DoS controlsAs Gavin and I have said clearly before,
the software is not at all resistant to DoS attack. Â This is one improvement, but
there are still more ways to attack than I can count. Â I'm leaving the -
limitfreerelay part as a switch for now and it's there if you need it.- Removed
"safe mode" alerts"safe mode" alerts was a temporary measure after the 0.3.9
overflow bug. Â We can say all we want that users can just run with "-
disablesafemode", but it's better just not to have it for the sake of appearances.
 It was never intended as a long term feature.  Safe mode can still be triggered
by seeing a longer (greater total PoW) invalid block
chain.Builds:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.3.19//nBitcoin open source implementation of P2P currency

P2P Foundation

2014-03-06 00:00:00 UTC - Original Post

I am not Dorian Nakamoto./nRe: What's with this odd generation?

Bitcointalk

2010-02-14 06:28:03 UTC - Original Post

Quote from: theymos on February 12, 2010, 08:31:52 AMDoes the sending client send
more BitCoins to account for the fee (so the recipient gets what he's expecting)?
Yes.Quote from: SmokeTooMuch on February 12, 2010, 01:11:09 PMwhy do we even need
fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!Almost
all transactions are free. A transaction is over the maximum size limit if it has
to add up more than 500 of the largest payments you've received to make up the
amount. A transaction over the size limit can still be sent if a small fee is
added.The average transaction, and anything up to 500 times bigger than average, is
free.It's only when you're sending a really huge transaction that the transaction
fee ever comes into play, and even then it only works out to something like 0.002%
of the amount. It's not money sucked out of the system, it just goes to other
nodes. If you're sad about paying the fee, you could always turn the tables and
run a node yourself and maybe someday rake in a 0.44 fee yourself./nRe: What's with
this odd generation?

Bitcointalk

2010-02-14 15:52:23 UTC - Original Post

Right. Â Otherwise we couldn't have a finite limit of 21 million coins, because
there would always need to be some minimum reward for generating. Â In a few
decades when the reward gets too small, the transaction fee will become the main
compensation for nodes. I'm sure that in 20 years there will either be very large
transaction volume or no volume./nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-02-15 06:28:38 UTC - Original Post

14/02/2010 00000000654657000000000000000000000000000000000000000000000000002009Â
   1.0030/12/2009 1.18  +18%11/01/2010 1.31  +11%25/01/2010Â
1.34Â Â +2%04/02/2010Â 1.82Â Â +36%14/02/2010Â 2.53Â Â +39%Another big jump
in difficulty yesterday from 1.82 times to 2.53 times, a 39% increase since 10 days
ago. It was 10 days apart not 14 because more nodes joined and generated the 2016
blocks in less time./nRe: Setting up multiple bitcoin machines behind NAT

Bitcointalk

2010-02-16 01:34:56 UTC - Original Post

 Right now there isn't a port number setting to do that. Â It's a feature yet to
be implemented. Â You can only set up your NAT to port-forward to one of the
computers. Â (I said something earlier about NAT port translation, but that
wouldn't work, other nodes wouldn't know to connect to that port)If you want, as a
small optimization, you could run the rest of your computers as:bitcoin -
connect=<the IP of the first computer>so they get all their network communication
from the first computer and don't all connect over the net individually for the
same information. Â This saves bandwidth, although it doesn't use much bandwidth to
begin with, so it wouldn't really matter unless you had tons of computers.For
redundancy in case the first computer goes down, you could have two that connect
out and the rest connect to both of them. Â The first two are run normally, the
rest are run like:bitcoin -connect=<IP1> -connect=<IP2>/nRe: Proof-of-work
difficulty increasing

Bitcointalk

2010-02-16 17:36:40 UTC - Original Post

Quote from: Suggester on February 16, 2010, 02:15:49 AMSatoshi, I figured it will
take my modern core 2 duo about 20 hours of nonstop work to create ฿50.00! With
older PCs it will take forever. People like to feel that they "own" something as
soon as possible, is there a way to make the generation more divisible? So say,
instead of making ฿50 every 20 hours, make ฿5 every 2 hours? I thought about
that but there wasn't a practical way to do smaller increments. Â The frequency of
block generation is balanced between confirming transactions as fast as possible
and the latency of the network.The algorithm aims for an average of 6 blocks per
hour. Â If it was 5 bc and 60 per hour, there would be 10 times as many blocks and
the initial block download would take 10 times as long. Â It wouldn't work anyway
because that would be only 1 minute average between blocks, too close to the
broadcast latency when the network gets larger./nRepost: Request: Make this
anonymous?

Bitcointalk

2009-11-22 18:32:00 UTC - Original Post

--------------------anonguy54:Request: Make this anonymous?Posted:Thu 15 of Oct,
2009 (19:58 UTC)Are there any plans to make this service anonymous?e.g; Being able
to route BitCoin through Tor./nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-02-17 17:58:03 UTC - Original Post

Quote from: Sabunir on February 16, 2010, 08:51:51 AM. Perhaps it has to do with
my connection's very high latency (2000ms or more on average) 2 seconds of latency
in both directions should reduce your generation success by less than 1%.Quote
from: Sabunir on February 16, 2010, 08:51:51 AMand/or my high packet loss
(sometimes up to 10% loss)?Probably OK, but I'm not sure. The protocol is
designed to resync to the next message, and messages get re-requested from all the
other nodes you're connected to until received. If you miss a block, it'll also
keep requesting it every time another blocks comes in and it sees there's a gap.Â
Before the original release I did a test dropping 1 out of 4 random messages under
heavy load until I could run it overnight without any nodes getting stuck./nRe:
Bitcoin client and website translation

Bitcointalk

2010-02-17 19:19:43 UTC - Original Post

I updated the SVN with changes to support translation. Translatable strings are
all enclosed in _(""), and we're using UTF-8 on all platforms.When the program
runs, it looks in the directory of the EXE for the file: locale\<langcode>\
LC_MESSAGES\bitcoin.mo<langcode> is the two letter code of the language your OS is
set to, like "de" or "nl".On Linux, it also looks
for:/usr/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo/usr/local/share/locale/
<langcode>/LC_MESSAGES/bitcoin.mo(are there other standard places it should look on
linux?)Here's a quick walkthrough using poedit to make a .po and .mo file:-
Download the bitcoin sourcecode from SVN- In the trunk directory, mkdir locale\
<lang>\LC_MESSAGES- In poedit, File->New catalog->Paths tab- Click the "New item"
dotted rectangle button- Put "../../.." and MAKE SURE TO PRESS ENTER to add the
path- Click OK- Save the file as "bitcoin.po" in the LC_MESSAGES directory you
made- It should then scan the sourcecode and find about 170 strings- If it didn't
find anything, check Catalog->Settings->Path tab, make sure the "../../.." was
addedWhen you're done translating, commit both bitcoin.po (the editable catalog
file) and bitcoin.mo (compiled data used by the program)./nRe: Number of
connections

Bitcointalk

2010-02-21 03:43:48 UTC - Original Post

Nodes stop trying to initiate connections once they have 15. If you can accept
incoming connections, then you can get well above that from nodes connecting to
you, otherwise you max out at 15.I don't know if there's any reason to have 15
connections. Maybe it should be 10.Since nodes that can only connect out are
probably at or near 15 most of the time now, you should level off to an
equilibrium. 45 suggests a ratio of 3 out-only nodes to every 1 in-accepting
node.The number of connections won't be a good gauge of the size of the network any
more. Someone should periodically IRC to the bitcoin channel on chat.freenode.net
and count the number of users. That gives you the total count of network nodes
(except TOR nodes).Block generation is again running ahead of pace. We're in for
another big step up in difficulty at the next adjustment in about 5 days./nPost
your static IP

Bitcointalk

2010-02-21 04:19:53 UTC - Original Post

It would be nice to have a list of static IPs for new users to send test
donations to so they can see how the software works. If you can accept incoming
connections and you have a static IP address, post it here!Anything sent to these
IPs should be considered a donation. Â If you do request a round-trip, be sure to
include your return bitcoin address or IP in the comment, but please assume it'll
be one-way. Â They won't necessarily be watching for incoming transactions to send
back./nRe: Current Bitcoin economic model is unsustainable

Bitcointalk

2010-02-21 05:44:24 UTC - Original Post

Excellent analysis, xc.A rational market price for something that is expected to
increase in value will already reflect the present value of the expected future
increases. Â In your head, you do a probability estimate balancing the odds that it
keeps increasing.In the absence of a market to establish the price,
NewLibertyStandard's estimate based on production cost is a good guess and a
helpful service (thanks). Â The price of any commodity tends to gravitate toward
the production cost. Â If the price is below cost, then production slows down. Â If
the price is above cost, profit can be made by generating and selling more. Â At
the same time, the increased production would increase the difficulty, pushing the
cost of generating towards the price.In later years, when new coin generation is a
small percentage of the existing supply, market price will dictate the cost of
production more than the other way around.At the moment, generation effort is
rapidly increasing, suggesting people are estimating the present value to be higher
than the current cost of production./nUI improvements
 Bitcointalk

2010-02-21 21:48:01 UTC - Original Post

Uploaded some UI changes to SVN as version 0.2.5.Instead of View->Show Generated,
we now have tabs:- All Transactions- Sent/Received- Sent- ReceivedMakes it a lot
easier to flip to received and check for payments.Moved the "Your Addresses" book
inside the main address book. It was confusing having two address books.I found
the "To:" in "From: unknown, To: (one of your bitcoin addresses)" still confusing,
so I changed it to "From: unknown, Received with:". The bitcoin address is
abbreviated so you can see the label that you set in the Receiving tab of the
address book.Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0.I haven't
forgotten about you people who want non-UI, but I had to do some fun stuff before
more build bashing./nRe: generation slowed down dramatically

Bitcointalk

2010-02-23 00:49:56 UTC - Original Post

Just a random streak of bad luck. It looks steady to me.Competition doesn't
have an effect until the next automatic retarget adjustment, and we haven't reached
the next one yet.The adjustments are every 2016 blocks. To calculate our progress
towards the next one, divide the block total by 2016. The fractional part is how
far we are to the next one. My back-of-the-envelope projection: 42032 blocks/2016
= 20.85 = 85% of the way. About 1.5 days to go until the next one. That'll only
be about 10 days since the last one, the target is 14 days, so 14/10 = 1.4 = around
40% difficulty increase./nRe: UI improvements

Bitcointalk

2010-02-23 01:16:28 UTC - Original Post

There are now "Sending" and "Receiving" tabs in the Address Book. Your
addresses are referred to as "receiving addresses".madhatter was working on
building it on Mac. He had errors probably caused by UTF-16 wxWidgets 2.8.Â
Should have better luck now with 2.9.0. wxWidgets 2.9.0 is UTF-8 and wouldn't
have that problem.I think he had it working on FreeBSD, but he wanted a non-UI
version.I have the command line and JSON-RPC daemon version working now. Will SVN
it in a day or two.I disabled gdm on my Ubuntu system so it boots into command
line. I hope I will be able to get it enabled again with rcconf./nRe: Bitcoin
Address Collisions

Bitcointalk

2010-02-23 16:26:09 UTC - Original Post

There's a separate public/private keypair for every bitcoin address. You don't
have a single private key that unlocks everything. Bitcoin addresses are a 160-
bit hash of the public key, everything else in the system is 256-bit.If there was a
collision, the collider could spend any money sent to that address. Just money
sent to that address, not the whole wallet.If you were to intentionally try to make
a collision, it would currently take 2^126 times longer to generate a colliding
bitcoin address than to generate a block. You could have got a lot more money by
generating blocks.The random seed is very thorough. On Windows, it uses all the
performance monitor data that measures every bit of disk performance, network card
metrics, cpu time, paging etc. since your computer started. Linux has a built-in
entropy collector. Adding to that, every time you move your mouse inside the
Bitcoin window you're generating entropy, and entropy is captured from the timing
of disk ops./nRe: UI improvements

Bitcointalk
 2010-02-23 16:53:27 UTC - Original Post
Quote from: Xunie on February 23, 2010, 12:28:27 PM/etc/init.d/gdm start and it
will start gdm!Ah yes, there we go, back to normal again.The ctrl+alt+F[1-8] thing
never worked on this computer. The screen just goes haywire./nRe: Repost: Bitcoin
Maturation

Bitcointalk

2009-11-22 18:34:21 UTC - Original Post

It's important to have network connectivity while you're trying to generate a
coin (block) and at the moment it is successfully generated.1) During generation
(when the status bar says "Generating" and you're using CPU to find a proof-of-
work), you must constantly keep in contact with the network to receive the latest
block. If your block does not link to the latest block, it may not be accepted.2)
When you successfully generate a block, it is immediately broadcast to the
network. Other nodes must receive it and link to it for it to be accepted as the
new latest block.Think of it as a cooperative effort to make a chain. When you
add a link, you must first find the current end of the chain. If you were to
locate the last link, then go off for an hour and forge your link, come back and
link it to the link that was the end an hour ago, others may have added several
links since then and they're not going to want to use your link that now branches
off the middle.After a block is created, the maturation time of 120 blocks is to
make absolutely sure the block is part of the main chain before it can be spent.Â
Your node isn't doing anything with the block during that time, just waiting for
other blocks to be added after yours. You don't have to be online during that
time./nCommand Line and JSON-RPC

Bitcointalk

2010-02-23 22:15:41 UTC - Original Post

Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or
JSON-RPC.On Linux it needs libgtk2.0-0 installed, but does not need a GUI running.
 Hopefully gtk can be installed without having a windowing system installed.The
command to start as a daemon is:bitcoin -daemon [switches...]Or, to run the UI
normally and also be able to control it from command line or JSON-RPC, use the "-
server" switch.bitcoin -server [switches...]With either switch, it runs an HTTP
JSON-RPC server that accepts local socket connections on 127.0.0.1:8332. Â The port
is bound to loopback and can only be accessed from the local machine, but from any
account, not just the user it's running under.To control it from the command line,
the interface is a command name without any switches, followed by parameters if
any.bitcoin <command> [params...]For example:bitcoin getinfobitcoin
getdifficultybitcoin setgenerate truebitcoin stopIt's a simple JSON-RPC client and
prints the JSON result. Â Look at rpc.cpp for the list of commands.Web apps or
anything automated will normally use JSON-RPC directly, not command line. Â There
are JSON-RPC libraries for all the major languages. Â In script languages like PHP
and Python the syntax is as natural as calling a local function./nRe: Bitcoin
Address Collisions

Bitcointalk

2010-02-23 22:24:00 UTC - Original Post

Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PMAre generated
bitcoins encrypted with whichever address is currently displayed in the main
Bitcoin window?No, each generated transaction uses a new, single-use
address.Nothing uses the address in the main window, it's just there for
convenience for you to copy. 0.2.5 has a "New..." button next to it to make it
easy to change each time you use it./nRe: URI-scheme for bitcoin

Bitcointalk
 2010-02-24 05:57:43 UTC - Original Post
That would be nice at point-of-sale. The cash register displays a QR-code
encoding a bitcoin address and amount on a screen and you photo it with your
mobile./nRe: Command Line and JSON-RPC

Bitcointalk

2010-02-24 06:17:23 UTC - Original Post

Quote from: theymos on February 24, 2010, 03:07:37 AMQuote from: satoshi on
February 23, 2010, 10:15:41 PMOn Linux it needs libgtk2.0-0 installedWill this
requirement be removed sometime? I'd rather not have to deal with GTK.How much
"dealing with" does GTK actually require? Is it just a matter of "sudo apt-get
install libgtk2.0-0" and having some extra libraries sitting around? GTK doesn't
have to do anything, just be there for bitcoin to link to when it loads up, have
the gtk-init-check call fail because no GUI present, then it's done. It saves us
butchering everything with ifdefs and a separate compile and binary to use wxBase
just to try to avoid linking GTK./nNew icon/logo

Bitcointalk

2010-02-24 21:24:23 UTC - Original Post

New icons, what do you think? Â Better than the old one? Â Â Â Full size
530x529 image for scaling down to custom
sizes:http://www.bitcoin.org/download/bitcoin530.pngThe perspective shadow was too
thick on the larger sizes. Â I updated 32, 48 and the full size.I release these
images into the public domain (copyright-free). I request that derivative works
be made public domain./nRe: Make your "we accept Bitcoin" logo

Bitcointalk

2010-02-24 21:53:52 UTC - Original Post

If you GPL stuff, I have to avoid using it. Nothing against GPL per-se, but
Bitcoin is an MIT license project. Anything GPL please clearly mark it as
such./nRe: Command Line and JSON-RPC

Bitcointalk

2010-02-24 22:08:55 UTC - Original Post

When and how fast did memory usage increase? Right away, slowly over a long
time, or starting at some later event?I have -daemon running on ubuntu 9.10 64-bit
and memory usage is steady.It has to be something about the difference on the
server besides 64-bit. Maybe some malfunction from the lack of GUI. A memory
leak debug tool could give a clue. /nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-02-24 22:42:24 UTC - Original Post

The automatic adjustment happened earlier today.24/02/2010
0000000043b3e50000000000000000000000000000000000000000000000000024/02/2010Â 3.78Â
+49%I updated the first post./nRe: New icon/logo

Bitcointalk

2010-02-25 01:56:24 UTC - Original Post

Quote from: Sabunir on February 25, 2010, 01:47:56 AMI like them. Do they come in
higher resolutions?Yes, the original is 546x531 pixels.It looks good at larger size
too, but since the small icons are what you mostly always see, I wanted to judge it
on those first. Â I'll post larger sizes and full size a little later./nRe: Command
Line and JSON-RPC

Bitcointalk

2010-02-25 22:54:17 UTC - Original Post

OK, I made a build target bitcoind that only links wxBase and does not link
GTK. Version 0.2.7 on SVN.I split out the init and shutdown stuff from ui.cpp
into init.cpp, so now ui.cpp is pure UI. ui.h provides inline stubs if
wxUSE_GUI=0. We only have four functions that interface from the node to the
UI. In the bitcoind build, we don't link ui.o or uibase.o.Quote from: sirius-m on
February 25, 2010, 04:32:17 PMIt started increasing right away. I'll see if
valgrind can help me.Sure feels like it could be something in wxWidgets retrying
endlessly because some UI thing failed or something wasn't inited correctly. Our
hack to ignore the initialize failure and run anyway means we're in uncharted
territory. We're relying on the fact that we hardly use wx in this mode. We do
still use a few things like wxGetTranslation and wxMutex.Another way to debug would
be to run in gdb, wait until everything is quiet and all threads should be idle,
and break it and see which thread is busily doing something and what it's doing.I
suspect bitcoind will probably work fine, but I hope you can still debug the
problem./nRe: Repost: Request: Make this anonymous?

Bitcointalk

2009-11-22 18:35:15 UTC - Original Post

There will be a proxy setting in version 0.2 so you can connect through TOR.Â
I've done a careful scrub to make sure it doesn't use DNS or do anything that would
leak your IP while in proxy mode./nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-02-25 23:06:29 UTC - Original Post

The formula is based on the time it takes to generate 2016 blocks. Â The
difficulty is multiplied by 14/(actual days taken). Â For instance, this time it
took 9.4 days, so the calculation was 14/9.4 = 1.49. Â Previous difficulty 2.53 *
1.49 = 3.78, a 49% increase. I don't know what you're talking about accepting
easier difficulties./nRe: Command Line and JSON-RPC

Bitcointalk

2010-02-26 16:29:21 UTC - Original Post

wx/clipbrd.h isn't used, move it inside the #if wxUSE_GUI.Updated headers.h on
SVN.Sorry, I linked to wxbase but I had full wxWidgets on my computer.The db.h:140
class Db no member named "exisits" is stranger. pdb->get, pdb->put, pdb->del
compiled before that. Do you have version 4.7.25 of Berkeley DB?
Db::exists()http://www.oracle.com/technology/documentation/berkeley-db/db/
api_reference/CXX/frame_main.htmlhttp://www.oracle.com/technology/documentation/
berkeley-db/db/api_reference/CXX/dbexists.htmlI suppose they might have added
exists recently, using get before that./nRe: New icon/logo

Bitcointalk

2010-02-26 23:17:19 UTC - Original Post

Good suggestion. I made the B slightly lighter and the background slightly
darker. Very slightly. The foreground is now exactly the same colour as the BC
in the old one.It's kind of OK if you can't easily read the B in the 16x16. At
that size, you just need to see that it's a coin. It doesn't matter so much
what's embossed on it, just that there be some detail there because it wouldn't
look like a coin if it was a blank smooth circle.It's slightly wider than tall
because the dark perspective under it goes more to the right than down.I finished
and posted the 32x31 and 48x47 versions in the first message. I like the 48 a
lot.How does everyone feel about the B symbol with the two lines through the
outside? Can we live with that as our logo?/nRe: Command Line and JSON-RPC

Bitcointalk

2010-02-26 23:48:44 UTC - Original Post

Are you using wxWidgets 2.9.0? I don't recommend using anything other than
2.9.0.It looks like they've got a reference in the wx headers (arrstr.h) to
something outside of wxBase.Removing -D__WXDEBUG__ from bitcoin's makefile would
probably solve it.If that doesn't work and you just want to get it working, you
could edit wxWidgets include/wx/arrstr.h, line 167 and comment out the
wxASSERT_MSG./nRe: New icon/logo

Bitcointalk

2010-02-27 04:28:29 UTC - Original Post

Quote from: Cdecker on February 27, 2010, 03:24:07 AMHow about an SVG version?
That way we could automatically generate smaller and larger versions as needed.I
don't know how to do SVG, but I did the original very large, over 500 pixels
across, so it can be scaled down. Â I'll give the original when I'm finished.I had
to custom tweak each icon size so the vertical lines land square on their pixels,
otherwise they're ugly blurry and inconsistent. Â Such is the challenge of making
icons. Â The original will be good for scaling to custom sizes between 48 and 500
but not smaller./nRe: wxWidgets 2.9.0

Bitcointalk

2010-02-27 21:22:53 UTC - Original Post

Quote from: Cdecker on February 27, 2010, 05:09:59 PMLooking through the source
of 2.8.10 it appears that unicode is possible with that version too.In the Windows
world, "unicode" means UTF-16 (wchar).2.8 has two build variations, ANSI and UTF-16
(unicode). Â The UTF-16 version is the "unicode" version provided in the Debian
package. Â I believe 2.8 and its UTF-16 build labelled simply "unicode" has been
the source of build problems described in the forum. Â We were previously using 2.8
ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell. Â We
cannot compile with UTF-16.2.9 has only one version, UTF-8. Â On Windows, we set
the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets
interfaces with us in UTF-8. Â On Linux I assume the codepage is already UTF-8.
 By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need
2.9 for UTF-8 internationalization.Make sure you read build-unix.txt and configure
wxWidgets using the configure parameters given.Curious, why is it incredibly hard
to provide wxWidgets 2.9.0? Â If you mean for users, that's why we static link
it.It's unfortunate that we require so many big dependencies, but we need them
all. At least on Debian/Ubuntu, all but wxWidgets are available as packages.Â
Eventually they'll provide a 2.9 package./nRe: New icon/logo

Bitcointalk

2010-03-02 02:33:05 UTC - Original Post

We have the standard icon sizes, and the full size scales nicely to anything
else.I added the full size to the first post./nRe: Money Transfer Regulations

Bitcointalk

2010-03-03 04:28:56 UTC - Original Post

When there's enough scale, maybe there can be an exchange site that doesn't do
transfers, just matches up buyers and sellers to exchange with each other directly,
similar to how e-bay works.To make it safer, the exchange site could act as an
escrow for the bitcoin side of the payment. Â The seller puts the bitcoin payment
in escrow, and the buyer sends the conventional payment directly to the seller.
 The exchange service doesn't handle any real world money.This would be a step
better than e-bay. Â E-bay manages to work fine even though shipped goods can't be
recovered if payment falls through./nRe: Command Line and JSON-RPC

Bitcointalk

2010-03-05 01:46:25 UTC - Original Post

Quote from: sirius-m on February 24, 2010, 06:17:35 PMThis is strange... When I
start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of
remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop,
it works fine and stays at 15MB of memory usage. The server is running a 64 bit
build of Bitcoin. Maybe there's something wrong with the build or something.sirius-
m debugged this, it was 64-bit related. The fix is now available on SVN, file
util.cpp./nRe: bitcoin auto-renice-ing

Bitcointalk

2010-03-15 18:44:12 UTC - Original Post

It sets different priorities for each thread. Â The generate threads run at
PRIO_MIN. Â The other threads rarely take any CPU and run at normal.#define
THREAD_PRIORITY_LOWEST Â Â Â Â Â PRIO_MIN#define THREAD_PRIORITY_BELOW_NORMAL
  2#define THREAD_PRIORITY_NORMAL      0The priorities converted from
Windows priorities were probably from a table like this:Â Â "The following table
shows the mapping between nice values and Win32 priorities. Refer to the Win32
documentation for SetThreadPriority() for more information on Win32 priority
issues.nice value    Win32 Priority-20 to -16    THREAD_PRIORITY_HIGHEST-15
to -6 Â Â Â THREAD_PRIORITY_ABOVE_NORMAL-5 to +4 Â Â Â THREAD_PRIORITY_NORMAL+5 to
+14 Â Â Â THREAD_PRIORITY_BELOW_NORMAL+15 to +19 Â Â Â THREAD_PRIORITY_LOWEST"If
you have better values, suggestions welcome.Also, there was some advice on the web
that PRIO_PROCESS is used on Linux because threads are processes. Â If that's not
true, maybe it accounts for unexpectedly setting the priority of the whole app. Â
 // threads are processes on linux, so PRIO_PROCESS affects just the one
thread   setpriority(PRIO_PROCESS, getpid(), nPriority);/nRepost: How anonymous
are bitcoins?

Bitcointalk

2009-11-25 18:15:57 UTC - Original Post

--------------------bitcoinbitcoin:How anonymous are bitcoins?Can nodes on the
network tell from which and or to which bitcoin address coins are being sent? Do
blocks contain a history of where bitcoins have been transfered to and from? Can
nodes tell which bitcoin addresses belong to which IP addresses? Is there a command
line option to enable the sock proxy the first time that bitcoin starts? What
happens if you send bitcoins to an IP address that has multiple clients connected
through network address translation (NAT)?/nIdea for file hosting and proxy
services

Bitcointalk

2010-03-15 19:16:56 UTC - Original Post

When you want to upload an image to embed in a forum post, there are services
like imageshack, but because they're free, they limit the number of views. Â It's a
minuscule amount of bandwidth cost, but they can't just give it away for free,
there has to be something in it for them. Â It would be nice to be able to pay for
the bandwidth and avoid the limits, but conventional payments are too inconvenient
for such a minor thing.It's worse if you want to upload a file for others to
download. Â There are services like rapidshare, but they require the downloaders to
go through extra steps and delays to make them look at advertising or encourage
upgrading to a paid subscription, and they limit it to 10 or so downloads.It would
be nice if we made some free PHP code for an image and file hosting service that
charges Bitcoins. Â Anyone with some extra bandwidth quota could throw it on their
webserver and run it. Â Users could finally pay the minor fee to cover bandwidth
cost and avoid the limits and hassles. Â Ideally, it should be MIT license or
public domain.Services like this would be great for anonymous users, who have
trouble paying for things./nRe: On IRC bootstrapping

Bitcointalk

2010-03-16 19:48:47 UTC - Original Post

Thanks soultcer for talking with the Freenode staffer. Good to know it's OK at
the current size, and now they know who we are. They're supportive of projects
like TOR so I hope they would probably be friendly to us. We don't want to
overstay our welcome. If we get too big, then by the same token, we're big enough
that we don't need IRC anymore and we'll get off.We only needed IRC because nobody
had a static IP. In the early days there were some steady supporters, but they
all had pool-allocated IPs that change every few days. IRC was only intended as a
temporary solution. Bitcoin's built-in addr system is the main solution.Bitcoin
can get the list of IPs from any bitcoin node. In that sense, every node serves
as a directory server.When there are enough static IP nodes to have a good chance
that at least one will still be running by the time the current version goes out of
use, we can preprogram a seed list.How do you think we should compile the seed
list? Would it be OK to create it from the currently connected IPs that have been
static for a while?BTW, if we want to supplement by deploying separate directory
server software, may I suggest IRC? IRC is a good directory server (I've heard it
has other uses too), and there are mature IRC server implementations available that
anyone can run. Â Bitcoin's IRC client implementation is already thoroughly
tested./nRe: Idea for file hosting service

Bitcointalk

2010-03-16 20:17:34 UTC - Original Post

That's a great idea. There's a thriving business in those services, but I've
always thought the standard payment methods are at odds with privacy minded
customers.Would you consider making your software freely available so anyone could
easily set one up? I know for competitive reasons the inclination is to keep it
to yourself, but it could get an order of magnitude more use if anyone could give
proxy access to their country just by putting the software on a server.I wonder if
there are other kinds of web application servers where we would only have to tack
on the payment mechanism to an already existing system?/nRe: who is bitcoin.com

Bitcointalk

2010-03-23 15:22:41 UTC - Original Post

It's unrelated. There wasn't anything there when I started.The price of .com
registrations is lower than it should be, therefore any good name you might think
of is always already taken by some domain name speculator. Fortunately, it's
standard for open source projects to be .org./nRe: Exchange Methods

Bitcointalk

2010-03-23 17:35:34 UTC - Original Post

LR and Pecunix have many established exchanges to paper currencies by various
payment methods, and a number of vendors accept them as payment, so an exchange
link between Bitcoin and LR/Pecunix would give us 2nd-hop access to all that. Â The
possibility to cash out through them would help support the value of
bitcoins.Bitcoin has unique properties that would be complementary. Â LR/Pecunix
are easy to spend anonymously, but hard to buy anonymously and not worth the
trouble to buy in small amounts. Â Bitcoin, on the other hand, is easy to get in
small amounts anonymously. Â It would be convenient to buy LR/Pecunix with bitcoins
rather than through conventional payment methods.Most customers who convert to LR
to buy something would probably ask the seller first if they accept Bitcoin,
encouraging them to start accepting it./nRe: Idea for file hosting and proxy
services

Bitcointalk

2010-03-24 18:01:57 UTC - Original Post

Title changed.It helps that we have someone with actual experience running a
proxy service. Â Do you think Psiphon is the best one currently? Â (sometimes the
one you run was the best when you started but you found better ones later)/nRe:
Idea for file hosting and proxy services

Bitcointalk

2010-03-24 18:02:55 UTC - Original Post

Mihalism Multi Host is a popular open source PHP file hosting server.It's geared
toward image hosting, but I think by increasing the file size limit and
liberalising the allowed file extensions, it could just as easily be used for
general file upload hosting. They need the limits to keep it reasonable as a free
service, but if we bolt on a Bitcoin payment mechanism, the limits could be
relaxed.It doesn't have a bunch of client side scripting or anti-embedding junk to
rip out. It generates standard links that work normally.There's a turnover churn
in these free hosting sites. Small sites can give free image hosting, but once
one starts getting popular, it gets too swamped with moochers using them for free
bandwidth. Any site that gets well known has to become more aggressively pay-
naggy to cover bandwidth costs. It's a perfect example of a service where the
needed price point is in the no-man's-land between just a little too expensive to
be free, but too cheap for most users to take the trouble of a conventional
payment. It's in the gap between 0 and 19.95. The best they can do is try to
maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like
freeloaders. It can't really be advertising supported because the images are
embedded in other sites and downloaded without going to the hosting site.An example
of a site running the
software:http://www.imagez.ws/Forum:http://www.mihalism.net/Download:http://
code.google.com/p/mihalismmh/What do you think? If I made a Bitcoin payment
integration for this, would anyone be interested in running it? It might be the
first fully automated service available to buy with Bitcoins. The advantage it
could offer over the free services is general file upload hosting of large files
without making downloading users go to the upload site and jump through hoops. It
would give a normal link directly to the file./nRe: Could the bitcoin network be
destroyed by someone generating endless bitcoin add

Bitcointalk

2010-05-16 21:01:44 UTC - Original Post

When you generate a new bitcoin address, it only takes disk space on your own
computer (like 500 bytes). It's like generating a new PGP private key, but less
CPU intensive because it's ECC. The address space is effectively unlimited. It
doesn't hurt anyone, so generate all you want./nRe: For a website taking payments
with bitcoins, better: IP or bitcoin addresses?

Bitcointalk

2010-05-16 21:37:36 UTC - Original Post

Quote from: Xunie on May 14, 2010, 09:52:53 PMI suggest we disable IP
transactions while the user uses a Proxy!Just to be on the safe side.That's a good
idea. At the very least a warning dialog explaining that it'll connect to the IP
and send the information cleartext, giving the chance to cancel./nRe: URI-scheme
for bitcoin

Bitcointalk

2010-05-16 22:37:21 UTC - Original Post

Quote from: Karmicads on May 01, 2010, 06:06:53 AMA freenet URI is like
this:http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F
1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdfThere you go, we
could easily do it the same way, like:http://127.0.0.1:8330/?
to=<bitcoinaddress>;amount=<amount>Bitcoin can answer port 8330 on local loopback
just as it does for JSON-RPC on 8332. Â It would give an HTTP answer.Quote from:
DataWraith on May 02, 2010, 11:13:09 AMA bitcoin-link should be more like mailto:
than magnet: IMHO.I think we can do that.Although it would be possible for Bitcoin
to take care of business in the HTTP response by presenting HTML UI to the user, as
a user I would wonder if some website is trying to trick me or if I'm really
talking to my own Bitcoin server.The HTTP response could simply be HTML with the
JavaScript equivalent of the back button, sending it back to the page. Â Bitcoin
then pops up the Send Bitcoins dialog with the destination bitcoin address and
amount already filled in. Â It would work just like a mailto: link that pops up a
new email with the address filled in.127.0.0.1 loopback is accessible by any user
on the machine, it doesn't have per-user separation, but it's OK because it would
only serve the convenience function of pre-filling the fields in a dialog. Â You'd
still have to press Send. Â We'd have to make sure the Send button is not selected
so it couldn't jump into the foreground while you're typing a space or enter./n