whalepanda smear tweet context

anthony [10:01 PM]
Is block size part of the core design of bitcoin?

Eric Lombrozo [10:12 PM]
it was added in 2010, I think, to prevent DoS attacks...but without establishing a means to raise it or get rid of it in the future

Peter R [10:13 PM]
Block size is never mentioned in the white paper.

Eric Lombrozo [10:13 PM]
most of the consensus rules are not mentioned explicitly in the white paper

Peter R [10:13 PM]
uploaded this image: Screen Shot 2017-01-22 at 10.13.37 PM.png
Add Comment

Peter R [10:14 PM]
The rules that enforce bitcoin's _money property_ are all mentioned. (edited)

brg444 [10:14 PM]
duhh

[10:14]
we're doing bible thumping again

Peter R [10:15 PM]
The question was whether the block size limit is part of the central design of Bitcoin.  The white paper is a good place to look for an answer, no?

Eric Lombrozo [10:15 PM]
it's an as-of-yet unsolved problem

[10:16]
as are other things such as thin clients

[10:17]
the white paper also makes no mention of mining pools nor ASICs nor selfish mining attacks nor a bunch of other stuff

brg444 [10:17 PM]
@peter__r nor the 21M limit

[10:17]
so I guess that's not a central design of Bitcoin

anthony [10:18 PM]
so brg444 is block size part of the core design of bitcoin?

brg444 [10:18 PM]
i dont know what core design is

shinobimonkey [10:18 PM]
its core to its functioning

[10:18]
disagreeing on it leads to a consensus break down

brg444 [10:19 PM]
I know it's been there for most of its existence

Peter R [10:19 PM]
@brg444: the precise limit of 21M isn't central.  It could have been 10M or there could have been perpetual tail inflation.

anthony [10:20 PM]
I dunno. I don't think it is, but I think I like brg444's answer and I don't know what "core design" is

shinobimonkey [10:20 PM]
that is false peter__r , again 21M cap is core to its functioning

Eric Lombrozo [10:20 PM]
I think we're getting caught up in semantics

shinobimonkey [10:20 PM]
the economics of how that system would self organize are totally different between a finite cap, and perpetual tail inflation

[10:21]
yeah we are Eric

brg444 [10:21 PM]
@peter__r the precise limit of 1MB isn't central. It could have been 10MB or linear/log growth.

Eric Lombrozo [10:21 PM]
the 21M cap is consensus-critical - but it isn't a fundamental design issue...it's in many ways an arbitrary parameter

brg444 [10:21 PM]
sounds like just like in the case of 21M we're stuck with it..

Peter R [10:22 PM]
The difference is that the paper makes reference to coin supply being scarce (as is obviously needed for a system to function as money).  There is no mentioned of block space being scarce.

brg444 [10:22 PM]
i don't think even Hal Finney or Satoshi had envisioned that all the Fidelity of this world would want to cram all their data on the blockchain

Peter R [10:22 PM]
So, IMO, scarcity of bitcoins is a central property, scarcity of block space is not.

Eric Lombrozo [10:22 PM]
surely Satoshi's computer didn't have infinite space - and at the very beginning of the network, there was so little use that it didn't really matter

[10:23]
it was thought that it was something that could be fixed later

anthony [10:23 PM]
I think I once knew why 21M actually makes a lot of sense; something about how C++ deals with real numbers

shinobimonkey [10:23 PM]
peter__r constantly pointing out the white paper is like, while we're in the middle of erecting an atomic reactor, you say "No no stop, lets consult the napkin you first had the design idea on."

[10:23]
its ridiculous

brg444 [10:23 PM]
you're entitled to your opinion @peter__r but the block size limit found its way there for some reason and now you gotta deal with it

[10:23]
let's just say that science has evolved

[10:23]
and leave it at that, shall we?

shinobimonkey [10:23 PM]
Peter, why did the p2p network have a 32 MB message limit then?

Peter R [10:23 PM]
@anthony: right, it allows all values to be expressed as floating point doubles without truncating any digits.

shinobimonkey [10:24 PM]
why did Satoshi implement that if he intended there to be no bounds on the blocksize limit?

Peter R [10:24 PM]
That's why I picked 10M in my example and not 100M :slightly_smiling_face:

[10:24]
But really, that point is minor anyhow.

brg444 [10:24 PM]
is this 2015?

anthony [10:24 PM]
:slightly_smiling_face:

[10:25]
maybe it is 2015

shinobimonkey [10:25 PM]
Peter? p2p limit?

Eric Lombrozo [10:25 PM]
the amounts are all handled internally as integers, @anthony

anthony [10:25 PM]
that's when america was great before, right?

Eric Lombrozo [10:25 PM]
there is no floating point type used except for user-facing stuff and APIs

shinobimonkey [10:25 PM]
what was that about,creating an upper limit on the size of things the client relays, if blocksize was to be totally unbounded?

[10:25]
why did Satoshi do that?

Peter R [10:26 PM]
@Eric: the point is that a wallet _could_ use floating points without losing information.

anthony [10:26 PM]
There was no floating point used in 0.1?

Peter R [10:26 PM]
Not in the core protocol. (edited)

shinobimonkey [10:26 PM]
no response Peter?

Eric Lombrozo [10:27 PM]
the white paper and first implementation was an amazing proof-of-concept for the proof-of-work idea...but it was hardly a finished network

shinobimonkey [10:28 PM]
set the channel topic: Why did Satoshi implement a p2p message limit?

Eric Lombrozo [10:28 PM]
expecting a flood network where every computer must validate every other computer's transaction to scale massively clearly is insane

shinobimonkey [10:28 PM]
:smile:

Eric Lombrozo [10:28 PM]
there's a lot of work remaining to be done to complete the network

anthony [10:28 PM]
heh you sound like the people who argued that bitcoin was impossible

shinobimonkey [10:28 PM]
and Peter sounds...quiet

