|
There is a reference to the coin maximum (MAX_MONEY) in the code. I don't think it gets used much, mostly just a sanity check. It would be trivial to change.
The client has no idea of how many coins have been created. There is no running total anywhere.
By the way, how would this proposal deal with the integer representation? The first step in the new system would be from 2500000000 to 2499992063.50. Would this round up, or down? When it gets down around 0.00315 BTC, the delta will be less than one unit. How will this be handled?
|
|
|
|
I think 20% is too much -- in regards to what is needed to ensure a miner is doing his job versus the autonomy desired by miners. As mentioned before, there only needs to be enough tx required that the rogue miner has to start paying attention to other tx on the network: it sounds like he's not paying attention to any of them: 0%. If he has to start paying attention an including any of them, he might as well include all of them. Problem solved.
Well not actually solved yet: but my point is there's a very low threshold for what is needed to get him to start paying attention.
EDIT: on second thought, what's stopping him from just creating 20 tx per block himself and broadcasting them, just to make sure he can meet the X% req't? Seems like we might accidentally encourage the rogue miners to start adding bloat just to get around the rule (which might be easier than starting to pay attention).
Nothing would stop him from creating his own transactions. But he still has to distribute them to his nodes, and even one transaction would be much more data than he is distributing now. Also, the data he needs now he can get from a variety of public sources. |
|
|
|
I also think that keeping the block rewards constant for all eternity is beneficial in many ways and is going to be discussed more and more when we get near it's planned elimination, and if that is how it is done, the miners will not need that much freedom, they will just have to include all the transactions they see. Ok this doesn't make any sense. As block reward declines the need for miners to exclude unprofitable tx becomes even MORE important. So hypothetically when the block subsidy is 0 BTC miners should be required to include all tx. Even if they are mostly 0 fee? If miners must include all tx (even those w/ no fee) why would any user include a fee? So when block reward is 0 and fees are 0 how will the network remain secure? He is talking about keeping the subsidy. Miners would have to include free transactions because they were paid by the subsidy, not by fees. This is actually the best reason I've ever seen suggested for potentially keeping the subsidy. But I still don't think it is a good idea, and I don't think it'll gain any traction. |
|
|
|
I like it. I sent 1.0 BTC to each one. bitcoind sendmany "" '{"1KgneQjY9fHHYBHanBRBJLb5xzrhdkT5ts": 1.0, "1MCG6fkzwXXqw6TKLtyxRRfBbv13nBeTDG": 1.0, "1MXqCoKMqTdN8mNvLnqKgba4ySQR53u5pp": 1.0, "1CRYxusoqPEECjqf35Nf8RjkmXd9U4UvCV": 1.0, "19oDRYx1HxvQnhkfYAx7g7qyPt2cwf986W": 1.0}'
|
|
|
|
This sounds like the exact problem I was hoping to solve with Armory's signature blocks (and message signing just implemented in Satoshi 0.6.0). The only requirement is that the user's first ever deposit is with an address they exclusively own. All future deposits to their account can be through any means whatsoever. Ok. Deal with this scenario: 1) Innocent user funds casino account with tiny number of bitcoins and provides convincing ID. 2) Innocent user's laptop is stolen or otherwise hacked by Hacker - the point being that Hacker gains access to innocent user's private key and Innocent user loses access to the private key. 3) Hacker steals lots of bitcoins and sends them to Innocent user's casino funding address. 4) Hacker withdraws the coins from Innocent user's casino account. 5) Police find out that the stolen coins went to the casino. 6) Police ask the casino to tell them who the account belongs to. 7) Police have good reason to accuse Innocent user of theft. Innocent user can't prove he doesn't control the stolen coins and a jury has good reason to believe he can. ByteCoin If the casino has a policy of only sending coins back to the address that it got them from, then the attacker can just send the coins to the stolen key, deposit them from there, withdraw them back to that key, and send them away. Steps 5-7 go the same way as in your example. Same thing would happen if a return address was embedded in the deposit using OP_DROP or whatever. |
|
|
|
In my opinion, the problem is this: 4) Casino only sends withdrawals to depositing address.
They should stop that. It is silly. Whatever convoluted workaround we come up with is going to be far worse than simply doing the right thing. The right thing, by the way, is for the casino to request a return address (address A), then generate a new address (address B), and link them in a database so that earnings made with BTC deposited to address B will only be returned to address A. Yes, you should insist that customers give you a refund/cash-out address BEFORE you give them the funding address. Simply not reusing addresses is the correct solution. But, this isn't what users do. I'm pretty sure this isn't possible in all cases. bitlotto's example seems it would be much more insecure with this requirement. How about the hypothetical case in which someone sends unsolicited funds to an address - the recipient may wish to refuse to accept the incoming TX. While it seems less likely, surely it will happen that a user decides to send money to Address A and clicks on Address B - user error. Wouldn't it be desirable for the recipient to be "honest" and return the money ( with a XXX TX_REFUSED_UNSOLICITED message or something?) Here's another example of wanting to refuse an incoming TX (based on amount rather than originating address) Big bad gangsterman has my vanity bitcoin address & wants to stash 50K BTC in my wallet for later physical retrieval. I refuse the TX because it's too large - I'm not expecting any such payment. (paranoid, ridiculous, but I could see plenty reasons) I'm also quite sure the correct solution in the above case is to not publish Green addresses, but that is what people do. What about whitelisting addresses? In this case I'm only willing to accept TXes from pre-authorized known addresses. I can see why a financial institution would want to do this. I understand the issue of introducing code (&bugs) into reference implementations. In general I'd be more inclined to implement a solution on top of the existing client rather than by modifying it directly. (or producing a merchant wallet) If the solution MUST be "insist that customers give you a refund/cash-out address BEFORE you give them the funding address" I would have thought then that a bitcoin address MUST be a single use address to prevent such error. If I gave the impression (wrong forum?) that I wished to change the reference client - I apologize. This was not my intent. If that's where it belongs, great, but doesn't seem necessary. I also suspect that there may be some confusion of this type of refusal with refusal to accept TX from blacklist addresses because of suspected "taint" in their balances. This is not the reason I'd seek this. Unfortunately I'd guess it could be used for that purpose, too. Would Mt.Gox be better off if it could refuse incoming transactions that look "risky"? Bitcoin just does not work that way. When you spend coins, you are signing a transaction that irreversibly passes control of them to the recipient. The recipient is not a participant in this. There is nothing he can do to prevent you from doing it, except by preventing you from ever getting an address that corresponds to a key he owns. We could add another layer that negotiates transactions before they happen, but as long as an address can be found, there is no possible way to prevent someone from sending to it. In the case where you send coins to person A when you meant to send them to person B, the solution is to call up person A and explain the situation. If you get an unsolicited transaction and decide to send them back to the last address that was known to have had control of them, you must do so with the understanding that you can not prevent people from using shared wallets and thus you might not be sending it back to the entity that sent it to you. Also, the situation where the criminal sends money to you and then shows up in person to collect is pretty silly. If he shows up with a gun, you should give him his coins back. Duh. You should probably give him all of your coins too, and whatever cash you have on you. Oddly, this is exactly the same thing that you should do if a FedEx package full of cash shows up at your house. If he sends the 50k coins from his MtGox account, and you return them, he is not going to be happy that you sent his money to a random MtGox user. |
|
|
|
They should stop that. It is silly. Hmm. Saying "don't have the problem" isn't quite what I'm looking for here. I will edit the OP in case you think I am suggesting making any changes to the network. I am not. Sometimes, saying " Stop it!" is the best a guy can do. No one wants to hear it, but sometimes they need to. Whatever convoluted workaround we come up with is going to be far worse than simply doing the right thing.
I'm not sure that this is the case at all. Please elaborate if you think this is the case. The right thing, by the way, is for the casino to request a return address (address A), then generate a new address (address B), and link them in a database so that earnings made with BTC deposited to address B will only be returned to address A.
Anonymous services may not wish to do this. Avoiding suspicion of money laundering is one possible reason this method might be impossible. (This is the stated reason for the casino - it only gos back to where it came from = no money laundered here) Also, regardless of the seemingly silly issue being directly discussed, can you not think of any reason ever that one person might wish to refuse an incoming transaction from another? I can think of several. Bitcoins don't come from addresses. Bitcoins come from transactions. And the notion that sending BTC back to the previous address that it had been sent to was the same as sending it back to the person or entity that sent it to you went out the window the first time two people ever shared a wallet, and with the invention of services with accounts (like all of the exchanges and banks) it was as dead as a doornail. And no, I can't think of any good reason to ever reject an incoming transaction. |
|
|
|
Probably because it isn't recognizing the external IP address as being itself, so when it finds the IP from other peers, and tries it, realizing it is talking to itself, then it closes the connection. Torrent clients have this happen too. Often, the computer is only aware of its internal/LAN IP, so that's how this happens. No big deal.  That makes sense, but then I would have expected the error messages to list the external IP, not the loopback. |
|
|
|
I'm willing to further discuss and finally probably also to agree that an indisputable link between a person and a transaction can not be established (issues with copies, backups, ...).
But (and I quote OP here) I would continue to argue that a hash of a digital file (a photo in this case) can be found in the blockchain and also that it can be proven when it has been included in the blockchain.
Why it's there, who's benefit it is I don't discuss. Just the fact that it's there and when it was included. Would the link between the file and it's fingerprint in blockchain stand?
Exactly right. Unless one or more of the major functions used by bitcoin is seriously broken, then the existence of the hash in the block chain would easily and convincingly prove that the document existed prior to the timestamp on the block (more or less) and that it has not been modified since then. It could still have been modified prior to being hashed, and it could have existed for a long time prior to being included, and anyone in the world could have posted it. But it existed, in that form, at that time, and you can prove it. |
|
|
|
In my opinion, the problem is this: 4) Casino only sends withdrawals to depositing address.
They should stop that. It is silly. Whatever convoluted workaround we come up with is going to be far worse than simply doing the right thing. The right thing, by the way, is for the casino to request a return address (address A), then generate a new address (address B), and link them in a database so that earnings made with BTC deposited to address B will only be returned to address A. |
|
|
|
Ha! Found a funny error message. 2012-03-31 21:52:02.374120 Peer 127.0.0.1:9333 misbehaving, will drop and ban. Reason: was connected to self
2012-03-31 21:52:02.374464 Peer 127.0.0.1:47778 misbehaving, will drop and ban. Reason: was connected to self
But why would it connect to itself in the first place? |
|
|
|
You can put the hash in the blockchain and prove it was taken before that block was generated. It would be good proof to me, but proving the timestamp of that block and what your hash proves would likely be "interesting" in court. That's a lot of math you'd have to explain to a jury.
Courts have "experts". You just need one that understands bitcoin and can testify that he knows that including the hash retroactively isn't possible. The other party's expert won't be able to claim otherwise without perjuring himself, and any math teacher or computer science professor from a local college will be able to back your guy up on the tricky parts (hashing), even if he doesn't know bitcoin specifically. Oh, but keep in mind that the timestamps aren't exact. There is a several hour window on either side. That is enough for most things, but not enough for precision timing. |
|
|
|
I would like this thread to discuss only this one proposal for hindering empty block mining. We already have two threads full of speculation about who is mining the empty blocks, and brainstorming other ideas for stopping them. I'd prefer that this not become a third. The idea has floated several times to reject blocks that don't contain at least some portion of the transactions that you node is aware of. Might be time to reconsider it
Of course, it wouldn't be anything as simple as "reject empty blocks" or "reject blocks with less than X transactions". Those won't work.
It will need to be more like "I see 100 pending transactions that are valid and should be included in the next block. This block I just got from the network contains less than 25% of them, so I will reject it." There will probably need to be a threshold too, like "I only see 10 pending transactions, and that isn't enough to enforce a minimum number on this incoming block, so I will accept it, even though it has none".
As a first guess, I would say that a threshold of 10 or 20 and a fraction of 1/4 to 1/2 would work well.
Method b) Nodes invidually determine which nodes are invalid (seems to be the method advocated by kjj )
The problem is that at any moment in time your node my not see every transaction. This is important: CHAIN SELECTION BY NODES IS DETERMINISTIC AND MUST ALWAYS BE TO AVOID FATAL FORKS. Now matter how a node is made aware of a block, how delayed, or what other data it has at the time it currently always picks the same chain. This keeps the entire network operating on the same chain and avoids fatal forks (forks which can't be re-organized by simply allowing dominant chain to grow longer).
If nodes determine which block is valid based on information it has (which may be incomplete) then it is possible (actually very probable given enough time) that some nodes will consider block X valid and some consider block X invalid. Deterministic chain selection is now fatally broken. Once a node considers a block invalid it won't change its mind and thus any blocks built on it also become valid. The two fragments keep diverging. Forks will build upon forks upon forks until the network a fragmented mess of sub networks each with a different view of the current coin balances. An attacker could exploit this fact by broadcasting transactions (not in the block it just mined) selectively right before broadcasting the block to ensure some nodes will consider a block valid and some not. Even without malicious intent the network would destroy itself if chain selection isn't deterministic.
It is a non-issue. Over time transaction fees will make up a larger and larger share of the revenue a miner needs to stay profitable.
You've added a number of assumptions. The biggest one is that you assume that block rejection is permanent. Taking out just that one added assumption, and the system works again. If my node has block X, and another block comes in (call it Y) that has the hash of block X-1 in it, that new block is rejected. Unless when block Y+1 comes in and has the hash of block Y in it instead of X. When that happens, block X is tossed out, and block Y gets unrejected. In this case, if block Y+1 meets the acceptance criteria, block Y becomes valid, even though I didn't like it when I first saw it. However, if block Y+1 is also an antisocial block, they both remain on the lonely pile until a good miner builds on top of it, or until the X chain grows longer than the Y chain, making the issue moot. There may be holes in my idea, but I don't believe that this is one. 16 or 20 years from now, when the subsidy has dropped and hopefully the fees have increased, this may be a non-issue. But today, it is a real issue. We are paying full price for these blocks, but only getting part of the value. For the record, I have no problem with botnets contributing to bitcoin, as far as bitcoin is concerned (i.e. ignoring the moral issues of theft of service or whatever you want to call it), as long as they are contributing to the security of both past and present transactions. Seems like a bad idea. There's going to be a lot of wasted work if half the miners are working on a different block. You will effectively halve the total network hashrate and make it that much easier to 51% the network. Plus if X+1 and Y+1 are found around the same time, it gets worse. This also makes it easier for some to try to double spend their coins.
Probably best to keep things as they are and things will sort themselves out as designed.
We get network splits all the time. And good miners would have an incentive to build off of the blocks other good miners, so the forks would rarely be anything near 50/50. And most importantly, this gives the antisocial miners powerful incentives to become good miners, without waiting for however many years it takes for fees and subsidies to do that automatically. Let me be very clear. I propose that:
1. nodes temporarily reject blocks that they can identify as antisocial. Nodes already temporarily reject blocks, but for different reasons.
2. nodes have a method whereby a block that was temporarily rejected can become accepted. Again, nodes already do this.
Further, I assert that:
1. these will not lead to permanent or even long-lived chain forks, for exactly the same reason that the ordinary chain forks that we get about once a week are not permanent, and can't become permanent.
2. any method used to game the system to create blocks that include only dummy transactions created by the attacker to circumvent rejection will necessarily require more effort than simply doing the right thing (including ordinary transactions), giving the current antisocial miner(s) a strong incentive to become a positive part of the network.
The two main objections to my proposal are: 1. It would cause forks, which would be bad. I think that I've addressed this sufficiently. It will indeed cause local forks, but those forks will not be global, and will not persist any more than the forks we already have. 2. Miners would lose quite a bit of autonomy over which transactions they include. Sadly, this is true, and is actually the entire point of the proposal. But, the community at large is paying for the work done. I think that we have the right to set standards for the quality of work which we will accept. My proposal also has some less obvious advantages. 1. It requires no new protocol and no new centralized authority. Each node can make the decision to defer an incoming block based on the data it has locally. 2. Each node would be able to set their own policy. The network would reflect something like an average of the policies of all miners. |
|
|
|
Gresham's law refers to government enforced exchange rates and does not apply. This is about deflationary expectations on a free floating market.
"Bad money drives out good if they exchange for the same price."[13] The law works in other circumstances too. For example, I have next to me a $5 coin and a $5 bill. Both are real, official, legal "money" of recent issue, blessed by the U.S. Government and either one could be traded for stamps at the post office or used to pay my taxes. One is paper, and the other is gold. In this country, the bad money drove out the good money, a process that started about 100 years ago, and was more or less completed by 1965. Sorry, you fail your test. If you whine and suck up to me, I may consider partial credit. Same circumstance. Fixed Exchange Rate. Exchange rate between $5 coin and $5 bill is fixed by law. If the exchange rate was fixed by law, I'd have hundreds of those gold coins. |
|
|
|
Gresham's law refers to government enforced exchange rates and does not apply. This is about deflationary expectations on a free floating market.
Good job. This quote from wikipedia is helpful at stating Gresham's Law accurately and in simple terms. The Nobel prize-winner Robert Mundell believes that Gresham's Law could be more accurately rendered, taking care of the reverse, if it were expressed as, "Bad money drives out good if they exchange for the same price."[13] Neither the US dollar nor bitcoin operates under a fixed exchange rate, so of course Gresham's law is not applicable. The law works in other circumstances too. For example, I have next to me a $5 coin and a $5 bill. Both are real, official, legal "money" of recent issue, blessed by the U.S. Government and either one could be traded for stamps at the post office or used to pay my taxes. One is paper, and the other is gold. In this country, the bad money drove out the good money, a process that started about 100 years ago, and was more or less completed by 1965. |
|
|
|
Tony suggested to take a look at this convention in Chicago. http://glamourcon.com/vendors.htmlI'll be willing to foot the total booth cost for this venue. Even for two adjacent booths. Where we at on this now? ~Bruno~ EDITPS: CES 2013 is probably off the table due whom the convention is marketed toward. I could probably drive down to Chicago that weekend to, uh, "help". |
|
|
|
Since 0.6.0 came out I tried to get p2pool working, but failed. Once I followed all the noob friendly steps cgminer wouldn't work, I have a feeling I need an sdk, but the further down this installation rabbit hole I go the more problems I find.
Would someone be able to tell me the number of programs required to run p2pool with full functionality? I installed 5 (bitcoin, p2pool, cgminer, python, twist) and I have a feeling I need a few sdks as well, would an estimate of 10 installs be necessary to get p2pool to work? Does it depend on my hardware? Do I need to be proficient in bitcoind as well? (I ask because I run bitcoind and all I get is a black screen, I can't type anything) Thanks for the help and work you guys do.
If this is for a dedicated miner, it might be easier to just grab p2pcoin. To troubleshoot your setup, work in three steps. First, get bitcoind running. Then p2pool. Then the miner. You need to configure bitcoind to become a background daemon, otherwise it will hold the terminal open and never write anything to it, the black screen that you describe. Once you have the black screen, check the debug.log file. If that file is growing, bitcoind is actually running, which would just mean that you need to configure it. |
|
|
|
p2pcoin users need to update to version 0.3 ASAP. This is due to a change in p2pool. Sorry for the short notice. I was out of town last week and somehow missed forrestv's post when I was catching up. |
|
|
|
Gresham's law refers to government enforced exchange rates and does not apply. This is about deflationary expectations on a free floating market.
The rational agent will not run out of cash if he has a webstore where people buy iPads with cash, and he gets a commission in cash. He will never get a a bitcoin revenue because people will not buy his inventory with bitcoins. Cash circulates, bitcoins do not.
You don't see it. Bitcoin is deflationary in relation to the dollar in your example. That means that the dollar is inflating. They are a matched pair, just as you can't have a purchase without a sale, you can't have an inflation without a deflation. Inflation always ends badly. |
|
|
|
@etotheipi
The subject has been beaten to death for a century by various economic schools, and the general consensus of most economists, supported by empirical data, is that deflationary expectations destroy trade, reduce economic activity and makes everybody a bit poorer, save for those who hold the most money.
A rational agent holding Bitcoins will understand their risky nature so it's likely he will diversify to control risk - not dump all his savings into Bitcoin. He might hold one third of his money in a mutual fund, one third in cash and one third in Bitcoins. Of these assets, Bitcoins is the most risky, but it also has the largest potential upside.
Ok, if this rational agent is faced with a buying decision regarding a new iPad, what currency is he likely to use, Bitcoin or cash ? Two basic scenarios:
- as long as bitcoins are rising, it's irrational to spend them; it's like killing your best cow - it's much more profitable to ride the bull market
- if bitcoins have stagnated since the user has added them to his portofolio, it's irrational to spend them since he took all the risk but has none of the expected upside
Faced with this decision the rational agent will chose to pay with cash. He will treat Bitcoin as a long term investment, and only spend them if:
- he wants to balance his portfolio after a bitcoin rally and mark his profits
- he wants to liquidate his bitcoin portfolio for whatever reason
Both these events are rare, so the velocity of bitcoins will be extremely low, and will mostly be related to cash <-> bitcoin exchanges. Thus Bitcoin's potential as a trade facilitator will not be fulfilled. On the other hand, an slightly inflationary cryptocurrency which has similar risks but no potential upside will be spend by it's owners like there's no tomorrow. Nobody will treat it as an investment since it's guaranteed to loose some value in a year or two - the hot potato game. The much higher velocity means higher GDP and strong merchant revenue in this alternate cryptocurrency.
Yes, given an unlimited supply of two currencies of unequal merit, it totally makes sense to unload the loser. Congratulations, you've found a really convoluted way to restate Gresham's Law. In reality, the rational agent will run out of dollars eventually, or run out of people willing to accept them. |
|
|
|
|
Show Posts
