Ermm, you still owe me 0.55 BTC, if I calculated bugs accepted since 1.1 BTC payment correctly.
Ah yes. Sorry I got distracted working on new wallets, and I forgot about fixing bugs in the master branch. I just sent it. Thanks for your help. More testing versions coming soon.  |
|
|
|
Hi I'm not sure why you think that's contradictory? The only difference between the two statements is that I said it must be OP_TRUE, the page says non-zero. Otherwise, they are the same statement. OP_TRUE is identical to the byte with byte value 0x01 = decimal value 1. Your interpretation sounds as if there is a unique "true" value, this one byte value. On the other hand, "true (non-zero)" means every stack-item which value is not 0 is interpreted as true. So if the final top-stack item is, say, 47 this would also be interpretated as true as well as the byte vector of length 3 "0x01 0x00 0x00" which is also not identical to OP_TRUE (but has the same value 1). I wasn't trying to give you rigorous implementation details. You asked a very general question in the top post, so I was giving very general description about how things work. It wasn't intended to be precise, as nothing that could be written here would be. You'll have to go to the reference code for that. |
|
|
|
If there are no more opcodes to run and the top stack item is not OP_TRUE, return SCRIPT_INVALID (I think I remember that's how it works...been a while...)
This contradicts the URL https://en.bitcoin.it/wiki/Script where is stated in the beginning of the article: A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero).
. So what is correct -- if you remember correctly?  I'm not sure why you think that's contradictory? The only difference between the two statements is that I said it must be OP_TRUE, the page says non-zero. Otherwise, they are the same statement. You can't get to "no more OP-codes on the stack" without the first condition stated by that page, "nothing in the combined script triggers failure". # Gavin clarified the effects of OP_0, and OP_1-OP_16.
# OP_0 puts an empty string onto the stack, which evaluates to
# false and is treated by HASH160 as '' (length=zero)
# OP_X puts a single byte onto the stack, 0x01 to 0x10
To be frank, I see here no subtilities. OP_X stands for the range of OP_1 up to OP_16, each pushing 1 byte onto the stack. OP_O in contrast like the whole range of nemonics with the byte values 0 - 75 each pushs 1 item onto the stack , a byte vector of length of its opcode. This sounds to me like independent kind to push data onto the stack (like OP_codes with byte values 76 - 78 a further different kind). Anyway, at least I think I have interpreted the same meaning from the URL https://en.bitcoin.it/wiki/Script like you. This is not necessarily intuitive, at least not from the naming. I spent many hours putting a single zero-byte onto the stack and trying to figure out why my script eval was failing certain OP_CHECKMULTISIG scripts. It's because OP_HASH160 obviously gives a different answer for "" (empty-string) than it does a single zero-byte. I see the page now says "put an empty string onto the stack" for OP_0 -- I'm pretty sure that was added after I complained to Gavin about how that is a rather important detail that wasn't documented. My only point was that there are lots of tiny details and they are likely not to be documented well. So, have fun |
|
|
|
to all those advocating observer wallets, read-only wallets, no-spend wallets etc:
imho, a good name communicates as much correct concepts as possible and few or none misleading ones. the term "wallet" is already a compromise, emphasizing "you can spend bitcoins with this" but omitting the fact that its not containing money, but permissions. "key collection" would be a different compromise.
so, when you call a thing you cannot spend bitcoins from a wallet, you use it for something that lacks exactly the one concept that made "wallet" a useful word in the first place. the term is completely void of correct concepts. yes, under the hood it looks a lot like a wallet file. in terms of functionality, it has as much to do with with a real life leather wallet as a dolphin or a fruit juice.
I think your point is dwelling too much on the literal meaning of "wallet", without acknowledging that many things in life, especially in tech, are named after things that they only approximately represent. I think "wallet" is a perfect euphamism for "key collection that lets you receive and send money" But you bring up a point that I like: the "Observer Wallet" doesn't have to be a "wallet". It could be more like a "collection box" or a "drop slot", etc. The only problem with that is that it still behaves much like a "wallet", and it's definitely more convenient to bundle it on the list of "wallets" like Armory does. And, I don't think it's incorrect at all to call it a "wallet" with an appropriate modifier, but you're right it doesn't have to be... EDIT: Actually, I'm not so sure I agree with not calling it a wallet. An "observer wallet" is nearly identical to other wallets, it just happens to be missing one operation. Users will use it exactly the same way. And especially for savings wallets, their interactions with it may be 99% the same as a "regular" wallet. |
|
|
|
I think some of these distinctions are academic. The reality is Bitcoin isn't ready for primetime. I have long believe (that dozens of other revolutionary technology) we are on a decade long timeline to mainstream usage.
random vs deterministic - nobody will care...
...
This thread isn't about how to make Bitcoin go primetime, or how to best market it to new users. It's about creating a common language for people that need that language. Many of these terms may be relics of the past one day, and many of them may never be seen by, or cared about, by grandma. But there's still plenty of users who need that language, because they're dealing with these things. Right now. And a lot of these potential users are people who will help build the foundation of Bitcoin's future. My goal with this thread is to make sure there's a friendly, coherent landscape for the users of the system, right now. Just because certain things may be relics of the past doesn't mean that we don't need to be intelligent about naming these things. The current user base is more advanced, more technical than the average person using text-message. But so is the current Bitcoin software. And if there are options for it, we need to at least make it as easy as possible for them to understand it. When Bitcoin is ready for primetime, I'll let the marketers figure out what to call these things, and what features users want. I'm someone who is constantly bombarded by users asking what the hell each feature is. How do I do this? Is this feature the same as that? Does it work the same in both this program and that? While the Bitcoin world consists of complicated options, we need a language to talk about it. You're talking more about how we'll market these things in the future, and how to choose which options are best for the user. I'm talking about right now, even while Bitcoin is still manual-transmission... |
|
|
|
Anything that doesn't meet the expectations of the OP-code results in an invalid script. If it takes two values and there's 0 or 1 values on the stack -- bail and return SCRIPT_INVALID If it checks a signature using the top stack item as a public key, but the stack data does not parse as a public key, return SCRIPT_INVALID If there are no more opcodes to run and the top stack item is not OP_TRUE, return SCRIPT_INVALID (I think I remember that's how it works...been a while...) etc There are lots and lots of subtleties. Things like this comment I found in my script processor: # Gavin clarified the effects of OP_0, and OP_1-OP_16.
# OP_0 puts an empty string onto the stack, which evaluates to
# false and is treated by HASH160 as '' (length=zero)
# OP_X puts a single byte onto the stack, 0x01 to 0x10
I have most of the opcodes testing in Armory except for th OP_IF/OP_ELSE/etc. But honestly, you should only use that like Wikipedia -- it might help you understand it, but there's not guarantee it's actually correct (I never even ran those script tests referenced above, because I had written this script processor before those tests were made [but I did have my own less-exhaustive unit-tests]). You pretty much have to go with Satoshi code or nothing if you want to make sure you're 100% compatible. |
|
|
|
Are we trying to come up with terms for regular folks or computer folks? I think the scope of the problem should be defined before really entertaining potential solutions. If I look at this thread and pretend that we are trying to name a JPEG file, the suggestions sound to me like the following names for a JPEG: "Tri-chromatic quantized raster image". "Non-palletized discrete cosine color map". Meanwhile, the rest of the world has settled on calling these "photos", and calling them "JPEG's" where there is any need to make a distinction as to how the picture is encoded.
If I put myself into "regular folks" shoes, there should just be one thing: "bitcoin wallet". You double click it (just like your e-mail inbox) and there's your bitcoins. Anything more complicated than that screams "this is for computer experts only". The Apple computer company has risen to stardom due to their intuitive grasp of this concept, and Microsoft is getting the burial it deserves.
Whether it's deterministic or not shouldn't even be in the regular user's lexicon. Whether it's random or non-random or whatever, shouldn't be either. Keep in mind that for the vast majority of users, if you simply tell them that a "bitcoin wallet" has the property of being able to spew out as many receiving addresses as they'll ever need, then they will take that at face value, without needing some sort of adjective qualifying the wallet as having that property.
From a technical standpoint, what kind of wallet it is should be denoted by the file extension, and the differences between certain kinds of wallets should be assigned certain file extensions (the extensions themselves may or may not stand for anything).
This way, if they need to make a distinction, it might roll off the tongue the easiest by calling it a ".BW3 bitcoin wallet", automatically incorporating by reference the exact nature of the "determinism" and "randomness" inherent in using the wallet, the same way calling a picture a JPEG automatically implies usage of the discrete cosine transform and Huffman encoding without the user having to say or even think about these.
I've been battling this question myself. The important question to ask is "what do users interact with?" Literally, what do they see on the interface? They interact with "wallets", of various kinds. They interact with "transactions" and "labels", and "confirmations", and "transaction amounts". The names need to start simple, and have a hierarchy that accommodates the various gradations of user education. You can't just call everything a "wallet" with no qualifiers, because that neglects the profound differences between different kinds of wallets. For users that use nothing more than "online, maybe-encrypted wallets", using "encrypted" or "unencrypted" is all the qualifier they need. But once you go beyond "standard" usermode, users have options and need to understand what those options are. And that's a million times easier if there's consistent names between the applications giving them these options. Armory uses deterministic wallets, Bitcoin-Qt uses "loose-key" wallets -- the user should care that "loose-key" wallets need to be backed up regularly. In this sense, anything that will show up on the user interface to the 80th-percentile-and-lower user base, should have simple, unique, fewer-syllables-preferred names. Things that only matter to developers, can have as complicated a name as they wanted. "TxOut trees" are fine because developers aren't actually developers if they're not used to things like that. And "deterministic wallets" are fine for developers. But for users, especially ESL and not-so-smart users, we need at least something they can call it, even if they don't understand it. |
|
|
|
Hot wallet, cold wallet, air-gapped wallet, deterministic wallet, are terms I use. They will change when technology changes. I like the gun analogy of single and double action for multisig transaction.
There's plenty of "slang" that can be used. I know that whatever we decide here will not automatically change the way people talk about these concepts. It would be fine to even put in the glossary that "Sometimes "offline wallets" are referred to as "cold storage"". But the important part is that application developers, in their apps, stick to consistent terminology. Then, new users who don't read the forums have consistency across (and even within!) applications. I mention "within", because even I've sometimes used different names for these things in different parts of Armory. |
|
|
|
30. After importing keys, Armory offers to either go offline and scan blockchain for transactions or stay online. If user selects the former option, wallet will stay opened and thus prevent user from seeing that Armory actualy went offline and is scanning blockchain. With silent storage devices, like USB and SSD, user might find himself confused. ~~~~~ 31. Open wallet > "Make Paper Backup" > enter wallet password > "Unlock" > "Cancel" > "Make Paper Backup" > if you repeat two steps before this one quickly, no password check will popup for around 5 seconds. In other words, once paper backup window is shown, there is around 5 seconds delay until password check kicks in. ~~~~~ 32. With no wallets created, if user clicks on "Create New Wallet" button or selects "Create New Wallet" from "Wallets" menu, window will be shown with empty "Wallet name:" field. However, if user clicks on either "Wallet Properties" or "Receive Bitcoins" or "Send Bitcoins" button and than agrees to create wallet, mentioned field will be populated with text "Primary Wallet". ~~~~~ 33. Create wallet window title is "Create/Import Armory Wallet" but user can't import wallet using window in question here. ~~~~~ 34. While in online mode and no wallets created > "Offline transactions" > "Create New Offline Transaction" > "OK" results in blank window being shown. ~~~~~ 35. Having two wallets with the same imported keys leads to numerous problems, including the last created wallet becoming undeletable, deleting one of wallets deletes the other one and "Transactions" tab listing going crazy after just one of wallets is deleted, like shown bellow - sorting of remaining transactions goes nuts as well, can't show it on screenshot:  (30) That was a design decision. Scanning should start as soon as possible. And the user may not be done with their business with that wallet. (31) Another design decision: passphrase is saved in RAM for 10 seconds. This allows subsequent functions (which may take a couple seconds) to still use the passphrase, but removes it from within 10 seconds to minimize exposure. (32**) I'll fix that window title. That window used to have an "Import button" on it, and it was removed without changing the title. (33*) Meh. (34**) Good catch. Need to disable that button. (35**) There's a fairly explicit warning against doing this. Unless you know how to accidentally import such a key without hitting this warning, it is already marked as "user beware". I'm giving the bounty, though, because it's been a while since I've checked this behavior, and you are pointing out that this is considerably worse than the warning suggests. I will upgrade the text to warn of the impending doom. (actually sounds like I should just flat out prevent it). |
|
|
|
You should make polls for the candidates
A poll would be impossible here because of the endless things to vote on. However, what I've done is bolded my personal preference, and will update as new consensus is reached. Please help with the more-advanced names. I can't even think of good names besides "Distribution". Though names that are descriptive with good abbreviations ("distro") are always good. But prefer something not too generic. |
|
|
|
24. Menu "Help" > "Armory Version..." > click on "No more reminders until next version" button > menu "Help" > "Armory Version..." > nothing!
~~~~~
25. While in offline mode, menu "Addresses" > "View Address Book" > message says address book will become available when Armory is online,
but user can actualy open it by double-clicking wallet > "Send Bitcoins" > click on address book icon.
~~~~~
26. On menu "Addresses", items "Import" and "Sweep" show the same message regardless of if some wallet is selected or not, and regardless
of there is just one wallet or more. In all cases, user is instructed to double-click on desired wallet > "Import/Sweep Private Keys". It
really makes me wonder why exactly those two menu items are there at all, and why there are two items pointing to same target. If it's not
a bug, selecting one of wallets - or autoselecting wallet if there is just one on list - than chosing any of items should result in exactly
the same as if user double-clicked on wallet > "Import/Sweep Private Keys"
~~~~~
27. On main window wallet list, clicking on some column header (ID, Name, Security, Balance) does not sort wallets based on column data.
~~~~~
28. On "Transactions" tab, attempting to sort transactions based on incoming / outgoing column does nothing. Icon tooltip for both types of
transactions - green arrow pointing at door and red arrow pointing away from door - says "Bitcoins received".
~~~~~
29. Is it normal that Armory scan complete blockchain on every run? Once scan is over and wallet balance is shown, exiting Armory and running
it again reveals (...) for wallet balance and complete blockchain scan starts all over again. Tested 3 times. Is it because my Bitcoin datadir is
not on default location?
- (24**) Good catch
- (25) That's part of the other bug you reported where you're not supposed to be able to open that window in offline mode to begin with (the Send-BTC window). The same problem exists on the message signing dialog which is also off-limits
- (26) That's intentional, because sooooo many people have complained that they couldn't figure out how to import/sweep, not realizing the operation is wallet-specific. I've gotten emails saying "YOU ADVERTISE EASY IMPORTING OF KEYS BUT I CANT FIND THE OPTION ANYWHERE!!!". I decided to add those menu options to give them some direction. I was considering popping up a wallet-select dialog instead, but I never got around to it, yet.
- (27) Similarly, that's an unimplemented feature, not a bug. It's surprisingly not-trivial to to enable sorting on tables.
- (28**) Another good catch.
- (29) That's a "feature." The primary benefit is that Armory stores almost no data between loads, making it very robust against perma-corruption bugs -- where something corrupts the between-load database and the user can no longer open the program or has permanently incorrect information. With this, just about anything that can go wrong is fixed by restarting. This made more sense when the blockchain was 500 MB (when I started), but will be changed soon (thanks, SatoshiDice!). Now that the app is stable and it's easier to implement it without such bugs.
|
|
|
|
The predecessor to Armory ( PyBtcEngine) used pure-python implementation of ECDSA. This implementation was created by forum user "Lis" here: http://bitcointalk.org/index.php?topic=23241.0If you plug that into google translate, you'll see that he declared that code to be public domain. It's not exactly fast, but it most definitely works. I was able to create, sign, and verify blockchain transactions with it. It is based on python's native handling of arbitrary-sized integers -- go ahead, open a python shell and type "2**10000" ... you'll see what I mean ) Not only can you verify that the code is just a basic EC library with hardcoded secp256k1 constants, it's stupid easy to wrap in a shell script to get whatever you need out of it. I would recommend using entropy generated from a reliable source (OpenSSL?), and pass that into Lis' script. His script uses the python "random" solely for testing that signing and verification work. But as is mentioned in python's own docs "python's PRNG is wholly unsuitable for cryptographic purposes". EDIT: also, you can use armoryengine.py, but it doesn't use Lis' code anymore... it uses Crypto++ libraries made available to python via SWIG. It has turned out to be pretty simple to compile and run on any Linux (even OSX, because you can use armoryengine.py without any Qt dependencies). But that could be a lot of code just to get to its ECDSA implementation. (you can probably strip out 90% of armoryengine.py, though, and keep just the ECDSA parts) Alternatively, you could extract my wrapper around Crypto++ and use that somehow. It does exactly what you want, and you can use publicly-verifiable download the crypto++ libraries, which have no external dependencies. (use only SecureBinaryData objects and all methods below this line). |
|
|
|
|
There's a lot of cool things that can be done with Armory. At the moment, I'm letting it fill its niche of trusting no one but yourself, as long as you have the patience to get it setup. There's clearly a high demand for that right now, and third-parties have no effect on Armory users.
I do want to improve dust management. My coin selection algorithm has a good start, but it only checks for how many unique addresses are on the input side, without regard for whether those addresses have been linked already. If I could get that implemented, it would make the dust cleanup problem much better. If you use one address a lot, right now, the dust cleanup should be pretty good. But it could be better.
Mixing is not really "my thing". I'll leave that to the third parties to do, and for users to manually execute through such third parties if they want it. I want to focus on the features that no one really has yet: multi-sig. I want to get two-factor auth via multi-sig implemented and usable, and sooner than later. I know there will be lots of hurdles and inconveniences with it, but the sooner we get going, the sooner we can learn and improve it. And the sooner people get to use their phone as a second-authenticator without actually needing a third-party.
On that note, I've been working on the new wallets, and decided I should just "start from scratch". By that, I mean, take everything I've learned since 12 months ago, and re-do it "The Right Way". It's not completely from scratch though, there's a lot of leftover, useful, tested code I am pulling in. But I think that the disruption right now is worth it in the long-run (like being able to encrypt the public keys/addresses in your watch-only wallet, so that theft of your online computer does not result in the thief knowing your net worth).
|
|
|
|
A new 0.3 BTC bounty: figure out how to get native HTML objects into the clipboard in PyQt. You don't need to add the button to the application, I just need a code snippet that doesn't result in plain text on the clipboard. I'm pretty sure QMimeData has something to do with it. This could be a super-easy 0.3 BTC! (I've tried before and failed, and don't feel like figuring it out right now...)
Hi, I haven't had a chance to try it out yet, but the 2nd answer to the below SO question should do the trick: http://stackoverflow.com/questions/10055421/with-qclipboard-how-can-i-copy-rich-text-and-have-it-downgrade-to-plain-text-foWell then, do it for me! Get your easy bounty! I bet it's easy. But I tried before but did something wrong and couldn't make it work. It's one of those things that has plagued me for a while, and really just needs a fresh set of eyes to do it. I don't need the button implemented, I just need the chunk of code I would plug into the method "clickCopyRichText()", which will go right next to clickCopyHtml(). Put it in, test it, test it with a variety of apps that support rich text, and then send/post the code and I'll give the bounty. I am enjoying the idea of buying my way out of annoying code problems |
|
|
|
(11) "(either transaction type can be saved here, depending on whether what is in the box is signed or unsigned)." Hmm, with file extension filter showing and allowing both signed.tx and unsigned.tx at all times, does it really matter what is in the box? I mean, will I be prevented from saving signed transaction in file test.unsigned.tx? If not, will Armory inform me I'm about to overwrite unsigned transaction with signed one? (13) Even in Expert mode, there is enough room for "Cancel" button next to "Send" one - at least on my side. (15) There quite a lot of space on right from truncated address - at least on my side. (19) Notepad++ shows links, highlights syntax and so much more. As said in PM, I do not expect everything I posted to be accepted as bug. It is just so much easier for me to report anything and everything I find not working, unusual and unexpected, and throw-in some suggestions - or even complaints - in the mix. If you think something does not pass the "Is it a bug or not?" test, it is fine with me, really. But OK, from now on, I'll avoid posting non-critical stuff. Don't read my response as a "don't do it" instruction. I actually appreciate the level of detail. But if I'm going to reject or reduce a bounty, I feel it deserves justification (i.e.- responding to each one). As long as you keep batching them up like that, I'm fine with the tiny things, as long as you're fine that I'm not rewarding every one. (11) The user may want to see what other transactions they have in the folder, signed or unsigned, while deciding on a filename. Although, the filename is auto-filled if there is useful data in the box, so there's not really a problem with overwriting. (13,15) There's room at the default window size. But these windows also need fit nicely when size-reduced on, say, netbooks. I've gotten a lot of complaints about compactness, so I pick and choose what I think is important. I was just pointing out that (13) and (15) were explicit decisions to save space. That's all. (19) Admittedly, I couldn't get the "Click to copy to clipboard" button to work right. I have lots of examples copying plain text to clipboard, but not HTML. Perhaps this would behave a little more consistently if I do that. A new 0.3 BTC bounty: figure out how to get native HTML objects into the clipboard in PyQt. You don't need to add the button to the application, I just need a code snippet that doesn't result in plain text on the clipboard. I'm pretty sure QMimeData has something to do with it. This could be a super-easy 0.3 BTC! (I've tried before and failed, and don't feel like figuring it out right now...) |
|
|
|
For instance "JBOK wallet" is practically impossible to localise - if you translate each word you'll get a completely different acronym in every language. A couple of terms like that and you will have acronym spaghetti.
Yeah, I wasn't entirely seroius about JBOK. I put it up there to get gears turning about what the wallet actually is, and then people can come up with better stuff. I was just amused by Casascius' suggestion. Most of the others up there are serious. Funny you mention localization, I was just looking into that for Armory. I guess that's another good reason to use simple words -- likely to translate cleanly. I really don't like "watch-only wallets." That actually inspired this whole thread, because they're kind clunky and "watch-only" is more of a description than an adjective (or descriptive noun). I'm really digging "Observer wallets". |
|
|
|
I always thought "one way wallet" sounded better than "watching only wallet". Not only is it shorter on syllables, it's alliterative too (well, phonetically!)
I am a big fan of "observer" wallet, as Eliel proposed in IRC. But you're right that it doesn't quite capture the fact that you can "do" something with that wallet (generate addresses, receive money). I'll add "one-way wallet" to the list. Though I bet there's an even better term for it, that explains which way it goes |
|
|
|
How about we work to rename non-deterministic wallets as "loose key collections" or "JBOK's" (just-a-bunch-of-keys) and give them the mouthful name as part of effort to deprecate them? Then, at some point, just set the expectation that a "wallet" is something where backing it up once is just a normal feature, just like the way you expect italicized text to be a feature of a "word processor".
I do agree with that. At some point in the future, I hope that JBOK wallets will no longer exist (except in history, and maybe specific, specialized applications). And then we don't need to differentiate them. But maybe it still warrants having a "long name" for them, anyway. Especially since they still need to be distinguished from HD wallets. Maybe: "Single-branch wallet" |
|
|
|
As I get deeper and deeper into Armory feature development, I find myself making names for things in Bitcoin which are really just dull descriptions of what they are. Such as "watching-only wallets". And "tx distribution proposal". Things like "deterministic wallets" and "Hierarchical deterministic wallets" are great enginerd phrases, but I think fewer syllables and less-fancy words are needed. If we can make them a little sexy, too, that would be great. Additionally, these things are not consistent between clients. I just found out that Armory uses "Watching-only wallets" and Electrum uses "Deseeded wallets". I really think the community would benefit from having a consistent terminology that can be learned once via a glossary put on the bitcoin.org webpage, and then new users have a way to learn what all these crazy concepts are about. Also, some of these things are future concepts for which it wouldn't hurt to agree to it before any devs implement them. So, I'm going to create a dynamic list of things here that I think need standardized names, and update it with the recommendations of subsequent posters. I'm okay rebranding the concepts in Armory (I'll throw in a pop-up window on the next upgrade with a link to a glossary). I hope that devs of other clients (Multibit, Electrum, Android apps, etc) will entertain the idea of changing their apps if these standardized names make sense.
Top contenders are bolded. Other options are listed to get neurons firing about other names. (A) - Concept: "Regular" wallets kept on an online computer, encrypted or not. It may be acceptable to have a couple different names for this, given it's broadness.
- Candidates: "Online Wallet", "Regular Wallet", "Hot wallet", "Full Wallet"
(B) - Concept: "Offline wallet" -- a wallet for which the private only exist on an internet-detached computer
- Candidates: "Offline Wallet" "Cold Wallet", "Detached Wallet", "Air-gapped wallet"
(C) - Concept: The concept of keeping your private keys offline (the previous term should probably be related to this)
- Candidates: "Offline Storage", "Cold Storage", "Cryo", "Detached Storage"
(D1) - Concept: "Watching-only wallets" -- a wallet containing no private key data, only public keys and/or addresses for watching balances
- Candidates: "Observer wallet", "Receiving Wallet", "Deseeded wallet" (Electrum term), "One-way wallet", "Hollow wallet", "Skeleton Wallet"
(D2) - Concept: "Full wallet" (when distinguishing from a "watch-only" wallet)
- Candidates: "Full Wallet", "Private Wallet", "Complete Wallet"
(E1) - Concept: "Deterministic wallets" -- this is just far too nerdy: it describes exactly what it is, but is a word that no foreigner would know (or even pronounce), and this is pretty much meaningless to new users who don't understand what is "deterministic" about the wallet or what is the alternative.
- Candidates: "Chained wallet", "Calculated wallet", "Permanent wallet", "Crystal wallet", "Pre-determined wallet","Single-branch wallet"
(E2) - Concept: "Non-deterministic wallets" -- This is what Bitcoin-Qt uses right now, and should be deprecated.
- Candidates: "Loose-Key Wallet", "Old-style wallet", "Random Wallet", "JBOK (Jay-Bock) wallet" (just a bunch of keys)
(F) - Concept: "Hierarchical Deterministic wallets" -- same as above, but this one is even worse
- Candidates: "Branched wallet"
(G) - Concept: Linked wallets -- multiple wallets that represent a single entity via multi-signature transactions -- i.e. Computer has wallet A, smartphone has wallet B. All receiving addresses are P2SH addresses. These two wallets are:
- Candidates: "2-way linked wallets", "Sister wallets", "Sibling wallets", "Multi-signature wallets", "Paired wallets", "Partial wallets"
(H) - Concept: "Transaction Distribution Proposal" -- multi-signature transactions will require passing an unsigned/partially-signed transaction between parties to be signed. This piece of data/file proposes how the funds from a multi-signature transaction should be distributed. Parties may accept the proposal by signing it.
- Candidates: "Transfer Order", "Distribution", "Proposal", "Distro", "Prop"
(I) - Concept: Pre-broadcast Tranasction ID: the "transaction distribution proposal" above needs a way to be referenced, but you can't use its official "Transaction ID" because you don't know it until all signatures are acquired. I'm thinking it would simply be the hash of the transaction without all the TxIn scripts blanked.
- Candidates:
 ??, "Pre-broadcast ID", "Distribution/Distro ID", "Proposal/Prop ID", "Temporary ID"
(J) - Concept: Multi-signature transactions -- any transaction spending coins that require multiple signatures
- Candidates: "Multi-sig tx", "Multi-party tx", "Joint transaction"
(K) - Concept: Multi-signature encumbered coins -- any funds currently requiring multiple signatures
- Candidates: "Encumbered funds", "Joint funds"
(L) - Concept: "bitcoin:" links/URLs
- Candidates: "Bitcoin URLs", " \"bitcoin:\" links", "Clickable Addresses"
|
|
|
|
( Of course I have Bitcoin-Qt on computer, you could see that in log file attached to my first post. Client is installed in default location, but data directory is on D: partition and I haven't yet come to part where I need to instruct Armory where to look for Bitcoin datadir. Points with report is that Armory does detect if Bitcoin-Qt is running or not but only if Bitcoin-Qt is started before Armory, even when it can't find data in default directory. I think your first screenshot is pretty clear about how to point Armory towards your blockfiles: run Armory with the " --satoshi-datadir=" option. |
|
|
|
|
Show Posts
