4. Create encrypted wallet then make it unencrypted. Wait like 10 seconds and click on "Make Paper Backup". Password prompt will popup even though wallet is unencrypted. The only way I found to fix the issue is to restart Armory. ~~~~~ 5. Import two valid keys, click on "Backup Individual Keys" and than set checkboxes as shown on screenshot bellow. Both keys will have the same chain index - negative one? - and invalid description shown, e.g. "(Unused/Address Pool)" instead of "(Imported)". https://i.imgur.com/qM87H.png~~~~~ Clickable link to clipboard functionality still does not work for me. In both NotePad++ and WordPad all I get is just plain text, as shown: Click here to pay for your order!
If clicking on the line above does not work, use this payment info:
Pay to: 13MtyJVMRAR9v3Jp3ujuKHxTheSqDP7uDC
Message: Joe's Fish Shop - Order #123 - 3 kg tuna - (888)555-1212 HTML and URL buttons work as expected, but once clicked, text " Copied!" pushes QR code to right, hidding almost half of it. I'll look at these when I get home tonight, but I should mention that I downloaded NotePad++ and was not able to get it to accept link text. I noticed that it highlights URLs for you, but that's different than accepting&displaying rich-text. I used MS Word and the "Compose" window in Gmail to test that the links copy correctly in my Windows VM. |
|
|
|
Are you going to open a translation project on transifex.com or crowdin.net?
Armory source code is not in the correct condition for translations. There is currently no unicode support, and I never implemented any of the hooks for adding translations/localizations... That said, the new wallet files will have unicode support, and I'll take the opportunity to upgrade the GUI to go with it. At the same time, I will add those hooks needed for translations. THEN, I can start soliciting help doing translations. Until then, there's not much to that can be done (any unicode characters added by the user, just about anywhere, crash Armory). |
|
|
|
Feature request: In addition to the existing passwords for the wallets, which are really passwords covering the secret keys of the wallets, it would be nice to have a password for viewing. Now, starting Armory, all the balances and addresses are shown directly.
Ah hah! It's funny you bring that up, because I was just in the process of designing my new wallets in such a way this would be possible. It probably won't be enabled on the first release, but I'm putting "EncryptionObject" entries next to each wallet entry which could be used to implement exactly what you just requested. It's becoming quite a massive undertaking, as I've ended up basically rewriting the wallets from scratch. But it's being rewritten in order to give it the flexibility to things like this without redesigning it again. The only problem is that this passphrase will be typed all the time, and the encryption key will have to sit in memory the whole time Armory is open. There's no way users will pick a different passphrase for their private keys and their public keys, and that makes this a pretty significant risk... I might only offer the feature on offline/watching-only wallets and plaster warnings everywhere (not that it necessarily helps, but users should be aware of the risks they take by using passwords that protect important things, on things that aren't that important). But I totally appreciate the desire to not have someone steal your laptop and learn (1) that you have $100k BTC probably at your house on an offline computer and (2) the address to your house. |
|
|
|
I suppose that wouldn't be too hard to do. But what is the application? So that you can show someone a QR code from the other end of the airport terminal?  It's useful if you are behind a desk in a shop, and you need to show the QR-code and only it to the customer. Multibit has the same feature. I can see the value as well: some phones do a piss-poor job of focusing up close. By allowing it to focus on a full screen several feet away, that problem is solved. Agreed. I just wanted to understand the application to make sure the feature makes sense, and maybe I can add something other twists that would further improve it. In this case, I'm not sure I can improve it further. Sounds like "make-it-BIG" is precisely what's needed. It should be pretty easy to implement, so I should be able to get it into the next release (which will hopefully be soon!). On that note, please help test and find bugs! kthxbye |
|
|
|
I have a feature request - Wherever is shown a QR-code, if the user double-click on it then it will enlarge to take all the screen (mainly). Double click again and it will back small. I suppose that wouldn't be too hard to do. But what is the application? So that you can show someone a QR code from the other end of the airport terminal? |
|
|
|
One thing quite annoying IMO = once everything is setup correctly (Bitcoin-Qt running and synced, Armory pointed to correct datadir)
and Armory is started, it will sync with the blockchain - humilliate HDD - even if no wallets are created. Is there some good reason for
such behaviour? From my observations, while scanning blockchain, Armory is building database of all addresses he finds there. If user
attempts to sweep or import some key afterwards, Armory might warn address belonging to key is not associated with any transaction
and than cancel rescan. That is a cool feature, but what if user started Armory just to copy / paste some existing address, generate
a new one or anything other than sweep or import keys, which are activities that happen probably more often than sweep or import?
Why is that annoying? There's no reason to be using Armory if you don't have any wallets, so you might encounter this unnecessary scan once, maybe twice. Ever. And even so, the original scan is still needed and not redundant if you create a new wallet -- because creating a new wallet does not trigger a "dirty" state. It can piggyback off of the original scan knowing that there's no point in rescanning when you've never seen these addresses before. So it works out nicely if it takes the person 5 min to create a wallet and make a backup. It will be done scanning and ready to be used by the time they're done. I'm not sure I understand your complaint/recommendation about sweeping or importing... but I can tell you that I don't have a good way to interrupt a scan operation. You pretty much have to wait for it to finish and then start a new rescan (which it will do if you import or sweep). It's mentioned somewhere (but I forgot where), that you can always start Armory in offline mode to import private keys, and then go into online mode so that it will grab everything in one scan. I will investigate the sweeping problem, more -- that sounds like a pretty serious problem! I got your two log files from sendspace... does one of those have the errors you encountered while sweeping/importing? Also, I will add an extra code path to catch trying to get to the address book without wallets. By the way, tools->message signing is still off-limits. It will all be re-vamped when I get the new wallets and synchronize the message signing interface with Bitcoin-Qt. Thanks again for the diligent testing. |
|
|
|
~~~~~
34. While in online mode and no wallets created > "Offline transactions" > "Create New Offline Transaction" > "OK" results
in blank window being shown.
~~~~~
Not fixed! Let me reset report counter, LOL! 1. While in online mode, open empty wallet and than proceed to import or sweep keys but click on "No" once Armory asks to go offline and scan blockchain for transactions. New address will be shown in wallet, I guess the one from unused pool. Repeat the procedure one more time, so that two addresses are shown in wallet, than click on "Addresses used" number on "Wallet Properties" window. You will see the same as on screenshot bellow = 2 addresses on list, 1 address reported as used on "Extend Address Pool" window and 0 next to "Addresses Used" on "Wallet Properties". https://i.imgur.com/11ro2.png~~~~~ 2. Attempting to sweep key resulted in crash presumably because I clicked on "Cancel" at final warning window that pops-up once the blockchain scan is completed ("Are you sure you want to sweep funds to this wallet?" or similar message). Another crash after attempting to import "reverse" form key version of key that is not "reversed". Both crash Win reports point to same file - check screenshot bellow. In both cases, looking at the log file, Armory seems to go crazy with block count. After one of this crashes and subsequent run, it even reported Bitcoin-Qt is not synced while it was actualy synced. https://i.imgur.com/uDlJY.pnghttp://www.sendspace.com/file/kfwzd3Oh boy, lots to look into. Can you send me the log file? I'll send you... a lot of BTC (probably 0.5) |
|
|
|
I wish Bitcoind was a universal backend that all the clients (including Bitcoin-Qt) could use to acquire blockchain data and transmit transactions to the network.
That's basically how I'm using it, and something that the core Bitcoin-Qt devs have brought up in the past as a possibility. I think they're very concerned about the network risks of independent implementations forking the network, and realize that providing a detached blockchain manager/backend (kind of like the necessity to have .NET on Windows machines for some apps) would aid app developers in creating new functionality without forking the network. Until then, I still have to answer the dozen emails a month asking when I'm going to get rid of bitcoind/bitcoin-qt dependence... for the sake of security, I can't. Though, as I mentioned to casascius... I can have lite-clients that connect to full Armory nodes that are using bitcoind/Bitcoin-Qt, thus making it unnecessary for the endpoint to have it running in the background... |
|
|
|
I wish Armory were split up between a knowledge center I could run on a server (with the Bitcoin-Qt dependency were limited to here), and a desktop client based on trusting the knowledge center.
I've been thinking about doing this for quite some time. It's basically the Electrum model, but without the hardcoded list of pre-trusted nodes (which may be added in the future, but I hadn't planned on maintaining any such servers/networks yet). The main hurdle is getting Armory to operate with less than full blockchain information. Honestly, I don't think it will be terribly difficult to do, but it would require touching just about every section of code. I guess the other hurdle is deciding what is "enough" information, and if I should consider secondary sources, etc (like downloading headers from other peers so I have some way to verify information coming from your "trusted" node). However, what is in store already, which may fit your particular desire, is to have Armory connect to any trusted full node. It would duplicate the blockchain data, but it wouldn't require having Bitcoin-Qt running on the same system, and could even use some other kind of full node, as long as it's a trustworthy one. And the act of maintaining its own blockchain data also means it will be using proper HDD-based storage and use dramatically less RAM. I'm working on multi-sig and split-wallet/shared-wallet/joint-account/whatever-you-call-it wallets upgrades right now. I may not actually get multi-sig implemented yet, but I want the new wallet files for a variety of other reasons. After that, I'll be doing the RAM reduction which will give you the any-trusted-node capability. I will continue pondering how much work it will be to have Armory run in a client-server mode (it would actually be client-server-bitcoind... since Armory-lite would connect to Armory-full which would still be running behind bitcoind) |
|
|
|
Reposted from the BOUNTIES thread:
Okay! Since I'm hoping to make this an official release, I've upped the bounties to 0.2 BTC. Yes, that's almost $3 per bug! However for this round, smaller bugs like most of what subSTRATA was posting will not be considered for the 0.2 BTC. I already fixed 21 bugs/suboptimal features based on subSTRATA's diligent testing, but for this release I'm really looking for the big things that actually prevent users from using the features of the software. Usually this is stuff like transactions not sending because I broke some networking code, or dialogs that are don't show up, or display garbage. And of course, crashing. The minor bugs and polishing will still be rewarded, but only 0.05 BTC. This version has full QR-code integration and copying payment request links in Windows finally seems to work. I have also uploaded the new releases to code.google.com because it has all the features I need in a project-hosting site: scriptable uploads, download counting, folders, etc. http://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_win64.msihttp://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_windows_all.msiAnd since this is a new download location, I have signed the SHA1 hashes using the offline signing key, in case anyone wants to verify them. The nice thing is that google-code shows you the hash there (though it's still preferred you hash the downloaded file, to be sure). http://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_sha1.txt.ascAnd just in case you find GPG/PGP annoying, here's a signed message, ironically using Armory's message-signing interface that I said was offlimits for bug reports (it works, but it's messy and hasn't been maintained for a while. Simply go to "Tools-->Message Signing" and then click on "Import Signature Block" and copy the following text into it: -----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message: "2013-Jan-06 02:51pm -- Downloadable Armory insta"
"llers will now be hosted at http://bitcoinarmory"
".googlecode.com. The first release at this new "
"location is version 0.86.7-testing, and has the "
"following SHA1 hashes -- 64-bit version: 3f6a4a"
"c9cdb98c421c883e15cf0acd52b7c25d31 and 32-bit ve"
"rsion: f3f3ee3de0d0434f1fd41664f456e755efaed1e2"
PublicKey: 0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
7571cbe492a7222442b75df75b9a84
Signature: 77a6f9a9e28b92b730216c5c6e62b89f6336d36e4bb1a0cbc3
42d5f3a6d5d9ea4032cafe8b3d7e9be249aac4b79bf663f96f
5ac4662d4f18ee4e76514ce8087c
-----END-SIGNATURE-BLOCK---------------------------------------
|
|
|
|
Okay! Since I'm hoping to make this an official release, I've upped the bounties to 0.2 BTC. Yes, that's almost $3 per bug! However for this round, smaller bugs like most of what subSTRATA was posting will not be considered for the 0.2 BTC. I already fixed 21 bugs/suboptimal features based on subSTRATA's diligent testing, but for this release I'm really looking for the big things that actually prevent users from using the features of the software. Usually this is stuff like transactions not sending because I broke some networking code, or dialogs that are don't show up, or display garbage. And of course, crashing. The minor bugs and polishing will still be rewarded, but only 0.05 BTC. This version has full QR-code integration and copying payment request links in Windows finally seems to work. I have also uploaded the new releases to code.google.com because it has all the features I need in a project-hosting site: scriptable uploads, download counting, folders, etc. http://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_win64.msihttp://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_windows_all.msiAnd since this is a new download location, I have signed the SHA1 hashes using the offline signing key, in case anyone wants to verify them. The nice thing is that google-code shows you the hash there (though it's still preferred you hash the downloaded file, to be sure). http://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_sha1.txt.ascAnd just in case you find GPG/PGP annoying, here's a signed message, ironically using Armory's message-signing interface that I said was offlimits for bug reports (it works, but it's messy and hasn't been maintained for a while. Simply go to "Tools-->Message Signing" and then click on "Import Signature Block" and copy the following text into it: -----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message: "2013-Jan-06 02:51pm -- Downloadable Armory insta"
"llers will now be hosted at http://bitcoinarmory"
".googlecode.com. The first release at this new "
"location is version 0.86.7-testing, and has the "
"following SHA1 hashes -- 64-bit version: 3f6a4a"
"c9cdb98c421c883e15cf0acd52b7c25d31 and 32-bit ve"
"rsion: f3f3ee3de0d0434f1fd41664f456e755efaed1e2"
PublicKey: 0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
7571cbe492a7222442b75df75b9a84
Signature: 77a6f9a9e28b92b730216c5c6e62b89f6336d36e4bb1a0cbc3
42d5f3a6d5d9ea4032cafe8b3d7e9be249aac4b79bf663f96f
5ac4662d4f18ee4e76514ce8087c
-----END-SIGNATURE-BLOCK---------------------------------------
|
|
|
|
By the way, to answer the original question... about a year ago, user "bittrick" submitted something resembling documentation about the technical details of Bitcoin: https://bitcointalk.org/index.php?topic=41718.0He spent a lot of time in the code and attempted to capture some of the subtler behaviors of the client. It's not a "specification" but it is an excellent starting point for understanding what's going on. Back to argument about "specification"... I absolutely support documentation, and especially written nuggets of information that are difficult to deduce (such as that OpenSSL behavior that Mike Hearn mentioned). I think it's critical to have these kinds of things to help people understand what they're looking at/for. Especially if they plan to dig into the C++ code afterwards. And certain parts of the system very well could be specified (perhaps much of the networking protocol). But not all of it, especially the script-validation engine. On the topic of OpenSSL... is it possible to reimplement the OpenSSL behavior, or at least extract it from where it is currently, and have it hardcoded into the Satoshi client? Or rather, does the license allow you to redistribute the OpenSSL project/source with the project so that it can be static compiled? I guess you only need a .a/.lib, but I'm not sure what the OpenSSL license is like. That would certainly resolve any issues related to dynamic linking to system libraries that might be different versions on different computers. It would make the project immune to system library upgrades, which is probably better for security anyway (an attacker could simply swap out the system OpenSSL with a different version having a known bug that he could exploit, and even a diligent user wouldn't notice because the signatures and checksums on the Bitcoin-Qt source distribution are correct). |
|
|
|
Check out the new QR stuff in the testing branch! If you like it enough and use smartphones a lot, you can donate here:  |
|
|
|
By the way, I am not able to compile the CppBlockUtils.py or _CppBlockUtils.so code.
Then how are you running with the new code? The .so most definitely needs to be recompiled to use the new stuff. I would expect seg faults, not hanging, but computers are weird.... I recommend checking out the current Armory branch to a different directory, type "make", and then copy the CppBlockUtils.py and _CppBlockUtils.so over to the BitcoinArmory-Daemon directory. Then it should work. |
|
|
|
I have recently pushed changes to the daemon to bring it up to date with the latest armoryengine.py Unfortunately I am unable to load the blockchain, and am getting these errors. (ERROR) armoryengine.py:11362 - Error processing BDM input
(ERROR) armoryengine.py:11363 - Received inputTuple: StartScanRequested [8, 28474661, False]
(ERROR) armoryengine.py:11364 - Error processing ID (28474661) MAV thanks! I have a fully operational bitcoind daemon (Debian 6) and also get the same errors. Does the CppBlockUtils.py and/or _CppBlockUtils.so can stay on the same version or do they need a more accurate version also? That's definitely going to have to be recompiled. On that note: mav, did you change any of the C++ code? Or were you just using the stock armory code, and just putting a wrapper around it? If you just wrapped it, it may be better to just fork the BitcoinArmory repo and add your .py files to it. Then updates are just a "make" away, and goes pretty smoothly on all linux distros (few dependencies, and no version requirements on them). Aaaaack been a long time since I looked at this and forgot to copy the new _CppBlockUtils.so to the repo. I have not changed any c++ code, this is just a wrapper. I am going to put this on hold until the changes are made. Then I will properly re-assess the situation and put this in a fork of BitcoinArmory rather than as a standalone daemon with the .so binary included. Actually, this may not be so bad. I was busy preaching about all the changes and how it was all worth the effort given the usability improvement for Armory GUI ... but actually you may be relatively unaffected as long as you set blocking=True. In general, the GUI is advancing, not the library, so you don't have to upgrade like this often. I just browsed your code and didn't see a whole lot that has to be changed, except you need to replace "TheBDM.LoadBlockchain()" with "TheBDM.setBlocking(True); TheBDM.setOnlineMode(True)". There might be a couple minor things that you have to update, and please post here with any more issues and I bet we can clear them up quickly. But overall you don't appear to be using many things that changed. |
|
|
|
|
I'll chime in: Mike Hearn is absolutely right.
There's nothing wrong with writing "documentation" to help describe at a higher level what is going on. As a developer of a non-validation client, such documentation has been quite useful. I fully support "extra stuff the describes at a high level what's going on". But you must understand that once you put the word "specification" on any such document, you are promising the reader that the document is sufficient for creating a compliant implementation of what is being described. But with Bitcoin, anything short of the source code itself is not sufficient for implementing it. And worse, the consequences of not doing so will result in people losing money -- because if there's an inefficiency in the system an attacker will exploit it, guaranteed (especially one where your target uses code that validates differently than much of the rest of the network). This is why Satoshi did not support alternative implementations.
Write all the "documentation" you want, and put as many comments into the code as you want. But do not use the word "specification" because nothing except the code can qualify for it.
|
|
|
|
I have recently pushed changes to the daemon to bring it up to date with the latest armoryengine.py Unfortunately I am unable to load the blockchain, and am getting these errors. (ERROR) armoryengine.py:11362 - Error processing BDM input
(ERROR) armoryengine.py:11363 - Received inputTuple: StartScanRequested [8, 28474661, False]
(ERROR) armoryengine.py:11364 - Error processing ID (28474661) MAV thanks! I have a fully operational bitcoind daemon (Debian 6) and also get the same errors. Does the CppBlockUtils.py and/or _CppBlockUtils.so can stay on the same version or do they need a more accurate version also? That's definitely going to have to be recompiled. On that note: mav, did you change any of the C++ code? Or were you just using the stock armory code, and just putting a wrapper around it? If you just wrapped it, it may be better to just fork the BitcoinArmory repo and add your .py files to it. Then updates are just a "make" away, and goes pretty smoothly on all linux distros (few dependencies, and no version requirements on them). |
|
|
|
I have recently pushed changes to the daemon to bring it up to date with the latest armoryengine.py Unfortunately I am unable to load the blockchain, and am getting these errors. (ERROR) armoryengine.py:11362 - Error processing BDM input
(ERROR) armoryengine.py:11363 - Received inputTuple: StartScanRequested [8, 28474661, False]
(ERROR) armoryengine.py:11364 - Error processing ID (28474661) Any ideas why these errors are being thrown? This is happening in TheBDM.run() The daemon still runs and correctly responds to getnewaddress however I haven't got a suitable wallet to test the other calls, namely: getbalance getreceivedbyaddress listtransactions sendtoaddress Please see https://github.com/thedawnrider/BitcoinArmory-Daemon/blob/master/armory-daemon.py for the source Oh boy. I forgot about this thread, and should've warned you that I converted Armory to a multi-threaded application. As such, some of the interfaces changed a bit. There is an example of blockchain loading in the extras/sample_armory_code.py file, but I'm not sure all the samples are up-to-date for the new multi-threaded code. On the upside, just about any function that doesn't return something (like blockchain scanning) you can use wait=False and it will run in the background allowing you to do other operations while you wait. You'll see what I mean if you look at the blocking vs. non-blocking methods, shown in sample_armory_code.py: ################################################################################
if run_LoadBlockchain_Block:
start = RightNow()
TheBDM.setBlocking(True)
TheBDM.setOnlineMode(True)
# The setOnlineMode should block until blockchain loading is complete
print 'Loading blockchain took %0.1f sec' % (RightNow() - start)
topBlock = TheBDM.getTopBlockHeight()
print '\n\nCurrent Top Block is:', topBlock
TheBDM.getTopBlockHeader().pprint() As above, if you set blocking to True, it should behave much like the original... the main thread always waits for a response from the BDM before continuing. On the other hand, if blocking=False (default): ################################################################################
if run_LoadBlockchain_Async:
start = RightNow()
TheBDM.setBlocking(False)
TheBDM.setOnlineMode(True)
print 'Waiting for blockchain loading to finish',
while not TheBDM.getBDMState()=='BlockchainReady':
print '.',
sleep(2)
# do other stuff while waiting...
print 'Loading blockchain took %0.1f sec' % (RightNow() - start)
topBlock = TheBDM.getTopBlockHeight()
print '\n\nCurrent Top Block is:', topBlock
TheBDM.getTopBlockHeader().pprint() In this case, the blockchain scan happens in the background and the main thread continues running immediately, giving you an opportunity to do other calculations or operations in the main thread. If you use the setBlocking=False, you should ALWAYS check theBDMState() before making a call like getTopBlockHeader() which you expect to return data -- anything that returns data is blocking by default. Use a conditional like this: if TheBDM.getBDMState()=='BlockchainReady':
# The blockchain is loaded and TheBDM is sitting idle waiting for something to do
elif TheBDM.getBDMState()=='Scanning':
# Currently scanning the blockchain, go do something else
elif TheBDM.getBDMState()=='Offline':
# Blockchain is not loaded and was not requested to be loaded (usually because of --offline)
elif TheBDM.getBDMState()=='Uninitialized':
# The BDM expects it will be online at some point, but the blockchain isn't loaded yet "Uninitialized" and "Offline" are pretty much the same, so I usually use "if TheBDM.getBDMState() in ('Uninitialized','Offline'): ..." Anyways, I'm sure there's other things that are new, but obviously ArmoryQt.py is functioning correctly, so there's lots of sample code in there. Really, 95% of it is the same, just some new/renamed calls and slightly different arguments. For this application, you probably want setBlocking(True), since you might just be adding complication to an app that doesn't actually need the multi-threading. If you run the latest Armory GUI, you'll see why I made the change. MUCH better user experience... Sorry about that! Please pester me about more errors, and I'll help you recover from this under-the-hood overhaul... (and sorry in advance, there's probably another one coming... upgrading to completely new wallets and unicode support...) |
|
|
|
|
I just realized that "multi-sig transactions" are clunky not only because of the unfriendly wording, but also because I don't believe that "transaction" is the way users will understand them. Every coin in the network has a script attached to it describing how it can be spend. Most of them require one signature. Some require multiple signatures. This is a property of the coins more than it is a "transaction". Yes, it requires a "multi-signature transaction" to spend them, but users typically think about how they "hold" the coins, not how they spend them. I've found it much easier to describe to Bitcoin newbies this way.
I think it makes sense to ditch "multi-signature transactions" and, if anything, use "multi-wallet coins", or "split-wallet funds". Actually, it's probably worth separating out two different terms even though they are both the same concept under-the-hood:
(1) Multi-signature coins that require the signatures of 2 or 3 devices you own: "double-protected coins", "two-factor coins", "split-wallet coins", "multi-wallet", etc
(2) Multi-signature coins that are serving as escrow between 2+ parties that don't trust each other: "encumbered coins", "two-party funds", etc.
|
|
|
|
Hi Alan,
Re: having a lite version of Armory.
Have you looked at the Bloom filter work that should be going into bitcoin-QT v0.8 ?
The Bloom filter is set on the server side so you only download the relevant tx.
Makes it O(size of your wallet). Mike Hearn and Matt Corallo have also been adding support into bitcoinj for it.
For mobile apps it should be good as it reduces the (expensive) data they consume.
Of course there are several ways to do things.
I understand bloom filters, but I haven't understood how they are used in this context. Is it: you send a peer your bloom filter (after your addresses have been applied to it), and they filter out all transactions for which none of the recipient addresses match your bloom filter? You probably get false positives, but dramatically reduced set. Although, I thought the filters were generally pretty big, so I wasn't clear how easy it was to share them with other peers. I'm very interested in this idea, nonetheless. I'm going to go back to my new wallets, and if I see a link pointing me to where I can learn more about them implementing bloom filters in Bitcoin, I'll happily take a break to read it  |
|
|
|
|
Show Posts
