Pages:
Author

Topic: Miners: Time to deprioritise/filter address reuse! - page 7. (Read 51830 times)

legendary
Activity: 882
Merit: 1000
As I said, you cannot do some changes to a billion dollar related project just because you think it's correct. The side effect may kill a project before you see any positive effect. That's why backward compatibility is so important in software industry.
legendary
Activity: 1002
Merit: 1000
Bitcoin
newbie
Activity: 27
Merit: 0
Quote from: AtlasONo

: What makes it "horribly insecure" ?

A permanent  list of addresses and times is created for that physical location.

Imagine a customer is careless and visits daily , using a address with other large transactions. That high value wallet can be ambushed.
hero member
Activity: 551
Merit: 500

What merchant uses a static address for all customers?  Horribly insecure and prone to problems.  Anyone that foolish should just use a service like bitpay and have it done right by someone competent.


Just about every in person retail merchant I've ever seen.

Quote from such a merchant "I like taking payments directly versus using a third-party processor like BitPay or Coinbase because it is more in the spirit of bitcoin. Why fill out an application and give up all your personal info when you don't have to? Bitcoin is your money." Is bitcoin our money or is it the miners money?

What makes it "horribly insecure" other than having the transactions visible?
sr. member
Activity: 303
Merit: 250
But isn't that the exact point? That it would start to be a hindrance to merchants so they'd stop reusing addresses?
Just thought of something... how does the BIP32 protocol addendum limit the usable address space based on whatever seed is generating the string of future keys? Reading the wiki pages now, will edit this post if i find an answer.

What do you mean limit the usable address space?  There is no change in the number of possible addresses.

For some reason I was thinking that using a seed->prng, and sequential nonce would end up with a subset of the 2^160 (#?) key pairs.

If the entire world economy used a new key pair for every digital transaction (the rate of which is increasing exponentially) for the next 50 years... where would we end up in terms of collision probability? I dunno, i think i'm way off topic here. We can let this sidebar fall away now...
sr. member
Activity: 360
Merit: 250
It's not just discourage as you think, it's forbidding in some scenario. If a merchant use a fix address to receive payment , it can only receive 6 payments per hour. Basically makes the service useless. It's customers have to wait forever if there're more than 6 payments per hour.

What merchant uses a static address for all customers?   Horribly insecure and prone to problems.  Anyone that foolish should just use a service like bitpay and have it done right by someone competent.


See, e.g., the Subway shop in Bratislava, Slovakia mentioned above, and at http://www.reddit.com/r/Bitcoin/comments/1qrp1h/subway_accepting_bitcoins_in_slovakia_bratislava/ and also the discussion above around non-profits and other entities wishing to conduct transparent finance on the blockchain.

donator
Activity: 1218
Merit: 1079
Gerald Davis
But isn't that the exact point? That it would start to be a hindrance to merchants so they'd stop reusing addresses?
Just thought of something... how does the BIP32 protocol addendum limit the usable address space based on whatever seed is generating the string of future keys? Reading the wiki pages now, will edit this post if i find an answer.

What do you mean limit the usable address space?  There is no change in the number of possible addresses.
sr. member
Activity: 303
Merit: 250
But isn't that the exact point? That it would start to be a hindrance to merchants so they'd stop reusing addresses?

Yup.

Just thought of something... how does the BIP32 protocol addendum limit the usable address space based on whatever seed is generating the string of future keys? Reading the wiki pages now, will edit this post if i find an answer. I understand this might be nonsensical.
donator
Activity: 1218
Merit: 1079
Gerald Davis
It's not just discourage as you think, it's forbidding in some scenario. If a merchant use a fix address to receive payment , it can only receive 6 payments per hour. Basically makes the service useless. It's customers have to wait forever if there're more than 6 payments per hour.

What merchant uses a static address for all customers?   Horribly insecure and prone to problems.  Anyone that foolish should just use a service like bitpay and have it done right by someone competent.

member
Activity: 116
Merit: 10
Apparently no restriction should be done before the clients supporting convenient solutions to avoid address reusing. Otherwise you are trying to kill BTC rather than helping. Please spend more efforts on clients instead of mining softwares. No project will succeed in going to mainstream try to piss off users just for pleasing some genious developers who think they have better vision of the future. BTC now is no longer the toy of developers as the early days. You are dealing with billions of people's money now.

This patch isn't designed to restrict, it is designed to discourage.
It's not just discourage as you think, it's forbidding in some scenario. If a merchant use a fix address to receive payment , it can only receive 6 payments per hour. Basically makes the service useless. It's customers have to wait forever if there're more than 6 payments per hour.

But isn't that the exact point? That it would start to be a hindrance to merchants so they'd stop reusing addresses?
legendary
Activity: 2282
Merit: 1050
Monero Core Team
No...

Options 2 and 3 are more like "I don't really want to pay for a security system, but if people are going to start burgling my house, I want one."

FWIW, I personally am in the "We should have waited longer, but I guess it needs to move forward now." boat.

Which is why I do not like options 2 and 3. Why? Because there may not be enough time to install the security system before the house is burgled. Option 4 is more to my liking by the way. One thing to note is that the proposed payment protocol will address the many of arguments against what is being proposed here.
legendary
Activity: 2576
Merit: 1186

You're an idiot, don't do this!   - 59 (36.6%)
I don't like this, but I agree we need to move forward with it.   - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now.   - 19 (11.8%)
Great, it's about time!   - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP!   - 35 (21.7%)
If it's from Luke, it can't be any good.   - 11 (6.8%)

I read the poll more along these lines. Opposed: 43.2% In favour with varying degrees of support: 56.5% Rounding 0.3%. There is a fair degree of support for this. We must also keep in mind the following


i coloured it because for instance
saying "i dont like this" 14 (8.7%) means literally i dont like this.. in other words NO
saying "we should have waited longer" 19 (11.8%) means literally i dont want this to be done yet.. in other words NOT YET

but both questions are worded to then subtly suggest they agree to implement it. these type of questions are called trick questions.

EG if i said "do you hate termites" and you chose
1) i dont like them, but i agree we to live along side them as they are living creatures

