No one here is asking for that.
Maybe not overtly or knowingly, but they are undoubtedly paving the way for it. Just as much as Satoshi paved the way for Bitcoin regulation by inventing Bitcoin. As far as I know, Satoshi was not in the habit of asking permission from "authorities" before writing software .... you, on the other hand, appear to be. |
|
|
|
So TCP/IP needed to get approval from the "regulators" before it was widely adopted?
Then the bitcoin protocol may not be all it is cracked up to be .... if Erik Vorhees is correct that bitcoin needs the crutch of state approval in order to get widely adopted, then I would say it is deficient as a technology and not fit for purpose .... bring on bitcoin2.0. (Holy Trinity should be nimble for the crypto-currency 2G will be life threatening for them.)
Oh god, please stop with this regulating Bitcoin nonsense. Yes, indeed we should just stop with this nonsense of getting the bitcoin technology regulated .... No one here is asking for that. Maybe not overtly or knowingly, but they are undoubtedly paving the way for it. |
|
|
|
So TCP/IP needed to get approval from the "regulators" before it was widely adopted?
Then the bitcoin protocol may not be all it is cracked up to be .... if Erik Vorhees is correct that bitcoin needs the crutch of state approval in order to get widely adopted, then I would say it is deficient as a technology and not fit for purpose .... bring on bitcoin2.0. (Holy Trinity should be nimble for the crypto-currency 2G will be life threatening for them.)
Oh god, please stop with this regulating Bitcoin nonsense. Yes, indeed we should just stop with this nonsense of getting the bitcoin technology regulated .... |
|
|
|
|
So TCP/IP needed to get approval from the "regulators" before it was widely adopted?
Then the bitcoin protocol may not be all it is cracked up to be .... if Erik Vorhees is correct that bitcoin needs the crutch of state approval in order to get widely adopted, then I would say it is deficient as a technology and not fit for purpose .... bring on bitcoin2.0. (Holy Trinity should be nimble for the crypto-currency 2G will be life threatening for them.)
|
|
|
|
i can confirm this happens on linux too! it happens only if the harddisk is under full load and bitcoind dosnt respond fast enough (just a guess that this is the problem). Armory thinks he lost the connection due to a short timeout setting (just guessing). is this possible?
Hmm, I've never seen it happen in linux. I guess my HDD just doesn't get overwhelmed like that. However, the disconnect-reconnect fluctuations are a symptom of the problem, not the cause. Perhaps I should add a mechanism to disable the flickering if there's too much... The real problem is why it's taking longer than 10s to do something that normally takes 0.2 ms. My guess is it isn't a "legitimate" failure (HDD taking 2500 times longer than normal), it could be an infinite loop in the readBlkFileUpdate method, or it's somehow inducing a rescan when it's only supposed to be doing a quick update. The debug output should tell me the last line that was run in readBlkFileUpdate, and also tell me the state of a bunch of different variables at that time. I had the same phenomenon on Debian, reconnecting/disconnecting every second. I got rid of it with closing Armory and "make swig". Of course the restart may have been enough too. Somewhere in the process I updated Armory, too. Sorry I don't remember it more specifically. System is running on a SSD, so I am not sure if it is a hdd issue.. Ente Can confirm I got the same behaviour on Linux Mint (debian variant) ... for me it was because I had a custom bitcoin.conf file which I removed and the error went away. Then I put the bitcoin.conf file back and I then went through commenting out individual lines to identify the culprit and discovered it did not like at least the line which when commented out stopped the repeated connect/disconnect behaviour. Hope that helps. |
|
|
|
I'm not so sure that the main defence being put up here for more regulation actually stands up that well to close scrutiny. The defence is along the lines of "the more bridges we build the faster we can flow the mainstream funds into bitcoin and out of the fiat system" Ok, so let's take a look at what happens when one person decides to change all their fiat money into bitcoin (say I'm Rick Falkvinge  ) ... before the transaction the bitcoin network had 10.5 million btc and the fiat system had XXYY fiat pesos ..... and amazingly after the transaction there are still 10.5 million btc and XXYYXX fiat pesos in the respective systems. So how is that all these "funds flowing into bitcoin" have not changed the number of units in either system? Of course the answer is that there was another willing seller of btc to exchange with Falkvinge's fiat pesos. The conceptual error here, and what undermines the "building bridges" argument, is that funds are NOT flowing from one system into the other, it is VALUE that is flowing. But what is value in this case? It is the collective illusion/delusion/belief, call it what you will, that we all choose to engage in to make this thing we call money a reality. For example, just imagine that tomorrow we all wake up and bitcoins are valued at $10,000 a piece (or equally say $0.0001), have any funds been "flowing" to and fro to achieve this? Maybe, but not necessarily so, there will still be the same number of BTC in circulation, and ~ the same number of fiat pesos but massive amounts of value can flow without any exchanges functioning whatsoever. Just something to consider, how much do you VALUE your financial privacy? |
|
|
|
But as far as I understand it, in the current implementation you need to trust the issuer. What I'm proposing would mean that not even the issuer has access to your coins. The issuer would be the only entity that can decrypt the bitcoin private key in the token. But they don't have acces to the tokens except when someone wants it redeemed.
Well, if what you are suggesting can really be done it would be a giant leap forward. Such a mechanism has been sought for some time (OT tokens provably-backed by BTC from an incorruptible automated issuer that can be traded as digital cash) ... code it up and reap the kudos  |
|
|
|
We honestly didn't think there would be this kind of massive interest from Americans and other nationalities all around the world. We honestly didn't think there would be this kind of massive interest from Americans and other nationalities all around the world. Welcome to the new age of fiscal facism ... US citizens will flock to anything that is somehow outside their fiscal prison of a banking system where you don't have to submit to the psychological equivalent of a full cavity search just to manage and transact with your own money. You come across as being a little naive to the true nature of the battle going on out there ... good luck. |
|
|
|
How do you know Gox's bank cares? Remember the bank is only seeing the withdrawals and deposits, they not seeing the bitcoins coming in and out, that are used to represent those dollars.
They're not just seeing withdrawals and deposits, they are seeing $20,000,000 a month worth of withdrawals and deposits. With that amount of money they know they are likely under the scrutiny of every regulatory body out there. It's likely why MtGox has had to resort to KYC and AML regulations as well, like a real bank. And running graph theory analysis on the blockchain. Inputting the now known users-bitcoin-address pairs supplied by Gox, BitPay, Paymium (whoever) as fixed points makes such graph theory analysis much more successful .... just saying, the more data points that go in the better the analysis (i.e. the weaker the privacy of ALL bitcoin transactions become). This would be why some exchanges correctly implementing Bitcoin do not use individual BTC addresses for users. For a cookie, name the one from that "some." Indeed, a subtle yet crucial point. So davout does Bitcoin-Central require linking users ID to bitcoin addresses? a) do you (or your regulators) intend to keep records of which users used which bitcoin addresses? b) since the regulators are only concerned with the 'fiat' side of your business it seems they would not need to know what happens on the bitcoin side of the transaction graph, right? |
|
|
|
|
NB : I just built/ran Amory on linux mint 13, it needed also the package pyqt4-dev-tools in addition to those listed in the Install instructions of the readme ... otherwise seems to build and run with only a few warnings.
|
|
|
|
So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others. I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it. Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following... Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction Runs this script against the unsigned file If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form) Shutdown the Pi I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts? Of course, I can't endorse it as a general solution, but it seems like an okay compromise for users that are knowledgeable and crave convenience. It sounds like the risks are: (1) Remembering to disconnect the cable when you're done (2) Making sure that your offline system username & password is not the same as online computer or any of the saved logins in your browser. (3) Keyloggers Keyloggers should be bolded there, because that seems like a big risk. Once a keylogger gets your username and password, it would only take a couple seconds to login and fetch the wallet file. I guess, if you kept the wallet file in some non-standard location, such automated attacks wouldn't be so clean. Although, if your wallet encryption password is further different than online, offline, and all your browser-saved passwords, then this is considerably safer than an encrypted online wallet. If the encryption password is unique, then the encryption would really shine, as there's no real way to get that password from the host system (I assume you still have to explicitly type your password on the offline computer, not through the terminal... and assuming they didn't get a keylogger onto the offline machine, synchronized with the data transfer). But depending on how much BTC you hold and/or how paranoid you are, this could be a reasonable solution. I suppose you could set up ssh keys on the rasbpi and access it like that ... no user/password typing for keylogger (once intialisation is complete). Seem to remember some tricky stuff you can do to wrap the screen tty session inside (around?) a ssh shell . http://serverfault.com/questions/21806/how-can-i-launch-a-screen-session-with-a-command-over-ssh-on-a-remote-server-fro |
|
|
|
Congratulations to etotheipi for reaching beta stage on this fantastic Bitcoin client. What follows are build instructions for OpenSUSE 12.2 (64-bit). I did a clean install of SUSE with default packages to find out which were needed for a plain-vanilla install. If you've been using your system for development, chances are you won't need all of the packages. 1. Install the following packages using your preferred package manager (zypper, YaST, rpm, etc.): git-core
swig
make
gcc-c++
python-devel
python-twisted 2. Open a terminal window and get the source: git clone git://github.com/etotheipi/BitcoinArmory.git 3. Edit BitcoinArmory/cppForSwig/Makefile and change: STATICPYTHON += "$(DEPSDIR)/lib/libpython$(PYVER).a" to: STATICPYTHON += "$(DEPSDIR)/lib64/libpython$(PYVER).so.1.0" 4. Build and run as described in the Ubuntu instructions, viz: cd BitcoinArmory/cppForSwig
make swig
cd ..
python ArmoryQt.py Fantastic! Now I have SuSE, Gentoo, Ubuntu, Fedora (somewhere). Maybe I'll start a list of such instructions on the website. Two things: (1) I don't think you need ".so.1.0", I think ".so" is sufficient (since it's just a symlink to .so.1.0, probably). (2) Everyone can avoid the Makefile modifications if I could just figure out how to autodetect the .a file, and switch the .so file if the .a does not exist. Unfortunately, my bash scripting is garbage (my failed attempt is commented out in the Makefile). Perhaps someone with more bash experience could just fix it for me and then I'll update the repo with it. This is the biggest "hurdle" for people compiling on non-Ubuntu systems, and I could make it go away if I just got the bash commands figured out. Then your compile instructions would pretty much be the same as I already have on the webpage. Anyone want to help with that? I can take a look ... |
|
|
|
So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others. I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it. Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following... Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction Runs this script against the unsigned file If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form) Shutdown the Pi I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts? Interesting approach. Seems pretty tight ... safer to use $cat rather than $less to display your signed file in case of line wrapping or extra whitespaces that might get copy/pasted and could cause errors. Any time you have a data cable between machines your "air-gap" security guarantee is obviously void  ... but how paranoid do you want to get? (risk versus reward rules as always) ... and a rooted USB stick is as much a concern anyway maybe. |
|
|
|
How do you know Gox's bank cares? Remember the bank is only seeing the withdrawals and deposits, they not seeing the bitcoins coming in and out, that are used to represent those dollars.
They're not just seeing withdrawals and deposits, they are seeing $20,000,000 a month worth of withdrawals and deposits. With that amount of money they know they are likely under the scrutiny of every regulatory body out there. It's likely why MtGox has had to resort to KYC and AML regulations as well, like a real bank. And running graph theory analysis on the blockchain. Inputting the now known users-bitcoin-address pairs supplied by Gox, BitPay, Paymium (whoever) as fixed points makes such graph theory analysis much more successful .... just saying, the more data points that go in the better the analysis (i.e. the weaker the privacy of ALL bitcoin transactions become). |
|
|
|
Wow, probably a record for bullshit density! The density is so high!
Don't know what article you read but I thought the level of information contained was pretty good, detailed. Not sure about his philosophy about state-issued currencies versus gold, silver, private-currencies and etc but he didn't seem to have any particular axe to grind there ... mostly just about physical forms of money versus digital, which is a worthy and enlightening topic to understand how people perceive "money" and wealth. Interesting to see that physical cash is still going great guns and in fact increasing in many countries at 10% compound growth rates and still represents 8 out of 10 transactions ... the digital overlords wouldn't have you believe anything like that. Edit: I should have made clear the proviso that the bitcoin info in the article was mediocre ... but I don't expect anything else after reading so much of it over the last 2 years ... so not even worth the comment. |
|
|
|
So the other side of the (bit)coin is that the banksters and the eurocrats will know how many bitcoins you have in there, how do you trade them (capital gains? repent!) and above all they will be enabled to lock your bitcoin-backed credit card if you end in some black list of them.
Thanks, but no thanks.
After all these efforts and complications to get out from the banksters' matrix, it is ironic to get back at square 1.
Beat them at their own game, that's the way I roll. Also if they want to lock your Bitcoins they have to define them legally first : no matter the way you look at it Bitcoin wins. Davout, I hear what you are saying and appreciate your enthusiasm. You are one of the guys who I've respected as having the right attitude from the first time I arrived at this forum ... so go for it I say. Fortune favours the brave. That said, I wonder how much the ECB (who released their little report into bitcoin) are trying to take you (and bitcoin) "under their wing", so to speak, so that at a later stage it will be that much easier for them to regulate bitcoin into oblivion. At this point in time they have no moral (or even legal perhaps) standing to regulate bitcoin, in as much as they have no standing to regulate exotic rock mining in Angolia. Be careful, as the old saying goes, "lie down with dogs .... ". |
|
|
|
Am now on my 3rd day of downloading the block chain. To say this is ridiculous would be generous. Come on core devs!
BTW, how did this happen? Did no one anticipate how unwieldy the block chain would become?
Yes and no ... it was always coming but not as soon as this. Satoshi dice kind of took a dump in the feedbowl. |
|
|
|
Given Stallman's political views he's one of the last people I'd expect to be interested in the monetary freedom Bitcoin represents.
Monetary freedom is an apolitical issue. It is like a basic human right, to be able to conduct your financial interactions as you choose, as much as freedom of movement, to seek happiness, etc. It should have been enshrined in founding laws as such, so that the bastards in the banks and political power structures would have been criminally liable when they took it away while noone was watching. |
|
|
|
|
Show Posts