[10:29]
because he's still ignoring my question, like always

Peter R [10:29 PM]
@shinobimonkey: all I do when I come here is answer your questions!

shinobimonkey [10:29 PM]
no you don't, you dodge them, change the topic, and then pretend like nothing weird is going on

Eric Lombrozo [10:29 PM]
fortunately we now know of ways to avoid forcing every computer to validate every single transaction by focusing on disputes for on-chain resolution and letting peers transact directly as long as there's no dispute (edited)

shinobimonkey [10:29 PM]
you just went and did it right there Peter, again

Eric Lombrozo [10:30 PM]
no need to play gotcha :wink:

shinobimonkey [10:30 PM]
if Satoshi envisioned unbounded blocksizes, why did he implement a p2p message limit?

[10:30]
surely he would have realized, if he intended unbounded blocks, that would be a problem?

Eric Lombrozo [10:30 PM]
arguing online just to win arguments is like competing in the special olympics

shinobimonkey [10:30 PM]
I'm a special person Eric :slightly_smiling_face:

Eric Lombrozo [10:30 PM]
even if you win you're still...ehm...mentally challenged?

anthony [10:31 PM]
that's not part of the consensus protocol

Peter R [10:31 PM]
He implemented a p2p message limit to prevent DoS attacks.

[10:31]
The limit was _far_ above demand at that time.

shinobimonkey [10:31 PM]
and wow...then after that...he did the same thing with the blocksize

[10:31]
go figure

brg444 [10:31 PM]
Also, the fixed supply is only as fixed as Bitcoin is decentralized so essentially your "central property" hinges on strong diversity of validating nodes which the blocksize limit helps preserve.

shinobimonkey [10:32 PM]
security ---------------------------------------------------- convenience

[10:32]
theres the slider Peter, you move one way or the other

[10:32]
you don't just magically get more security by getting more convenience

anthony [10:32 PM]
it's more like a laffer curve

Peter R [10:33 PM]
@brg444: I don't believe a _fixed_ supply is a central property of Bitcoin.
 5 replies Last reply today at 12:42 PM View thread

shinobimonkey [10:33 PM]
newsflash: the vast majority of Bitcoiners would say you are wrong

Peter R [10:33 PM]
Yes, I agree they would.

Eric Lombrozo [10:33 PM]
the block size limit is an issue that never really got resolved satisfactorily. but the way to fix it isn't to incite hate against developers and lobby miners to try to strongarm the network using a mechanism that fundamentally cannot work

anthony [10:33 PM]
democracy!

[10:34]
let's vote on what is true and false

Eric Lombrozo [10:34 PM]
would have been nice to have more sane discussion on the topic rather than this strongarm approach

shinobimonkey [10:34 PM]
well, thats kind of hard with Peter consistently saying things the vast majority of people using Bitcoin find central to the system are not central to the system

Peter R [10:34 PM]
@elombrozo: right, the way to resolve it is to encourage nodes to increase their block size limits to what they believe is reasonable.

Eric Lombrozo [10:35 PM]
nodes will never be capable of enforcing that

shinobimonkey [10:35 PM]
and display a constant willingness to ignore preserving those things in context of design concerns

Eric Lombrozo [10:35 PM]
and miners won't either

Peter R [10:35 PM]
Once enough nodes have increased their block size limit, miners will be free to follow suit.

anthony [10:35 PM]
https://yourlogicalfallacyis.com/bandwagon
yourlogicalfallacyis.com
Your logical fallacy is bandwagon
You appealed to popularity or the fact that many people do something as an attempted form of validation.


Eric Lombrozo [10:35 PM]
it will provably result in a broken network

shinobimonkey [10:35 PM]
anthony: your application of logical fallacies is always way out of context

Eric Lombrozo [10:35 PM]
with different people not agreeing on which is the right blockchain

shinobimonkey [10:36 PM]
Bitcoin is what the sum of its users make it

[10:36]
so actually...its a completely valid statement

anthony [10:36 PM]
https://yourlogicalfallacyis.com/ad-hominem
yourlogicalfallacyis.com
Your logical fallacy is ad hominem
You attacked your opponent's character or personal traits in an attempt to undermine their argument.


shinobimonkey [10:36 PM]
nope, I didn't attack your character or traits

[10:36]
I attacked your actions

Peter R [10:36 PM]
@elombrozo: 10% of the network is already permitting blocks larger than 1 MB.  At what point would the network be broken?

shinobimonkey [10:36 PM]
out of context yet again

anthony [10:36 PM]
that's what character is!

Peter R [10:37 PM]
And if nodes increasing their block size limits breaks the network, how do you propose this can be prevented?

shinobimonkey [10:37 PM]
character: the mental and moral qualities distinctive to an individual.

Eric Lombrozo [10:37 PM]
there will necessarily be a dispute that has nothing to do with block size (most likely motivated by a desire for more money and/or power) and fracturing of consensus will be used as a wedge

[10:38]
it's a given - it's a law of human nature to politicize everything :wink:

[10:38]
giving nodes the choice over block size means agreement on whether a block is valid is now subjective, different rules can apply - and people will try to game this for nefarious purposes or to sabotage the network

[10:38]
you can count on it

[10:39]
just wait until there's a disputed transaction that gets reorged

[10:39]
then pandamonium

Peter R [10:39 PM]
But how to you prevent them for exercising a power they already have?

[10:39]
Nodes are _already_ increasing their block size limits and nothing has broken so far.

anthony [10:40 PM]
by forcing them to have to recompile to exercise that power :laughing:

shinobimonkey [10:40 PM]
the consensus rule is 1 MB block Peter

[10:40]
you either enforce that, or you open yourself to a security hole

Eric Lombrozo [10:40 PM]
nothing has broken because blocks in excess of the limit enforced by most nodes has not been exceeded

shinobimonkey [10:40 PM]
you are either in consensus, or not

