Is amory going to support download headers only?

[gweedo]

Blocks are becoming too consuming for me to run both a local bitcoind and armory to keep both databases. I know Allan teased that a SPV version of armory was a theory of where armory is going but I have yet to see anywork. Is there any headway? I am subscribed to the commits as an RSS from github and really haven't seen any work of this.

Ultimately I would like to run a local bitcoind and armory in SPV forcing it to connect only to my bitcoind this would give me the same network secure as armory currently.

[1715113506]

1715113506

[1715113506]

1715113506

[1715113506]

1715113506

[1715113506]

1715113506

[rocks]

Blocks are becoming too consuming for me to run both a local bitcoind and armory to keep both databases. I know Allan teased that a SPV version of armory was a theory of where armory is going but I have yet to see anywork. Is there any headway? I am subscribed to the commits as an RSS from github and really haven't seen any work of this.

Ultimately I would like to run a local bitcoind and armory in SPV forcing it to connect only to my bitcoind this would give me the same network secure as armory currently.

I'd like to bump this as I am very interested in this functionality as well. It would also simplify Armory quite a bit and enable development to focus more on features.

Ideally Armory should only need to run as an SPV client. Users could then select the privacy they require by either running a local instance of bitcoind for Armory to connect to, a remote instance of bitcoind, or have Armory connect directly to the P2P network.

Running a bitcoind locally is become less and less of an option as the network grows. Some of us are stuck behind slow ISPs (my upload is 256kbps...) and SPV wallets are going to become required for many users. In my situation, bitcoind slows down my home network connection to the point that I prefer running an instance in AWS and ideally should just be able to connect to that. Gavin is also close to raising the block limit to 20MB.

I remember there was some talk from the Armory development team indicating this direction, but have not heard or seen anything in a while. It would be helpful to understand the direction Armory expects to take, since that would help with wallet planning. Thanks

[etotheipi]

A testing release of the soon-0.93 has been released.  You will need this version to work with Core 0.10 or newer.

https://bitcointalk.org/index.php?topic=919202.0

[rocks]

A testing release of the soon-0.93 has been released.  You will need this version to work with Core 0.10 or newer.

https://bitcointalk.org/index.php?topic=919202.0

Thanks etotheipi, but this is not the funcationality gweedo or I asked about.

Armory 0.93 and Bitcoin 0.10 support headers-first, but do not support SPV headers-only functionality. Headers-first still requires a full node that syncs with the entire chain, SPV allows for thin clients without storing any blocks.

SPV functionality is needed because many home ISP connections will not support running a full node with 20MB blocks or more. My home connection already has issues with bitcoind and I can not leave a full node running all the time (I have ~100kpbs up).

In this situation, if Armory does not support SPV then I might need to switch wallets, which I don't want to. One option is to run a full node in AWS and connect my home bitcoind only to that IP. This would enable my home node to download blocks only, which might be fine because the upload is the problem. But this costs money to run.

A better solution is for Armory to support SPV headers-only without running a full node. Yes, you are losing a little security without doing your own verification, but that is the trade off if you can't run a full node.

So, does Armory still plan to support SPV headers-only at some point?

Thanks,

[TierNolan]

One option is to run a full node in AWS and connect my home bitcoind only to that IP. This would enable my home node to download blocks only, which might be fine because the upload is the problem. But this costs money to run.

That would probably be a small tweak to bitcoin-core.  They might even be willing to add a NETWORK_NODE command line switch.

If NETWORK_NODE was disabled, the node wouldn't send any transaction inv messages and wouldn't relay blocks or transactions.  Block inv messages would be forwarded, but not blocks.  This would allow getheaders to be used to keep the header chains in sync.

For a little more functionality, they could make it flexible with an upload ratio.  You upload at most 200% of what you download per day.  If the flag was set to zero, then it would be a fully leaching node.

I think the 2nd option would be more likely to be accepted, since it isn't pure leeching (though not really, since supporting usage contributes to the value of the coin)

[goatpig]

Thanks etotheipi, but this is not the funcationality gweedo or I asked about.

Armory 0.93 and Bitcoin 0.10 support headers-first, but do not support SPV headers-only functionality. Headers-first still requires a full node that syncs with the entire chain, SPV allows for thin clients without storing any blocks.

SPV functionality is needed because many home ISP connections will not support running a full node with 20MB blocks or more. My home connection already has issues with bitcoind and I can not leave a full node running all the time (I have ~100kpbs up).

In this situation, if Armory does not support SPV then I might need to switch wallets, which I don't want to. One option is to run a full node in AWS and connect my home bitcoind only to that IP. This would enable my home node to download blocks only, which might be fine because the upload is the problem. But this costs money to run.

A better solution is for Armory to support SPV headers-only without running a full node. Yes, you are losing a little security without doing your own verification, but that is the trade off if you can't run a full node.

So, does Armory still plan to support SPV headers-only at some point?

Thanks,

By SPV do you mean a BC Core setting that doesn't save block data locally, only block headers? How will Armory parse the blockchain to find your wallets' history then?

[gweedo]

By SPV do you mean a BC Core setting that doesn't save block data locally, only block headers? How will Armory parse the blockchain to find your wallets' history then?

I am talking about using the bloom filter that is on the bitcoin-core system. This would eliminate the entire armory database. Currently armory has two databases, the bitcoin core, and it's own. Right now both of those take up ~60gb on my system. It would be nice to eliminate one of those databases. I understand the risk that armory would have with just using a bloom filter to get transactions.

[goatpig]

By SPV do you mean a BC Core setting that doesn't save block data locally, only block headers? How will Armory parse the blockchain to find your wallets' history then?

I am talking about using the bloom filter that is on the bitcoin-core system. This would eliminate the entire armory database. Currently armory has two databases, the bitcoin core, and it's own. Right now both of those take up ~60gb on my system. It would be nice to eliminate one of those databases. I understand the risk that armory would have with just using a bloom filter to get transactions.

In that case, keep an eye out of the upcoming 0.93.1 release candidate.