b) building on an unconfirmed transaction won't make the original transaction happen any sooner. The method suggested will not work anyway, as the coins in the pending transaction can only be re-sent by the recipient, who is not the sender. A Bitcoin modified to allow its users to cancel transmitted transactions (that broke the fee rules anyway) would make a huge double-spend attack vector. What? The RECEIVER would build upon the unconfirmed transaction. i.e. you (being cheap) send me 5 BTC from Address A (owned by you) to Address B (owned by me). No fee was included so the transaction isn't being picked up by miners. I take the unconfirmed B and send it to C (another address owned by me). I include a fee of 0.10 BTC. A smart miner would see B->C wanting the fees see it is dependent on A->B and include both in the next block. A really awesome "confirmation booster". A solid +1 to Steve. A very nice way around senders paying for tx fees. The solution would be to have a special "add-more-fee" transaction you can send, that can only be added to a block that includes the original transaction. The real solution is to not send payments that clients won't relay and miners won't include.
Um that is exactly what he proposed except there is no need for a special tx. Simply a tx with a fee that uses as an input the output of an unconfirmed tx w/ no fee. I've thought this would be a good idea for a long time. The key problem is that miners don't resolve dependencies like this yet. |
|
|
|
Conditions: The only thing i care about is that it works on Linux. Not that it's secure? |
|
|
|
This fork is only a simple patch to maintain the way things previously were, before developers introduced a change that is unfair and unacceptable by my standards. I'm not aware of any version that didn't force fees... |
|
|
|
bitcoind and Bitcoin-Qt version 0.5.4 release candidate 1 is now available for download at: bitcoind version 0.4.5 release candidate 1 is now available for download at: These are bugfix-only releases, plus protocol support for BIP 16. Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. PROTOCOL UPDATES- BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
BUG FIXES- Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown. (0.5.4 only)
- Fix broken testnet mining.
- Yet another attempt at implementing "minimize to tray" that works on all operating systems. (0.5.4 only)
- Fix default filename suffixes in GNOME save dialog. (0.5.4 only)
- Make the "Send coins" tab use the configured unit type, even on the first attempt. (0.5.4 only)
- Print detailed wallet loading errors to debug.log when it is corrupt.
- Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
- Workaround for improbable memory access violation.
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Gavin Andresen Wladimir J. van der Laan Pieter Wuille Matt Corallo Joel Kaartinen |
|
|
|
Can devs upload the binaries + source to sourceforge.net?
Not worth the trouble for this release. 0.4.5 (with BIP 16 support) will hopefully be ready within the next week or two (about to upload RCs). |
|
|
|
0.4.1 running on my computer. And I did not see any security problems to it at all. The vulnerable was Qt version. The wallet encryption is a joke in all versions.
Minor security issues in 0.4.1: - Possible to crash with an incoming p2p connection
- Doesn't verify integrity of private keys
- No BIP30 or BIP16 support
- Multiple unlimited-memory-growth DDoS vulnerabilities
Semi-important bugs: - Memory leaks
- Deadlocks (client freezes)
- UPnP/router issues
- Testnet protocol incompatibilities
|
|
|
|
The only GUI version of Bitcoin I use is 0.3.15 because I usually don't need the features in the newer versions, and AFAIK none of the security problems apply to me. Maybe I'll upgrade if I ever have to download the blockchain from 0 again. 0.3.15 must have a lot of security issues by now... You shouldn't need to redownload the blockchain with any of the new versions, but even if you did, there's been fixes to drastically improve the download speed too. |
|
|
|
i use the very last one before the interface got 'upgraded'. 0.4.4/0.4.5rc include the old wxBitcoin client still, though it's not maintained. |
|
|
|
More updates (other tags, trunk) should follow soon. Be aware that if you cross-compile, 0.6rc4 will only build securely if you rebuild Qt with the gitian hacks first (or merge #946). |
|
|
|
|
Just wondering how many people are using what versions. Also, please note that I intend to drop support for (only) the 0.5.0.x branch when 0.6.0 is released, so if you're using that please upgrade to 0.5.3.1. If you're using a broken or insecure version, please comment on this thread why. I would also appreciate comments on how long you intend to use which versions. Thanks!
Edit: If you run git master, that counts as 0.6 RCs
|
|
|
|
yes, thanks for that diagram. i'll bet most of us have never seen it. I bet not, considering I literally just drew it in KolourPaint real quick :p |
|
|
|
confused. whats the diff btwn this and the recent 0.5.3.1?
 The blue branches only get fixes. The red one gets new features, changes, etc as they're developed. The green one is the critical vulnerability fix for 0.5.3.1 |
|
|
|
confused. whats the diff btwn this and the recent 0.5.3.1?
0.4 is an older bitcoind series. 0.5 has more features, but is less tested. |
|
|
|
I don't see it as gaming.
The compensation for including transactions isn't worth the cost. Period. Up till now people have "played nice" but any system will be pushed to its limits in the name of efficiency.
Its not gaming it is optimal decision making.
The problem isn't requiring a fee, it's this miner not including any transactions at all period. |
|
|
|
How dares he, the "mystery jerk miner", to mine a pseudo-anonymous currency while wishing to stay anonymous... Maybe if he wanted to be anonymous, he shouldn't have attracted negative attention by trying to harm Bitcoin. |
|
|
|
blockchain.info did before the the mystery miner changed tactic and either started relaying only to mining pools or blocked my nodes. I suspect he blocked your nodes. The IP in question does have port 8333 open. I'm guessing 88.6.208.35 or an ip in a similar subnet? Same /16 subnet. |
|
|
|
|
Since it seems people are getting the wrong impression from this pullreq...
It was proposed by a pool member who noticed the mystery jerk miner (making transactionless blocks) was relaying them through Eligius. This handy-but-simple change enabled me to get the real IP of the actual server making these blocks. The objections given herein by other developers are logical concerns, and I have no qualms with the pullreq being closed unmerged.
I'll refrain from feeding any trolls, but FWIW I do believe everything the Catholic Church teaches, including (the "weaker" form of) the divine right of kings. However, I consider this to be fairly off-topic in this forum, so don't intend to get into a discussion about it here.
P.S. The point of pull requests is for others to review them...
|
|
|
|
[This handy-but-simple change enabled me to get the real IP of the actual server making these blocks.
You dont know that. You get the IP of whomever is relaying the block. How do you know it actually made it? This particular miner is known to not be broadcasting the block normally, only to select peers. Blockchain.info blames DeepBit and Eligius for the blocks because we've been getting them first. Based on analysis of the IP in question, it doesn't seem to be any kind of specialized proxy, so it's a reasonable conclusion to think it is the block maker. Is it the spanish Telefonica one? It's a Spanish IP, but not one blockchain.info seems to know anything about. ....why Tonal?!
Isnt there something even more overfluent you might have used instead?
Tonal is the whole reason I'm involved with Bitcoin. "Overfluent" doesn't seem to be in any dictionary, so I don't know what it means. |
|
|
|
By default if you can steal the log of someone, you then can steal there wallet.dat. (that may or may-not be usefull, if the wallet is encrypted or not)
Right, the concern was that someone might attack (perhaps legally; ie, a visit from the police) for the logs themselves if they all contained this information. If someone could get logs full of IPs from lots of people, it could enable some more serious privacy invasions. |
|
|
|
Whenever a block is received, log the sender's IP and the current time
Go fuck yourself, Luke. I know you proposed this crud.
Actually, it was proposed by a pool member who noticed the mystery jerk miner was relaying his poisonous blocks through Eligius. I implemented it. This handy-but-simple change enabled me to get the real IP of the actual server making these blocks. No idea why you have a problem with logging useful information. The only objections have been on the basis of someone potentially stealing logs for the info. |
|
|
|
|
Show Posts
