Armory wallets should always be thought of a "deterministic wallets", and imported keys basically being a bonus feature.  If you spend money from any one of your keys (imported or not), its change gets sent to the next unused address of your deterministic wallet. 

I don't know what you mean by "run out" and "generate more".  The wallet is deterministic meaning that your paper backup provides the seed that allows you to generate an infinite number of keys, and that whole process is transparent to you (and repeatable).  You never "run out", and "generating keys" simply means retrieving the next key in the sequence based on the information on your paper backup. 

No offense taken.  I would like others to look at it and sanity check things.  I've done quite a bit of it during unit testing, but I wouldn't mind having some others vouch for it, too.

I have documented my wallet files which should make it easy to spawn a watching-only copy of one of your wallets and examine the binary of the *.wallet file.  The 32 bytes where each private key is stored should be all zeros. 

In a PyBtcAddress serialization, the private key starts 108 bytes into the 237-byte field.  In your wallet file, the root key starts 846 bytes from the beginning of the file, meaning bytes 954 to 954+32 should be zeros in your watching-only wallet. 

Can you remind me how "the miner gets it automatically"?  I think it would be a totally unacceptable change to allow coins to be transferred to a party/script that was not signed by the originator.  i.e. AddrA signed a tx to go to AddrB, but instead the network allows it to be awarded to AddrC.   I don't see how there's even a hint of feasibility in this idea, unless I'm misunderstanding the proposal...

There's also some legit reasons a tx might end up appearing to be a double spend, even though it's not.  Programmatically, it would be impossible to distinguish those cases, and miners would have free reign to eat up any such transactions anyway.

I am swayed.  Otherwise we're trying to swim upstream.  I just didn't like the idea that anyone can replace their not-in-the-blockchain-yet tx (final or not) just by submitting one with a bigger fee.  It seems to make the zero-conf tx even more useless than before.  On the other hand, maybe it's a good idea to do that and cement zero-conf tx as totally useless outside of the pure-trust tx (at least before, the person has to inject a replacement into the blockchain, not just broadcast it). 

Good point about the multi-input seq numbers.  I forgot they are per-TxIn, not per-Tx (like nLockTime).

Gavin and I debated your last point the other day, because we were determining if it was possible to have a "Seller automatically gets payment after 31 days" in escrow transactions, in case the buyer is too lazy to sign the escrowed Bitcoins to the seller.   What we determined is that if the locktime is in the future and any one sequence number is non-maxxed, then the tx will be accepted to the memory pool but not included in a block.

What this gives is you a very inconvenient implementation of what you have already proposed.  It is replaceable but only if you get a miner to agree to drop the locked tx in their memory pool and accept your final replacement tx.  If they have enough mining power and there is enough time, your tx will eventually make it into a block and invalidate the locked tx in all nodes' memory pools.

The issue, of course, is that it's not really feasible to have regular users contacting miners to help them replace tx like this (in the event that the seller broadcasts the 31-day tx right away, hoping the buyer can't figure out how to replace it).  Also, I didn't like the idea that anyone would be able to bribe a miner to replace their 0-confirmation tx.  But that's a whole 'nother story...

Red Emerald,

I had some reservations about enabling this.  While it's possible under the hood, there's risk of users adding watching-only addresses to the wallet, in a variety of ways.  The most important is that someone sneaks their own address into your wallet then sends you money to it making you believe that it's yours.  This is normally prevented due to requiring an encryption password to inject keys into your regular full wallets.

Also, mixing regular wallets with foreign keys can create lots of confusion the same way:  users add addresses on their own for a variety of reason, and then forget or don't realize what they're doing, and trick themselves into believing they have more money than they do.  it can be a mess, later, to figure out what keys are "legit" and which aren't (without comparing the WO wallet with the full wallet addr list).

This way, the only way to add an address to a wallet is by the person that has the private key for that address.  It's quite inconvenient (as you determined), but adds a certain robustness for users that are less knowledgeable.

I'll spend some time thinking about how to enable this responsibly.  Perhaps only in Dev mode...?   (though it doesn't solve the problem of someone sneaking a key into your wallet)

For that, you just set sequence numbers to 0xfffffffe.  The maximum value is 0xffffffff, which means that there's only room for one replacement before the tx becomes actually-final.

EDIT: The point was, that you could make a or node-acceptance rule that only allows replacement on seq=0xfffffffe instead of any value

