Bitcoin Forum
December 05, 2016, 08:39:32 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 [108] 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 ... 232 »
  Print  
Author Topic: Armory - Discussion Thread  (Read 481822 times)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
April 30, 2013, 05:12:55 AM
 #2141

Is there any advantage of using a separate offline computer for offline transactions, over a live USB distribution with Armory in an encrypted partition and only booted to sign transactions on the primary computer with all networks turned off? I can't think of any. Anyone care to enlighten me?
BIOS/firmware malware.
1480927172
Hero Member
*
Offline Offline

Posts: 1480927172

View Profile Personal Message (Offline)

Ignore
1480927172
Reply with quote  #2

1480927172
Report to moderator
Some PGP public keys you should import: theymos, BadBear, Sirius, Stefan, Wladimir, Gavin, Gregory, Jeff, Pieter
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
April 30, 2013, 05:56:12 AM
 #2142

Is there any advantage of using a separate offline computer for offline transactions, over a live USB distribution with Armory in an encrypted partition and only booted to sign transactions on the primary computer with all networks turned off? I can't think of any. Anyone care to enlighten me?
BIOS/firmware malware.

Yeah sure, but unless I am going to order a LiveCD rather than make my own to install on the offline computer, it can get infected by said malware as well. Roll Eyes

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 30, 2013, 06:45:56 AM
 #2143

Is there any advantage of using a separate offline computer for offline transactions, over a live USB distribution with Armory in an encrypted partition and only booted to sign transactions on the primary computer with all networks turned off? I can't think of any. Anyone care to enlighten me?

It is pretty hypothetical, but if somehow malware was sneaked into the USB distribution, then in principle that malware could write your private keys to the normal harddisk and then another part of the malware could harvest it when booted in online mode.  In principle, the same could of course be done over a USB stick.  Both attacks would of course require tailor-made malware to steal just your bitcoins.  Quite frankly, if anybody worries about this scenario, I think they need help from a psychiatrist rather than from a computer scientist  Wink

Personally, I have an offline wallet in a virtual machine.  That is somewhat less secure than your suggestion of using a live DVD, since in principle the keyboard can be logged on the "real" machine, and the filesystem of my virtual computer can also be read from the "real" machine.  But then, anyone spending time writing specific malware to steal my bitcoins will end up being disappointed Smiley 

(but I also have real offline wallets ...)
opentoe
Legendary
*
Offline Offline

Activity: 1190

Personal text my ass....


View Profile WWW
April 30, 2013, 07:01:41 AM
 #2144

Is there a said definition of what an offline wallet is? I'm still trying to understand it because anything that is in the blockchain is live no matter what, right? Right now I have one wallet. I have bitcoin in there, but I want to move those bitcoin into another more secure wallet within Armory. Would that be an "offline" wallet? When I receive bitcoin into this "offline" wallet doesn't it go "online" at that time? I guess I'm looking for a noob response on what an "offline" wallet is. I think I'm thinking too literal here and it is messing me up.


Need help with your Newznab usenet indexer? http://www.newznabforums.com
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
April 30, 2013, 09:00:06 AM
 #2145

When I receive bitcoin into this "offline" wallet doesn't it go "online" at that time?

That's exactly the point, the answer is a "No". Bitcoin address are just hashes of the public keys, when people send bitcoins to an address, they just persuade the network to change the amount of bitcoins recorded under that hash in the blockchain(the ledger), you can even "send" your bitcoins to a random string corresponding to an address which doesn't below to anyone, but it's pointless, as the point is the "ownership" of the address, which belongs to whoever has the private key, and it's as difficult(read: infeasibly difficult) to reverse a used public address to find its private key, as it's to reverse a unused one.

Now the only thing you have to do to get people to "send" bitcoins to you, is to generate a public key for which you hold the private key. It's entirely doable if you somehow generate your private/public key on an offline device, which since its birth has never been connected to the internet, and publish the public key's hashed form(the address) on the internet, and keep the private key forever offline(like on a paper), that's about enough what you need to do to "receive" bitcoins. An address whose private key never goes on an online computer is considered an offline address, and an offline wallet is essentially just a  collection of offline addresses.

