Just for reference, I just received a bug report from a user having problems sending a transaction with Armory.  He sent me the *.unsigned.tx which is what would need to be sent over the link:  3.5 MB! 

Yes, the transaction has 483 inputs, and by itself is 120 kB.  But since Armory uses BIP 10, the *.unsigned.tx file includes all the 483 transactions that supply the inputs.  This turns out to be a lot of data...

Granted, it's possible to get it to about half the 3.5 MB, since BIP 10 is an ASCII format and all the transactions are encoded as simple hex.  Could switch to binary.  But that's still 1.7 MB to transfer. 

However, even if it did go smoothly (I'm actually not sure why it failed... it should work), it would probably have a tough time getting into a block, since Armory's linear tx fee rules probably won't work...

So I guess the question is whether this is a truly relevant transaction, period.  Both for offline wallets and online.  I'm thinking that any transaction that is over 10 kB be "rejected", by suggesting the user break it into multiple transactions.  It's not the most elegant solution, but this is extremely rare... I think...

Or is it?  A business processes 500 tx per day.  Even if they sweep the coins every day... this is still a problem.  I really wish Satoshi had put the input values into the transaction (and be part of the string that is signed), so that I could avoid including all the supporting transactions.  But he didn't, so the only way to make this airtight is to include all that extra data.  As such, maybe it's not so ridiculous that the data link would have to handle a few MB...

On the other hand, maybe it's not so ridiculous to make the user wait 2 minutes.  I could be worse... ( like waiting 5 minutes just to load the program )

Okay, fun research on LLC's.  They are pretty easy to create and maintain -- initial filing, and one annual filing per year.  And it must have its own bank account, which is used to collect rent and pay expenses, and transfer profits to you.  The account doesn't need to be used for 100% of business operations, but it does need to be used 0% for personal finances.  Any money that you want to use for personal finances can simply be "paid to you" by the LLC.   I'm pretty sure that's just a fancy way to say "write yourself a check from your business bank account".  

$100 filing in MD to start, but $300 annual filing fee after that.  It's not a deal-breaker, but it is doubling my insurance costs.  But I assume it's at least tax-deductible...?  

Having done some research on this now, I stumbled across one article that was rather blunt about how to really minimize your liability exposure.  This is some serious LLC magic:


I'm sure it's not quite that simple, but I'm sure it's not too far out, either.  This kind of reminds me of sandboxing security-sensitive software -- your goal is to completely isolate it, so that no matter what goes wrong, nothing can escape the sandbox.  In this case, you can try to continuously transfer all the value of the LLC out of the sandbox... to you.

This is a bit extreme, but it's educational.  Given just how unlikely it is for this kind of thing to crop up and overrun my insurance, I don't think I need to play these games.  But if it turns out to be easy, why not?  

As long as there is only one owner, you can "pass-thru" the finances to your personal tax filings.  If there are multiple owners (such as husband and wife), you'll have to file it as a separate entity.  Apparently, you can avoid this by having one person be the sole proprietor and give the other the "right to survivorship" in the event of death of the first owner.  

Corporations sound complicated and scary.  I always assumed they come with endless paperwork and generally require lawyers or endless research to deal with it.  It sounds like I will have to do some research on LLCs to see what it takes, and I'll be pleasantly surprised about how easy it is.  I wonder if it also allows me to take certain deductions I otherwise wouldn't be able to (such as passive income losses, which can't offset ordinary income if you make more than $150k/yr, unless you are a real-estate professional -- this is not modeled in the spreadsheet, btw, because the purchase/rent ratio is so favorable, I rarely have to worry about annual cash losses; equity losses are handled entirely separately).  i.e. now that it is owned by a corp, I wonder if all losses become deductible, etc.  Perhaps, if Romney becomes CEO of the US, he will make conditions more favorable for us small businesses... though I suspect most tax changes would be geared towards benefitting the already-successful multi-multi-millionaire crowd...



Thanks.  And part of the reason this is attractive is because it seems like it should be very little work on average for 8% return (under reasonable circumstances).  If it looks like it's going to be much higher than that, then we just pay for a mgmt company to deal with it.  Free time (for things like Armory) has always been high on my priority list.



Excellent advice jgarzik.  I will have to keep in mind the social aspect of this.  Being the nerd that I am, social confrontation is not my favorite activity, but I think I can handle it.  I will be sure, if I carry through with this idea, I will get a unit in one of the buildings on the other side of the association   Still walking distance, but don't have to run into the tenant on a daily basis.

One of the primary motivations behind this was that the property would be next door.  This dramatically cuts down on "unknowns", since I've already lived in the same HOA for 2+ years.  I know all the fees, what the construction is like, what problems are consistent across many units, how much it costs to replace appliances, etc.   I recognize there is potential headache associated with property management, but I'm minimizing the amount of headache by being right there and knowing so much about it already. 

Also, I know some other people who flip/rent properties, and have good contractors they use for these things.  I really can't imagine needing to pay 8% for professional management of this single property.  Plus, I'm part time at my real job, which gives me lots of flexibility to deal with issues.  The other benefit is that I am near a lot of really high-quality work places -- it's not unlikely I can find someone at my work (5,000+ employees) to rent, which gives me a good chance of smooth sailing...

But once I got 2-3 or three properties, I think it makes sense for management. 

Also, I do recognize the whole liability thing, and obviously I want to avoid it.  I just wonder if there's not going to be a bigger headache dealing with intra-state corporate laws and incorporation, to avoid something that is about as likely as winning the lottery.  Yes, super-nasty things have happened to landlords.  But I can spend my whole life worrying about that, and then get killed by a drunk driver tomorrow.  But maybe I'm underestimating the likelihood of something like that happening...

Part of the appeal for us was that I thought this could be done, not only in the same complex as we're already in, but without hiring lawyers, accountants, or doing endless paperwork for incorporating and complicating the hell out of my taxes.  The more stuff we throw on top, the less interested we are in pursuing this.  But, maybe it's fantasy to believe that we can pull this off (safely!) without all that mess.

This HOA is very good.  They charge a little bit more than neighboring associations, but they maintain very good reserves, and still have plenty leftover for other stuff (such as replacing the pool!).  It was one of my criteria when purchasing, and so far I haven't been disappointed.

The liability is a valid concern.  And while I recognize that "crazy shit can happen," I question how bad it can get.  The tenant has to prove that I was aware of the problem, a record of notifications/requests made to me, and that I was negligent in repairing it.  My understanding is that if you make every reasonable effort to address it, it's no contest.  Even if such shit happens, most of these landlord insurance policies cover quite a bit.    It's dirt cheap (relative to everything else) to increase a "standard" landlord policy to $500k coverage of such events.  Sounds like it's worth it!

kjj,

Thanks!  This is all very good advice!  Please continue this in the Off-topic thread I started.  I would like to continue this discussion, but it's way off-topic for this thread!

Diving back into Armory tomorrow!

I originally posted this in the Armory thread, because I was explaining why I neglected Armory for a week.  But the subsequent discussion is very off-topic for that thread, so I'll continue it here.  The link to spreadsheet is in my first post, but here it is again:

Spreadsheet for analyzing rental property investments.

The numbers that are pre-filled in are extremely representative of the 1100 sqft condo currently on the market that inspired this discussion.  kjj's first response was very much tailored for a single-family home.  I think it was excellent advice in general (which this thread can be about), but not so applicable to my potential situation.  Read on below and contribute your advice!  Especially, if you have any actual experience with rental properties and the taxes.

---

Original posting:

---

---

---

Thanks for the feedback!  The particular properties we're looking at are condos.  The by-laws of the condos are standard, which means that a $5k HVAC replacement is about as extreme as the repairs get, and that's probably once every 10 years (at most).  Anything more expensive than that is going to be covered either by HOA or insurance (i.e. every example you mentioned in your previous post).  If you add up all the appliances in a 1100 sq ft condo, it doesn't even add up to $10k.  So I think it's actually crazy to suggest I'd spend $17k over 10 years.  If I did, that would be a 99.5th percentile kind of thing.

The 95% occupancy accounts for time between tenants.  That is definitely not a down payment thing:  you might pay a little bit upfront while first finding a tenant, but once you have an income stream, the vacancy periods are covered by your profits to that point.  I don't need to contribute more money from my personal bank account to cover those, unless I was really irresponsible with the cash stream (which is the opposite of my financial personality)/  Though, perhaps I should add a little bit to the "cash to close" to cover the initial tenant search -- though even that may be minimal since I might find someone while waiting to close.

Also, this property would be in the same condo association as we already live in.  There's no necessity to pay a management company for one property that is across the parking lot.  If we start accumulating lots of rental properties, it might become worth it.    So, I totally agree with your assessment if this was a single-family home, but the variance on a condo is dramatically lower than on a regular house.  The HOA fees are a form of insurance.  Also, in this particular HOA, there has not been a special assessment ever in the 25 years since it was built.

However, I do like your advice about incorporating.  Again, it might be kind of overkill for a single unit, especially when it looks so cash-positive, but if we start really getting into it, it sounds like there's lots of options for "optimizing" our tax burden  Very interesting!    And thanks for the feedback.  I'll investigate Nevada tax code!

I don't have a tutorial for what buttons to click, but I do have a conceptual tutorial on the website about Using Offline Wallets in Armory.  

If you want to know what buttons to click, just double click on the wallet you have created already and go to "Make paper backup on the right side".  To recover the wallet, you click on "Import Wallet" or "Restore Wallet" from the main window.  One of the options will be "Restore from Paper Backup."  Then you can enter everything on the paper backup to recover it.

The website linked above also has a section called "I'm Scared" which gives you a little guidance to make yourself more comfortable with the whole process.  

Fees are an inevitable part of the Bitcoin network (especially in the far future when block reward is significantly lower), but it's important to recognize who is getting these fees:  anyone who wants to.  This is an extremely important distinction!

In most other systems, it's usually the central authority that is charging the fees (Mastercard, Paypal, Blizzard charging 15% fee for DiabloIII item auctions!?).  Because there is usually a lack of competition or a very steep cost-of-entry, they essentially have a monopoly and can charge whatever they want.  That's why consumers are losers  in all those services.

However, in bitcoin there is no way to have a monopoly on fees.  In fact, there is infinite room for competition in the bitcoin mining market.  I can go buy $10k worth of FPGAs tomorrow and hook it up to the network and start collecting fees right away.  I can do it completely anonymously and without getting anyone's permission to do it.  There is inherently no restriction on who can be part of the bitcoin equation.  Every single person in the world can be part of it.   That's a really powerful feature!

The "infinite room for competition" part is the critical piece of this puzzle:  there is no way for any party to try to lock out competition from the market.  The only way to influence the network fees is to offer lower fees than everyone else.  Anyone who wants to try to charge higher fees, will just be missing out on profitable, lower-fee transactions that are processed by all the other miners that are willing to include them.

Because of this dynamic, it is overwhelmingly likely that fees will never be higher than they need to be.  They will always be low as they can reasonably be, at least until/if super-computers + T1 lines are needed to do mining -- but even then, there's still plenty of investors who can participate.  Therefore, if there are fees, it's because the network has a non-zero cost to keep in operation.  But you can be assured that you're not getting overcharged.

Mostly-random posting (updating you on what I have been doing instead of Armory developement):

I have been neglecting Armory completely the last few days, because I got nerd-sniped trying to figure out the investment quality of buying rental property.  This came up because my new fiance and I started counting up each others' financials and realized that a dual-income will leave some headroom for investing.  And we noticed some nearby properties that are going for super-cheap which we could rent out for much higher than the mortgage payments. 

So I spent the last few days diligently digging into IRS publications, and making spreadsheets to try to model the relative investment potential of the rental property, taking into account every relevant tax code.  Partially for curiosity, partially for education, but ultimately because it's feasible we could do this in a couple years.  What I found surprised me.  And I have included everything on this spreadsheet, which I am posting because others might find it useful, and the time spent making it would otherwise have been spent on Armory development, which is what you were probably expecting

I won't go into extraordinary detail about it here (off-topic!), but this spreadsheet assumes that the initial closing costs on the loan are your "investment", and compares your movement in net worth to a fixed-rate-of-return asset.  What's your overall equity&cash gain through an entire cycle of purchase, rent it out, pay taxes, sell it, and then pay more taxes?  For this particular property, it looks like approximately 11% annualized return for 10 years.  That's hardcore! 

It appears that house prices have dropped dramatically, but rent prices have not.  Perhaps this happened because the shitty economy has made it very difficult for people to do anything about the market inefficiency.  I'm sure many people see the opportunity but can't act on it because they can't get the credit, and/or don't have capital for down payment and closing costs

None of this constitutes financial or tax advice.  I just thought it might be educational, and I'm sure there's a lot of investor types reading this.  Perhaps you have some experience with this and will PM me your thoughts about it!

Holy hell:  167 inputs!?!  To be honest, I would expect Armory to work anyway, but I also am not surprised that it didn't since this is a corner condition I haven't been able to test.  Do you mind sending me the log file and/or a copy of the raw transaction that has the bad signature?  If that's too much of a privacy concern for you, maybe I can find another way to debug it...

And wow for the 0.0435 transaction fee!  That transaction is probably 30 kB ...?!

This is the trade-off with keeping... a lot of stuff... in RAM.  I will be moving to a disk-based index, but that will trade Armory's RAM footprint for its disk footprint.  A lot of users have expressed that they like the fact that Armory doesn't duplicate blockchain data, and uses only about 30 MB on disk (making it very portable).

After beta, I will be switching to disk-based, which will duplicate blockchain data, but will tone down the RAM usage quite a bit.  But as said above, this will change the mechanics of Armory, and I didn't want t do that until after beta (and it might be a lot of work... but it will be leveldb which has been quite pleasant so far in my testing)

The problem is that encryption doesn't protect you from a Bad Person that obtains access to your system.  Your wallet may be encrypted, but it has to be decrypted for a moment in order to sign transactions.  That means that, at some point (unless you never spend any coins, only receive them), your private keys will be sitting unencrypted in RAM.  If someone has root access to your system, they can write a program to copy the program's memory space as soon as it detects you've unlocked it.

It's not easy for an attacker to do.  Not every attacker gets root/admin access.  But there's also a lot of nasty viruses/malware out there, and people get infected all the time.  And part of the reason it's so difficult to secure computers against them is because they're constantly changing and developing new ones.  In fact, the threat vectors are the ones you don't know about yet (because the ones we do know about have generally been patched already).

If you really want to do the online computer thing, I recommend it be done on a system or OS that has good A/V and is not used for web-surfing.  It should have a minimal amount of software installed, and minimal interaction with the internet.   It's sole purpose should be for your Bitcoin software.   And in fact, that's very much like what you're asking for...

I just wanted to point out that for most users, hearing the phrase "Securing your savings wallet" is synonymous with "I want to keep a couple hundred dollars worth of BTC online, but I want to store my $30k in savings in the most secure way possible."  For most people, $30k is not something you compromise with, you just get the best thing out there, even if it's a little inconvenient.  I'd like to believe that Armory is not only "the best thing out there", but also rather convenient once you get past the load times

Unfortunately, it's very difficult to quantify what the security difference is, because most of it is based on what we don't know -- Bad People are finding new ways to attack systems, all the time ...

hazek,

I don't think that anything you said is outrageous or unreasonable, with minor exception.  My point was more that there is a gap between the supply and the demand on the end-user-software spectrum.

The caveat is that any system that is online has an order of magnitude more attack surface than one that isn't.  I'm not saying that there's no security to an online system, I'm saying that this thread is about "securing your savings wallet" which many users don't consider secure unless there's a physical/manual gap between the internet and your keys.   I misread your statements, thinking that you were like other users who wanted the cold-storage, but also wanted all the other features that haven't been combined into any existing cold storage solution, yet.  Since that's not the case, your options are significantly wider.  I was simply trying to bridge your understanding between "reasonable" and "reasonable-but-doesn't-exist-yet-you-might-need-to-find-a-compromise."  

If you are interested in simply a more-secure online solution, then that's a discussion worth having.  And it probably won't include Armory (eventually it will have a lite mode, though).

Here's some questions about your requirements:

(1) Do you want to be able to use unique addresses for each deposit into the wallet?
(2) Will the addresses be distributed to other users for receiving payments, or only used for your own deposits?
(3) Does it matter how often you have to backup?   
(4) Does it matter how easy/convenient it is to move the coins once it's in savings?
(5) Does it matter how easy/convenient it is to monitor coins in your savings?
(6) Are you afraid of running scripts, or must you have a GUI?

If the Bitcoin community was bigger, and the developer community was bigger, there might be enough competition in the client market that you can ask for whatever you want and someone will have made it already.  But at the moment, it sounds like you are asking for cold-storage, but chose requirements that are in conflict with existing cold storage solutions.  I think you are going to have to pick a partial solution, and tweak your own CONOPs (concept of operations) to better achieve your goals using these partial solutions.

You have made one of your requirements not to have the blockchain, at all.  That's a fine requirement, as long as you're willing to give up some security (being a lite node dependent on full nodes you don't own comes with risks), and willing to limit your options to clients that don't require the blockchain.  That leaves... very little.   I guess electrum with offline wallets using the command line.  Or a variety of hack-it-together-yourself solutions which are fragile and very inconvenient (and error prone). 

However, if you remove your no-blockchain requirement, suddenly you have Armory, which was designed specifically for the reasons you are requesting.  You can have your top-notch encrypted in offline storage, with the ability to watch your funds without having private keys online, requires only a single backup the first time you create the wallet, produces an infinite number of unlinkable addresses to use for yourself or distribute to others, and gives you a way to actually move the funds out of cold storage without having to execute 37 command line calls (it takes 60 seconds once you understand the process).  And all packaged in a nice GUI with built-in instructions, and 6+ months of testing with end-users.

However, if you're going to make no-blockchain your unbreakable requirement, you're going to give up a lot of other features that may be useful to you.  You can require A, and as a consequence give up B,D,E,F,and J.  Or you can acknowledge that giving up A might be worth getting B,D,E,F and J (whatever those may be). 

I'm not trying to be annoying or degrading.  My only point is that I made Armory with offline wallets for exactly the reasons you are requesting, but your inflexibility to waver on the no-blockchain requirement might be blinding you to what is otherwise a fantastic solution.  If you are going to stick to it, you might consider electrum + command-line.  That's the only structured solution I know that does offline wallets without the blockchain.  If you don't want blockchain or deal with the command-line, then you're going to have to go with an internet-connected solution that is kind of contrary to the original goal.  If you insist on no-blockchain + no command-line + no internet, then I think you're out of luck  (maybe the electrum devs will work on making an offline wallet GUI).

This is not feasible.  99% of users have encrypted wallets, which require unlocking to move any coins once they've been received. Many wallets are offline, and require a bit more work than typing a passphrase.

Second of all, this is not a feature for any baseline Bitcoin client.  This violates one of the core metrics of suitability for a currency: fungibility.  If I have 10 BTC, it will buy me 20 cheeseburgers, regardless of the transaction history of those 10 BTC.  No coins are worth more or less, any more so than $100 bill from my wallet is different than a $100 bill from a bank vault.

In the end, there's no benefit anyway.  If someone steals 1000 BTC they're not going to spend them directly.  They will mix them through 100 addresses with "non-tainted" coins, and 99% of users don't care anyway, so they will accept them as payment and mix them with more good coins from legitimate users.  The end result is that your client no longer believes that any coins in circulation are legitimate, and the only person you've inconvenienced is yourself.

If you would like to explore this idea, modifications could be made to notify you that somehow there's a relevant history to the coins you just received.  I'm sure someone could help you modify Armory to explore this, but I'm up to my eyeballs in core feature development, and making Armory usable at all.  This particular feature would be very low on the priority list.

Okay, threading branch is starting to look a lot better.  I've only played with it on testnet, but so far most things work.  Maybe now is a decent time for those who are anxious to play with it.  That would apply only to Linux users who are compiling it themselves.  I haven't touched this version with Windows yet...

There's some details I'm working out with restoring wallets -- because it may require many scans to figure out how many addresses you've created in your wallet and doing that asynchronously is a bit more complicated than I expected.  I might just have to add a button to increase the key pool, or set the default keypool size to super big (but this wallet format is kinda slow).

Either way, the restore does work if you let it scan right away.  And it looks like all importing and sweeping of keys works, and switched Armory modes correctly.  Some things probably don't work, so don't be surprised.  But you can help me figure out what those things are, while I deal with restoring wallets from paper backup   Be sure to copy log messages for me!

Hey, fantastic project!  

I just wanted to point out that while Armory is advancing (with new versions), even ancient versions of Armory will work as an offline signer.  It's because neither the wallet, nor the BIP 0010 format has changed in the last 6 months.  So even if you create the image with version 0.74, you can keep upgrading the online version (say 0.82) and it will still work.  This will be true for a while.

However, there will be a hiccup after beta, where I introduce a new wallet format, which will include support for P2SH and update BIP 0010 to better handle multi-sig.  Old wallets will be still be supported, but then this image will have to be updated and redistributed to support the newer version.

-  There is full re-org/double-spend handling, which has been tested at the library level.   But it hasn't been tested at the GUI/interface level, because I never set up a way to test block/tx injection over the networking interface.  I see re-orgs happen all the time -- you'll see output to the console that says "Invalidating old chain tx -- Marking new chain tx valid".  For web-servers, this should be all you need. 

- Armory is pretty dumb when it comes to... lots of network-stuff.  It was written with the assumption that Bitcoin-Qt is going to feed it trustworthy, reasonable data.  I have noticed, under strange testing conditions, if a conflicting tx happens to make it in, it will show up in the ledger but it actually won't affect your balance at all.  Again, this is not all that relevant for web-servers, but it's worth noting:  Armory receives the conflicting tx, and immediately detects it's relevant, and adds it to the ledger on the GUI.  Then Armory tries to add it to it's pool of tx for each address, etc, but finds those outputs have already been spent.  So it gets dropped, and the underlying UTXO list is untouched.  It rarely ever matters, because Bitcoin-Qt/bitcoind can't pass it conflicting tx...

So I need to fix the auto-display-in-ledger bug.  But balances and spendability should maintain correctness in this situation.  Please let me know if they appear not to.

As for storing data between loads:  some people complain about the load times, etc, but it comes with a tremendous benefit of robustness, because there's no way for Armory to ever be "out of sync" with the blockchain.  One issue with Bitcoin-Qt is that it can mark outputs as spent, or believe that some transaction succeeded that wasn't accepted and get stuck in a state that isn't consistent with the rest of the network.  Armory avoids all this by having no memory.  At the expense of load times.

This functionality will eventually have to be added to do this (especially with the blockchain size getting so big), but right now it's not there, and it will probably require a lot of testing.  If the server is going to process lots and lots of transactions separately, you might consider taking my examples above for creating transactions, and add that memory/tracking around it (maintain the tracking yourself).  Maybe that's too much work...  I don't know.

---

Btw, I haven't looked at your stuff yet, but this sounds fantastic!  Thanks so much for doing this, and the JSON-RPC interface is something I've wanted to do for a while.  Perhaps we'll find a way to merge functionality together...