A straight proof-of-work system would actually be usable if Mike Hearn hadn't pointed out that spammers frequently are not limited by resources.      It would be very easy to make a email plugin that calculates a PoW for all outgoing mail and verifies it on all incoming mail.  And, it would only unblock incoming mail instead of rejecting stuff that didn't use it.  It could sit mostly-usused until it is widespread enough that people could start scaling down their regular spam filters knowing that all their legit mail will have a PoW.

The other advantage of PoW is that it doesn't require money.  My concern with a micropayment scheme is the ease with which people will figure out how to empty your email wallet and thus not let you send mail, or the complication of typing in your password in just to send an email, because you want to avoid the previous inconvenience.

I'm personally starting to believe that this is theoretically a great idea, but fails in practice.  In many ways...

Many years ago I was a proponent of the pay-for-email scheme, and thought it was a brilliant idea.  I never thought of it again since Bitcoin became real, so I was excited to see cbeast's recommendation.  But I do agree:

(1) That's a lot of transaction volume on the network.  I think Bitcoin clients needs to have better blockchain management/pruning schemes before anything like this could ever be attempted.  Or find a way to aggregate the payments (like the hashcoin solution involving locktimes and replacement, so that you can make thousands of micropayments off network, as long as both parties have a persistent financial relationship...)

(2) DeathAndTaxes is absolutely right.  The Bitcoins are kind of an roundabout way to solve the problem:  might as well just use proof-of-work directly.  I like the idea of requiring emails (with sender, recipient and date) to require a nonce that gives the hash of the email X leading zero bytes.  In Bitcoin, X=4 is the same as difficulty-1 calculation.  Even if it was just X=2 or 3, most computers and devices can do that computation very quickly.    

Either way, users would need to make sure that their ISP or email server supports this.  I could see many midstream providers implementing this, then selling out to allow a single proof-of-work to distribute multiple emails for some BS reason that doesn't make sense to anyone but the spammers.

Actually, I can think of one legitimate reason:  if you write a lot of emails on your smartphone, having any proof of work acceptable for desktop computers would probably take a few seconds and quite a bit of battery life.  So perhaps, the data service provider skips the check or performs proof of work for you for a fee?  But then that would quickly turn into a game of making exceptions to the PoW rules that spammers will learn to exploit.

I don't know, but there's a lot of possibilities here.  Whether you're paying in computation time or money, it's very easy to find a threshold that is basically transparent to the majority of legitimate users sending <20 emails a day, but is prohibitive to the spammers sending millions.

EDIT:  Hell, we don't even need Bitcoin or anything else to sign onto the idea of using proof of work.  Your email client could do it all for you (since verifying PoW is super-fast, and a scrypt-like CPU "hasher" is easy to implement in arbitrary software).  Once a certain level of adoption is reached, you could just turn off your ISP spam filter entirely and your email client filters out everything that doesn't have PoW.

Foxpup, thanks for the feedback.

Certain things like color schemes and layouts, and certain robustness features, were overlooked in the first [major] release of Armory, I didn't even know if I'd ever finish the damned thing -- so I didn't spend much time polishing things.  This is definitely something that will be addressed after beta...

Not to mention that the color scheme stuff is not actually that hard.  I don't think I have a need to deviate much from the user's palette, which is available pretty easily within PyQt.  I just have to study up on what all the palette colors are and try to match (and probably slightly modify per your suggestion) to my application design. 

Similarly, the two-Armories-open-at-once thing can be fixed, but it's something I didn't even think about until now.  It is definitely high priority... it's actually already done in my dev code, and it will make it into the next minor release.

I'll see what I can do about changing the behavior for offline mode:  for now you can test it yourself:  https://github.com/etotheipi/BitcoinArmory/blob/master/ArmoryQt.py#L535 .  Look for "timeout" and change it to 5 or 10, or whatever seems appropriate. 

As for Bob's deposit adding a step:  I guess Bob-zero-deposit could remove a step if Bob posts his public key as part of his advertisement.  But Alice has to send Bob a message and receive confirmation from Bob that he's still selling the item, anyway.  Even if she expects 0 deposit from Bob, she doesn't want to dump her money into a 2-of-2 or 2-of-3 until she's sure that Bob hasn't already sold the item.