Here we have a problem, we can receive bitcoins now with our offline address, but how can we "send" them? Now you have to rely on the sneaker net to do that. Armory provide a functionality allowing to you to sign any transaction offline: you create a so called "watch only" address on an online Armory installation, and generate a unsigned transaction which doesn't really move your coins, then copy it through some movable storage to the offline computer where an Armory installation with your private key resides, sign it offline, and then move the signed transaction back and publish it, this way you can "send" bitcoins without your private key ever going online.

Hope that I am clear.




https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 30, 2013, 03:03:18 PM
 #2146

See also this description of offline wallets: https://bitcoinarmory.com/using-offline-wallets-in-armory/
xcsler
Full Member
***
Offline Offline

Activity: 203



View Profile
April 30, 2013, 11:10:11 PM
 #2147

I think there are security tradeoffs between having only digital/paper backups in a few locations versus having a Truecrypt backup of your wallet on Dropbox/Cloud. I'm not sure if either way is significantly safer than the other.


Free money, buy bitcoins!
opentoe
Legendary
*
Offline Offline

Activity: 1190

Personal text my ass....


View Profile WWW
May 01, 2013, 03:52:27 AM
 #2148

When I receive bitcoin into this "offline" wallet doesn't it go "online" at that time?

That's exactly the point, the answer is a "No". Bitcoin address are just hashes of the public keys, when people send bitcoins to an address, they just persuade the network to change the amount of bitcoins recorded under that hash in the blockchain(the ledger), you can even "send" your bitcoins to a random string corresponding to an address which doesn't below to anyone, but it's pointless, as the point is the "ownership" of the address, which belongs to whoever has the private key, and it's as difficult(read: infeasibly difficult) to reverse a used public address to find its private key, as it's to reverse a unused one.

Now the only thing you have to do to get people to "send" bitcoins to you, is to generate a public key for which you hold the private key. It's entirely doable if you somehow generate your private/public key on an offline device, which since its birth has never been connected to the internet, and publish the public key's hashed form(the address) on the internet, and keep the private key forever offline(like on a paper), that's about enough what you need to do to "receive" bitcoins. An address whose private key never goes on an online computer is considered an offline address, and an offline wallet is essentially just a  collection of offline addresses.

Here we have a problem, we can receive bitcoins now with our offline address, but how can we "send" them? Now you have to rely on the sneaker net to do that. Armory provide a functionality allowing to you to sign any transaction offline: you create a so called "watch only" address on an online Armory installation, and generate a unsigned transaction which doesn't really move your coins, then copy it through some movable storage to the offline computer where an Armory installation with your private key resides, sign it offline, and then move the signed transaction back and publish it, this way you can "send" bitcoins without your private key ever going online.

Hope that I am clear.





Thanks for the info. I'm understanding it more and more. I'm not just using it, I also want to understand how it works, that's why I'm spending the time on how it all works also.

Thanks.

Need help with your Newznab usenet indexer? http://www.newznabforums.com
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 02, 2013, 12:33:27 AM
 #2149

I cant change default transaction fee 0.0005(this is reap off when I send 0.01) I try set lower then 0.0005 but armory don't let me do it its bolox....

Some transactions must have a fee, and that is determined by the network, not Armory.  Armory simply determines whether the network will require a fee, and then tells you you must include it.  Many transactions, especially those over 1 BTC, can usually be sent for 0.0 fee.

Small transactions, using coins that were recently received, almost always requite a fee of 0.0005.  The network does this to prevent people for sending out millions of tiny transactions for free, or moving coins billions of times between two of their own wallets and clogging the network.  

"Moving coins billions of times between two of their own wallets and clogging the network"
can also be done with 1 or more BTC.

Small sums are normally used for tests, to check the functionality of backups, clients etc.

See no reason to punish tests with fees.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
May 02, 2013, 01:27:47 AM
 #2150

