Bitcoin Forum
April 26, 2024, 04:43:34 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 186 »
841  Bitcoin / Development & Technical Discussion / Re: 1 quantum computer == 1000 ASICs? on: November 08, 2013, 04:25:27 AM
From http://arxiv.org/abs/1108.2316 (Merkle Puzzles in a Quantum World):

Quote
We showed in an earlier paper that Merkle's schemes are completely insecure against a quantum adversary...

Bitcoin mining algo can be used as Merkle's Puzzle. Does it mean that a quantum computer can find a nonce much faster (sqrt[X] vs X for a classical computer)? I can't find that paper to check this by myself.

Yes, a QC can do a brute force search that normally takes O(N) in O(sqrt(N)).   But QCs are going to be a long way from exploiting that advantage until they (1) exist, and (2) are good enough to actually execute "guesses" that fast.

Consider for example that you need approximately 108 operations to brute-force guess something (in this case find a nonce that gives a particular target when hashed).  Perhaps your ASIC does 108 guesses/sec, so it takes 1 second.  It may only take 104 operations for your QC... but if it can only do 100 ops per sec, you're still far better off with your ASIC.

Of course the math and the scales are far from that simple, but you get the point -- even getting a real QC that has enough qubits and gates to do the calculation may be decades off... and it may be far longer before it can even exploit such an advantage.

