The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday. The Amazon Machine Images I used to do the builds are available: ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64
(mac build will be done soon) If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file: maxsendbuffer=10000
maxreceivebuffer=10000
... or download the new version. |
|
|
|
|
fopen() is a standard C library call; it is weird Bitcoin can't find it.
Is anybody else running bitcoin on OSX 10.5 ? I'm running 10.6.6; Laszlo does the OSX builds, I'll ask him what he's running.
|
|
|
|
I was editing the bitcoin.org homepage to update the download links, and I couldn't resist make a few changes: - I removed the "If you are running version 0.3.9 or earlier please update" message. People running really old versions of bitcoin SHOULD update, but there is no longer any security risk if they don't.
- I replaced "there were X blocks as of Y date" with a link to jgarzik's Bitcoin Watch site.
- I made the SHA1 checksums at the bottom of the page tooltips of the download links. I think it is easier to match up checksums to filenames that way, and I think it looks less intimidating for people who have no idea what SHA means.
PS: I read the thread about replacing the self-signed bitcoin.org security certificate, and agree that needs to be done... |
|
|
|
Nice analysis! I'm tempted to put a link to your post in the code as a comment... The whole transaction prioritization scheme was written by Satoshi after I suggested that de-prioritizing "small new" transactions might help the spamming problem. In the last couple of days we've exchanged email about possibly modifying it; pull request 88 is the first suggested change (it makes the CreateTransaction fee calculations match the CreateBlock calculations). Until somebody finishes implementing lightweight ' headers-only block download', we should try to keep block size small-- otherwise new users will have to wait an even longer time before being able to use bitcoin. Also: the Faucet is now paying a 0.01 BTC fee per transaction. With the CreateTransaction fix, it probably would be anyway (the transactions it creates look very spammy). |
|
|
|
Seems like it would be useful if the GUI client had an option similar to the bitcoind "sendfrom" functionality. Do you think this would be impossible to try and get into the client? Am I just wasting my time?  I'm willing to do the work and write some code for review, but I don't want to go down that road if it's something everyone would basically vote down at review time. I wouldn't have any objections to changes that let you decide which input transactions or receiving addresses to choose when sending coins, as long as it is well-tested, follows the coding guildelines (see coding.txt in the source directory) and it doesn't make the "I just want to send some coins" case look more complicated (maybe hide it behind an Advanced... button in the Send dialog). |
|
|
|
fread failed means bitcoin couldn't read some data off of your hard disk. You might want to invest in a copy of SpinRite and check your hard disk for errors. |
|
|
|
Myers-Briggs tests are crap, very similar to horoscopes.
There was a good Skeptoid podcast about it. Our brains are really good at pattern-matching, and are really good at fooling us into seeing patters where none exist. |
|
|
|
Please help test: https://github.com/bitcoin/bitcoin/pull/95Sets the -maxsendbuffer and -maxreceivebuffer limits to 10MB each (so possible max of 2GB of memory if you had 100 connections). I tested by running a 0.3.20 node to act as server, then ran a client with: -connect={server_ip} -noirc -nolisten ... to make sure I was downloading the block chain from that 0.3.20 node. |
|
|
|
Couldn't peers theoretically need to send 500 MB in response to a getblocks request? The limit should perhaps be MAX_BLOCK_SIZE*500.
500MB per connection times 100 connections would be 50 GB. That re-opens the door to a memory exhaustion denial-of-service attack, which is the problem -maxsendbuffer fixes. As transaction volume grows I think there will be lots of things that need optimization/fixing. One simple fix would be to request fewer blocks as they get bigger, to stay inside the sendbuffer limit... (ps: I've been re-downloading the current block chain connected to a -maxsendbuffer=10000 0.3.20 node, and the workaround works) |
|
|
|
That's code to parse JSONs. There's a Python library to work with JSON-RPC.
Huh? See that 'import json' statement at the top? That would be the standard (as of python 2.6) JSON parsing library. The code I posted tells the standard JSON parsing library to read JSON Numbers as Decimal. If you are doing monetary calculations in python, then you should be using Decimal. That is what it is for. |
|
|
|
|
Oops.
My fault-- I DID test downloading the entire production block chain with a 0.3.20 client, but I wasn't careful to make sure I downloaded it from another 0.3.20 client.
Workaround: if you are running 0.3.20, run with -maxsendbuffer=10000
|
|
|
|
You can't open and close the file; it is not thread-safe (thread one closes fp and sets it to NULL and sleeps, thread two wakes up and uses a NULL fp). And you can't wrap the open/close in a CRITICAL_SECTION, because logging happens at shutdown, CRITICAL_SECTION relies on a destructor to work properly, and you can't control the order in which C++ destructors are called during shutdown. I learned all that the hard way a few releases back. You can rotate the logs using the "copytruncate" feature of logrotate. |
|
|
|
genjix: here is how to do it right in Python2.6 :
import decimal
import json
# From http://stackoverflow.com/questions/1960516/python-json-serialize-a-decimal-object
class DecimalEncoder(json.JSONEncoder):
def _iterencode(self, o, markers=None):
if isinstance(o, decimal.Decimal):
return (str(o) for o in [o])
return super(DecimalEncoder, self)._iterencode(o, markers)
decimal.setcontext(decimal.Context(prec=8))
print json.dumps(decimal.Decimal('10.001'), cls=DecimalEncoder)
print json.dumps({ "decimal" : decimal.Decimal('1.1'), "float" : 1.1, "string" : "1.1" }, cls=DecimalEncoder)
print json.loads('{"blaa": 0.333331}', parse_float=decimal.Decimal)
Produces output: 10.001
{"decimal": 1.1, "float": 1.1000000000000001, "string": "1.1"}
{u'blaa': Decimal('0.333331')}
Note that EVEN IF YOU PASSED THE 'WRONG' strings to Bitcoin, Bitcoin would do the right thing. That is, these two are equivalent once they are parsed by bitcoin: sendtoaddress FOO 10.000999999999999
sendtoaddress FOO 10.001
... because bitcoin does proper rounding. On the bitcoin side, this is a non-issue. And if code on the other end of the JSON-RPC connection does the wrong thing (truncates values like 10.000999999999999 instead of rounding them to the nearest 8'th decimal place) then that's a bug in that code. |
|
|
|
|
Can we not beat this dead horse?
I think there are MUCH more important things to work on / worry about than whether or not "send 1 BTC" is expressed as "sendtoaddress FOO 1.00" or "sendtoaddress FOO 100000000" in the JSON-RPC.
How about we (I'll start) write a "Proper Money Handling" page for the Wiki that discusses the issue and gives code example of how to convert to/from JSON double-precision floating point and 64-bit integer?
|
|
|
|
|
Because JavaScript doesn't have a 64-bit integer type (all Numbers in JavaScript are double-precision floating point).
|
|
|
|
|
If there is a virus on your computer, and your bitcoins are stored on that computer, then there is nothing the bitcoin software can do to prevent that virus from eventually stealing your coins.
That said, allowing you to 'lock' your coins with a password, and requiring that you enter that password to send coins, is high on the list of things I'd like to see bitcoin do. That would make it harder for a virus to steal your coins.
But even then, a smart virus could lay in wait until you typed your password to unlock your wallet and take that opportunity to either capture your password or send the coins to a bad guy. If you can't trust your computer, don't store your life savings on it (and yes, bitcoin software also should make it easy to save some of your bitcoins on USB sticks or CD-R disks so they can be stored safely in your safe deposit box at your bank).
|
|
|
|
https://github.com/bitcoin/bitcoin/pull/88This makes CTransaction::CreateTransaction use the same rules for what transactions require a fee as CBlock::CreateBlock. The mismatch was the root cause of the transaction slowness (low-priority free transactions were created but weren't being included into blocks until they 'matured' and had a higher priority).
|
|
|
|
The only things in my obj dir are cpu.o and sha.o
I did install wxwidgets and I'm running on Ubuntu 10.10
... and you get 'fatal error, can't create' when you try to compile bitcoin? Sounds like your obj/ dir is not writeable by whichever user you're using to compile. |
|
|
|
Add a mass-pay JSON-RPC method, provided that the user interface requires a TX fee parameter (NOTE: zero is a valid TX fee)
I've got a (private so far) patch that creates mass-pay transactions. API is: sendmulti <fromaccount> {address:amount,...} [minconf=1] [comment] This code in CTransaction::AcceptToMemoryPool will need to change, too: if (GetSigOpCount() > 2 || nSize < 100)
return error("AcceptToMemoryPool() : nonstandard transaction"); (a mass-pay transaction will have N+1 OP_CHECKSIGs in it, where N is the number of people being paid). Replacing in the stock client with something like: if (GetSigOpCount() > 2) minFee += GetSigOpCount()*GetArgMoney("-masspayfee", CENT/100);... seems like the right direction to go. BUT: I think a higher priority is figuring out how to deal with fees for the other two send methods. |
|
|
|
|
Show Posts
