look how far UP we have to go:
-pic removed-
10 - 15 bucks is a nice number.. we dont have to go as high! we are gonna get higher! up we go!
|
|
|
break above 5!
happy newyear!
|
|
|
last 2 blocks look like they were found within just a few seconds of each other... what's the chance that the 2nd of this pair is invalid and will need to be re-done?
if they are consectutive: none. if they are paralelle: 100% but blockexplore says they are consectutive. so chances are: none, will not get "re-done."
|
|
|
I think we should stop donating until we get these answers.. Is this forum really that great? Who the fuck is the we. You are a noob. You haven't donated shit. This forum is indispensable IMHO. I haven't found anything that come close for getting technical answers related to the client, protocol, mining, etc. If you think otherwise then leave or don't donate. Nobody is forcing you. Just don't include this "we should STOP donating". You have donated shit, your a noob, and have 4 posts. +1
|
|
|
See, this is whats gonna drive us down to the Satoshi level.
Um... erm... do you really believe that? yes I do!
|
|
|
there have been some posts about this before. it was something about this forum lacks features and stuff. try use the search function.
|
|
|
Yes, creating blocks still takes lots of computing power, but isolating someone from the network means it's no longer a race; if it takes a day to make six block, then after a day, the victim (which may be an automated process) will think they have six confirmations. It does still cost 50BTC of computing power per confirmation on the forked part of the chain, since those blocks won't be built on. This is a good enough deterrent in most cases, but it's not as strong a defense as requiring 51% is. Ordinarily this attack wouldn't work at all, even if you spent hashing power on it, because during that time the target would almost certainly hear about the main chain, which is longer.
Actually, there might already be some mechanisms in place to notice and warn if the observed block generation rate drops precipitously, which this attack would cause. I'm not sure about that; if there aren't, there should be.
don't you think that the user, will notice something is wrong? he got bitcoinmonitor and blockexplore. your attack will not work. yeah, like the average user will stare at blockexplorer constantly yeah, like the user is waiting ~4hour for just one confirmation.
|
|
|
Yes, creating blocks still takes lots of computing power, but isolating someone from the network means it's no longer a race; if it takes a day to make six block, then after a day, the victim (which may be an automated process) will think they have six confirmations. It does still cost 50BTC of computing power per confirmation on the forked part of the chain, since those blocks won't be built on. This is a good enough deterrent in most cases, but it's not as strong a defense as requiring 51% is. Ordinarily this attack wouldn't work at all, even if you spent hashing power on it, because during that time the target would almost certainly hear about the main chain, which is longer.
Actually, there might already be some mechanisms in place to notice and warn if the observed block generation rate drops precipitously, which this attack would cause. I'm not sure about that; if there aren't, there should be.
don't you think that the user, will notice something is wrong? he got bitcoinmonitor and blockexplore. your attack will not work.
|
|
|
Bitcoin being one of them, but also Ron Paul, Free Energy/Cold Fusion, revelations of big secrets and a fundamental change in consciousness
he is a fucking religious fanatic! please don't! Wait, what? his argument for free drugs is: "people who goes to church every sunday, will not take drugs".
|
|
|
Bitcoin being one of them, but also Ron Paul, Free Energy/Cold Fusion, revelations of big secrets and a fundamental change in consciousness
he is a fucking religious fanatic! please don't!
|
|
|
4.45 now
SELL SELL SELL
panic trading! FTW!
|
|
|
gonna be big when we break 5!
thats a huge psychological barrier. yes, but also a ask wall! know the "why did I not buy earlier"-feeling?
|
|
|
gonna be big when we break 5!
|
|
|
weekly cross over of MACD!
|
|
|
UP UP AND AWAY!
|
|
|
suggestion: fork the client, and rename wallet to keyring.
please fork the client, if you want it to change!
i will keep my "wallet.dat" client.
Maybe you'll keep your wallet.dat, but after asking for it twice, I must indulge: diff --git a/bitcoin-qt.pro b/bitcoin-qt.pro index b690fae..fb267de 100644 --- a/bitcoin-qt.pro +++ b/bitcoin-qt.pro @@ -131,3 +131,3 @@ HEADERS += src/qt/bitcoingui.h \ src/qt/bitcoinamountfield.h \ - src/wallet.h \ + src/keyring.h \ src/keystore.h \ @@ -135,3 +135,3 @@ HEADERS += src/qt/bitcoingui.h \ src/qt/transactionview.h \ - src/qt/walletmodel.h \ + src/qt/keyringmodel.h \ src/bitcoinrpc.h \ @@ -178,3 +178,3 @@ SOURCES += src/qt/bitcoin.cpp src/qt/bitcoingui.cpp \ src/qt/bitcoinamountfield.cpp \ - src/wallet.cpp \ + src/keyring.cpp \ src/keystore.cpp \ @@ -182,3 +182,3 @@ SOURCES += src/qt/bitcoin.cpp src/qt/bitcoingui.cpp \ src/qt/transactionview.cpp \ - src/qt/walletmodel.cpp \ + src/qt/keyringmodel.cpp \ src/bitcoinrpc.cpp \ diff --git a/contrib/bitrpc/bitrpc.py b/contrib/bitrpc/bitrpc.py index b02b299..ae109f3 100644 --- a/contrib/bitrpc/bitrpc.py +++ b/contrib/bitrpc/bitrpc.py @@ -17,6 +17,6 @@ cmd = sys.argv[1].lower() -if cmd == "backupwallet": +if cmd == "backupkeyring": try: path = raw_input("Enter destination path/filename: ") - print access.backupwallet(path) + print access.backupkeyring(path) except: @@ -302,6 +302,6 @@ elif cmd == "validateaddress": -elif cmd == "walletpassphrase": +elif cmd == "keyringpassphrase": try: - pwd = raw_input("Enter wallet passphrase: ") - access.walletpassphrase(pwd, 60) + pwd = raw_input("Enter keyring passphrase: ") + access.keyringpassphrase(pwd, 60) print "\n---Wallet unlocked---\n" @@ -310,7 +310,7 @@ elif cmd == "walletpassphrase": -elif cmd == "walletpassphrasechange": +elif cmd == "keyringpassphrasechange": try: - pwd = raw_input("Enter old wallet passphrase: ") - pwd2 = raw_input("Enter new wallet passphrase: ") - access.walletpassphrasechange(pwd, pwd2) + pwd = raw_input("Enter old keyring passphrase: ") + pwd2 = raw_input("Enter new keyring passphrase: ") + access.keyringpassphrasechange(pwd, pwd2) print @@ -323,2 +323,2 @@ elif cmd == "walletpassphrasechange": else: - print "Command not found or not supported" \ No newline at end of file + print "Command not found or not supported" diff --git a/contrib/debian/examples/bitcoin.conf b/contrib/debian/examples/bitcoin.conf index e56c43c..8762a05 100644 --- a/contrib/debian/examples/bitcoin.conf +++ b/contrib/debian/examples/bitcoin.conf @@ -68,3 +68,3 @@ gen=0 -# Pre-generate this many public/private key pairs, so wallet backups will be valid for +# Pre-generate this many public/private key pairs, so keyring backups will be valid for # both prior transactions and several dozen future transactions. diff --git a/contrib/debian/manpages/bitcoin.conf.5 b/contrib/debian/manpages/bitcoin.conf.5 index 1243253..5802f8b 100644 --- a/contrib/debian/manpages/bitcoin.conf.5 +++ b/contrib/debian/manpages/bitcoin.conf.5 @@ -72,3 +72,3 @@ Enable or disable use SSE instructions to try to generate bitcoins faster. \fBkeypool=\fR\fI'100'\fR -Pre-generate this many public/private key pairs, so wallet backups will be valid for both prior transactions and several dozen future transactions. +Pre-generate this many public/private key pairs, so keyring backups will be valid for both prior transactions and several dozen future transactions. .TP diff --git a/contrib/debian/manpages/bitcoind.1 b/contrib/debian/manpages/bitcoind.1 index 0179406..4f99899 100644 --- a/contrib/debian/manpages/bitcoind.1 +++ b/contrib/debian/manpages/bitcoind.1 @@ -83,4 +83,4 @@ This help message .TP -\fBbackupwallet 'destination'\fR -Safely copies *wallet.dat* to 'destination', which can be a directory or a path with filename. +\fBbackupkeyring 'destination'\fR +Safely copies *keyring.dat* to 'destination', which can be a directory or a path with filename. .TP @@ -197,3 +197,3 @@ Checks that 'bitcoinaddress' looks like a proper bitcoin address. Returns an obj "isvalid" : true or false. - "ismine" : true if the address is in the server's wallet. + "ismine" : true if the address is in the server's keyring. "address" : bitcoinaddress. diff --git a/contrib/wallettools/walletchangepass.py b/contrib/wallettools/walletchangepass.py index 30f3f5b..3f2867a 100644 --- a/contrib/wallettools/walletchangepass.py +++ b/contrib/wallettools/walletchangepass.py @@ -2,4 +2,4 @@ from jsonrpc import ServiceProxy access = ServiceProxy("http://127.0.0.1:8332") -pwd = raw_input("Enter old wallet passphrase: ") -pwd2 = raw_input("Enter new wallet passphrase: ") -access.walletpassphrasechange(pwd, pwd2) \ No newline at end of file +pwd = raw_input("Enter old keyring passphrase: ") +pwd2 = raw_input("Enter new keyring passphrase: ") +access.keyringpassphrasechange(pwd, pwd2) diff --git a/contrib/wallettools/walletunlock.py b/contrib/wallettools/walletunlock.py index f847c6f..7bcec90 100644 --- a/contrib/wallettools/walletunlock.py +++ b/contrib/wallettools/walletunlock.py @@ -2,3 +2,3 @@ from jsonrpc import ServiceProxy access = ServiceProxy("http://127.0.0.1:8332") -pwd = raw_input("Enter wallet passphrase: ") -access.walletpassphrase(pwd, 60) \ No newline at end of file +pwd = raw_input("Enter keyring passphrase: ") +access.keyringpassphrase(pwd, 60) diff --git a/doc/build-unix.txt b/doc/build-unix.txt index 5389339..47e6e45 100644 --- a/doc/build-unix.txt +++ b/doc/build-unix.txt @@ -28,3 +28,3 @@ Dependencies libssl SSL Support Secure communications - libdb4.8 Berkeley DB Blockchain & wallet storage + libdb4.8 Berkeley DB Blockchain & keyring storage libboost Boost C++ Library diff --git a/doc/coding.txt b/doc/coding.txt index b3c812a..c93479c 100644 --- a/doc/coding.txt +++ b/doc/coding.txt @@ -49,3 +49,3 @@ CRITICAL_BLOCK/TRY_CRITICAL_BLOCK macros to protect data structures. Deadlocks due to inconsistent lock ordering (thread 1 locks cs_main -and then cs_wallet, while thread 2 locks them in the opposite order: +and then cs_keyring, while thread 2 locks them in the opposite order: result, deadlock as each waits for the other to release its lock) are @@ -79,3 +79,3 @@ ThreadTopUpKeyPool : replenishes the keystore's keypool. -ThreadCleanWalletPassphrase : re-locks an encrypted wallet after user +ThreadCleanWalletPassphrase : re-locks an encrypted keyring after user has unlocked it for a period of time. @@ -86,3 +86,3 @@ ThreadDelayedRepaint : repaint the gui -ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used +ThreadFlushWalletDB : Close the keyring.dat file if it hasn't been used in 500ms. diff --git a/doc/readme-qt.rst b/doc/readme-qt.rst index 0901773..ed6d2e3 100644 --- a/doc/readme-qt.rst +++ b/doc/readme-qt.rst @@ -6,3 +6,3 @@ Features -- All functionality of the Wx GUI, including wallet encryption +- All functionality of the Wx GUI, including keyring encryption
... and a whole lot more
lulz, you did only change some of the wallet-code, and most of the documentation. the 'keyring' is still called wallet.dat. i did not say that it would be hard, it is just sed'ing through the code. and fix minor things afterwards.
|
|
|
|