(On the other hand, it has a far greater advantage than that against breaking crypto schemes, so even a minimal QC might take minutes/hours/days to break a key, but it's better than the 1032 years it would take a classical computer)

842  Bitcoin / Armory / Re: Encrypted Paper Backups on: November 08, 2013, 01:41:08 AM
It just takes two seconds to encrypt your recovery key, there's no need for this in armory.  Just do it yourself if you want that.

Agreed, this is very easy to do.

The issue is it is error prone when done manually. For every 100 times I've done the above manually there is 1 time where something went wrong. If I have a cold wallet that I come back to in 2020 and BTC is priced to the moon, I don't want that to be the time my manual encryption effort screwed up somehow.

The advantage of automation is it eliminates manual mistakes.

You're going to remember the password you chose today, 7 years from now?  Either you re-use passwords way more than you technically should, or your memory is epic.  I'd be much more concerned about the number of things that can go wrong in 7 years that make that backup useless.
843  Bitcoin / Armory / Re: Armory - Discussion Thread on: November 08, 2013, 01:25:36 AM
ok, but it is encrypted right?  as long as I never enter my password on a possibly keylogged box nobody can use it

That's like putting on your new bullet-proof vest then walking upright into an open field in a warzone.  You risk getting shot, and if you do you might survive, but if your vest (password) isn't high quality or the person happens to be using something like an anti-tank weapon (a lot of computing power to break your password), you might get screwed despite your nifty vest.  Why even risk it?
844  Bitcoin / Armory / On bitflips and Armory security on: November 07, 2013, 10:22:48 PM
I have received a lot of questions about RAM errors potentially causing users to lose coins.  gmaxwell has made some statements about this in the past, and I want to give people an opportunity to find a hole in my logic.   Admittedly, I haven't spent a ton of time thinking about this, and I'm probably overlooking something.

My Statement:

Offline transactions:  Armory offline transactions are not vulnerable to bitflips, if you verify addresses and values on both the online and offline computer.
Online transactions (hot wallets):  There is a remarkably narrow window in which a bit-flip could result in loss of coins.  This could be mitigated with a secondary verification window after signing is complete.

Neither of these conditions hold true if you are assuming the possibility of multiple, perfectly-inconvenient bitflips.  DRAM errors are so rare, that squaring that error and assuming that the two errors are perfectly correlated in the worst way possible -- is effectively impossible.

My justification:

Offline transactions:  I can't enumerate all the possible times and places a bitflip could happen.  But here's a few:

  • Online computer creating the transaction, value or address: you catch it when you check the addresses and values on the offline computer (check every character!)
  • Offline computer before signing:  you catch it when you verify the address and value on the online computer before broadcasting.  
  • Either computer, after signing:  signature breaks, tx is invalid.

Online transactions (hot wallets):  
For this situation, a bitflip after confirming the outputs as correct, but before the system actually creates the signature, is the black swan event.   But it could be caught if there was a second verification window that displayed the final, signed transaction before it actually broadcasts.  At least in Armory, it is always re-parsing the raw transactions and displaying information from that parse.  So, a check of every character of the output address both before and after signing would catch this.

The only other time I can think that this would be a real issue, is a bit flip in the address as it is sent to you by the other party.  Perhaps their system bitflips the hash160 value pulled out of the wallet, before they even give you the address.  That would be undetectible.  But if you are moving life-changing quantities, of money, I'd always recommend calling and verifying every character of the address, anyway.  That would catch bitflips after the transfer of the address (and technically the checksum should catch that, too).

Lessons learned: When executing an offline transaction, always check every character of the recipient addresses and values, both on the offline computer before signing, and on the online computer before broadcasting.

What am I missing?  

P.S. - We could also just recommend that all systems handling large BTC volumes use ECC RAM.  But I'm not convinced it's necessary for an online-offline setup if you do the appropriate checks.
845  Bitcoin / Armory / Re: Armory scanning the whole blockchain every time i start the program on: November 07, 2013, 05:09:40 PM
The next version has solved all of these problems (currently in the ramreduceleveldb and rrld_planB branches).  It's not quite ready for testing, but should be very soon.  Armory now builds the database and scans it on the first load only, saving everything between loads.  And only uses like 250 MB of RAM (which should be independent of the blockchain size).  

Obviously, this is a huge step up from where it currently is.  I just haven't had the time to overhaul the relevant code until now.

I built direct from github on Ubuntu and Armory still performs a lengthy scan each time it loads.

Despite the optimistic messages (2 minutes left ... 1 minute left ... 15 seconds ...) it generally takes about an hour.

I have also discovered that after performing a spend (offline wallet mode) armory will crash silently. I have seen this twice. I can provide logs on request, this may be due to Armory believing BitcoinQt to be out of sync, when it is not.

Despite these niggles, Armory is by far my favourite tool for keeping BTC safe Smiley

If you switch to the "testing" branch, you'll get the new version, which has it's own set of issues, but works very well if you are careful (don't interrupt the initial DB build or scan).  So far, I have experienced zero issues on both my Linux and Windows testing versions when I let it do its thing. 

The initial DB build takes 30-90 minutes, and 15-30 minutes for the subsequent scan.  After that, it's about 30 seconds to startup (plus a couple minutes if you haven't loaded it in a while and it has a lot of tx history to synchronize).
846  Bitcoin / Armory / Re: Why would the Armory client (secure) recommend using a USB drive (unsecure)? on: November 07, 2013, 05:07:31 PM
The fact is:  using an offline computer with USB keys is two orders of magnitude better than just maintaining a hot wallet.  If the alternative methods of doing an offline transaction are inconvenient and/or unreliable (such as using QR codes, because they're not big enough for all tx), then many people will simply use hot wallets because they're easier.

That doesn't mean that there shouldn't be an alternative solution available.  But it's a matter of balancing user tendencies (aversion to complexity) with the security advantage.  Everyone understands USB keys and how to move a file.  Not everyone can get their webcames working, or scanner and printers with OCR, etc.  I'd rather them use offline+USB key than give up and just use a hot wallet.

847  Bitcoin / Armory / Re: Is there any problem to change the file name? on: November 07, 2013, 05:04:10 PM
If the file stays in your Armory home dir, then it should still work.  Armory checks each file in that directory (where you found the original .wallet file) for a magic 8 bytes at the beginning.  If the file starts with those 8 bytes, it will interpret it as a wallet file.  So changing the name shouldn't affect it unless you actually change the file too.
848  Bitcoin / Armory / Re: Armory transaction can't broadcast on: November 07, 2013, 05:03:02 PM
Definitely a mempool.bin issue.  Armory attempted to broadcast it, but Bitcoin-Qt was probably disconnected from the network when it tried, and now it's stuck (for reasons that are difficult to describe).

Close Armory
Close Bitcoin-Qt
Remove ~/Library/Application Support/Armory/mempool.bin.
Restart Bitcoin-Qt
Restart Armory
Send transaction again

If this was an offline transaction, you don't even need to recreate&sign.  Just select the file in the offline-broadcast window by "Show All Files" at the bottom-right of the file-select screen.  Select the *.SENT.tx (normally you select a *.unsigned.tx or *.signed.tx). 

If you are using an older version of Armory on the offline computer, there may be other issues, but those will be resolved with the new version of Armory posted on the RAM-Reduction testing version thread.

849  Bitcoin / Armory / Re: RAM-Reduction & Backup Center Testing (version 0.89.99.8) on: November 06, 2013, 09:13:17 PM
etotheipi (or anyone else),

1. Is it possible to restore the m of n backups using version 0.88.1? As this is the version I have on my (offline) netbook and it defeats the purpose of it being offline if I have to restore to an online machine, kind of...

2. Conversely, and this is a little long winded, but would I be able to install 0.89.99.8/9 onto (an offline) Ubuntu 10.04? Would I simply have to download:
Code:
git-core build-essential pyqt4-dev-tools swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted python-psutil libcrypto++-dev
as .deb packages, transfer them accross to the netbook and install them on-by-one.

Then also copy accross the cloned Armory git, and make and run as I have been doing on Ubuntu 13.10? Or is there something about this which would not work?

Then I could create m of n wallets on my network-neutered machine, and also be able to restore to them directly from there... But I am only speculating about this with my basic understanding of it all....

If you've already installed an offline bundle on your offline machine, it already has all the dependencies needed to run the new version (though, occasionally new dependencies crop up in new versions, but I don't think that happened for this update).  Given that, you should be able to checkout the repo and build it on an online computer, then take the built directory to the offline computer and run it there.  As long as it has been built already,  and dependencies installed, you're good. 

The offline bundle has all the dependencies needed for 10.04.  However, it doesn't have the dependencies for building the package, which is a bit more work.  Technically, you can use synaptic on the offline machine to generate and offline download script, but that's a bit of work.  I don't recommend it unless you're patient.

No, you can't recover the fragmented backups in 0.88.1.  Ultimately, you'll have to switch to the new version for the offline computer.  However, I added a backup-testing window, which should help calm any nerves about trusting new technology Smiley
850  Bitcoin / Armory / Re: Armory - Discussion Thread on: November 06, 2013, 07:25:04 PM
No matter how you look at it, Armory (and the decentralized Bitcoin concept) is that your computer holds the private keys.  No matter what kind of toppings you put on it, at some point your system decrypts the private key and uses it to sign a transaction.  Therefore, you can require as many devices as you want, in any complicated scheme you want, but unless there's a server somewhere holding they key, etc, it's not going to help.  Your computer still holds all the data needed to decrypt the single key needed to move the funds. (this is also why removable-media DRM keeps failing -- at some point, your computer or DVD drive has to decrypt the data and send the unencrypted results to the TV/monitor -- that process cannot only be intercepted, but also run in a VM and analyzed to excrutiating detail to reverse engineer the algorithms)

However, when I finally implement multi-sig, you will have actual 2FA -- the network acts as the "server" which requires two signatures from two different keys to move the coins.  And those keys can be be created completely separately, no located on the same device, thus requiring multiple devices to be compromised to get the signatures needed.

Until then, there really are no multi-factor solutions for a decentralized, run-locally app like Armory.
851  Bitcoin / Armory / Re: Armory - Discussion Thread on: November 05, 2013, 06:28:17 PM
Completely random side-note: I think this is one of my new favorite python patterns (I just learned about decorators recently).  There's a few places to use it in Armory, but mostly excited about for other applications.


Code:
class PyBackgroundThread(threading.Thread):
   """
   Wraps a function in a threading.Thread object which will run
   that function in a separate thread.  Calling self.start() will
   return immediately, but will start running that function in
   separate thread.  You can check its progress later by using
   self.isRunning() or self.isFinished().  If the function returns
   a value, use self.getOutput().  Use self.getElapsedSeconds()
   to find out how long it took.
   """
  
   def __init__(self, *args, **kwargs):
      threading.Thread.__init__(self)

      self.output     = None
      self.startedAt  = UNINITIALIZED
      self.finishedAt = UNINITIALIZED

      if len(args)==0:
         self.func  = lambda: ()
      else:
         if not hasattr(args[0], '__call__'):
            raise TypeError, ('PyBkgdThread constructor first arg '
                              '(if any) must be a function')
         else:
            self.setThreadFunction(args[0], *args[1:], **kwargs)

   def setThreadFunction(self, thefunc, *args, **kwargs):
      def funcPartial():
         return thefunc(*args, **kwargs)
      self.func = funcPartial

   def isFinished(self):
      return not (self.finishedAt==UNINITIALIZED)

   def isStarted(self):
      return not (self.startedAt==UNINITIALIZED)

   def isRunning(self):
      return (self.isStarted() and not self.isFinished())

   def getElapsedSeconds(self):
      if not self.isFinished():
         LOGERROR('Thread is not finished yet!')
         return None
      else:
         return self.finishedAt - self.startedAt

   def getOutput(self):
      if not self.isFinished():
         if self.isRunning():
            LOGERROR('Cannot get output while thread is running')
         else:
            LOGERROR('Thread was never .start()ed')
         return None

      return self.output


   def start(self):
      # The prefunc is blocking.  Probably preparing something
      # that needs to be in place before we start the thread
      self.startedAt = RightNow()
      super(PyBackgroundThread, self).start()

   def run(self):
      # This should not be called manually.  Only call start()
      self.output     = self.func()
      self.finishedAt = RightNow()


# Define a decorator that allows the function to be called asynchronously
def AllowAsync(func):
   def wrappedFunc(*args, **kwargs):

      if not 'async' in kwargs or not kwargs['async']==True:
         # Run the function normally
         if 'async' in kwargs:
            del kwargs['async']
         return func(*args, **kwargs)
      else:
         # Run the function as a background thread
         del kwargs['async']
         thr = PyBackgroundThread(func, *args, **kwargs)
         thr.start()
         return thr

   return wrappedFunc

Simply take any function that you would normally define,

Code:
def myFunc(...):
   doSomething()

And add:

Code:
@AllowAsync
def myFunc(...):
   doSomething()

You can now call myFunc(..., async=True) to have it run in the background instead of in the main thread (control will go to the next line of code immediately without wainting for myFunc to finish).  If you want to keep track of it, you can instead do:

Code:
thr = myFunc(..., async=True)

while not thr.isFinished():
   doOtherStuff()

# It must be finished to have gotten here
data = thr.getOutput()
print "myFunc took %f seconds" % thr.getElapsedSeconds()

If you have functions that do a lot of I/O, but aren't needed for the subsequent operations, you can simply do the following to parallelize:

Code:
thr = myFunc(..., async=True)

doOtherStuffInParallel()

thr.join()  # will wait for it to finish

Very cool!   Just keep in mind that you don't get a computational advantage using python threads, but if you are doing things that are I/O limited, networking, UI-related, etc... it works wonderfully.

Okay, now back to this orphan chain bug...
852  Bitcoin / Armory / Re: Armory - Discussion Thread on: November 05, 2013, 05:36:42 PM
What if I change my encryption password on my armory wallet file.  If there is an old wallet file on a usb key somewhere I assume that version of the wallet file would unlock with the older encryption password and not the new one?

Paper backups don't have this problem.  You make a backup once, and it doesn't depend at all on your password (which is part of the point of them... to help people recover their wallet when they forget the password).

Digital backups (in 0.88.1 and earlier) will be encrypted with the same passphrase that is used at the time the backup was made.  In order to use that digital backup, you'll have to know that earlier password, regardless of what you do with the active wallet you use.

The next version has a "make unencrypted digital backup" button which is intended for USB keys, etc.  This will make a digital backup with the same properties as the paper backup, besides the risk of device failure.  Until then... use paper!

853  Bitcoin / Armory / Re: Armory - Discussion Thread on: November 05, 2013, 04:06:07 AM
For offline transactions, is there any problem with creating and signing a transaction but delaying the broadcast for a while (e.g. months)?

How about creating but not signing?

There's no problem as long as you don't execute any more transactions between the time that the transaction was created and when it is broadcast.  Technically, it might work, but I wouldn't count on it.  For simplicity reasons, Armory doesn't "lock" any of your inputs to prevent them from being spent in further transactions, unless a signed transaction spending those inputs hits the network.  Therefore, if you create, sign and broadcast another transaction before broadcasting the first one, you are likely to spend some of its outputs which will make the first tx invalid.
854  Bitcoin / Armory / Re: RAM-Reduction & Backup Center Testing (version 0.89.99.8) on: November 05, 2013, 04:03:24 AM
trying out the ArmorySetup-0.89.99.8-beta_win32 install on a virgin install of Win 7 Home Premium 64-bit (SP1 + all updates).

it installs fine, but when run it fails with logfile errors.   anybody know if the _win32 means it won't work with 64-bit, or perhaps if i am missing some prerequisite installs?  (i had an earlier testing version working on another instance of win7, where i get the same errors with this version).


The win32 means that it is built as a 32-bit application, but 64-bit windows can still run 32-bit applications.  So far, I think most people have been testing the 32-bit app on 64-bit (and I've been using it on my 64-bit Win7 VM).  If there's a problem, perhaps it has to do with installing different versions and jumping around.  I would recommend removing it via control panel, and then remove all C:\Program Files\Armory and C:\Program Files (x86)\Armory.  Then reinstall.  There may still be a problem with the installer not deleting/overwriting everything.

P.S. - Your wallets are not in those directories, so there's no risk of losing your wallets or settings when uninstalling or reinstalling Armory.  For reference, the wallets are in C:\Users\<username>\AppData\Roaming\Armory (do not delete that directory!).
855  Bitcoin / Armory / Re: RAM-Reduction & Backup Center Testing (version 0.89.99.8) on: November 04, 2013, 07:20:38 PM
I dowloaded the Linux client and the version states 0.88.1-beta.  Is that right?

That's the current stable version. If you want to use the test version, check the first post in this thread for instructions.
Huh, I followed the instructions with "checkout testing" etc...  If I do "git checkout testing" I get the response "you are already using testing". 

I'll uninstall and try it again.

Then you're fine.  It's just to make sure you're on the branch with the latest testing code.  Once you're there, you can follow the rest of the instructions no problem. 

The only thing is that if you don't see "Version 0.89.99.9", you may not be up to date.  You can type "git pull origin testing", and then type "make" again and "python ArmoryQt.py".
856  Bitcoin / Armory / Re: Armory - Discussion Thread on: November 04, 2013, 06:58:38 PM
Is there an interface in Armory that I can enter the hash256() result into (or the result of the dice throws), so I can generate a deterministic Armory wallet from a series of dice throws? Or is there some hackish way of doing it (I'm fine without a GUI).

If you have all the dependencies installed and can "from armoryengine import *" in a python shell without errors, then yes.  You can take your entropy source, run it through the hash256() function, and then run the result through the "makeSixteenBytesEasy()" method, which will add a checksum and convert it to "easyType16" format for a paper backup. (do 16 bytes at a time).

And if there isn't an interface in Armory, would you accept patches that implements one?

Kind of... it's a long story.  But those motivated enough will be able to figure it out from the instructions above...
857  Bitcoin / Armory / Re: RAM-Reduction & Backup Center Testing (version 0.89.99.8) on: November 04, 2013, 03:33:23 PM
Yes, it took many hours for me too (three or four year old MacBook, OS X 10.Cool.

But then restarting is much faster than it used to be - except that today it looks like it decided to rescan all the transactions (estimated: 30 min).

Edit:  That smiley was supposed to be version 10.8 

I've designed it so that it only saves the wallet history on clean shutdowns while synchronized.  Otherwise it will have to rescan.  It is probably too aggressive in requiring rescanning when probably not necessary... but it's one of those things that can be really messy if it's doesn't work right... frustration is guaranteed, and someone could also lose coins (i.e. because Armory tells them they have X coins, when they actually have X+Y coins and they do something like delete the wallet thinking it's empty).  I'd rather require the rescan too much than deal with "missing" coins, etc.



858  Bitcoin / Armory / Re: RAM-Reduction & Backup Center Testing (version 0.89.99.8) on: November 04, 2013, 04:23:17 AM
WOO! it works and got my little stash recovered, thank you so much!


Fwhew!  What a huge weight off my shoulders!  Having a reliable OSX package has been on my TODO list forever, and I had no idea where to start with it, or who to recruit to help with it.  If anyone feels inspired to donate based on the availability of OSX support, I ask that you send your donations to picobit.  ATI (Armory Tech, Inc) will also be sending him some BTC whether he wants it or not!  (in exchange for a copyright release on the build script) 

859  Bitcoin / Armory / Re: RAM-Reduction & Backup Center Testing (version 0.89.99.8) on: November 04, 2013, 04:19:48 AM
I think I found an issue from my log, it doesn't really detect my system specs correctly.
Code:
2013-11-03 23:01 (INFO) -- armoryengine.py:800 - Detected System Specs    : 
2013-11-03 23:01 (INFO) -- armoryengine.py:801 -    Total Available RAM   : -1.00 GB
2013-11-03 23:01 (INFO) -- armoryengine.py:802 -    CPU ID string         : Unknown
2013-11-03 23:01 (INFO) -- armoryengine.py:803 -    Number of CPU cores   : -1 cores
2013-11-03 23:01 (INFO) -- armoryengine.py:804 -    System is 64-bit      : Unknown
2013-11-03 23:01 (INFO) -- armoryengine.py:805 -    Preferred Encoding    : US-ASCII

I have 4gb and my number of cpu cores is a negative number.

Actually that's expected.  I didn't know how to query system specs in OSX so I just skipped it and left the sentinel -1 values.  It doesn't actually affect performance.  It's really just there to assist with troubleshooting when someone sends a log file, and not important for any actual runtime operations.
860  Bitcoin / Armory / Re: Can i import Armory paper backup using other clients? on: November 04, 2013, 03:24:16 AM
No, you cannot import the paper backup to other apps.  Armory uses it's own deterministic wallet scheme so that you never need to make more than one backup.  However, if you really need to move your private keys, you will be able to get to them from inside Armory, in a format that is recognized by other apps.

When all the wallets upgrade to using HD Wallets (BIP 32), then those backups will become interoperable between Bitcoin applications. 

Concerns about Armory disappearing and not being able to access your keys are unfounded.  Armory is thoroughly distributed around the world, and even if Armory Technologies magically disappeared, and took the git repo with it, and all the google download links, you'd still only need to find a single person who has an installer for any version of Armory ever made.  Not to mention that someone could probably pretty easily write a backup reader to extract the private keys out of it.  Not to mention that the above scenario is ridiculous Smiley

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 [43] 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 ... 186 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!