Peter R [10:40 PM]
But it's only a rule if the network as a whole agrees it's a rule.  My node doesn't agree.

shinobimonkey [10:41 PM]
all you are doing is making it easier for people to break consensus, or warp consensus into a gray error

Peter R [10:41 PM]
If enough nodes eventually act like mine, then it will no longer be a rule.

shinobimonkey [10:41 PM]
instead of a black or white "valid or not valid"

[10:41]
wrong Peter

[10:41]
it will be a rule, on the correct network

[10:41]
and you will have forked onto a different network

Eric Lombrozo [10:42 PM]
as soon as you can begin to argue over whether a particular block is valid via arbitrary parameters supplied by users you open the door to serious abuse...and it will happen

[10:42]
as I said, just wait until there's a disputed transaction that gets reorg'd

Peter R [10:42 PM]
The door has always been open.  It is happening today.

shinobimonkey [10:42 PM]
thats is vague nonsense Peter

[10:42]
yes, people have always been able to fork off or attack the network

Eric Lombrozo [10:42 PM]
just because it can happen doesn't mean it should be encouraged

shinobimonkey [10:42 PM]
you are lobbying miners to use software that will make that easier

Eric Lombrozo [10:43 PM]
if it can happen it means bitcoin has broken

Peter R [10:43 PM]
Obviously people make their nodes enforce whatever rules they want.

[10:43]
That is just a statement of fact.

shinobimonkey [10:43 PM]
and if those rules diverge from Bitcoins, they are not enforcing Bitcoin's rules

[10:43]
should they fork onto a different chain, they are not longer participating in Bitcoin

[10:44]
they are participating in an altcoin or a temporary fork that will leave them blind

Peter R [10:44 PM]
You can argue that they _shouldn't_ run anything but Bitcoin Core.

Eric Lombrozo [10:44 PM]
it's still hard to exploit reorgs beyond a certain depth in profitable ways - but that would completely change if we started giving individual nodes choices over consensus rules

Peter R [10:44 PM]
But you can't force it.

Eric Lombrozo [10:45 PM]
it leads to a mode of operation that is *not at all* the way the system was designed to work

Peter R [10:46 PM]
Whether or not that is true (I believe it is false) you're still arguing for how things _ought_ to be.

[10:46]
I'm describing how things are.

[10:46]
And how they are is that node operators _can_ and _are_ increasing their nodes' block size limits.

shinobimonkey [10:46 PM]
no Peter, you are describing potential security problems with the system

[10:46]
and then attempting to assist people in attacking it

Eric Lombrozo [10:47 PM]
these are unsolved issues that need solutions - the incentives are already out-of-whack

Peter R [10:47 PM]
IMO the incentives are working properly.

[10:47]
But that's a normative statement on my part.

anthony [10:47 PM]
:bitcoin:

Eric Lombrozo [10:48 PM]
to the extent that it is working properly, the fact that people don't just arbitrarily change consensus rules has a lot to do with it :wink:

[10:49]
the moment it becomes possible for some random person I transact with to reverse my transaction on the grounds that "I don't like your block" the value of Bitcoin seems to lose a huge chunk of its foundation

[10:50]
sure, miners can reorg a chain - but we can be conservative in confirmation counts for greater security

[10:51]
it's still very costly to attack - whereas a "let's just change a consensus rule" attack by a cartel of miners could be done much more cheaply

[10:52]
especially considering it could always be applied retroactively

anthony [10:52 PM]
this seems like an argument in favor of BU

Eric Lombrozo [10:52 PM]
?

[10:53]
currently miners are physically incapable of getting blocks accepted by nodes unless they comply with the rules

anthony [10:54 PM]
I don't understand...they'll always be incapable of getting blocks accepted by nodes which don't comply with the rules set by those nodes

Eric Lombrozo [10:54 PM]
yes - and if nodes start just changing consensus rules arbitrarily, a fragmented network is inevitable sooner or later

anthony [10:55 PM]
sure, that has nothing to do with BU though

shinobimonkey [10:56 PM]
...yes it does

Eric Lombrozo [10:56 PM]
allowing nodes to change consensus limits is allowing them to change consensus rules

[10:56]
it causes the exact same kind of consensus failure as anything else

[10:56]
and consensus failure is a hard fail - it's not like a block is sort of acceptable

shinobimonkey [10:56 PM]
arbitrary changes to acceptable blocksize limit 1) puts confirmations network wide at risk, 2) radically alters the operation costs curve of nodes potentially

Eric Lombrozo [10:56 PM]
it either is acceptable or it is not, as per each node

[10:57]
that we're talking about the block size limit is really incidental to the argument I'm making

[10:57]
it could be any parameter that could result in a consensus failure if nodes do not agree

anthony [10:57 PM]
that's why I think you're not talking about BU

[10:57]
BU doesn't allow just any old arbitrary change

shinobimonkey [10:57 PM]
yes it does, to the Blocksize

Eric Lombrozo [10:58 PM]
it allows changing a parameter that is consensus-critical and will result in consensus failure if different nodes do not agree

[10:58]
the fact that consensus failure can be caused is the problem here - chances are it would be abused for reasons that have nothing to do with block size (or whatever the parameter changes)

[10:58]
the attack is to deliberately cause a consensus failure

anthony [10:59 PM]
so bitcoin users shouldn't be trusted with such awesome power? It's too dangerous, they might hurt themselves?

Eric Lombrozo [11:00 PM]
users wouldn't even have the power at all here

shinobimonkey [11:00 PM]
what happens if a block is minted thats 2 MB, and an exchange accepts a deposit in it because their node accepts 2 MB blocks, but then because no other miners accepted it, it gets orphaned after they've transferred fiat

[11:00]
then what?

[11:00]
and businesses like that, until there is an inchannel way to communicate this, have no fucking clue when something like that could happen

[11:01]
and Bitcoin, unlike most alts, actually sees frequent and heavy economic use

[11:01]
what about Local Bitcoin sellers?

