because their opinions only partially overlap with Gavin's? |
|
|
|
tl;dr starting from Jan 2017 a 4.4% increase every 97 days, i.e. 17.7% per year |
|
|
|
what does it mean when Wladimir "merges" a BIP over on github? ? |
|
|
|
the exchanges is still going, if you have five mins just read it. Mike made a few others valid points imho in subsequent messages. And those from Thomas Zander deserve a quote. > The only way to see how fees would work in practice is to have scarcity.
This skips over the question why you need a fees market. There really is no
reason that for the next 10 to 20 years there is a need for a fees market to
incentive miners to mine. Planning that far ahead is doomed to failure.
|
|
|
|
The explicitly stated goal right in the BIP62 document was a reduction in dependence on OpenSSL for consensus; which the truth and nearly the whole truth all that was missing was that the concern was less theoretical than presented. But yes, the unstated privately known consensus vulnerability was a driving force for clearing up that ugly corner with BIP66 immediately rather than mopping it up as a side effect of BIP62. Especially due to fact that BIP62's progress has been slow-- and had grown over complicated. The fact that BIP66 accomplished one of the necessary steps will make BIP62 or its logical successor easier to move forward. If you note from the timeline that BIP62 had already been revised to accomplish a BIP66 like goal prior to us knowing about that specific vulnerability: We were aware of the risk class in principle before having specific knoweldge with enough concern that we thought it was worth closing off. Knowing that it was _actually_ exposed had only an impact on timing and sequencing; and only after it was clear that BIP62 was not rapidly converging (unfortunately, in spite of much progress on BIP62 we continued to find problems with it). It's sad, there is a vastly superior-- simpler, more comprehensive, and with secondary benefits like enabling more degrees between full and SPV-- malleability 'fix' in elements alpha but I don't have any way to get it into Bitcoin, BIP62 is disappointing by comparison (brillant ideas welcome). do you care to elaborate on that better fix? especially on the reason why it cannot be "ported" to bitcoin. thanks in advance. |
|
|
|
If anything, we should get the blocksize to the largest rationally supportable size
This is exactly where reasonable people differ. That is a key word right there "reasonable". I certainly haven't had any great epiphany as to how to choose the correct size or how to make it a reliably updated thing. Predictability and anything that removes human consensus making from an ongoing process is what I would favor. The only way to remove human consensus from the ongoing process is to leave it exactly the way it is. No changes to the consensus rules ever (MP argument). That is btw pretty much Wladimir's view. He's not going to back any change that doesn't have human consensus. So you either have human consensus or, removing it from the process, no changes at all. i wonder what all those guys will say next year when the Blockstream guys want to change the code for SC's and LN if Gavin objects. Sidechains can be done with a soft fork, which means all they need to do is sign up miners (and of course find customers who want to use the side chain). It doesn't require a global consensus. But if SC, and also LN, needs a block size increase in any case ( source, source2), doesn't this mean that introducing SC implies an hard-fork? |
|
|
|
Increasing block size does add features (and/or bugs), in the form of higher tps and whatever concomitant other new auto/adaptive regulation mechanisms come along with the eventual solution. 100k max tx size is probably only the first such required adjustment. In the very thread you linked gmaxwell said solution proposed by gavin adopt an indirect and simplistic approach, to which gavin replied: But I would REALLY hate myself if in ten years a future version of me was struggling to
get consensus to move away from some stupid 100,000 byte transaction size limit
I imposed to mitigate a potential DoS attack.
So I agree, a limit on sigops is the right way to go. And if that is being changed,
might as well accurately count exactly how many sigops a transaction actually
requires to be validated...
the bolded part really makes me laugh, though. that said it seems that there won't be any cap to tx size for the moment. |
|
|
|
If we are to think about Bitcoin in the long term, and given Bitcoin's reasonably critical economic mass of ~$5 bil, current temporary block subsidies can be discounted as we consider fundamental questions about how and when to change one of Satoshi's Holy Numbers.
To which holy number are you referring to? One last question: what's your position on block size limit, never change it or change (in the way you like the most) in the future? |
|
|
|
if memory serves both Adam Back and Joseph Poon said that SC and LN respectively needed a bigger block in any case.
(I'm actually in a hurry as soon as I've time I'll post reference to the source)
There is a huge difference between "a bigger block" and proposing to scale block sizes upward to the moon in an attempt to meet the core scaling demands of the system that way. Sure there's a big difference and I was not endorsing any particular proposal on the table, be it BIP 100, 101, 102 you name it. I just wanted to make clear that all the parties (modulo MP) agree on the fact that in a way or another the 1MB max block size has to be changed. |
|
|
|
And now icebreaker is quoting a guy who's only contribution is a failed OS architecture, probably typing it from his incredibly successful linux android or windows monolithic kernel. And yes I tried minix. It crashed after a few hours.
And to add irony on top the argument actually adds ammo to block size increase crowd because lightning or sidechains will be an ESSENTIAL part of a 1MB chain. There won't be any value to users if BTC is running if lightning or SC fails because there isn't space on the chain for users.
I'm guessing ice is still in school regurgitating here the garbage his professors (who likely never worked on a million+ LOC project in their lives) feed him.
Whoah, that's a bit harsh. I wouldn't agree on saying minix is Tanenbaun only contribution, there's so much more from him, despite being proven "wrong" on the specific monolithic/microkernel debate. Apart from that, I agree with you on SC and LN (currently mostly vaporware) being an essential part of a 1MB chain in order to make it valuable. if memory serves both Adam Back and Joseph Poon said that SC and LN respectively needed a bigger block in any case. (I'm actually in a hurry as soon as I've time I'll post reference to the source) |
|
|
|
Garzik Predicts ‘Chaos’ If Changes Made to Both Fee Structure and Block Size http://cointelegraph.com/news/114966/garzik-predicts-chaos-if-changes-made-to-both-fee-structure-and-block-size“First, users & market are forced through this period of chaos by ‘let a fee market develop’ as the whole market changes to a radically different economic policy, [one] the network has never seen before. Next, when blocks are consistently full, the past consensus was that block size limit will be increased eventually. What happens at that point? Answer — Users & market are forced through a second period of chaos and disruption as the fee market is rebooted again by changing the block size limit.”
|
|
|
|
the thing that I can't grok at all about arguments contrary to max blk size increase is the "fee-pressure" one.
isn't the fixed and over time decreasing tokens emission already supposed to take care of it?
why do we need to anticipate the time when miners should sustain theirs activity through fees?
When Satoshi designed Bitcoin he expected most users of it to be able to mine using their own full nodes, receiving block rewards, for a lot longer than actually happened, ASIC farms and mining pools hijacked the reward emission to a certain extent. So people who run full nodes are often not mining and not compensated for handling ever larger blocks. So the idea of higher and higher fees is to force tx volumes lower than what the market and ecosystem would like, purely in the theory that it helps the non-mining nodes with less overhead. The real solution to this is a combination of several things: node services payment channels (like JR has written about), blockchain pruning, Lightning Network type off-chain services, and IBLT which reduces the block propagation bandwidth requirements. If all these changes were happening then there would be no pressure to try forcing a (misguided) centrally planned fees-market. So they are trying to solve the ever increasing burden of running a full node for a non miner indirectly, through the mean of a side effect of an anti-DoS mechanism. Am I right? if I'm correct, It seems to me a rather convoluted way of thinking, why not just say that instead of use the fee pressure rethoric? why not embrace JR's free market idea for full node services? |
|
|
|
|
the thing that I can't grok at all about arguments contrary to max blk size increase is the "fee-pressure" one.
isn't the fixed and over time decreasing tokens emission already supposed to take care of it?
why do we need to anticipate the time when miners should sustain theirs activity through fees?
|
|
|
|
thanks for the link. I have to main points about it, firstly I don't know how thread ranks distribution is correlated to users opinion about the thread itself. Secondly, even if we get some way to say that a particular ranks distribution means a general approval for the thread among hero/legendary users, going from this to say that "Monero is considered by many legendary/hero members to be the next step in crypto" is quite a big jump, isn't it? Your request for citation was reasonable. Gainsaying and nit-picking at the requested citation, upon it it being graciously provided, is not reasonable. Nobody is stopping you from investigating "how thread ranks distribution is correlated to users opinion about the thread itself." RTFA. Stop moving the goal posts because you don't like the fact my assertion has a reasonable basis, demonstrated with empirical data. I'll save you the trouble. The Hero/Legendary posts in the XMR thread are positive and supportive, while the ones in the other threads are significantly less so. Notice the number of hero and legendary members? Darkcoin has 57 (2.23%) hero and 9 (0.35%) legendary versus Monero with 56 (3.94%) hero and 12 (0.85%) legendary. Percent wise monero has attracted more than twice legendary members and almost twice hero members.
In other words, it seems oldtimers gravitate towards monero/cryptonote and ignore darkcoin.
Sorry but posts frequency don't say anything about the opinions of thread's participants. TheKoziTwo's chosen the right word: gravitate. Mind you even JorgeStolfi gravitates a lot towards Btctalk "Speculation" section with more than 4K posts, but this does not mean that he's a bull... on the contrary. I'm not moving the goal posts I'm just saying that posts frequency by hero/legendary members can't say anything about the contents of such posts. As you already acknowledged to estimate if those hero/legendary users support the thread you need to perform a qualitative analysis, I.e. you have to read those posts. That said if you're interested in my opinion I wouldn't touch DRK with a ten foot pole, and as I've already said, a mix of due diligence and gut feeling, ascribe myself among the group of people that have a quantity > O of XMR in their crypto currencies portfolio. I've read the posts, and so can you. I also wrote many of them, as I was participating in the thread. Yes, Monero is considered by many legendary/hero members to be the next step in crypto. No other coin even comes close. so we agree on the fact that posts freq are useless to validate the affirmation at hand, whilst a qualitative measures (i.e. read the posts) is needed. fair. |
|
|
|
thanks for the link. I have to main points about it, firstly I don't know how thread ranks distribution is correlated to users opinion about the thread itself. Secondly, even if we get some way to say that a particular ranks distribution means a general approval for the thread among hero/legendary users, going from this to say that "Monero is considered by many legendary/hero members to be the next step in crypto" is quite a big jump, isn't it? Your request for citation was reasonable. Gainsaying and nit-picking at the requested citation, upon it it being graciously provided, is not reasonable. Nobody is stopping you from investigating "how thread ranks distribution is correlated to users opinion about the thread itself." RTFA. Stop moving the goal posts because you don't like the fact my assertion has a reasonable basis, demonstrated with empirical data. I'll save you the trouble. The Hero/Legendary posts in the XMR thread are positive and supportive, while the ones in the other threads are significantly less so. Notice the number of hero and legendary members? Darkcoin has 57 (2.23%) hero and 9 (0.35%) legendary versus Monero with 56 (3.94%) hero and 12 (0.85%) legendary. Percent wise monero has attracted more than twice legendary members and almost twice hero members.
In other words, it seems oldtimers gravitate towards monero/cryptonote and ignore darkcoin.
Sorry but posts frequency don't say anything about the opinions of thread's participants. TheKoziTwo's chosen the right word: gravitate. Mind you even JorgeStolfi gravitates a lot towards Btctalk "Speculation" section with more than 4K posts, but this does not mean that he's a bull... on the contrary. I'm not moving the goal posts I'm just saying that posts frequency by hero/legendary members can't say anything about the contents of such posts. As you already acknowledged to estimate if those hero/legendary users support the thread you need to perform a qualitative analysis, I.e. you have to read those posts. That said if you're interested in my opinion I wouldn't touch DRK with a ten foot pole, and as I've already said, a mix of due diligence and gut feeling, ascribe myself among the group of people that have a quantity > O of XMR in their crypto currencies portfolio. |
|
|
|
thanks for the link. I have to main points about it, firstly I don't know how thread ranks distribution is correlated to users opinion about the thread itself. Secondly, even if we get some way to say that a particular ranks distribution means a general approval for the thread among hero/legendary users, going from this to say that "Monero is considered by many legendary/hero members to be the next step in crypto" is quite a big jump, isn't it? |
|
|
|
Yes, Monero is considered by many legendary/hero members to be the next step in crypto. No other coin even comes close.
citation needed? I belong to the group of people that think Monero is a valid implementation of cryptonote white paper. I even bought some (ath obviously). But I think that what you're saying is quite bold and should be backed by something more objective. |
|
|
|
The sentence
"Block pruning is currently incompatible with running a wallet"
should be exposed in the changelog.
definetly. it will be less problematic if the user will be alerted in the beginning of the pruning process, though. |
|
|
|
So your take is that devs are going full "political" rather than technical? (serious question)
If yes, what's the way to unlock this impasse?
Exactly. The heavy political bent of the core developers was obvious to me since I joined this forum. I just underestimated the amount of internal tension and mutual distrust within that group until the March 2013 event. My proposal was published late 2011 and I always wear it in my signature: https://bitcointalk.org/index.php?topic=54382.0In one sentence: Don't sign political slogans like "Chancellor on the brink...", sign the "digital prospectus" specifying exactly the rules of consensus and explicitly track their inevitable changes as the world evolves, including through the splits and joins that form a DAG (directed acyclic graph), not just forks. Posted in this thread couple of days ago: https://bitcointalk.org/index.php?topic=68655.msg11664787#msg11664787Thanks for the pointer, I will definetly have look. From a cursory Iook it seems I have a lot to digest  |
|
|
|
|
Show Posts
