|
Blocks don't have the discriminative power to determine who it is that found them.
In theory (not part of the protocol), the transaction could include requirements for the block header to be included. So for example it could specify that only specific version numbers in the block header are allowed. However, the version number can be faked, it doesn't tell you what the miner is really running.
The simplest solution is probably to just hand-pick who you are submitting your transaction to; if they don't broadcast it, only those who received it can mine it.
In any case, I think the problem is overstated - we didn't have a problem when ATI was the only manufacturer of mining hardware, and I don't see how mining ASICs would be much different. And, boycotting ASIC miners as a method of combating the perceived problem suffers from tragedy of the commons.
|
|
|
|
Is it possible to calculate in advance how many shares will be included in the window? I'm thinking in terms of an implementation using a shares database (e.g., SQL). Before I begin collecting shares, can I compute approximately how many I will need to look at?
Yes, it will be approximately X * D. Depending on how you intend to use the approximation, a better one can be found. My goal is to limit the number of rows fetched from the table to reduce server overhead. I would of course want to avoid the possibility of under-estimating, else the total payout wouldn't equal the block reward. Would I need to add anything to X*D to avoid underestimation? If D1 is the current difficulty and D2 is the previous difficulty, an upper bound would be X * max (D1, D2) + 3. Taking the max makes sure that if the difficulty has just decreased, you won't miss the shares needed at the previously high difficulty; the +3 term helps with rounding, off-by-one errors etc., it can probably be tightened but it costs very little so I wouldn't bother. Note that if the window spans more than one difficulty adjustment it may not work (you might need the maximum over previous difficulties as well) but that's not a situation I believe should happen. If miners submit shares with difficulty greater than 1 this can be decreased. If d is the minimal difficulty that they can submit (assuming that throughout the window you only have shares with this difficulty or higher), and upper bound is X * max (D1, D2) / d + 3. |
|
|
|
Profitable mining reqires ASICs, mining itself can be (still) be done easily on general purpose CPUs. Depending on the actual purpose, mining shares might actually be "useful".
Think for example about my fictional website that will disable ads for the next link you click if you submit a valid share. You have a small "account" that can be filled up to a certain limit with "clicks" that you gain via mining. That's ~60 Satoshis per click at diff-1 at the moment. Not a lot but still maybe more than one could get from an adblock user + you can do some interesting things with your website "currency" maybe.
It takes about half and hour to find a share on a CPU. There is absolutely no revenue that can be made this way by the site owner. Users will notice that their computer slows down, makes noise and heats up, and the smarter ones will realize power is being consumed. This will drive away all the profitable users, all in the name of "sticking it" to the adblock users and making a millionth of a cent off them. |
|
|
|
|
Bitcoin mining requires ASIC devices which a typical user does not have. With a CPU it will take days to generate a single cent (consuming orders of magnitude more than that in electricity). For scrypt-based alts it's better, but not by much.
|
|
|
|
Is it possible to calculate in advance how many shares will be included in the window? I'm thinking in terms of an implementation using a shares database (e.g., SQL). Before I begin collecting shares, can I compute approximately how many I will need to look at?
Yes, it will be approximately X * D. Depending on how you intend to use the approximation, a better one can be found. |
|
|
|
Geez. Make one comment and everyone jumps up my ass.  yes. and you deserved it because you was a tard. Crazyates is absolutely correct. Hz means "cycle per second". Calculation of each hash does not define a cycle because multiple hashes are computed in parallel. A "cycle" here could be the time from one calculation to the next; if multiple units are hashing together they increase the hashrate, but they do not magically shorten the cycle. Example: We have a device for which each clock cycle takes 1ns. Its clock rate is therefore 1 GHz. It takes 10 clock cycles to compute a hash. So the hash calculation frequency is 100 MHz. The device has 1000 cores calculating hashes in parallel. So the hashrate is 100 GH/s. But there is nothing here working at 100GHz because there is no cycle that takes only 0.01 ns. The given "counterexamples" for varied uses of Hz all involve actual cycles with period that can be inferred from the stated frequency. Kish = KH/s
Mish = MH/s
Gish = GH/s
Tish = TH/s
I think I'll adopt this. |
|
|
|
Is there an option in the creation of a transaction that makes it so that the value of the outputs equals the value of the inputs? Otherwise, consider the transaction invalid. Alp is saying only if the outputs>inputs is invalid. I am looking for, outputs<>inputs is invalid, but it sounds like this is not currently possible?
Difference between inputs and outputs is the transaction fee, not the change. The change is one of the outputs. I'm still not sure what you mean (or wish to accomplish) by making some form of transaction "invalid". Are you looking for such an option in some GUI? If you're creating the transaction programatically, can't you just... Not include change/tx fee in it? |
|
|
|
That is what I thought.
If I were creating a transaction and was provided the input for my transaction (i.e., in hash form), how can I specify the value of the output? My concern being, I do not want change created from the transaction I am creating.
I don't understand what you're asking. |
|
|
|
|
Absolutely nothing. If you could deduce anything it means the hash function is broken. You can't even tell if this hash actually represents a valid transaction.
But assuming this hash is different from the hash of any transaction you know, you can tell that if in fact it is a valid transaction, it is a transaction you don't already know of.
|
|
|
|
Now I'm even more confused. The problem is that until demonstrated otherwise, remaining funds = original funds - funds paid to yourself. So in this case you still keep all of your funds and some of other people's funds.
Specifying in advance what is the salary you intend to receive for full-time employment in this (which AFAIK you have not yet done) will be helpful.
I don't plan to take a salary at all I was under the impression that you intend to quit your day job and instead receive a salary from the Mastercoin project. Is that correct? How much money I withdraw for work on this project
What does withdrawing have to do with anything? The money in the Exodus address isn't yours, you can't withdraw it. It belongs to the Mastercoin project and a salary can be paid to you. will be a negotiation I have with my wife
That was my point, what assurances do we have that the "negotiations" will not result in you taking a salary of $100K / month? Sounds like your wife is a net drag on investors profits. I would hire everything out if I were you because you cannot use your wife as an excuse for charging insane rates.
That is a great idea - I've thought about doing some bounties, and it is likely that there will be some. Bounties have their own set of problems though, since somebody might work many hours and not get paid because somebody else collected first. Or, you have to offer the bounty to just once person who might not do a good job. Still, I would LOVE to use the Exodus Address funds to pay somebody else to work on this! That also was my point. With an upper bound on your own salary, it becomes practical/necessary to hire other people as well. |
|
|
|
Some of you seem to think that my own money is not at risk if this project fails. That is not true. If this project fails (probably because somebody else does something similar, but does it better and/or faster), I would return any remaining funds to investors. I would get a partial refund just like everyone else.
The problem is that until demonstrated otherwise, remaining funds = original funds - funds paid to yourself. So in this case you still keep all of your funds and some of other people's funds. Specifying in advance what is the salary you intend to receive for full-time employment in this (which AFAIK you have not yet done) will be helpful. |
|
|
|
Yes, I will still control the funds I use to purchase MasterCoins. That's why I can go all in, while the rest of you have to decide if I'm nuts, a scammer, or maybe could really pull this off  I would like to emphasize that, since you control the exodus address, it is important that you buy only few mastercoins and furthermore that you are completely transparent about how much you buy. Of course, this doesn't apply to buying them on the free market later.
As implied above, I actually intend to buy a large number of them - probably around 24 hours after the announcement. I really believe this will work, and I want to own as many of them as possible. In other words, you're taking none of the risk and getting all of the reward? I like you but I really don't like where this is going, you'll need to be extremely transparent (and with reasonable expectations set forth in advance) for this to make any sense. |
|
|
|
It's worth pointing out that the units for velocity and acceleration, two of the most important quantities in physics, don't have a special name. We just use meters per second and meters per second squared. Hashrate. Defined as Hashes-per-second. Symbol 𝓗. T𝓗 = Terahashrate, etc.
Hashrate is the quantity being measured. It's not an appropriate name for the unit. (Also, I'm using 𝓓 for difficulty.)
Using D or 𝓓 for the difficulty is fine. But difficulty has no units, it is defined as the ratio between the max target and the current target, and is thus a pure number. |
|
|
|
Nobody has sent any coins there yet though, and I am delaying my own purchase so I don't make everyone mad by getting the best exchange rate moments after the announcement I would like to emphasize that, since you control the exodus address, it is important that you buy only few mastercoins and furthermore that you are completely transparent about how much you buy. Of course, this doesn't apply to buying them on the free market later. |
|
|
|
|
Terahash, not terrahash. Terra = earth, Tera = SI prefix based on teras = monster.
|
|
|
|
2) Seems to assume that one cannot control prices by controlling supply. I believe that is false. While the fed has indeed printed a lot of money, they could drive the value of the dollar to zero if they wanted to print billions of dollars and give them to every person on the planet.
Increasing supply to decrease price is the easy part. Decreasing supply to increase price is the impossible part. |
|
|
|
|
Is this for real? This is huge (in the negative sense) news if true.
Is the source credible?
|
|
|
|
Meni's paper is a very good read. Here is a table from his paper and the two notes that followed.
These two notes are actually part of a list of 7 notes which has some figures in the middle. |
|
|
|
Seems like Meni is taking you up on the security side. Statistics aside, lets not forget the importance of that first confirmation! I've met dozens of people in coffee shops helping them to get some bitcoins. In purely human terms, there is a big difference between 5 and 10 minutes. 5 minutes is fast food, 10 is not. You expect putting gas in a car to take 5 minutes - 10 would be a drag. 5 minutes just feels a lot faster than 10. And since that first confirmation is way, way (maybe 100x?) more secure than an unconfirmed one, everything happening twice as fast would be very convenient for the bitcoin community as it is today. I agree that in the future there will be lots of solutions to these issues, but to get there from here we need to keep people happy and things convenient so that the community lives on.
On the other hand, in practice even 0-confirmation transactions are reasonably secure. There is no need to wait for confirmations in a coffee shop. I'm speaking specifically about confirm count without regard to latency. Under the assumption that orphaning isn't an issue, with a lower mean block time you need to wait less on average for a given level of security. For example, let's say that with either 5 min or 10 min mean time, orphaning isn't an issue. Let's say also that you want a 10%-hashrate attacker to have less than 2% chance of successfully double spending, so you wait for 3 confirms. If 10 min is the time constant, you have to wait 30 mins on average. If it's 5 min, you have to wait 15 mins. This is an advantage of a lower time constant, as suggested by the OP. In the case where an attacker is purchasing his hashing power on-demand, wouldn't halving the block period also halve the cost of any n-block chain reversal, since on average the attacker would need to rent the same fraction q of total hashing power, but for only half the time? Yes, but that's negligible since for <50% hashrate, success probability decreases exponentially with confirmations. In my example, if the block time is 5 min, the merchant can wait for 1 more confirmation (20 mins, still much less than 30), cutting success probability by a factor of 3 thus tripling the average cost of a successful attack. |
|
|
|
|
Show Posts
