Topic: Armory - Discussion Thread - page 123. (Read 521829 times)

It's on the medium-term plans.  In fact, the database that I'm implementing right now is intended to be flexible to accommodate any level of storage:  from total lite-node to the radix-tree stuff.  It won't all be implemented now, but I'm trying to leave room for it so that when I want to do that, I'll at least have a lot of the details worked out already, even if I missed something and have to rewrite parts of it later.

In the long run, I'd like to have a server version that uses a real database.  By that, I mean a hardcore database with all the ACID robustness in it, to be run by those that really want to run a server.  Right now, I'm constrained by the requirement that the database I choose must be easy to distribute, run in isolation, and have a license agreeable with distribution with Armory.  LevelDB is a great choice for the end-user version of the software.  But for the server version, I can have something more heavyweight.  And I don't have much experience with that, so I wouldn't mind offloading that somehow. but definitely can't even think about it for a few weeks until after the conference.

How difficult would it be to create a "lite mode" which only stores block headers, like Multibit does? I have also read your idea about the blockchain compression using radix tree structure, any chance for to implement it in the Armory? If you think we should get someone else to do it,  I can contribute part of the bounty.

UPDATE:

I just found out that some users report instability being fixed by using the 64-bit version.  It slipped my mind that it might be one of the problems being faced, but it makes sense given the high RAM usage. 

So I re-linked it on the download page.  If you were previously experiencing problems, please try the 64-bit version!


@Ente

There's a setting to disable auto-bitcoind.  Just disable it, and you can run Armory like you used to.

Yay, that's what helped! :-)
I almost got nightmares again when I saw that "python" and "python2" message.. One of the few things I hate about linux! So I never touched my python again :-)

It works, thank you!

Quick question, about the "Armory now manages bitcoind":
I prefer to keep bitcoind running whenever the computer is on, to always have an up-to-date blockchain and help the network with a full node. I don't use Armory daily, though. Thoughts, how I should proceed?

Ente

Gah, someone recommended that change to help with systems that may have python3 hardlinked to "python".  Apparently this has caused problems for a bunch of innocent bystanders.

Change the "python2" in the Makefile to just say "python".  That will resolve it.

It's failing because it can't find the "python2" executable.

It's available in the python-minimal in Ubuntu (it's just a soft link to python2.7).

As chrisrico says, are you following the build instructions? https://bitcoinarmory.com/building-armory-from-source/

If you haven't made any changes to the source, I would wipe the folder, clone the repository again, checkout testing, and try again. You shouldn't be getting errors like that while compiling.

Also, did you install all the dependencies listed here? What operating system are you running?

p.s. Etotheipi, you should clean up your github branches, it can be quite confusing determining which one to use.

Daymn!
Now that's good to know, thank you! :-)

edit:


*sigh*

Ente

The branch you actually want is "testing". It was last updated 5 days ago, compared to dev which was last updated 4 months ago.

Hmm, I am having some issues here.
I am sure it's on my side, with GIT and all..
Armory-gui tells me I am on 0.86.8



Anyway, so I stick to the dev branch, but there comes more:





Still says 0.86.8 then.

So, is the master branch newer than the dev branch?
Am I missing the "swig" stuff?

edit:

Doesn't help.

You can see I have no real clue what I am actually doing here ;-)

Ente

Gah.  Good point.  Especially because Armory 100% depends (right now), on Bitcoin-Qt/bitcoind forwarding your tx back to you, as verification that it was valid. 

However, there is still one extra thing I can do:  I've had a few reports of people sending valid tx, but Bitcoin-Qt/bitcoind had no peers/connections at the time, so it "broadcast" it, but no one heard the broadcast.  There's nothing Armory can do, because if it tries to rebroadcast it, Bitcoin-Qt recieves it and says "Oh, I've already seen this and relayed it.  Ignore."   Luckily, this is solved by restarting Bitcoin-Qt which clears its memory pool.  But it will be nice that I can use that RPC command to force it to rebroadcast every 30 minutes.

This seems like a bad idea. Armory will have no way of knowing if the transaction was accepted by the network or not. If you're not connected to any nodes with non-standard fee relay rules (is that even really a thing?), then your transaction silently fails.

