Bitcoin Forum
July 01, 2024, 11:07:48 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 »
3021  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.6-alpha) on: March 19, 2012, 11:56:06 PM
Okay, I got enough feedback and done my own testing to have confidence in releasing

Armory Version 0.60:  with migrate Satoshi-wallet feature

This is the last version increment before RAM-reduction!  In the near future, I have to sort out rewards for crowdfunding donors, and finally implement a once-and-for-all memory overhaul that will let Armory run on just about any system.   This is becoming critical, since it seems the size of the blockchain is accelerating, and soon 4GB of RAM might not even be enough for 0.60-alpha!

As for 0.60, I'll repeat the previous warning:  if your Satoshi wallet was ever touched by the 0.6.0+ Satoshi client, do not use the wallet-import feature.  The only difference between this version and the release copy is that I added a message-box warning before the migrate window opens, giving you a chance to bail before being tempted to try.  I don't know the true consequences of trying to import compressed public keys into an Armory wallet, but I guarantee you won't get what you wanted!

This means that if you have any wallets you want to convert, please convert them now.  Of course, you can always start a new wallet and send the funds to it from the Satoshi client (which I recommend anyway), but the migration feature will need an upgrade after the community moves onto 0.6.0.

3022  Bitcoin / Bitcoin Discussion / Re: Armory: One last push! on: March 19, 2012, 10:17:24 PM
My only monetization plans are to charge a few dollars for the Android app for two-factor authentication, because I'm getting external help with it, and that's not free.

What integration? And what is the charge for?

An Android armory client, that also has 2FA to interact? or

Android app that is just a 2FA client to produce a code that is then entered into an armory client on windows/a.n.other client to unlock wallet/functions?

in the last case just use google authenticator as a separate android app that can be used to 2FA for armory. It can have multiple counters (I have one for bitcoinica for example, another for my SSH logins, armory would just be a scroll down in the list).

Use a standard OTP library compiled into armory, and produce a QR code for the device to set up the seed. It can be time or counter based. These are IETF standards based mechanisms:
HOTP: An HMAC-Based One-Time Password Algorithm
Time-based One-time Password (TOTP) algorithm

As a bonus, you also get iOS and Blackberry authenticators as well. (blackberry doesn't have QR code scan though)

code is at https://code.google.com/p/google-authenticator/ so you can clone and customise the UI yourself if you want an armory client - it has already been done several times as I think the Battle.net/StarWars KOTOR clients are basically reskinned authenticators. Or just add to the list of accounts in the standard authenticator, and leave it up to google to keep it updated so you don't have to fix the issues resulting (and there have been a few recently including Force closing when opening the app- it was updated the same day, but was still an issue as it had been updated for several new devices that had recently been launched.)

The only real cost should be that of getting it into the Google Android market, though you can just make the APK available to download from your armory client site. You won't get the auto-update features of the market. (There are a couple of other markets as well such as amazon app market and appbrain)

marked


Marked,

Armory desktop client will always be completely free and open-source.  It will even include capabilities to set up an arbitrary 2-of-2 wallet, which include creating a Full+WatchOnly wallet-pair for Device A, and a WatchOnly+Full wallet-pair for Device B.  And the appropriate tools to manage them if they happen to both be desktops using Armory.

It's the Android app that will be cost money.  There's been a lot of talk about how that could be done, and a lot of talk (like you posted) about being able to use something like Google authenticator.  But that relies on google.  It's a third-party.  Sure it's free, but it's not "The Way."   I made deterministic and watching-only wallets, and BIP 10 for a reason:  to do all this cool stuff that no one else can do!  This Android app is one of those things.

The Android app will hold only a full wallet (B), probably transferred to it via scanning a paper-backup.  The watching-only wallet of (B) will be kept on the user's computer along with the full other wallet (A) to be used in the 2-of-2 transaction.  Whenever the user wants to spend Bitcoins:

(1) Create transcation as usual on desktop, provide signature A
(2) Generate BIP 10 packet of partially signed transaction, display as a QR code (or sequence of QR codes)
(3) Scan QR code(s) with phone, display confirmation dialog
(4) Enter passphrase as confirmation, press "Go".  Signature B is added, converted to final tx, and broadcast.

(The broadcast step will actually be to jump onto the Bitcoin network, seek out 3+ peers, and broadcast to each... it should take only a couple seconds).

The whole process requires no third-party at all.  Only your computer and your Android device.  Besides the broadcast part, you don't even need an internet connection.  Broadcasting will simply be queuing it to be broadcast next time it has a connection.

THAT app is what would not be free, because someone else is doing the bulk of the development on it.  It won't be even be a full Bitcoin app. 
If others want to implement it some other way, they are welcome to do so, and I will do my best to support the use cases other developers request.  But at the moment, this is what my plan is.  Let me know if you are planning to develop your own Android client that has Armory in mind...
3023  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.6-alpha) on: March 19, 2012, 09:50:34 PM
Ah, yes, of course. That was it. I was not on master. I think I switched to another branch at some point to check out the EC calculation stuff. All is well Smiley.

