Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools. No everyone's fate is in the hands of miners. However it HAS ALWAYS BEEN in the hands of miners (since the genesis block). Don't like that concept? Then become a miner. Not in the hands of miners, but in the hands of the operators of big mining pools. That's a big difference. A small miner is as powerless as non-miner. Can't tell if trolling or stupid.... at least try to stick to one mumbling complaint at a time Your complaint was true yesterday, the day before, the previous week, the previous month, and the entire history of pooled mining. Give yourself a round of applause for finally working out that pools represent multiple miners working for a single node. BITCIONS IS DIEEEING It's not as true when the difficulty was not as high as now and increased as quickly as now. In the early days, it was much easier to create a new pool and get enough miners to join to survive. Now may I ask a simple question to you? How many hash rate do you have to get before anyone will be interested in joining the new pool you created? This situation becomes worse and worse every time the difficulty increases. Why should I troll when my benefit lies on the appreciation of the BTC? I am just worrying. One of the main reasons why people love BTC is that they think BTC is democratic and nobody can damage it since it is protected by millions of users. Call me stupid if you want cause I feel quite unconformable now when I realized just 3 to 5 persons (the operators of BTCGuild, GHash, Eligius, BitMinter, and Slush) can effectively damage the who ecosystem. Yes, this time this patch may be not so harmful and you happen to side with the OP. But eventually you may disagree on other more serious issues. Considering it more before calling others FUD or stupid. Problems have to be warned by some FUDers before they can be fixed, because the Lovers are often too blind to find them. Finally maybe off topic, a proposal to OP, as I believe he really cares about the future of BTC. Could you please also considering a patch that restricts the market share of one pool. I think that is at least as important as your current patch. Maybe we could open a new topic on that? EDIT: create a new topic here: https://bitcointalk.org/index.php?topic=337260.msg3618577#msg3618577 |
|
|
|
|
The problem now is if Luke's patch is applied in all big pools, Mastercoin will be DoA. Only one MSC transaction is allowed in 10 minutes in that case. MSC relies on BTC, but BTC community seems care nothing about MSC. In that thread, nobody even mentioned MSC except me.
|
|
|
|
 Accounting in USD? Then if I am not wrong, if they did not invest and just keep the BTC, the ROI is 500% now.
