Bitcoin Forum
September 27, 2016, 08:39:21 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Version 0.3.11 with upgrade alerts  (Read 4068 times)
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
August 27, 2010, 09:54:12 PM
 #1

Version 0.3.11 is now available.

Changes:
- Some blk*.dat checking on load
- Built the -4way code with -march=amdfam10, which makes it a little faster
- Warning if your clock is too far off
- Warnings/errors/alerts can also be seen in the getinfo command
- Alert system

The alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update.

In response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade:
 sendtoaddress
 getbalance
 getreceivedbyaddress
 getreceivedbylabel
 listreceivedbyaddress
 listreceivedbylabel

If you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them.

This is an important safety improvement.  For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information.

Nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/
1475008761
Hero Member
*
Offline Offline

Posts: 1475008761

View Profile Personal Message (Offline)

Ignore
1475008761
Reply with quote  #2

1475008761
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1475008761
Hero Member
*
Offline Offline

Posts: 1475008761

View Profile Personal Message (Offline)

Ignore
1475008761
Reply with quote  #2

1475008761
Report to moderator
1475008761
Hero Member
*
Offline Offline

Posts: 1475008761

View Profile Personal Message (Offline)

Ignore
1475008761
Reply with quote  #2

1475008761
Report to moderator
1475008761
Hero Member
*
Offline Offline

Posts: 1475008761

View Profile Personal Message (Offline)

Ignore
1475008761
Reply with quote  #2

1475008761
Report to moderator
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
August 27, 2010, 10:12:06 PM
 #2


Good stuff.  For those who haven't been following other threads, I think it's important to note that the alerts are only accepted if signed by a specific key (held by satoshi).  Alerts cannot be generated by average nodes.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
BioMike
Legendary
*
Offline Offline

Activity: 1218


View Profile
August 27, 2010, 10:40:35 PM
 #3

- Built with -march=amdfam10, which makes -4way slightly faster

Doesn't -march break abi with older systems?
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
August 27, 2010, 11:35:26 PM
 #4

- Built with -march=amdfam10, which makes -4way slightly faster

Doesn't -march break abi with older systems?

It's quite possible.  -mtune=XXXX may be preferred, because -march=XXXX means the compiler expects the binary will only be run on amdfam10.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 28, 2010, 12:33:35 AM
 #5

... -march=XXXX means the compiler expects the binary will only be run on amdfam10.

That's exactly what we want. But I agree, it's a dirty hack to use -march=amdfam10. In this case it'll produce the most compact and efficient SSE2 code from the source. A cleaner alternative would be inline assembler.
pavelo
Newbie
*
Offline Offline

Activity: 2


View Profile
August 28, 2010, 07:36:07 AM
 #6

iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.

1NJDHzoygjdj3PehEq8ALpm7uwXHDZ9JpX
BioMike
Legendary
*
Offline Offline

Activity: 1218


View Profile
August 28, 2010, 08:24:05 AM
 #7

... -march=XXXX means the compiler expects the binary will only be run on amdfam10.

That's exactly what we want. But I agree, it's a dirty hack to use -march=amdfam10. In this case it'll produce the most compact and efficient SSE2 code from the source. A cleaner alternative would be inline assembler.

So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 28, 2010, 10:06:20 AM
 #8

iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.

We only compile one source file with the 4way code (sha256.cpp) using -march=amdfamk10, not the whole client.
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 28, 2010, 10:12:18 AM
 #9

So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?

Phenoms, i5 and i7 from what I know. Those are the only CPUs that have a 128 bit SSE2 instruction decoder and benefit at all, every older CPU will be slower. Don't think about it as "only works on AMDs K10" but rather as "tweak the compiler to produce the exact assembly code we want and still be flexible to support other vector engines in the future".
BioMike
Legendary
*
Offline Offline

Activity: 1218


View Profile
August 28, 2010, 10:48:17 AM
 #10

So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?

Phenoms, i5 and i7 from what I know. Those are the only CPUs that have a 128 bit SSE2 instruction decoder and benefit at all, every older CPU will be slower. Don't think about it as "only works on AMDs K10" but rather as "tweak the compiler to produce the exact assembly code we want and still be flexible to support other vector engines in the future".

Ah. Ok. Thank you for the info.
torservers
Jr. Member
*
Offline Offline

Activity: 52



View Profile WWW
August 28, 2010, 01:00:37 PM
 #11

The "About" dialog still shows 0.3.10.1 beta.
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
August 28, 2010, 02:54:04 PM
 #12

The "About" dialog still shows 0.3.10.1 beta.
What OS?  I ran the Windows and 64-bit Linux version and checked the about dialog.

The Mac version is still 0.3.10.1.

iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.
I updated the first post to be more specific.  Only the -4way code is compiled this way.
torservers
Jr. Member
*
Offline Offline

Activity: 52



View Profile WWW
August 29, 2010, 09:22:08 PM
 #13

The "About" dialog still shows 0.3.10.1 beta.
What OS?  I ran the Windows and 64-bit Linux version and checked the about dialog.

Nevermind. All good. Roll Eyes
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350


probiwon.com


View Profile WWW
September 02, 2010, 01:59:01 AM
 #14


Good stuff.  For those who haven't been following other threads, I think it's important to note that the alerts are only accepted if signed by a specific key (held by satoshi).  Alerts cannot be generated by average nodes.



I am concerned about the future, when will be a few bitcoin clients: messages will be sent/received in the network of various clients with various authors public keys? Or is it a temporary solution?

How this is technically implemented now?

New bitcoin lottery: probiwon.com
- Может, ты ещё и в Невидимую Руку Рынка веруешь? - Зачем же веровать в то, что можно наблюдать непосредственно?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2422


View Profile
September 02, 2010, 02:43:29 AM
 #15

Alerts are broadcast in the same way as transactions. Each node, upon accepting the alert, sends the alert to all of its peers.

Bitcoin won't relay alerts that are signed with a different key. Propagation might not be very good for any client if different alert keys start being used.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Gespenster
Newbie
*
Offline Offline

Activity: 15


View Profile
September 02, 2010, 10:32:46 AM
 #16

Alerts are broadcast in the same way as transactions. Each node, upon accepting the alert, sends the alert to all of its peers.

Bitcoin won't relay alerts that are signed with a different key. Propagation might not be very good for any client if different alert keys start being used.
That doesn't sound very scalable... Does anyone remember the gnutella bottlenecks? If not, read up on this: http://en.wikipedia.org/wiki/Gnutella#Design

Also not relaying alerts signed with a different key basically means there's only one person in the whole world that can send messages through the network. Isn't that kind of against the spirit of p2p and decentralization in general?
mizerydearia
Hero Member
*****
Offline Offline

Activity: 574



View Profile
September 02, 2010, 11:21:17 AM
 #17

Quote
Finally, when a user disconnects, the client software saves the list of nodes that it was actively connected to and those collected from pong packets for use the next time it attempts to connect so that it becomes independent from any kind of bootstrap services.

In practice, this method of searching on the gnutella network was often unreliable. Each node is a regular computer user; as such, they are constantly connecting and disconnecting, so the network is never completely stable. Also, the bandwidth cost of searching on gnutella grew exponentially to the number of connected users,[8] often saturating connections and rendering slower nodes useless.

http://gnufu.net/
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
September 02, 2010, 02:09:03 PM
 #18

Alerts are broadcast in the same way as transactions. Each node, upon accepting the alert, sends the alert to all of its peers.

Bitcoin won't relay alerts that are signed with a different key. Propagation might not be very good for any client if different alert keys start being used.
That doesn't sound very scalable... Does anyone remember the gnutella bottlenecks? If not, read up on this: http://en.wikipedia.org/wiki/Gnutella#Design

Also not relaying alerts signed with a different key basically means there's only one person in the whole world that can send messages through the network. Isn't that kind of against the spirit of p2p and decentralization in general?
The Network as it is right now appears to be a random graph with fixed node degree (8 connections each host), this indeed will never scale, and we have to find a better structure. eDonkey and others fixed it with a two-hierarchy network with supernodes and nodes, while this might solve some issues I don't think it's perfect. I'd rather go with hypercubic networks as they are truly P2P and have no single points of failures.

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!