I bet that's why message verification failed, too! (from a previous message you posted in the thread)

Now that you have the updated version, try it again:  http://cloud.github.com/downloads/etotheipi/BitcoinArmory/Armory_0.56_sig_block.txt
3024  Bitcoin / Bitcoin Discussion / Re: Armory Crowdfunding Complete! 33% (but still successful!) on: March 19, 2012, 09:23:44 PM
Yessir!  I got a little crazy with vanitygen and succeeded.  It should've taken about 70 days of computation time but I got lucky and found it in about a week...  (notice no digits either, only uppercase letters).

Unfortunately, it's so cool that people don't even recognize it as a Bitcoin address Sad  
3025  Bitcoin / Bitcoin Discussion / Re: Armory: One last push! on: March 19, 2012, 09:19:32 PM
Can't see why donations cannot carry on, in bitcoins Smiley

When I get more free time myself I will try to promote it a bit.

Of course!  But for long-term planning purposes, I really needed to gague the level financial support I would get up front, so I know how many hours to reduce at my real job.  The decision I make will stick for at least 9 months, so I have to be sure I'm ready to do it!

I will update the top post with information, shortly.  And I will continue collecting donations through my regular two donation addresses:  

1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX
1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv


I might even start something very similar on my webpage:  a mini-store of over-priced items that will double as donation/support and also getting something useful.  I'll have to look into the financials of providing shirts & USB keys on-demand, but it might be doable in such a way that I get more benefit than effort spent doing it.  Plus who wouldn't want one of those TShirts!?! Smiley   I will send out an email soon asking donors for information, and verify that rewards are requested.  There were a lot of folks who explicitly declined rewards...


I can't find the one-week vacation with the g/f feature anywhere in there. I checked all the menus and options, too. Does the "there was" imply this feature was taken out? How much of a bounty is needed to add it back in?  Grin

LOL.  Nice interpretation.  I'll check with her about adding that as a feature Smiley
3026  Bitcoin / Bitcoin Discussion / Re: Armory: One last push! on: March 19, 2012, 07:35:59 PM
its really too bad more ppl don't step up and donate.  for all the things we're getting as a community we need you to spend more time developing this product.  given how much you've already added just this last month i could only imagine how much better the product would be if you were working on it full time.

It looks like it's just about over.  Obviously, I would've liked to see more donations (mainly because I really love this project and would love to work on it full-time if I could!).  But it was far from a failure.  There's quite a bit I can do with the money that was raised, and I'm already plenty psyched about taking some time off to get lost in coding for 10 hour chunks of time (while my g/f is at work Smiley).  Speaking of work, I'm at my real job, right now, but I'll post a more-detailed description of thoughts and plans tonight or tomorrow.

Thanks so much to all those who donated!  Seriously, even if I didn't make the goal, I got so much extraordinarily positive feedback, and so many people donating large sums that I really feel like my work is appreciated and will continue to make an impact!

-Alan
3027  Bitcoin / Bitcoin Discussion / Re: Armory: One last push! on: March 19, 2012, 06:57:26 PM
Just to be absolutely clear. It's free, right?

Armory is free, open-source software.  My only monetization plans are to charge a few dollars for the Android app for two-factor authentication, because I'm getting external help with it, and that's not free.  All other aspects of Armory are completely free, up to an including everything mentioned on the RocketHub page (which is everything including all multi-sig capability, offline wallets, multi-OS support, etc).  

I've already added an elliptic curve calculator, Bitcoin-address message-signing interface and Satoshi wallet migration tool, since starting this push one month ago!  (and there was even a one-week vacation with the g/f in there, too!)
3028  Bitcoin / Bitcoin Discussion / Re: Armory: One last push! on: March 19, 2012, 06:31:40 PM
Got one hour left!  One final push for some funds!!!  I anticipate that even though I didn't make $12k, I will be able to take a substantial amount of time off to work for Armory!  And I'm really looking forward to it!

I will maintain a donation address (and there's a donate button in Armory) for after crowdfunding is over, but RocketHub was my way to collect donations from credit cards too.  I may keep some kind of rewards thing for people who continue to donate in BTC, as I feel like it's a really good idea to make donors feel like their money isn't just hitting a black hole.



3029  Bitcoin / Development & Technical Discussion / Re: Synchronizing with Blockchain I/O bound on: March 19, 2012, 03:46:13 PM
Very good post, and you're right! Back to the initial point then. Smiley Except for some very basic stuff, I'm no programmer. But how hard do you think it is to implement a caching feature? I was checking the Bitcoin-qt process, and it looks like most of it's I/O activity was happening to the blkindex.dat file, which could quite easily fit in most people's RAM. Do you think it's feasible to cache that entire file into RAM? Of course, a smarter caching algorithm would be much better, but would also be quite a bit harder to implement. And we have to make sure sudden loss of power won't result in corrupted blockchains.


Btw, just for reference, I started writing Armory about 9 months ago when the blockchain was a few hundred MB.  I asked the same question, and even built an experimental, speed-optimized blockchain scanner that holds the entire blockchain in memory.  It has been remarkably successful for those that have enough RAM, but it's going to become unusable very soon.  The blockchain has more than doubled in size since I started, and it's increasing in speed.   I'm scrambling to get something in there so that systems with less than 4GB of RAM can use it...

Instead, I'm switching to an mmap-based solution which seems to give the best of both worlds.  It's treating disk space like memory, and a memory access retrieves the data from disk if it's not in the cache.  The nice thing about this is, if you have a system with 8GB+ RAM, it will just cache the whole blockchain and you get the benefits of the original implementation.  But if you have less RAM, it will cache as much as it can, and supposedly intelligently.  The caching is OS-dependent, but fairly optimized, as it's something that's actually implemented at the kernel layer.  The only consideration there is that if you are going to some kind of structured access pattern of the file, then you can "advise" the mmap'd memory about it and it will optimize itself for it (i.e. - if you are going to access the whole file sequentially, it will start caching sector i+1 as soon as you read sector i).

The problem with "why not hold everything in RAM?" questions is that with Bitcoin, there is no limit on what "everything" will be.  I don't know exactly what the blockindex holds, but there's no guarantee it won't get wildly out of hand -- maybe someone figures out how to spam the blockchain with certain types of bloat.  Then, thousands of users who've been using the program for months, suddenly can't load the client anymore.  Even with blockchain pruning, there's no guarantees.

So, my lessons from Armory were that you should never count on anything being held entirely in RAM.  And I like gmaxwell's solution of having a SPV-node until synchronization completes, then switching.  I've been pondering this a lot recently, but haven't come up with a good, robust (and user-understandable) way to implement it yet.

3030  Bitcoin / Wallet software / Re: android wallet to webcam client? on: March 19, 2012, 04:11:00 AM
I had considered this idea for Armory's offline wallets (webcams to move data around between offline and online devices).  It turns out to be kind complicated and cumbersome, and subject to driver issues because webcams do not always work easily on every OS.  Instead, I've resorted to USB keys between a regular online computer and an offline system.  And a recommendation to update full anti-virus and disable all autorun on the offline computer!  (plus paper backups to ensure even more security against device failure)

It's a million times better than any online-wallet setup.   However, it's only 99.99%, and people with lots of Bitcoins and even more paranoia probably want 100.00%.  Webcams + QR codes would theoretically work, but honestly I think it would be a mess.  Multiple sequential QR codes, driver issues, designing a real-time-feedback UI for using the camera, resolution issues, wires everywhere, etc.   Instead I'm working on a serial-port-based solution right now that really should be 100%.  I just have to investigate exactly how USB-serial-port adapters work, and make sure that there is exactly 0.0% chance of remote code execution based on incoming serial port data.

As you can tell, there's a few folks already using the USB-based solution, and they seem quite happy with it.   Check it out yourself:  
Main Page
Offline Wallet Tutorial
And of course, if you're offering bounties for such a solution, then please consider visiting my crowdfunding page to help me continue this project.  Only 12 hours left!  Smiley


EDIT: I realize this solution doesn't use a phone like you suggested, but any old about-to-be-junked laptop will work.  Get one off of craigslist for $40 and disable the wifi card in the BIOS.  In the next couple months, I will be setting up a system for using a phone for two-factor authentication via multi-signature transactions which will be a decent alternative for people who don't want to find/setup/maintain an old laptop for the above solution.
3031  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.1-alpha) on: March 19, 2012, 03:47:42 AM
I just pulled from git and made another transaction, same thing, the message pops up saying it didn't broadcast, even though it did. This time there's no error on the console though:

That's an error that only happened in version 0.55.  Are you sure you are in the master branch of the git repo?

Open ArmoryQt.py and go to line 1215:  you should see this:

Code:
else:
   newTxHash = pytx.getHash()   # CHECK THIS LINE
   print 'Sending Tx,', binary_to_hex(newTxHash)

Here's the commit that fixed it:  https://github.com/etotheipi/BitcoinArmory/commit/98bdfc29699be671fcfb959590fc733aeba9eb0c
If instead you see binary_switchEndian(pytx.getHash()), then you must be on the wrong branch...