great using that answer, you have agreed to allow me to deliver 500,000 termite larvae to your house as you seem to be ok with it.


To quote the termite example. It is more like I am not ok with allowing you to deliver 500,000 termite larvae to my house; however if you do I will not call the exterminator even though the termites will demolish the house. The trouble with saying "no but" is that more often than not it means "yes".
No...

Options 2 and 3 are more like "I don't really want to pay for a security system, but if people are going to start burgling my house, I want one."

FWIW, I personally am in the "We should have waited longer, but I guess it needs to move forward now." boat.
legendary
Activity: 3430
Merit: 3080
Apparently no restriction should be done before the clients supporting convenient solutions to avoid address reusing. Otherwise you are trying to kill BTC rather than helping. Please spend more efforts on clients instead of mining softwares. No project will succeed in going to mainstream try to piss off users just for pleasing some genious developers who think they have better vision of the future. BTC now is no longer the toy of developers as the early days. You are dealing with billions of people's money now.

This patch isn't designed to restrict, it is designed to discourage.
It's not just discourage as you think, it's forbidding in some scenario. If a merchant use a fix address to receive payment , it can only receive 6 payments per hour. Basically makes the service useless. It's customers have to wait forever if there're more than 6 payments per hour.

Eligius are only testing this out. It's only one pool. It's not absolute, just preferential. Mining Dynamics 101. Find. Read. Learn. Understand. Shush.
legendary
Activity: 882
Merit: 1000
Apparently no restriction should be done before the clients supporting convenient solutions to avoid address reusing. Otherwise you are trying to kill BTC rather than helping. Please spend more efforts on clients instead of mining softwares. No project will succeed in going to mainstream try to piss off users just for pleasing some genious developers who think they have better vision of the future. BTC now is no longer the toy of developers as the early days. You are dealing with billions of people's money now.

This patch isn't designed to restrict, it is designed to discourage.
It's not just discourage as you think, it's forbidding in some scenario. If a merchant use a fix address to receive payment , it can only receive 6 payments per hour. Basically makes the service useless. It's customers have to wait forever if there're more than 6 payments per hour.
legendary
Activity: 2282
Merit: 1050
Monero Core Team

You're an idiot, don't do this!   - 59 (36.6%)
I don't like this, but I agree we need to move forward with it.   - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now.   - 19 (11.8%)
Great, it's about time!   - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP!   - 35 (21.7%)
If it's from Luke, it can't be any good.   - 11 (6.8%)

I read the poll more along these lines. Opposed: 43.2% In favour with varying degrees of support: 56.5% Rounding 0.3%. There is a fair degree of support for this. We must also keep in mind the following


i coloured it because for instance
saying "i dont like this" 14 (8.7%) means literally i dont like this.. in other words NO
saying "we should have waited longer" 19 (11.8%) means literally i dont want this to be done yet.. in other words NOT YET

but both questions are worded to then subtly suggest they agree to implement it. these type of questions are called trick questions.

EG if i said "do you hate termites" and you chose
1) i dont like them, but i agree we to live along side them as they are living creatures

great using that answer, you have agreed to allow me to deliver 500,000 termite larvae to your house as you seem to be ok with it.


