Bitcoin Forum
June 24, 2022, 10:58:36 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 96 »
1  Economy / Speculation / Re: What would a fast exponential run-up look like? on: January 01, 2017, 07:00:26 PM
Time to consider this again.
2  Economy / Speculation / Re: Reasons for recent uptick in Bitcoin price? on: January 01, 2017, 05:50:44 PM
Ask not why the price rises.

Ask instead why the heck it was so low for so many years.
3  Economy / Speculation / Re: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion on: December 28, 2016, 11:33:06 PM
Sold my coins at $500  each.
I feel ill.
 Embarrassed

It's only going to get worse until you get back in.
4  Economy / Speculation / Re: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion on: December 28, 2016, 06:45:18 PM
We have a date with history, gentlemen.
Been a while since you have been around !

You have picked the right time: moving on up !

We have a date with history, gentlemen.

You were missed, welcome back!

Nice to see you fellows, too! Yes, it has been a hard winter of hodling these past years. This time we have built a careful base, we are up on pretty much all timescales, the stars are well-aligned, and the old 2013 movement patterns are repeating, including one I call the "battering ram." You can maybe figure out what that one is.

Here's a log chart, since it can never be posted enough. We have at least an order of magnitude of catching up to do!

5  Economy / Speculation / Re: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion on: December 28, 2016, 01:34:52 PM
We have a date with history, gentlemen.
6  Bitcoin / Bitcoin Discussion / Re: OpenBazaar , a failure ? on: August 18, 2016, 11:39:54 AM
Can't call OpenBazaar a failure when they haven't enabled TOR yet. For better or worse, commerce for normal (non-contraband) items is going to be one of Bitcoin's last major uses as it goes mainstream, not one of its first.

See: https://www.reddit.com/r/Bitcoin/comments/37m00z/problem_when_i_spend_bitcoin_in_the_real_world_i/crnum1a
7  Economy / Speculation / Re: 1 BTC = 1000$ in 2016 on: March 01, 2016, 01:40:32 PM
$1000? Pshaw. Have you no ambition? If I thought Bitcoin would only go to $1000 this year I'd not even bother with it as an investment.
8  Bitcoin / Bitcoin Discussion / Re: Why Peter Rs Fee Market Wont Work on: February 01, 2016, 05:24:56 AM
Bitcoin doesn't "work" just because of the rules encoded in the software--it works because there are people who choose which rules to enforce and what behaviour to encourage.

Key point, though it is hard to get people to see the intended interpretation of this.
9  Other / Archival / Re: Why bitcoin will never die in two words on: January 10, 2016, 01:41:08 AM
Ledger > Protocol
10  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 04:50:49 AM
Note to all since I've been answering a lot of questions: I'm not a spokesman for BU. I'm just someone with a keen interest in the project, and more than that, the overall concept and approach. My views are mine alone. For more details on what others involved in the project think, you'll probably have to go to other forums because many who are close to the project feel - with some justification but wrongly in this case I think - that they will be censored here.

I notice Adam posted on the other subreddit, so if you're not averse to asking questions there you may get some answers that I myself cannot provide. Really the developers should be answering a lot of the specific questions (on reddit: /u/thezerg1 /u/awemany and sickpig (not sure of sickpig's reddit name)). My responses here are mostly about the general idea of user-adjustable blocksize settings, which I see as the major idea of the project - note that many others probably do not agree.
11  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 04:11:40 AM
inserted by developers who excellent at what they do have no track record as incentive designers, economic parameter setters, etc.

They do in fact have a track record. Various economic- and incentive-related decisions have been made in Bitcoin development over the past 6 years and it hasn't completely blown up yet. That includes both changes and decisions about what not to change.

I guess this conclusion depends in part on how big a failure you think the "blocksize debate" represents. From where I sit, the blockchain is still working, transactions are being processed, etc. I don't see a major failure even in that.

I think the blocksize is the biggest controversial economic aspect they have touched (kind of easy to change something when it's not controversial), but - see my edit - I don't think it would be good to vest power even in someone who did have a good track record on that.

I do think we will be fine whatever happens with blocksize, and are fine now, but that adoption could be set back quite a ways if too much friction is introduced and circuitous paths are taken, so I think it's worth pointing out some existing burdens on weighing on the market discovery process.
12  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 03:54:18 AM
Interesting. Do you have a general sense of what block sizes are most BU supporters comfortable with? How about yourself?

I used to be an unqualified big blocker until I realized that big blocksize caps aren't necessarily any more "free market" than small blocksize caps. I was caught up with the "cap" thing, thinking low caps are market interventions. Well they are, but so are high caps. So the free market position must be elsewhere. The free market position to let the market decide the cap. See the image I posted above.

Now my position is that much bigger blocks are probably fine and the system will probably self-limit via mechanisms like orphaning, and that generally most of the small block arguments spring from a mistrust of markets... BUT that I shouldn't be the one to decide. I'd like to place my bet in a prediction market that, say, 50 MB would actually be fine right now, but if I were Core maintainer I definitely wouldn't want to put 50MB or even 10MB in the next release - for fear that I, a fallible human, could be wrong.

I wouldn't want anyone to have that power. I want the market to decide, and to do so unburdened by the interference of the hardcoded cap inserted by developers who - while absolutely excellent at what they do - have no track record as incentive designers, economic parameter setters, etc. And even if they did it wouldn't matter, the power would be too concentrated.

I'm for having Core be closer to a wallet, with any controversial consensus parameters left to the user. Users would not screw themselves over, just like a car driver doesn't turn on the emergency brake while cruising on the freeway. I know some people think they would, but as I keep saying, the inconvenience barrier isn't that high. It's plenty high enough to set a very strong Schelling point, though, which serves as a big market intervention. With multiple competing implementations to choose from, like XT, this intervention becomes weaker, but it is still highly suboptimal and in my opinion a security risk or at least a millstone slowing progress.

Quote
Will BU be rolling in the long list of other scaling changes core is going to be rolling out, including SegWit/SepSig?  (Seems to be some confusion on the issue here-- https://bitco.in/forum/threads/what-is-bus-stance-on-segwit.665/) , perhaps this is all premature as you still need to vote in officers and finish updated your github as I see multiple issues there with a quick glance(many old notes and links from pre-fork).

I think there is some interest in doing that. Generally I'm not that particular about what happens in any one implementation. If Core and XT would abdicate some power and give users leeway on consensus parameters that are controversial, that would be great. If BU is adopted, that would be fine, too. If someone forks BU and does something else with it, that would be cool as well. If btcd implements adjustable blocksize caps, I might use that.

From an adoption perspective, I think it likely that BU will try to incorporate whatever it can. I have even argued that opt-in RBF would be good to include, despite my disagreeing with it. My motto is,

"I find your settings despicable, sir, but I will defend to the death your right to set them."
13  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 03:32:59 AM
BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code.
Why should this be removed from the code and made user configurable? It is consensus critical since it can create hard forks, so why should it be removed?

It gives choices you say, so does that mean that we should make everything else that is consensus critical and make that user configurable? Should we remove the block reward schedule? Should we change the difficulty retargeting schedule?

Everything controversial, yes, unless we want to vest inordinate power in whichever devs control the dominant implementation. That power concentration opens a major attack vector. I believe this hasn't been noticed before because there was never such a big controversy before. Who knows what the next big debate will be. Whatever it might be, realize that making the choices blockier (less granular) by trying to shoehorn people into one, two, or three possible implementations with bundled consensus parameters doesn't make the situation any better. The market will always choose the least bad option, but if there are only two options, say that offered by Core and that offered by XT, that's quite suboptimal and will lead to less satisfying results no matter what parameter we're talking about.
14  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 03:24:10 AM
I personally believe XT's (and as suggested here BU) 75% threshold to be dangerously low as well. A 95% supermajority with a minimum 2 week grace period and alerts sent should be the default for hardforks.

I think 60% is fine. Just kidding. Or am I? I say it doesn't matter what I think. The market will make the choice anyway. The only thing devs can do by locking the consensus parameters down in each implementation is force the market to make a less granular choice.

For example, if the market wants a 90% supermajority, and the options are Core at 98% and XT at 75%, maybe the market will be forced to go with 75%, which the market deems dangerously low but better than an impossible 98%, or it will be forced to go with 98%, causing a lot of unreasonable delay. 

Or maybe it's Core with 95% and a three-day grace period, and XT with 75% and a three-week grace period. Gotta choose the lesser of two evils, not a happy place to be.

When choices are not granular, consensus cannot find its optimum level. This is the kind of friction that can be removed by unbundling the consensus-parameter-setting service from the rest of the roles the devs play. The choices can even be among BIPs the devs offer, so it's not even anti-dev. If the market thinks devs know best, the market will go with a dev recommendation. If not, it will go with something else.

Quote
And small block adherents, imagine the reverse, if it were Mike and Gavin were running Core and Pieter, Wlad, and Maxwell had broken off and started their own implementation, with maybe Jeff going between. And people were sticking with Core and its giant block plan, heading for catastrophe. You might notice the market friction then.

One doesn't have to pick sides. I respect all of the developers above and can have nuanced opinions and disagreements with individual aspects of their code contributions.

So do I. They all have great talents to contribute, and it pains me to see them have to be involved in a kind of power struggle because of the fact that they are being relied upon not just to recommend consensus parameters from among controversial choices, but to attempt to force them on users or at least spoonfeed them to users because they believe that they need to do so in order to generate consensus. I think some of them are unaware, or have not considered the fact that consensus can be emergent. I don't even think Gavin has fully internalized this, even though he did agree to the idea three years ago.
15  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 03:09:34 AM
Really? How? So far what I have seen is that a new block size limit in BU takes effect immediately. There is no mechanism that does the supermajority fork process.

If there is a specific option to for the supermajority fork process for a single BIP, then there should be that for every BIP. Will BU have options to allow the user to support whatever BIP or not? How will new BIPs be added? Through a software upgrade?

Yeah, software upgrade as far as I know. These are planned. Dev just started recently. Don't know how long it will take. Probably the supermajority requirements will be as in the original BIPs, with option for the user to customize them as well. Depends on what the devs do, or what people who fork BU do.*

*Note that, unlike Core or XT, it doesn't really matter (as far as consensus parameters) whether you run BU or a fork of it. This is an implication of the unbundling of consensus-parameter-setting from the rest of the code. So any questions you might be asking about the specific BU project with Andrew Stone as lead dev should probably be reconceived a bit:

Instead of asking BU what it will do, ask what anyone that does something similar could do. The genie is kind of out of the bottle. With the unbundling concept, anyone could offer blocksize-related BIP-mimicry of any kind in any configuration. It's just a matter of dev time and inclination. Dave Collins of the btcd implementation mentioned adding BU-style blocksize cap configurability, for example (on the other forum).
16  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 02:56:26 AM
Does BU have any sig-ops limits for CVE-2013-2292 like what Gavin proposed here - https://github.com/bitcoinxt/bitcoinxt/commit/cc1a7b53629b265e1be6e212d64524f709d27022 of is BU stuck to standard 20k ?
 I see a brief mention of it here - https://bitco.in/forum/threads/bitcoin-unlimited-code-review.359/  nothing confirmed.

I'm probably not the right person to ask. Other people on that forum should know.

Quote
Most of my interest is with the experimental stuff discussed by testing1567 as well as some interesting new attack vectors opened up politcially by empowering the nodes with developmental decisions. There are some topics that need further analysis.

Note that nodes already are empowered with decisions on the consensus parameters, it's just that there is a lot of friction in them doing so because of the inconvenience barrier and the strong Schelling point that artificially sets up. (See my post above in reply to Smooth. I would say the current approach makes it far more political, and BU attempts to eliminate such aspects.)

Quote
This does get me interested in a potential oracle or DAO potentially having the role to determine maxBlockSize by analyzing technical merits/limitations at a higher weight than user demand which could be used to influence a more dynamic block adjustment.

Interesting idea. Bitcoin has a lot up its sleeve for the future, and DAO+oracles could do amazing things to market efficiency. I think a prediction market would be ideal. Once a decentralized prediction market is up and running and gets liquidity, this will probably be the way the blocksize cap is decided in the future.  

This whole debate has made be extremely optimistic about Bitcoin's future, as I see the ferocity with which people will defend and debate until the right answer has been reached even on a fairly esoteric point to most lay people. This is the power of an economic system powered people with skin in the game. How much have all of us learned, no matter what side of the debate you are on, in this past year? Bitcoin drives us to be better, smarter, wiser, less biased, less emotional, less narrowly focused on our own domains of expertise.

Quote
1) Very few of the core developers are "small block adherents", besides 1-2 developers , all suggest raising maxBlockSize.

Yeah. By "small" I just mean like single-digit MB sizes for the next few years. I don't mean just permanent 1MB supporters.

Quote
2) testing1567 indicated " My other issue with BU is it lacks a way to move the blocksize down, only up." is this true for nodes with BU(I am aware that miners can set the limit to anything.)

No, any limit can be set. I assume testing1567 was referring to something about how someone said the acceptance depth thing was supposed to work.
17  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 02:38:14 AM
"We would be trying to predict what the market would decide, "

@Zangelbert Bingledack, I'm somewhat sympathetic to your cause but I don't really see how the market mechanism operates here, outside of a very broad definition of "market" which encompasses politics. Node voting doesn't work at all. Without that you are still reduced to politics and whoever shouts the loudest in trying to convince miners what block size they should use.

Well that's how it is anyway, and even now the market does decide. My point is that there's market friction in the inconvenience barrier of users not being able to set the blocksize cap themselves. That gives artificial solidity to the Schelling point set by Core (as well as the one set by XT). If Core is doing the correct thing, it shouldn't mind putting it to the market test more fully, by taking its finger off the scale.

How much is Core's finger really on the scale here? Well, for example, how many reasons are there to mistrust Mike Hearn? Some would say a lot. That means, as things stand now, even if you want BIP101, you can't really have it if you have a problem with Mike, because XT isn't an option for you. And because other people feel that way, you're further limited. The way Core (and XT) does it now makes it a power struggle, a popularity contest, and a package deal. Maybe Core could stall for a long time before people would finally give up and go with Mike. That's a lot of friction in the market.

And small block adherents, imagine the reverse, if it were Mike and Gavin were running Core and Pieter, Wlad, and Maxwell had broken off and started their own implementation, with maybe Jeff going between. And people were sticking with Core and its giant block plan, heading for catastrophe. You might notice the market friction then.

BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code. It also of course makes for a lot more choices. If 1MB is too small and 8MB too big, what recourse is there? Roll your own and try to popularize it? Very hard. But propose 4MB and try to get people to agree? More doable. Or what if, like some Chinese miners were saying, 8MB is fine but the scaling to 8GB is ridiculous. What do you do? You have two options, and they are bundled up tightly with all the other aspects of the code and why you choose Core or XT. That's again a lot of market friction.
18  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 02:16:48 AM
Note to small block adherents: Despite the name, Bitcoin Unlimited is not a "big blocks" implementation. It's simply an implementation that doesn't include a locked-down blocksize as part of the package. It lets the user set it. It could be 500kB if you like.

It's an accident of history that BU is being developed by big block supporters. It could have been developed by small block supporters for the exact same reason: to avoid the dominant Bitcoin implementation from doing something you consider foolish.

As I said in my first post, right now the leaders of the dominant Bitcoin implementation are for a low blocksize cap, but imagine if the situation reverses and big blockists are in control, to the consternation of many in the community. I think you would not want them locking down the settings. You might say, "You folks are doing fine otherwise, but you are off on the blocksize cap. Why try to play central planner? Please leave it up to the market if you are so sure the market will like your huge blocks. People will follow your recommendations if they like them anyway, so what are you worried about?"

If I were Core maintainer, I would do the same. Perhaps I would set a higher default, but I would not take the option away from the user. To do so risks sudden consensus shocks due to friction effects, risks my position being undermined silently, and most of all assumes I know better than everyone else. I might set it at 10MB. But I may be wrong; I'd rather trust in the market, because none of us knows better than a million people all with skin in the game.

Bitcoin Unlimited is just as much a small blocks implementation, guarding against the possibility of, say, Mike Hearn taking over Core, as against, say, LukeJr. Bitcoin Unlimited is simply against central planning of the blocksize. Instead, blocksize consensus would emerge from each user making their own decisions, signaling, coordination, debate, flag days, expert recommendations, etc. It prevents against centralization of developers in one implementation; again, today it's small block adherents in Core, but what if it became big block adherents? It might start to sound like a pretty good idea to let the market decide.



Under BU, all our arguments about blocksize become merely academic. We would be trying to predict what the market would decide, rather than vying over control of the One Ring of Power - the official/reference implementation of Bitcoin. Much rancor could be dispensed with. The market would do its thing and probably maximize value, and Bitcoin would continue, unable to be controlled by anyone. Just the way we like it.
19  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 02:04:29 AM
Ok, thanks for clarifying and I understand why you wanted to ignore those "differences" but they should have been revealed up front when I kept asking for clarification as this is a technical subforum where we are meant to discuss the details .

Actually, I did mention this to you on page 3. It's been a fast discussion and we forget things, so no worries.
20  Bitcoin / Development & Technical Discussion / Re: bitcoin "unlimited" seeks review on: January 03, 2016, 01:57:02 AM
Ok, thanks for clarifying and I understand why you wanted to ignore those "differences" but they should have been revealed up front when I kept asking for clarification as this is a technical subforum where we are meant to discuss the details .

testing1567 had 2 very interesting posts.... do you disagree with any of the information therein before I start pondering them in detail?

I didn't realize you were asking about those other features, as you didn't mention them explicitly that I noticed. I just thought you were misunderstanding something about my explanation. That might explain the confusion.

I don't have a lot of thoughts on the acceptance depth aspect. It seems it would work, but it is experimental. It can be turned off, and I have recommended that it be turned off by default and marked as an experimental feature. I don't consider it necessary for the BU concept of letting users determine the blocksize limit, which I consider the main attraction of BU, so for me it's kind of <shrug>.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 96 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!