I had originally switched the endianness for display purposes not realizing it was used to verify the transaction was sent, too.  It's looking for the wrong tx.  If you are running the correct code, then I'm kinda concerned...  (what OS, btw?)

3032  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.6-alpha) on: March 19, 2012, 12:13:18 AM
Wallet Migration Borked for 0.6.0!

Cypherdoc got around to helping me test the wallet migration... and it doesn't work if your wallet has ever touched the 0.6.0 Satoshi client.  It's because 0.6.0 adds compressed public keys to the wallet, and Armory does not yet support them.  And I set it to fail if it cannot handle 100% of the keys:  I don't want to risk someone thinking they're importing their whole wallet, when in fact they might be leaving money behind (if there happens to be any in those compressed addresses).

Given that I desperately need to complete RAM reduction, this feature is going to have to be restricted to only wallets pre-0.6.0 until I get a chance to implement the compressed public keys.  Gah!  If I had realized this was going to happen, I would've done RAM reduction first instead of putting in a feature that will only be 50% useful until after RAM reduction Sad

But at least I'm making progress on the RAM reduction!



3033  Bitcoin / Development & Technical Discussion / Re: Elliptic Curve Calculator UI (now part of Armory) on: March 18, 2012, 08:52:03 PM
What about encrypting messages with public keys using ECIES (http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme)?

Haven't done that yet and wasn't really planning to.  Though, it wouldn't take terribly long, gotta spend some time to figure out how to get the functionality out of crypto++ and add it to the interface.  So far, you are the first person to recommend it!  If others were interested, I could do it.   

