So does that mean that I need to check for leading zero bytes and remove them, in the case that the R or S values happen to be that small by chance?
Exactly. So R and S are not always supposed to be 32 or 33 bytes?
Certainly not, but fewer bytes becomes exponentially less probable. |
|
|
|
|
It's certainly incorrectly padded (according to DER).
Neither R and S can start with a zero byte, unless the value would otherwise represent a negative value, in which case exactly one zero byte is required.
So if R would be the (improbably low) number 10000000 (decimal), it'd be encoded as 0x00989680.
|
|
|
|
|
gmaxwell has since found out that at least some of the non-DER signatures are created by Armory, and etotheipi has already told me he'll change it for the next release.
|
|
|
|
Hello everyone, as some of you may know, Bitcoin uses DER-encoded signatures. However, at least the reference client supports any signature encoded in the less strictly defined BER encoding (and even allows some deviations from that). There are several inconveniences associated with allowing multiple encodings, and even some very weak attacks (there's no risk of losing money, in any case). To prevent this, we'd like to at first make non-canonical signatures non-standard, and maybe at a (much) later time, propose a BIP to make them invalid entirely. There are still some sites/software which produces non-canonical signatures, so we can't make them non-standard yet. My question for you is finding who creates them. Here is a list of transaction id's my node saw recently, which use a particular type of DER violation (excessive padding):
2229be0a6b3342d5dc3443be9b8b5306e6531f177434b5111247c0155995ba58
284c7971387d1a049aee8bd693fe2dfbad69521c0e43224bd5263529f0002744
35c0819290fd7bdfd48e7a20ea8260a0805993d714a7d7e21892d93e6e7c2f7b
5b74b9b294769be261a9caa1310bb648dd6dd530ac75cee9b7c6bfb6d160d07d
6009f0ef333e81c15a3818fc18b728e7b37881e665ae2b2e6d71b2337219f3da
63c310454e0a23d2543548a4cf7500557a2c632a84fbeb20bee47a3b16bd37b9
72dd12b8451298f316a8b687766e399f397e81e4c1c318f87548725bc95aadf5
82f37114f752865b1520eae888913b02f68aea740d830d1afe9487efd6bfa6d0
83abc9588b7a5c6084398f92c88c485e025773c567745b125c977aa1a502bc88
8a1fae8c8dbb96d1f6b879830f4df948b11ea10806564a60e0197c28f7718d52
95b5b109b744c04369e4d122bb86f3cce951088ab641fe7c6dc35c91a66ffc5b
ae216d17d68fef69b53fbc283f60efd342509f36b51c8740bdf149c319a516b1
c0f852f402f1a9989cc4c8b4921461ec850d8c4b8a9c5733a6273429523f066a
cfd4fce2d88967fdbe089b455169b683503576f69faaa1e9da636ccd62196b05
Anyone knows who/what created these? |
|
|
|
|
Just don't send coins back to a sender address; if you need to do a refund, ask the customer for a refund address.
Bitcoin transactions do not have a well-defined "from" address anyway; they potentially have inputs for which a previously-sent-to address can be determined. There is no reason to know, or to assume, that the sender wants to receive payments there. Furthermore, doing that implies address reuse, which is bad for privacy in the Bitcoin network (for everyone, by increasing the trackability of coins).
|
|
|
|
Is there a guide for this?
doc/Tor.txt in the source tree |
|
|
|
|
-rescan is not needed in this case (and hasn't been since 0.3.21).
|
|
|
|
would love to test but it gives a version error with p2pool  require 0.5 or higher I believe you need the git version of p2pool. |
|
|
|
The only option is to work around it by creating a whole second BDB instance, doubling the overhead, doubling the development effort needed, and bloating the code. Oh, and then the client would have to rescan after even trivial "clean" crashes (maybe even on normal starts too, now that I think about it), because there would be no way to do transactions across both instances and so the code could never be sure that both databases were synchronized, even if both were marked clean.
This is not entirely true, to be honest. Splitting the environment would mean some extra code, but after recent cleanups, it would certainly not be too hard anymore. Wallets store information about which blockchain they last saw (since 0.3.21 iirc), and are effectively rescanned at startup when there is a mismatch already, and we don't really do transactions across database files. The only reason that hasn't been done, is because it is not the final solution. We've had so much troubles with BDB, because we don't use it in a way it was intended for (big servers with power generators, managing large database files simultaneously being accessed by many processes, with all log files backed up regularly to tapes, and software upgrades being performed manually by a database administrator; in this setting, it is rock solid). As I said, the only real solution - in my opinion - is moving away from BDB and use a key-value store format that guarantees consistency in a single file. As the wallet is loaded entirely in memory anyway, that shouldn't be hard at all. I've already worked on this for a while, but right now, there are more urgent problems, and we're all volunteers that need to choose what to spend time on. |
|
|
|
So are you saying wallet.dat effectively comprises a table in the BDBE - does BDB not support linked tables?
If wallet.dat is linked in with these other database files, how come it can be renamed and replaced with a new wallet.dat without any discernible difference apart from I can now send BTC from my new wallet -what difference does the BDB see if this file is outside the data folder? If Access can manage linked tables... - I know, bad example ;-)
BDB is not like SQL databases. A BDB environment consists of database files and log files, each database file consisting of one or more tables, and each table consisting basically just of key-value pairs. The environment is used to allow atomic transactions that span multiple files, and manage access from multiple processes to the tables without conflicts - all features we don't use. I'm not sure what you mean by linked tables - I'm not talking about the tables/values represented by the database files, but rather their actual implementation. The log files are necessary to recover from crashes (or at least intended for that), to be able to redo or undo partially completed transactions. Also, for the wallet, we ask BDB to detach the database file from the environment at shutdown, to be sure it can be backed up and copied around. This works, but is certainly not how BDB is intended to be used. |
|
|
|
|
Use the 'backup wallet' feature in the menu. It will allow saving a copy of wallet.dat, which you can place in the datadir on your new computer.
You can also just copy the wallet.dat file, but don't do so while the program is running, or hasn't shut down cleanly.
|
|
|
|
The BIP links directly to the code change. It's hard to be more explicit than that.
It doesn't explain the reason though. Blockheight-in-coinbase will guarantee that every transaction in the network is unique and has a unique hash, apart from hash collisions. This is a more fundamental solution than the quick fix that BIP30 provided. You may want to read for some more motivation. |
|
|
|
|
The problem is slightly more difficult than just choosing the location of the wallet file.
The problem is BDB: our wallet file is not just a standalone file, but lives in a Berkleley Database environment, which consists of several files (including log files the database files refer to). Being able to have the wallet be stored in a placed independent from the other databases requires splitting the database environment in two. There are several difficulties with doing this, and it's not a real solution.
The real solution is moving away from BDB for wallets. It was a bad design decision to use BDB for wallets, and has caused us numerous problems already. We've been working on implementing a new wallet format that doesn't depend on a database before, but there have been more urgent issues recently.
In short: yes this needed, yes it will be implemented, but no it's not that easy, and it probably won't be done very soon.
|
|
|
|
|
Enable "detach databases at shutdown" in the menu, or use the -detachdb configuration option, shutdown cleanly, and remove (or just don't copy) the database/ subdirectory between the two system.
The database environment is very system dependent, and BDB (the database engine we use) does not guarantee backward compatibility between environments. When detached from the environment, the database files themselves are backward compatible, though.
|
|
|
|
|
I'm going to start a bet that he either repays partly before juli 15, 2013, or never fully at all. Who's in?
PS: that's when his debt will be more than the amount of bitcoin in circulation.
|
|
|
|
|
blkindex.dat, addr.dat (before 0.7.0) and wallet.dat are database files. They live in a database environment, consisting of several files, including transaction logs that are necessary in order to recover from (some) crashes.
When using -detachdb (or always for wallet.dat), BDB is asked to fully synchronize all changes to disk, and remove the references from the database files to the log files in the environment.
As to what blkindex.dat contains: where every transaction and every block can be found in the blk0000*.dat files, and where each transaction output was spent.
|
|
|
|
An error occurred while setting up the RPC port 8332 for listening: Cannot assign requested address That's normal if some other instance is already running which is listening on port 8332. Testnet+mainnet maybe? Or Bitcoind and Bitcoin-Qt? Or an old and a new version? If neither of these is the case, please paste (the end of) your debug.log file somewhere. |
|
|
|
To be extra conservative the protocol requires 120 blocks before generated coins can be sent. If we have a >120 block re-org we likely have big problems. Nitpick: the protocol only requires 100 confirmations before allowing to spend a coinbase output, but the client enforces 120, to be safe in the presence of reorganisations. |
|
|
|
|
Show Posts
