Gold collapsing. Bitcoin UP.

[cypherdoc]

@Peter R

i'm fine with your proposal above with immediate implementation:

-maxblocksize=<n> Set block size limit in bytes (default: INFINITY [=1073741824])
-blockminsize=<n> Set minimum block size in bytes (default: 0)
-blockmaxsize=<n> Set maximum block size in bytes (default: 750000)
-blockprioritysize=<n> Set maximum size of high-priority/low-fee transactions in bytes (default: 50000)

seems to me the bolded default of 750000 needs to be removed?

 

[theZerg]

Ppl check over here for my proposed BU articles of confederation: https://bitco.in/forum/threads/bitcoin-unlimited-ideas-arguments-and-proposals.123/

 

[solex]

@theZerg
I like the idea of a base minimal change client, which later multiple extension clients can be built on top of (such as your configurable concept).

This is a great approach, and one extension already comes to mind.

I'm thinking that BU could do with a "killer app" which makes more people want to use it, especially the many node owners who are agnostic about the block limit and just stick with Core because: Core.

The answer is software support for JR's concept on node service micro-payment channels. This provides an economic incentive for non-mining nodes and aids the greater goal of decentralization (however that gets defined).

It can also be a nice strategic advantage. Lots of people might not run XT just to make a political statement, but they would run BU if they can get a steady trickle of satoshis into their wallet.

 

[cypherdoc]

I thought that BU was additionally going to vote for 100 & 101. Is that also out of the baseline?

I still don't get what this was meant to entail?

Is it just an announcement that "we support the concept of 100 and 101" and nothing else in terms of code execution in BU? Or is the addition of bigger blocks to BU somehow dependent on the more restrictive rules of those 2 implementations?

Perhaps the term "flag" is confusing me. This usually means an "option" for an argument in Linux terms.
[doublepost=1446104137,1446103415][/doublepost]As an aside, I guarantee you core dev and idiots like brg444 et al are watching this discussion and are are already formulating ways to attack and lie about how harmful BU will be.

this is why it is so important to KISS.

 

[cypherdoc]

@theZerg & @Melbustus

I would add some comments to your docs that profess that we want to be forward looking to the time we inevitably need more tx/s, bigger blocks, & fees to replace rewards to support the mining industry. It's important to state that this initiative is to help them transition with the goal of maintaining/growing current hashing power and thus security.

I would also make mention that we feel a need to do this now in light of the painfully obvious lack of discussion of this important topic going on in the mailing list.

Make mention that all of this work is voluntary and no one has a financial COI in doing this. This is merely to advance Bitcoin back to Satoshi's original vision.

Make mention that we feel Bitcoin has evolved to that of a public good and that no one group should have control especially one with a financial COI. .

Make mention that Bitcoin is a fragile ecosystem whereby many groups and economic actors have made large investment decisions based on maintaining the current trajectory of growth and conditions. Any ideas or proposals that deviate from that path risk severe disruption and economic loss to the ecosystem actors which we don't believe is fair. BU is meant to avoid that.

None of the above in that order.

 

[sickpig]

all, misc thoughts about BU project:

• KISS:

BU first step: Core + "remove" max block size limit. On that matter just want to point out that XT github repo has a branch named "only-bigblocks".​

• Easy installation:

we should set up an apt repository from which we should serve BU, in such a way that a user has only to preform a gpg signed apt-get install bitcoin-unlimited and call it a day.​

• (D)DoS:

if the past has teach us something BU will be targeted by DoS attacks, should we do something about it?​

• Deterministic Build process:

the provided BU software had to be built using a deterministic build process, e.g. https://gitian.org/​

• Needed changes other than max block size:

• other that the maximum block size limit there is another constraint that will limit the block size, namely the max network message size, i.e. maximum length of incoming protocol messages that a full node could receive. It used to be 32 MiB but it has been changed to 2MB around version 0.10.0

• DDoS look at Tom Harding's patch developed in the context of the XT project?

• Governance:

@AdrianX made a really good point, we should find a way to avoid becoming the next core.​

 

[cypherdoc]

http://www.economist.com/news/briefing/21677228-technology-behind-bitcoin-lets-people-who-do-not-know-or-trust-each-other-build-dependable

 

[cypherdoc]

all, misc thoughts about BU project:

• KISS:

BU first step: Core + "remove" max block size limit. On that matter just want to point out that XT github repo has a branch named "only-bigblocks".

​

problem with this is that it is 101, not unlimited, and with Mike in control of the github acct, and technically an XT fork.
​

• Easy installation:

we should set up an apt repository from which we should serve BU, in such a way that a user has only to preform a gpg signed apt-get install bitcoin-unlimited and call it a day.​

great suggestion

• (D)DoS:

if the past has teach us something BU will be targeted by DoS attacks, should we do something about it?​

agree this will happen. any suggestions?

• Deterministic Build process:

the provided BU software had to be built using a deterministic build process, e.g. https://gitian.org/​

absolutely

• Needed changes other than max block size:

• other that the maximum block size limit there is another constraint that will limit the block size, namely the max network message size, i.e. maximum length of incoming protocol messages that a full node could receive. It used to be 32 MiB but it has been changed to 2MB around version 0.10.0

• DDoS look at Tom Harding's patch developed in the context of the XT project?

why don't you join @theZerg and the others for commit access to help solve this?

are you talking about Harding's anti-Tor DDoS strategy of shutting off Tor connections in an attack?

• Governance:

@AdrianX made a really good point, we should find a way to avoid becoming the next core.​

i agree

 

[cypherdoc]

ok, this would be a prime place for a Dow ($DJI) roll:

 

[sickpig]

@cypherdoc

I mentioned "only-bigblocks" xt branch only because it is maintained by Gavin and it's simply is core + bip101. In my opinion it should be seen as a reference for our implementation if we decide to take the bit 101 route (ala @rocks). Even if we take the "pure" unlimited route we could look at how Gavin solved the "max-network-message" problem in aforementioned branch.

Regarding (D)DoS I didn't study Tom Hardings (@dgenr8) patch, but from what I can tell reading xt patches description, it seems that it's not related to Tor clients connections, Mike's anti-dos patch is what gave a lower priority to IP marked as tor exit nodes, though. Tom's patch "fixes an issue that allows a malicious peer to jam a node by repeatedly offering a transaction or block and then never delivering it".

That said I more than happy to help make BU project successful, still I'm more a sys admin/devops rather than a developer, especially when it comes down to C++ skill.

 

[cypherdoc]

on Finex, we've already poked our heads above the 7/12/15 high. so hold on folks:

silvers, gold, and the pm miners making a break for it; to the downside:

[doublepost=1446131551][/doublepost]

@cypherdoc

I mentioned "only-bigblocks" xt branch only because it is maintained by Gavin and it's simply is core + bip101. In my opinion it should be seen as a reference for our implementation if we decide to take the bit 101 route (ala @rocks). Even if we take the "pure" unlimited route we could look at how Gavin solved the "max-network-message" problem in aforementioned branch.

excellent suggestion. i still think someone should talk to Gavin just in case he wants to come onboard with BU. that would be a huge feather in our cap. actually, i wonder if Mike would also support to BU?

Regarding (D)DoS I didn't study Tom Hardings (@dgenr8) patch, but from what I can tell reading xt patches description, it seems that it's not related to Tor clients connections, Mike's anti-dos patch is what gave a lower priority to IP marked as tor exit nodes, though. Tom's patch "fixes an issue that allows a malicious peer to jam a node by repeatedly offering a transaction or block and then never delivering it".

hmm, not sure i've heard of that. any links? how strongly do you feel we need to have something like that in place before initial release?

That said I more than happy to help make BU project successful, still I'm more a sys admin/devops rather than a developer, especially when it comes down to C++ skill.

you follow dev email closer than most of us which is a big help.

 

[cypherdoc]

alright, i'm in @19.92. we'll see:

 

[rocks]

This is a great approach, and one extension already comes to mind.

I'm thinking that BU could do with a "killer app" which makes more people want to use it, especially the many node owners who are agnostic about the block limit and just stick with Core because: Core.

The answer is software support for JR's concept on node service micro-payment channels. This provides an economic incentive for non-mining nodes and aids the greater goal of decentralization (however that gets defined).

It can also be a nice strategic advantage. Lots of people might not run XT just to make a political statement, but they would run BU if they can get a steady trickle of satoshis into their wallet.

Another one is adding a bitcoin mixing mechanism. I couldn't find it after a quick search, but people have worked on more secure methods of mixing coins than coinjoin. If this was added as an addon to a main client, the pool of people to mix with would be large enough to make it worthwhile and usable.

Frankly the level of features development in the core client has been abysmal over the past 2 years. They've essentially stopped trying to build user facing functionality and are just screwing around with trivial items and LN. This is another opportunity to take the thunder from core.

Overall I really like the concept of a BU core that is 1 line different from the current core, but also has extendable plugins that enable more functionality. It makes BU very minimally focused on removing Satoshi's "temporary" limit, while also adding features people can use.

Edit: For BU related stuff I'll post in the other thread now.

 

[cypherdoc]

@rocks

Overall I really like the concept of a BU core that is 1 line different from the current core,

let's focus on getting this going first, please
[doublepost=1446136126][/doublepost]how beautiful is that?

 

[rocks]

I've always liked the inverse charts myself, shows the dollar crashing

https://pizzacharts.com/c/dOnLIlWs/

 

[Inca]

lol

you have been temporarily banned from posting to /r/Bitcoin. this ban will last for 1 days.

note from the moderators:

trolling:
In reply to this by adam:
I have heard from multiple people that the uncertainty was bad. From traders, from investors, from businesses, from financial institutions. The point that the uncertainty is unwelcome was made before, one could dig up the posts.

I sent this:
Uncertainty? Who are you trying to kid.
Bitcoin will scale with or without you jokers.

Getting a bit sensitive aren't they

 

[Zangelbert Bingledack]

Mark Friedenbach, what the...?



Couldn't have had anything to do with blatant censorship and banning of users just for talking about blocksize or forks.

They think that just because the mods created a thread where you're allowed to talk about blocksize (but aren't allowed to talk about the censorship nor about actual forks), those threads are automatically where all the discussion happens. People didn't get tired of discussing it. They got tired of being censored and banned and having threads they were posting in erased completely at moderator whim.

By blocking all reasonable scaling proposals, Team Core makes it impossible to talk about scaling without talking about forking, then Theymos bans discussion of forking. Who's going to bother discussing scaling when the elephant in the room has to be avoided? Any discussion that starts can and will be ended as soon as the mods feel the small blockists getting thrashed. The small blockists can just say smugly, "If you think it's a good idea, go ahead, submit a BIP," and any reasonable response is prohibited by the rules. What a perfect reality bubble they've created.

Technical progress doesn't happen on reddit...when discussion is censored. How does anyone get to be so narrow in their thinking that they can't view points made about forks as part of technical development?

 

[cypherdoc]

c'mon, c'mon, c'mon:

 

[cypherdoc]

everything down again except UST's and ...wait for it...Bitcoin!

 

[cypherdoc]

http://moneyandstate.com/its-all-about-the-blockchain/

good article Erik.

also, $DJI trying to sneak out the door.
[doublepost=1446231995,1446231133][/doublepost][doublepost=1446232465][/doublepost]

in response to @chmod755 who asked why i still participate in r/bitcoin:

i sparingly do so. and for some reason, i've not been banned. maybe i haven't been too controversial despite not hesitating to criticize BS, and SC's and LN.

i guess i still believe i can effect change by speaking my mind than allowing them to drive me away.