|
|
|
|
Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools. No everyone's fate is in the hands of miners. However it HAS ALWAYS BEEN in the hands of miners (since the genesis block). Don't like that concept? Then become a miner. Not in the hands of miners, but in the hands of the operators of big mining pools. That's a big difference. A small miner is as powerless as non-miner. |
|
|
|
Why miners care so much to leave the pool they are used to? They are not the ones suffering from this patch. I am saying those who disagrees has no chance to create a new pool to protect themselves. Miners aren't Bitcoin users? Not a single miner will be affected by this patch in any way shape or form? Not a single miner will be convinced by your FUD and doom and gloom and switch in order to save Bitcoin from Luke-Jr? Is your worlds so black and white that miners are a group outside of the group of users? We went through the same kind fud with P2SH, we went through the same kind of fud with dust threshold. Bitcoin survives. The protocol is robust, clients and service providers will make improvements. If they don't they lose marketshare to those who do. Please calm down and think about it more. A small part of miners may care about this patch does not change the fact that now everyone's fate are in the hands of a few operators of big pools. Some day you may disagree some actions they will take. But you can do nothing, just like me now. |
|
|
|
Miners will not join a new pool which find a block every one week. To create a new pool you have to spend huge amount of fund beforehand. It is not so different as 'everyone can be a president candidate in US'.
Who said anything about a "new pool" If BTC Guild supports this patch (which they don't yet) and miners disaprove they can simply go to the #2 pool which doesn't support the patch. Still 50% of miners supporting the patch still doesn't have a catastrophic effect on multi-use addresses. 1st confirm time doubles to 20 minutes. 6 confirm time goes from 60 minutes to 70 minutes. Why miners care so much to leave the pool they are used to? They are not the ones suffering from this patch. I am saying those who disagrees has no chance to create a new pool to protect themselves. |
|
|
|
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.
Utter nonsense. This isn't a change to the core protocol. All miners have ALWAYS had the ability to prioritize tx as they see fit. Currently ~15% on the network is implementing this so the effect on multi-use addresses is minimal at best. Bitcoin was DESIGNED for this type of decentralized tx processing. There is a reason tx selection is loosely coupled. There is a reason that miners are free to include any valid tx in a block. There is a reason that other miners can't override or veto that decision. Once BTCGuild joins, it's done. BTC now is not decentralized at all. Miners vote with their hashing power. If miners agree then it is no different than a million solo miners implementing it directly. If miners disagree then they can move to another pool more inline with their views. Miners have always had the power to choose the tx they want to include in a block. The availability of the patch merely gives miners an effective tool to implement this type of prioritization. The patch isn't doing anything the protocol doesn't already allow. Still this is still a relatively soft change. Even for affected tx having 50% of hashing power implementing the patch doesn't kill those tx. Affected tx will simply take twice as long for first confirmation and the following 5 will be at the same rate. Essentially a 6 confirm goes from 60 minutes to 70 minutes. If you honestly believe that will "kill" Bitcoin then honestly Bitcoin never had a chance of surviving and was a pretty crappy experiment to begin with. Bitcoin will survive just fine. Miners will not join a new pool which find a block every one week. To create a new pool you have to spend huge amount of fund beforehand. It is not so different as 'everyone can be a president candidate in US'. You are talking about just one transaction. As long as some addresses have more than a couple of transactions every 10 minutes, the waiting time goes to infinity. |
|
|
|
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.
Utter nonsense. This isn't a change to the core protocol. All miners have ALWAYS had the ability to prioritize tx as they see fit. Currently ~15% on the network is implementing this so the effect on multi-use addresses is minimal at best. Bitcoin was DESIGNED for this type of decentralized tx processing. There is a reason tx selection is loosely coupled. There is a reason that miners are free to include any valid tx in a block. There is a reason that other miners can't override or veto that decision. Once BTCGuild joins, it's done. BTC now is not decentralized at all. As a simple example, yesterday I suggested to create a pool to save master coin, which will be killed immediately with Luke's patch. Then we realized we need 500TH and double it every month to mine a block each hour. even we can get several TH to start it, no miner will join us since it may takes weeks to find a block. Now you can clearly see the danger of centralized mining. Disclaimer I hold 0 share of mastercoin. |
|
|
|
I. Auction bidding. This can be accomplished with a BIP32 address chain Is this supported with blockchain.info or bitcoin-qt at this time? No, and that's the point. Unless some pressure is exerted, adoption of BIP0032 will always be on the back burner. This is an example of how miners can exert pressure on the entire ecosystem. On the contrary, now I think the over centralized miners become the biggest danger of BTC. Just two or three big pools can ruin the who ecosystem with just one bold action. With current difficulty, there's almost no chance for a new pool to survive and hence no democracy at all in BTC now. We are now all controlled by the operators of BTCGuild and other couple of pools. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
|
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. Remember even your decision is correct in the long term, it's side effect will do great harm if not being careful enough. Now it's too dangerous to do something like: just do it and let's see what will happen.
|
|
|
|
I am getting maybe 1 PTS by mining for over a day. What is the total coin supply now?
I think it will reach a tipping point soon. With difficulty rising price will be nowhere near the effort spent to mine.
I get 10~12 PTS a day mining with 20 physical cores and 20 VPS cores. Before btc38.com went into maintenance mode, PTS was going for about $5.8 each. I hear on coingrounds, it goes for 0.008 BTC. Plus, don't know what the value will be once the genesis block start and all the PTS spawn 1:1 ratio of Bitshares, and what ever else spawns from PTS. Are you saying after some changes price may even go up? I have not looked closely into bitshares and DAC. I had mined one block solo and after that getting a very small return when I started pool mining. I am now wondering whether to sell now for almost 0.5 BTC or hold. Thats why I wanted to know what the current coin supply was. Where did you get the impression that 1 PTS can be sold at 0.5 BTC? Really curious, because all sources I know have much lower price. I said 1 block. My bad. I didn't notice it.  To sell it at 0.01BTC will not be difficult now. How about sell a half and keep the other half to see what will happen? Then you will get 0.25 BTC in the worst case, and don't need to regret too much in the best case. |
|
|
|
I am getting maybe 1 PTS by mining for over a day. What is the total coin supply now?
I think it will reach a tipping point soon. With difficulty rising price will be nowhere near the effort spent to mine.
I get 10~12 PTS a day mining with 20 physical cores and 20 VPS cores. Before btc38.com went into maintenance mode, PTS was going for about $5.8 each. I hear on coingrounds, it goes for 0.008 BTC. Plus, don't know what the value will be once the genesis block start and all the PTS spawn 1:1 ratio of Bitshares, and what ever else spawns from PTS. Are you saying after some changes price may even go up? I have not looked closely into bitshares and DAC. I had mined one block solo and after that getting a very small return when I started pool mining. I am now wondering whether to sell now for almost 0.5 BTC or hold. Thats why I wanted to know what the current coin supply was. Where did you get the impression that 1 PTS can be sold at 0.5 BTC? Really curious, because all sources I know have much lower price. |
|
|
|
So that means addresses in a wallet is very easy to be associated. Then not-reusing address is not enough, and we have to generate a new wallet for each transaction?
Even if people all generate new address for each transaction, since the addresses in one wallet is easy to be found associated, their addresses are still can be classified into one big 'address family'. So there may be no 'well known address', but 'well know address family'. Did I make any mistake here? If this is true, why the trouble?
No, if you use each Address only once, it will be completely empty after you send BTC from that address the first time and will never be used for any transaction again. There would be no difference in creating a new Wallet. The client takes care that Change addresses are only used once, the only thing you have to do is to use addresses for reviving transactions only once. If you only revive at B one time, there never will be a B-2 Change. Unless what you send exactly equals to what you received before, otherwise there's a change and the change needs to be sent to a change address in the same transaction. So if you see a transaction S -> A and S -> S2, you know it's highly likely S and S2 belongs to the same wallet. As a result, your address S is associated with the change address S2, but not so closely because you can still claim (arguably weakly) that you are sending to two different people simultaneously and happens to used up all the unspent amount of S. Then let's say you have change address A, and change Address B, they all have 0.5 BTC and you want to send to user U 1 BTC, then this time you will see A -> U 0.5 and B -> U 0.5. This makes a strong association between A and B and every one knows A and B belongs to the same wallet. Therefore, it is easy to associate the addresses in the same wallet by analysing the block chain. If you don't reuse the address S. It will never have an unspent output after this transaction again. If you use every address only once. S will receive exactly 1 Transaction and never again a second one. Therefore there will never be more than one change address for ever address. And it's impossible to tell which address is the change address and which one is the reviving address. Changing Wallets here makes absolutely 0 difference. That was the point. What you are missing here is that a wallet may contain many unspent txouts from receiving many payments from different sources before there is any need to purchase something with the wallet. Lets say I sell alpaca socks out of a truck down by the river. I would be receiving many 0.10 BTC payments from different individuals to different addresses, suppose for a total of 20 .1 BTC payments in my wallet. Now, I donate 0.95 BTC to a known-address donation site and say to everybody "hey, I just donated!". There will be a 0.05 change back to my wallet, that is now considered "tainted" - based on my declaration of donation, or the site owner saying "thanks for donating, deepceleron", it has become simple to figure out my donation AND determine which is the change back to me that is still in my wallet. So I've got 1.00 BTC of sock-selling money that 10 sock buyers know the address of, and 0.05 that anybody interested can know about. I then send the entire contents of my wallet to a man-boy snowden tibet love honey pot that is supposed to be anonymous, but is monitored or busted by a government. Even with this site using one-time addresses, the previous use of a reused address has compromised my identity and made my payment have little plausible deniability, due to my control of the change. The "change" could have been a multi-send to a third party, and the third party may have made the illicit payment, but LE will not care to investigate so much when they need doors to kick in. The disclosure is because you publicly donated to a know address and later send money to another well known address (at least known to the authority), and it of course make your address public and makes all your efforts in never reusing addresses void. I believe if someone wants to do some problematic donation, he has to create a new wallet and use some mix service anyway. |
|
|
|
|
Ok. That's interesting. Thanks for sharing.
Then I am more convinced that if a careful person always use address only once, no need to worry about the other part has a well known address. It's very difficult to link the address he uses this time with all other addresses he owns.
|
|
|
|
I don't think having our own pool would help enough. Even if we found find the incidental block that would probably be just as fast as the 1 transaction per block that the other pools are doing, if we assume everybody adopts Luke's patch. We would need to find a block every hour consistently if we find less then that Mastercoin would be a seriously slow protocol.
Yes, good point. But if there are 144 transactions, we can finish them in one hour with our own pool, but without our own pool, they take one day. So with our own pool, at least we can ensure all transactions can be finished when we found a block, but without it the transactions will definitely take forever to finish as long as there are more than 1 transactions every 10 minutes. |
|
|
|
Even if it is risky, I'm to lazy to make new addresses
If you are using clients other than MultiBit, (e.g. the Qt version and Amony), most likely the client is creating a new change address whenever you send out BTC. |
|
|
|
How do you tell which of the two outputs was the change and which the payment?
With each transaction you have a 50% chance to follow the wrong path.
Good point, but sometimes by looking at the amount you can know better than 50% chance. |
|
|
|
|
How about the combining case?
If we see B -> E
C ->
Then B, C are associated right?
|
|
|
|
|
Show Posts
