|
Gavin,
I have nothing new to add except that I switched Alice and Bob on the gist I posted. So now it should be consistent with your gist. I'll continue pondering the replacement idea... I think it's acceptable, but we also need some way for a user to be able to submit a replacement tx without hiring a geek to help. Getting help could cost more than the tx itself, and then Bob would just broadcast the LAZY_ALICE tx right away and get the money after 30 days knowing it's not worth it for Alice to try to figure it out.
Even if it's just another service that can be directly integrated or linked into the UI so the user has something to click to explore that option. Presumably some big miners could setup some kind of service for this purpose, but I hate bringing even more third-parties into the equation.
Plus, I'm not 100% fond of the idea that miners should be easily bribed to replace their memory-pool tx with different ones...
Sebastian,
I don't totally understand your proposal, but I don't see how or why the Bitcoin network, 99.9% of whom have nothing to do with this private transaction, should have any say in this. I *don't want* the network getting involved in my private affairs.
|
|
|
|
Just an update: I talked with Gavin yesterday and we determined the extent to which transactions are "replaceable", which is more than I expected. There are two locktime/replacement features of a transaction that would be used if full-replacement was available: tx-locktime and per-txin-sequence number. While replacement is technically "disabled", there is some logic in there that still triggers if you have non-zero locktime, and non-maxxed-out sequence. See the bytemap for where locktime and sequence numbers occur in a tx. The final conclusion was this: If you create a transaction with a locktime in the future and with a non-maxxed sequence number, that tx will not be allowed in the blockchain. It will be allowed into the blockchain after the locktime though (if seq is maxxed out, it will pass IsFinal() and be included in the blockchain immediately, though you can't spend the outputs yet). However, even without it being in the blockchain, it will propagate and stay in nodes' memory pools. This means that even though the tx is not in the blockchain, if it is broadcast, nodes will hold onto it and reject conflicting tx. Therefore: locked-tx replacement is possible, exactly once, if you contact a miner and have them delete the locked tx from their memory pool and then include a new [conflicting] tx in their next block. However, I'm not entirely convinced that this is "usable". In most of the scenarios where I can see this being used, there's too much reliance on being able to contact a miner to replace a tx. And I wonder if miners should [ethically] be agreeing to just replace arbitary tx for users on a whim. I'm sure there's some deceptive practices Bad People will find. Gavin, where is your original proposal on multi-sig/escrow? I want to look at it again now that I understand what's actually possible. |
|
|
|
Renamed this to the "discussion thread", started a new "Announcement thread" just for major release information. The discussion here was getting excessive/annoying for users who only want to know about major developments! The new annoucement thread is: https://bitcointalk.org/index.php?topic=75647.0PLEASE DO NOT POST ON THAT THREAD! Use the notify button at the top to subscribe! I merged 0.70 into master, and compiled binaries for Windows. Find them: http://bitcoinarmory.com/index.php/get-armory |
|
|
|
DO NOT REPLY TO THIS THREAD. THIS THREAD IS RESERVED FOR ANNOUNCEMENTS ONLY!To discuss this topic, use the discussion thread! Use the "notify" button at the top-right to subscribe! ^^^^^^ ( Armory Homepage) ( Get Armory) ( Cold Storage) ( Donate!) ( Github Project Page) ( Report Issues) ( Discussion)
Armory Version 0.82.2-alpha! Lots of new features! (and a couple bug fixes)Grab 0.82.2-alpha from the github download pageChangelog between 0.81 and 0.82.2- URL/Link Creator:
Right click on an address in your address book, or press "Create
Clickable Link" when you get a new address. Use this to email
payment requests to others, or post payment information on webpages.
- Minimize-to-system-tray
The file menu now has a "Minimize" option, and you can set it to
minimize-by-default when you click the "x" on the top window bar. - Logging system implemented
All information normally written to console is now saved to a
log file in the Armory home directory. This makes it much easier,
to report bugs/crashes, especially for Windows users. Please use
"File"-->"Export Log File" to save a copy and send it with your
bug reports. - Specify Change Address (Expert Mode Only!)
The send-bitcoins window now has options in the bottom-left corner
to specify how you want change outputs to be constructed. Either
recycle change into existing addresses, or specify an address. - New "MAX" button
New button for each recipient in the send-bitcoins window. Given
the values already entered for other recipients and the transaction
fee, it will compute the max spendable balance for this recipient
and insert it into the "Amount" field. - Version Checking and Notification
When you start Armory, it will automatically check versions.txt in
the master branch of Armory on github. It will then notify you if
your version is older than the latest one. - Removed Bitcoin-Qt Wallet Migration
This was causing more confusion than it was helping. Given that
very few users will benefit from it anymore, it has been removed
until the new wallet format is finished. - Fixed SelectCoins Bug
Many users reported issues sending coins under some circumstances.
This has been fixed.
GPG Armory Signing Key!The following key has been uploaded to the SKS Key Server. It's also available directly from the Armory website. I will start signing all *.deb files with this key, and the private key is kept on an offline computer. I actually transfer the binaries to that system to sign them before posting them here! UID: Alan C. Reiner (Armory Signing Key) <alan.reiner@gmail.com>
PUB: 4096R/98832223 2012-02-28
Hash=54107F537C4075F62298BB75BBA599A0
Fingerprint=821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)
mQINBE9MSnQBEACk81H2LPHm6wnodFU4qgEuswJJ5tRzTWU5kl+aIuxQ5iyVIF21
aOR0M0TLW0N7qAfGawXIf4nSPt5ohE2k1YVEsD/wVzICtsDi8AzwhMoRpDPIREi9
5NLKOUOmsTCM/1CYvmFhI741y/SeoLVimFBDlnUrDg8ivH+6gh0zgHJLigjUPmz5
dA+ea7n9iFluoGoSVudmBAytDlvYPrDH1nWWdpv+lfIIjFHc7k6y4wuD0H3W3UmQ
RIo3JfvLsvbY01vZIyPPRGzCn3/3bbv1dOkoF8FBMOkCgq+dohD5u8yEs/ePz2GI
aiWkTNFsX/N0MR/r+ce96Pekt6j5LYbXqo5hZOO6jZ+foidzoVK3GnHGU07wBRgf
Rd7MeaV07dZaIwlyym0RpF0INPt7iI9jJBW0qJGCFWkpl5gXk5N0U+MAGN4bMHAp
tybmOJo4pctaXcByzWGNVjDRhJCRgjD9o0Frlond0We1iPyxw3+ZDBbjjXH586El
MxJwdUUtfn96DsmRMyIAdc30Pzo6FBl0SEEBakz2Lt4d/AgKcbb/D6g+z0zOHfrc
etf6mxPWEW9x1cCB3+7IQ6sEcpF7a/UcPIFqsjGo5VFIkGdu7oKqN5wP6lbnmwBI
3r2pUnhxFlXBq0JqQS7rIJqpXBkS8XyH6Tsw4FWILaHK1kl1fa2EFBHwqwARAQAB
tDtBbGFuIEMuIFJlaW5lciAoQXJtb3J5IFNpZ25pbmcgS2V5KSA8YWxhbi5yZWlu
ZXJAZ21haWwuY29tPokCOAQTAQIAIgUCT0xKdAIbAwYLCQgHAwIGFQgCCQoLBBYC
AwECHgECF4AACgkQSrFq6piDIiO3xA//cu7equV8b6ScuAyVwCEhvGG/Cf5Dh3nR
IhLCbcYe1KjQ2XHKpjA5LxgJDgZRYzUwswDRkHThZgwHBmxOc56ZFn/DYd5uA60j
B/++pb+IlymEb+khetHgQPE/cY4B+NM8lG1qUMWfCUOK/soUK76Dv5LDxuxygMbH
jylWEh6LwrhUUTdzhQfxvKI0hpdS6k+8njdQcvFTlouqbORAUrgOyjl4/bdKNd2S
Dpuz6iJYmTJ8keW8kcH/CWOl9kHCyOTGckVPTfnTueaVc0idb6bbTlsRRWRo3qxi
pUw3o6yInU1ImMEIpVp3zgVkDBAoIQVq/lSqXNs4+5WmGD1Mv0DM47WB8IvS/jQR
clvdegNKG3sOurnLmv6HPauE2hUF1hbO/aVabon/AtxFdrRIgUI2pkJSw/aHNys4
fKg5npJWc+V1o+zEZSNyckxHnMu5zIfj7vtP+aMHtI17YjKrJ88WzR/d3P2oGT0s
rbWD0GKJk8vBXKFJiq/uFse8kJtzjyvr0Rydm+O0BzfRHTD777aha+kW8iI8Prxm
JarQ4zgy8kKOANlqKqXouSc2TpIMlLUxgnSIv7xKSYZp9oOka2M8zIHhKyACwcCC
mcnyRZK//23IZGzN50smRrSZgzFbp2xrb7v+0RklkQpQb6snzJSNjyG4miJiWRZw
+zrNmueZ6ra5Ag0ET0xKdAEQANwKOrNbQIgUAlQ7sjXURYMhgaWZvRW8C8ZPcIbM
TcUAqOuUS4A/d9k7Q4AJOiuQHyfVzBZC7Q6iUZm9iUyS84q5x8mVwYM+KjF4Etbe
QZqztps5deIJfAHy/GsSWv8GQdvKGH7l5REcba/+8IdIrqlgff6j8GD2lZXvLoOm
eL2TmJuzCFLZRveUHppjHCx2IBYPnJQqScIHPLequaKZwDPngJPofZkHGkIWAzKW
mgJWcIlXlGVCs7BqgmIoniZk2pO+kj7Z6FqmTReHgCkl2sFzwCe3/QpLLGCBa6Er
gxeAo91rOlJejmZTxkdIzMyw8BmLm6xJgUwB7vpf+Vsp1dv2s9RdFnD2DZKrYmmi
3Lemz26zSVw1peFNSW7ApuOND9GjNvJfST0cWbRN8Ckqtoij86JE8gIlzGGa7Uyu
pT4/3Bw9mdRinkQUCc37URrWiZg5pxHGPEiE3RJQGnXbXsaSIeiFDL8dQcypqLSL
N2lcSauXVauqdmYZvk4EW5DW7/dw2WbePsEkgLoiVH68DhGB6Qd/5EjxehMdntwc
XAXfQho1dlkcDljwPu+1MxDQAlOdht3eMVmdNaQK3QVMyLeRmynNA4DUotckT6mN
sctRidGJODE/q/f2A19apRuXgNIkijWVbbkVWJ8+XC+7V9Q3Z3Ir2NJMxv/Jokg6
SUD/ABEBAAGJAh8EGAECAAkFAk9MSnQCGwwACgkQSrFq6piDIiMdHxAAiqlvWHO4
vRlBIn3GUf/ZHN5HGA039onE4piD8iQDX+zHo4K7csO/jn8fJfln+9RIF/pB7PIv
U+eEDw06xb9xnDwul5xId+v794szZLsio4WYGNb1lzvTAHolEB5xtv1a24Ta8suK
nGPxSmC/uTjmkIANTFj6099fuiuuWB8dw0At0Qj+AwSr4cXju4k1e4NsCKVLvxo3
Q9kTtoL1GnzBQvaRW9AGm4ynH5K8aWo4MqR33+EBDOwJ5NDJBkMrlcw+GYU6Z87o
ldCtEFg5iGrwZAhpN3wLt1WH/ZGBlYAUEQ+jXwcuzZuB8TcTIw/paGwHu7vn9jRP
1gghJnZp/KTe2B/e1h69qRD1n91NI7lGsENDFYI9WF8z3ALbmNz4kNhlZxjlsbMH
NUCVdjBJp87KuIb5slK1mQEp3/Db3GdmUaEGoYZODwWCQIHz52806ofxy9vo5/F7
V32ldUc+AinhQfhtne//U2yaIJ6Gv3yiuJGegQcQEm3TjOiqXFPkm1gU/4q76tp8
wWjv/N+SUvHtbPa+cwVjMkvdo6OyXXj3INp40GnuXa+05ujmX8cv8tGXP0kb3PpF
nIRy2FIoQ/jEBhvHIm+PznZdgON4ZoXmzXYyPDu+c85Cb4mN4xS2t5ahFKZMDbkl
YAmM8m30X2wN2GFa4lLy0FeHmIxXqXZ9WOg=
=S5E4
-----END PGP PUBLIC KEY BLOCK-----
DO NOT REPLY TO THIS THREAD. THIS THREAD IS RESERVED FOR ANNOUNCEMENTS ONLY!To discuss this topic, use the discussion thread!
|
|
|
|
Maybe I'm doing it wrong? (or missed a post about this?) Importing encrypted private key (hex) generated by vanitygen Using the Privkey (hex) output from vanitygen I get this: Traceback (most recent call last):
File "/home/rob/devel/BitcoinArmory/qtdialogs.py", line 1636, in processUserString
QMessageBox.critical(self, 'Invalid Data', e, QMessageBox.Ok)
TypeError: arguments did not match any overloaded call:
QMessageBox.critical(QWidget, QString, QString, QMessageBox.StandardButtons buttons=QMessageBox.Ok, QMessageBox.StandardButton defaultButton=QMessageBox.NoButton): argument 3 has unexpected type 'BadInputError'
QMessageBox.critical(QWidget, QString, QString, int, int, int button2=0): argument 3 has unexpected type 'BadInputError'
QMessageBox.critical(QWidget, QString, QString, QString, QString button1Text=QString(), QString button2Text=QString(), int defaultButtonNumber=0, int escapeButtonNumber=-1): argument 3 has unexpected type 'BadInputError' dialog operated correctly when attempting to import invalid key - proper error displayed. ========= P.S. I have much the same issue as psy on my ubuntu box with the window sizes, and I'm running 1280x1024 on this machine. I haven't seen the oddness he saw in the balance display, just incorrect window sizes. Guruvan, is this on 0.70? I messed with the import box recently, so maybe I botched something. In fact, it must be a bug, because it would pop up an error message if it wasn't. I'll check it out tonight. Thanks! |
|
|
|
1366x768 is a small screen? That's a 15.4" laptop HD screen, so i wouldn't qualify it as a small screen, much less super-small  And yes, the window resizing trick makes it go away. Also, sent you a small 1.5 BTC donation. Hmm... those screenshots look more scrunched than Armory looks on 1024x600 screen on my EeePC. Admittedly, I have the same problems on the Eee, but it only takes stretching it out a few pixels to make it look right. I'll see if there's a global change I can make to help: like setting minimum button/label heights (based on font) that will prevent the dialogs from opening too small... |
|
|
|
Indeed, there are some issues with Armory layouts on small screens. It looks like yours is on a super-small screen! In fact, I'm not sure how to appropriately handle that, besides noting that if you stretch the windows out just a little bit (but still within the screen size) they get much better. That's obviously not a solution, but more of a comment about how to deal with it until I get a solution. Recommendations for how to accommodate for this more intelligently in my design layouts would be great. I can't imagine that just changing the font size depending on desktop resolution would even do anything. Maybe I just need to put less stuff on my GUIs...? |
|
|
|
In all cases: the Bitcoin network is acting as an escrow service -- and it's conditions are release are: "Wait for further instructions that are agreed upon by any two of these three people."
BTW: I'm not proposing that this is the only way to escrow in the BTC network. I would like to see some kind of time-locked tx that prevents laziness, and doesn't give one party too much power. But I don't know how it can be done when tx-replacement isn't enabled on the network.
I think it is really important that the bitcoins involved in failed escrows not be destroyed, but EVENTUALLY make their way back into the economy. So I'd really like to see network and client support for having both people pre-sign and hold on to a transaction with a far-in-the-future lockTime (maybe as a fee-only transaction). Gavin, I totally agree with you if it were possible. But so far I'm not seeing how. The locktime/replacement stuff is promising, but it doesn't answer the question of how to deal with it now. It would probably be a long time before we could test it enough and roll it out. Which is why I don't feel bad that I don't understand it too well... I have time. As far as I can tell, even locked transactions are final, it's just that the outputs can't be spent until the lock time. This means that once any such transaction hits the network, one party will get the money in the future if they just disappear and do nothing else. And because it's final and in the blockchain, there's nothing else you can do to divert it. Obviously, we want to avoid that situation. But I'm not seeing many other ways with the tools we have (besides keeping third-parties in the loop) |
|
|
|
Hi Alan,
You must be pleased with the results of your memory mapping work !
Pleased enough! It's disappointing it didn't work better on Windows, since most users in the target audience are Windows users, but there's still a very high proportion of Linux users in this community, so the fact that it works so amazingly well, there, is quite pleasing. Eventually, the full-blockchain-scan-on-load is going to be silly (it already is, on Windows). At some point (but not high priority) I will be upgrading it even further, to save info between loads, so it will load instantly but be in "reduced" mode until balances can be verified. At that time, it might support 32-bit Windows systems, too. I thought I would cross post about the Satoshi 0.7.0 deterministic wallets on the bitcoinj mailing list.
Do you have any links to either the discussion about it or an actual spec ?
Good question! I've been talking to Sipa about it on IRC mostly. At some point he had written something up, but when I asked, he said he was going to start a BIP on it. My understanding is that he has a branch with a working deterministic wallet, and I know the technical details of it, so I can get started implementing it right away. Perhaps if you ask him, he will provide his original pastebin/gist proposal. But he might be preparing the BIP right now... If you're interested, I can go into the gory details of it right now, but sipa is probably already in-progress, so I'll defer the question. |
|
|
|
|
ACK: I was responding to a message from teste... but those disappeared... here was my response to his now-missing message
You guys are missing the point of 2-of-3 transactions, which was the whole point of P2SH/BIP16: there are X coins held up in a 2-of-3 transaction. It means that in order for those coins to be used as input for a new transaction, that transaction must have the signatures of 2 of the 3 parties. Any party can propose how to distribute the funds however the heck they want, but they can't make it happen unless they get one other party to sign it.
Let me say that in another way: No one party has any control over the money whatsoever.
-- The third-party can't "run with the money," because it would require transferring 100% of that 2-of-3 output to their own address, and neither Alice nor Bob would ever sign that transaction.
-- Alice could decide he deserves a refund, but he can't execute it without getting Bob's signature (when he agrees that there was a problem with the shipment and he needs to be refunded), or getting the third-party signature (after it arbitrates and decides that Alice deserves a refund).
-- Alice and Bob are both understanding people and recognize they both f***ed up and they should split the money: that works too! They create a tx spending 28 BTC, and sending 14 BTC to each of them (and the third party wasn't even necessary).
In all cases: the Bitcoin network is acting as an escrow service -- and it's conditions are release are: "Wait for further instructions that are agreed upon by any two of these three people."
BTW: I'm not proposing that this is the only way to escrow in the BTC network. I would like to see some kind of time-locked tx that prevents laziness, and doesn't give one party too much power. But I don't know how it can be done when tx-replacement isn't enabled on the network.
|
|
|
|
In the case of Bitcoin, the network can be the third party. That's what the 2-of-2 version is: both parties agree on the terms (that only further agreement from both parties will be accepted) and the network holds it until they're ready for disbursement. Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value. But if you're purchasing something for under $100, I think it's acceptable (and third-parties may not want to deal with small tx, anyway). I don't see how that solves anything. If Alice wants to buy something from Bob for 10BTC, and Alice doesn't trust Bob to deliver and Bob doesn't trust Alice to pay, how does "the network" decide if Bob has delivered or not to know whether to sent the money to Alice or Bob? If Alice is "lazy", then Bob might have to wait until the contract n-locktime expires to get his money, which might be a long time. Worst case if the tx can't be finished without both parties signing it, then if Alice is lazy Bob might never get his money, and if Bob is crooked then Alice can't get her money back. You're missing the point. People buy stuff all the time, from other people they don't trust over the internet. But for many transactions, they do it anyway, and just hope they don't get screwed. This system makes it an order-of-magnitude safer to conduct these transactions. No one gets any money (or gets their risk deposits back) until both parties agree. Both parties have an incentive to complete the transaction smoothly and without issue. It means that the seller can't send some super-shitty/incomplete product to the buyer knowing that he's already got the buyer's money. The buyer doesn't have to send money to some random person on the internet hoping that he's going to ship some potentially-imaginary product. I highly recommend third-parties, but I think it should be possible not to use them. And people who use silk-road would probably agree with me (though I am making no formal endorsement of silk road or drugs in general: just an example of where executing transactions between untrusted parties may be desirable without a third party).
Plus, the benefit of using 2-of-3 is that there's a lower threshold of trust needed for the third-party -- there is no risk that they take the bitcoins and run. They'd have to collude with the one of the parties to do that. All that matters is that they are impartial to the two parties involved.
If you've figured out some magical way to do escrow without a trusted third party to settle disputes, I'd love to hear it, but it seems technically impossible to me. As I mentioned the best you're likely to do is to lock the money up on the blockchain so your third party doesn't need to be trusted to hold it, just to release it to the deserving party. That's really not much better than what's possible now, although it might streamline things a bit. You've missed a critical distinction here: there's a difference between "escrow" and "third-party arbitration." The escrow simply means that the money is held by a third-party that has no partiality towards either of the first two parties, and that there is an explicit agreement about the conditions under which the money will be released. "Arbitration" means that the third party gets involved to solve a dispute, which may involve contacting both parties, and sorting out semi-truths to find out who the money should go to. Typically, third-parties serve both roles. In this case, the bitcoin network can be that third party escrow -- it is holding onto money for the two parties, and has instructions to release it only when there is a distribution agreement (spend tx) that is signed by both parties. You're right, the network can't arbitrate it: but it can be trusted to be impartial and not steal the escrow fund. In many cases, especially early in the multi-sig world, there may not be good third-party services that both parties agree on. In that case, I'd prefer to use the network for escrow alone, than trust that some third-party the seller is recommending is truly impartial ( super-common escrow fraud). As I said before: (1) I only recommened this for small transactions, in which case the third-party arbitration may be more expensive than the transaction itself. In lots of standard transactions, it doesn't even make sense to have a third-party, does that mean that we shouldn't bother at all? (2) When neither party gets the money, they will (usually) find a way to agreeably resolve their own dispute so that the money does get unlocked. |
|
|
|
Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value
Gavin proposal has something like: if Alice is lazy for 30 days, it's the same of ok/agree Etotheipi: what about your proposal? The problem is, I don't think Gavin's proposal works. His proposal relies on transaction replacement, which is not enabled on the network, and he admitted that he made an erroneous assumption about the way locked transactions work. Specifically, Alice can get Bob to put the 20 BTC into one of these transactions, and then Alice just disappears without doing anything -- then after 30 days she gets the money. Gavin had assumed that Bob can replace the transaction, but I don't think it's feasible (at least not without setting up an explicit agreement with a miner, which is way beyond usable in this case). EDIT: and even then, I think the locked tx technically goes into the blockchain, so it couldn't be pre-spent even with a miner's help -- it would be final. However, if an alternative can be made to work with existing, enabled features of the network, I'm open to it. |
|
|
|
Whatever overhead fees are incurred are on the buyer, who is asking for the service. I don't think it's possible to do escrow without a third party, at least not one which would be acceptable to both involved parties. The best you could do would be to store the deposited money to a "virtual address" on the blockchain so that your third party can't just steal the money (unless he's already in collaboration with the seller).
On the other hand, for a proxy-seller like bitmit it might make more sense to escrow the money to a proxy account so that the proxy service can collect their fees as well as guarantee their own buyers against seller abuse. Escrow can't work without at least one trusted third party anyway, which is why amazon is so successful, since customers know they can get their money back most of the time even with an unrated seller.
It's not so clear cut who pays for overhead fees. If you consider credit cards, it's always been the seller. If it's PayPal transfers, again it's the seller. Why not here, too? In the case of Bitcoin, the network can be the third party. That's what the 2-of-2 version is: both parties agree on the terms (that only further agreement from both parties will be accepted) and the network holds it until they're ready for disbursement. Of course, even with good intentions, the death of one party or HDD failure could lead to un-recoverable funds -- which is why I wouldn't recommend it for any substantial value. But if you're purchasing something for under $100, I think it's acceptable (and third-parties may not want to deal with small tx, anyway). I highly recommend third-parties, but I think it should be possible not to use them. And people who use silk-road would probably agree with me (though I am making no formal endorsement of silk road or drugs in general: just an example of where executing transactions between untrusted parties may be desirable without a third party). Plus, the benefit of using 2-of-3 is that there's a lower threshold of trust needed for the third-party -- there is no risk that they take the bitcoins and run. They'd have to collude with the one of the parties to do that. All that matters is that they are impartial to the two parties involved. |
|
|
|
Besides the bulk-import feature missing, has anyone found any issues with the RAM-reduction (0.70) that should make me concerned about merging it into master? As far as I can tell: (1) Linux-64: -- Previous: Required 3+ GB of RAM, super fast -- Now: Works with 0.5 GB of RAM! And same speed if you have the spare RAM (2) Linux-32: -- Previous: Kind of worked with 3.9 GB of RAM if you did nothing else. -- Now: Works! With 0.5 GB of RAM! (3) Windows-64: -- Previous: Worked with 4+ GB of RAM, but used all of it. Fast! -- Now: Works with 1.5 GB, but 2 GB needed if you want it to load in less than 2 min. (4) Windows-32: -- Previous: Didn't work at all! -- Now: Doesn't work at all! Note: "Requires X GB of RAM" means "Your system must have this much RAM for Armory to be usable", not "Armory consumes this much RAM"Does this seem like an accurate assessment? I'm a little concerned about Torus mentioning double-counted addresses, but I can't replicate the problem and it apparently goes away on restart -- and who knows, that might've been there before, too. On another note: Here's my short term priority list: - Bulk Import Dialog (already like 80% done... just have to figure out some input and validation details)
- Address books! FINALLY going to get this implemented
- New Wallet Format! (Compressed Public Keys), (Compatibility with Satoshi 0.7.0 deterministic wallets), (Any-version Satoshi wallet migrate), (Much faster wallets), (P2SH support [preparation])
The new wallet format is likely to take be a HUGE time investment, especially because I have to maintain the old wallet format entirely and start dealing with multiple-versioning. But it's totally worth it, in the long run. |
|
|
|
|
Sorry Donors!
I've been waiting to send out rewards until I got the Tshirts made. After a mess of getting the Tshirts negotiated with ooShirts.com, they delivered the lowest-quality shirts imaginable! The logo is awkwardly placed, and the printing is so terrible it looks like they washed the shirts 30 times before sending them. I have no choice but to return them and start over. Ugh!
If you are waiting on just a USB key, I can send those out. If you are waiting on both, please email me if you'd like your USB key separately instead of waiting for the shirts. I have no reservations about sending out the keys separately.
Thanks for being patient!
-Eto
|
|
|
|
I have posted a complete first-draft of how I would implement buyer-seller escrow if I had to do it right now in Armory. https://gist.github.com/2305966Luckily, I'm not doing it right now, and I think this could use some improvement & optimization. I'll leave the bulk of the content on the gist page, but I have copied the "Things to ponder further..." section below: - Someone had brought up the possibility that only the "loser" of the arbitration should pay, and the "winner" would get their risk deposit back. I'm not entirely sure I agree with this...
- If we can't use SIGHASH_ANYONECANPAY, then one party would have to supply the other party with an appropriate sized set of inputs and a change address, so that the other party can construct the entire transaction before signing. It may require an extra half-step, but also may not be too bad if this step is executed by software, anyway -- it's already producing a PubKeyB to send to Alice... it might as well also figure out an appropriate set of inputs and change address and forward that on. On the other hand, if the tx never executes, Bob just revealed some of his funds to Alice.
- Second-half tx fee could be included on the original amount: commit 28.01 BTC to the 2-of-3 to make sure you don't need extra inputs later just to pay it.
- Client software could integrate third-party services -- so the retrieval and verification steps for third-party, Charles, could be done in the software for you. This may be especially important, because if you do a lot of purchasing online, you may need to advance-register with the third party so that they know who to contact during arbitration...
Message signing may become important here, especially for third-parties... - In direct response to Gavin suggesting that "risk deposits" are awkward and confusing: I don't see a way without it. If Bob doesn't have a risk deposit, he has no incentive to complete the transaction after he receives the merchandise (besides being a good person). If Alice isn't required to put in a risk deposit -- she could have Bob create the 2-of-3 transaction (or 2-of-2!) with her address, and then she backs out and leaves the money stranded. Then Bob will have to pay Charles to help unlock the money. Or if it's a 2-of-2 -- it's just locked forever.
- This process is complicated, but half of it is under the hood. A lot of it can be automated with a "simple" set of options and a well-thought-out interface.
- I think the number one priority to optimize is simplicity/usability at the UI. I don't mind complicating stuff under the hood a bit to make it easier on the user. But I do require a solution that would work without relying on third-party services being available (I think the solution should work for 2-of-2 tx, as well, and let users eat the risk of small tx getting locked).
|
|
|
|
I don't know why http://p2pool.stitthappens.com:8336/patron_sendmany/123 doesn't load for you. It loads fine for me on all the systems I have tried. {"17grYhCyvbBih2Vd5qxWxPxnEmpNLfy2h8": 0.32683335000000002, "1FCx87BboqamhGM7YxQ7fNwrfaWxEWzpfD": 1.79806869, "1PiqTqqHCyxTpZbkWkDB6CrGNmUNHYYvUH": 0.046107719999999998, "124s42PCAJHhskBETc1CTs5ch9qbbfkuqE": 1.488434, "136ZCnRtWjS4xDPZWAJhLrHHzP68mayq8r": 0.25952874999999997, "1QG6unNskfdjNA557Jc9aegpRZBWbEWMuX": 0.78374562999999997, "1J3rEQJZXYBdJxA1f7UuQzbVwzdKBMaHX3": 0.98840163000000003, "15zXXDuhFkz2a5MSrC9VKz4UemGgQdsM7T": 0.09861702, "12JDBRw5YYMRBgeUuqiak1FkYoeGVHt5sM": 1.2461039, "15P281GsBdjZLcgVaK4TEWzVEV4MZ2WKK4": 0.15079606000000001, "1EHeT5A86SNJzisxdi64GkarzBWKNtFwzT": 1.14850908, "1GJwv8JRCzQyPtpFWWPMoZM8AE4nCUib7E": 0.14174373000000001, "1ZuDojE1tJb1WutQpSeskFD2coKejBrwz": 0.032062399999999998, "1DijdLctKanHmZ4QazDwLeCo29coGrJVxS": 0.13563022, "1Dzt8dVzTTb44tmymKpkYNeXpPCjY3sGs7": 0.019047870000000001, "1JyYwUkTSMxtgZ3KAiR2GXRBTCu8n85n11": 0.16656689999999999, "1MX9zsPeR8p97qYCbJLmdLxkjtDxjFTfHi": 0.17415987999999999, "1BW6LFXb7rcDt5KDtZgEHQERJhi9HNzN4L": 0.38236838000000001, "14dSKs2F3m2ySnVmxvGgYrfxyBDntziMWJ": 3.6916757499999999, "18cfVDzcLQ91Xe4yGEs8uJFtHZUiZhmdks": 3.73907816, "1LrpuyebMYzQEx6fW8Bj2vuzc1pNFiTMVn": 0.049987499999999997, "1FGNrRbpWkqwYz9rWXR8UD2boHVfkLgeQg": 6.3440144399999996, "1BATjg86rX4dsyKN8Pos38k7Wwyd9e4DZC": 0.050773409999999998, "1JdeEhBysSSD5byexAn9CiF3LwFqsszuFd": 0.30087311999999999, "1MSMgQEKsANqaXGVALuzPWqNDu46KR5zit": 2.4480455399999999, "1DpJ9tfVotdAXc2FKfUDRJhHLP72hzBtQ4": 0.18411242, "181ikEekqoCNv4X1AFYG3fHKvdr86osAds": 1.1453341699999999, "18meRyxbZJZtENbhWeMt9htFGBTMaxqYf5": 0.26550655000000001, "18Ppo3w3y8Tm7mR1q8X2drWM2kgCHMWe4s": 0.12597876999999999, "13FQPYwvrXjWvxyzu9ZpiQsU4gaGECEQQ2": 1.1971634600000001, "19dxo1DGBfAWas3RwDMXmCZoU5RrG5SJvD": 0.29243649999999999, "1JLPBMD9mXSku7ydTo43T7gthBmppmYS7c": 0.44912273000000003, "12WDm9D12hqFaYMyVYQuiHBB6i2NCwbsct": 1.8055881899999999, "17W19K1hkAprwrTLZpdna1YaCxNi6eVWv7": 0.095049910000000001, "1Mc6ZGHuFrfrGmSwGowdo8MuKsRa39hdXk": 0.34660303999999997, "193iRjtJA6wLQa21bHUr3bURFNt8uSBwDy": 0.49820013000000002, "1LCK9u5xwrZt6iJeFXwkKVJXGSdYVL2W9u": 1.5166582099999999, "1JEBKvgRCdsi6zZoCmh9YjPRcEM5gi37z5": 0.51340299, "1KWzyAheTyj885VxAy2uwrsixgQg22eKkn": 0.12163108, "12B16qZLAnC4vHBc2LeuXtJqwjxLM71b77": 0.028828570000000001, "1EXyV8iH27d9HCr7JYjiLTdzT5EBuSLTSZ": 0.069424079999999999, "1DaJngVdmmj7y4rnGJKriRta6aXTNtsphS": 1.5183295699999999, "1Pt1UdXPS4oEirMWB6iLVVqLHwkzxxjJPY": 0.064851829999999999, "17EW37vFxcS3Ku88Az6fuQEFEScE1aimpL": 0.050003409999999998, "1LLU5ioNyg61VWSe4wQz8wHog25brseHpe": 0.61280701000000004, "1Lh4drRAVG3NToe3wNAgvHVT6rhB8LCvAg": 1.1183695499999999, "18cFy1XcwZvNPqZou82ydtod6r91v6dk5K": 0.01670224, "1N9mMCgV1CzU3s8Kvf7BcQhBBXGgoo9Wx1": 0.095788090000000006, "1CpU1PtAf5ACADuBJMZGS2tNTghVvP4h83": 0.030400389999999999, "1CmY7ySLrRx8TGfV464oj7T2uKdMhrARGW": 0.15620983999999999, "153B6PKQa3UaeSir8juvtg2Err7xVgz6UD": 0.082439789999999999, "1Gf2o55nnXnTqUBVqrR1MrBbhnfhHKca7m": 0.060556449999999998, "131Ujny1eg63TPeGY9oEUvNKMJ83APwdPQ": 0.93913420000000003, "1Grx6kPbWCwZVJfi6rxDkw3nZbY4d7wdj2": 0.25323181, "1BaqV4pr2JxAcwhkhnQZHJpfZTpKzJkZqd": 0.68058025, "1bBPTBJ5pVURnx6m8a1rfyogY4AeguAGr": 0.062172850000000002, "131gxBzWNjGe82kMyTzg3sV2gYW2VqjtJb": 0.1110558, "1B2BtosV8nsa5VP2vSaqgXb1bevgsT7aWG": 0.19502084, "1Pjx2Vxy5XoBAX3K28NhAkjrYpgm3CDYcj": 1.21450339, "1JxTaLoF5ya5xU4DVgnXF6A2h1AYtGeivn": 1.5630012, "1ACcXAnKwCR1N8qFEf435X9guEg4htSCbW": 0.17789262, "1JXRDPMcjeH11xKJPYhDUp19cCvwP6Dby5": 2.4368074399999999, "1L9WRN2rj4JVzu1312jWwHoF7ajR2v6oSM": 0.41428831999999999, "1s3ivQBkK8iYgpRHtwoWcCjyEFoNyK1Lu": 0.080453230000000001, "1N5T1NCTqpsdNzxwb1K7nRwZxpv6vU3iPt": 0.015679470000000001, "19mJovhF6qSYKf1FpaKVtvEbi8UjkNF2AW": 0.20859479, "145PvHRXZckfMKrGnLWG9C5g2zpscmZpqu": 0.21248919999999999, "1DVvLLe8HJvpLtZ46mCGWBiaiqyDgok1pV": 0.34440563000000002, "1EKNW9tir5rKMgmoH6YMA9V6TS2urYoqZB": 0.50206691000000003, "1LWkDUVtMVUvgojDhhqDfuGu8YJCv7p2dn": 1.5128814100000001, "1AAAA1inoADZAF6wJtrvcZLT2nVwt5Zzuo": 0.62393407000000001, "1JWPU7RC84YgyBUoEdFQgEz2Du6Rv1m7iD": 0.08290575, "1KFVbio6bMJagvPsKE6u1MebXdfxWV7Ucj": 0.19292090000000001, "1P2PooLtMyykv6PiRMycPz8KtMZPpnABZf": 2.8483544200000002, "1qb4D8vXnTi1odqDFxWw2yjxYVeywrurf": 0.66392516999999995, "1NPucNnkyxy2jaFSzMvWhTWByzUZBkX6oF": 0.83157002000000002, "194LBZHndpufr8w7iNkbfaGy2Rnwav2JFu": 1.08397772, "1HaKyN85Dt1kah5bwCWPGmhYj8GYWo4LEP": 0.45889120999999999, "1DTMdX6WBtwouiQ1wKMxycrod8PonWEgCc": 0.017439340000000001, "12AEGVu3PNJ37fVbMBnhL6mCv1YmTjF74z": 0.31492215000000001, "12WxpZXFCKc4fQVUqM4LpejUo3JFdTgzu6": 0.48975418999999998, "1FzHpVtMNPaDND9ymkp9kdm9wASDBqzzmg": 0.23416871, "1GQ18JvZvEKj4iwj9MTzHZsmyTD59b9XVD": 11.395968999999999, "1GhKMLuf8h6gc5iWj52Znr6u33NQENU4yU": 0.28066297000000001, "18Dy2ZG145Uk5cUKAa8MLMeoKZpkr3nc4": 0.20692292000000001, "17iHfDET84WbbfE6P1XKjxxoqGRah4vTSo": 0.24444316999999999, "12XhuZutPqEzhH1vJgCizoRCjmjbCme4M1": 0.83645069999999999, "1FoLobZYSNEUCadHGLUc6MJPmABhBNL8sj": 0.13384244000000001, "1Bb6SwgyCDaCSahFE6NvjPsexhd4RR1fbV": 0.21969156000000001, "17Hh9HsJseYGHuEVy6eHZDM5VXesjisyUg": 0.20485354, "1N6KMP6PwaZYVhXHEh9FTqDrWUjUuboSsX": 1.14739444, "13371MhPYMBFE4t7Qz9W7onyaoGVxfPy3e": 0.032698860000000003, "15KfkCQeuvgqW86HEbSjk2t6oXuBGoETGE": 0.034017609999999997, "1FoLjGcHFekHWcXxcja6C7SKNGNVc3rYZH": 0.75578639000000003, "1MGv7AXXi4scXQ14mb76Xh74Xtsh68FvUA": 0.66073006000000001, "1Atjku5MyT81ZvPeY43HnVmLfNGbgELXSK": 0.014885270000000001, "1EeNkR3VPihwHCGt2VKSjJHetiKHZt9U1e": 0.56586316000000003, "1KkWB4VpBne3xrFjpyA9xpogdUn3cgJN44": 0.32223544999999998, "1BhGxCFmRcASHGJwkCKAUUZ7eiPqHHcCsN": 0.25943421, "1PmEersThWjzvS9cGKZPY7rRt8FFfy4uHJ": 0.14869098, "1DoRtw4dxNeb2mDPHhDfcbYhKKsogubghR": 0.083360450000000003, "1wh57wTZ3uB1W2jg1CVM7c3SBpQuVczjQ": 0.18176753000000001, "1MgH8iNkdZrDW8rsfzifDzsqJnCjBVyRBV": 1.1631248599999999, "13CeFWqdqKRXqvXaSureKFdcruJddSAyD6": 0.075015029999999996, "1BUHXhwmDNacsaM5kyvkwqNfGc8Zrx9BAH": 0.52496087999999996, "1FscgYWAunWHVWU7CGWHK6LYdUbyEDsEWK": 0.50896947000000003, "1QCnJU2qK1ufNouQoEqRhuRkbWU1Qpo2uw": 0.54272465000000003, "1D5kUo1PrgCwzhbSNGf8zQqRQdDwwtUm5u": 1.83324793, "14QQRahvy248GNPyHmyAb3tQHv857fscGz": 0.21108052999999999, "1H7RTSZGoRNwfSWsAMgqxYM8BGR4aCfZsB": 0.35661224000000002, "1JiSZHyCQd7Y7j3EzcRKusYgs2Uw9ALefU": 0.080857369999999998, "1JyVDwMXWYfsrEAMqCjAsRY8e4Ttdm3Zwy": 1.6709407300000001, "1CaBGStSxZoQSgWsJEEAtorhfsdgFtJn6s": 0.016388460000000001, "1HEVSgVfPF7hXtcPTXzSSDyMj2zwajHuwJ": 0.24490249, "1KcmjWZdcYf5xxvqqamf1SE37JoRtWnQVT": 0.032580289999999998, "1GumnfaYT9bn7EmFodZqg4f5JVF8UB3D4e": 0.17985395000000001, "1463AfYwG4bRsUN7QFa15ziTefiwCPtbt6": 0.01377548, "1ACQQVGcxwDMgz5AaptPqyt7H5EA6wFHo1": 0.31138312000000001, "1L7pRa8gUnhaVa5cWMYVWoaHDEZaxSQ1FE": 0.12710168999999999, "12VHbFDMooQabKqRFHvF9QJgeGGTZLFkHB": 0.24679564000000001, "1QETbAYdadAg1A3eznA6Bi1RhFp28iJQyc": 0.21072212000000001, "1D1v1WWwJBNLtnnX8TpLSNB1m9ZChkZKRR": 0.11514301, "1Bry8GxRWKTMbYK1mHK72kHJNXZkpgA3VW": 0.04877008, "1CvHeELVzg1YiBLVNzJXkQMa8Awg8TX3X1": 0.047751410000000001, "1Mf4SBdgeHWP6X7sJyR5T6GG3G9johrZF9": 0.32073985999999999, "14ka1jHDjuuCXKAQEUoAMoUuLW5AtqpbEQ": 0.13470819000000001, "1DtBehvBEPThnqamRCNHYisrdfJX8DjGwC": 0.21595487999999999, "1AVb1PuguzpAL9zpufh5K2cS5C9CWn5U7t": 0.53473850000000001, "1K9Z2GwMLTYRjhcZGCsQvnVRyGjeZzMagA": 0.61321245999999996, "1DMe8xchq6ChFcuJRz9EodHWjmR6ckofqq": 0.30408499, "16LDBNC7Cq6LVd1tLNLRCmrS42Yy8TW6VE": 0.16875287999999999, "1EADvPHFdANzdSd9gyojyLWZowEUeRmnKR": 0.42944356, "1MC57ucFpS31gSbHZx1moBvGo9bCtS4MYG": 0.25308341000000001, "13ieqD6Yikuh5boT5McnTrWFMzBMSTHRV2": 0.20685987, "1Ax95bVEUzrkiATxyUQ8E4bDjzA81PPXkd": 0.063532729999999996, "1obamaWGgrNc3245LvbcwMmF5yVxraGBP": 0.16040473, "1DcvMmC7xsUFnuxZ3CLzuEf2TNXJLYpCAa": 4.0399094299999998, "1P2P3P9kqQZTCYLZEkczNZ3JHXPrmi4q8s": 0.13133246000000001, "1KkE18XYFwpuFv6DF1qcqT17Z8GXtVH8XD": 0.083267279999999999, "1PsjZQMpanz7FWgHxS42ZFG3dEsHi1V2yt": 2.84060757, "1M1TERdxgf65RgSXUarwhN4E8Fcr5nowkS": 0.15966464999999999, "1EjgnC23hE3w1r8hLoWtGBV77X94x6jteA": 0.11100603000000001, "1CgUQn592uSDyVqxShy8Pt2pZ7d9twGK9S": 0.62523834, "15eeGeBaPYrND38X2nWvL8AsfkoyWZjuU8": 0.16598131999999999, "1BVNys6B5v8yeWMZxT1RJWgrcuArikYgA1": 0.86420633999999996, "1JFUE5GNcTqNsJDmXk3DEHJkzvogyJKXzD": 0.064402890000000004, "18Hqop9AsuCcAy8sLFcmSsThB3ZxmhbF7P": 0.048608409999999998, "1GoG64cyycwB1XYv8HB5WqeDL9WZQ1uDkm": 0.061666579999999999, "1DGScEZx18hwiz68rGAuFyxvhjpHAC9jgt": 0.5058279, "14kBJ79AwUrZLB8mMn8saNP6m364agjN11": 0.032514349999999997, "1NieegqpPy7w9stmGAALTVkEtjZ7bka2wb": 0.17415765999999999, "1PZLxijrmHHvf9iFKdLwNy6BeTej8o1enf": 0.39942948, "1PSAvuBRTeQpHgcJcHGt85VkpyPX6RGAxP": 0.14067813000000001, "1PehxSWedW578DyjfTDtuMAQ1Qqbe8omxs": 0.43913120999999999, "13yNMcVmUoK7EadiUhkrLU98qgQ5zEeMT9": 0.13169228999999999, "1NXtmSEZtdunZqf48g6uFhc7dCcMwGDf6m": 0.13438462000000001, "1CdYbiq38Qaah942iZHiRBJGeDpPbzBVnQ": 0.11280332999999999, "1KtBJTggjijy4EEW85RqnVifyeCxGEBjtF": 0.10024421, "1HxWbkCAvCEeVGcLTfLAweS4ECQYvGoE1c": 0.32232654999999999, "1HZY2Bks6HjTXFxXSj8ivhWCnkosypiUxR": 0.62683829000000002, "1HA7QGY9pASpbmhXbpc9XnbEcJ9KoV7Cek": 0.13684049000000001, "14uiReKs54fHvf1iAf66w1f5EVkW6bCy6M": 0.29085032, "1F8g7MumJhYk6pjQPNRAuo5yyGD3y8CWRm": 1.3837234899999999, "1J2wEyfnZoSy2muixTJGMUDck63Z5GkGip": 1.12642251, "1LsRycmTQRnG5joE5vDdVWtd1JXbJP4KjR": 0.66835509999999998, "13JVVCB8qJKJiwDmy7WWtHfs6eQfg9WmD2": 0.30852249999999998, "17n2PjMRMZWsz6fiF9KpQZpLwRDzum7TzV": 0.72040574000000002, "18Vcdk5bPwxk2ffexYR1Qggk968UizCMiq": 0.01636112, "1NtnS4ohrXX1cLgA8tWD1x7uJ7uRhX4mtS": 0.90266177999999997, "14Pu2FYGjZJydzGYZk7hmRhrFnrJcZB2b7": 0.06470339, "1CejMr8rVB42sW8MLKt1zruX4M5WP2TcFa": 0.19319260999999999, "1FaN45fEEPSMMKkqWf3XX4JF77CwkMye4G": 1.26225483, "12ixj2NmGhpGLZ4fnYj4hqbiBJtBqCocMs": 0.30416632999999998, "1QBEZ77TeDA4VEaPjyQ3GamZVDxbfyCdoQ": 0.12998486000000001, "1EaTXKfQY9Uf2SwNxQrpAZUmAvdyQNe8ig": 0.01411197, "1PjpL8dipRjho4dNbHTMjXvzkmFpFtzZn": 0.063725680000000007, "17ovei6YUWA8seKf6PWriunMPxGaVr5UC": 0.01664682, "1BQtFMPqZrtNNBe38oxoFyZTPrHnog4YBh": 0.27907396000000001, "18g2E5aS37X1aTdVDAhNEhUZVhNBZVhR6e": 0.083591170000000006, "1EcEmx5h9d3NGLJdCFdyaNXVbGDrPBmkaC": 0.14713227000000001, "1PaRgvVyJCRq9WAucmso1woXZdrEo5rbHF": 0.15867961999999999, "1D82XnrZquuo51VeFi24hCbHLdxtNfjVet": 0.13700027000000001, "1LYYtm38ypHRguFmxZfjQctwPER8TpEziS": 1.3602825599999999, "1Mdks71WqGBWM55StC2ZpDbYq6Thx1HYFT": 0.92697324999999997, "19yRn7nT4wV67xtpC7wuySBKg1p1kAxMj2": 0.96024039000000005, "1J9Q5CBnvBUWJ2knXC88norDukeZo19bVd": 2.1067746500000002, "1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw": 1.76963469, "1CM5KrYZ1SEfqrSmWenenYiBNp7Av7t13V": 1.30675024, "1G1brDEGCXx3N68GjHkTEkmyk49XJJQEf7": 0.30931089, "1P7dEqWe98wSchyheUyDsC3DtGxmn5ZSUo": 1.5489480099999999, "1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4": 0.36355658000000002, "13Emc6zwk6VK5QtJrxWMN54SmU9Sp5YxnY": 1.7178027499999999, "17aar2dWd4VTK4Wi5kBqV3NyANSw6TV3RE": 0.032831150000000003, "1ERrJWJpNdebeGcu9a4ueUdYr5F2BA7tXR": 0.01735397, "1Hxhyew5cJthaxX1iGi6gKjguaGYHpPoLj": 1.7967216800000001, "1ZorZor89Ls7AaB7TMmkE5ugA4LCH9KX7": 0.078628509999999999, "17HUKL94x6X3FhKSTUq6mbEjqZF6QJUkTu": 0.28061543999999999, "12yBHqKmqZbwJCBWEEVL2djEHPJrSZxAR9": 0.014322110000000001, "14XnW5BK1F2xDcaEP6FZNHdTJAfRkyMR7S": 0.02883196, "169K7XXPHDkmw1PypAfd48yVCcdaxzPbGp": 0.71848171000000005}
The output is a bit long to put into the send gui by hand I see why, now! Amusingly, my biggest problem with this is that I don't use a scroll-area for the confirmation dialog, so I don't even know what that would look like with 100+ outputs! (what happens when PyQt tries to create a 350x2000 pixel dialog?) But, under-the-hood, the capability is already there, and it's trivial to parse that kind of string for it. Seems like a good feature to add to the "Developer" usermode. I'll make a comment to myself about using a scroll-area for the confirmation window, and then I can add that pretty easily. |
|
|
|
I had originally planned to do manual locking and unlocking. With a little lock button on the top wallet-display table. But it seemed like extra work for not enough benefit, so I decided to skip it. However, unlocking does unlock for 5-10 seconds, Armory checks an re-locks if necessary every 3 sec. I could definitely make that parameter configurable.
this  - This is what I'd generally like. Unlock it for settable period, preferably set in the passphrase dialog, so it's set on each open, rather than only globally....maybe a check right there "Make Default" too - make it globally settable. (this checkbox should have a default setting, and not require user interaction beyond the passphrase if change is not desired) This feature will become a lot easier once I finally have a real options/settings/preferences section. Another feature to go in before Beta is done |
|
|
|
Maybe then there's a feature request in there. Users don't realize they don't know their own passphrase until it's too late Also, users may have 2 wallets, one w/known PP one with unknown, and click on the wrong wallet. I'm thinking it would be a good idea to check the passphrase before the first operation on a wallet in each session, just to double check the user still knows it. This might be configurable too, for users that don't care for the check. I'll think about a good way to do this. I like the idea of making sure the user knows their passphrase before letting them dump too much more money into their wallet, but I still want users to benefit from not having to click too much stuff and read message boxes all the time. I guess paper backups are for those that really forget (defend against theft or bad memory). I'll think about it... So to answer your question, it is a feature. I didn't anticipate users not realizing they don't know their own passphrase.
I have a request. I wanted to import several addresses into Armory, and it was a pain because I had to enter my password every time. The Satoshi client has the ability to unlock the wallet for X seconds. If the wallet could be unlocked for the session or for X seconds, it would have been more convenient. The ability to relock the wallet would also be nice. I don't think this needs to be default behavior, or even available to every user level. Also, is there any way to send a transaction with a list like this? http://p2pool.stitthappens.com:8336/patron_sendmany/123I had originally planned to do manual locking and unlocking. With a little lock button on the top wallet-display table. But it seemed like extra work for not enough benefit, so I decided to skip it. However, unlocking does unlock for 5-10 seconds, Armory checks an re-locks if necessary every 3 sec. I could definitely make that parameter configurable. But if all you want is multiple imports... I was working on a bulk-import dialog, but never got around to finishing it before I decided that I should get the 0.70 testing version out the door. Then got distracted by Windows memory mapping. In fact, I was so excited that MMAP in linux worked so well, that I forgot I left that hanging! Thanks for reminding me Btw, your link didn't work. I have heard the term sendmany, but need clarification on its meaning. However, for reference, if you fill out multiple recipients on the tx send dialog in Armory, it will bundle all outputs into the same transaction (and concatenate all the comments together). In other news, I figured out compressed public keys in the underlying C++ library (Crypto++), they're really not bad at all. That's the first step towards being able to import new Satoshi-0.6.0 wallet formats (which use compressed public keys). However, there's a non-trivial domino effect of everything else affected by the new format: blockchain scanning and Armory wallets. I have some upgrade plans for a new wallet format that will better accommodate P2SH and be compatible with the deterministic wallets planned for Satoshi client 0.7.0+ (...? I don't know for sure when they're putting it in). I might just take the plunge and do all these updates at once -- get compatibility, compressed public keys, prepare for P2SH support, and a significant speed boost, all at once! Don't worry, I'll leave the old wallet format in there, so users can keep using the old wallets. You just might have to create a new wallet in order to use any multi-sig stuff. |
|
|
|
Now: Bug, or Feature?- In satoshi client, if the wallet is encrypted, you must unlock it to generate a new address for receiving - In Armory, there seems to be no such restriction I have a wallet (with no funds) that I created some time ago, and don't have the password anymore. It appears that I could send money to this, and then never recover it. This could make me  Is there a reason for it being like this? Guruvan, Since the wallets are deterministic, there is nothing magical going on when you request an address. You are simply getting the next one in the chain. I figured: you can create a watching-only wallet and get an infinite number of addresses without needing a passphrase, why shouldn't the user with the full wallet be able to do the same? I figured that the Satoshi behavior was an unfortunate downside of non-deterministic wallets: the Satoshi client has to create a new, unpredictable private key to refill the key pool, and the only way to add it to the wallet is to encrypt it with your passphrase (which I have to do for importing external addresses [and should do, since I don't want someone planting their own keys in my wallet]). I was always annoyed that I had to type in my passphrase just to get a new address. So to answer your question, it is a feature. I didn't anticipate users not realizing they don't know their own passphrase. |
|
|
|
|
Show Posts