But arguably, if this all has to get dumped into a bunch of opaque binary transfers between clients.  At that point, I guess it doesn't really matter.  3 vs 4 is immaterial (right?). Unfortunately, networking is not my forte.  There's a reason I rewrote everything in Armory except for the networking (and of course, because it's big and scary).  I will have to defer the creation of the protocol to others, and then follow the implementation in Armory.  (like verifying a mathematical proof instead of proving it myself)

So, I think we're in agreement that the clients will have to communicate in some fashion.  How difficult will it be to setup the communication?  Will it require extra steps, such as one person sending the other their IP address?  Or an IRC name?    Then it sounds like the method we define in this thread will not be so sensitive to the number of "hops" unless each hop requires confirmation from the user.  But I think the client can be made to have the user click once what their preferences are, and then the client apply all operations in sequence as long as each step completes/verifies successfully.  If Bob doesn't sign the DISPUTE/MAD tx, the client will not broadcast the multi-sig, etc.    However, that comes with the risk that the client handshakes and processing sequence have a vuln in them...

So there's still questions about whether deposits are necessary (sound like yes, but may be 0% in some cases) and whether there is a LAZY_ALICE tx (sounds like yes, but need to have a dumb-user-capable way for Alice to MAD the money after Bob prematurely broadcasts it).

I knew this was going to bite me some day.  My PyQt book spends a lot of time setting colors based on the user's palette, but it's a lot of extra work!  

Once I get Beta out, I'll switch to development on a 1280x768 screen with a dark user-theme.  That will force me to fix colors and layout.


Per cypherdoc's suggestion (via PM) I will merge these both into a single backup interface and have a single print option, so that you can print both root/chain data, and imported keys.  It definitely makes sense to put it in one place, and reduce user confusion about what they are actually accomplishing.

Ugh, so much to do!


P.S. -   amincd:  I don't even have a twitter account!  I like the btctip idea, but I'm just not one of those people.  Please use the donation address in my sig.  Thanks!

Any file that is constantly modified by two processes at once is at risk of being corrupted in unpredictable ways.   I'm not sure there's anything special about my code that does it.  It's more the fact that I never put in any extra code/locks to protect against this situation.

I'm looking into file locks right now to see if I can prevent Armory from opening twice.  Looks like it needs some OS-specific code....

Is it?   The fancy anti-corruption features were intended to guarantee against corruption due to process crashes or power outtages.  No matter what nano-second your computer loses power, your wallet will either not be corrupted, or will be automatically restored from a non-corrupt backup.  And it's been pretty thoroughly tested.  The thought never entered my mind that someone would have two instances of it open! (maybe I should've...)

Please please please do not open Armory twice!  All my super-fancy corruption-resistant, auto-error-correcting wallet files were *not* designed to be accessed simultaneously by two processes.  It's on my list for BETA, to make the application a "singleton" which means that it will detect other instances of Armory being open when you try to start it and refuse, if necessary.

And along with all the 0.70+offline bugs I have mentioned, I have fixed the -0.00000001 balances in offline mode.  It should now display nothing when in offline mode.

Layouts on small screens... I'll devote some time to that after getting address books implemented.

ACK!  Heads up, I totally flaked on my quality control, and didn't do testing with the new RAM-Reduction + Offline mode.  Strictly speaking, you can execute offline transactions with 0.70, but any other wallet management is a disaster!!!   Like really bad!

I apologize to cypherdoc, who has been complaining endlessly of things not working in offline mode, and I just assumed he didn't know what he was doing!    Sorry Cypher!

If you want to setup an offline system, us 0.60 or 0.61.  I'll be making a new release soon, though, fixing this along with (hopefully) bulk-address-import, and address books!  

You're right -- these days, sellers have incentive not to do shady stuff because they have a reputation, and likely have some degree of legal accountability because someone (usually the third-party) knows their identity.  Most of that is because sending money over the internet has always required a third-party.  It just so happens that in this case the third-party can arbitrate.

But Bitcoin is different -- the third party to hold the money is no longer necessary (or rather, it's the Bitcoin network).  So if you can find a way to eliminate the chance of needing arbitration, then why bother paying a third-party at all?  That is the Bitcoin way.  Of course, you won't eliminate it entirely, but I bet there's a way to reduce it enough for the MAD option to be like real MAD:  no one really ever uses it, but the threat that a party could use it is enough to keep people playing fairly.  

I think some combination of things Gavin and I are discussing add a lot of value for knowledgeable users, even if it's awkward and different.  For users that can't grok it, they can always just do it through the third-party, as usual.  

---

Gavin,

I just realized one complication -- the 2-of-2 tx (or 2-of-3) has to be created and fully signed before any of the spending tx can be created -- because they need the tx-hash for the 2-of-2 txout, which won't be available until all signatures are collected. That means I see a minimum of 4 "hops" for tx data:

(1) Alice contacts Bob saying "I'll buy this, here's some public keys"
(2) Bob creates the 2-of-2 tx (with SIGHASH_ANYONECANPAY), signs it and sends to Alice  (Bob can't create any spending tx until he gets Alice's sig)
(3) Alice signs the 2-of-2 and doesn't broadcast -- Creates and signs REFUND && LAZY_ALICE, sends to Bob
(4) Bob stashes REFUND and LAZY_ALICE, creates and signs DISPUTE/MAD and SUCCESS, sends to Alice

That's a lot of hops.  The nice thing is, Alice (who has the most money at stake) can hold onto the 2-of-2 and not broadcast it until she gets DISPUTE and SUCCESS signed from Bob.  That gives her a way to avoid locking her money until she at least has the power to MAD the money.

Sounds like there has to either be a third-party server to post data for each other to exchange, or direct-connect.  I don't like either idea.  It's a shame we finally have a way to send money conveniently, but no easy way to exchange all the data for this.  All solutions so far seem to be 80% solutions...

That's why Gavin suggests that DISPUTE is actually a send-100%-to-tx-fee.  Then no one gets the money, but it does get recycled.   And that's why I recommended deposits, so that both parties have a mutual incentive not to do shady stuff.  If it costs them money to be a dick, there will be a lot less dickery.


The part that you're missing is that the Bitcoin network is offering a dramatic improvement over something that happens all the time -- people trust completely random strangers over the internet, endlessly.   And for those people, one party has to assume all the risk: Alice sends money first, or Bob sends merchandise first.  

But now the Bitcoin network can act as very dumb-but-strict escrow and split some of the risk between the two parties that choose to trust each other anyway.  Perhaps because they wish to preserve their own privacy, or simply don't feel like registering with a third-party.   I agree that for "full 100% guarantee" you need a third-party. But that doesn't mean that there is 0% value in using the scripting capabilities of the network to improve the non-third-party case.

---

Gavin,

I still think a risk deposit is necessary here.  Even if DISPUTE goes to the miners, Alice may just be bitter that her new merchandise is crappy quality and issue DISPUTE to spite Bob.  She doesn't get any money back either way, so what does it matter to her whether Bob gets it or the miners get it?

By the way, another problem with it:  if Alice has a lot of mining power, it's very +EV for her to pull the DISPUTE trigger, since she's would get something back instead of nothing.

I'm less concerned about miners not agreeing to it, than the complexity of making sure the arbitrary user has access to a miner that will do it for them.  Maybe it could just be a rule that most miners will adopt, but something doesn't sit right with me about most miners accepting conflicting zero-conf tx just by including a bigger fee.  Maybe zero-conf tx have very little value right now, but they'll have even less once anyone can start canceling their outgoing [zero-conf] tx on a whim...



The asymmetry is that Alice is the only one with anything at risk.  Maybe Bob is just bored and wants to laugh about people losing money, so he starts advertising stuff he doesn't actually have.  When the person commits money, he delays a bit, then broadcasts LAZY_ALICE.  Worst case (for Bob), he doesn't get anything and gets his laugh.  Best-case, Alice can't figure out how to DISPUTE, and Bob actually gets some money!  Sweet game! 

I mean, people could do this now, though it would catch up to them eventually.  With Bitcoin, it's a lot easier to hide your identity, so there's almost no risk for Bob to do this. 

And so I'm coming around to your point about complexity and awkwardness of something like a Bob-deposit.  I agree, the further we deviate from what people are already used to, the stranger and more-confusing it will be.  At the very least, if we were to do something like risk-deposits, bitcoin.org could have an education section so users have some trusted place to go when they say "wait? I have to put in money as the seller?  sounds like a scam!"



Yeah... I don't think anything is going to be easy about it, besides minimize the number of exchanges between parties.  Right now, I want to get anything that works, and let the knowledgeable users get their hands on it, play with it, break it, and figure out how it can be improved.   As you said, it'll be easier to know what people like when we see if they use it.

I'm sorry guys:  it is not acceptable to have to share my personal information and transaction details with the entire Bitcoin network, or any subset thereof, just to have my transactions arbitrated.  If I'm going to pay anyway, I expect a privacy agreement and someone who will exercise due diligence in arbitration -- which may involve contacting both parties and collecting documentation.  I just don't think a random-user voting scheme is part of this solution.

There may be a place for it, but it's not a general solution to the problem we face here.