is this only for linux or windows as well? If you follow the link in the reddit announce you can get to binaries available for win/lin/mac. |
|
|
|
...
I guess there is often a ton of code to merge but I believe Segwit was by far the most complicated change which has had basically zero impact on the scaling problems that are now becoming very serious with the fees going parabolic and effectively locking up to 50% of coin inputs. BTC is bleeding while Greg is drinking "champaign", I don't think I wish to follow this genius any further down the road he is building... It looks like people are taking in interest based on market demand... You've lost me now... these projects have no shortage of questionable people surrounding them, I think it's best to try to ignore all of that and focus on implementation. You've given a line count now and say it's complicated. Can you point to where in that 6k line count it's complicated? Where it's not addressed in unit-testing? I need technical specifics to understand. Segwit is actually a very small part of this v0.14 update, a tightening of consensus rules / not a hard fork, and it's an optional type of transaction to boot. I agree that we don't need to worry about personalities. 6000 lines of dense code that changes consensus on a distributed network is complicated and risky by nature. I have to correct one word here, and that's "changes". If it were to change consensus it would be a hard fork. This is a "tightening" of consensus. Older nodes still work fine, you don't have to use segwit transactions if you don't want to. I don't think we need to go line-by-line to agree on that?
Actually, yes, that's exactly what I'm asking for. Where exactly in the core software is the concern? Line number, function, etc. I'm looking for specifics and not page after page of conjecture. Unit testing is good in Bitcoin Core but what's the point of it for a useless change?
I don't see it as a useless change. I am intrigued by new capabilities like cross-chain swaps, rootstock-like applications, lightning (almost-instant payments) and MAST (especially the privacy that MAST could deliver). I think many folks probably didn't see the point in BIP16 at the time, but now we have multisig and it seems like second nature.
On top of this, Segwit requires an estimated of 100k lines of code changes in all of the utility code in the ecosystem (building and revalidating transactions in the new format, wallets, etc.).
Do you have a source for this? Why can't they just continue to use traditional transactions if they don't want to participate? Regardless, I can only focus on the core client right now so let's keep the conversation focused there I suppose. I really don't see anything in that link that specifically points to a flaw in the core client beyond the client not being complete yet. Good code takes time and peer review. From what I've observed I'm confident in the upstream process (which is not just Blockstream by the way). Core is still beta software after all. I'd hate to see someone suggest that because the Myriadcoin reference implementation is still evolving it can't be useful or interesting.
I'm sorry to see XMY/MYR get embroiled in this.
I'm glad we can talk this through like adults. This must be the first Segwit discussion I've had with anyone that didn't get heated and personal. It's easier to just talk about the specific tech and ignore the generalities. I think that helps for the most part. We might not always agree, but at least we can target the disagreements.
In my opnion Segwit doesn't work, and it hasn't solved the problems it was touted to solve, most notably SCALING (this is supported by stats on the BTC main chain, which is almost unusable right now due to limited blocksize and insane fees). Since scaling isn't an issue with Myriad (yet), Segwit was especially not needed. Let's face it - some coins jumped to adopt Segwit to get on the hype train. Litecoin and a few others pumped in value when they added Segwit, so others followed suit.
I don't think Segwit itself would solve scaling the transaction throughput, that should be the domain of layer2. Just raising block-size wouldn't address true scaling either, and I certainly don't think "all nodes in data-centers" is a good plan. I'm sure I'm not the only netizen who desires the decentralized plan to run a node on a residential DSL line. If blocks are 20MB I think we lose a lot of decentralization. Segwit enables layer2 without mandating it, thus I support it.
Segwit does make transactions smaller in some use cases, but it's so complicated that even the Bitcoin Core wallet doesn't support making transactions using Segwit. My understanding is that Segwit makes Lightning and other Layer2 solutions easier to implement - since those don't work yet I am not holding my breath. I also have serious issues with the concepts behind the L2 solutions and believe that they won't ever see mass adoption, even if they get the technical issues sorted out.
I just mentioned multisig... Since core doesn't produce multisig transactions in the gui should we abandon it? Core does allow you to create segwit transactions manually just like multisig. The first mainnet LN transactions have already started, a fledgling LN network is active on testnet. I see progress here. It of coarse takes time and carefully reviewed work. It's difficult to be patient but when I compare the work in core vs the alternatives I don't find a better/safer development process. I'm open to being enlightened with specific examples, I just don't see it.
Again these are not line-by-line code issues, they're more like the "elephant in the living room". Code does stuff or it doesn't. In this case, the code doesn't do do anything tangible and is extremely complicated. My argument would be that therefore the code is not useful so should not be merged. I'm happy to be proven wrong by some future cool tech that uses Segwit features, but I guess we'll cross that bridge when we get to it?
I get that Segwit was complicated so that it could be a soft fork. But again, if no one is adopting it then what good is it? Even the Core people have stopped talking about it other than to complain that "nobody is adopting it".
Hindsight is always 20/20. At this point I can say that Segwit was a mistake. You probably know that devs rarely admit mistakes, and they very rarely roll back changes in software. So here we are with an albatross around our necks.
We'll just have to disagree I guess... I think it's entirely way too early to judge segwit. I'm excited for the future and the possibilities. LOL at MyriadCash. Don't worry one MYR/XMY can rule them all!
|
|
|
|
...
I guess there is often a ton of code to merge but I believe Segwit was by far the most complicated change which has had basically zero impact on the scaling problems that are now becoming very serious with the fees going parabolic and effectively locking up to 50% of coin inputs. BTC is bleeding while Greg is drinking "champaign", I don't think I wish to follow this genius any further down the road he is building... It looks like people are taking in interest based on market demand... You've lost me now... these projects have no shortage of questionable people surrounding them, I think it's best to try to ignore all of that and focus on implementation. You've given a line count now and say it's complicated. Can you point to where in that 6k line count it's complicated? Where it's not addressed in unit-testing? I need technical specifics to understand. Segwit is actually a very small part of this v0.14 update, a tightening of consensus rules / not a hard fork, and it's an optional type of transaction to boot. I agree that we don't need to worry about personalities. 6000 lines of dense code that changes consensus on a distributed network is complicated and risky by nature. I have to correct one word here, and that's "changes". If it were to change consensus it would be a hard fork. This is a "tightening" of consensus. Older nodes still work fine, you don't have to use segwit transactions if you don't want to. I don't think we need to go line-by-line to agree on that?
Actually, yes, that's exactly what I'm asking for. Where exactly in the core software is the concern? Line number, function, etc. I'm looking for specifics and not page after page of conjecture. Unit testing is good in Bitcoin Core but what's the point of it for a useless change?
I don't see it as a useless change. I am intrigued by new capabilities like cross-chain swaps, rootstock-like applications, lightning (almost-instant payments) and MAST (especially the privacy that MAST could deliver). I think many folks probably didn't see the point in BIP16 at the time, but now we have multisig and it seems like second nature.
On top of this, Segwit requires an estimated of 100k lines of code changes in all of the utility code in the ecosystem (building and revalidating transactions in the new format, wallets, etc.).
Do you have a source for this? Why can't they just continue to use traditional transactions if they don't want to participate? Regardless, I can only focus on the core client right now so let's keep the conversation focused there I suppose. I really don't see anything in that link that specifically points to a flaw in the core client beyond the client not being complete yet. Good code takes time and peer review. From what I've observed I'm confident in the upstream process (which is not just Blockstream by the way). Core is still beta software after all. I'd hate to see someone suggest that because the Myriadcoin reference implementation is still evolving it can't be useful or interesting.
I'm sorry to see XMY/MYR get embroiled in this.
|
|
|
|
I am long-time MYR(XMY) hodler and I just want to say that I am disappointed that the devs fell for the Segwit propaganda. It's unneeded code and likely to product plenty of bugs...
Anyway thanks for listening
What exactly is your issue with segwit? Be technical and specific. Thanks for your reply. My issues with Segwit are actually not that technical, more practical. Most will agree that Segwit deployment on BTC was rammed down people's throats, and it hasn't done anything for scaling - BTC blocks are currently averaging 1.04MB. Only 10% of vendors are using the technology and it is looking more and more like a failure. Even the BTC Kore wallet doesn't support Segwit transactions from the GUI last I checked. Segwit does adds a huge technical debt (6k lines of code), with no tangible improvement other than fixing malleability, which has never really been an issue (Gox used it as an excuse for their "hack"). I don't wish to ignite the scaling war here - clearly XMY has plenty of blockspace. However I do feel like the devs here might've fallen for the Blockstream/pro-Segwit propaganda. Regardless, I'm still here and I still love the multi-algo coin design. Personally I believe that multi-algo coin design is the only way to have a truly ASIC-resistant coin, and this ensures that mining will not become centralized (which is a major problem in the entire crypto space). So big thanks to the community and especially the devs! Well, basically every time we jump in version we end up with a lot more than 6k lines of code to dig through from upstream... That's always going to be an issue for a downstream project. Every time I try to understand technically what the issue with segwit is, I don't get a lot of technical arguments that I can understand as an actual issue, let alone one that I can agree with. At least yours has a line count  Beyond the politics and the concern trolling it's hard to argue with the technical expertise from upstream IMHO. Thanks for your reply! I guess there is often a ton of code to merge but I believe Segwit was by far the most complicated change which has had basically zero impact on the scaling problems that are now becoming very serious with the fees going parabolic and effectively locking up to 50% of coin inputs. BTC is bleeding while Greg is drinking "champaign", I don't think I wish to follow this genius any further down the road he is building... It looks like people are taking in interest based on market demand... You've lost me now... these projects have no shortage of questionable people surrounding them, I think it's best to try to ignore all of that and focus on implementation. You've given a line count now and say it's complicated. Can you point to where in that 6k line count it's complicated? Where it's not addressed in unit-testing? I need technical specifics to understand. Segwit is actually a very small part of this v0.14 update, a tightening of consensus rules / not a hard fork, and it's an optional type of transaction to boot. |
|
|
|
I am long-time MYR(XMY) hodler and I just want to say that I am disappointed that the devs fell for the Segwit propaganda. It's unneeded code and likely to product plenty of bugs...
Anyway thanks for listening
What exactly is your issue with segwit? Be technical and specific. Thanks for your reply. My issues with Segwit are actually not that technical, more practical. Most will agree that Segwit deployment on BTC was rammed down people's throats, and it hasn't done anything for scaling - BTC blocks are currently averaging 1.04MB. Only 10% of vendors are using the technology and it is looking more and more like a failure. Even the BTC Kore wallet doesn't support Segwit transactions from the GUI last I checked. Segwit does adds a huge technical debt (6k lines of code), with no tangible improvement other than fixing malleability, which has never really been an issue (Gox used it as an excuse for their "hack"). I don't wish to ignite the scaling war here - clearly XMY has plenty of blockspace. However I do feel like the devs here might've fallen for the Blockstream/pro-Segwit propaganda. Regardless, I'm still here and I still love the multi-algo coin design. Personally I believe that multi-algo coin design is the only way to have a truly ASIC-resistant coin, and this ensures that mining will not become centralized (which is a major problem in the entire crypto space). So big thanks to the community and especially the devs! Well, basically every time we jump in version we end up with a lot more than 6k lines of code to dig through from upstream... That's always going to be an issue for a downstream project. Every time I try to understand technically what the issue with segwit is, I don't get a lot of technical arguments that I can understand as an actual issue, let alone one that I can agree with. At least yours has a line count Beyond the politics and the concern trolling it's hard to argue with the technical expertise from upstream IMHO. Thanks for your reply! |
|
|
|
I am long-time MYR(XMY) hodler and I just want to say that I am disappointed that the devs fell for the Segwit propaganda. It's unneeded code and likely to product plenty of bugs...
Anyway thanks for listening
What exactly is your issue with segwit? Be technical and specific. |
|
|
|
Hello ! I have a problem about the wallet JSwallet !!! I went to check the balance plus the site disappeared? Could someone tell me what happened !!
If you have the private key backed up you can import it to a supported wallet. If you have the paper wallet .html file, you should be able to recover the private key via the "Brain Wallet" tab. The brain wallet string would be the string of characters after the "#" symbol in the jswallet link. |
|
|
|
Hey guys wanted to ask, I mine on pokemongogo pool. Can I mine directly to JS mobile wallet? To use that address in my mining file?
thanks
You CAN, however if you're expecting a significant number of mining inputs you can expect jswallet to fail to sign an outgoing transaction eventually. It's not well suited for large numbers of utxos. No worries though, it gives you your private key which you could import into another wallet better suited for larger (as in number of bytes) transactions. |
|
|
|
Again, blockchain sync problem :
Current block
- on bittrex is 2225505
- on insight-myr.cryptap.us is 2225645
- on miningpoolhub 2225645
- on suprnova 2225505
- on my wallets 2225505
same problem for me...... Same here. Releasing new wallets without testing them thoroughly beforehand is dangerous, harms the network & damages the coins reputation. I hope the devs bear this in mind before releasing the next version. I've disabled my wallet & mining for the time being as a security measure. Hi guys, Any updates on the wallet situation? What wallet version can be used safely for mining? Thanks. Cautiously optimistic that we've solved the issue on the "master" branch: https://github.com/myriadteam/myriadcoin/issues/68The stable version still remains on v0.11.3.2, however if any mining pools are willing to test v0.14.2.3 via the "master" branch I think input would be quite valuable. If we can break >50% legbit consensus on a single algo I think it would be promising. We've approached ~40% on skein recently and no issues have been reported. |
|
|
|
We have noticed some differences in chainwork between the versions. It might not be noticeable in testnet due to the low total chainwork. https://github.com/myriadteam/myriadcoin/issues/68If you are a pool operator and are willing to help test these changes please pull from the "master" branch. Your feedback would be most valuable. A reindex is recommend, but initial testing showed chainwork to be calculated without a reindex. https://github.com/myriadteam/myriadcoin |
|
|
|
|
Show Posts
