How can it be any different when a lot of supply is locked in masternodes? None of the supply is "locked in masternodes". Masternodes do not hold coins. This is essentially an example of a distinction without a difference. A user needs to "lockup" 1000 DASH in order to operate a masternode. The DASH are "locked up" in a wallet because of said user wanting to "operate a masternode". Gotta love the word splicing here. Only the Instamine beneficiaries and the independently wealthy get to have Master Nodes. The rest of us have to use Slave Nodes, over which Master Nodes have complete power. That's supposed to be a good thing, according to Dash Logic. The problem with that cult doctrine is that it goes against the concept, recently discovered by Nick Szabo, called social scalability. The social scalability of an institutional technology depends on how that technology constrains or motivates participation in that institution, including protection of participants and the institution itself from harmful participation or attack. One way to estimate the social scalability of an institutional technology is by the number of people who can beneficially participate in the institution. Another way to estimate social scalability is by the extra benefits and harms an institution bestows or imposes on participants, before, for cognitive or behavioral reasons, the expected costs and other harms of participating in an institution grow faster than its benefits. The cultural and jurisdictional diversity of people who can beneficially participate in an institution is also often important, especially in the global Internet context. When you raise to 1000 Dash ($18,000) the barrier to entry for running a full node (CONOP) you kill decentralization as well as the diversity of participants, which destroys social scalability.Requiring Slave Nodes to trust Master Nodes also kills social scalability. These two fatal flaws mean Dash is useless except as a pump-and-dump Ponzi scheme. Of course all this is theoretical since Dash can't even scale from IPv4 to IPv6.  Emphasis on bolded section for those who are visually impaired. Thanks smoothie. I can't believe it's so difficult to have an intelligent conversation about the role Masternodes' high CONOP plays in determining Dash's (lack of) decentralization and social scalability. Instead of constructive responses we see the usual knee-jerk accusations of trolling, which have have lost all meaning due to misuse against Gmax, coblee, Tone Vays, Ric Spagni, and anyone else who fails to clap loudly for Evan's instamined scamcoin. Here's another problem with Masternodes.  |
|
|
|
... I didn't say anything assuming you'd reached any kind of conclusion about the ETF approval. I just asked WTF your links about Shkreli's friend had to do with it; I didn't "argue" anything by asking that question. Perhaps those critical thinking classes you teach should cover the concept of non sequitur!  My bad on this, I misremebered. And I could care less about trump so stop trying to sidetrack with that (yet another red herring). Of course you upgraded Os2 systems to NT, Duh that was years later. Your missing the point of my argument is that it failed even though it was better tech than win 3.0 or 3.1 I forget which was there at the time and WFW 3.11 was the nail because it had the networking bundled in. As a matter of fact M$ killed alot of gereat tech by bundling it in windows. They outright ripped off stacker and NU had to sell or would have had the same thing happen to them. Well, I didn't upgrade *all* the os2 systems to NT. There was that one Wally guy who was a die hard and would not switch because "boo hoo muh precious data silo" or some such lame excuse. I should have gone BOFH and/or Evil Ratbert on that dork. "Ohhh geee did that circuit accidentally get switched to 220, making your stupid overpriced Genuine IBM workstation into a smoke machine? Wow...that's just toooo baaaaadd!!"  Heh, I 'member Billgates of Borg assimilating all the 3rd party utilities. They even got antivirus eventually! Though CCleaner still lives.... But I'm glad to no longer be writing my own Winsock config and dealing with Cygwin or whatever in muh IP stack. The relevance for Monero is that "better" is a normative term, defined relative to the subjective task at hand. OS2 may have been better in terms of under the hood technology and for power users running the latest 32 bit apps, but for users requiring compatibility with protected-mode DOS programs using the older VCPI interface, OS2 was a non-starter. |
|
|
|
How can it be any different when a lot of supply is locked in masternodes? None of the supply is "locked in masternodes". Masternodes do not hold coins. This is essentially an example of a distinction without a difference. A user needs to "lockup" 1000 DASH in order to operate a masternode. The DASH are "locked up" in a wallet because of said user wanting to "operate a masternode". Gotta love the word splicing here. Only the Instamine beneficiaries and the independently wealthy get to have Master Nodes. The rest of us have to use Slave Nodes, over which Master Nodes have complete power. That's supposed to be a good thing, according to Dash Logic. The problem with that cult doctrine is that it goes against the concept, recently discovered by Nick Szabo, called social scalability. The social scalability of an institutional technology depends on how that technology constrains or motivates participation in that institution, including protection of participants and the institution itself from harmful participation or attack. One way to estimate the social scalability of an institutional technology is by the number of people who can beneficially participate in the institution. Another way to estimate social scalability is by the extra benefits and harms an institution bestows or imposes on participants, before, for cognitive or behavioral reasons, the expected costs and other harms of participating in an institution grow faster than its benefits. The cultural and jurisdictional diversity of people who can beneficially participate in an institution is also often important, especially in the global Internet context. When you raise to 1000 Dash ($18,000) the barrier to entry for running a full node (CONOP) you kill decentralization as well as the diversity of participants, which destroys social scalability. Requiring Slave Nodes to trust Master Nodes also kills social scalability. These two fatal flaws mean Dash is useless except as a pump-and-dump Ponzi scheme. Of course all this is theoretical since Dash can't even scale from IPv4 to IPv6. |
|
|
|
If the quadratic hashing issue is a truly a "non-problem" then why did Gavin write an unforgivably kludgy, quick and dirty, non-futureproof workaround for it?
Because Gavin is a pragmatist that endeavored to give the users what they wanted, as long as it did not cause any actual harm? I dunno - you'd need to ask him. Incidentally, I'm not aware of any 'unforgivably klugy' such work by him. To which pull req are you referring? After: You aren't even familiar with Gavin's sigop/sighash patch and the situation/history surrounding it,
I've certainly been aware of it, yet am not currently familiar with the (irrelevant) details. Thanks for the background. So which is it? Is your final answer "not aware" or "certainly aware?" Your initial tirade was insufficiently specific to know which specific pull req that you referred to as 'unbelievably klugy'. After you actually bothered to identify that to which you were referring, it was evident I was already aware of it. Said identification, of course, being exactly why I pointed out that the thing of which I was unaware was what thing you had not at that point identified. Accordingly, until you identified it, I was not aware of what specific thing you were referring to. This is absolutely elementary. English much? So you need to convince Gavin ... I don't need to convince Gavin of doodly-squat. He's an uninvolved third party in this discussion. So far, this discussion is you and me, and you have not as of yet bothered to identify any shortcoming to my observation of the fact that mining incentives are already aligned to make the quadratic sig hash issue a non-problem. After three rounds, I am about to conclude you are unable to. It's not like Gavin has written dozens of patches to fix workaround what you are now conceding is an "issue." My initial tirade could only refer to a single, specific patch because Gavin only wrote one patch to fix work around the quadratic hashing issue. There ARE NO OTHER tx_size limiting patches for you to have been confused by, you quivering deflecting hand-waving piece of shit. I'll change my mind about the O(n^2) attack being a "problem" when Gavin does, since he was the one who identified it as such. What happened to your overwhelming conviction that the quadratic sigop scaling problem isn't really an issue, merely an 'aspect' or 'attribute'? Oh that's right, I showed you where Gavin used the word "problem" to describe the potential attack vector, and you were thus BTFO. I'm not surprised you'd rather drop that point and pretend like it never happened, and glad you've decided to live in consensus reality, where an O(n^2) attack is considered by sane, informed people to be a PROBLEM. Pro tip: when you make a shitty unsupportable argument like "this O(n^2) issue isn't a problem or an issue, oops I called it an issue, I take that back, I mean to say 'aspect' or 'attribute'" and then drop it when BTFO, it reflects poorly on the rest of your credibility. If you didn't lack the necessary background required to form intelligent opinions on the subject matter, you'd be aware of GMAX and others' negative responses to Gavin's 100k tx size limit fix workaround. Those critical responses gave Gavin's quick and dirty proposal NACKs because it is unforgivably kludgy and the opposite of future-proof (requiring another hard fork if it needed to be changed). mining incentives are already aligned to make the quadratic sig hash issue a non-problem
Objection. Calls for speculation. Assumes facts not in evidence. Your anointed vision, epistemological closure, and metaphysical certainty don't count as evidence. But good luck deducing from first principles empirical matters of fact! How about, instead of hurling insults, and non-responsive drivel, you actually engage the topic with reasoning? Incapable?.
I'll do that right after you familiarize yourself with the essential aspects of the topic and stop glossing over vital bits simply because you were not aware of them (or not aware of their significance). The devil is in the detail. The details you casually and instantly dismiss as "irrelevant" are anything but. Get a clue or STFU. Asking you to know WTF you are talking about before promoting your worthless Bitcoin Horoscope opinion as incontrovertible fact is not asking too much; it's a reasonable request.  Wait, isn't "mining incentives" the same hand waving BS that BU claims will magically allow the network to handle unlimited block sizes? I'm sure that's just a coincidence....  /REKT |
|
|
|
... What does the anti-Trump FUD about Shkreli's friend have to do with the BTC ETF, and/or the inevitability of XMR ETFs? You don't need to tell me about 8088 blah blah blah. I owned one. 10 years later, my work-study job was doing IT on campus. I supported OS2 and NT systems and so am aware of their relative strengths and weaknesses. I learn tons of stuff from Wikipedia, all the time. Putting down information because it appears on that site is a cheap shot typical of preening snobs who lack a better argument than attacking the source source aggregator. The person who stated "OS/2 lacked device drivers for many common devices such as printers, particularly non-IBM hardware" is Michal Necasek, who wrote that in a little something called "The History of OS/2." I'll take his research (and my own recollection) over your distorted view, which seems to take pains to avoid acknowledging that NT is OS2 3.0. Your assertion that lacking a driver does not equate to "wouldn't support" is hilarious. Talk about a distinction without a difference! Blah Blah blah right back at you, first bolded you conveniently once again fail to see the half decade Os2 was available before New Technolowgy which was primarily Server targeted. Second bolded, nice red Herring, I never disagreed with his statement as a matter of fact I used it to point out your failure to understand the difference between "Lack" and "Would not support". Once again NT LAcked (NT didn't support by your definition) Driver support for a Huge percentage of the hardware used by the world. So you are trying to argue that NT was better than OS2 because it lacked driver support while NT lacked the same. You can't have it both ways. Third Bolded, I'm not sure what difference you don't get the difference between not supporting (as in will never work) and driver not available at that time is One of massive proportions that is a straight out distortion of the facts which my quote from your wiki link debunks. Try you logic fallacies on someone else you tire me son. Ohh and AFA whether ETF will pass or not, I could care less. Your trying to argue I said it won't because of the links I supplied when I said no such thing. I said it does not help. Another Logic fallacy one your part. Maybe when you were playing with your 8088 you should have also taken a critical thinking class. Your not arguing with a dashtard troll here. I'm aware OS2 spend years failing on the desktop market before its brave attempted pivot to the back office. The most common usage of "supports" refers to out-of-the-box turnkey support, not theoretical If-and-only-if-you-write-your-own-middleware Turing compatibility. NT supported most common peripherals out of the box; OS2 didn't. Sorry that you are still bitter about it two decades later.  When my OS2 users couldn't connect to the (beastly old unstoppable tank-like) Apple laser printers and/or goddamned HP JetDirect, I would simply upgrade them to NT. Spending time writing drivers for a soon-to-be-abandoned OS was not a viable option. The point is that NT (aka OS2 3.0) was great for both workstations and servers and had a long successful product lifecycle, in stark contrast to the failure of OS2. You said "I don't think this [anti-Trump FUD] is going to help BTC's EFT at all" followed by two links. In response, I asked "What does the anti-Trump FUD about Shkreli's friend have to do with the BTC ETF, and/or the inevitability of XMR ETFs?" I didn't say anything assuming you'd reached any kind of conclusion about the ETF approval. I just asked WTF your links about Shkreli's friend had to do with it; I didn't "argue" anything by asking that question. Perhaps those critical thinking classes you teach should cover the concept of non sequitur! |
|
|
|
Before getting BTFO: If the quadratic hashing issue is a truly a "non-problem" then why did Gavin write an unforgivably kludgy, quick and dirty, non-futureproof workaround for it? Because Gavin is a pragmatist that endeavored to give the users what they wanted, as long as it did not cause any actual harm? I dunno - you'd need to ask him. Incidentally, I'm not aware of any 'unforgivably klugy' such work by him. To which pull req are you referring? After getting BTFO: You aren't even familiar with Gavin's sigop/sighash patch and the situation/history surrounding it,
I've certainly been aware of it, yet am not currently familiar with the (irrelevant) details. Thanks for the background. So which is it? Is your final answer "not aware" or "certainly aware?" You admit having no clue about the details (instantly characterized as "irrelevant" despite you not being previously aware of them) yet continue to assert the validity of your anointed vision despite lacking the background required for such a churlish degree of certainty. I always reason from first principles, which is precisely why I don't omit inconvenient facts and messy empirical data, such as the quadratic hashing problem, when forming opinions and conclusions. Take your fact-free crystal ball and shove it deep up your worthless Gypsy fortune teller ass, OK? BTW, Gavin (not me) defined quadratic sigop validation time as a "problem."So you need to convince Gavin (not me) that your But Muh Incentives And Logical Inturrpolayshun Thought Experimunt analysis are correct, and he needn't worry about the O(n^2) attack, because you've got it all figured out. |
|
|
|
How would BTC ETF approval next month affect XMRBTC and XMRUSD over the next 3 months & the next year?
The ETF will amplify BTC volatility, which means increasingly noisy price signals for Monero in the short/mid term. But that's not important. The key new fundamental here is the looming probability/inevitability of Monero ETFs. Silbert already made one for ETC. XMR is part of ICONOMI and should be part of Polychain Capital, etc.  I don't think this is going to help BTC's EFT at all. https://www.wsj.com/articles/lawyer-linked-to-martin-shkreli-arrested-on-fraud-charge-1450393836https://www.fbi.gov/contact-us/field-offices/newyork/news/press-releases/former-hedge-fund-manager-and-new-york-attorney-indicted-in-multi-million-dollar-fraud-schemeBTW OS2 was far superior to windows and lost do to IBM overpricing at launch as well.
It's more complicated than that. Win 3.0 was bundled with PCs. IBM wouldn't support non-IBM peripherals. And so on... ( https://en.wikipedia.org/wiki/OS/2#1990:_Breakup) The best version of OS2 is called "Windows NT" (which I ran for almost a decade and sorely miss). No Win Nt was not available for about 5 years after os2 and was primarily used for business (no directx and no backward comparability to win9x). That means no real mode driver support if you know what that is. The same thing that wiki is crying that OS2 lacked. 0s2 was a complete 32bit OS win 3.1 was 16bit layer ontop of a 8bit dos layer. Os2 did support non IBM peripherals I have no clue what your talking about there, they were just not already prewritten for the thousands of products. Any thing that was x86 compatible could have a driver written with little effort. BTW the 8088 was a 16bit chip with a 8bit address, 80286 had a 16bit address, 3086DX was 32 while the SX was 16, 486 SX/DX 32bit (SX had co-processor disabled). And thats off the top of my head so go wiki them and see if i'm right. Wasting your time reading wiki's to make an argument is foolish, I was there and had been professionally in the market for years at that time and was one of the first 4 IBM and MAchintsh certified techs in my state. I have a clue. From your wiki The collaboration between IBM and Microsoft unravelled in 1990, between the releases of Windows 3.0 and OS/2 1.3. During this time, Windows 3.0 became a tremendous success, selling millions of copies in its first year.[13] Much of its success was because Windows 3.0 (along with MS-DOS) was bundled with most new computers.[14] OS/2, on the other hand, was available only as an expensive stand-alone software package. In addition, OS/2 lacked device drivers for many common devices such as printers, particularly non-IBM hardware Lacking a driver does not equate to "wouldn't support". W3.1 was priced into every system when you bought it as per M$ licensing so you had to but Os2 separate that was a massive hurdle to adoption. Gates really screwed the world on this as well as many other tech stifling moves and WFW3.1 put the nail in the coffin as it was practically free and the Os2 equivalent was Approx $890 or so. BTW back then M$ wanted their OS pirated and intentionally left it that way so users could use it at home and business would adopt it because there work force was already trained with it. That was a very smart strategy on M$'s part. BTW I was setting up all M$ OS's since M$ began. What does the anti-Trump FUD about Shkreli's friend have to do with the BTC ETF, and/or the inevitability of XMR ETFs? You don't need to tell me about 8088 blah blah blah. I owned one. 10 years later, my work-study job was doing IT on campus. I supported OS2 and NT systems and so am aware of their relative strengths and weaknesses. I learn tons of stuff from Wikipedia, all the time. Putting down information because it appears on that site is a cheap shot typical of preening snobs who lack a better argument than attacking the source source aggregator. The person who stated "OS/2 lacked device drivers for many common devices such as printers, particularly non-IBM hardware" is Michal Necasek, who wrote that in a little something called "The History of OS/2." I'll take his research (and my own recollection) over your distorted view, which seems to take pains to avoid acknowledging that NT is OS2 3.0. Your assertion that lacking a driver does not equate to "wouldn't support" is hilarious. Talk about a distinction without a difference! |
|
|
|
The quadratic hashing issue is a non-problem.
Any miner that creates a block that takes inordinate time to validate will find himself bankrupted by other miners who continue hashing on the same parent to find a peer solved block. Such a peer solved block will validate well before the aberrant block, leading to the aberrant block being orphaned. 'Problem' solved. With the incentives as they exist today. Unchanged. I love the semantic hair split between "issue" and "problem" that you start off with. Great spin. Very Comical Ali of you. Spin? WTF? No spin here. I could have used the word 'aspect' instead of 'issue'. Or 'attribute'. Or some other. Wouldn't have made much difference. But how can you predict exact future scenarios like that? Are you psychic? Do you have visions or hear angels?
It is not a 'prediction', it is pointing out an essential element of the incentives already baked in to Bitcoin. I know you know that Bitcoin only works _at_all_ because the incentives are such that 'doing the right thing' is profitable. Right? Well, this is just one more instance of doing the right thing being profitable. I'll admit that I don't know if any significant miners currently implement this policy. Then again, aberrant blocks -- in the sense that they take a huge time to validate -- are rare. Indeed, I am aware of only one ever being created. But if such blocks ever became A Thing, rational miners will implement the mode I describe above. Because orphaning such aberrant blocks by others guarantees increased profitability. Sure, we might choke down several aberrant blocks in the meantime. But that won't bring the network down. It merely forestalls block completion time in the same manner that a variance outlier does. We've choked down at least one of these blocks before -- indeed one crafted intentionally to max out validation time -- to no ill effect. The rest of us simply don't know the specifics about the situation (which seems to be both empirical and theoretical!) you are describing.
Don't blame me for your being unable to game out this perfectly rational scenario. It is the only such scenario that makes sense in the case of such aberrant blocks. Doesn't the percent of total mining power the putative attack block creator determine the likelihood of his attack fork will be reclaimed by the defending chain?
Of course. A 51% attacker always gets to define the chain. What's your point? Doesn't variance also play a non-computable role in determining whether the attack block-based or defending chain-based side will win?
Of course. These things are all probabilistic. But the incentives are aligned to render this (::ahem::!) attribute a non-problem. If the quadratic hashing issue is a truly a "non-problem" then why did Gavin write an unforgivably kludgy, quick and dirty, non-futureproof workaround for it? Because Gavin is a pragmatist that endeavored to give the users what they wanted, as long as it did not cause any actual harm? I dunno - you'd need to ask him. Incidentally, I'm not aware of any 'unforgivably klugy' such work by him. To which pull req are you referring? Yes, I understand what makes Bitcoin work is its (magnificent, sublime) alignment of incentives. No, you can't simply assert ("waaaah, it's not a prediction") you have concrete knowledge of future events, because another way to describe your "perfectly rational scenario" is "anointed vision." Quadratic sigop validation is an ISSUE. You may try to furiously backpedal and retroactively substitute in less self-incriminating terms like "aspect" or "attribute" but the damage is done. Everything you pile on top of your inadvertent admission are excuses at best and lies at worst. Your problem is that you don't know what the fuck your talking about. You aren't even familiar with Gavin's sigop/sighash patch and the situation/history surrounding it, yet feel perfectly comfortable telling those of us who are you know more about the situation. That some nice Entitlement Syndrome you got there, Mr. Comical Ali. GTFO and come back when you are less ignorant of the critical nuances involved in this complex area of non-linearly interacting multidisciplinary subjects. Here, I'll even spoon feed you like a baby so you can't whine about how mean I'm being.  “Accurate sigop/sighash accounting and limits” is important, because without it, increasing the block size limit might be dangerous. You can watch my presentation at DevCore last November for the details, but basically Satoshi didn’t think hard enough about how transactions are signed, and as a result it is possible to create very large transactions that are very expensive to validate. This commit cleans up some of that “technical debt,” implementing a new ValidationCostTracker that keeps track of how much work is done to validate transactions and then uses it along with a new limit (MAX_BLOCK_SIGHASH) to make sure nobody can create a very expensive-to-validate block to try to gum up the network.
Do not relay or mine excessive sighash transactions
This is a belt-and-suspenders fix to make sure CreateNewBlock() or external mining software can never produce a block that violates the MAX_BLOCK_SIGHASH rule.
It does this by rejecting transactions that do too much signature hashing -- they are not added to the memory pool, and so will not be considered for inclusion in new blocks.
gavinandresen committed on Feb 2, 2016 See? We don't need to ask Gavin anything. He's already rubbished your entire position. You'd be aware of that if you read more and played Nostradamus less. |
|
|
|
How would BTC ETF approval next month affect XMRBTC and XMRUSD over the next 3 months & the next year?
The ETF will amplify BTC volatility, which means increasingly noisy price signals for Monero in the short/mid term. But that's not important. The key new fundamental here is the looming probability/inevitability of Monero ETFs. Silbert already made one for ETC. XMR is part of ICONOMI and should be part of Polychain Capital, etc. BTW OS2 was far superior to windows and lost do to IBM overpricing at launch as well.
It's more complicated than that. Win 3.0 was bundled with PCs. IBM wouldn't support non-IBM peripherals. And so on... ( https://en.wikipedia.org/wiki/OS/2#1990:_Breakup) The best version of OS2 is called "Windows NT" (which I ran for almost a decade and sorely miss). |
|
|
|
What a shitshow, there are several forks again.
1. John Conner creates Vcash shitshow 2. John Conner runs Vcash shitshow 3. John Conner abandons Vcash shitshow 4. Community asserts "we don't need John Conner to run this shitshow" 5. *Shitshow Intensifies* <----We are here now. |
|
|
|
12.1 info
Merchants ,Exchanges ,3rd Parties ,.... still need time ,so there is NO rush to switch Enforcement back on again - no date is set yet ; )
I'm sorry to hear that as we did commit to a specific date in the official announcement of 12.1 and Amanda repeated that date in her YouTube show as well. Now we have an extra delay in having our budget proposals up and running and have missing MN payments because payment enforcement is still off. Without running code which based on block height triggers the hard fork, THERE IS NO COMMITMENT. Do you understand the stark contrast between neutral, incorruptible code and squishy, unreliable, wavering humans? Don't you understand that what makes Bitcoin great is its magical ability to REMOVE the trusted-but-untrustworthy human element from value storage/transfer mechanisms? That's the entire point of having a blockchain. And you goofballs traded that Holy Grail for some dorky ginger beta's judgement calls. In 2017. WTF I can't even.  When your cult leader benevolent dictator for life tells you one thing (Deadline A) in order to get you to act in certain ways but then says something different (No Deadline A) that's called manipulation. Duffield never intended to enforce Deadline A. That was merely hocus-pocus optics. It was just for public consumption, so Evan The Instaminer could dump more of his 'accidentally' instamined hoard into the pump. You were manipulated into believing something that was not true. It's time to stop and reconsider the reliability of your Dash signals, because a very important one just proved to be less signal than noise. Even worse, the false information you were given about Deadline A was INTENTIONALLY tailored to manipulate your behavior. Have some dignity and stop letting Evan use you like a puppet. This isn't the first time Evan has manipulated the Dash community like marionettes by pulling their strings for PR purposes, only to renege on his previously indicated course of action when it proves to be unwise and/or inconvenient and/or beyond his abilities. It's happened repeatedly. Dash's Decentralized-In-Name-Only governance demonstrates a clear pattern and practice of Commit-->Delay-->Renege-->Repeat. It happened with Ring Signatures. It happened with Masternode blinding. It happened with 2MB blocks. I can't believe you guys don't see the pattern; it's like watching Lucy fool Charlie Brown with the football. Every. Single. Time. |
|
|
|
The quadratic hashing issue is a non-problem.
Any miner that creates a block that takes inordinate time to validate will find himself bankrupted by other miners who continue hashing on the same parent to find a peer solved block. Such a peer solved block will validate well before the aberrant block, leading to the aberrant block being orphaned. 'Problem' solved. With the incentives as they exist today. Unchanged. I love the semantic hair split between "issue" and "problem" that you start off with. Great spin. Very Comical Ali of you. But how can you predict exact future scenarios like that? Are you psychic? Do you have visions or hear angels? The rest of us simply don't know the specifics about the situation (which seems to be both empirical and theoretical!) you are describing. Doesn't the percent of total mining power the putative attack block creator determine the likelihood of his attack fork will be reclaimed by the defending chain? Doesn't variance also play a non-computable role in determining whether the attack block-based or defending chain-based side will win? If the quadratic hashing issue is a truly a "non-problem" then why did Gavin write an unforgivably kludgy, quick and dirty, non-futureproof workaround for it? |
|
|
|
Agree with TC here.
Why not save 2/3 of your extra money in silver and Bitcoin, while gambling the other 1/3 in Monero? This provides a silver liquidity cushion for emergencies, so you don't have to sell any crypto (which is more of a PITA). |
|
|
|
Dash paid $50,000 to be listed on BitMex  The "major exchange" was rumored and hyped to be Coinbase or Kraken, so this is a major disappointment. But at least now we know BitMex should be avoided at all costs because they take bribes to list instamined scamcoins. Dash can't buy its way onto Coinbase and Kraken for any amount of money because they give a shit about its Instamine, Masternode money laundry HYIP, centralization, bad crpto, etc. |
|
|
|
Any community members running their MNs on IP6? What are your experiences? I'm looking into moving my MNs to another datacentre (and beefing them up a bit) and figured I could save a few bucks opting for IP6 if it's working for people. I also want to reduce the amount of times my MNs crash as it seems to be happening every other week now, I can only put this down to performance issues on the current platform... Not so expensive a couple of years ago but at $20 a missed payment lost earnings are starting to rack up!  Walter Not sure about IPv6, I didn't even know it worked in the current stable release. Nope, not anymore. IPv6 is a thing of the past. According to the Dash forum, Dash's future is now married to the fate of IPv4.  WTF camosoul? IPv6 works just fine for Bitcoin, Apple, and even the US Govt. Dash is the only supposedly modern cutting-edge project that can't keep up with 1998's hot new networking technology. |
|
|
|
Is Lightning Bitcoin?
Yes. You pick a peer and after some setup, create a bitcoin transaction to fund the lightning channel; it’ll then take another transaction to close it and release your funds. You and your peer always hold a bitcoin transaction to get your funds whenever you want: just broadcast to the blockchain like normal. In other words, you and your peer create a shared account, and then use Lightning to securely negotiate who gets how much from that shared account, without waiting for the bitcoin blockchain. Read pages 49-51 of the LN whitepaper and all of the ways your LN funds can be stolen , then lie some more. So @rusty_lightning is a liar? And he's lying through his teeth? And that's pathetic? Could be. Or maybe you're just being hysterical because you can't stop Lightning. I'm sorry you don't understand how trustless bidirectional payment channels inherit Bitcoin's security, but Honey Badger doesn't care one bit. |
|
|
|
Lightning tx are trustless. They are not some idiotic trusted 3rd party solution like Dash's Masternodes.
On-chain scaling is the most secure thing one could do (here you have the biggest hardware + energy investors = miners behind) and we need this first or at least parallel to all the other triggy scalings on top. LN *is* Bitcoin, so it uses the same amount of energy for security. Is Lightning Bitcoin?
Yes. You pick a peer and after some setup, create a bitcoin transaction to fund the lightning channel; it’ll then take another transaction to close it and release your funds. You and your peer always hold a bitcoin transaction to get your funds whenever you want: just broadcast to the blockchain like normal. In other words, you and your peer create a shared account, and then use Lightning to securely negotiate who gets how much from that shared account, without waiting for the bitcoin blockchain. See? Lightning is 100% Bitcoin. It's just a clever way to efficiently arrange blockchain writes, yielding massive gains in effective TPS. Only correct thing in this rage-post is: You did not dare arguing against: 'On-chain scaling is the most secure thing one could do (here you have the biggest hardware + energy investors = miners behind) and we need this first or at least parallel to all the other triggy scalings on top. ' I'll let you play with LN in LitecoiN - so you have time for self-education. Lightning is on-chain scaling. Rusty explains why Lightning is 100% Bitcoin in clear, simple words. If you can't follow the technical discussion, too bad for you. Your failure to understand how trustless bidirectional payment channels inherit Bitcoin's security isn't anyone's problem but your own. |
|
|
|
Lightning tx are trustless. They are not some idiotic trusted 3rd party solution like Dash's Masternodes.
Lol If you really believe this than every other alt is trustless in nearly same manner. -> Go and use them. Think: 1. How much energy goes into making bitcoin that trustless it is? 2. How much do you need for LN ? Pls go and read physics or Shannon about entropy and order -> security. On-chain scaling is the most secure thing one could do (here you have the biggest hardware + energy investors = miners behind) and we need this first or at least parallel to all the other triggy scalings on top. Sorry, cupcake. Not impressed. Some of us went to school for this stuff...  I'll see your Shannon and raise you Kolmogorov. Don't make me break out Wiener and Von Neumann on you. LN *is* Bitcoin, so it uses the same amount of energy for security. Your failure to understand how Lightning inherits Bitcoin's security isn't anyone's problem but your own. Educate yourself, then come back when you're ready to play with the big kids. Here, I'll even spoon feed you like a baby to accelerate the bootstrapping process.
Is Lightning Bitcoin?
Yes. You pick a peer and after some setup, create a bitcoin transaction to fund the lightning channel; it’ll then take another transaction to close it and release your funds. You and your peer always hold a bitcoin transaction to get your funds whenever you want: just broadcast to the blockchain like normal. In other words, you and your peer create a shared account, and then use Lightning to securely negotiate who gets how much from that shared account, without waiting for the bitcoin blockchain.
See? Lightning is 100% Bitcoin. It's just a clever way to efficiently arrange blockchain writes, yielding massive gains in effective TPS. Lightning isn't Layer 2, if that's what you're afraid of. Think of it as layer 1.5 and maybe that might help you understand using spatial intuition. |
|
|
|
Especially liked the following comments.
The other theoretical solution is the lightening network to carry out the off chain transactions
Two years ago it was an idea and by the looks of it, it still is (despite recent alpha announcements).
The proposal is to have transactions in off chain transactions that will somehow be trusted.
Again we go back to off chains being just like the old banking infrastructure today.
These off chain payment channels still rely on broadcasting back to the Blockchain.
If we already have congested blocks then how is Lightening even going to work?
The transaction fees and intermittent nature will still be present as these channels will only scale so far and we would still need to figure out how to scale on chain.
Lightening just seems like a complex theoretical model when in fact off chain should be simple.
If we go back to my Coinbase example it can just be on a central database.
Various payment providers keep track of their own ledgers, in fact this is what banks do today the technology is already there.
Users could choose to have a Bitcoin account with say a mainstream bank like Barclays.
Most of their transactions occur off chain on ledgers just like today.
Then the user may demand once their balance reaches a certain point to automatically post a set amount to a private bitcoin address they own.
They may choose just to use a bank to handle their bitcoin.
So not only is all the above both in my opinion unnecessary and complex but how the heck am I going to explain Bitcoin to others?
It was hard enough when there was just the Blockchain with terms such as distributed consensus and miners and digital wallets (and I had to pray they didn’t ask what wallets were and if there were coins).
Now I’ve got to explain these exotic off chain solutions on top of all that.
To me its almost like people are working on ways to make Bitcoin more complicated and in the long run make it more unpopular. Honey Badger really doesn't give a shit if some moon kidz want to characterize his activities as "stagnation." Who made you his life coach? Lightning tx are trustless. They are not some idiotic trusted 3rd party solution like Dash's Masternodes. A Lightning type payment channel is simply a write cache for the blockchain. Do you know how much the write cache improves a hard drive's performance? Try turning yours off and find out. Why don't you moan about the presence of write caches on hard drives, and spew FUD about how output operations to the write cache aren't real "on disk" transactions! |
|
|
|
I spent time and effort, even at night, to stay on pace. Changing the enforcement would have been on its own a sufficient reason to have my nodes update after a payment, and not on monday (mostly) cause i was sure that if a payment was less than 3 days distant it was possible that i was nonetheless missing it, with a bit of bad luck.  So this costed me money, instead of being prized cause i was doing my best for Dash.  Also, i was confident that if the official communication said "we are enforcing on Sunday" it was... official.  I also totally agree that stability and all it's important; next time i'd re-evaluate the way communications are done, but there is a major downside: The "ghost" of enforcement was, I think, one of the reason for the very fast upgrade. Next time, people will just say "meh" and wait till it's mandatory, making the whole transaction way slower. I'm with you on this one. I sacrificed some important time of mine to get this upgrade completed before what I thought was the official enforcement date. Maybe we should use a budget proposal to let the masternode owners decide when to make the enforcement. I would suspect that the majority would vote to do it now since we've already invested our precious time doing the upgrade. Bitcoin, Litecoin, and Monero hard forks are triggered by block height, not two random brogrammer dudes acting as Network Dictators by forking at an arbitrary time of their choosing. That's because fork-trigger-by-block-height is the known Best Practice for that kind of situation. Dash eschews that known best practice. When I pointed out the vast difference and its significance in terms of centralization, the point was ignored. Suddenly these unelected Network Dictators arbitrarily changed their minds about the (already arbitrary) fork timing and everyone is crying about it. Now do you see why clear, objective computer code is better at running a "decentralized" networks than some unpredictable, flighty, unaccountable so-called engineeres? If you want to be involved in a coin that is run by code and not by people, Dash isn't really a good fit. It's more of personality cult centered around one person, and that Dictator For Life prioritizes marketing over technology. Evan's 'Marketing Over Technology' tax-and-spend philosophy why Dash has a shiny new high-rent office, but can't -implement advanced new BTC features like RBF/CPFP, segwit and Lightning -restore IPv6 functionality to 12.1 (despite Bitcoin supporting it since 2009) -blind Masternodes (so we don't know how Masternodes voted and whose coins they are laundering) -get Mycelium integration completed (blown deadline was October 2016) -get Lamassu ATM integration completed (blown deadline was June 2016) -hard fork the network using software based block height triggers (instead of confusing/conflicting/manipulative judgement calls) I agree with your proposal to let the masternode owners decide when to make the enforcement. That would be actual distributed governance by blockchain, in contrast to the current fake/shitty Decentralization Theater (aka centralized governance by two random brogrammer dudes). |
|
|
|
|
Show Posts
