Kicking the Hornet's Nest - part 18
Kicking the Hornet’s Nest - third edition - part 18
All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi
Edited by @crrdlx, npub:
npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j
Kicking the Hornet’s Nest pages 400 - 425
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-15 22:58:08 UTC - -
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.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o
The 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.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
Steps:
- Shut down.
- 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.torrent - Upgrade to 0.3.10.
- 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:
- Shut down.
- Delete (or move) blk*.dat
- Upgrade to 0.3.10.
- It redownloads all blocks, probably take about an hour.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-15 23:17:24 UTC - -
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.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-15 23:36:10 UTC - -
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.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-15 23:37:07 UTC - -
Quote from: Joozero on August 15, 2010, 11:32:43 PM
I 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
BitcoinTalk
Version 0.3.10 - block 74638 overflow PATCH!
2010-08-15 23:48:22 UTC - -
Version 0.3.10 patches the block 74638 overflow bug. http://BitcoinTalk.org/index.php?topic=823
The 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.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip
It 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.
BitcoinTalk
Re: 0.3.10.1 Question on where block should be
2010-08-16 00:28:28 UTC - -
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.
BitcoinTalk
Re: 0.3.10.1 Question on where block should be
2010-08-16 00:37:20 UTC - -
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.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-16 01:00:45 UTC - -
Quote from: Ground Loop on August 16, 2010, 12:29:55 AM
Question 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.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-16 01:02:24 UTC - -
Quote from: kosovito on August 16, 2010, 12:39:17 AM
I 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.14
See
http://BitcoinTalk.org/index.php?topic=828
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-16 01:12:05 UTC - -
Quote from: trebronics on August 16, 2010, 01:02:35 AM
_Most people running clients are not reading this message thread. So… Silly questions:
-
How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?
-
How will this affect clients that upgrade to 3.8.10 but don’t remove their block chain files?_
-
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.
-
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.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-16 02:16:10 UTC - -
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.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-16 02:38:21 UTC - -
On Windows, findstr /c:“version message” debug.log
It 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.
Re: tcatm’s 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
2010-08-16 02:57:57 UTC - -
Quote from: tcatm on August 16, 2010, 12:43:39 AM
I 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= switch
Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM
With 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?
BitcoinTalk
Re: tcatm’s 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
2010-08-16 03:23:04 UTC - -
Quote from: Vasiliev on August 16, 2010, 03:17:07 AM
try -march=amdfam10
That works.
That’s strange… are we sure that’s the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement.
BitcoinTalk
Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10
2010-08-16 04:36:59 UTC - -
Quote from: jgarzik on August 16, 2010, 03:35:28 AM
Code:
cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4
cpu 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.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-16 12:59:38 UTC - -
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!
BitcoinTalk
Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10
2010-08-16 13:38:01 UTC - -
I wrapped sha256.cpp in
#ifdef FOURWAYSSE2
#endif // FOURWAYSSE2
try it now.
BitcoinTalk
Re: [PATCH] Automatic block validation
2010-08-16 15:25:54 UTC - -
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;
}
BitcoinTalk
blocks minus 1
2010-08-16 15:59:25 UTC - -
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 PM
Quote 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._
BitcoinTalk
Re: blocks minus 1
2010-08-16 17:06:27 UTC - -
Done in SVN rev 137
BitcoinTalk
Re: [PATCH] Automatic block validation
2010-08-16 17:08:02 UTC - -
Quote from: satoshi on August 16, 2010, 03:25:54 PM
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.
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.
BitcoinTalk
Checking the block chain on load
2010-08-16 20:07:46 UTC - -
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.
BitcoinTalk
Re: checkpointing the block chain
2010-08-16 20:20:53 UTC - -
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.
BitcoinTalk
Re: overflow bug SERIOUS
2010-08-16 22:54:55 UTC - -
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.
BitcoinTalk
Re: checkpointing the block chain
2010-08-16 23:01:48 UTC - -
Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PM
How is the strength of the chain calculated?
Total proof-of-work.
BitcoinTalk
Re: New screenshots to the front page?
2010-08-18 16:58:44 UTC - -
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.
BitcoinTalk
Re: Difficulty: More nodes active, or faster nodes?
2010-08-18 18:01:40 UTC - -
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.
BitcoinTalk
Re: Checking the block chain on load
2010-08-18 18:28:28 UTC - -
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.
BitcoinTalk
Re: Convert Bitcoin to GTK: Yes? No? wx is better?
2010-08-19 18:44:36 UTC - -
Quote from: BioMike on August 19, 2010, 08:05:18 AM
WxWidgets 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.
BitcoinTalk
Re: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)
2010-08-19 18:55:48 UTC - -
That’s a really well written walkthough. Someone should confirm if they followed it and didn’t run into any snags.
BitcoinTalk
Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10
2010-08-19 19:07:43 UTC - -
Quote from: Ground Loop on August 18, 2010, 11:14:26 PM
Any 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 PM
And i5, at least on my macbookpro
Good, 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.
BitcoinTalk
Re: 28 days without generation, i have 4200khash/s
2010-08-19 19:40:30 UTC - -
Make sure your computer’s date and time are correct.
BitcoinTalk
Need a post writing up some things users should know
2010-08-19 20:14:01 UTC - -
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.
BitcoinTalk
Re: Hypothetical question on lost coins / transfers
2010-08-19 20:28:50 UTC - -
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.
BitcoinTalk
Re: Need a post writing up some things users should know
2010-08-22 22:51:00 UTC - -
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.
BitcoinTalk
Re: 28 days without generation, i have 4200khash/s
2010-08-22 23:01:02 UTC - -
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 PM
How 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.
BitcoinTalk
Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10
2010-08-22 23:21:50 UTC - -
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.
BitcoinTalk
Development of alert system
2010-08-22 23:55:06 UTC - -
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:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
BitcoinTalk
Re: integrating digital payments into p2p protocols
2010-08-22 23:57:32 UTC - -
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.
BitcoinTalk
Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10
2010-08-24 22:43:56 UTC - -
Quote from: ArtForz on August 21, 2010, 04:56:31 PM
-
AMD K10: 2 128bit units
-
intel nehalem: 3 128bit units
This probably explains why hyperthreading increases performance with -4way. If three SSE2 units is excessive, then hyperthreading would help keep them all busy.
BitcoinTalk
Re: Development of alert system
2010-08-24 23:51:12 UTC - -
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.
BitcoinTalk
Re: Development of alert system
2010-08-25 00:06:36 UTC - -
This is in SVN rev 142 as version 0.3.11.
BitcoinTalk
Re: Development of alert system
2010-08-25 15:17:37 UTC - -
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:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
The 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.
BitcoinTalk
Re: Development of alert system
2010-08-25 16:40:20 UTC - -
I changed the switch name to -disablesafemode.
BitcoinTalk
Re: Development of alert system
2010-08-25 16:56:15 UTC - -
Quote from: jimbobway on August 25, 2010, 04:45:22 PM
Quote 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
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
_
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 AM
So, theoretical this is a first control system where
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”.
BitcoinTalk
Re: Development of alert system
2010-08-25 17:59:30 UTC - -
Quote from: nelisky on August 25, 2010, 01:28:32 AM
So 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 AM
I just discovered http://www.bitcoin.org/wiki/doku.php?id=man_pageand 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.
BitcoinTalk
Re: Development of alert system
2010-08-26 00:08:12 UTC - -
Quote from: BioMike on August 25, 2010, 06:23:45 PM
Quote from: satoshi on August 25, 2010, 04:56:15 PM
Quote from: BioMike on August 23, 2010, 05:15:43 AM
_So, theoretical this is a first control system where
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
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.
BitcoinTalk
Re: RFC: remove DB_PRIVATE flag
2010-08-26 00:33:28 UTC - -
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.
BitcoinTalk
Re: Need a post writing up some things users should know
2010-08-26 00:44:05 UTC - -
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.
BitcoinTalk
Re: auto backing up of wallet.dat
2010-08-26 00:57:40 UTC - -
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
BitcoinTalk
Re: Gentoo Linux Ebuild
2010-08-27 00:49:43 UTC - -
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.
Quote
Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.
Did they say why they were baffled?
Quote
This is because on my system the path is /usr/include/wx-2.9/wx/wx.h
Why 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.
BitcoinTalk
Re: auto backing up of wallet.dat
2010-08-27 01:13:42 UTC - -
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 AM
As 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.
BitcoinTalk
Re: auto backing up of wallet.dat
2010-08-27 02:54:07 UTC - -
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 AM
But 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.
Martii Malmi (AKA Sirius) “COPA trial” email #232
Date: Fri, 27 Aug 2010 03:36:43 +0100
From: Satoshi Nakamoto satoshin@gmx.com
Subject: [Fwd: SweepMines now accept bitcoins]
To: Martti Malmi mmalmi@cc.hut.fi
–––– Original Message ––––
Subject: SweepMines now accept bitcoins
Date: Tue, 24 Aug 2010 19:50:47 +0600
From: Kirill Kisel kisel2626@gmail.com
To: satoshin@gmx.com
Dear BitCoin.
http://apps.facebook.com/sweepmines/ now accepts BitCoins.
This is single-player computer game based on Windows Minesweeper version.
Would you be so kind to add us to the http://www.bitcoin.org/trade page?
Thank you.
BitcoinTalk
Re: auto backing up of wallet.dat
2010-08-27 15:47:57 UTC - -
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.