+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).
Isn't that a brilliant idea? Like hashcash? You would be required to hash the string of the transaction, with a proof of work, that would say, take 5 seconds to calculate on a modern PC. Checking the POW just like in bitcoin would be easy and very quick for the receiving machines, but would stop a flood attack of random data without the attacker having limitless CPU power. I was actually thinking of a minute or three of proof-of-work on initial connection, not when submitting a transaction, but requiring some proof-of-work for every transaction submitted into the network IS a very interesting idea! Should be straightforward to implement, too (add a nonce and either a full or partial hash to the transaction)... Unfortunately, as simple to implement as it is, in order to be effective it would have to be a breaking change. Older clients won't send the proof of work because they don't know to. So an attacker could just claim that their client version was, say, 308 - too old for the protection. So your node would have to choose between dropping support for older clients and being secure against this sort of attack or continuing to support older clients and being insecure against this. I'm not saying we shouldn't do it, but I think we ought to get a list of important breaking changes together before we make one. Users really don't like being told that they have to upgrade every other day. Also, I don't know how the message relay protocol works. I guess each node could just relay that Tx with the same nonce and hash that the first one gave it. There's no danger of "reusing" a hash since a duplicate transaction is by nature invalid (although it could still harass the nodes). Some detection and blacklisting code would be useful too. If an IP sends you a certain number of invalid transactions within a certain time, disconnect and refuse to accept connections from them for a certain period of time. If they do it again upon reconnecting, block them for longer... etc. |
|
|
|
I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
Yeah, that would be useful behaviour. I think better key management - the ability to import, export, create, and delete addresses at will - is also in order. The current system only let you create them - you cannot delete them or export them to a file. |
|
|
|
It was able to reproduce this. The database doesn't like the relative path.
"bitcoind -datadir=./subdir getinfo" works against a running daemon, but trying to start the daemon as "bitcoind -datadir=./subdir" gets that exception.
I guess we should resolve the full path before passing it to the database.
It looks like you were the first one to ever use -datadir with a relative path.
I've tried to do it before too, but I never considered it a large enough bug to report. It would be nice to see a fix, though. |
|
|
|
News to me is that *all* your coins are at risk. I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance. Yikes.
You were right before. The reason all of his coins were lost is that he first transfered all ฿9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself ฿1, he would have only lost the smallest payment that he had previously received that was over ฿1. I think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer. |
|
|
|
|
Do you have an updated version of this patch for SVN revision 125? Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.
|
|
|
|
unsigned int is good until 2106. Surely the network will have to be totally revamped at least once by then.
There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int.
Why are we using uint64 in Version but 32-bit integers in everything else? |
|
|
|
I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
Yet another argument for cmake or similar. |
|
|
|
|
Timestamps are already stored as uint64s. At least, that's how they're transmitted on the network.
|
|
|
|
Just had a "fun" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
Nice work mate! Time to PM Satoshi. Sent you ฿5.01 for your troubles. |
|
|
|
|
I'm having a similar problem with my own compile of the SVN trunk. I just reverted to the stock builds to test and see what happens. I should try setting up my own network of two nodes with my builds.
|
|
|
|
Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.
Why isn't it practical? I agree that a good micropayment system would avoid generating thousands of transactions (e.g. one per packet), but that doesn't mean that bytemaster's change idea is wrong: Payments would generally be advanced, say 1 BTC at a time and when the connection closes any "change" would be returned. This rule makes it impossible to pay for a simple "search query" with no further transactions.
That seems like a great use case. Furthermore, as llama said, the fixed component of a transaction fee should always represent the real cost of including that transaction in a block. So, are there any more intelligent and less painful ways of implementing anti-dust spam systems? |
|
|
|
I have to agree with Satoshi, other than the extra field of "credit/debit" how is this different than getreceivedbyaddress & getreceivedbylabel? Can someone explain it to me better?
It lists transactions while the getreceivedby* functions return the sum of all transactions to that label or address. There's no reliable way to see individual transactions using the getreceivedby* functions. |
|
|
|
|
You should be using Python or Perl or something when writing a high level interface. The CLI code is really just there to let you play with the server. You should try the python-jsonrpc library.
|
|
|
|
If it sees a longer chain, but it can't process it, then it knows something is wrong. It displays "WARNING: Displayed transactions may not be correct! You may need to upgrade." and makes most RPC commands return an error.
What sort of attack is this intended to protect against? If it sees a longer chain but can't process it, it should also fail to validate any of the transactions in that block, right? |
|
|
|
On a slightly more meta note, here's the protocol for making a transaction: Transaction is built and the hash is taken. My client sends "inv" message to every other host to which it is connected. If the other client doesn't already know about the tx, it responds with a "getdata" message with the same data (and therefore checksum). My client then responds with a "tx" message. I've been decoding the tx message, but I haven't gotten it down yet. These messages are or will be decoded on the wiki here http://code.google.com/p/pybitcoin/wiki/BitcoinProtocol. |
|
|
|
|
Support is planned but not yet implemented. I don't think it would be that hard.
|
|
|
|
By the way, the "version" message does not include a version number only a string, where is the version number transferred?
It includes the version number as the first four bytes (host byte order) of the message. That number is converted to the 0.3.6 notation that you see in the client: init.cpp:191: printf("Bitcoin version %d.%d.%d%s beta\n", VERSION/10000, (VERSION/100)%100, VERSION%100, pszSubVer);Here's an (ugly) colorized version of the version packet from my machine: http://www.alloscomp.com/bitcoin/messages/version.html |
|
|
|
The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.
I hate to sound rude, but that sounds like the danger with the SCRIPT field in transactions. You're comfortable writing a whole evaluation language letting the blocks suggest operations to the client, but you're not comfortable using a library like protocol buffers? Would you consider including an option to write the wallet file out in protocol buffer format instead of the custom format? That way the default can be the custom format which you trust more, and users can export their wallet to protobuf format if they want to move to a new client.
Why not use XML for that case? The size of the wallet file on disk isn't exactly a big concern when it comes to export, and XML compresses pretty well. Plus, it's completely human readable - it would help people to understand what is actually stored. |
|
|
|
Nice work! I made some small changes. So far we have the version message pretty worked out, except the nLocalServices, nLocalHostNonce and the nBestHeight, which I can't fathom what they are used for.
nBestHeight is the number of blocks minus one, which means it's probably the index of the last block the host knows about. That's so the nodes can choose who should ask for blocks after the initial version message exchange. I don't know what the rest of those are, except that nLocalHostNonce is used (at least partially) to make sure the client isn't connecting to itself and nLocalServices appears to always be 1. [/quote] As for the other messages I have identified these so far:
Don't forget "tx", used to insert a transaction. |
|
|
|
|
Show Posts