Actually, I totally forgot that RPC now has a sendrawtransaction command that will let you do it.  It's actually been there for a while, but Armory never used to connect via RPC, only as a regular peer.  Now, there is an RPC connection if you use auto-bitcoind, and thus Armory could do this. 

It doesn't mean that the network will accept the tx.  But if it's not dust, there's a good chance that there's a lot of custom nodes that would accept it, even if your own node would have otherwise rejected it.

It's only a benefit if someone wants to push a valid transaction that the reference client will not forward by default.

What is the benefit of submitting it to blockchain.info over the local instance of bitcoin that you have to be connected to anyway?

Any reason not to add an expert mode option to send the raw transaction through blockchain.info?

https://blockchain.info/pushtx

Right now users can do this manually with a copy and paste operation, but I don't see any downside to making it automated by just having Armory connect to the blockchain.info API.

This is definitely a Bitcoin problem, not an Armory problem.  Armory is bound to the transaction fee "guidelines" built into the default Bitcoin-Qt/bitcoind apps.  I can let Armory try to send a zero-fee tx, but Bitcoin-Qt/bitcoind may not like it and the tx will be DOA -- it will never make it to the network, because it didn't have enough fee to even be relayed by Bitcoin-Qt/bitcoind.

And you're right, that it seems inconsistent.  It is, essentially, out of the control of the user.  It's one of the somewhat valid criticisms of Bitcoin, that fees are difficult to predict and update.  Armory simply follows the default fee rules that are specified by the current default installation, simply to make sure your transactions actually make it outside of localhost and onto the network.

It would almost be better if Armory just always required a fee, since consistency might be better than "randomness", but at least it does pick the minimum, so users get their free transactions if the network would allow it.




Splitting Armory into lite-nodes and super-nodes has been on my long-term plans.  I'm just not there yet.  However, all this time I've spent working on the DBs for the resource-usage-upgrade, has partly been careful planning by me, to make sure the new DB design is flexible enough to do both without making two different versions of Armory.

Dedicated Servers?

On my Laptop (Win 7/64, 8 GB RAM, fast 100 Mbit/sec Internet)
Armory needs 10-30 minutes to start, using much of my CPU-power, internet bandwidth and about 10 GB AppData of my HD.
Even after start and actually not used (but running in the background) I feel Armory is working hard.

If I see it correct now, Armory installs and uses its client machines as "servers".
I was not asked to allow that. And please do not tell me or other beginners they should have known that.
For people not having internet-flat-rates or other limits this might be an expensive problem...

So I ask equal questions as SimonL in another thread already did
https://bitcointalksearch.org/topic/m.1500568

Is it possible for Armory to query Electrum or other servers?

See no special technical or security risk for clients if they do not play servers themselves
(using bitcoin-qt / bitcoind, as Armory does).

Network and protocols are in all cases the same, arn't they?

In the long run with even more blocks and traffic it might be impossible to run the BTC-System without dedicated servers.

Transaction fee
Had a look at some blocks:
Blocks before 200 000 (or so) seem to contain no (or very seldom any) fees.

Newer Blocks like 234165 often or always contain MANY fees:
http://blockexplorer.com/block/00000000000000c0d730d29a3da3d71440d2d9325c2176bbb615f262e7182956
Just trying to understand the fee system I only checked just a few blocks, of course.


We read in:
https://en.bitcoin.it/wiki/Transaction_fee


"Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction."

Later in the same article we find this:

"Users may override the default 0.0005 BTC/kb fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee)."

In this case a transaction seems quite impossible.

Normal users are not able to control/understand inconsistent and dark informations/regularities.
So there is no previous agreement. So the enforced transaction fees might be illegal.

But as I hope to understand it now, this is a general problem of BTC, not Armory.

You cannot spam the network with larger amounts either.  You have to pay a fee if the sum times the time since it was last moved is less than 1 BTC * 1 day (or something close to that).  So bouncing 1 BTC back and forth will cost fees, too.

Yes, it would be nice if "test transactions" were free, but there is no way the network can distinguish between your test transaction and my twenty million spam transactions intended to destroy the network.  The only way to stop me is to force both of us to pay a fee.  That fee was insignificant until the bitcoin price blew up - and I guess at some point it will be reduced.