Well, I've reached critical mass of people with Armory problems.  About 80% of it is related to resource usage, and that just fell off a cliff for people with 4GB of RAM.  See the link below:

https://bitcoinarmory.com/announcements/

Trying to find the right balance of discouraging new users without scaring anyone.  I think this is the right thing to do until I get the persistent blockchain stuff implemented.  Which may still be a couple weeks.  Unfortunately, being featured on bitcoin.org has resulted in a lot of people putting money into Armory and not being able to get it out.

On the upside: it's not like one these exchange hackings... your funds are still safe.  Simply put, my design decisions combined with the size of the blockchain has DDoS'd users with less than or equal to 4 GB of RAM Undecided

But I'll have a fix out in a few weeks.  The app still works great for people with 6+ GB (and people like me with 32GB!).  No security issues, just usability.

P.S. - I apologize if I've been ignoring people (via email and forums).  This is a tad stressful for me.  It was actually my fault for poor development prioritization.  I'll get to you eventually.  Anyone I haven't responded to, I've left the email marked "unread".  Poke me again if it's urgent!

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
oakpacific
Hero Member
*****
Offline Offline

Activity: 798


View Profile
May 02, 2013, 02:38:39 AM
 #2151

I cant change default transaction fee 0.0005(this is reap off when I send 0.01) I try set lower then 0.0005 but armory don't let me do it its bolox....

Some transactions must have a fee, and that is determined by the network, not Armory.  Armory simply determines whether the network will require a fee, and then tells you you must include it.  Many transactions, especially those over 1 BTC, can usually be sent for 0.0 fee.

Small transactions, using coins that were recently received, almost always requite a fee of 0.0005.  The network does this to prevent people for sending out millions of tiny transactions for free, or moving coins billions of times between two of their own wallets and clogging the network.  

"Moving coins billions of times between two of their own wallets and clogging the network"
can also be done with 1 or more BTC.

Small sums are normally used for tests, to check the functionality of backups, clients etc.

See no reason to punish tests with fees.


"input_age" is also considered when calculating the priority, which partially determines if a fee should be applied.

And it's ultimately not up to Armory to decide if you should pay a fee or not, if miners don't want to include your transaction for the lack of a fee included, they won't deliver you a message to inform you.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
May 02, 2013, 04:25:40 PM
 #2152

"Moving coins billions of times between two of their own wallets and clogging the network"
can also be done with 1 or more BTC.

Small sums are normally used for tests, to check the functionality of backups, clients etc.

See no reason to punish tests with fees.

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.
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 02, 2013, 04:44:33 PM
 #2153

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.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 02, 2013, 04:49:36 PM
 #2154

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. Cheesy

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://bitcointalk.org/index.php?topic=140908.msg1500568#msg1500568

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.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
May 02, 2013, 04:53:51 PM
 #2155

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.



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

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
May 02, 2013, 05:39:01 PM
 #2156

Armory is bound to the transaction fee "guidelines" built into the default Bitcoin-Qt/bitcoind apps.
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.

chrisrico
Hero Member
*****
Offline Offline

Activity: 496


View Profile
May 02, 2013, 05:41:05 PM
 #2157

Armory is bound to the transaction fee "guidelines" built into the default Bitcoin-Qt/bitcoind apps.
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.



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

Activity: 1400



View Profile WWW
May 02, 2013, 05:50:26 PM
 #2158

What is the benefit of submitting it to blockchain.info over the local instance of bitcoin that you have to be connected to anyway?
It's only a benefit if someone wants to push a valid transaction that the reference client will not forward by default.
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
May 02, 2013, 05:56:56 PM
 #2159

What is the benefit of submitting it to blockchain.info over the local instance of bitcoin that you have to be connected to anyway?
It's only a benefit if someone wants to push a valid transaction that the reference client will not forward by default.

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
chrisrico
Hero Member
*****
Offline Offline

Activity: 496


View Profile
May 02, 2013, 09:21:40 PM
 #2160

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.

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.
Pages: « 1 ... 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 [108] 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 ... 232 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!