Advertisement
Guest User

Untitled

a guest
Oct 21st, 2016
1,484
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 19.22 KB | None | 0 0
  1. *** COPY AND PASTE TEXT BELOW THE LINES INTO https://wordcounter.net/ ***
  2. *** RESULTS: 3,211 words 19,034 characters ***
  3. ________________________________________________________
  4. ________________________________________________________
  5.  
  6. Only 2% of blocks are signaling support for anything other than the defaults right now.
  7.  
  8. that isn't true.
  9.  
  10. that isn't true, it was softforked many times however.
  11.  
  12. You can take an original bitcoin node, bridge it onto the network and have it sync all the way up to 2014 before its unreliability with blocks >500k in size will eventually make it get stuck. If you change a setting in it, it will sync all the way up to current. (though it might take months to do so. :) )
  13.  
  14. If their software was simply buggy, they would fix it. They are having to hardfork because their design is seriously flawed and lets attackers impose high load every node in the network which can't effectively be stopped without changing the protocol rules.
  15.  
  16. What I write isn't even carefully planned by myself, much less anyone else.
  17. We don't. I think segwit has only even been discussed in internal meetings twice, both in the form of explaining whats up and thanking staff for their self-directed contributions to the Bitcoin ecosystem.
  18.  
  19. I have no idea how that could make us money; doubly so since we have no plants to monetize lightning in relation to Bitcoin.
  20.  
  21. Haha. No, that isn't the case-- Lightning was proposed long before SW was even imagined. Some of the current implementations are forward looking and use segwit, but lightning doesn't need segwit. (Though if it did, it still wouldn't make me care so much).
  22.  
  23. Pretty much only place I'm bothering to discuss any of this stuff is at rbtc, because it's the only place where repeated lies, left uncorrected, have resulted in main stream press printing outright libel... due to the mixture of irresponsible management of the venue, and an extreme number of accounts piloted by people without a shred of integrity.
  24.  
  25. But you say I'm at other forums and conferences.. Can you name one conference I've been at in the last 6 months? How about another forum, other than reddit that I've posted in more than a couple times?
  26.  
  27. Not one.
  28.  
  29. See. That is how rbtc is: Lots of very loudly stated lies. Shame on you and everyone who upvoted your post.
  30.  
  31. I think you dramatically underestimate how quickly I can churn out arguments on the internet.
  32.  
  33. If you believe that why do you keep posting?
  34.  
  35. ... I did give you a link. You're free to follow it and see that it responds to your question. It's pretty hard to lie about whats merged in Bitcoin Core.
  36.  
  37. No I didn't. Plain BFT distributed consensus is well known. Decentralized consensus is physically impossible. Bitcoin doesn't do either of these things, but something new and quite interesting.
  38.  
  39. wtf?
  40.  
  41. I don't expect there to be problems with activation now, either. Surprises happen, and I don't much care either way. I did my part, time for people who said they were concerned about capacity to show their true colors.
  42.  
  43. It doesn't matter-- which I specifically pointed out. The only place it really matters is in rbtc's twisted imagination.
  44.  
  45. Please, point us to this "crushing" that I am supposedly performing-- but no one here can apparently find, I'm sure it would be on the top of rbtc for weeks and grant you boundless karma.
  46.  
  47. In Bitcoin Core? Sure, https://github.com/bitcoin/bitcoin/pull/8149
  48.  
  49. On 1, I'm disappointed that you ignored the real substance of my response. If influence of the system is a dynamic tension between nodes and miners why do you think its proper to give miners the ability to act to exclude nodes?
  50.  
  51. On 2, People can participate in whatever way they are interested and able to-- your reply doesn't really say anything to counter my correction of your factually incorrect claim.
  52.  
  53.  
  54. Its unclear to me what you're trying to say here. In other words, your comment does nothing to dispell the idea that you are in communication with space aliens. -- it appears to just introduce a new accusation without any substance.
  55.  
  56. For the most part, through collaboration. It is in all the participants rational self interest to find ways to agree and compromise.
  57.  
  58. Doesn't exist.
  59.  
  60. If you'd like to see more communication with the public about whats going on in the bowels of Bitcoin technology you can help take on that task (by doing it yourself, or by paying someone else to help). Demanding other random people to do work for you without compensation is unethical. ... and not likely to work.
  61.  
  62. You keep making these allegations but you say nothing to support them. I don't believe it is possible to provide a constructive response to them. Is that your intention?
  63.  
  64. It's unclear to me what you're referring to here, but I'd be happy to provide a specific response to a specific statement.
  65.  
  66. It's baffling that you state this. There is a huge amount of public communication, virtually all of the Bitcoin projects activities are conducted in the full view of the public and in modes that are open for anyone to participate in. I agree it would be nice to have even more summary material, but that takes people willing to do this. Lets take it another way, look at the Linux kernel (a project with orders of magnitude more contributors and resources than Bitcoin core)-- which of the many things that the linux project provides that Bitcoin Core does not which you feel is most sorely lacking?
  67.  
  68. We can all see your conspicuous lack of answer here. The conclusion is obvious. </rbtclogic>
  69.  
  70. It isn't and I've posted over and over again here, that blockstream has no commercial plans for lightning on bitcoin. We've posted about our business model many times on Reddit, going way back: https://www.reddit.com/r/IAmA/comments/2k3u97/we_are_bitcoin_sidechain_paper_authors_adam_back/clhoo7d/
  71.  
  72. Gahah! This is NOT TRUE.
  73.  
  74. We stand to lose a lot if Bitcoin fails, but otherwise-- pretty much that.
  75.  
  76. The witness data isn't even stored or sent in a different place, it's just accounted for differently, so that old nodes do not include it in the size. But what I was speaking to was the economical effect-- what change does it make on the economics of using the Bitcoin network. The change it makes is equivalent to making the transactions smaller. Thats it.
  77.  
  78. That isn't so-- you have strictly more choice than you do with a hardfork. In a hardfork you must either upgrade or fork away. When a softfork happens you can upgrade, do nothing, or fork away. (There are also additional low impact ways to upgrade available in a softfork that don't exist in a hardfork).
  79.  
  80. Nope. Not for a long time, the minimum fee behavior on the network is whatever is required to keep the mempool size at 300 MB.
  81.  
  82. They're not-- don't you read rbtc's constant headlines for the past two years? blocks are full. The only time blocks aren't full is due to things like validationless mining or blocks created by recently restarted nodes.
  83.  
  84. It's one article on a previously inactive blog, because that is what has come up since the site was redone. There is about four kilowords of technical material queued up for publication now that has nothing to do with lightning.
  85.  
  86. I might as well say that trolling about blockstream is all you exist for, given that 100% of your posts in the last hour are about that.
  87.  
  88. wtf is the "crickets" for-- the post you are responding to is a thanks for a response and contains no question.
  89.  
  90. No, sidechains are completely unrelated to segwit.
  91.  
  92. It's sad that you're confused about how segwit works, but your insults make it clear you're not interested in understanding. None the less, you're still incorrect-- non-upgraded nodes continue to validate store and relay bitcoin transactions, they don't relay the segwit using ones-- but there is nothing new about that: old nodes don't relay new transaction styles.
  93.  
  94. Again, another "rbtc fact" that has no basis or no support.
  95.  
  96. What agenda are you talking about? This 'test' only works if there is actually something to dispute, unfortunately you've defined it circularly.
  97.  
  98. Of course it is-- widely replicated perpetual storage with no ongoing cost paid by me? I'd back my systems up into it if I could for free.
  99.  
  100. Nice citation. Oh wait, you didn't provide any... just more substanceless allegations.
  101.  
  102. We just redid the website, and until about two weeks ago we weren't really using the blog.
  103.  
  104. The two posts you're referring to, one is non technical-- talking about our participation in the lighting protocol summit with a half dozen other orgs. There will be many other things posted soon, now that we're using it.
  105.  
  106. Consider your same facts in another light. In 9 of the 10 months so far this year, lightning was only mentioned in one of them.
  107.  
  108. Thats not true, there are many gigabytes of unconfirmed transactions that exist. Websites showing smaller backlogs do so by placing an arbritary fee cutoff and only showing transactions above the cutoff.
  109.  
  110. Distributed != decenteralized. Distributed consensus-- where you have some known in advanced, fixed, set of participants ... works fantastically, at least for moderate numbers of participants. But the whole system is beholden to those parties.
  111.  
  112. Thanks for the demonstration.
  113.  
  114. People here "know" a lot of untrue misinformation; spread by constantly repeating the same lies over and over again, with many different pseudonyms such that people just accept it to be true without ever seeing any evidence for it. Quite impressive, really.
  115.  
  116. you appear to misunderstand a softfork-- no existing nodes are prevented from participating!
  117.  
  118. where does my company come into anything?
  119.  
  120. Measurements have showed that double spends of unconfirmed have a high success rate even without any RBF, worse-- many wallets didn't show you were double spent even after the double spend confirmed! With these facts its hard to say that RBF adds any risk for anyone.
  121.  
  122. Some do-- but it's only universally worked for a couple months. In the case of Bitcoin Core, we've been too busy working on segwit, though a bumping feature narrowly missed 0.13... one should be in the next major release.
  123.  
  124. We also have ancestor feerate mining now, which is another way to correct prices after the fact (though not as universally applicable and much more costly)... but that one needs less wallet support, some already make use of it basically by accident.
  125.  
  126. Because he wants to undermine it, he has said so explicitly. Supporting the rbtc party line makes for a reasonable effort to undermine Bitcoin.
  127.  
  128. For all these comments about "despicable practices" and crushing Bitcoin and what not.. there has been a total failure of anyone in this subreddit to provide any citation for any actual 'bad' action taken by me. Apparently I am "crushing bitcoin" by ... arguing with pseudonymous in rbtc.
  129.  
  130. No, -- current implementations are setup to use it but lightning was thought up and proposed long before segwit was even imagined.
  131.  
  132. But your response only adds more mystery, you're saying that Lighting is "the only thing [I or Blockstream] exist for?" what? I don't work on lightining at all, less than 10% of blockstream's developers do, and we have no commercial plans ourselves for lightning on the Bitcoin network. We got involved with it at all because Mike Hearn argued that if we thought it was important for Bitcoin's future why weren't we supporting its development-- he had a point, and because we realized that it would eventually be important technology for sidechains and our Bitcoin unrelated cryptographic products.
  133.  
  134. This isn't strictly true-- without people using the system what do nodes and miners matter. But moreover, your argument seems silly when we're talking about granting miners the ability to push nodes off the network; so your argument is an argument for care in this subject, not the indifference to nodes that you express.
  135.  
  136. In 0.13 there were commits by 100 distinct people.
  137.  
  138. This is nonsense. A couple people who are not heavy contributors met with some miners and agreed to work on some hardfork proposals after segwit was activated on their own. They were extremely politically naive in that they didn't expect their personal offer to work on some things to be immediately misrepresented as having any effect at all on a large community of users and developers which they have no control over... one could say that the matter was moot because F2Pool was signaling Bitcoin Classic pretty much immediately after in any case-- but the folks that said they'd work on that stuff still did it! ... but this has nothing to do with anyone but them.
  139.  
  140. What the heck are you talking about? It sounds like you expect someone to be "in charge" of Bitcoin and "tell you how it is"-- But NO ONE is in charge of Bitcoin, and this fact is fundamental to Bitcoin's value proposition. Nor is this really all that unusual, no one is in charge of HTTP or many other largely cooperative internet standards, and they still work well.
  141.  
  142. I can't think of anything in this case; but if there was awareness of a reason to do so already, it already would have been incorporated.
  143.  
  144. Absolutely not. It's pragmatic. The 95% threshold has been used for a while for softforks, BIP9 changed the measuring methodology in a way that radically upped the threshold (by making the comparison over twice as many blocks and making 1/2000th the number of comparisons); but the 95% was kept owing to having no particular reason to change it. It might turn out with further experience with BIP9 to have been better to do something somewhat different, there is no principled reason not to.
  145.  
  146. What kind of 'principle' would produce the number 95% in any case?
  147.  
  148. This constant claim that the thresholds are going to be changed or something is pure rbtc conjecture, and at every turn its been proven wrong.
  149.  
  150. This is a pretty meaningless explanation: The "average wait to first confirmation" over all unconfirmed transactions is infinite.
  151.  
  152. So yes, it doesn't depend on fees... but generally people are concerned about the wait for their own transaction, which very much depends on fees.
  153.  
  154. 21inc has a nice estimator webpage that shows expected wait times based on fees paid, https://bitcoinfees.21.co/
  155.  
  156. What the heck are you talking about?
  157.  
  158. Then I suppose you support handing complete control over Bitcoin to Bob, keeper of ledgers... because the belief that Bob would take any improper action against Bitcoin when he relies on income from it falls flat on its own stupidity?
  159.  
  160. With Bob at the helm we have have instantaneous confirmations, absolute immunity to reorganization, no risk of 51% attacks, and a utterly smooth path to even the most sophisticated upgrades.
  161.  
  162. (FWIW, Bitcoin miners have behaved improperly quite a few times in the past.)
  163.  
  164. Most of us have been completely clear that if a small group is able to use these techniques to force changes onto Bitcoin users that don't want them then we will consider the system a failure. There is no way we're going to 'just go work on BU', especially considering how abusive the people in charge of it have been.
  165.  
  166. Bitcoin uses a hashpower vote to accept and order transactions, not a traditional consensus. In theory the whole history could be wiped out at any time by a single party who just joined with a faster computer, or a single party with a remarkable amount of luck. This is fairly weak, compared to classical distributed consensus, where once a state update has been accepted you can be absolutely sure it's never going to get undone-- but good enough.
  167.  
  168. The parenthetical addition there is yours, not mine.
  169.  
  170. Bitcoin doesn't not achieve a strong form decentralized consensus-- what it achieves is different. Strong decenteralized consensus is physically possible. Without admissions, some greater super-majority could always show up from outside of your lightcone (where you couldn't possibly know about them).
  171.  
  172. I didn't say it was a failure-- just a "revealed preference".
  173.  
  174. Thank you for the highlight of my day, earnestly.
  175.  
  176. What position?
  177.  
  178. I have never claimed bitcoin was impossible. What is wrong with you?
  179.  
  180. Payment channels were invented by Bitcoin's creator-- and the transaction format has specific affordances to enable them (sequence numbers).
  181.  
  182. And rbtc by sidebarring and whitelisting all his properties. And by trading on the name of client software by collecting funds on their behalf on his site.
  183.  
  184. BIP62 is far from complete and even if it were it created a perpetual risk that any new script usage or script enhancement would be exposed to surprise malleability issues.
  185.  
  186. It was originally developed as a hardfork, in elements alpha. That design was abandoned because the design in Bitcoin is so much nicer-- that it's also deployable in practice is a bonus. The only suggestion made on the mailing list about this when Bitcoin's segwit design was proposed was to instead put the commitment at the top of the hash tree. ... which is where you might have put it designing from scratch. It's a 2 line of code difference, and even ignoring compatibility it actually has a negative effect-- would increase every spv proof by 32 bytes to achieve no gain. ... From a compatibility perspective it would be a disaster-- breaking every wallet and other piece of software that directly handles bitcoin blocks.
  187.  
  188. What does physically segregate even mean? This is digital data. It isn't physical. Segwit doesn't physically segregate anything-- even with a pretty expansive definition of physical: the transaction is still sent in a single message over the network.
  189.  
  190. Moreover, how scriptsig is placed with respect to the rest of the transaction is a product of serialization... which has nothing to do with consensus... consenting peers can serialize transactions between each other however they want-- regardless of what everyone else does, or store them on disk however they want if if they're the only node in the world that does it that way. I expect 0.14 to support a new more efficient serialization for disk and network usage.
  191.  
  192. So what you're suggesting as an alternative to segwit ... is also segwit.
  193.  
  194. No amount of blocksize increases no matter how much they're allowed to devastate the decentralization if the network can reduce the 99.9% percentile confirmation below an 70 minutes. Fortunately, it doesn't have to-- because we have technology that can give instant confirmations and lowers the load on the blockchain-- but that technology can only be securely deployed if the networks decentralization isn't undermined.
  195.  
  196. I said no altcoin of mention-- I wasn't aware of this latest fold in your dishonest scamcoin, but even if I were-- I wouldn't have mentioned it because you have a long history of lying about technology and I'm not aware of anyone using your altcoin.
  197.  
  198.  
  199.  
  200. ... "Double spends work reliably" and "Many parties accept unconfirmed transactions as final" are not incompatible facts.
  201.  
  202. Here is an example article with measurements.
  203.  
  204. How have I done that?
  205.  
  206. 2016-10-21 00:27:20.014452 UpdateTip: new best=000000000000000003b352e9329229d399d4011f01a251f4a5a9a81983c53a9c height=435175 version=0x20000000 log2_work=85.433994 tx=164516189 date='2016-10-21 00:26:57' progress=1.000000 cache=68.9MiB(47085tx) warning='2 of last 100 blocks have unexpected version'
  207.  
  208. It seems not.
  209.  
  210. Segwit itself is a huge compromise. One which was responded to with a slap to the face by the creation of 'Classic' with a HF proposal that offered the same capacity but none of the scalability and safety improvements that made it possible to convince so many to go along with segwit.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement