How will the tax agency know you're not doing additional transactions and receiving payments to an address other than your "official" one?
They would know it when they try to buy something from the seller. Note that a tax agency could also sign registered addresses with their own private key; if a receiving address does not have the agency's signature, it means it escapes taxation, and the buyer would know it. Got it, sounds interesting. I'd love the ability to disarm arguments against Bitcoin on grounds of potential tax evasion. |
|
|
|
|
I think the protocol already allows arbitrary messages to be included in a transaction. So it's just a matter of having the client include a message on one side and display it on the other.
How will the tax agency know you're not doing additional transactions and receiving payments to an address other than your "official" one?
|
|
|
|
|
Currently, the easiest way for you will be to post here how much you'd like to sell and at what price, and be paid with PayPal. I might do it for the right price.
You'll be expected to send first, so only deal with someone with a reputation.
|
|
|
|
Ok, for 5 that may be my posting error. 5 is current round and I posted totalscore earlier in the day and posted share count later.
Here it is in an atomic select
totalscore: 997.23786939
shares: 431965
Ok, that's better. There's still an error in the 3rd decimal place which I don't think should happen. As for round 2, can the difficulty change account for that? r gets adjusted and subsequent scores also. The above reported r value for round 2 is that at the end of the round, but not so for the duration.
Yeah, that could be it. If you happen to know at which share the difficulty changed I'll be able to verify it (assuming everything worked as specified for that round). |
|
|
|
Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.
Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar. Great, that's a big help. Yeah, it's the big table scan that's bogging it down. Edit: balance updated to only scan last 10,000 shares. Note that the final round payment calculation still scans all shares. There's still room for improvement in the final calculation. At the current r, shares older than 17,000 will have score less than double-precision granularity, so they won't have any effect anyway. |
|
|
|
Ok, balancecurrent is really expensive in terms of performance and RPC is timing out with this long a round. I am trying to figure a faster way to do this.
Assuming the problem is summing over all the shares of the worker, note that shares older than the last 10,000 or so will have negligible score, so you can just find out the ID of the last share and use "where ID > X-10000" or similar. |
|
|
|
Hi again,
Hopefully I have the payment formulas of your method right. I am wondering what the round duration is before the operator loses money with an expected fee of 0 at c=0.001.
After 4 rounds, I have lost on all even those of relatively short duration. Since I have a miner as well, it doesn't really matter that much. Just wanted to double-check I am scoring correctly.
Looks ok, but it will help if you also post the number of shares on each round. To profit in a round you need it to have less than 3,000 shares (which happens with probability 1/140). So that's fairly rare, but in those cases you do, you'll make on average about 1/7 of the block reward so it evens out. The variance is still not too bad because even when you lose, you don't lose too much. Thanks, as long as it looks ok, I am content with the variance. For completeness though: select round.id,count(*) from round inner join share on round.id=round_id where score is not null group by round.id order by round.id; id|count 1|83410 2|275961 3|161084 4|281610 5|412581 I'm finding some inconsistencies between the reported ltotalscore and what it should be based on the number of shares. For rounds 3 and 4 the error is only in the 2nd decimal place so it's tolerable. But for rounds 2 and 5, the total score is as if the round lasted 307990 and 360808 shares, respectively. |
|
|
|
Hi again,
Hopefully I have the payment formulas of your method right. I am wondering what the round duration is before the operator loses money with an expected fee of 0 at c=0.001.
After 4 rounds, I have lost on all even those of relatively short duration. Since I have a miner as well, it doesn't really matter that much. Just wanted to double-check I am scoring correctly.
Looks ok, but it will help if you also post the number of shares on each round. To profit in a round you need it to have less than 3,000 shares (which happens with probability 1/140). So that's fairly rare, but in those cases you do, you'll make on average about 1/7 of the block reward so it evens out. The variance is still not too bad because even when you lose, you don't lose too much. |
|
|
|
Exactly, no one in his right mind would agree to change the block rewards. Unfortunately, I believe that the general public would say the same of a deflationary currency. The libertarians and austrian economists are the ones who are looked upon as kooks. But sure, if the scenario I layed out were to happen right now, I do believe this community still has enough influence to make sure that the right adjustments are made. The point I tried to make to you was that in the future, the influence over bitcoin of this community may be next to nil. If that is the case, we can't be sure that the majority of miners won't settle for some other solution that sounds plausible/has better marketing. But changing the difficulty is a perfectly valid measure to deal with emergencies. But the cost of this would surely be a massive loss of confidence in the very concept of cryptocurrencies. I don't see how that would benefit any of us. Preventing emergencies is always better than dealing with them. If the scenario I have layed out is plausible, then I am of the belief that measures should be taken to prevent it, not to deal with it. There will always be a need for a way to establish consensus about changes to the protocol. It need not be this community. What happens if/when SHA-256 or ECDSA is broken? Someone will have to agree on a replacement. Nobody will lose faith in cryptocurrencies because of occasional amendments which are known in advance to be inevitable. It is clear that changing block rewards is utterly unacceptable, for the reasons you have mentioned. But a one-time difficulty adjustment to deal with what is basically a technical issue (difficulty update granularity) is ok. I agree that the effects of a difficulty spike may be preventable, but we need to be very careful not to change the rules in a way that will cause more harm than it solves. |
|
|
|
But then we have set the precedent to turn bitcoin into an inflationary currency with increasing block rewards. Bitcoin relies on trust, and if this ever becomes real that trust will be severely damaged.
Exactly, no one in his right mind would agree to change the block rewards. But changing the difficulty is a perfectly valid measure to deal with emergencies. +1
People mining or investing in bitcoins need to always keep in mind that this is HIGH RISK.
BTC/USD may fall as fast as they rose in case of a downward spiral. We have seen -50% to -70% corrections all the time in the past 12 months
A -70% drop won't cause the effect discussed here (not in the near future anyway). |
|
|
|
The Bitcoin server, after deciding which transactions to include in the block, builds a Merkle tree of the transactions, probably using some standard library. The hash at the root is the merkle root. Then after a transaction, the new merkle root generated and replace the old one since the block header has changed, how can we verify the block? You can't, this is the point, you can't add a new transaction to an already solved block. That's what guarantees their integrity. If you're still trying to solve a block, when you add a new transaction, you start hashing the new block header with the new merkle root. |
|
|
|
|
Hi n00k!e, welcome to Bitcoin.
a) The main catch is that there's no guarantee the exchange rate will indeed rise. There could very well be a bubble about to burst any moment. Most people here expect rates to rise, though.
b) The rates people are willing to pay. If you are willing to pay $9.5/BTC and nobody else is currently, you will raise the exchange rate (of course, you'll have to make a large purchase for you personally to affect it significantly).
c) You might be misunderstanding that speculating is not what Bitcoin is about. Sure, you can do that, and you may make a profit. But Bitcoin aspires to be a medium of exchange to buy goods and services which is superior to currently existing currencies and wealth store/transfer services.
|
|
|
|
Even today some blocks have no transactions except for the generation transaction.
|
|
|
|
A mere $10,000 will hardly make a dent on the market. Based on a glance at https://mtgox.com/trade/history - Depth of Market, at the time of this writing you can sell them at >$8.8 / BTC. I don't think a dark pool is needed. |
|
|
|
I read in the wikipedia article that generating nodes have no obligation to include transactions when they create a block.
Correct. However in the bitcoin wiki/blocks section it says 'Bitcoin transactions are broadcast to the network by the sender, and all peers generating coins collect them and add them to the block they're working on'
They can add them if they want to, and currently they generally do. But they don't have to. I also read that the totality of transactions are hashed (with individual transactions NOT being hashed). (I assume this means ALL transaction since genesis, rather than in an individual block?).
Every transaction has a hash which identifies it. In addition, all the transactions in an individual block are structured as a Merkle tree, and its root hash is included in the block header as the "Merkle root". So when you say nodes have no obligation to include transactions, does it mean that they can just use the last transaction hash and work from there?
They don't use any "last transaction hash". They just build a block where the only transaction is reward generation, with a Merkle root to match. here is a recent example of a block where the only transaction is generation. |
|
|
|
|
+1. Whom do we need to contact about this?
|
|
|
|
The Bitcoin server, after deciding which transactions to include in the block, builds a Merkle tree of the transactions, probably using some standard library. The hash at the root is the merkle root. |
|
|
|
In transaction 3ed4c5ec21f339f577e5ceb5091b0590fe07dbbabe3dd5be94f26bdd29e2c647, I received a payment of 1.71745255 to my address 1GG8tuJqpUwNTf2BHRjY3unFa9R4hnRpMH. In the same transaction I received payments to several others of my addresses. My client doesn't display that I received payment for other addresses (such as 19BMM9q378xM3k8Afpbhpq1nAJJeQrGZvy). However, it does display that 1GG8tuJqpUwNTf2BHRjY3unFa9R4hnRpMH received a payment of 15.04889331, even though this address has never received this much payment. Is this a bug or a feature? If a bug, is it known? |
|
|
|
Doesn't anyone else think that this is worth some more discussion? It seems to me that the possibility of multiple weeks of a weak network and unprofitable mining is a pretty bad combination. And what if someone that really wanted bitcoin to fail would take an opportunity like this and time an attack on the network. It seems really bad.
Someone please disprove me.
This isn't really a big problem. In the rare case that such an extreme drop happens, we can discuss (here on the forum, for example) and agree to decrease the difficulty manually to an appropriate level. The same people who would panic-stop their miners will also be eager to seek a quick resolution. |
|
|
|
Btw, I am curious as to how useful publishing the share and score logs would be. Particularly whether that ensures pool integrity given that the worker solution is included. I would not be willing to publish the IP addresses of workers but could make previous round sharelog data available less IP address. So, would that be useful to anyone? Does anyone object IE are their privacy concerns here of which I am not aware?
This is a very important issue. I think it will be very useful if you publish such logs. Ideally, for each completed round you would have a table of shares (maybe downloadable in csv format) with the following info: Share #ID, Timestamp, score (as a proportion of the total round score), worker Bitcoin address, hash. In case people are uncomfortable with their addresses' payout info being displayed, you could show stats only for the shares submitted by the user. For this you will probably need some sort of login system. |
|
|
|
|
Show Posts
