But what actually, prevents an adulterated client - with another reward set on the code above - to create blocks that are accepted by the other nodes?
Nothing, as long as the reward is smaller than the maximum you outlined. It actually already happened - there will never be exactly 21 million BTC mined. |
|
|
|
BIP32 ( https://en.bitcoin.it/wiki/BIP_0032) sounds nice... You'd generate new addresses on the fly and don't need to send the coins elsewhere. If you want to _send_ payments though (to customers, not yourself) then you need something else, for _receiving_, BIP32 it is probably. |
|
|
|
So it'd be like the search engine circle-jerk back when the most relevevant possible page, in the engine's eyes, was its own output.
So we got what, a big three in each part of the world?
Modula the fact that blocks are not cultural/linguistic the way web pages are, so maybe the big three can be the same big three world-wide, no "you don't even speak our language, you don't understand the nuances of our pages, thus your searches suck" effect helping very-different cultures to prop up a big one (do they even get to have a big three, or are the regions where the big three aren't the biggest only have a big one of their own not their own whole big three?)
Way to not centralise. Are the big number two and big number three still shrinking the big one or are they becoming more equal?
-MarkM-
I'm not sure what you try to tell me about block size with this...? If that is a (bad) attempt at sarcasm, please keep that out of the debate and post some clear arguments/reasons. As far as I get it, you're saying that there is a threat of centralisation and 3 miners competing in an endgame scenario? Sorry, but it is really not clear to me what point you want to get across. |
|
|
|
If you disagree with his explanation, can you refute it specifically? Of course I can, and this has been explained MULTIPLE times. Miners want to maximize their revenue. Users want to minimize their fees. If miners always include every transaction regardless of fees, there's no incentive for users to pay fees. The only way for a market for fees to emerge is if there is competition for transactions in a block. That means that miners have to leave some transactions out. But which transactions should they drop? Obviously...the ones with the lowest fees per kilobyte. Or to put in other terms, a market for fees can only emerge when block size is limited. I strongly disagree with this, as limited block size is not the only limitation in the system. I agree that miners want to earn fees and users want to pay as few fees as possible. Miners however in your (limited block size scenario) not only can leave transactions out of blocks, they have to leave them. Even if there are more transactions out there that the miner would like to include, he has to choose as subset of the available ones. Even if miners only can ignore transactions, they will do so - including more transactions means slower block propagation times and as already said in a different thread, bandwidth is still a limiting factor in an unlimited/virtually unlimited block size scenario. People are getting worried that miners might start to inflate blocks to drive other miners out of the network. Still having a bunch of miners that can only send blocks with a 100% used 10 GBit link between them would just mean they'd have the longest chain but nobody can use it, as it is not accessible to anyone outside any more (sending data out of the mining network would mean the miner gets driven out of business by his colleagues that have no more need for him). I'd like to call it the miner circlejerk scenario. Anyways, since larger blocks = higher risk for orphans = fees need to be higher to migitate that risk (e.g. 5% orphan risk = needs 5% more fees than needed with 0% orphan rate), miners still can and will create a market for fees, even with (practically) limitless blocks. |
|
|
|
My own question: The bitcoin network has operated well under the limit so far. If arbitrarily increasing the block size were so advantageous to certain miners, why hasn't it already been done? We should have seen the limit maxed a long time ago, yes?
Increasing it beyond 1 million bytes would require a hard fork. We are close to reaching the 250k bytes "soft limit" of bitcoin-qt however, mostly "thanks" to Satoshi's dice. Writing custom rulesets requires work and this was not necessary so far, there are actually no real specialized "mining" bitcoind implementations out there as far as I'm aware. Everyone running a full node has to store currently ~2.5 GB of SD transactions alone. Currently the rules in bitcoin-qt are quite tight concerning "spammyness", also quite a few pool operators are as far as I see it rather interested in the long run than risking something by making a quick change for a few extra coins (=accepting more spammy transactions with and maybe even without fees). |
|
|
|
|
Well, Dwolla is quite US-centric as far as I know and probably doesn't offer something different than PayPal (which is NOT included on the trends list...).
Ripple and the freshly launched "Masterpass" by Mastercard might be something to watch as well as Google wallet.
|
|
|
|
there are fees paid even though there is still quite some room to grow and block subsidy is high. Did we forget that clients will only relay transactions through the overlay network if they have a minimum fee attached (computed based on the size of the transaction and the age of the coin)? Tsk...tsk... This is not a hard rule and you could directly connect to a "friendly" miner who also mines spammy transactions to get these into the block chain. Also I can be that miner myself. This is like the 250kB "limit" that currently seems to be something where people bump against. I see your point that the network forces some people right now to pay fees, but the same effect could be done if miners start to claim that they won't mine these spammy transactions. |
|
|
|
Are you claiming that you have a negative house edge in the whole game or are you just saying that currently the "house" has a bad luck streak and is for some (limited) time in the negative? I'd rather say "play roulette against a currently unlucky operator" rather than claiming to have a negative house edge in a game that does normally have a positive house edge...  |
|
|
|
|
I personally really believe that mining does FOLLOW the bitcoin price, meaning a miner will switch off some hardware if it doesn't pay any more. I do not think that people will start to pay more USD for a BTC just because somebody brought online a few more ASICs.
Looking at difficulty data + MtGox prices so far seems to support this.
|
|
|
|
|
What should be my motivation as a user anyways to spend time (and potentially money) on rating somebody?
If everybody rates merchants, my rating is irrelevant and if nobody rates, I don't gain more information from rating as well + the rating website would be irrelevant.
|
|
|
|
I will check those out, and then delete this post. If that is possible.
Now you can only claim I changed this quote!  Gribble is not 100% as you describe (I don't think it provides a general API) and ratings are not done by "donations", but as I said, trivial amounts of donations can be faked and nontrivial amounts are too expensive to spend on ratings of merchants that don't benefit you as customer. |
|
|
|
If typical "tips" used as reputation are low, what stops me as merchant from simply creating as many addresses as I need, fund them and send tips? There is no real way of telling how many addresses a "wallet" has - if you require the tips to be "untainted" you can only tip once from MtGox, on the other hand you'd just promote coin mixing services. If you don't watch taint at all, you can just send 1 BTC in 1000 transactions over time and have a huge reputation (compared to what others might tip) and then start scamming. Also, this system already exists and is I think even older than MtGox... please look up the Bitcoin WoT (Web of Trust) and Bitcoin-OTC.  |
|
|
|
The name of the game is keeping the block space as scarce as possible, encouraging fees that will eventually have to cover the costs of securing the network but not making it too scarce so that Bitcoin can scale batter. If blocks are basically limitless (= have a limit that only serves for DoS protection of somebody mining a 10 TB block, i.e. a hard limit for the next decade of 1 GB/block), your argument would be that this means the total fees per block would be lower than if the limits are tight (= users actually not only have to convince miners with their fees to include their transaction but they also need to make their trasaction as small as possible or for example fitting in between existing transactions or combining a lot of these to make sure they are as efficient as possible)? Block space currently is quite arbitrarily chosen at a quarter of the actual limit in bitcoin-qt and most miners even follow this ruleset. Still there are fees paid even though there is still quite some room to grow and block subsidy is high. I'd also like to see a comment on a "too high to reach without malicious intent" block size that does not limit miners to include transactions based on scarce block size but only on their own metrics (e.g. "spammyness", "fees per kB"...). Something maybe along the lines of "10 (100?) times the median (not average, to remove potential outliers) block size of the past 4 years" adjusted together with the block subsidy every 4 years or even adjusted every 2 weeks (then it might be too easy for attackers to shift the median, but it might be easier to recover/grow as well) with the difficulty. Again the goal should be that the block size never limits miners at all on deciding which transactions to include. |
|
|
|
While we ponder this, if you are worried about this, there is a fairly straightforward workaround that will make you immune from this.
Run two bitcoin daemons. One that is a full peer in the network, but has an empty, never-used wallet.
And another with a full wallet that connects to the full peer. You could even run them both on the same machine (you'll use double the CPU and disk space, unfortunately). If you run (or know) a full node that you trust 100%, there's no need to replicate the block chain - the biggest amount of data you might need is a listing of all unspent outputs, the minimum amount would be probably the unspent outputs of your own addresses (doable now with bloom filters in 0.8 as far as I understood) I think the main issue with this attack is still that Bitcoin (the "finance application") and bitcoind (the "full network node") started and still are closely interlinked. I guess in the longer run something like the approach by the armory client will emerge, where the node does not know and care anything about a wallet and the finance application won't know anything about the block chain but has to trust a node (most likely on the same PC/installation). |
|
|
|
29.25 BTC sent to johndedong ( https://blockchain.info/address/14gnjyTXGvS4ZYTigUkVCtfVQ931jNQh8q) - sorry for the slight delay (though you won't get the money anyways for some time until friedcat releases the shares to john), I expected your "2 days or so" for escrow addresses to be longer than it was and just came back from 2.5 days on the weekend without internet... Please confirm or deny hat I still won the shares (you said you sold all 850 shares - but I'm obviously not yet on the list who paid the escrow), so I can work with John about potential reimbursement (if needed). |
|
|
|
|
Adding a "Data directory" field in the options I guess.
That way only maybe a "datadir.conf" file would be at the default location pointing to the actual location.
|
|
|
|
Is that allowed?
No. You need to wait 100-120 blocks before you may spend a coinbase output. Even if you mine the block yourself? In other words, is a block seen as invalid, if it contains a transaction that spends a coinbase output? |
|
|
|
My argument that even with an unlimited block size there would be an equilibrium (= a point where even transactions with fees might get rejected by miners because it costs them more to include these than to ignore them) goes like this: The longer it takes you to get out a block to at least 50% in hash rate of the other miners, the higher the risk of stale blocks. Probably miners will need to have a certain total fee in their blocks to operate (e.g. 1 BTC). With the lowest fees possible (1 Satoshi flat) and an average transaction size of 0.5 kB this means blocks would be around 50 GB in size. However it might make more sense to ensure that blocks don't get much bigger than 100 MB, otherwise you risk an orphaned block and have to take this into consideration (e.g. with 10% orphaned blocks you need 1.1 BTC in fees per block). The chance for orphaned blocks increases probably not linearly (Oh Meni, where art thou? ) so there will be an ideal block size for any desired total fee amount, even if it is not limited at all. The main factors that play into this are eventual optimizations in announcing new blocks (e.g. sending transaction hashes first and then only the transactions some other miner didn't know about) and general bandwidth + network latency between miners. In another thread ( https://bitcointalk.org/index.php?topic=144895.0) it was already feared that this can create situations where it makes more sense in sending your blocks only to other miners that have a high hash rate and are quickly reachable which means you encourage more and more centralization (--> lower latency and much higher bandwidth if you send between two pools in the same data center) and could drive out small distant miners. |
|
|
|
[...]
75 @ 0.39 ;;;;; 29.25 sukrim
[...]
Thanks.
As agreed via PM with Goat, John (Johnthedong) would be an acceptable escrow agent for both of us. I'll post relevant transactions/agreements etc. in here to have a public record of that stuff. |
|
|
|
|
Show Posts