[11:01]
anyone involved in a trasaction leading to fiat changing hands right after

anthony [11:01 PM]
I'm confused what you mean by "nodes" then, Eric

Eric Lombrozo [11:02 PM]
nodes cannot force other people to change consensus rules at all - they can only make sure that a given blockchain is valid and has the most work

[11:02]
if no blockchain exists with the rules they want that is widely accepted as valid, it doesn't matter that their node thinks it's valid

[11:04]
ultimately, it gives most of the power of deciding what is valid to things like big exchanges...and we've now introduced a single point of failure for the entire system

anthony [11:04 PM]
Nodes are run by people, and some people have a lot of influence on the consensus rules....that is, after all, what it means for the rules to be consensus rules

Eric Lombrozo [11:04 PM]
it doesn't even give miners this power - that's the funny thing :slightly_smiling_face:

anthony [11:05 PM]
I'm glad you recognize that, at least

Eric Lombrozo [11:05 PM]
it actually strips power away from miners and gives it to the people who buy the coins from the miners

anthony [11:05 PM]
gives the power to the economic majority

Eric Lombrozo [11:05 PM]
but if you get consensus failure, the entire system's reliability is put to question

anthony [11:06 PM]
not the cartel being run by the miners with the help of blockstream core

Eric Lombrozo [11:06 PM]
it is unlikely you'll get everyone on a single blockchain as soon as you start to play with changing consensus-critical rules that give people a chance to game the system

[11:06]
it's likely to lead to a cross-chain war

anthony [11:06 PM]
But that's exactly what we have been doing for years

Eric Lombrozo [11:07 PM]
we have?

anthony [11:07 PM]
Sure, every soft fork

shinobimonkey [11:07 PM]
there is no "blockstream core" anthony

anthony [11:07 PM]
oops...bitstream core...whatever they're called

[11:08]
the people who want to maintain their current control over bitcoin

Eric Lombrozo [11:08 PM]
nobody controls bitcoin

[11:08]
it's hard for people to understand that - and they want someone to control it

shinobimonkey [11:09 PM]
Blockstream _or_ Core have no control over Bitcoin anthony

[11:09]
I do, if you ran a node you do, everyone collectively validating and maintaining consensus does

anthony [11:09 PM]
nobody controls bitcoin in the long run

shinobimonkey [11:09 PM]
Core is not the dominant client because "Blockstream Core"

anthony [11:09 PM]
which is exactly why something like BU is inevitable

shinobimonkey [11:09 PM]
Core is the dominant client _because thats what most people chose to run_

Peter R [11:09 PM]
Nobody controls Bitcoin.  Nobody can prevent node operators from running software that permits larger blocks.

Eric Lombrozo [11:10 PM]
it's there for historical reasons - I don't think it's ideal. I even wrote my own stack from scratch because Bitcoin Core couldn't do what I wanted

anthony [11:10 PM]
taking away control from blockstream core or bitstream core or whatever they're called is the point

Eric Lombrozo [11:10 PM]
but emphatically, I never tried to force a consensus rule change

[11:10]
that's a completely different thing than writing a new implementation

anthony [11:10 PM]
that's what most people chose to run currently....maybe...I don't know the numbers nor do I particularly care about them

Eric Lombrozo [11:11 PM]
but it's not about the choice of client - it's about agreement on consensus rules

[11:11]
that the two are inextricably linked is a historical accident

[11:11]
it's certainly not ideal

anthony [11:12 PM]
well some people were arguing earlier that everyone should be using the same client...that having multiple clients is a bad thing

shinobimonkey [11:12 PM]
I was, because I think for the most part it is

[11:12]
you can use my name you know

Eric Lombrozo [11:13 PM]
having multiple implementations complicates some issues, but that's more of a technological deficiency than a philosophical ideal

anthony [11:13 PM]
I know you were one but I thought there were others

Eric Lombrozo [11:13 PM]
the philosophical ideal is that any implementation can be formally verified to enforce a specific set of rules that everyone else agrees on

Peter R [11:14 PM]
I don't understand how it is possible to "force" a consensus rule change.

shinobimonkey [11:14 PM]
in terms of non-mining nodes, it would be ideal, in terms of mining nodes, that presents risks to the network at large and not just your local client

Eric Lombrozo [11:14 PM]
I would prefer to see many implementations if we could get around the severe technical hurdle of ensuring that code actually does what it's intended to do

anthony [11:14 PM]
okay but why should 1MB (or 4 million points, under segwit) be part of those rules?

shinobimonkey [11:14 PM]
I'll repeat again peter__r : You created a closed group, implementing software design based solely on the interests of that closed group, ignoring the preferences of most businesses in the space, and lobby miners to run that software

[11:14]
thats how Peter

Eric Lombrozo [11:15 PM]
@anthony there was never a good solution to the block space resource issue - at the very beginning of Bitcoin it wasn't an issue because it had no users

[11:15]
for better or worse, a 1MB limit was added later on...without a good mechanism for increasing it or removing it later on

anthony [11:16 PM]
you increase it or remove it by increasing it or removing it

Eric Lombrozo [11:16 PM]
had the limit had growth built into it somehow, perhaps we wouldn't be having this discussion

[11:16]
but you can't just increase or remove it without consensus failure

[11:17]
this is the problem - it requires us to solve an extremely difficult political problem

[11:17]
with practically zero tolerance

anthony [11:17 PM]
it's only a difficult political problem because the core devs are fighting against it

Eric Lombrozo [11:17 PM]
that is certainly not the case

shinobimonkey [11:17 PM]
anthony, thats bullshit

[11:18]
100%

[11:18]
its difficult because everyone has to agree to the change, when the change happens, and implement that in sync

[11:18]
and if Core proposed a hardfork blocksize raise, I would stop running Core

[11:18]
and so would alot of people

anthony [11:18 PM]
that's not a political problem at all, that's a technical problem

[11:18]
and not a difficult one

shinobimonkey [11:18 PM]
yes it is anthony

Eric Lombrozo [11:18 PM]
the logistical issues are on top of the political issues

anthony [11:19 PM]
pick a block number, and get rid of the limit

Eric Lombrozo [11:19 PM]
but the political issues are certainly the less tractable of the two

shinobimonkey [11:19 PM]
that doesn't work anthony

[11:19]
a huge portion of nodes wouldn't upgrade to clients impementing that

Eric Lombrozo [11:19 PM]
increasing the cost to run a node while risking the possibility that nobody will accept your chain anymore is something many users are rightly concerned about

[11:19]
not just devs

shinobimonkey [11:19 PM]
and then you are not dealing with a technical issue, you are dealing with a "Is it okay to set a precedent of just kicking users off the network."

anthony [11:19 PM]
then they won't be able to use bitcoin much longer

shinobimonkey [11:20 PM]
thats not how this works anthony

[11:20]
you are the grandma pointing at someone going "Unfriend, unfriend."

[11:20]
thats not how this works

anthony [11:20 PM]
just contradicting me is not an argument

Eric Lombrozo [11:20 PM]
@shinobimonkey actually, it's not kicking users off the network...it's creating a new network and forcing users to abandon the old one

[11:20]
the first part is easy

shinobimonkey [11:20 PM]
yeah, but that is semantics based on the subjective viewpoint here

Eric Lombrozo [11:20 PM]
it's the second part that's hard :wink:

shinobimonkey [11:21 PM]
I would say rather anthony, they would continue using bitcoin for a time to come

anthony [11:21 PM]
forcing a few users to abandon the old one might be hard

shinobimonkey [11:21 PM]
and those who upgraded to a forking client, aren't using Bitcoin anymore

anthony [11:22 PM]
shinobimonkey and luke might stick to their bitcoin1mb foreva

[11:22]
most people aren't that stubborn :slightly_smiling_face:

shinobimonkey [11:22 PM]
anthony, like seriously, you do this constantly, are you trying to be obtuse?

[11:22]
If Bitcoin is now "Just trust miners, whatever they say, segmenting nodes off the network is fine" its not a store of value

[11:22]
why would i put money there knowing rules can be changed at any minute?

anthony [11:23 PM]
I never said anything about just trust the miners

shinobimonkey [11:23 PM]
that I could based on subjective fuzzy rules have my ability to validate taken at any time?

Eric Lombrozo [11:23 PM]
if Bitcoin turns into a network where some of the participants can coerce others into abandoning the original network I don't think it's that interesting to work on anymore

shinobimonkey [11:23 PM]
thats exactly what you re saying anthony

anthony [11:23 PM]
literally, right?

[11:23]
lol

shinobimonkey [11:23 PM]
that arbitrary consensus changes at any time are A-OK

[11:23]
thats just "trust miners, follow what miners say."

anthony [11:24 PM]
it's not arbitrary nor is it a consensus change, though

shinobimonkey [11:24 PM]
yes, it is

Eric Lombrozo [11:24 PM]
@shinobimonkey it's not even the miners who get to decide

[11:24]
bottom line is...will an exchange buy your coins?

shinobimonkey [11:24 PM]
if it survived instead of collapsing I expect thats what it devolves to

[11:24]
you either trust miners, or your view on the state of things is just up in the air

Eric Lombrozo [11:25 PM]
will Bitcoin continue to work as you expect it to? and will other people continue to honor your coins?

shinobimonkey [11:25 PM]
not if consensus changes can be made willy nilly

anthony [11:25 PM]
Bitcoin has always let some participants non-violently "coerce" others into abandoning the original network

[11:26]
that's how we got the 1MB limit in the first place

shinobimonkey [11:26 PM]
nope

[11:26]
we got that because Satoshi proposed it, and people accepted it

[11:26]
period

Eric Lombrozo [11:26 PM]
you mentioned soft forks earlier, @anthony - and yes, a soft fork that is malicious is just a 51% attack. But what distinguishes a 51% attack from the kinds of soft forks that have been proposed by the Core team is that they don't break backwards compatibility (old wallets continue to be able to transact just the same) and they use signaling to ensure that an overwhelming supermajority of hashpower is ready to also enforce it

anthony [11:26 PM]
right, that's why I used scare quotes around "coerce"

shinobimonkey [11:26 PM]
and it was a softfork

anthony [11:26 PM]
there's no actual coercion involved

shinobimonkey [11:26 PM]
it did not abandon the original network

anthony [11:27 PM]
you're free to run whatever code you want

Eric Lombrozo [11:27 PM]
soft forks that have these properties are considerably more challenging to code than just changing a hardcoded parameter

[11:27]
but they do not disenfranchise users and avoid consensus failure

anthony [11:28 PM]
I think you're the second person now who used the term "disenfranchise" to describe this

[11:28]
there's no disenfranchisement happening

shinobimonkey [11:28 PM]
false

Eric Lombrozo [11:29 PM]
if my Bitcoins might suddenly no longer be valid at an exchange because the exchange changed a consensus rule, I am disenfranchised

shinobimonkey [11:29 PM]
^

anthony [11:29 PM]
well that's between you and the exchange, though

[11:30]
and that's not even the way it happened with ETH/ETC, as I understand it...everyone still got to keep their ETC in the end

Eric Lombrozo [11:30 PM]
point is the value of Bitcoin depends on this not even being an issue

[11:30]
it was never part of any of the economic nor security models

anthony [11:31 PM]
well the way to make it not an issue is to stop making it an issue

[11:31]
get rid of the arbitrary blocksize limit

shinobimonkey [11:31 PM]
dude

Eric Lombrozo [11:31 PM]
you can't without dealing with political realities

[11:31]
get used to the fact that nobody controls that shit

[11:32]
yes, not even Core devs

anthony [11:32 PM]
that some blockstream employees will whine?