To quote the termite example. It is more like I am not ok with allowing you to deliver 500,000 termite larvae to my house; however if you do I will not call the exterminator even though the termites will demolish the house. The trouble with saying "no but" is that more often than not it means "yes".
legendary
Activity: 3430
Merit: 3080
I have no flipping idea what anyone is talking about. Am I going to need to create new address everytime I get paid from my pool? Because that would be plain stupid. Please correct me in simple English because this is how I'm seeing it.

Not yet, relax for the moment. None of this will matter for a while yet, till then, get clued up. I've explained it all below.

I recently lost all my coins because I created a new receiving address and didn't back it up. Wouldn't this create more similar problems?

Nope, instead it solves them.

There's a new wallet feature, Armory has used this idea since very early on. The idea is to have the addresses worked out in advance, but not just in a list. Instead, and you should be able to guess this, you use cryptography to define the list. You get the ability to create Master Addresses, and each Master Address basically gives you an infinite list of addresses for receiving funds at your wallet. You create yourself a Master Address for mining with, and give that to the pool. Then you only have to BACK UP ONCE. It's pretty neat, I've used Armory's version of this already. Create as many Master Keys as you like, just like normal addresses. So that whoever you give a Master Address can't see your whole wallet and every address in it, they can only see the ones you gave it to them for in the first place.

I may be barking up the wrong tree here... but what gives? Bitcoin is fine the way it is.

Problem is the idea for colour lists that track our coins. It comes down to the old theory of money stuff. Someone can look at one of these tracking lists, look at my BTC address, then look at your BTC address, and decide they'd prefer your coins to mine. Because mine are on a list that says they were ransomed from a grandma. This makes Bitcoin less money-like, and if yours or my government want to kill Bitcoin, they can start by creating laws that say "everyone must use addresses that are on the list, otherwise they can't pay". It doesn't have to be in the BItcoin software, it can just be a list you can search on some website. If you get given listed coins, you say to the person paying you "Sorry, can't give you what you paid for, because you paid with dirty money. I can't spend this, because it's on the list. If you still want [whatever it is], you can pay with clean, listed BTC. I'm sending the dirty money to the dirty money collection & cleaning guys". Big problem. People don't want to use a system like that, BTC price goes down. People stop using it. Bye bye Bitcoin.

The lists are no good if we take steps. This is one out of many steps. If we concentrate on getting these things in place, and make them understood by everyone, the lists won't work. Hello Bitcoin.
legendary
Activity: 2576
Merit: 1186
... there are projects in the works to make anonymous commerce just as safe (or safer) as non-anonymous commerce, in a grandmother-friendly way.
Bitcoin is never anonymous, no matter how you use it.

After that's done, law enforcement can shove their desire to spy on everyone and everything up their ass.
Law enforcement can do forensics the same way they do with cash (actually, they can do better with Bitcoin).
This only buys you privacy - without it, everyone would be able to see everything you do.

I think he's saying that these clients are missing bloom filter support, which has been standard for a while.

Are you sure Bloom filter is the right solution? It creates more load on Bitcoin nodes than UTXOs-for-address queries would.
"Lookup by address" is only less load than "lookup by bloom filter" if every node carries an address index (which adds to disk and memory requirements).
In any case, Bitcoin was designed with addresses being single-use, and it becomes unusable with too much reuse, so this side-topic is irrelevant.
donator
Activity: 1218
Merit: 1079
Gerald Davis
the other thing to note is:

Gavin A proposes adding API callbacks into the bitcoin URI so that retailers do not have to use unique addresses per customer, but using one address and be able to track which TXID belongs to which customer by use of the API callback.

so we have Gavin A trying to reduce the need for unique addresses. and we have Luke Jr trying to increase the need for unique addresses.

can we find a room for the main dev's to go in and slug it out for a few matches as to something that can be agreed on that is best for the community..

Link please.  Nothing I have read about the payment protocol implies static addresses.
sr. member
Activity: 308
Merit: 250
Double your Personal Bitcoin Funds.
I have no flipping idea what anyone is talking about. Am I going to need to create new address everytime I get paid from my pool? Because that would be plain stupid. Please correct me in simple English because this is how I'm seeing it.

I recently lost all my coins because I created a new receiving address and didn't back it up. Wouldn't this create more similar problems?

I may be barking up the wrong tree here... but what gives? Bitcoin is fine the way it is.
legendary
Activity: 1022
Merit: 1033
I think he's saying that these clients are missing bloom filter support, which has been standard for a while.

Are you sure Bloom filter is the right solution? It creates more load on Bitcoin nodes than UTXOs-for-address queries would.
Pages:
Jump to: