SHARE
TWEET

whalepanda smear tweet context

a guest Jan 23rd, 2017 190 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. anthony [10:01 PM]
  2. Is block size part of the core design of bitcoin?
  3.  
  4. Eric Lombrozo [10:12 PM]
  5. 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
  6.  
  7. Peter R [10:13 PM]
  8. Block size is never mentioned in the white paper.
  9.  
  10. Eric Lombrozo [10:13 PM]
  11. most of the consensus rules are not mentioned explicitly in the white paper
  12.  
  13. Peter R [10:13 PM]
  14. uploaded this image: Screen Shot 2017-01-22 at 10.13.37 PM.png
  15. Add Comment
  16.  
  17. Peter R [10:14 PM]
  18. The rules that enforce bitcoin's _money property_ are all mentioned. (edited)
  19.  
  20. brg444 [10:14 PM]
  21. duhh
  22.  
  23. [10:14]  
  24. we're doing bible thumping again
  25.  
  26. Peter R [10:15 PM]
  27. 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?
  28.  
  29. Eric Lombrozo [10:15 PM]
  30. it's an as-of-yet unsolved problem
  31.  
  32. [10:16]  
  33. as are other things such as thin clients
  34.  
  35. [10:17]  
  36. the white paper also makes no mention of mining pools nor ASICs nor selfish mining attacks nor a bunch of other stuff
  37.  
  38. brg444 [10:17 PM]
  39. @peter__r nor the 21M limit
  40.  
  41. [10:17]  
  42. so I guess that's not a central design of Bitcoin
  43.  
  44. anthony [10:18 PM]
  45. so brg444 is block size part of the core design of bitcoin?
  46.  
  47. brg444 [10:18 PM]
  48. i dont know what core design is
  49.  
  50. shinobimonkey [10:18 PM]
  51. its core to its functioning
  52.  
  53. [10:18]  
  54. disagreeing on it leads to a consensus break down
  55.  
  56. brg444 [10:19 PM]
  57. I know it's been there for most of its existence
  58.  
  59. Peter R [10:19 PM]
  60. @brg444: the precise limit of 21M isn't central.  It could have been 10M or there could have been perpetual tail inflation.
  61.  
  62. anthony [10:20 PM]
  63. 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
  64.  
  65. shinobimonkey [10:20 PM]
  66. that is false peter__r , again 21M cap is core to its functioning
  67.  
  68. Eric Lombrozo [10:20 PM]
  69. I think we're getting caught up in semantics
  70.  
  71. shinobimonkey [10:20 PM]
  72. the economics of how that system would self organize are totally different between a finite cap, and perpetual tail inflation
  73.  
  74. [10:21]  
  75. yeah we are Eric
  76.  
  77. brg444 [10:21 PM]
  78. @peter__r the precise limit of 1MB isn't central. It could have been 10MB or linear/log growth.
  79.  
  80. Eric Lombrozo [10:21 PM]
  81. the 21M cap is consensus-critical - but it isn't a fundamental design issue...it's in many ways an arbitrary parameter
  82.  
  83. brg444 [10:21 PM]
  84. sounds like just like in the case of 21M we're stuck with it..
  85.  
  86. Peter R [10:22 PM]
  87. 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.
  88.  
  89. brg444 [10:22 PM]
  90. 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
  91.  
  92. Peter R [10:22 PM]
  93. So, IMO, scarcity of bitcoins is a central property, scarcity of block space is not.
  94.  
  95. Eric Lombrozo [10:22 PM]
  96. 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
  97.  
  98. [10:23]  
  99. it was thought that it was something that could be fixed later
  100.  
  101. anthony [10:23 PM]
  102. I think I once knew why 21M actually makes a lot of sense; something about how C++ deals with real numbers
  103.  
  104. shinobimonkey [10:23 PM]
  105. 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."
  106.  
  107. [10:23]  
  108. its ridiculous
  109.  
  110. brg444 [10:23 PM]
  111. 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
  112.  
  113. [10:23]  
  114. let's just say that science has evolved
  115.  
  116. [10:23]  
  117. and leave it at that, shall we?
  118.  
  119. shinobimonkey [10:23 PM]
  120. Peter, why did the p2p network have a 32 MB message limit then?
  121.  
  122. Peter R [10:23 PM]
  123. @anthony: right, it allows all values to be expressed as floating point doubles without truncating any digits.
  124.  
  125. shinobimonkey [10:24 PM]
  126. why did Satoshi implement that if he intended there to be no bounds on the blocksize limit?
  127.  
  128. Peter R [10:24 PM]
  129. That's why I picked 10M in my example and not 100M :slightly_smiling_face:
  130.  
  131. [10:24]  
  132. But really, that point is minor anyhow.
  133.  
  134. brg444 [10:24 PM]
  135. is this 2015?
  136.  
  137. anthony [10:24 PM]
  138. :slightly_smiling_face:
  139.  
  140. [10:25]  
  141. maybe it is 2015
  142.  
  143. shinobimonkey [10:25 PM]
  144. Peter? p2p limit?
  145.  
  146. Eric Lombrozo [10:25 PM]
  147. the amounts are all handled internally as integers, @anthony
  148.  
  149. anthony [10:25 PM]
  150. that's when america was great before, right?
  151.  
  152. Eric Lombrozo [10:25 PM]
  153. there is no floating point type used except for user-facing stuff and APIs
  154.  
  155. shinobimonkey [10:25 PM]
  156. what was that about,creating an upper limit on the size of things the client relays, if blocksize was to be totally unbounded?
  157.  
  158. [10:25]  
  159. why did Satoshi do that?
  160.  
  161. Peter R [10:26 PM]
  162. @Eric: the point is that a wallet _could_ use floating points without losing information.
  163.  
  164. anthony [10:26 PM]
  165. There was no floating point used in 0.1?
  166.  
  167. Peter R [10:26 PM]
  168. Not in the core protocol. (edited)
  169.  
  170. shinobimonkey [10:26 PM]
  171. no response Peter?
  172.  
  173. Eric Lombrozo [10:27 PM]
  174. 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
  175.  
  176. shinobimonkey [10:28 PM]
  177. set the channel topic: Why did Satoshi implement a p2p message limit?
  178.  
  179. Eric Lombrozo [10:28 PM]
  180. expecting a flood network where every computer must validate every other computer's transaction to scale massively clearly is insane
  181.  
  182. shinobimonkey [10:28 PM]
  183. :smile:
  184.  
  185. Eric Lombrozo [10:28 PM]
  186. there's a lot of work remaining to be done to complete the network
  187.  
  188. anthony [10:28 PM]
  189. heh you sound like the people who argued that bitcoin was impossible
  190.  
  191. shinobimonkey [10:28 PM]
  192. and Peter sounds...quiet
  193.  
  194. [10:29]  
  195. because he's still ignoring my question, like always
  196.  
  197. Peter R [10:29 PM]
  198. @shinobimonkey: all I do when I come here is answer your questions!
  199.  
  200. shinobimonkey [10:29 PM]
  201. no you don't, you dodge them, change the topic, and then pretend like nothing weird is going on
  202.  
  203. Eric Lombrozo [10:29 PM]
  204. 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)
  205.  
  206. shinobimonkey [10:29 PM]
  207. you just went and did it right there Peter, again
  208.  
  209. Eric Lombrozo [10:30 PM]
  210. no need to play gotcha :wink:
  211.  
  212. shinobimonkey [10:30 PM]
  213. if Satoshi envisioned unbounded blocksizes, why did he implement a p2p message limit?
  214.  
  215. [10:30]  
  216. surely he would have realized, if he intended unbounded blocks, that would be a problem?
  217.  
  218. Eric Lombrozo [10:30 PM]
  219. arguing online just to win arguments is like competing in the special olympics
  220.  
  221. shinobimonkey [10:30 PM]
  222. I'm a special person Eric :slightly_smiling_face:
  223.  
  224. Eric Lombrozo [10:30 PM]
  225. even if you win you're still...ehm...mentally challenged?
  226.  
  227. anthony [10:31 PM]
  228. that's not part of the consensus protocol
  229.  
  230. Peter R [10:31 PM]
  231. He implemented a p2p message limit to prevent DoS attacks.
  232.  
  233. [10:31]  
  234. The limit was _far_ above demand at that time.
  235.  
  236. shinobimonkey [10:31 PM]
  237. and wow...then after that...he did the same thing with the blocksize
  238.  
  239. [10:31]  
  240. go figure
  241.  
  242. brg444 [10:31 PM]
  243. 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.
  244.  
  245. shinobimonkey [10:32 PM]
  246. security ---------------------------------------------------- convenience
  247.  
  248. [10:32]  
  249. theres the slider Peter, you move one way or the other
  250.  
  251. [10:32]  
  252. you don't just magically get more security by getting more convenience
  253.  
  254. anthony [10:32 PM]
  255. it's more like a laffer curve
  256.  
  257. Peter R [10:33 PM]
  258. @brg444: I don't believe a _fixed_ supply is a central property of Bitcoin.
  259.  5 replies Last reply today at 12:42 PM View thread
  260.  
  261. shinobimonkey [10:33 PM]
  262. newsflash: the vast majority of Bitcoiners would say you are wrong
  263.  
  264. Peter R [10:33 PM]
  265. Yes, I agree they would.
  266.  
  267. Eric Lombrozo [10:33 PM]
  268. 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
  269.  
  270. anthony [10:33 PM]
  271. democracy!
  272.  
  273. [10:34]  
  274. let's vote on what is true and false
  275.  
  276. Eric Lombrozo [10:34 PM]
  277. would have been nice to have more sane discussion on the topic rather than this strongarm approach
  278.  
  279. shinobimonkey [10:34 PM]
  280. 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
  281.  
  282. Peter R [10:34 PM]
  283. @elombrozo: right, the way to resolve it is to encourage nodes to increase their block size limits to what they believe is reasonable.
  284.  
  285. Eric Lombrozo [10:35 PM]
  286. nodes will never be capable of enforcing that
  287.  
  288. shinobimonkey [10:35 PM]
  289. and display a constant willingness to ignore preserving those things in context of design concerns
  290.  
  291. Eric Lombrozo [10:35 PM]
  292. and miners won't either
  293.  
  294. Peter R [10:35 PM]
  295. Once enough nodes have increased their block size limit, miners will be free to follow suit.
  296.  
  297. anthony [10:35 PM]
  298. https://yourlogicalfallacyis.com/bandwagon
  299. yourlogicalfallacyis.com
  300. Your logical fallacy is bandwagon
  301. You appealed to popularity or the fact that many people do something as an attempted form of validation.
  302.  
  303.  
  304. Eric Lombrozo [10:35 PM]
  305. it will provably result in a broken network
  306.  
  307. shinobimonkey [10:35 PM]
  308. anthony: your application of logical fallacies is always way out of context
  309.  
  310. Eric Lombrozo [10:35 PM]
  311. with different people not agreeing on which is the right blockchain
  312.  
  313. shinobimonkey [10:36 PM]
  314. Bitcoin is what the sum of its users make it
  315.  
  316. [10:36]  
  317. so actually...its a completely valid statement
  318.  
  319. anthony [10:36 PM]
  320. https://yourlogicalfallacyis.com/ad-hominem
  321. yourlogicalfallacyis.com
  322. Your logical fallacy is ad hominem
  323. You attacked your opponent's character or personal traits in an attempt to undermine their argument.
  324.  
  325.  
  326. shinobimonkey [10:36 PM]
  327. nope, I didn't attack your character or traits
  328.  
  329. [10:36]  
  330. I attacked your actions
  331.  
  332. Peter R [10:36 PM]
  333. @elombrozo: 10% of the network is already permitting blocks larger than 1 MB.  At what point would the network be broken?
  334.  
  335. shinobimonkey [10:36 PM]
  336. out of context yet again
  337.  
  338. anthony [10:36 PM]
  339. that's what character is!
  340.  
  341. Peter R [10:37 PM]
  342. And if nodes increasing their block size limits breaks the network, how do you propose this can be prevented?
  343.  
  344. shinobimonkey [10:37 PM]
  345. character: the mental and moral qualities distinctive to an individual.
  346.  
  347. Eric Lombrozo [10:37 PM]
  348. 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
  349.  
  350. [10:38]  
  351. it's a given - it's a law of human nature to politicize everything :wink:
  352.  
  353. [10:38]  
  354. 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
  355.  
  356. [10:38]  
  357. you can count on it
  358.  
  359. [10:39]  
  360. just wait until there's a disputed transaction that gets reorged
  361.  
  362. [10:39]  
  363. then pandamonium
  364.  
  365. Peter R [10:39 PM]
  366. But how to you prevent them for exercising a power they already have?
  367.  
  368. [10:39]  
  369. Nodes are _already_ increasing their block size limits and nothing has broken so far.
  370.  
  371. anthony [10:40 PM]
  372. by forcing them to have to recompile to exercise that power :laughing:
  373.  
  374. shinobimonkey [10:40 PM]
  375. the consensus rule is 1 MB block Peter
  376.  
  377. [10:40]  
  378. you either enforce that, or you open yourself to a security hole
  379.  
  380. Eric Lombrozo [10:40 PM]
  381. nothing has broken because blocks in excess of the limit enforced by most nodes has not been exceeded
  382.  
  383. shinobimonkey [10:40 PM]
  384. you are either in consensus, or not
  385.  
  386. Peter R [10:40 PM]
  387. But it's only a rule if the network as a whole agrees it's a rule.  My node doesn't agree.
  388.  
  389. shinobimonkey [10:41 PM]
  390. all you are doing is making it easier for people to break consensus, or warp consensus into a gray error
  391.  
  392. Peter R [10:41 PM]
  393. If enough nodes eventually act like mine, then it will no longer be a rule.
  394.  
  395. shinobimonkey [10:41 PM]
  396. instead of a black or white "valid or not valid"
  397.  
  398. [10:41]  
  399. wrong Peter
  400.  
  401. [10:41]  
  402. it will be a rule, on the correct network
  403.  
  404. [10:41]  
  405. and you will have forked onto a different network
  406.  
  407. Eric Lombrozo [10:42 PM]
  408. 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
  409.  
  410. [10:42]  
  411. as I said, just wait until there's a disputed transaction that gets reorg'd
  412.  
  413. Peter R [10:42 PM]
  414. The door has always been open.  It is happening today.
  415.  
  416. shinobimonkey [10:42 PM]
  417. thats is vague nonsense Peter
  418.  
  419. [10:42]  
  420. yes, people have always been able to fork off or attack the network
  421.  
  422. Eric Lombrozo [10:42 PM]
  423. just because it can happen doesn't mean it should be encouraged
  424.  
  425. shinobimonkey [10:42 PM]
  426. you are lobbying miners to use software that will make that easier
  427.  
  428. Eric Lombrozo [10:43 PM]
  429. if it can happen it means bitcoin has broken
  430.  
  431. Peter R [10:43 PM]
  432. Obviously people make their nodes enforce whatever rules they want.
  433.  
  434. [10:43]  
  435. That is just a statement of fact.
  436.  
  437. shinobimonkey [10:43 PM]
  438. and if those rules diverge from Bitcoins, they are not enforcing Bitcoin's rules
  439.  
  440. [10:43]  
  441. should they fork onto a different chain, they are not longer participating in Bitcoin
  442.  
  443. [10:44]  
  444. they are participating in an altcoin or a temporary fork that will leave them blind
  445.  
  446. Peter R [10:44 PM]
  447. You can argue that they _shouldn't_ run anything but Bitcoin Core.
  448.  
  449. Eric Lombrozo [10:44 PM]
  450. 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
  451.  
  452. Peter R [10:44 PM]
  453. But you can't force it.
  454.  
  455. Eric Lombrozo [10:45 PM]
  456. it leads to a mode of operation that is *not at all* the way the system was designed to work
  457.  
  458. Peter R [10:46 PM]
  459. Whether or not that is true (I believe it is false) you're still arguing for how things _ought_ to be.
  460.  
  461. [10:46]  
  462. I'm describing how things are.
  463.  
  464. [10:46]  
  465. And how they are is that node operators _can_ and _are_ increasing their nodes' block size limits.
  466.  
  467. shinobimonkey [10:46 PM]
  468. no Peter, you are describing potential security problems with the system
  469.  
  470. [10:46]  
  471. and then attempting to assist people in attacking it
  472.  
  473. Eric Lombrozo [10:47 PM]
  474. these are unsolved issues that need solutions - the incentives are already out-of-whack
  475.  
  476. Peter R [10:47 PM]
  477. IMO the incentives are working properly.
  478.  
  479. [10:47]  
  480. But that's a normative statement on my part.
  481.  
  482. anthony [10:47 PM]
  483. :bitcoin:
  484.  
  485. Eric Lombrozo [10:48 PM]
  486. 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:
  487.  
  488. [10:49]  
  489. 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
  490.  
  491. [10:50]  
  492. sure, miners can reorg a chain - but we can be conservative in confirmation counts for greater security
  493.  
  494. [10:51]  
  495. 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
  496.  
  497. [10:52]  
  498. especially considering it could always be applied retroactively
  499.  
  500. anthony [10:52 PM]
  501. this seems like an argument in favor of BU
  502.  
  503. Eric Lombrozo [10:52 PM]
  504. ?
  505.  
  506. [10:53]  
  507. currently miners are physically incapable of getting blocks accepted by nodes unless they comply with the rules
  508.  
  509. anthony [10:54 PM]
  510. 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
  511.  
  512. Eric Lombrozo [10:54 PM]
  513. yes - and if nodes start just changing consensus rules arbitrarily, a fragmented network is inevitable sooner or later
  514.  
  515. anthony [10:55 PM]
  516. sure, that has nothing to do with BU though
  517.  
  518. shinobimonkey [10:56 PM]
  519. ...yes it does
  520.  
  521. Eric Lombrozo [10:56 PM]
  522. allowing nodes to change consensus limits is allowing them to change consensus rules
  523.  
  524. [10:56]  
  525. it causes the exact same kind of consensus failure as anything else
  526.  
  527. [10:56]  
  528. and consensus failure is a hard fail - it's not like a block is sort of acceptable
  529.  
  530. shinobimonkey [10:56 PM]
  531. arbitrary changes to acceptable blocksize limit 1) puts confirmations network wide at risk, 2) radically alters the operation costs curve of nodes potentially
  532.  
  533. Eric Lombrozo [10:56 PM]
  534. it either is acceptable or it is not, as per each node
  535.  
  536. [10:57]  
  537. that we're talking about the block size limit is really incidental to the argument I'm making
  538.  
  539. [10:57]  
  540. it could be any parameter that could result in a consensus failure if nodes do not agree
  541.  
  542. anthony [10:57 PM]
  543. that's why I think you're not talking about BU
  544.  
  545. [10:57]  
  546. BU doesn't allow just any old arbitrary change
  547.  
  548. shinobimonkey [10:57 PM]
  549. yes it does, to the Blocksize
  550.  
  551. Eric Lombrozo [10:58 PM]
  552. it allows changing a parameter that is consensus-critical and will result in consensus failure if different nodes do not agree
  553.  
  554. [10:58]  
  555. 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)
  556.  
  557. [10:58]  
  558. the attack is to deliberately cause a consensus failure
  559.  
  560. anthony [10:59 PM]
  561. so bitcoin users shouldn't be trusted with such awesome power? It's too dangerous, they might hurt themselves?
  562.  
  563. Eric Lombrozo [11:00 PM]
  564. users wouldn't even have the power at all here
  565.  
  566. shinobimonkey [11:00 PM]
  567. 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
  568.  
  569. [11:00]  
  570. then what?
  571.  
  572. [11:00]  
  573. and businesses like that, until there is an inchannel way to communicate this, have no fucking clue when something like that could happen
  574.  
  575. [11:01]  
  576. and Bitcoin, unlike most alts, actually sees frequent and heavy economic use
  577.  
  578. [11:01]  
  579. what about Local Bitcoin sellers?
  580.  
  581. [11:01]  
  582. anyone involved in a trasaction leading to fiat changing hands right after
  583.  
  584. anthony [11:01 PM]
  585. I'm confused what you mean by "nodes" then, Eric
  586.  
  587. Eric Lombrozo [11:02 PM]
  588. 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
  589.  
  590. [11:02]  
  591. 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
  592.  
  593. [11:04]  
  594. 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
  595.  
  596. anthony [11:04 PM]
  597. 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
  598.  
  599. Eric Lombrozo [11:04 PM]
  600. it doesn't even give miners this power - that's the funny thing :slightly_smiling_face:
  601.  
  602. anthony [11:05 PM]
  603. I'm glad you recognize that, at least
  604.  
  605. Eric Lombrozo [11:05 PM]
  606. it actually strips power away from miners and gives it to the people who buy the coins from the miners
  607.  
  608. anthony [11:05 PM]
  609. gives the power to the economic majority
  610.  
  611. Eric Lombrozo [11:05 PM]
  612. but if you get consensus failure, the entire system's reliability is put to question
  613.  
  614. anthony [11:06 PM]
  615. not the cartel being run by the miners with the help of blockstream core
  616.  
  617. Eric Lombrozo [11:06 PM]
  618. 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
  619.  
  620. [11:06]  
  621. it's likely to lead to a cross-chain war
  622.  
  623. anthony [11:06 PM]
  624. But that's exactly what we have been doing for years
  625.  
  626. Eric Lombrozo [11:07 PM]
  627. we have?
  628.  
  629. anthony [11:07 PM]
  630. Sure, every soft fork
  631.  
  632. shinobimonkey [11:07 PM]
  633. there is no "blockstream core" anthony
  634.  
  635. anthony [11:07 PM]
  636. oops...bitstream core...whatever they're called
  637.  
  638. [11:08]  
  639. the people who want to maintain their current control over bitcoin
  640.  
  641. Eric Lombrozo [11:08 PM]
  642. nobody controls bitcoin
  643.  
  644. [11:08]  
  645. it's hard for people to understand that - and they want someone to control it
  646.  
  647. shinobimonkey [11:09 PM]
  648. Blockstream _or_ Core have no control over Bitcoin anthony
  649.  
  650. [11:09]  
  651. I do, if you ran a node you do, everyone collectively validating and maintaining consensus does
  652.  
  653. anthony [11:09 PM]
  654. nobody controls bitcoin in the long run
  655.  
  656. shinobimonkey [11:09 PM]
  657. Core is not the dominant client because "Blockstream Core"
  658.  
  659. anthony [11:09 PM]
  660. which is exactly why something like BU is inevitable
  661.  
  662. shinobimonkey [11:09 PM]
  663. Core is the dominant client _because thats what most people chose to run_
  664.  
  665. Peter R [11:09 PM]
  666. Nobody controls Bitcoin.  Nobody can prevent node operators from running software that permits larger blocks.
  667.  
  668. Eric Lombrozo [11:10 PM]
  669. 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
  670.  
  671. anthony [11:10 PM]
  672. taking away control from blockstream core or bitstream core or whatever they're called is the point
  673.  
  674. Eric Lombrozo [11:10 PM]
  675. but emphatically, I never tried to force a consensus rule change
  676.  
  677. [11:10]  
  678. that's a completely different thing than writing a new implementation
  679.  
  680. anthony [11:10 PM]
  681. that's what most people chose to run currently....maybe...I don't know the numbers nor do I particularly care about them
  682.  
  683. Eric Lombrozo [11:11 PM]
  684. but it's not about the choice of client - it's about agreement on consensus rules
  685.  
  686. [11:11]  
  687. that the two are inextricably linked is a historical accident
  688.  
  689. [11:11]  
  690. it's certainly not ideal
  691.  
  692. anthony [11:12 PM]
  693. well some people were arguing earlier that everyone should be using the same client...that having multiple clients is a bad thing
  694.  
  695. shinobimonkey [11:12 PM]
  696. I was, because I think for the most part it is
  697.  
  698. [11:12]  
  699. you can use my name you know
  700.  
  701. Eric Lombrozo [11:13 PM]
  702. having multiple implementations complicates some issues, but that's more of a technological deficiency than a philosophical ideal
  703.  
  704. anthony [11:13 PM]
  705. I know you were one but I thought there were others
  706.  
  707. Eric Lombrozo [11:13 PM]
  708. the philosophical ideal is that any implementation can be formally verified to enforce a specific set of rules that everyone else agrees on
  709.  
  710. Peter R [11:14 PM]
  711. I don't understand how it is possible to "force" a consensus rule change.
  712.  
  713. shinobimonkey [11:14 PM]
  714. 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
  715.  
  716. Eric Lombrozo [11:14 PM]
  717. 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
  718.  
  719. anthony [11:14 PM]
  720. okay but why should 1MB (or 4 million points, under segwit) be part of those rules?
  721.  
  722. shinobimonkey [11:14 PM]
  723. 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
  724.  
  725. [11:14]  
  726. thats how Peter
  727.  
  728. Eric Lombrozo [11:15 PM]
  729. @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
  730.  
  731. [11:15]  
  732. for better or worse, a 1MB limit was added later on...without a good mechanism for increasing it or removing it later on
  733.  
  734. anthony [11:16 PM]
  735. you increase it or remove it by increasing it or removing it
  736.  
  737. Eric Lombrozo [11:16 PM]
  738. had the limit had growth built into it somehow, perhaps we wouldn't be having this discussion
  739.  
  740. [11:16]  
  741. but you can't just increase or remove it without consensus failure
  742.  
  743. [11:17]  
  744. this is the problem - it requires us to solve an extremely difficult political problem
  745.  
  746. [11:17]  
  747. with practically zero tolerance
  748.  
  749. anthony [11:17 PM]
  750. it's only a difficult political problem because the core devs are fighting against it
  751.  
  752. Eric Lombrozo [11:17 PM]
  753. that is certainly not the case
  754.  
  755. shinobimonkey [11:17 PM]
  756. anthony, thats bullshit
  757.  
  758. [11:18]  
  759. 100%
  760.  
  761. [11:18]  
  762. its difficult because everyone has to agree to the change, when the change happens, and implement that in sync
  763.  
  764. [11:18]  
  765. and if Core proposed a hardfork blocksize raise, I would stop running Core
  766.  
  767. [11:18]  
  768. and so would alot of people
  769.  
  770. anthony [11:18 PM]
  771. that's not a political problem at all, that's a technical problem
  772.  
  773. [11:18]  
  774. and not a difficult one
  775.  
  776. shinobimonkey [11:18 PM]
  777. yes it is anthony
  778.  
  779. Eric Lombrozo [11:18 PM]
  780. the logistical issues are on top of the political issues
  781.  
  782. anthony [11:19 PM]
  783. pick a block number, and get rid of the limit
  784.  
  785. Eric Lombrozo [11:19 PM]
  786. but the political issues are certainly the less tractable of the two
  787.  
  788. shinobimonkey [11:19 PM]
  789. that doesn't work anthony
  790.  
  791. [11:19]  
  792. a huge portion of nodes wouldn't upgrade to clients impementing that
  793.  
  794. Eric Lombrozo [11:19 PM]
  795. 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
  796.  
  797. [11:19]  
  798. not just devs
  799.  
  800. shinobimonkey [11:19 PM]
  801. 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."
  802.  
  803. anthony [11:19 PM]
  804. then they won't be able to use bitcoin much longer
  805.  
  806. shinobimonkey [11:20 PM]
  807. thats not how this works anthony
  808.  
  809. [11:20]  
  810. you are the grandma pointing at someone going "Unfriend, unfriend."
  811.  
  812. [11:20]  
  813. thats not how this works
  814.  
  815. anthony [11:20 PM]
  816. just contradicting me is not an argument
  817.  
  818. Eric Lombrozo [11:20 PM]
  819. @shinobimonkey actually, it's not kicking users off the network...it's creating a new network and forcing users to abandon the old one
  820.  
  821. [11:20]  
  822. the first part is easy
  823.  
  824. shinobimonkey [11:20 PM]
  825. yeah, but that is semantics based on the subjective viewpoint here
  826.  
  827. Eric Lombrozo [11:20 PM]
  828. it's the second part that's hard :wink:
  829.  
  830. shinobimonkey [11:21 PM]
  831. I would say rather anthony, they would continue using bitcoin for a time to come
  832.  
  833. anthony [11:21 PM]
  834. forcing a few users to abandon the old one might be hard
  835.  
  836. shinobimonkey [11:21 PM]
  837. and those who upgraded to a forking client, aren't using Bitcoin anymore
  838.  
  839. anthony [11:22 PM]
  840. shinobimonkey and luke might stick to their bitcoin1mb foreva
  841.  
  842. [11:22]  
  843. most people aren't that stubborn :slightly_smiling_face:
  844.  
  845. shinobimonkey [11:22 PM]
  846. anthony, like seriously, you do this constantly, are you trying to be obtuse?
  847.  
  848. [11:22]  
  849. If Bitcoin is now "Just trust miners, whatever they say, segmenting nodes off the network is fine" its not a store of value
  850.  
  851. [11:22]  
  852. why would i put money there knowing rules can be changed at any minute?
  853.  
  854. anthony [11:23 PM]
  855. I never said anything about just trust the miners
  856.  
  857. shinobimonkey [11:23 PM]
  858. that I could based on subjective fuzzy rules have my ability to validate taken at any time?
  859.  
  860. Eric Lombrozo [11:23 PM]
  861. 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
  862.  
  863. shinobimonkey [11:23 PM]
  864. thats exactly what you re saying anthony
  865.  
  866. anthony [11:23 PM]
  867. literally, right?
  868.  
  869. [11:23]  
  870. lol
  871.  
  872. shinobimonkey [11:23 PM]
  873. that arbitrary consensus changes at any time are A-OK
  874.  
  875. [11:23]  
  876. thats just "trust miners, follow what miners say."
  877.  
  878. anthony [11:24 PM]
  879. it's not arbitrary nor is it a consensus change, though
  880.  
  881. shinobimonkey [11:24 PM]
  882. yes, it is
  883.  
  884. Eric Lombrozo [11:24 PM]
  885. @shinobimonkey it's not even the miners who get to decide
  886.  
  887. [11:24]  
  888. bottom line is...will an exchange buy your coins?
  889.  
  890. shinobimonkey [11:24 PM]
  891. if it survived instead of collapsing I expect thats what it devolves to
  892.  
  893. [11:24]  
  894. you either trust miners, or your view on the state of things is just up in the air
  895.  
  896. Eric Lombrozo [11:25 PM]
  897. will Bitcoin continue to work as you expect it to? and will other people continue to honor your coins?
  898.  
  899. shinobimonkey [11:25 PM]
  900. not if consensus changes can be made willy nilly
  901.  
  902. anthony [11:25 PM]
  903. Bitcoin has always let some participants non-violently "coerce" others into abandoning the original network
  904.  
  905. [11:26]  
  906. that's how we got the 1MB limit in the first place
  907.  
  908. shinobimonkey [11:26 PM]
  909. nope
  910.  
  911. [11:26]  
  912. we got that because Satoshi proposed it, and people accepted it
  913.  
  914. [11:26]  
  915. period
  916.  
  917. Eric Lombrozo [11:26 PM]
  918. 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
  919.  
  920. anthony [11:26 PM]
  921. right, that's why I used scare quotes around "coerce"
  922.  
  923. shinobimonkey [11:26 PM]
  924. and it was a softfork
  925.  
  926. anthony [11:26 PM]
  927. there's no actual coercion involved
  928.  
  929. shinobimonkey [11:26 PM]
  930. it did not abandon the original network
  931.  
  932. anthony [11:27 PM]
  933. you're free to run whatever code you want
  934.  
  935. Eric Lombrozo [11:27 PM]
  936. soft forks that have these properties are considerably more challenging to code than just changing a hardcoded parameter
  937.  
  938. [11:27]  
  939. but they do not disenfranchise users and avoid consensus failure
  940.  
  941. anthony [11:28 PM]
  942. I think you're the second person now who used the term "disenfranchise" to describe this
  943.  
  944. [11:28]  
  945. there's no disenfranchisement happening
  946.  
  947. shinobimonkey [11:28 PM]
  948. false
  949.  
  950. Eric Lombrozo [11:29 PM]
  951. if my Bitcoins might suddenly no longer be valid at an exchange because the exchange changed a consensus rule, I am disenfranchised
  952.  
  953. shinobimonkey [11:29 PM]
  954. ^
  955.  
  956. anthony [11:29 PM]
  957. well that's between you and the exchange, though
  958.  
  959. [11:30]  
  960. 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
  961.  
  962. Eric Lombrozo [11:30 PM]
  963. point is the value of Bitcoin depends on this not even being an issue
  964.  
  965. [11:30]  
  966. it was never part of any of the economic nor security models
  967.  
  968. anthony [11:31 PM]
  969. well the way to make it not an issue is to stop making it an issue
  970.  
  971. [11:31]  
  972. get rid of the arbitrary blocksize limit
  973.  
  974. shinobimonkey [11:31 PM]
  975. dude
  976.  
  977. Eric Lombrozo [11:31 PM]
  978. you can't without dealing with political realities
  979.  
  980. [11:31]  
  981. get used to the fact that nobody controls that shit
  982.  
  983. [11:32]  
  984. yes, not even Core devs
  985.  
  986. anthony [11:32 PM]
  987. that some blockstream employees will whine?
  988.  
  989. shinobimonkey [11:32 PM]
  990. you are being so dense anthony, *that is outside of developers hands*
  991.  
  992. [11:32]  
  993. and also, the blocksize is pretty much the only check against unbounded UTXO set growth (edited)
  994.  
  995. anthony [11:32 PM]
  996. fine, it's outside of developers hands
  997.  
  998. [11:32]  
  999. stop blaming developers for it
  1000.  
  1001. Eric Lombrozo [11:32 PM]
  1002. yes, please :slightly_smiling_face:
  1003.  
  1004. shinobimonkey [11:33 PM]
  1005. I'm the guy to have that conversation with anthony, and people like me
  1006.  
  1007. anthony [11:33 PM]
  1008. great, so BU is a good thing
  1009.  
  1010. shinobimonkey [11:33 PM]
  1011. nope, its beyond retarded
  1012.  
  1013. [11:33]  
  1014. and completely breaks the networks security in multiple ways
  1015.  
  1016. anthony [11:33 PM]
  1017. it takes it out of the developers hands
  1018.  
  1019. shinobimonkey [11:33 PM]
  1020. its already out of developer's hands
  1021.  
  1022. Eric Lombrozo [11:33 PM]
  1023. it never was in developers' hands
  1024.  
  1025. anthony [11:33 PM]
  1026. sure it was, it was imposed by satoshi
  1027.  
  1028. Eric Lombrozo [11:33 PM]
  1029. 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?
  1030.  
  1031. shinobimonkey [11:34 PM]
  1032. and guess what anthony
  1033.  
  1034. anthony [11:34 PM]
  1035. I didn't say it was coercion, you're the one who called it that
  1036.  
  1037. shinobimonkey [11:34 PM]
  1038. *users still had to adopt it*
  1039.  
  1040. anthony [11:34 PM]
  1041. and now users are wising up and adopting choice
  1042.  
  1043. shinobimonkey [11:34 PM]
  1044. no, morons are pushing incredibly retarded things to spread lies to people (edited)
  1045.  
  1046. [11:35]  
  1047. users have choice *right now*
  1048.  
  1049. [11:35]  
  1050. follow consensus, or break from consensus
  1051.  
  1052. [11:35]  
  1053. changing consensus is not a technical issue
  1054.  
  1055. [11:35]  
  1056. its a political one
  1057.  
  1058. [11:36]  
  1059. you knew there was a 1 MB blocksize, you knew there were 21 Million coins, you knew how this system worked
  1060.  
  1061. [11:36]  
  1062. and you bought in
  1063.  
  1064. Eric Lombrozo [11:36 PM]
  1065. 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
  1066.  
  1067. shinobimonkey [11:36 PM]
  1068. well now you have a choice: sell, or don't
  1069.  
  1070. [11:36]  
  1071. participate in consensus, or don't
  1072.  
  1073. [11:36]  
  1074. changing consensus is entirely political, and has absolute zero guarantees to work
  1075.  
  1076. anthony [11:36 PM]
  1077. I never bought in to a 1MB blocksize
  1078.  
  1079. shinobimonkey [11:36 PM]
  1080. yes you did
  1081.  
  1082. [11:36]  
  1083. if you just assumed it would just change, you were misinformed or deluded
  1084.  
  1085. anthony [11:36 PM]
  1086. I bought in to a promise that that was a temporary limit which would be removed
  1087.  
  1088. shinobimonkey [11:36 PM]
  1089. then guess what, you didn't do your homework
  1090.  
  1091. [11:37]  
  1092. you were misinformed
  1093.  
  1094. [11:37]  
  1095. thats not how that works
  1096.  
  1097. [11:37]  
  1098. its a consensus rule: take it, or leave it
  1099.  
  1100. anthony [11:37 PM]
  1101. sure, the core devs who said that lied
  1102.  
  1103. shinobimonkey [11:37 PM]
  1104. if you want to change it, start having geniune discussions
  1105.  
  1106. [11:37]  
  1107. not just fake arrogant statements of "We'll just change that, thats just how it works."
  1108.  
  1109. Eric Lombrozo [11:37 PM]
  1110. 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?
  1111.  
  1112. anthony [11:37 PM]
  1113. did luke ever make the hard fork he promised?
  1114.  
  1115. shinobimonkey [11:37 PM]
  1116. and wave off all consequences/dangers as irrelevant
  1117.  
  1118. anthony [11:37 PM]
  1119. or was that another lie?
  1120.  
  1121. shinobimonkey [11:38 PM]
  1122. he has been, and still is, working on it
  1123.  
  1124. [11:38]  
  1125. if you stopped by here more than to be arrogant and troll, you would know that
  1126.  
  1127. Eric Lombrozo [11:38 PM]
  1128. How do we fix the problem without the network fracturing? without consensus failure?
  1129.  
  1130. anthony [11:38 PM]
  1131. so a lie about the timing
  1132.  
  1133. shinobimonkey [11:38 PM]
  1134. code has to be written, checked, and tested anthony
  1135.  
  1136. [11:38]  
  1137. it just doesn't pop into existence cause someone said it would
  1138.  
  1139. Eric Lombrozo [11:38 PM]
  1140. 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)
  1141.  
  1142. anthony [11:39 PM]
  1143. he should have thought about that before he promised to write it
  1144.  
  1145. shinobimonkey [11:39 PM]
  1146. anthony, you are being intentionally obtuse
  1147.  
  1148. [11:39]  
  1149. and just spouting misinformed rhetorical bullshit (edited)
  1150.  
  1151. Eric Lombrozo [11:40 PM]
  1152. we're trying to solve real problems here...and people are just trying to play gotcha
  1153.  
  1154. anthony [11:40 PM]
  1155. what problem are you trying to solve?
  1156.  
  1157. Eric Lombrozo [11:40 PM]
  1158. scroll up
  1159.  
  1160. anthony [11:41 PM]
  1161. the 1mb limit?
  1162.  
  1163. [11:42]  
  1164. 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
  1165.  
  1166. shinobimonkey [11:42 PM]
  1167. they are not
  1168.  
  1169. Eric Lombrozo [11:42 PM]
  1170. if you consider that a solution then obviously you don't really understand the problem
  1171.  
  1172. anthony [11:42 PM]
  1173. The Core devs basically have created the problem
  1174.  
  1175. shinobimonkey [11:42 PM]
  1176. you literally completely ignored me pointing out earlier how *1 block* orphaned with their "design" could potentially fuck up millions of dollars
  1177.  
  1178. anthony [11:42 PM]
  1179. Maybe I just disagree with you about the problem
  1180.  
  1181. shinobimonkey [11:43 PM]
  1182. If you think destroying the security of confirmations for exchanges handling millions of dollars isn't a problem, you are an idiot
  1183.  
  1184. anthony [11:44 PM]
  1185. 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.
  1186.  
  1187. [11:44]  
  1188. but I'm sure you'll say that's *literally* what I think
  1189.  
  1190. Eric Lombrozo [11:45 PM]
  1191. 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
  1192.  
  1193. [11:45]  
  1194. 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
  1195.  
  1196. anthony [11:46 PM]
  1197. 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.
  1198.  
  1199. Eric Lombrozo [11:46 PM]
  1200. 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
  1201.  
  1202. anthony [11:46 PM]
  1203. I actually appreciate your willingness to discuss it here
  1204.  
  1205. [11:48]  
  1206. Hopefully LN will be the answer to everything...I'm skeptical, but keeping an open mind about it
  1207.  
  1208. Eric Lombrozo [11:48 PM]
  1209. it won't be the answer to everything - hate to disappoint you :wink:
  1210.  
  1211. [11:48]  
  1212. but it will still be awesome
  1213.  
  1214. anthony [11:48 PM]
  1215. ha well I exaggerate
  1216.  
  1217. [11:48]  
  1218. I'll settle for it being legal to use
  1219.  
  1220. [11:49]  
  1221. although I guess I also have questions about who will pay for channel creation
  1222.  
  1223. [11:51]  
  1224. (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)
  1225.  
  1226. Eric Lombrozo [11:51 PM]
  1227. 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
  1228.  
  1229. [11:52]  
  1230. 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
  1231.  
  1232. [11:53]  
  1233. 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:
  1234.  
  1235. anthony [11:53 PM]
  1236. I was never for a tiny increase in max block size; that's actually one of the problems I have with segwit
  1237.  
  1238. Eric Lombrozo [11:54 PM]
  1239. segwit isn't about a permanent fix to the block size issue
  1240.  
  1241. [11:54]  
  1242. it's about fixing some other critical issues - and it also provides a short-term block size bump
  1243.  
  1244. anthony [11:54 PM]
  1245. right...that's my issue with it...it messes with block size but isn't a permanent fix to it
  1246.  
  1247. Eric Lombrozo [11:55 PM]
  1248. it wasn't meant to permanently fix it - such a fix doesn't exist (at least not that I know of) (edited)
  1249.  
  1250. [11:55]  
  1251. all the proposed "fixes" are fundamentally broken
  1252.  
  1253. anthony [11:55 PM]
  1254. I know...that's my problem with it!
  1255.  
  1256. Eric Lombrozo [11:55 PM]
  1257. but why should segwit solve this problem?
  1258.  
  1259. anthony [11:55 PM]
  1260. It shouldn't...it shouldn't mess with block size at all
  1261.  
  1262. Eric Lombrozo [11:55 PM]
  1263. segwit solves a bunch of other problems *which we do know how to solve*
  1264.  
  1265. [11:55]  
  1266. 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?
  1267.  
  1268. anthony [11:56 PM]
  1269. first of all, in the end, I think segwit is better than nothing, and I support it
  1270.  
  1271. [11:56]  
  1272. but I wish it didn't mess with block size
  1273.  
  1274. [11:56]  
  1275. I think at the very least that has been a political negative of it
  1276.  
  1277. Eric Lombrozo [11:57 PM]
  1278. 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
  1279.  
  1280. anthony [11:58 PM]
  1281. I actually had that discussion before and still don't think the discount for the witness will reduce UTXO bloat
  1282.  
  1283. Yoghurt [11:59 PM]
  1284. @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 ;)
  1285.  
  1286. Eric Lombrozo [11:59 PM]
  1287. 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
  1288.  
  1289. anthony [11:59 PM]
  1290. now now, don't try to argue semantics with me....I'll point out that segwit eliminates the block size limit
  1291.  
  1292. Eric Lombrozo [11:59 PM]
  1293. a permanent fix to the block size issue is *hard*
  1294.  
  1295. [11:59]  
  1296. it requires reassessing network incentives and considering a wide range of scenarios
  1297.  
  1298.  
  1299. ----- Today January 23rd, 2017 -----
  1300. [12:00]  
  1301. and people clearly have strong opinions on it and get very emotional
  1302.  
  1303. anthony [12:00 AM]
  1304. but I'd rather just say yknowwhatImean....it messes with the effective block size limit....or whatever you want to call it
  1305.  
  1306. Eric Lombrozo [12:00 AM]
  1307. so all in all, *not* the best issue to try to tackle first if you want better collaboration :wink:
  1308.  
  1309. anthony [12:01 AM]
  1310. the hard part is what we're going to do when the block reward gets too small
  1311.  
  1312. Eric Lombrozo [12:01 AM]
  1313. 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
  1314.  
  1315. anthony [12:02 AM]
  1316. I was just thinking about another problem with that a few weeks ago
  1317.  
  1318. [12:02]  
  1319. it fundamentally ruins the entire design of bitcoin
  1320.  
  1321. Yoghurt [12:03 AM]
  1322. Diminishing inflation ruins the design of Bitcoin?
  1323.  
  1324. anthony [12:03 AM]
  1325. I've heard arguments that a backlog of txes can solve that, but it can't
  1326.  
  1327. shinobimonkey [12:04 AM]
  1328. why not?
  1329.  
  1330. anthony [12:04 AM]
  1331. You could phrase it that was if you want to distract from the point, Yoghurt
  1332.  
  1333. [12:04]  
  1334. because the backlog won't have a constant tx fee
  1335.  
  1336. shinobimonkey [12:04 AM]
  1337. and?
  1338.  
  1339. [12:05]  
  1340. it'll smooth out over time based on the confirmation times people expect
  1341.  
  1342. [12:05]  
  1343. and the curve will change based on inflow of new TXes, RBF, etc.
  1344.  
  1345. Yoghurt [12:06 AM]
  1346. Why is a constant tx fee remotely desirable?
  1347.  
  1348. anthony [12:06 AM]
  1349. 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
  1350.  
  1351. shinobimonkey [12:06 AM]
  1352. that can happen right now
  1353.  
  1354. [12:06]  
  1355. its called an idiot paying 100 BTC in fees
  1356.  
  1357. anthony [12:06 AM]
  1358. sure, it can...but it's infrequent and probably no one has coded for it
  1359.  
  1360. shinobimonkey [12:06 AM]
  1361. in fact, it has happened multiple times
  1362.  
  1363. anthony [12:07 AM]
  1364. there are also potential technical fixes to that particular problem (edited)
  1365.  
  1366. shinobimonkey [12:07 AM]
  1367. oh pray tell us
  1368.  
  1369. anthony [12:07 AM]
  1370. I didn't create them...I think greg talks about one of them
  1371.  
  1372. [12:07]  
  1373. and I don't have the url handy
  1374.  
  1375. shinobimonkey [12:07 AM]
  1376. you mean timelocking TXes for the next block?
  1377.  
  1378. [12:08]  
  1379. mhmm?
  1380.  
  1381. anthony [12:08 AM]
  1382. if you don't want to believe me, fine, whatever, it's not an important point
  1383.  
  1384. [12:08]  
  1385. probably
  1386.  
  1387. [12:08]  
  1388. I don't remember
  1389.  
  1390. shinobimonkey [12:08 AM]
  1391. thats not a technical fix
  1392.  
  1393. [12:08]  
  1394. thats users changing their behavior, and that is it
  1395.  
  1396. anthony [12:08 AM]
  1397. and like I said, it's not an important point
  1398.  
  1399. [12:08]  
  1400. you're arguing about nothing
  1401.  
  1402. [12:08]  
  1403. okay, I used the wrong terminology, sorry
  1404.  
  1405. Yoghurt [12:10 AM]
  1406. 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
  1407.  
  1408. shinobimonkey [12:10 AM]
  1409. heres another thing anthony, you wouldn't really have to do that...
  1410.  
  1411. anthony [12:10 AM]
  1412. 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
  1413.  
  1414. shinobimonkey [12:10 AM]
  1415. if LN activity was prominent...there would ALWAYS be timelocked transactions
  1416.  
  1417. [12:10]  
  1418. which again, would help create a predictable steady curve
  1419.  
  1420. anthony [12:10 AM]
  1421. 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
  1422.  
  1423. Yoghurt [12:11 AM]
  1424. 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.
  1425.  
  1426. anthony [12:12 AM]
  1427. doesn't it also give incentive to selfishly mine?
  1428.  
  1429. shinobimonkey [12:12 AM]
  1430. not if the fee curve is relativley even
  1431.  
  1432. [12:12]  
  1433. and if things using timelock become prominent, there will be lots of those balancing that out too
  1434.  
  1435. anthony [12:12 AM]
  1436. but if blocks are full then fees go up the longer it takes to find a block
  1437.  
  1438. [12:13]  
  1439. and the more blocks are orphaned, the longer it'll take to find a non-orphaned block
  1440.  
  1441. shinobimonkey [12:13 AM]
  1442. sounds like something the market will figure out
  1443.  
  1444. [12:13]  
  1445. and thats ridiculous anthony
  1446.  
  1447. anthony [12:13 AM]
  1448. something the market will figure out?
  1449.  
  1450. shinobimonkey [12:13 AM]
  1451. miners will not sit there and orphan blocks forever
  1452.  
  1453. [12:13]  
  1454. they would do that if there is NO fees to collect
  1455.  
  1456. [12:13]  
  1457. if theres just slightly less, are you serious?
  1458.  
  1459. Yoghurt [12:13 AM]
  1460. in the end, the only direction of movement is forward
  1461.  
  1462. shinobimonkey [12:13 AM]
  1463. eventually the energy burned to orphan instead of moving forward translates to a loss
  1464.  
  1465. [12:14]  
  1466. and then they move forward
  1467.  
  1468. anthony [12:14 AM]
  1469. why won't miners orphan blocks forever?
  1470.  
  1471. shinobimonkey [12:14 AM]
  1472. because unlike the proposed model here, there ARE fees to collect
  1473.  
  1474. [12:14]  
  1475. just less
  1476.  
  1477. [12:15]  
  1478. there is a point at which it profits them more to move forward instead of stall
  1479.  
  1480. [12:15]  
  1481. and when that point is hit, they move forward
  1482.  
  1483. [12:15]  
  1484. or they are fucking retards
  1485.  
  1486. anthony [12:15 AM]
  1487. the more blocks that are orphaned, the further away that point becomes
  1488.  
  1489. shinobimonkey [12:15 AM]
  1490. ...
  1491.  
  1492. [12:15]  
  1493. wrong
  1494.  
  1495. [12:16]  
  1496. the more blocks that are orphaned, the CLOSER that point gets
  1497.  
  1498. anthony [12:16 AM]
  1499. as more blocks are orphaned, the fee difference increases
  1500.  
  1501. shinobimonkey [12:16 AM]
  1502. do you keep being a fucking retard and eating more loss for a tiny insignifcant gain?
  1503.  
  1504. [12:16]  
  1505. no, you move forward
  1506.  
  1507. [12:16]  
  1508. and get slightly less
  1509.  
  1510. anthony [12:16 AM]
  1511. the loss is on the person orphaned, not you
  1512.  
  1513. [12:17]  
  1514. I guess eventually whoever has the most hash power will overwhelm the rest of the network though
  1515.  
  1516. shinobimonkey [12:17 AM]
  1517. 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
  1518.  
  1519. anthony [12:17 AM]
  1520. so, yeah, you won't keep orphaning forever
  1521.  
  1522. [12:18]  
  1523. instead you'll have winner takes all
  1524.  
  1525. [12:18]  
  1526. I'm glad you're done though
  1527.  
  1528. anthony [12:31 AM]
  1529. Can LN transactions use anti-fee-sniping?
  1530.  
  1531. [12:36]  
  1532. https://twitter.com/petertoddbtc/status/705264036284407809
  1533. Peter Todd @petertoddbtc
  1534. @el33th4xor It doesn't happen often enough to bother is most likely explanation - need significantly larger fee than 25BTC to be worthwhile.
  1535. TwitterMarch 2nd, 2016 at 9:30 PM
  1536.  
  1537. [12:39]  
  1538. https://twitter.com/petertoddbtc/status/705264517954060288
  1539. Peter Todd @petertoddbtc
  1540. @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
  1541. TwitterMarch 2nd, 2016 at 9:32 PM
  1542.  
  1543. Yoghurt [12:43 AM]
  1544. yeah..
  1545. anthony
  1546. I guess eventually whoever has the most hash power will overwhelm the rest of the network though
  1547. Posted in #debateToday at 12:17 AM
  1548.  
  1549. [12:45]  
  1550. I'm kind of thinking we're already there with Bitmain effectively controlling most of the hashing power
  1551.  
  1552. [12:45]  
  1553. their incentive now, is to hide that fact
  1554.  
  1555. [12:46]  
  1556. and exploit it through initiatives like BU
  1557.  
  1558. 1501 [1:21 AM]
  1559. at some point they gotta give up. im not sure this BU strategy is working out for them?
  1560.  
  1561. [1:23]  
  1562. 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.
  1563.  
  1564. adam levo [2:59 AM]
  1565. joined #debate. Also, @tbolt256 joined, @firebird2490 joined, @coco joined.
  1566.  
  1567. mrhodl [4:21 AM]
  1568. @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)
  1569.  
  1570. 1501 [4:41 AM]
  1571. i stopped taking that guy serously. no offence.
  1572.  
  1573. [4:42]  
  1574. it sucks
  1575.  
  1576. mrhodl [4:42 AM]
  1577. Now we need everyone else to do the same
  1578.  
  1579. 1501 [4:42 AM]
  1580. but im not going to listen to him anymore
  1581.  
  1582. mrhodl [4:42 AM]
  1583. We just need to give him a platform so people can hear his voice
  1584.  
  1585. [4:42]  
  1586. All his gems are hidden here
  1587.  
  1588. 1501 [4:42 AM]
  1589. he will just piss everyone off
  1590.  
  1591. mrhodl [4:43 AM]
  1592. Good ?
  1593.  
  1594. 1501 [4:43 AM]
  1595. well if you like being pissed off i guess. but i see your point
RAW Paste Data
Pastebin PRO Summer Special!
Get 60% OFF on Pastebin PRO accounts!
Top