shinobimonkey [11:32 PM]
you are being so dense anthony, *that is outside of developers hands*

[11:32]
and also, the blocksize is pretty much the only check against unbounded UTXO set growth (edited)

anthony [11:32 PM]
fine, it's outside of developers hands

[11:32]
stop blaming developers for it

Eric Lombrozo [11:32 PM]
yes, please :slightly_smiling_face:

shinobimonkey [11:33 PM]
I'm the guy to have that conversation with anthony, and people like me

anthony [11:33 PM]
great, so BU is a good thing

shinobimonkey [11:33 PM]
nope, its beyond retarded

[11:33]
and completely breaks the networks security in multiple ways

anthony [11:33 PM]
it takes it out of the developers hands

shinobimonkey [11:33 PM]
its already out of developer's hands

Eric Lombrozo [11:33 PM]
it never was in developers' hands

anthony [11:33 PM]
sure it was, it was imposed by satoshi

Eric Lombrozo [11:33 PM]
if vitalik can't coerce everyone off the old ethereum chain, what makes you think any Core devs can do an equivalent feat on Bitcoin?

shinobimonkey [11:34 PM]
and guess what anthony

anthony [11:34 PM]
I didn't say it was coercion, you're the one who called it that

shinobimonkey [11:34 PM]
*users still had to adopt it*

anthony [11:34 PM]
and now users are wising up and adopting choice

shinobimonkey [11:34 PM]
no, morons are pushing incredibly retarded things to spread lies to people (edited)

[11:35]
users have choice *right now*

[11:35]
follow consensus, or break from consensus

[11:35]
changing consensus is not a technical issue

[11:35]
its a political one

[11:36]
you knew there was a 1 MB blocksize, you knew there were 21 Million coins, you knew how this system worked

[11:36]
and you bought in

Eric Lombrozo [11:36 PM]
the only thing Bitcoin  developers have really done is warned that bad things might happen if people choose to do X. They can do X if they want to, nobody is stopping them. In hindsight, it is clear that people had a hard time understanding that nobody had this control...and developers got blamed for just telling people that if they did this it would break the network

shinobimonkey [11:36 PM]
well now you have a choice: sell, or don't

[11:36]
participate in consensus, or don't

[11:36]
changing consensus is entirely political, and has absolute zero guarantees to work

anthony [11:36 PM]
I never bought in to a 1MB blocksize

shinobimonkey [11:36 PM]
yes you did

[11:36]
if you just assumed it would just change, you were misinformed or deluded

anthony [11:36 PM]
I bought in to a promise that that was a temporary limit which would be removed

shinobimonkey [11:36 PM]
then guess what, you didn't do your homework

[11:37]
you were misinformed

[11:37]
thats not how that works

[11:37]
its a consensus rule: take it, or leave it

anthony [11:37 PM]
sure, the core devs who said that lied

shinobimonkey [11:37 PM]
if you want to change it, start having geniune discussions

[11:37]
not just fake arrogant statements of "We'll just change that, thats just how it works."

Eric Lombrozo [11:37 PM]
arguing for or against the 1MB limit is besides the point - fact is it's there, and fact is how it got there probably wasn't the best way it could have gotten there. Question is how do we fix the problem without ending up with everyone pissed off at each other?

anthony [11:37 PM]
did luke ever make the hard fork he promised?

shinobimonkey [11:37 PM]
and wave off all consequences/dangers as irrelevant

anthony [11:37 PM]
or was that another lie?

shinobimonkey [11:38 PM]
he has been, and still is, working on it

[11:38]
if you stopped by here more than to be arrogant and troll, you would know that

Eric Lombrozo [11:38 PM]
How do we fix the problem without the network fracturing? without consensus failure?

anthony [11:38 PM]
so a lie about the timing

shinobimonkey [11:38 PM]
code has to be written, checked, and tested anthony

[11:38]
it just doesn't pop into existence cause someone said it would

Eric Lombrozo [11:38 PM]
these are very difficult problems and they have nothing to do with petty political posturing or stupid negotiation on deals that cannot be satisfied (edited)

anthony [11:39 PM]
he should have thought about that before he promised to write it

shinobimonkey [11:39 PM]
anthony, you are being intentionally obtuse

[11:39]
and just spouting misinformed rhetorical bullshit (edited)

Eric Lombrozo [11:40 PM]
we're trying to solve real problems here...and people are just trying to play gotcha

anthony [11:40 PM]
what problem are you trying to solve?

Eric Lombrozo [11:40 PM]
scroll up

anthony [11:41 PM]
the 1mb limit?

[11:42]
I mean, I'm not sure how to fix that problem, but I think BU is making a much better attempt at it than Core

shinobimonkey [11:42 PM]
they are not

Eric Lombrozo [11:42 PM]
if you consider that a solution then obviously you don't really understand the problem

anthony [11:42 PM]
The Core devs basically have created the problem

shinobimonkey [11:42 PM]
you literally completely ignored me pointing out earlier how *1 block* orphaned with their "design" could potentially fuck up millions of dollars

anthony [11:42 PM]
Maybe I just disagree with you about the problem

shinobimonkey [11:43 PM]
If you think destroying the security of confirmations for exchanges handling millions of dollars isn't a problem, you are an idiot

anthony [11:44 PM]
Maybe I am an idiot, but I don't think destroying the security of confirmations for exchanges handling millions of dollars isn't a problem.

[11:44]
but I'm sure you'll say that's *literally* what I think

Eric Lombrozo [11:45 PM]
we're dealing with very difficult challenges in uncharted territory - and to top it off, we have to continue to upgrade the plane while it's in midflight with no ability to ever land

[11:45]
it's hard enough to address these issues in a sane environment where people are sincere in their quest to solve the problem and admit what they do not know

anthony [11:46 PM]
Understood Eric. I hope you don't take the things I'm saying personally. I don't have any problem with you, so far as I know.

Eric Lombrozo [11:46 PM]
it's *much* harder to address when people are doing political campaigns pushing views that completely misrepresent the inherent complexity of the problem and push the blame onto volunteers who are great engineers but not necessarily the best at PR and politics

anthony [11:46 PM]
I actually appreciate your willingness to discuss it here

[11:48]
Hopefully LN will be the answer to everything...I'm skeptical, but keeping an open mind about it

Eric Lombrozo [11:48 PM]
it won't be the answer to everything - hate to disappoint you :wink:

[11:48]
but it will still be awesome

anthony [11:48 PM]
ha well I exaggerate

[11:48]
I'll settle for it being legal to use

[11:49]
although I guess I also have questions about who will pay for channel creation

[11:51]
(that kind of goes along with the legal to use thing, though....if it's legal to use, then exchanges and big merchants and payment aggregators and such will pay for channel creation)

Eric Lombrozo [11:51 PM]
FWIW, I was always in favor of eventually fixing the max block size issue...but I feel like a bunch of other areas need to be worked on as well, and introducing such a huge political wedge with the real risk of forever fragmenting the network just to get a tiny increase in transaction throughput is totally absurd

[11:52]
let's face the fact here - it was used as a wedge in a campaign to "fire the Core devs" and replace them with people who would more easily do Corporate bidding...but thing is the system fundamentally doesn't work like this

[11:53]
so if some of the volunteers who have done this work that these companies hope to profit from for free are a little peeved, it has to be understood in this context :wink:

anthony [11:53 PM]
I was never for a tiny increase in max block size; that's actually one of the problems I have with segwit

Eric Lombrozo [11:54 PM]
segwit isn't about a permanent fix to the block size issue

[11:54]
it's about fixing some other critical issues - and it also provides a short-term block size bump

anthony [11:54 PM]
right...that's my issue with it...it messes with block size but isn't a permanent fix to it

Eric Lombrozo [11:55 PM]
it wasn't meant to permanently fix it - such a fix doesn't exist (at least not that I know of) (edited)

[11:55]
all the proposed "fixes" are fundamentally broken

anthony [11:55 PM]
I know...that's my problem with it!

Eric Lombrozo [11:55 PM]
but why should segwit solve this problem?

anthony [11:55 PM]
It shouldn't...it shouldn't mess with block size at all

Eric Lombrozo [11:55 PM]
segwit solves a bunch of other problems *which we do know how to solve*

[11:55]
so why not solve those given we know how to fix them while we continue to look for ways to solve the problems we don't know a solution for yet?

anthony [11:56 PM]
first of all, in the end, I think segwit is better than nothing, and I support it

[11:56]
but I wish it didn't mess with block size

[11:56]
I think at the very least that has been a political negative of it

Eric Lombrozo [11:57 PM]
a discount for the witness is good for reducing UTXO bloat - and it turns out it's possible to nearly double typical block space without breaking older wallets

anthony [11:58 PM]
I actually had that discussion before and still don't think the discount for the witness will reduce UTXO bloat

Yoghurt [11:59 PM]
@anthony it's important to point out that segwit doesn't mess with the block size limit, it only adds another way to interpret it ;)

Eric Lombrozo [11:59 PM]
I believe in attacking problems which have known solutions and for which it's easy (or easier) to get consensus first, build goodwill, then go for the hard ones

anthony [11:59 PM]
now now, don't try to argue semantics with me....I'll point out that segwit eliminates the block size limit

Eric Lombrozo [11:59 PM]
a permanent fix to the block size issue is *hard*

[11:59]
it requires reassessing network incentives and considering a wide range of scenarios


----- Today January 23rd, 2017 -----
[12:00]
and people clearly have strong opinions on it and get very emotional

anthony [12:00 AM]
but I'd rather just say yknowwhatImean....it messes with the effective block size limit....or whatever you want to call it

Eric Lombrozo [12:00 AM]
so all in all, *not* the best issue to try to tackle first if you want better collaboration :wink:

anthony [12:01 AM]
the hard part is what we're going to do when the block reward gets too small

Eric Lombrozo [12:01 AM]
add to that the intent by some who pushed this agenda to "fire the Core devs" and there goes much of the goodwill - it's unfortunate, been trying to repair the damage

anthony [12:02 AM]
I was just thinking about another problem with that a few weeks ago

[12:02]
it fundamentally ruins the entire design of bitcoin

Yoghurt [12:03 AM]
Diminishing inflation ruins the design of Bitcoin?

anthony [12:03 AM]
I've heard arguments that a backlog of txes can solve that, but it can't

shinobimonkey [12:04 AM]
why not?

anthony [12:04 AM]
You could phrase it that was if you want to distract from the point, Yoghurt

[12:04]
because the backlog won't have a constant tx fee

shinobimonkey [12:04 AM]
and?

[12:05]
it'll smooth out over time based on the confirmation times people expect

[12:05]
and the curve will change based on inflow of new TXes, RBF, etc.

Yoghurt [12:06 AM]
Why is a constant tx fee remotely desirable?

anthony [12:06 AM]
the basic assumption of bitcoin's security is that the reward for each block is roughly equal....if the reward for a block is twice as much as the reward for building on that block, bad stuff happens

shinobimonkey [12:06 AM]
that can happen right now

[12:06]
its called an idiot paying 100 BTC in fees

anthony [12:06 AM]
sure, it can...but it's infrequent and probably no one has coded for it

shinobimonkey [12:06 AM]
in fact, it has happened multiple times

anthony [12:07 AM]
there are also potential technical fixes to that particular problem (edited)

shinobimonkey [12:07 AM]
oh pray tell us

anthony [12:07 AM]
I didn't create them...I think greg talks about one of them

[12:07]
and I don't have the url handy

shinobimonkey [12:07 AM]
you mean timelocking TXes for the next block?

[12:08]
mhmm?

anthony [12:08 AM]
if you don't want to believe me, fine, whatever, it's not an important point

[12:08]
probably

[12:08]
I don't remember

shinobimonkey [12:08 AM]
thats not a technical fix

[12:08]
thats users changing their behavior, and that is it

anthony [12:08 AM]
and like I said, it's not an important point

[12:08]
you're arguing about nothing

[12:08]
okay, I used the wrong terminology, sorry

Yoghurt [12:10 AM]
I see your point, anthony -- like how the incentives were such that miners would have done well to have taken a bribe from BFX such to never let the theft happen until weeks after the fact

shinobimonkey [12:10 AM]
heres another thing anthony, you wouldn't really have to do that...

anthony [12:10 AM]
but aside from an idiot paying 100 BTC in fees, which, like I said, and despite the fact that it has happened multiple times, is infrequent, if that starts happening on a regular basis it messes up the entire incentive to mine on the longest chain

shinobimonkey [12:10 AM]
if LN activity was prominent...there would ALWAYS be timelocked transactions

[12:10]
which again, would help create a predictable steady curve

anthony [12:10 AM]
if the fee for the tip is 2 times the fee for building on the tip, you only need 33 1/3% to be better off orphaning the tip

Yoghurt [12:11 AM]
imo this only upwardly changes the amount of work one must expect before considering a transaction final - and constant fees / reward per block won't change this.

anthony [12:12 AM]
doesn't it also give incentive to selfishly mine?

shinobimonkey [12:12 AM]
not if the fee curve is relativley even

[12:12]
and if things using timelock become prominent, there will be lots of those balancing that out too

anthony [12:12 AM]
but if blocks are full then fees go up the longer it takes to find a block

[12:13]
and the more blocks are orphaned, the longer it'll take to find a non-orphaned block

shinobimonkey [12:13 AM]
sounds like something the market will figure out

[12:13]
and thats ridiculous anthony

anthony [12:13 AM]
something the market will figure out?

shinobimonkey [12:13 AM]
miners will not sit there and orphan blocks forever

[12:13]
they would do that if there is NO fees to collect

[12:13]
if theres just slightly less, are you serious?

Yoghurt [12:13 AM]
in the end, the only direction of movement is forward

shinobimonkey [12:13 AM]
eventually the energy burned to orphan instead of moving forward translates to a loss

[12:14]
and then they move forward

anthony [12:14 AM]
why won't miners orphan blocks forever?

shinobimonkey [12:14 AM]
because unlike the proposed model here, there ARE fees to collect

[12:14]
just less

[12:15]
there is a point at which it profits them more to move forward instead of stall

[12:15]
and when that point is hit, they move forward

[12:15]
or they are fucking retards

anthony [12:15 AM]
the more blocks that are orphaned, the further away that point becomes

shinobimonkey [12:15 AM]
...

[12:15]
wrong

[12:16]
the more blocks that are orphaned, the CLOSER that point gets

anthony [12:16 AM]
as more blocks are orphaned, the fee difference increases

shinobimonkey [12:16 AM]
do you keep being a fucking retard and eating more loss for a tiny insignifcant gain?

[12:16]
no, you move forward

[12:16]
and get slightly less

anthony [12:16 AM]
the loss is on the person orphaned, not you

[12:17]
I guess eventually whoever has the most hash power will overwhelm the rest of the network though

shinobimonkey [12:17 AM]
dude, I'm done with this, seriously, its like walking hand and hand with a child and having to explain where to they should put their foot

anthony [12:17 AM]
so, yeah, you won't keep orphaning forever

[12:18]
instead you'll have winner takes all

[12:18]
I'm glad you're done though

anthony [12:31 AM]
Can LN transactions use anti-fee-sniping?

[12:36]
https://twitter.com/petertoddbtc/status/705264036284407809
Peter Todd @petertoddbtc
@el33th4xor It doesn't happen often enough to bother is most likely explanation - need significantly larger fee than 25BTC to be worthwhile.
TwitterMarch 2nd, 2016 at 9:30 PM

[12:39]
https://twitter.com/petertoddbtc/status/705264517954060288
Peter Todd @petertoddbtc
@el33th4xor This will be an issue as the mining reward drops mind you; my anti-fee-sniping is a partial fix: https://github.com/bitcoin/bitcoin/blob/e5121eb951c49b36b2b55069ab778a74bbf6bcb1/src/wallet/wallet.cpp#L1973
TwitterMarch 2nd, 2016 at 9:32 PM

Yoghurt [12:43 AM]
yeah..
anthony
I guess eventually whoever has the most hash power will overwhelm the rest of the network though
Posted in #debateToday at 12:17 AM

[12:45]
I'm kind of thinking we're already there with Bitmain effectively controlling most of the hashing power

[12:45]
their incentive now, is to hide that fact

[12:46]
and exploit it through initiatives like BU

1501 [1:21 AM]
at some point they gotta give up. im not sure this BU strategy is working out for them?

[1:23]
imo the miners are testing the waters. but they will only learn what we already know. bitcoin is decentralized and you cant force through a change. miners are not in charge etc. but i wonder how much time they require to realise this. meanwhile bitcoin wait.

adam levo [2:59 AM]
joined #debate. Also, @tbolt256 joined, @firebird2490 joined, @coco joined.

mrhodl [4:21 AM]
@peter__r sounds like we should have a talk. We need everyone to to understand where you are coming from. Let me know when you're ready to come on whalepool (edited)

1501 [4:41 AM]
i stopped taking that guy serously. no offence.

[4:42]
it sucks

mrhodl [4:42 AM]
Now we need everyone else to do the same

1501 [4:42 AM]
but im not going to listen to him anymore

mrhodl [4:42 AM]
We just need to give him a platform so people can hear his voice

[4:42]
All his gems are hidden here

1501 [4:42 AM]
he will just piss everyone off

mrhodl [4:43 AM]
Good ?

1501 [4:43 AM]
well if you like being pissed off i guess. but i see your point