But I feel like the signature operations were much more important... both for pseudo-multisig (key combining/splitting), as well as sending verifiable messages to other parties -- such as sending a mailing address for purchases.  Also, so services can start accounts based on your funding addresses, and then you can manage your account using signed messages from those addresses, without ever having to set up a login or give out personal information (I'm envisioning online gambling as a prime use-case for this). 
3034  Bitcoin / Development & Technical Discussion / Re: Backups in a Multi-sig world on: March 18, 2012, 02:26:32 PM
I've talked a lot before about various ways to do various multi-signature schemes, with and without OP_CHECKMULTISIG's help.  Let me start by repeating the most important one, which is what I plan to implement in Armory:  Two-factor authentication, computer+phone, without third-party.  This is made possible because of Armory's deterministic, watching-only wallets, and BIP 0010 to transfer data to the cell phone.


Setting up the wallets:
  • Create Wallets A and B on the primary computer (or an offline computer if you want to make sure both wallets never touch the same online computer)
  • Print paper backups of A and B
  • Scan QR code on paper backup B with phone
  • Delete private keys of wallet B on the primary computer (Armory has an option for deleting private keys only, converting to watching-only wallet)
  • Put both paper backups away in a safe place (safety-deposit box preferred)
  • (optional) Put watching-only copy of wallet A on the phone (if you want to give out addresses from your phone)

Now to give out addresses:
  • Device gets next unused public key from its own wallet, n, and then gets public key n from the watching-only wallet of the other device
  • Generate 2-of-2 multi-sig address

To spend the money:
  • Computer generates transaction like normal.
  • Create BIP 0010 Tx Distribution Proposal (TxDP; I really need a better name for this) and add signature for wallet A
  • Display BIP 0010 packet as a QR code on the screen (or multiple codes, if it's a long tx)
  • Phone scans QR code(s), displays transaction details, asks user to confirm
  • Phone adds signature B, and connects to the network just long enough to broadcast it to 3+ nodes

To recover loss of one or both devices
  • Restore both paper backups
  • No per-address/tx backup information needed, at all

BIP 0010 guarantees that the phone doesn't need the blockchain, yet it can still verify the details of any given transaction.  The determinism guarantees that we can create an infinite sequence of these multi-sig addresses and each one will be unique and unpredictable to strangers.  By designating these wallets are dedicated to 2-of-2 transactions, we can guarantee that we only use "parallel" public keys in both wallets:  that way you don't have to check all combinations of keys in wallet A with all keys in wallet B:  you only have to check publicKeyA(i)-and-publicKeyB(i)

A similar scheme can be concocted for ((A and B) or C), using a designated full wallet for A, and requesting a watching-only wallet for B (which is the third party).  C is then created on an offline computer and never touches the internet, backup is stored in safety deposit box.  Again, you only use ((PubKeyA(i) and PubKeyB(i)) or PubKeyC(i)) to keep a simple search space in case of a restore-from-backup situation.

-----

There are lots of magical things you can do with ECDSA, but to me they feel like hacks with multi-sig right around the corner (except for the [[A and B] or C] case).  They are secure, but they usually come with caveats:  such as requiring one party to give up their private key to the other party, who then gets full control of the funds--works fine in some situations, but a complete fail here, since giving them one private key is giving them all of them with a determinstic wallet.
3035  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.1-alpha) on: March 18, 2012, 01:44:03 PM
And, this is me putting my money where my mouth is: a7218dd222b7565ac00c93208b5ce9e7c1b9e1894ec31f5bc62d92e35d96c352

Thank you for this awesome, awesome work.

Edit: one minor request ... it would be great if you could add this to the git tree

znort987,

Thanks so much!  Drop me an email so I can at least send you the encryption seminar, and I will send you other rewards as appropriate, if you want!   I actually already added the file to the git tree under the "migratewallet" branch.  It was because I just happened to be on that branch and it will be merged into master soon (as soon as I get some feedback from others about the wallet-migration!).    How did you get that donation address, btw?  It used to be in my signature, but then I changed it for Armory funding and didn't think anyone still had it!  (I was going to put it back after crowdfunding was over).

Yay! Just made my first offline transaction. It works perfectly, though Armory popped up with a message on my online computer saying the transaction didn't get broadcast and that I can find information about the transaction in failedtx.bin. But the Satoshi client received the transaction fine and it's been picked up in a block: http://blockexplorer.com/tx/a090caf70a778ee7393e33c1283311b332ec92271fbe719a3a2030d82dbbc1fe#o0

It sounds like you're using version 0.55.  I had accidentally switched the endianness of a variable somewhere that prevented Armory from detecting that the tx was accepted, even though it already hit the network.  Please upgrade to 0.60...and try the wallet migration Smiley  (though 0.56 fixes that error, too).  Glad to finally get some more feedback about offline transactions working!  Please let me know if there's anything I can do to improve it!


3036  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.1-alpha) on: March 18, 2012, 03:04:34 AM
So, going back to one of my earlier questions ... is the 'send from'
feature (like the coderr patch in this thread : https://bitcointalk.org/index.php?topic=24784.0)
anywhere on your list ? Is it hard to pull-off at the code level ?

I'd donate generously to see that happen ...

znort987,

I spent some time putting together a script that will work with all versions of armoryengine.py:  It works takes in a wallet object, a list of input addresses in that wallet, a list (recipient,value) pairs, the fee you are willing to pay, and then a change address (which can be none, and the wallet will generate a new address to use for change).   It will even prompt you for your password if the wallet is encrypted.  It is heavily commented for educational purposes, and has lots of print statements so it looks about 3x the length it actually is!   But you can reuse this code everywhere, so really it was just a matter of me spending the time to create a good example script for others...

-- First 100 lines is the actual, reusable function:  takes inputs, loads blockchain, does calculations and error checking, prompts you if there's not enough fee, and prints out a shitload of information about your wallet and then returns the unsigned transaction it is creating.

-- After that is the "main" function which actually uses it.  It loads the wallet and creates inputs/outputs, executes the above function, then signs it with the wallet.  It then displays the signed transaction both in raw hex (which can be copied directly into http://bitsend.rowit.co.uk/) and the BIP 0010 format which can be copied into Armory "offline transactions" as if it was generated on an offline computer.  

-- Alternatively, I could add a method to send it right there, but Armory networking relies on an event loop to be running, and for such a small script, I figured there was enough there already to keep you entertained for a while Smiley

Here's the code -- createTxFromAddrList.py:
Code:
from armoryengine import *
from getpass import getpass


def createTxFromAddrList(walletObj, addrList, recipAmtPairList, \
                                          fee=0, changeAddr=None):
   """
   Create an unsigned transaction.  This method expects a wallet,
   a list of addresses in that wallet, and then a list of recipients and
   amounts to send each one.  

   !!! YOU MUST SPECIFY ALL BITCOIN VALUES IN SATOSHIS !!!
   You can either write it out explicitly -- 150000000
   Or use floats and convert to long      -- long(1.5*ONE_BTC)

   You must also specify an address to which you want change sent.  It will
   only be used if necessary (i.e. if you don't specify your recip list to
   exactly match inputs minus fees)
  
   If no change address is specified, the next unused address will be
   retrieved from the walletObj
   """
  
   if not TheBDM.isInitialized():
      # Only executed on the first call if blockchain not loaded yet.
      print '\nLoading blockchain...'
      BDM_LoadBlockchainFile()  # can add optional arg for blk0001.dat location


   # Check that all addresses are actually in the specified wallet
   for addr in addrList:
      addr160 = addrStr_to_hash160(addr)
      if not walletObj.hasAddr(addr160):
         raise WalletAddressError, 'Address is not in wallet! [%s]' % addr
  

   print '\nUpdating wallet from blockchain'
   walletObj.setBlockchainSyncFlag(BLOCKCHAIN_READONLY)
   walletObj.syncWithBlockchain()
   print 'Total Wallet Balance:',coin2str(walletObj.getBalance('Spendable'))
  

   print '\nCollecting Unspent TXOut List...'
   # getAddrTxOutList() returns a C++ vector<UnspentTxOut> object, which must
   # be converted to a python object using the [:] notation:  it's a weird
   # consequence of mixing C++ code with python via SWIG...
   utxoList = []
   for addr in addrList:
      addr160 = addrStr_to_hash160(addr)
      unspentTxOuts = walletObj.getAddrTxOutList(addr160, 'Spendable')
      utxoList.extend(unspentTxOuts[:])
  
   # Display what we found
   totalUtxo = sumTxOutList(utxoList)
   totalSpend   = sum([pair[1] for pair in recipList])
   print 'Available:  %d unspent outputs from %d addresses: %s BTC' % \
                  (len(utxoList), len(addrList), coin2str(totalUtxo, ndec=2))

   # Print more detailed information
   pprintUnspentTxOutList(utxoList, 'Available outputs: ')


   #############################################################################
   # IF YOU WANT TO CHANGE THE PRIORITIZATION OF HOW COINS ARE SELECTED:
   #        It's not dynamically customizable, yet.  But you can
   #        go into armoryengine.py and look for the WEIGHTS list
   #        around line 4550.  Change the values to change the
   #        optimization.  
   #############################################################################

   # PySelectCoins() assumes that the remaining will be sent to a change addr
   print 'Selecting coins based on unspent outputs, recipients, fee...'
   selectedUtxoList = PySelectCoins(utxoList, totalSpend, fee)

   print 'Checking that minimum required fee is satisfied for this tx...'
   minValidFee = calcMinSuggestedFees(selectedUtxoList, totalSpend, fee)[1]

   if minValidFee>fee:
      print '***WARNING:'
      print 'This transaction requires a fee of at least %s BTC' % coin2str(minValidFee)
      print 'Sending of this transaction *will fail*.  Will you increase the fee?'
      confirm = raw_input('Increase Fee [Y/n]:')
      if 'n' in confirm.lower():
         print 'ABORTING'
         return None
      fee = minValidFee
      selectedUtxoList = PySelectCoins(utxoList, totalSpend, fee)

   # Convert address strings to Hash160 values (and make a copy, too)
   recip160List = [(addrStr_to_hash160(pair[0]), pair[1]) for pair in recipList]

   # Add a change output if necessary
   totalSelect = sumTxOutList(selectedUtxoList)
   totalChange = totalSelect - (totalSpend + fee)
   if totalChange < 0:
      print '***ERROR: you are trying to spend more than your balance!'
      return None
   elif totalChange!=0:
      # Need to add a change output, get from wallet if necessary
      if not changeAddr:
         changeAddr = walletObj.getNextUnusedAddress().getAddrStr()
      recip160List.append( (addrStr_to_hash160(changeAddr), totalChange) )

   print 'Creating Distribution Proposal (just an unsigned transaction)...'
   print [(hash160_to_addrStr(r),coin2str(v)) for r,v in recip160List]

   txdp = PyTxDistProposal().createFromTxOutSelection(selectedUtxoList, recip160List)

   return txdp
  
  
  
################################################################################
if __name__ == '__main__':

   walletFile = 'armory_29KADwa1D_.wallet'
   if not os.path.exists(walletFile):
      raise FileExistsError, 'Wallet file does not exist! [%s]' % walletFile
   wlt = PyBtcWallet().readWalletFile(walletFile)

   # List of addresses in wallet, which you are willing to use for this tx
   addrList = ['1dyRSCSJdRiPgGYNTSE31Lodvs3Peiiqx', \
               '131t9NSPV3U1DdyQsEEcEzyyYsWrAcm1ZX']
  
   # Send money to these three outputs (change will be added if/where necessary)
   recipList =[('12V6i8PHhxyYWSEeYsXNr9kzwca1GrW5T8',  long(0.2*ONE_BTC)), \
               ('14CDNme1pFJxLKitdSMqTNETPeLzs1V4RD',  long(0.5*ONE_BTC)), \
               ('16GsZYhzJiv5BHTQaosrwpSpf9Unw3eLuC',  long(1.1*ONE_BTC))   ]
  
   # Works with or without a change address specified
   #sendChangeTo = '151kQbcEdBDehW5gt3fahrHwfBBtEjSSAx'
   sendChangeTo = None
  
   # Remember, must specify amounts in SATOSHIs
   print 'Creating Unsigned Transaction...'
   txdp = createTxFromAddrList(wlt, addrList, recipList, 50000, sendChangeTo)
   txdp.pprint()
  
   print 'Transaction created, now sign it...'
   if wlt.useEncryption and wlt.isLocked:
      passphrase = SecureBinaryData(getpass('Passphrase to unlock wallet: '))
      wlt.unlock(securePassphrase=passphrase)
      passphrase.destroy()


   print 'Signing transaction with wallet...'
   wlt.signTxDistProposal(txdp)
  
   print 'Transaction is fully signed?',
   print txdp.checkTxHasEnoughSignatures(alsoVerify=True)
  
   print 'Preparing final transaction...'
   pytx = txdp.prepareFinalTx()

   print '\nRaw transaction (pretty):'
   pprintHex(binary_to_hex(pytx.serialize()))
  
   print '\nRaw transaction (raw hex, copy into http://bitsend.rowit.co.uk):'
   print binary_to_hex(pytx.serialize())
  
   print '\nSigned transaction to be broadcast using Armory "offline transactions"...'
   print txdp.serializeAscii()
3037  Bitcoin / Bitcoin Discussion / Re: Armory: Cold Storage for the Average User! on: March 18, 2012, 02:38:59 AM
Has no one tried the new wallet migration tool (0.60-alpha-RC1)!?!  I know there has been a low SNR on this thread sometimes, but there was a lot of people requesting it!  Even if no one wants it right now ... I have no idea if the interface makes sense, whether it works on all systems, whether there's any problems with decrypting wallets associated with certain versions of the Satoshi client, etc.    Please help test it so that I can release it as a final version!

many thanks, each of say the 40 tx needs to be sent as a distinct tx on the blockchain because the tx is the lotto ticket, well it's hash is, so all need to be different & not bundled even though they're all going to the same address, so looking for a way to do this with a wallet that wasn't just manually entering 40 different tx, you'll get better feedback on this once the Bitlotto peeps have replied

edit: each tx is for 0.25 BTC with 0.0005 added as miners fee

edit 2: & it would be nice if it was easy to repeat each month to that month's lotto receiving address once that had been manually entered in to the wallet as recipient for another 40 times 0.25 BTC tx

I don't really want to enable folks to send hundreds of tiny transactions.  That bloats the blockchain for everyone else.   For instance... if you send 40 transactions like this, it's likely to add 10 kB to the blockchain, but if you send using multiple outputs, it will take about 1.5 kB...

It sounds like the BitLotto guys have decided that each transaction is one ticket.  It should be pretty easy to change it to each transaction output is/can be a ticket.  So instead of having a pool of tickets like:

Code:
TransactionA
TransactionB
TransactionC
TransactionD

They might have the following:
Code:
TransactionA:0
TransactionB:0
TransactionB:1
TransactionB:3
3038  Bitcoin / Development & Technical Discussion / Re: Backups in a Multi-sig world on: March 18, 2012, 12:31:44 AM
Many thanks @etotheipi.

Untill this post (and your other posts in BIP18 topic), i haven't collected enough data to make an opinion in the BIP16/BIP17 debate.

Now I have a clear point on the matter: P2SH sucks totally and should be deprecated. A solution which requires backup of wallet after every [P2SH] transaction is flawed by definition. It has always been the standard that making a backup of wallet secures you for the future transactions (unless you generate more than 100 addresses in the wallet and use the 101-th generated address). This was a very good and well-thought over standard created by Satoshi himself.

I find changing it highly irresponsible & potentially dangerous for the network.

Unless, of course I am misunderstanding something (sb please correct me then).

Shadow,

I made an oversight in one of my earlier posts, and the tried to correct it later (scratch that, I thought I did, but that must've been a different thread where I tried to correct myself on this topic...).   I will clarify both for you, and so others can correct me if I misunderstand it:

-- Regular transactions will not need to be backed up immediately.  The only thing about Luke's BIP 18 is that regular transactions might have a different "format", but you'd still always be able to identify them from the deterministic backup you made 10 years ago.

Multisignature transactions fall into two categories:  multi-sig with yourself (computer + phone for two-factor auth), and escrow/contracts multi-sig

-- For multi-sig with yourself, you should be able to identify those transactions without backups.  (I didn't think of this at first, but Gavin corrected me)  You can use two synchronized deterministic wallets, and all 2-factor-auth transactions will use address n in your computer wallet and address n on your phone.  Then, since it uses a constant format to combine those two addresses, search the blockchain for such addresses is no harder than a regular wallet;  as long as you know which two wallets were used for the 2-of-2 transactions.   You only have a couple permutations and orderings to try if you have lots of wallets.

-- For multi-sig with others, this is where it gets fuzzy.  You do have to backup after every multi-party transaction, because you have no way of identifying your own transactions with any P2SH/OP_EVAL type system, without the other person's addresses.  So that is where the real issue might be.

But there are two things to note about this scenario:

Let's say you lost all your computers and restored from backup and you were using regular OP_CHECKMULTISIG.  Well yes, you can identify the tx as your own, but who the hell owns that other address?  Shit, I lost all that information with my computers...  It seems you have some critical (but not necessarily sensitive) data that needs to be stored on each transaction regardless of the multi-sig system system used.

Also, I generally approve of the goal of P2SH or other OP_EVAL strategies, I just started this thread to fully understand the consequences of it.  I'm pretty sure it's not nearly as bad as I originally, incorrectly thought it was.
3039  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.1-alpha) on: March 17, 2012, 02:02:37 AM


For reference, if the tx has any output less than 0.01, it requires a fee of 0.0005.  If it has low priority (sum of BTC*numConfirmations of each input), then it will require a fee of 0.0005.  If the final transaction is too big, it will require a fee based on how big it is.  And that is 0.0005.  Not 0.005.   So yes... if you have exactly 0.0004 BTC there will be no way to spend it.

do u mean that if i want to send 1 btc, for instance, if one of the input addresses has <0.01 in it, then i will HAVE to pay a fee of 0.0005?

is this why sometimes i notice i can send a tx w/o any fee and other times am forced to pay 0.0005?  i didn't know these restrictions existed.

It's an output of less than 0.01.  It's creating "dust spam".  The main goal is to prevent someone from spamming the network with millions of tiny transactions.  

If someone tries to convert 1 BTC into 10,000,000, one-satoshi outputs they break the size limit.  If they try to send out 10,000,000 transactions of 1 satoshi each, they must pay 0.0005 for each one.  If they split coins into 0.01 increments to avoid the dust-fee requirement, they have to keep resending the same coins over and over, but then the priority criteria  will require a 0.0005 fee because all subsequent transactions will use really young coins ("priority" of each input:  BTC*numConfirmations;  a transaction can only be free if the sum of the priorities exceeds 144 which is one BTC after one day).  

There are extra, dynamic, factors based on the current number and size of existing transactions queued up in the next block, but it's pretty much irrelevant at the moment since the network doesn't even come close to filling up blocks.

I have the full set of rules in the calcMinSuggestedFees() method in armoryengine.py.  That doesn't take into account the dynamic blocksize considerations but it guarantees that your tx will be included on the next block that has space, which is pretty much all of them given the current transaction volume.

If you are wondering why some things require fees and other don't: it's kind of random ... if you have to combine 30 inputs to send 1 BTC, you will exceed the size threshold and pay a fee.  Or if it's a few inputs a combined priority of less than 144:  but if you wait two hours later, the combined prioirty breaks through then can be free.  In both cases, you don't realize that it's happening:  you just try to send 1 BTC, and you don't know if it has to combine hundreds of inputs, use young coins, or it could even [accidentally?] create a change output that is dust.  That's why it appears random.

The Armory algorithm takes into account all these factors, and will try to optimize the SelectCoins algorithm to minimize transaction fee and anonymity.  If you have a lot of coins, there may be thousands of different ways to construct a given transaction.  Armory gives equal weight to "avoid transaction fee" and "link as few input addresses as possible".  In the future, I will have an option to allow the user to select what they would like to optimize -- perhaps they're willing to pay a mandatory fee if it links less input addresses and makes the change output indistinguishable from the recipient output.

Fwhew!  I explained a lot more than you were expecting!  I guess I don't have enough to do, these days Smiley  (just kidding, I'm working feverishly on RAM-reduction.. just hitting a few snags)

3040  Bitcoin / Armory / Re: Armory - The most advanced Bitcoin Client in existence! (v0.5.1-alpha) on: March 16, 2012, 11:55:35 PM
Disabling the minimum fee still requires >.005BTC to send. I wanted to consolidate a wallet (the sending wallet contains .004BTC) out of OCD tendencies and ignore the fee (as I'm unable to pay it), but was prevented from doing so on the basis that I cannot cover the fee (even though I set it @ 0BTC).

So it turns out that while I originally advertised i can do actually zero-forced tx fees, I can't *actually* force it to do it.  Since you are transmitting your tx through one satoshi client, which has a min tx fee for such transactions, it will not forward it and is DOA.  So I can't actually do zero fees if the satoshi client wouldn't accept it (but Armory has the appropriate fee "schedule" built into it, so it will always give you a good fee "requirement."

For reference, if the tx has any output less than 0.01, it requires a fee of 0.0005.  If it has low priority (sum of BTC*numConfirmations of each input), then it will require a fee of 0.0005.  If the final transaction is too big, it will require a fee based on how big it is.  And that is 0.0005.  Not 0.005.   So yes... if you have exactly 0.0004 BTC there will be no way to spend it.

The satoshi client would do the same thing.  If it really bothers you, I'll send you 0.01 coins to compensate you for your troubles Smiley
Pages: « 1 ... 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 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!