Hi e4xit,
We just pushed a new update of the app which should now work with firewalls blocking electrum and allowing you to ignore that if you have no alternative.
I need to make some more changes for android and then will push to github both, for now I just updated the chrome store.
Hope this helps!
Topic: GreenAddress: open source multisig wallet service - page 10. (Read 28246 times)
@e4xit
is it possible on your chrome app computer you have a firewall for outbound connections on port 8081 or other ports used by electrum servers?
We have a patch coming for this that in case there's firewall issues allows the user to decide to go ahead anyway and not use the extra checks provided by this extra checks we do.
If is not that I need to check a little more about the version you are running of chrome and the app so i can try to reproduce.
Thanks!
is it possible on your chrome app computer you have a firewall for outbound connections on port 8081 or other ports used by electrum servers?
We have a patch coming for this that in case there's firewall issues allows the user to decide to go ahead anyway and not use the extra checks provided by this extra checks we do.
If is not that I need to check a little more about the version you are running of chrome and the app so i can try to reproduce.
Thanks!
Hi tryexcept,
I am using a work computer for this so entirely possible that port 8081 might be blocked... I will try to run a test for it when I am back at work tomorrow (there must be a website which can check an open port right?)
We are planning to be interoperable with other wallets that support n of m for multiple people authorizing transactions.
We also have implemented subwallets which are currently available via the API and that we will soon add to our UI such that you can create subwallets with any security settings you like including 2of3.
More on this soon!
We also have implemented subwallets which are currently available via the API and that we will soon add to our UI such that you can create subwallets with any security settings you like including 2of3.
Hi 
very nice service.
But are you planning to implement more signature features - like 2 of 3, 3 of 5, etc? I somehow feel that with multisignature it's possible to lose part of key.
very nice service.But are you planning to implement more signature features - like 2 of 3, 3 of 5, etc? I somehow feel that with multisignature it's possible to lose part of key.
I understand your point of view.
Sending a tx is not the best way to test the address, as gmaxwell suggested in a short conversation on irc #bitcoin something better may be signing a message but unfortunately i don't think it is the most user friendly way.
You can reuse addresses in our service and it wouldn't be any worse than reusing addresses in other services, in fact, because of multisignature and deterministic signatures it is better but we still prefer to discourage things that may ruin your privacy or security where possible.
Is there something we can do to improve your experience but at the same time avoid impacting privacy and security?
We could have a settings option that shows you the last one at your own risk such that you don't have to find it in the list.
Conversation below for reference:
Sending a tx is not the best way to test the address, as gmaxwell suggested in a short conversation on irc #bitcoin something better may be signing a message but unfortunately i don't think it is the most user friendly way.
You can reuse addresses in our service and it wouldn't be any worse than reusing addresses in other services, in fact, because of multisignature and deterministic signatures it is better but we still prefer to discourage things that may ruin your privacy or security where possible.
Is there something we can do to improve your experience but at the same time avoid impacting privacy and security?
We could have a settings option that shows you the last one at your own risk such that you don't have to find it in the list.
Conversation below for reference:
Quote
(15:23:50) GAit: User wants to test address with little amount before sending big amount vs HD service defaulting in not reusing addresses so making it multple steps to go find old addresses. User has reasonable points. https://bitcointalk.org/index.php?topic=521988.new;topicseen#new - What is your opinion?
(15:24:51) gmaxwell: GAit: this isn't a reasonable point. If an address works once thats no guarentee that it'll work in the future... or at least not any _less_ of a guarentee that a hd wallet will work.
(15:25:58) GAit: gmaxwell: a reasonable point of view maybe, i can see where he comes from. Perhaps the user should think less of addresses and more of entities but he has learned to not immediately trust services which is reasonable
(15:26:34) gmaxwell: yea, I see where he's coming from, but it's oversimplified.
(15:27:17) GAit: it is, and it will take a bit of time for HD wallet to make a dent
(15:28:03) gmaxwell: A better test in a signed message but there is as of yet no multisig signmessage.
(15:24:51) gmaxwell: GAit: this isn't a reasonable point. If an address works once thats no guarentee that it'll work in the future... or at least not any _less_ of a guarentee that a hd wallet will work.
(15:25:58) GAit: gmaxwell: a reasonable point of view maybe, i can see where he comes from. Perhaps the user should think less of addresses and more of entities but he has learned to not immediately trust services which is reasonable
(15:26:34) gmaxwell: yea, I see where he's coming from, but it's oversimplified.
(15:27:17) GAit: it is, and it will take a bit of time for HD wallet to make a dent
(15:28:03) gmaxwell: A better test in a signed message but there is as of yet no multisig signmessage.
i wont send more than 100 BTC to an address that i have never tested before , and i think not i am the one
so when i am trying a new wallet service :
1, send only 0.1 BTC to the wallet
2, send another 0.01 BTC to the wallet to the same address
3, send back 0.1 BTC to my currently used wallet (testing the other way)
4, after everything worked , i will send 10-1000 BTC to the new wallet (same address)
@e4xit
is it possible on your chrome app computer you have a firewall for outbound connections on port 8081 or other ports used by electrum servers?
We have a patch coming for this that in case there's firewall issues allows the user to decide to go ahead anyway and not use the extra checks provided by this extra checks we do.
If is not that I need to check a little more about the version you are running of chrome and the app so i can try to reproduce.
Thanks!
is it possible on your chrome app computer you have a firewall for outbound connections on port 8081 or other ports used by electrum servers?
We have a patch coming for this that in case there's firewall issues allows the user to decide to go ahead anyway and not use the extra checks provided by this extra checks we do.
If is not that I need to check a little more about the version you are running of chrome and the app so i can try to reproduce.
Thanks!
Hello,
I am not sure I understand exactly your issue, can you help me understand it better?
Let me start from saying that unlike other wallets generating new addresses in GreenAddress does not require manual backup as the wallet is deterministic.
On top of that, it is the norm in bitcoin security and privacy to avoid reusing addresses.
Last, we don't automatically show an address as you may wish to receive bitcoin via paper wallet scan or by manually sweeping some keys as opposed to provide someone with an address.
If we generate the address anyway and that is not distributed it gets wasted, on the other hand there is no way for us to know once we display it if it is ever given out as it can be used later for what we know and by default we avoid but not prevent address reuse.
What is the actual need or issue you suffered? You can reuse addresses but we do not do that as a default as it is bad for both your privacy and potentially security.
For more details you can see this blog post http://blog.greenaddress.it/2014/04/30/reusing-addresses-is-bad-mkay/
Hope this helps!
Thanks!
I am not sure I understand exactly your issue, can you help me understand it better?
Let me start from saying that unlike other wallets generating new addresses in GreenAddress does not require manual backup as the wallet is deterministic.
On top of that, it is the norm in bitcoin security and privacy to avoid reusing addresses.
Last, we don't automatically show an address as you may wish to receive bitcoin via paper wallet scan or by manually sweeping some keys as opposed to provide someone with an address.
If we generate the address anyway and that is not distributed it gets wasted, on the other hand there is no way for us to know once we display it if it is ever given out as it can be used later for what we know and by default we avoid but not prevent address reuse.
What is the actual need or issue you suffered? You can reuse addresses but we do not do that as a default as it is bad for both your privacy and potentially security.
For more details you can see this blog post http://blog.greenaddress.it/2014/04/30/reusing-addresses-is-bad-mkay/
Hope this helps!
Thanks!
i only want to receive bitcoins
1, i went to Receive Money tab , no addresses and no generate new address button
2, ok then try "show uri and addresses" button --> ohh a new address shown (my first address)
3, logout , login
4, i went to Receive Money tab , no receiving addresses shown , wtf?
5, ok then try "show uri and addresses" --> ohh and i got another address wtf?
? new address? i clicked on "show" not generate , (there is no generate new address) i generated 4 addresses (with the show button) before i noticed that my addresses can be only seen when i click "show previously generated addresses" button --> this is a very bad UI (user interface)
why the "show uri and addresses" button generates address , and not only showing the last one? this is very bad UI too
i think you should reconsider this misleading UI
Hi, I'm loving the chrome app for this (and can't wait for an iOS version to arrive, hopefully soon!), but I do have two questions to ask...
The first is about the NLockTime thingy... How can I (provably) tell if my funds are in an NLockTime state? Does some information exist on the blockchain or something? Sorry if this is a silly question but it just seems that currently I am just taking your word for it when I switch the toggle in the settings panel...
Secondly, how can I check which address my timelock funds are set to be sent to at expiry? Also, is ti possible to change this address (I suspect not)...?
Thanks
EDIT: Also would liek to ask about the chrome app: I don't seem to be able to send using it? The app just hangs before it gets to the 2FA screen (which it can thankfully reach from my iPad).? Any ideas how I can get sending to work on the chrome app?
Thanks again
The first is about the NLockTime thingy... How can I (provably) tell if my funds are in an NLockTime state? Does some information exist on the blockchain or something? Sorry if this is a silly question but it just seems that currently I am just taking your word for it when I switch the toggle in the settings panel...
Secondly, how can I check which address my timelock funds are set to be sent to at expiry? Also, is ti possible to change this address (I suspect not)...?
Thanks
EDIT: Also would liek to ask about the chrome app: I don't seem to be able to send using it? The app just hangs before it gets to the 2FA screen (which it can thankfully reach from my iPad).? Any ideas how I can get sending to work on the chrome app?
Thanks again
Hi, I just created a greenaddress.it wallet and played around a bit, overall I am quite impressed with the concept and its execution. Just a few thoughts:
1) nLockTime for user refund is nice and all, but the time-locked refund tx is only provided after the new incoming tx has been broadcast, so your nLockTime solution does not protect me, if for example, if I receive a payment in a state where greenaddress.it keys have already been lost, for example. Of course this is the way the service has been designed, so I'm not sure if there exists a solution. Have you any thoughts about this? Is there a way to design a payment protocol perhaps such that the sender only signs the inbound tx after the nLockTime tx has been provided to the recipient?
2) Micropayments. I notice that the way micropayment channels are set up is very similar to how greenaddress.it works. I wonder if you have given any thought to integrating a micropayment system into your wallet? I have been waiting to see a real solution for receiving off-blockchain, zero-fee transactions which doesn't require the sender to have an account with any specific third party like Coinbase for example.
Good luck with your service!
1) nLockTime for user refund is nice and all, but the time-locked refund tx is only provided after the new incoming tx has been broadcast, so your nLockTime solution does not protect me, if for example, if I receive a payment in a state where greenaddress.it keys have already been lost, for example. Of course this is the way the service has been designed, so I'm not sure if there exists a solution. Have you any thoughts about this? Is there a way to design a payment protocol perhaps such that the sender only signs the inbound tx after the nLockTime tx has been provided to the recipient?
2) Micropayments. I notice that the way micropayment channels are set up is very similar to how greenaddress.it works. I wonder if you have given any thought to integrating a micropayment system into your wallet? I have been waiting to see a real solution for receiving off-blockchain, zero-fee transactions which doesn't require the sender to have an account with any specific third party like Coinbase for example.
Good luck with your service!
Hi, there are network fees but GreenAddress does not charge for any usage of the wallet.
We will only change for some premium services and promptly tell the user if so.
See below cut and paste of the article
We will only change for some premium services and promptly tell the user if so.
See below cut and paste of the article
Quote
tl;dr Reusing bitcoin addresses has both security and privacy consequences and should be avoided, especially since services and tools that don’t reuse addresses are available and even easy to use.
First what do we mean by “address re-use”?
In general we mean sending, ever, more than one transaction to any specific bitcoin address.
Specifically what you want to do is to prevent having funds sent to an address after any bitcoin has been spent that were addressed to that same address. Technically receiving two transaction on an address and then spending is OK but receiving, spending and receiving from an address in this order is not. The easiest thing to do is not reuse, especially since you can’t easily synchronize with parties which may pay you after you spend from an address.
Yet, a lot of people are reusing addresses over and over and over, mostly because they don’t know better and, most importantly, reusing addresses is the default option in the tool or service of their choice.
From a privacy standpoint it should be clear why this is really bad: people that have your address can see your past and future transactions and track you and also, by making yourself more identifiable you’re making it harder for everyone else to use Bitcoin privately. Poor privacy is infectious.
If you ever pay someone that also uses a public address, like a gambling site, everyone that knows that you control that address will also be able to know you gamble, when you gamble and who you gamble with which may not be something you want people to find out or even phantom as a possibility, yet is trivial to do, as the bitcoin public ledger, the blockchain, is, duh, public.
From a security standpoint it’s not obvious why it is better to not reuse addresses but there are two components:
Not reusing addresses can protect you from a weak random number generator or buggy ECDSA implementation (see what happened on Android with their RNG)
Not reusing addresses protects you from quantum computing
A reasonable question/answer about this topic is on bitcoin.stackexchange.
Historically reusing addresses has also been practiced for two main reasons:
Simpler to reuse, both from user and developer implementation prospective (and most people don’t know yet about bitcoin, that this is even an issue or how to track you)
Every time you ‘create’ a new address you must also create a new private key and with that comes responsibilities such as making backups of the new private keys each time a new one is created. This is no longer an issue if you use a deterministic wallet
How to solve the issue? People should be made aware of the problems associated more clearly and services and tools like Mycelium and Blockchain.info or even Bitgo, which are relatively famous tools/services that do at least some address reuse by default , should really avoid reusing addresses before more users are harmed.
Users that don’t want to wait for these service or tool providers to catch up and update can use services like GreenAddress, which never reuses addresses, uses a deterministic approach and provides true per-transaction two factor authentication via multisig.
Feedback is welcome!
First what do we mean by “address re-use”?
In general we mean sending, ever, more than one transaction to any specific bitcoin address.
Specifically what you want to do is to prevent having funds sent to an address after any bitcoin has been spent that were addressed to that same address. Technically receiving two transaction on an address and then spending is OK but receiving, spending and receiving from an address in this order is not. The easiest thing to do is not reuse, especially since you can’t easily synchronize with parties which may pay you after you spend from an address.
Yet, a lot of people are reusing addresses over and over and over, mostly because they don’t know better and, most importantly, reusing addresses is the default option in the tool or service of their choice.
From a privacy standpoint it should be clear why this is really bad: people that have your address can see your past and future transactions and track you and also, by making yourself more identifiable you’re making it harder for everyone else to use Bitcoin privately. Poor privacy is infectious.
If you ever pay someone that also uses a public address, like a gambling site, everyone that knows that you control that address will also be able to know you gamble, when you gamble and who you gamble with which may not be something you want people to find out or even phantom as a possibility, yet is trivial to do, as the bitcoin public ledger, the blockchain, is, duh, public.
From a security standpoint it’s not obvious why it is better to not reuse addresses but there are two components:
Not reusing addresses can protect you from a weak random number generator or buggy ECDSA implementation (see what happened on Android with their RNG)
Not reusing addresses protects you from quantum computing
A reasonable question/answer about this topic is on bitcoin.stackexchange.
Historically reusing addresses has also been practiced for two main reasons:
Simpler to reuse, both from user and developer implementation prospective (and most people don’t know yet about bitcoin, that this is even an issue or how to track you)
Every time you ‘create’ a new address you must also create a new private key and with that comes responsibilities such as making backups of the new private keys each time a new one is created. This is no longer an issue if you use a deterministic wallet
How to solve the issue? People should be made aware of the problems associated more clearly and services and tools like Mycelium and Blockchain.info or even Bitgo, which are relatively famous tools/services that do at least some address reuse by default , should really avoid reusing addresses before more users are harmed.
Users that don’t want to wait for these service or tool providers to catch up and update can use services like GreenAddress, which never reuses addresses, uses a deterministic approach and provides true per-transaction two factor authentication via multisig.
Feedback is welcome!
You should post an excerpt so more people click and read the article. It's actually informative and well-written so I think many users will benefit from it.
Just a quick question - when using the "sweep" function - are there any fees?
Just a quick question - when using the "sweep" function - are there any fees?
Let us know what you think after you try it and what you'd like improved ! 
Great conept! I'll give it a try!
We used to support qrcode scanning only for Android, now we support iOS safari and all other browser that support it.
http://blog.greenaddress.it/2014/04/07/ios-bitcoin-and-qr-codes/
Cheers!
http://blog.greenaddress.it/2014/04/07/ios-bitcoin-and-qr-codes/
Cheers!
thanks for the suggestion and sorry for the confusion.
I have not tried Cryptsy, will have a look
I have not tried Cryptsy, will have a look
poordeveloper:
Correct, that's nothing more than picking whether the fee will come out of the amount you are sending or from the reminder in your wallet.
It's probably not a particularly useful feature and I'm not sure whether it should stay as it may confuse some users.
What do you think?
At first, I must say I was a bit confused - at first I thought maybe it was a new protocol feature I hadn't heard about until now (I've been out of the Bitcoin world for a month of so... and things change fast). It took me a while to actually see that no such feature exists in the protocol, and so this should mean whether the fee is included or not in the amount to be sent (but still I wasn't sure - I could even think you implemented this system for payments to GreenAddress users, since normal Bitcoin TXs don't have this option).Correct, that's nothing more than picking whether the fee will come out of the amount you are sending or from the reminder in your wallet.
It's probably not a particularly useful feature and I'm not sure whether it should stay as it may confuse some users.
What do you think?
With this option, I'd add the data in a table, like the Cryptsy withdrawal forms do.
I'd clarify this in the options themselves (Me/Recipient), with a tooltip maybe.
Jump to: