Topic: rpietila Wall Observer - the Quality TA Thread ;) - page 131. (Read 907212 times)

It sounds like one of those drastic measures that would probably never actually have to be implemented. Having said that, one of the biggest if not the number one chief threat to bitcoin as a long term store of value is that it could get replaced by an alt. If that ever looked like it might actually happen, I would imagine it would not be difficult to reach a consensus that the above plan would be preferable to watching the value of bitcoin plummet. So it is comforting, at least, to know something like that MIGHT be implement-able.

So, my thought process tells me that perhaps the chief threat to bitcoin is not replacement by an alt, but rather, fragmentation of community consensus. (Which could be the result of threat from an alt, or could come from who knows what.) Methods of managing community consensus is a problem that seems very interesting, although I have not seen it much discussed.

It is an interesting proposal that can work if there is a very clear vote and hence valuation one way or the other. Where it can get real messy and problematic is if there is close to an even split or even significant vote for the minority chain. Then the uncertainty created can cause a significant overall loss of trust. The reality is that a hard fork only works with strong consensus and my thought is that Peter R's proposal will expose that reality. Having said this it may in the end have to come down to a spin off method solution as a last resort.

Edit: The best solution is a hard fork with strong community consensus.

ArticMine - what do you think about the spin off method described in Peter R's post?

Jeff makes an argument that the block size should be a limited resource (akin to the 21 million limit) and that this will incentivize people to build layers on top of bitcoin. Perhaps experience will teach what was not obvious in the early days, which is that running into the transaction limit causes damage to bitcoin's utility that outweighs any benefit of encouraging "layers on top of bitcoin." His argument may or may not be correct, but it doesn't sound to me (a non programmer) to be some idiotic idea that is completely without merit. So here's my question: if the arguments put forth by Jeff in the above post do not stand the test of time, will the proponents of this idea will be too stupid to see it? Because if they CAN see it (and why wouldn't they?), then the problem will most likely be solved.

Sidenote: He also does not like feedback based methods, saying they can be easily gamed. It seems to me it would be easy to design a feedback based method that is prohibitively expensive to game. Just my initial reaction.

I actually dug up the old thread that led to that blog post back in 2013. For those who are interested here is the original thread. https://bitcointalksearch.org/topic/patch-increase-block-size-limit-1347.

Yes 260,000 transactions per day, 3 transactions per second, is the practical limit. The maximum theoretical limit assuming all transactions were ideally optimized is closer to 600,000 thousand per day or 7 transactions per second. Is a technical solution that meets the above quoted requirements possible? Yes there are many including getting rid of the limit altogether as Gavin has proposed. Furthermore a solution very close to above that meets the above quoted requirements is part of the implementation of the CryptoNote alt-coins including its leader XMR (Monero); however virtually all other alt-coins suffer from this very same limitation. The problem is social. There is a significant and influential point of view within the Bitcoin community that is opposed to or at best very resistant to making this change. Furthermore this debate is very old. Here is a post from 2010 that addresses this issue and is in many respects highly prophetic.


I take the point of view that the 1 MB blocksize limit in Bitcoin makes no more sense than limiting the RAM in a personal computer to 640K http://quoteinvestigator.com/2011/09/08/640k-enough/ for the very same reason: Moore's Law. As a baby boomer, I happen to remember that debate well and had to deal with its aftermath.

The time for endless arguments and debates on this issue is over, since we are fast approaching this limit. The time for action is now. This brings me to my next point since this is after all a thread in Speculation: How can Bitcoin investors profit from this and / or protect their XBT investment? There are two sides to consider here:

First (XBT bull) if one takes the 1 MB blocksize limit out of the equation the fundamentals for Bitcoin are otherwise very bullish. Furthermore the most likely scenario, although not certain is that the Bitcoin community will finally get its act together and deal with the 1MB blocksize limit. This would make moving out of XBT into fiat or precious metals a very risky move for a long time XBT investor. The second case (XBT bear) is that the Bitcoin community does not get its act together, we get close to the limit and fees start to rise as a result. It is here where a coin not encumbered by this limit will become highly desirable, and XMR (Monero) is the leading candidate. Now and this is critically important XMR must stand on its own merits with good reasons to appreciate in terms of XBT for reasons completely unrelated to the to the 1MB blocksize limit issue. It is for these reasons that after reviewing this thread https://bitcointalksearch.org/topic/rpietila-altcoin-observer-624223 and after performing my own independent due diligence on XMR that I have moved approximately 15%, by market value, of my XBT holdings into XMR. This is to both protect my XBT position and potentially profit not only from XMR making bronze or silver on its own merits, but from also the small chance of it actually making gold as a result of the turmoil associated with Bitcoin reaching the 1MB blocksize limit.

He's one of two on my igbore list. He's a Bitcoin begging, early adopter jealous idiot. Please ignore him.

http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html

Hard to believe he can mean serious with that idea.

Does that mean you are going to force people who do not want to be controlled by this computer to move elsewhere? Or can they stay where they are and live by their own rules? Is this a purely voluntary system? Opt-in, opt-out when you want? Abide by the computer's decisions when you want, don't abide by them when you don't? Or will there be an enforcement mechanism? If so, how do you enforce the rules?

To address all these points --

1. I never said it wasn't there, I just said that it shouldn't do more than just provide that functionality. The idea of going beyond the basic protocol functionality introduces a gray area between protocol and policy.

2. Mining pool software and solo miners call bitcoind (or at least a custom-compiled version of bitcoind), are you somehow insinuating that miners all use libbitcoin or have all written their own top secret independent implementations?

3. The notion of the reference client being a wallet is being phased out gradually anyway per statements made by Gavin previously.

4. Ideas that you disagree with just because you're mistaken about them do not constitute "FUD".

that's still there

there is no reference client for mining. all major pools have their own thing.


the reference client is also a wallet, therefore it is ok to have some estimation function inside. there is also no barrier in implementing your own function to do that!
my guess is, there will be different methods to estimate the fee and the data of the reference client is more like a monitoring tool (that's how I see it currently).
there is also no decision made regarding the protocol itself.

hence i regard what you write a bit like FUD, sorry for that.

They will naturally as they see it's just better. Of course you are free to live outside the civilized world.

I disagree philosophically with the direction Gavin is taking this where floating fees are integrated into the reference client.

The methodology of estimating them is never a non-controversial undertaking, and there are no structural limitations that prevent data and market information determining tx pricing from getting decided outside of the Bitcoin network. All the reference client actually has to do in this respect is create and sign raw transactions through an API that provides all the relevant parameters, including tx fee itself. On the mining end, all the reference client has to do is provide configuration parameters robust enough for pools and solo miners to decide their tx fee policy, or integrate through API to take external data about appropriate pricing in order to select transactions for candidate blocks as desired.

The decision on methodology of pricing transactions is properly offloaded to wallet and mining pool software developers, and the market will decide the correct infrastructure for tx fee price discovery. Not some guy working on an institutional stipend.

If transacting is prohibitively expensive, then Bitcoin might lose users, and the resulting loss of adoption turn to loss of network effect, vicious circle, etc. So it is not trivial to let the fee shoot up, but we are well on the safe side with sub-$1 fees.

Like I said a week ago, in very few applications, is the total transaction cost less than $1 anyway even if the "handing money" part were free (as is the case with cash).

well, why does it need to be cheap when it is still useful? the tradeoff is this: either the system starts to fall apart by a combination of growing too fast, no incentive for miners and flaky behaviour -- or a well working and tested system, where there is a market for the fee to use it.
i lean on the side of caution, better a well tested system than killing it by a step forward which cannot really be undone.

also: a higher fee for bitcoin just means, that a new market opens up: one for other coins which do what the pissed-off users demand. e.g. really fast transactions of small amounts, etc.

I am not in favor of artificially reducing the blocksize. But if the technology (storage space, propagation speed of blocks etc. similar factors) demands it, then I believe typical transaction fees in the $1-$2 range (50 times higher than now) won't kill it, ie. the Bitcoin's unique characteristics of a secure store-of-value ledger are unaffected even if the transactions were more expensive.

Somewhere else by Gavin...

But what about when blocksize is too small that the fees become high lowering BTC's usefulness as a cheap payment system.

currently, a client like bitcoin core -- and the floating fees are ONLY about clients sending out TXs, nothing related to miners -- has a fixed minimum fee. other online wallets also have a fixed minimum fee, etc. you can also send out TXs with any other fee, also zero, but it's just a guess out of your butt.

what you want is actually this: higher fee -> quicker inclusion in the next block. lower fee -> maybe wait an hour or two, but it will get included.

solution:
1.  let your client monitor the last 2500 successfully confirmed transactions (ignore what's currently in the mempool or what your client hasn't seen so far) whereas they are grouped by the number of blocks they had to wait until they are confirmed in bins of maximum size 100,
2. calculate for each of them the TX-fee per kB,
3. sort them by this value and put them into 25 bins of size 100 each (and yes, if you don't have 2500 TXs, bins are smaller),
4. select bin number "n" for your desired number of blocks "n" you want wait for inclusion -> calculate the median TX-fee of that bin number "n" and multiply it by the kB your new TX.

For example, this is what my dev client says are the fees to be included in the next "n"-th block: