Topic: Satoshi Nakamoto: "Bitcoin can scale larger than the Visa Network" - page 11. (Read 18415 times)

this is a prime example of ivory tower thinking getting in the way of real solutions that matter to real poeple.



this is a prime example of bad project management, we can't achieve any kind of consensus without first agreeing to what the main goals of the project is.

of course Gavin is doing things differently in classic his primary goal is to scale the blockchain as much as possible.

this is NOT the main goal of Core, which is fine, there second layer solution is fine, but it's simply not what the majority want...

They're a group of volunteers. Some are employed by MIT (Wladimir IIRC), and some are employed by Blockstream (Maxwell, Wuille) and such. However, most of them are just volunteers from what I know.



They are mostly Blockstream members. They are on payroll of bankers from VC's. Before somebody call me a liar. You can check out https://www.blockstream.com/team/ and then compare with https://bitcoin.org/en/development#bitcoin-core-contributors . I will stop coming into a conversation without proof. I hope that's good enough. It will never have an 2MB hardfork they will just give us breadcrumbs to shut up a bit while they are building solutions so people will go in wave to their solutions rather then stay on main chain. Transforming it in a settlement layer and absolute the P2P payment system and take it off-chain to their solution.

That's the last thing I had to say. No more involving in this subject, it drains me out of energy, it drains me out of patience. All I can do is keep my Bitcoin Classic nodes up and hope slowly other will join as more will be aware of the breadcrumbs were given. Dramatizing the whole increase of block size just because it's dangerous without any real and statistical answer while they forked when testing SegWit it says a lot.

Also they are a lot of Bitcoin Core supporters here while the whole board bitcointalk is 100% Bitcoin Core by just not offering people alternative solutions and advertising every update of Bitcoin Core while not offering people alternatives with proper explanation prooves again the control of mass and keeping it them blind against recent Bitcoin discussion. It absolute the whole idea of community of an free & open source project made by people for people. So Bitcoin Classic must somehow pay for advertising and inform people about the news and their right to choose, because other channels are trying to hide as much as possible the right to choose.

Thanks,
I wish both sides good luck and may the best chain win.

someone can probably come up with some highly speculative scenario where such a transaction could potently be useful
is that excuse a good reason to not protect the network against such an attack?

These limitations are very bad. Wasn't Bitcoin supposed to be censorship free? Who gets to decide what kind of transactions we are going to limit? As an example, the sigops limitation that Gavin implemented in Classic is not a solution of any kind. For example, if we had confidential transactions today they would not work due to this. There are so many potential use cases that it is nearly impossible for us to consider everything.

They're a group of volunteers. Some are employed by MIT (Wladimir IIRC), and some are employed by Blockstream (Maxwell, Wuille) and such. However, most of them are just volunteers from what I know.

I try my best, as long as the other person (especially when lacking knowledge) is willing to listen to reason, facts, data and such.

give it a few more days of debate, you'll see your optimism and praise will turn to anger and disgust. LOL  

your a really nice guy, quite refreshing!

LEAVE THIS PLACE IMMEDIATELY, this is for your own good.

Although I am willing to participate in a test to measure the SigOp quadratic growth, I am not able without help.  If someone will build the code then I will install, run, and report back on it.

Bitcoin is up and running well (assuming one uses reasonable fees ~5¢/transaction) despite an onslaught of ill-intention persons.  Shame on all of us for not adjusting our marketing messages earlier to set expectations better.  Find me another system that has withstood as much and moves millions of dollars a day.

Who pays the Core Dev Team?  Are they doing all their work for Bitcoin for free?

My sincerest heartfelt praise and admiration go out to Core Dev Team members!  They are giving us something I couldn't do myself.  That said, I do think there's room for improvement on the handling of perceptions front.  I sincerely believe they have the overall good of Bitcoin *and* the users of it foremost in their minds.

Lauda has done a yeoman's job representing the positions; thank goodness someone has the patience.

then we move onto the other debate. blockstream devs not only want segwit in april but some other changes within the same release.

one of them is actually debunks the "hard fork is doomsday".. because it, itself is a hardfork.
by which i mean luke Jr's proposal for code to be added in april with just a 3 month grace (activating at block 420,000) in the attempt to unnaturally drop the difficulty to allow miners to solve blocks easier. basically forcing blocks to be made in 5 minutes instead of 10, to allow an extra 2 weeks of similar income before natural biweekly difficulty adjustments raise the difficulty.

which apart from knowing its just a feature that has no long term purpose. the suggestion that a hardfork can be added in april with a 3 month grace totally contradicts the same devs who say that a hardfork which is not on the roadmap needs 12months grace..

but the ultimate thing that defies logic, is the solid faith that all code done by blockstream is perfect and any proposal outside of blockstream must be ruled out, veto'd, debated to cause contention and delay.

like i said a 2mb buffer is like the 1mb buffer in 2013. it wont cause a doubling of blocksize over night. as the miners will have preferential settings to grow slowly within the hard limit.

the code itself is simple to implement. and the only thing that can cause harm would be contention by those foolhardily refusing to upgrade when the majority have actually already upgraded.

thats why its better to have the code available to all and then let the community decide if they want it..
if no one wants it. it doesnt activate, its that simple rather then avoid and delay the code and cause the contention that they doomsday speak about. by never letting the community have access to it.(self fulfilling prophecy they created)

now that has been said. going back to the other stuff you have said
i would like to see the results of the tests you intend to do. as real results always outweigh opinion and guesswork. so your tests can actually help out alot of people

Listen everyone: *** Bitcoin is a fantastic thing!!! ***  Our internal debates are seen; they are taken as a measure of our ability to provide governance or not.  There are folks lurking in here; picking up on the mood and reporting on it.  Every posting should take this into account.

Championing Bitcoin first before espousing one technical aspect or another will help.

Avoiding the practice of nitpicking or worse will help.

Compromise and appeasement are valuable tools.

I feel the core dev team is not willing to make the appropriate trade offs.
I do believe we could of had the 2MB limit inplace months ago and all this  pain/anxiety avoided.
but the Core dev team doesn't seem very concerned with end users pain/anxiety, as much as they are with theoretically more elegant scaling.
I feel they are programmers not qualified to manage and direct the project, and they are making bad decision, maybe the decision they make are technically more elegant, but they do not create a more elegant user experience. but they are convinced that the users dont matter because its Bitcoin's birth right to replace central banking.

That's interesting adamstgBit.  *Is* it *always* the case that >10K inputs is indeed spam?  *Is* there *ever* a case where it is not?  Can the same movements be accomplished by splitting it up into multiple transactions to avoid triggering the spam rejection?

adamstgBit, you've hit it right on the head.  We must do everything we can to help folks adopt Bitcoin without pain/anxiety.  Our marketing messages need to set expectations appropriately; gone are the days of leading with the misleading "no fees".  It's ok to indicate lower fees than the competition, e.g. wire transfers, VISA, *if* it is indeed true but don't touch the topic if it is not -- if 5¢/transaction is the going fee then transactions less than say $5, i.e. 1%, make less sense.  Instead lead with our indisputable strengths, e.g. ~1 hour (6 blocks) to guarantee transfers of even large amounts anywhere in the world.  It is just unbelievable that there are wallets out there that don't set an appropriate fee automatically and by default such that transactions get through quickly despite the dynamic environment.  Once a new user grows accustom then they could dig in and find the overrides to try transactions with low/zero fees and see the natural consequences of long delays.

somthing like  if TX has >10,000 inputs it's no good?

why not!? I wouldn't mind if F2Pool's tiny blocks were orphaned by other miners. maybe he'll stop making these tiny blocks if they do punish him for it?

oh wait i read that wrong....

again, WHY NOT!? the TX in question WAS an attack, why include in the blockchain?

if you can't be sure if its spam or not ( <1$ TX with 1cent fee ) fine included in the block, but if you are sure it is spam ( >10K inputs ) why include it?

Well, franky1, that's really interesting (although it could have been said just as well without the provocative words); 2MB + SegWit.  We do want to be careful -- releasing multiple things at the same time can lead to confusion if things don't go perfectly well.  I'd hate to see something going wrong and each side blaming the other.  Also, if there would be a need to retract a feature/function then that would likely cause a media stir; something Bitcoin doesn't need anymore of at this time.

You're very welcome. I do hope that there will be a hard fork proposal after Segwit which will gain consensus. However, if Segwit is adopted quickly by both the miners and users we should see a good increase in transaction capacity that should hopefully get us through 2016. The problem caused in this conflict is that there are a lot of people who aren't willing to listen to reason and facts. Time should not be wasted on them.

Exactly how do you plan on "simply" detecting these blocks and why would somebody orphan them? How do you classify this as an attack; was the TX that F2Pool did to clear the spam also an attack?

Another thank you Lauda:  If only more people took the time to make clear their positions like you do.  Yep, I see it; with SegWit so close it would be disruptive to overlap it with a block size limit increase combined with a sigops limitation.  I do feel it was a missed opportunity not to provide a modest block increase (even without a sigops limitation) many months ago but there's no going back now.  *Hopefully* SegWit will come out on time, functioning well, and be embraced quickly without a lot of angst.

and now you see why a 2mb+segwit released in april with 6month grace is not a problem

i love it when lauda debunks his own doomsday scenario

having the 2mb block limit included in aprils release is easy. plus it incentivises more people to download the april version ensuring a real chance of no contention, instead of having upgrades every couple months EG march april july. which just mess with the community too much

because the 1 TX the miner included, is obviously an attack to try and get the other miners to run in circles validating for minutes while he starts on the new block?

let's ignore the fact that miners have a strong incentive to keep the network running smoothly... and think about this WILD speculation that with 2MB blocks a miners can block all mining on the network by creating extremely complex transaction that take a long time to validate.

why can't the other miners simply orphen these blocks?

Well the problem is only minor at a 1 MB block size limit. Segwit should scale it down and make it linear. It should be released in April (from the initial estimates), so I don't see how you plan to deploy the block size limit and a sigops limitation in <2 months.

No, why would they?