 Show Posts
|
|
Pages: [1] 2 »
|
|
I am a bit confused, Why does armory run bitcoind in the background and what is the use of armory daemon?
|
|
|
|
Its the work I'm afraid I will have to do if I'm to use armory for our exchange. Etotheipi mentioned some where it requiring some work. The transaction format is the same across coins only the hashing algorithm changes from sha256 to scrypt?
Indulge me what makes you say its a lot of work?
I'm basing that assessment on this thread in github https://github.com/etotheipi/BitcoinArmory/issues/32Wondering if etotheipi can chime in, why does the hashing function need changing for ltc if I am just using armory wallets for storing coins. or are wallets and hashing function connected together? Can armory not use the coin daemon (litecoin daemon via rpc calls ) and manage offline wallets that way. I can modify armory to convert the unsigned tx to work with armory's offline signing and then all should be good? |
|
|
|
While BTC is still the king-of-the-hill, there are a number of altCoins popping up these days that often use the same core code for their wallets (since they have essentially the same structure). Can Armory support these as a mix of 'wallets'?
I've offered to give folks advice on how to adapt Armory, though only one person has really tried. A lot of coins may only need changing some constants. And in the case of LTC, updating a hash function. I know there will be some other hurdles, but it may not be a ton of code. It's just that alt-currencies are nowhere near the top of my priority list. Hi etotheipi To Support ltc , one just has to update the hashing function ? Where can I find it in the source ? |
|
|
|
|
Its the work I'm afraid I will have to do if I'm to use armory for our exchange. Etotheipi mentioned some where it requiring some work. The transaction format is the same across coins only the hashing algorithm changes from sha256 to scrypt ?
Indulge me what makes you say its a lot of work ?
|
|
|
|
|
OK armory would need to be modified and recompiled. Can Armorybe modified to create wallets for a coin type ? So I want multiple wallets maybe one wallet per coin type.
|
|
|
|
|
And this can't be done with when creating raw unsigned transaction with the online bitcoin daemon ?
|
|
|
|
|
wondering why you need to go in online mode and sync with blockchain?
|
|
|
|
Armory unsigned transactions are different. It's because they store all the extra data needed for the offline computer to verify the transaction without the blockchain. It can be a lot of data, but required to maximize security.
On the other hand, you might be able to go the other way, but you'd have to build some helper functions to convert a raw unsigned transaction from bitcoind, to collect all the blockchain data that is needed for Armory to verify the tx before signing. Armory assumes all transactions will always be signed by a dumb device with no blockchain -- there is no alternative form.
This is not standardized in any way. Maybe one day it will be.
Ok I am actually trying to build an exchange and the idea is to have cold warm and hot wallets. The cold would be using offline armory and the hot would be using online armory. The warm wallet will be built using either armory daemon or bitcoind. I didnt know armory daemon was not complete. So like you explained, I can use bitcoind and then before sending the unsigned transaction to cold storage, I would need add extra data to the transaction. What about signing a transaction, can that be done using bitcoind or do i need to implement a command specific to armory's requirements? I'm not sure what you're asking with the last question. If you are signing with bitcoind (can it do offline signing?) then you can just broadcast it with any network-connected app once you get it back online. Armory's default is to pass in this decorated-unsigned-tx, and return the same decorated-signed-tx to the online computer. That Armory instance will "prepareFinalTx().serialize()" which converts the decorated-tx to a byte string appropriate to be sent over the wire. Btw, we do have many users leveraging armoryd as their backend, it just requires a bit of work to fill in the gaps. One of the nice things about armoryd.py is that it's pretty easy to adapt it to whatever you need to do: there's a clear place to put code everytime a new tx comes in, everytime a new wallet-relevant tx comes in, and every new block. You don't have to operate through RPC, you can just program your hooks directly in. I need to figure out how to use bitcoind and armory offline wallets together via json rpc or some other method. I think this is the post I am looking for https://bitcointalk.org/index.php?topic=448284.0this is able to convert a signedtransaction from bitcoind into something armory can sign in offline mode. correct me if i am wrong? |
|
|
|
Armory unsigned transactions are different. It's because they store all the extra data needed for the offline computer to verify the transaction without the blockchain. It can be a lot of data, but required to maximize security.
On the other hand, you might be able to go the other way, but you'd have to build some helper functions to convert a raw unsigned transaction from bitcoind, to collect all the blockchain data that is needed for Armory to verify the tx before signing. Armory assumes all transactions will always be signed by a dumb device with no blockchain -- there is no alternative form.
This is not standardized in any way. Maybe one day it will be.
Ok I am actually trying to build an exchange and the idea is to have cold warm and hot wallets. The cold would be using offline armory and the hot would be using online armory. The warm wallet will be built using either armory daemon or bitcoind. I didnt know armory daemon was not complete. So like you explained, I can use bitcoind and then before sending the unsigned transaction to cold storage, I would need add extra data to the transaction. What about signing a transaction, can that be done using bitcoind or do i need to implement a command specific to armory's requirements? I'm not sure what you're asking with the last question. If you are signing with bitcoind (can it do offline signing?) then you can just broadcast it with any network-connected app once you get it back online. Armory's default is to pass in this decorated-unsigned-tx, and return the same decorated-signed-tx to the online computer. That Armory instance will "prepareFinalTx().serialize()" which converts the decorated-tx to a byte string appropriate to be sent over the wire. Btw, we do have many users leveraging armoryd as their backend, it just requires a bit of work to fill in the gaps. One of the nice things about armoryd.py is that it's pretty easy to adapt it to whatever you need to do: there's a clear place to put code everytime a new tx comes in, everytime a new wallet-relevant tx comes in, and every new block. You don't have to operate through RPC, you can just program your hooks directly in. You don't have to operate through RPC, you can just program your hooks directly in.
Well the thing is, our server making the calls to the daemon is in .net(C#) It is much easier and cleaner to simply make json rpc calls to the coin daemon. What are the advantages of programming the hooks directly? Also looking at armoryd.py i notice many new jsronrpc methods not found in the original bitcoin API calls list ( https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list) these methods have a prefix of 'jsonrpc' so im thinking they are newly added to the api call list but wiki does not show them. |
|
|
|
|
is it possible to mine bitcoin via coinium? or can one modify the code to support btc?
|
|
|
|
|
Does coinium work with btc as well or is it mostly for all coins ?
|
|
|
|
Armory unsigned transactions are different. It's because they store all the extra data needed for the offline computer to verify the transaction without the blockchain. It can be a lot of data, but required to maximize security.
On the other hand, you might be able to go the other way, but you'd have to build some helper functions to convert a raw unsigned transaction from bitcoind, to collect all the blockchain data that is needed for Armory to verify the tx before signing. Armory assumes all transactions will always be signed by a dumb device with no blockchain -- there is no alternative form.
This is not standardized in any way. Maybe one day it will be.
Ok I am actually trying to build an exchange and the idea is to have cold warm and hot wallets. The cold would be using offline armory and the hot would be using online armory. The warm wallet will be built using either armory daemon or bitcoind. I didnt know armory daemon was not complete. So like you explained, I can use bitcoind and then before sending the unsigned transaction to cold storage, I would need add extra data to the transaction. What about signing a transaction, can that be done using bitcoind or do i need to implement a command specific to armory's requirements? |
|
|
|
What commands are specific to the armory daemon that are not in the bitcoindaemon?
At the moment, "getledger" and "getledgersimple" are the biggest divergences of them, though we attempted to implement "listtransactions" the same way Bitcoin Core does. I really don't like what Core does with "listtransactions": it provides multiple outputs with overlapping entries, which require a bit of extra logic to adapt to your application. On the other hand "getledger" provides you exactly what you would see on the Armory GUI ledger -- it's a mutually-exclusive list of entries, each one corresponding to a single transaction, and theoretically all the values produced from it can be summed to give you your balance. We will also soon have an interface for: - Multiple wallets (context switching) - Create unsigned transaction (to take to offline computer) - Sign unsigned transaction (to run from offline computer) If you'd like to recommend more stuff you'd like to see, post in the following thread: https://bitcointalk.org/index.php?topic=588227.0ok so at the moment, can i sign/unsign transactions using bitcoin daemon since they already have a json api ? or will that not work with armory wallets? |
|
|
|
The simple Armory Daemon is now on github. It aims to be as close to a direct replacement for the Satoshi interface as possible. https://github.com/thedawnrider/BitcoinArmory-DaemonAvailable json-rpc calls are based on the Satoshi rpc interface and are as follows: getbalance getnewaddress getreceivedbyaddress sendtoaddress getbalance: Returns a decimal value in BTC for the total remaining balance in the wallet. getnewaddress: Returns the next address in the wallet as a string. getreceivedbyaddress: Returns a decimal value in BTC for the amount received by the address. sendtoaddress: Returns an unsigned transaction as a string. Implementation of signing and broadcasting is left to the client. Features that may be included in the future: User authentication SSL More API methods as required (the current set fills my needs). listtransactions is one method I am looking to include in the future. Please suggest anything else you personally may find useful, as I have designed this only to fill my specific needs. Clarifications required: - Are incoming transactions which eventually do not become part of the blockchain dealt with correctly? I am unsure how / unable to test this. - What happens if multiple transactions are made which would result in the balance being less than zero? Presumably when it comes to broadcasting the last of the signed transactions there will be an error from the Armory client which is performing the signing/broadcasting. Should tracking of the likely future balance in the daemon be enforced even though the transactions have not yet been broadcast and maybe never will be? How should this be managed, if at all? What commands are specific to the armory daemon that are not in the bitcoindaemon? |
|
|
|
It seems really archaic but bitcoin is strange like that, we have to go back to old tech like paper to truly secure such a futuristic asset.
You are trying to create an "air-gap" effect. The problem is that many things have auto-run, so it is hard to be certain that you are secure. You pretty much have to code the channel yourself to be absolutely sure. One suggestion was an animated QR code .gif file. Each frame would have a different code. Armory doesn't care how you get the file to/from the offline computer. well i was suggesting and maybe someone can try this and post here, if you remove ubuntu-desktop and you end up with a bare terminal. and if you put the usb stick, auto run should never run. Animated qr codes would work great, but digitizing something makes it easier for theft then physical objects. I think paper wallets would be the way to go. |
|
|
|
while using usb stick to move info over and back might be suitable for a individual miner it is not feasible in an exchange environment where several withdrawals are possible. So what is an ideal design for a exchange environment?
The cold wallet is supposed to be reserve funds. Cold Wallet - funds can be deposited automatically - funds can be monitored via watching wallets - withdrawal is difficult Hot Wallet - all wallet operations are automatic The idea is that you get a notification if the Hot Wallet is running low on funds. Funds can then be transferred to the Hot Wallet in a single transaction from the Cold Wallet. When a client withdraws money, it is from the Hot Wallet. In an exchange, there is like a "float" that varies daily. If the total funds stored on the exchange went up an down by 10%, then you only need to store 10% in the hot wallet. You could have an intermediate level (warm wallet?) that have less security than the cold wallet but more than the hot wallet. For example, transfers might be automatic, but need to be signed by 3 of 3 separate servers. I believe other controls (not tech based) around this process are also needed. I'm not an accountant but I'm thinking: - Regular cash/BTC recons. Is the amount of btc/cash held now equal to previous balance +/- transactions made? - Customer balance recons. - Cold to hot transfers can only occur if a proper recon has been done. Is the cold as big as it should be. Has the hot reduced to a low level for valid reasons? Need sign-offs on this, with the cold to hot transaction only occurring if audits/recons are in place. This is to stop one blindly refilling an empty hot wallet from the cold. If you have a recon you can be sure the hot needs refilling for the right reasons. - Regular cash/BTC recons. Is the amount of btc/cash held now equal to previous balance +/- transactions made?
- Customer balance recons.
- Cold to hot transfers can only occur if a proper recon has been done. Is the cold as big as it should be. Has the hot reduced to a low level for valid reasons? Need sign-offs on this, with the cold to hot transaction only occurring if audits/recons are in place.
those are valid concerns. there has to be some form of auditing available to customers especially they have no control over hot/cold storage. we will have an officer approve the withdrawal request and then also have speed bumps and a some kind of activity monitoring. has anyone found a serial tx program that can be used to transfer transactions from cold to hot storage? |
|
|
|
Thanks for all the great responses.
I love the idea of a warm wallet!
I am collating all the ideas and schematics for the devs to talk over.
Just looking at armory and it would be great if you could import a CSV with transactions that you need to happen and then then sign those on the cold wallet and finally broadcast them from hot.
So Armory would effectively be both the cold and warm wallet but we daily export a CSV of transactions that are waiting to happen and then send them out from cold storage.
Its not ideal because I was thinking it would be best to use Armory to just recharge the HOT wallet and so if the hot wallet runs out of funds then every new transaction goes into a Queue which are then executed once the hot wallet is full again.
What I like about this is that its more automated but if we are compromised I want a way to detect dodgy withdrawals in the queue because we don't want to fall into the alleged Karpeles tunnel syndrome, where funds are tunnelled away under the noses. But thats a whole other problem.
The main problem at the moment is cold warm hot wallet architecture.
Armory really is an amazing piece of work for cold storage, the issue is hot and warm really. I think it might be that every 24 hours we manually top up the hot wallet to a percentage of the cold.
If there is an overflow of withdrawals then we could manually process them. (This could annoy customers but if they realise that its for security reasons then people will be a bit more accepting, although people are fast to yell scam all over the internet if they don't get there bitcoins within seconds :/ so theirs that. )
The main problem at the moment is cold warm hot wallet architecture.
I would like to discuss what manual methods are available to transfer signed tx from cold storage to warm/hot wallets. I am having a hard time to convince my team to use cold storage for one let alone usb sticks because they think its too old fashioned to use usb sticks. The thing about cold storage is it must not be connected so ethernet cable over vpn does not work. What other options are available to withdraw manually? |
|
|
|
while using usb stick to move info over and back might be suitable for a individual miner it is not feasible in an exchange environment where several withdrawals are possible. So what is an ideal design for a exchange environment?
The cold wallet is supposed to be reserve funds. Cold Wallet - funds can be deposited automatically - funds can be monitored via watching wallets - withdrawal is difficult Hot Wallet - all wallet operations are automatic The idea is that you get a notification if the Hot Wallet is running low on funds. Funds can then be transferred to the Hot Wallet in a single transaction from the Cold Wallet. When a client withdraws money, it is from the Hot Wallet. In an exchange, there is like a "float" that varies daily. If the total funds stored on the exchange went up an down by 10%, then you only need to store 10% in the hot wallet. You could have an intermediate level (warm wallet?) that have less security than the cold wallet but more than the hot wallet. For example, transfers might be automatic, but need to be signed by 3 of 3 separate servers. so your implying, the withdrawal from cold wallet will be manual and deposits would go in warm wallet? transfer will be automatic from warm wallet to hot wallet using a server api (custom) ? What other options are available for manual withdrawal from coldstorage besides usb stick? |
|
|
|
But using the api method, we are then left with a connected system, a cold storage is offline and no automatic withdrawal exists, withdrawal must be done manually. What protocols are available for a manual withdrawl from coldstorage?
Cold storage withdrawal is supposed to be manual. Armory uses a USB stick to move info over and back. You use Armory running in "watching-only" wallet mode to create an unsigned transaction. This is copied to the USB stick as a file. You boot up your offline computer (not connected to the internet). The offline computer reads the file from the USB stick. It displays information about the transactions, i.e. destination address and amount. You press OK, and it signs it and saves it back to the USB stick. You take the USB back to the internet connected main computer. Armory running on the main computer broadcasts the transaction. This assumes that the USB doesn't auto-run and your initial download/setup was correct. while using usb stick to move info over and back might be suitable for a individual miner it is not feasible in an exchange environment where several withdrawals are possible. So what is an ideal design for a exchange environment? |
|
|
|
|
I like to have a discussion on how one can maintain a cold storage (offline system) that has no way to reach the hot wallet. How does one transfer transaction between the two systems? One way would be to have a api server that would allow unsigned transactions to be sent to the cold storage, get them signed and then send them back to hot wallet for broadcasting. A human can also authorize transactions like withdrawal requests.
But using the api method, we are then left with a connected system, a cold storage is offline and no automatic withdrawal exists, withdrawal must be done manually. What protocols are available for a manual withdrawl from coldstorage?
How can a tx be moved from a cold storage to an internet connected machine for submission ? I am able to build a api server that could technically have some api exposed to transfer signed tx from cold storage to hot wallet for submission but then coldstorage wont really be offline. Without using usb keys in an exchange environment, I like to know of other possible methods to transfer tx from cold storage.
|
|
|
|
|
