Bitcoin Testnet: A Beginner’s Guide to Using the Bitcoin

Weekly Update: 1 Million ParJar Tips,, SelfKey Mobile Wallet, Sentivate Social... – 6 Mar - 12 Mar'20

Weekly Update: 1 Million ParJar Tips,, SelfKey Mobile Wallet, Sentivate Social... – 6 Mar - 12 Mar'20
As Coronavirus (COVID-19) wreaks havoc across the world, we hope that Parachuters are safe, at home and healthy. This has been a difficult few months for everyone. But we will get over it. So let’s spread some good vibes with an update filled with awesome news from the Parachuteverse. Here’s your week at Parachute + partners (6 Mar - 12 Mar'20):

Starting off with a biggie. This week we crossed 1 million ParJar tips with a grand party in the Tiproom that left heads spinning and massive hangover. Haha! Click here for a sneak peek into the madness. Those who missed the party, woke up to 30k+ messages. And that happened within a couple of hours only. Wild! If that wasn’t enough, the TTR crew followed it up with a tiproom tipbattle with 6 teams (10 members each) fighting it out. Click here for the team lineups and rules. What ensued was a whirlwind comprising 80k+ tips. Double wild! LordHades shared the latest #FPL update according to which Novelcloud has now crossed LH to take second position. Alexis continues to be on top. If you’re already on BAGS token’s Dirty Bags platform, don’t forget to check out the Parachute posts over there. If you’re not on it yet, there’s $BAGS prizes for Parachuters who sign up. Bose’s random trivia in TTR got folks scratching their heads for answers.
A Gian food pic after ages. Though not cooked by him. Peruvian chicken. Yum!
Alejandro hosted a free-for-all CoD flash game in the Parachute War Zone followed by a battle royale. Congratulations to Clinton for being awarded the Bronze Seal of Transparency for his charity. GamrB0y’s trivia in TTR this week was based on science. Victor hosted a TTR quiz themed on MetaHumans. Charlotte’s math trivia was uber fun as always. Jobchain crew sponsored 750k $JOB as prizes for a round Robot Rise in the ParJar Gaming channel. Cap held a flash Parena this week. If you haven’t been keeping a tab on Parachute, you just missed on scoring some sweet $PAR. Like Achilleas almost did with his top prize. He won the finale but wasn't around to claim his 1st prize. So Bose snagged the winner’s spoils. But Cap being Cap made sure he didn’t miss out either. For Two-for-Tuesday this week, Gian got Parachuters to post music videos "featuring bands or songs that have a food or drink in their name". Like always, Sebastian was kind enough to compile a playlist with everyone’s posts. A flurry of beta testing activities related to Transak (fiat on/off ramp for ParJar) and swapping flung into action this week. For this week's #wholesomewed, Jason asked Parachuters "to draw a fierce non-existant creature that you would like as your champion in a parena".
What an amazing view Alexis!
In this week’s educational posts from aXpire, COO Matthew Markham wrote about the state of the legal tech market, the E-Billing industry, why legal billing software matters and artificial intelligence in law firm software. For the latest update video, click here. Still not sure what aXpire is all about? Check out their token overview and business presentation. The weekly 20k $AXPR token burn went ahead as per schedule. Insights from 2gether’s consumer report were published in a Cointelegraph article exploring women’s usage behaviour in crypto. For the full report on female users, click here. Euro deposits on the platform were briefly paused and subsequently restored because of a third party dependency. Upgrades were made to the $BTC transfer mechanism as well. But a high traffic issue led to a temporary stoppage of the crypto purchase feature. Birdchain released its 2 year roadmap. Few weeks back, we shared news of $BIRD being listed on Probit. CEO Joao Martins talked more about it in his video podcast this week. Probit also started a stake and earn event for $BIRD holders. Ethos’ parent company Voyager is now a sponsor of Scott Melker’s (The Wolf of All Streets) new podcast. For the latest Switch update, click here. Fantom announced the pre-launch of which will be an end-to-end DeFi suite of products. The project has been killing it on its socials. Want to see proof? Check out the social metric graph mapped by LunarCRUSH. Michael made a weekly update video to catch up on all the latest news. Click here to read the latest technical update. Fantom also announced its involvement in Fusion Protocol’s decentralised custodian solution DCRM Alliance.
Interesting insights from 2gether’s female crypto users report
The new XIO website layout and a new set of article were released this week. Zachary did a deep dive into the new stuff with a 40 minute video. For this week’s #XIOSocial discussions, Citizens talked about underrated qualities of successful entrepreneurs and about progressive decentralisation. DigiByte joined Uptrennd this week with their own community on the platform. Uptrennd crew marked the occasion with a cool giveaway. Looking to join the team? Don’t forget to apply for the open positions. How has the platform been fairing in the last 3 months vis-à-vis other platforms? Check out the numbers. Plus, congrats on crossing 70k members. YouTuber Chico Crypto joined Uptrennd this week. District0x’s weekly update covers news such as the new District Designer, latest Dapp Digest etc. Meme Factory launched a new contest. Hydro integrated Plaid’s account verification and aggregation services to its platform this week. This was followed by additional integrations with KYC provider Onfido and financial data provider MX. Silent Notary crew has created a new fund for pursuing IDL’s listing opportunities. Looking for human connections during the Coronavirus lockdown? OST’s Pepo app now has a dedicated community channel for this. SelfKey’s Mobile Wallet was launched this week. CoinLoan joined SelfKey’s crypto lending marketplace. Moreover, crypto exchange Bitkub was added to the exchange marketplace. Plus, the team compiled a list of data breaches at Facebook.
The new Crowdstaking graphic explains how it is different from crowdfunding
Realtime market widgets and downloads page were added to the Sentivate social site this week along with a ton of other upgrades. The beta test of the platform has also been a success on Windows and Mac. The browser build is ongoing with a naming contest to begin soon. If you have been keeping your eyes open, BAGS crew have been hosting some fun quizzes in the Dirty Bags channel for $BAGS prizes. Make sure to have a look when you have a moment. Last year, around this time, Pynk won the startup pitch competition at Wolves Summit. This week, CEO Seth Ward and COO Rupert Barksfield shared 8 tips for aspirants. The community also discussed about Facebook’s Libra Alliance this week. CyberFM started a special playlist on the Spotlight Channel to celebrate Women’s History Month. Harmony showcased its transaction speed and fees compared to Ethereum through a video demo. Plus, a fast finality demonstration. Click here to read last week’s #pow thread. If you would rather watch the video update, click here. Founder Stephen Tse shared some more updates over live videos (1, 2, 3, 4). And kudos for being the most active project on GitHub last week. The crew sat down with Vite Labs for a community AMA. The roadmap towards launching Open Staking was published. It is currently in the second phase out of four phases. Testers and hackers were welcomed to participate in Stake Heist - try and break the open staking design on the Pangaea testnet for 10M $ONE tokens in prizes.
The Sentivate social site community dashboard looks fresh!
Intellishare founder Raymond Xiong will sit down for a community AMA next week. Folks who sent in questions could win 50 $INE tokens as well. GET Protocol’s GUTS Tickets featured in a list of recommended portals for safe ticket purchases by the Netherlands’ Police. As part of its ticketing transparency standards documentation series, developer Kasper Keunen wrote about nodes this week. The $COTI conversion bridge has been reopened with some limits to ensure fair chance for everyone looking to convert from mainnet to ERC20/BEP2 tokens. For the latest newsletter, click here. The new COTI explorer was released as well. Apart from simple wallet-to-wallet transactions, it also tracks merchant txns, bridge txns etc. The dev team also released a detailed article explaining its multi-currency (MultiDAG) framework. For the token deployment demo, click here.

And with that, it’s a close for this week in Parachute! See you again soon. Bye!
submitted by abhijoysarkar to ParachuteToken [link] [comments]

Groestlcoin 6th Anniversary Release


Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.

Other Linux


Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here


ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.





ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.


Live Version (Not Recommended)



ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).





ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).




Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.


Remastered Improvements



ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.



Linux :
 pip3 install -r requirements.txt python3 bip39\ 


ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.



Linux / OSX (Instructions)


UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via


submitted by Yokomoko_Saleen to groestlcoin [link] [comments]


With two cryptocurrency integrations under my belt I've set out with a solid plan for Monero.
Instead of jumping in and figuring it out as I go along I want to make sure that I have the solutions I'll need, well defined and scoped out. It's a good thing I'm going this path, too.
Turns out that there isn't really much in the way of JavaScript code for Monero out there. Probably the two best (and possibly only), solutions at the moment are monero-javascript and MyMonero.
Although there's no official Monero JavaScript library, the monero-javascript project is probably the closest to the original C++ client. This derived code comes in the form of WebAssembly, a low-level language that runs a lot closer to the metal than JavaScript. This means that WebAssembly is generally faster when doing things like calculations, but with some trade-offs like ease of use. JavaScript is a lot easier to code and understand, but it tends to run slower. In modern browsers, both run side by side so developers can decide which parts need to work fast, and which parts need to be easier to change and maintain.
The MyMonero project is actually a set of supporting libraries for a Monero wallet. It seems to have a lot more "real world" mileage but has a smaller dev team and hasn't been updated for many months, unlike monero-javascript which was updated as recently as today. MyMonero also uses WebAssembly for some of the core wallet functionality but the "bindings", or how this functionality is exposed to JavaScript, are different.
Between the two solutions, I've had more luck in getting support for monero-javascript. Neither project is well documented so having someone to run questions by is, at least at this point, a winning feature.
This will be my first time working with WebAssembly so factoring in some learning time is prudent. I'll only be learning to use existing code rather than learning how to write it but still, it's a new thing for me.
As I mentioned, support for Monero via JavaScript is surprisingly rare, so I may end up contributing some original code back to the project(s) I'll be using. I haven't yet decided which of them will find its way into CypherPoker.JS because there are still some open questions about how certain things are done and if they're even possible. However, right now monero-javascript is looking like the best choice.
Once I'm satisfied that all the building blocks are viable, I'll add the cryptocurrency handler and integrate it all the way through to the front end. As with BTC and BCH, a Monero testnet option will be available along with a faucet so that you can test it out without using any actual XMR. A full client option that uses the downloadable monerod client, the equivalent of a full Bitcoin node, will be available alongside the "light" option which will use external APIs. After that I'll upgrade the live demo (and server), update the wallet generator, post v0.5.2 code documentation, create a new release, and write a wrap-up post.
I want to stress again that this is all contingent on whether or not the JavaScript libraries actually do what I need them to do, and if there exists at least one public API that can be used in place of the daemon (monerod). But based on the help I've received from the Monero community so far I'm feeling optimistic.
Probably the most interesting thing about the Monero integration is that it represents the final, Rumsfeldian, "known unknown" of the CypherPoker.JS project. It's the last thing I'm embarking on with essentially zero prior knowledge; I know that I know nothing.
The rest of the project, the other cryptocurrencies, smart contracts, peer-to-peer communications - those are all things I'd at least had an introduction to if not outright practical knowledge of. When it comes time to add Ethereum support I'll be able to confidently say that it's nothing new. Incorporating Tor anonymization ... been there, done that.
When it comes to Monero, though, I'm a wide-eyed ignoramus. Never owned any XMR, never ran a Monero wallet, never tried out a Monero block explorer; seems I'm even getting some of the technical terminology wrong. Basically, it's the last part of the project's core vision that comes with a steep learning curve and a not-insignificant chance of failure. I mean, I don't think I'm gonna fail but I can't point to any definitive reason why I should think that.
There's no pragmatic reason to believe that March and (the) Monero (integration) will be contemporaneous but then again, why not?
submitted by monican_agent to cypherpoker [link] [comments]

12-22 13:34 - ' Etherscan Export CSV Data - 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-4699...' by /u/mahdiamolimoghadam removed from /r/Bitcoin within 128-138min

 Etherscan Export CSV Data - 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-46998878-6', { 'anonymize_ip': true }); .ether-search-heading { pointer-events: none !important; } .ether-search-heading .ui-menu-item-wrapper, .[link]^^1 .ui-menu-item-wrapper { cursor: default !important; border-color: transparent !important; 0 } .ui-menu-item .ether-search, .[link]^^2 .ether-search { background-color: transparent !important; border-color: #e7eaf3 !important; } .[link]^^2 .ether-search { background-color: #f8fafd !important; } .ui-menu-item .ether-search, .ui-menu-item .ether-search { background-color: transparent !important; border-color: transparent !important; } body.dark-mode .[link]^^2 .ether-search { background-color: #012137 !important; color: #a2b9c8 !important; border-color: #013558 !important; } //  Eth: $148.33 (-0.12%) Home Blockchain 
View Txns
View Pending Txns
View Contract Internal Txns
 View Blocks Forked Blocks (Reorgs) 
View Uncles
Top Accounts
Verified Contracts
ERC-20 Top Tokens
View ERC-20 Transfers
ERC-721 Top Tokens
View ERC-721 Transfers
Ethereum Directory
Charts & Stats
Top Statistics
 More Developers 
Verify Contract
Byte to Opcode
Broadcast TXN
Vyper Online Compiler
 Swarm & ENS 
SWARM Search
SWARM Upload
ENS Events
ENS Lookup
 Service Tracker 
Dapp Tracker New
DEX Tracker
DEX OrderBooks
Gas Tracker
Node Tracker
Loan Tracker
Mining Calculator
Verified Signature
Similiar Contracts
Label Word Cloud
 Sign In  Explorers 
Ethereum Mainnet
Ethereum Mainnet CN
Ropsten Testnet
Kovan Testnet
Rinkeby Testnet
Goerli Testnet
EWC Chain
Beacon Testnet Eth2.0
 All FiltersAddressesTokensName TagsLabelsWebsites 
Download Data (Transactions)
The information you requested can be downloaded from this page. But before continuing please verify that you are not a robot by completing the captcha below.
 Export the earliest 5000 records starting from  Powered by Ethereum 
Etherscan is a Block Explorer and Analytics Platform for Ethereum, a decentralized smart contracts platform.
About Us
Contact Us
Brand Assets
Terms of Service
Developer APIs
Knowledge Base
Network Status
Disqus Comments
Social Links
Etherscan آ© 2019 (A)
Donations 0x71c7656ec7ab88b098defb751b7401b5f6d8976f
 This website uses cookies to improve your experience and has an updated Privacy Policy. Got It $(window).on('load', function () { // initialization of HSMegaMenu component $('.js-mega-menu').HSMegaMenu({ event: 'hover', pageContainer: $('.container'), breakpoint: 767.98, hideTimeOut: 0 }); }); $(document).on('ready', function () { // initialization of header $.HSCore.components.HSHeader.init($('#header')); // initialization of unfold component $.HSCore.components.HSUnfold.init($('[data-unfold-target]'), { afterOpen: function () { $(this).find('input[type="search"]').focus(); } }); // initialization of malihu scrollbar $.HSCore.components.HSMalihuScrollBar.init($('.js-scrollbar')); // initialization of focus state $.HSCore.components.HSFocusState.init(); // initialization of go to $.HSCore.components.HSGoTo.init('.js-go-to'); // initialization of cubeportfolio //$.HSCore.components.HSCubeportfolio.init('.cbp'); }); var strGlobal = sessionStorage.getItem("ShowAs"); var cookieconsent = getCookie("etherscan_cookieconsent"); if (cookieconsent !== "True") { document.getElementById("divcookie").style.display = "block"; }; function getCookie(cname) { var name = cname + "="; var ca = document.cookie.split(';'); for (var i = 0; i < ca.length; i++) { var c = ca[i]; while (c.charAt(0) === ' ') { c = c.substring(1); } if (c.indexOf(name) === 0) { return c.substring(name.length, c.length); } } return ""; } $("#btnCookie").click(function () { $("#divcookie").fadeOut("slow", function () { var d = new Date(); d.setTime(d.getTime() + (1095 * 24 * 60 * 60 * 1000)); var expires = "expires=" + d.toUTCString(); document.cookie = "etherscan_cookieconsent=True" + ";" + expires + ";path=/";; }); }); function handleSearchText(data) { searchAddress = false; if ($("txtSearchInput").val() == "") { $("#hdnSearchText").val(""); } } jQuery(document).ready(function () { $.HSCore.components.HSRangeDatepicker.init('.js-range-datepicker'); $.HSCore.components.HSValidation.init('.js-validate'); }); var correctCaptcha = function (response) { //alert(response); }; function get_action(form) { var v = grecaptcha.getResponse(); if (v.length == 0) { console.log("You can't leave captcha code empty"); return false; } else { console.log("Captcha completed"); document.getElementById("responsetext").innerHTML = "
Your download is being processed.
"; document.getElementById("ContentPlaceHolder1_divAlertMsg").style.display = "none"; document.getElementById("ContentPlaceHolder1_btnSubmit").style.display = "none"; document.getElementById("rcaptcha").style.visibility = "hidden"; return true; } }
Context Link
Go1dfish undelete link
unreddit undelete link
Author: mahdiamolimoghadam
1: ether-search-heading:hover 2: ui-menu-item:hover 3: ui-menu-item:hover 4: ui-menu-item:hover
submitted by removalbot to removalbot [link] [comments]

⚡ Lightning Network Megathread ⚡

Last updated 2018-01-29
This post is a collaboration with the Bitcoin community to create a one-stop source for Lightning Network information.
There are still questions in the FAQ that are unanswered, if you know the answer and can provide a source please do so!

⚡What is the Lightning Network? ⚡


Image Explanations:

Specifications / White Papers


Lightning Network Experts on Reddit

  • starkbot - (Elizabeth Stark - Lightning Labs)
  • roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • stile65 - (Alex Akselrod - Lightning Labs)
  • cfromknecht - (Conner Fromknecht - Lightning Labs)
  • RustyReddit - (Rusty Russell - Blockstream)
  • cdecker - (Christian Decker - Blockstream)
  • Dryja - (Tadge Dryja - Digital Currency Initiative)
  • josephpoon - (Joseph Poon)
  • fdrn - (Fabrice Drouin - ACINQ )
  • pmpadiou - (Pierre-Marie Padiou - ACINQ)

Lightning Network Experts on Twitter

  • @starkness - (Elizabeth Stark - Lightning Labs)
  • @roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • @stile65 - (Alex Akselrod - Lightning Labs)
  • @bitconner - (Conner Fromknecht - Lightning Labs)
  • @johanth - (Johan Halseth - Lightning Labs)
  • @bvu - (Bryan Vu - Lightning Labs)
  • @rusty_twit - (Rusty Russell - Blockstream)
  • @snyke - (Christian Decker - Blockstream)
  • @JackMallers - (Jack Mallers - Zap)
  • @tdryja - (Tadge Dryja - Digital Currency Initiative)
  • @jcp - (Joseph Poon)
  • @alexbosworth - (Alex Bosworth -

Medium Posts

Learning Resources


Desktop Interfaces

Web Interfaces

Tutorials and resources

Lightning on Testnet

Lightning Wallets

Place a testnet transaction

Altcoin Trading using Lightning

  • ZigZag - Disclaimer You must trust ZigZag to send to Target Address

Lightning on Mainnet

Warning - Testing should be done on Testnet

Atomic Swaps

Developer Documentation and Resources

Lightning implementations

  • LND - Lightning Network Daemon (Golang)
  • eclair - A Scala implementation of the Lightning Network (Scala)
  • c-lightning - A Lightning Network implementation in C
  • lit - Lightning Network node software (Golang)
  • lightning-onion - Onion Routed Micropayments for the Lightning Network (Golang)
  • lightning-integration - Lightning Integration Testing Framework
  • ptarmigan - C++ BOLT-Compliant Lightning Network Implementation [Incomplete]


Lightning Network Visualizers/Explorers



Payment Processors

  • BTCPay - Next stable version will include Lightning Network




Slack Channel

Discord Channel


⚡ Lightning FAQs ⚡

If you can answer please PM me and include source if possible. Feel free to help keep these answers up to date and as brief but correct as possible
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.
Is the Lightning Network open source?
Yes, Lightning is open source. Anyone can review the code (in the same way as the bitcoin code)
Who owns and controls the Lightning Network?
Similar to the bitcoin network, no one will ever own or control the Lightning Network. The code is open source and free for anyone to download and review. Anyone can run a node and be part of the network.
I’ve heard that Lightning transactions are happening “off-chain”…Does that mean that my bitcoin will be removed from the blockchain?
No, your bitcoin will never leave the blockchain. Instead your bitcoin will be held in a multi-signature address as long as your channel stays open. When the channel is closed; the final transaction will be added to the blockchain. “Off-chain” is not a perfect term, but it is used due to the fact that the transfer of ownership is no longer reflected on the blockchain until the channel is closed.
Do I need a constant connection to run a lightning node?
Not necessarily,
Example: A and B have a channel. 1 BTC each. A sends B 0.5 BTC. B sends back 0.25 BTC. Balance should be A = 0.75, B = 1.25. If A gets disconnected, B can publish the first Tx where the balance was A = 0.5 and B = 1.5. If the node B does in fact attempt to cheat by publishing an old state (such as the A=0.5 and B=1.5 state), this cheat can then be detected on-chain and used to steal the cheaters funds, i.e., A can see the closing transaction, notice it's an old one and grab all funds in the channel (A=2, B=0). The time that A has in order to react to the cheating counterparty is given by the CheckLockTimeVerify (CLTV) in the cheating transaction, which is adjustable. So if A foresees that it'll be able to check in about once every 24 hours it'll require that the CLTV is at least that large, if it's once a week then that's fine too. You definitely do not need to be online and watching the chain 24/7, just make sure to check in once in a while before the CLTV expires. Alternatively you can outsource the watch duties, in order to keep the CLTV timeouts low. This can be achieved both with trusted third parties or untrusted ones (watchtowers). In the case of a unilateral close, e.g., you just go offline and never come back, the other endpoint will have to wait for that timeout to expire to get its funds back. So peers might not accept channels with extremely high CLTV timeouts. -- Source
What Are Lightning’s Advantages?
Tiny payments are possible: since fees are proportional to the payment amount, you can pay a fraction of a cent; accounting is even done in thousandths of a satoshi. Payments are settled instantly: the money is sent in the time it takes to cross the network to your destination and back, typically a fraction of a second.
Does Lightning require Segregated Witness?
Yes, but not in theory. You could make a poorer lightning network without it, which has higher risks when establishing channels (you might have to wait a month if things go wrong!), has limited channel lifetime, longer minimum payment expiry times on each hop, is less efficient and has less robust outsourcing. The entire spec as written today assumes segregated witness, as it solves all these problems.
Can I Send Funds From Lightning to a Normal Bitcoin Address?
No, for now. For the first version of the protocol, if you wanted to send a normal bitcoin transaction using your channel, you have to close it, send the funds, then reopen the channel (3 transactions). In future versions, you and your peer would agree to spend out of your lightning channel funds just like a normal bitcoin payment, allowing you to use your lightning wallet like a normal bitcoin wallet.
Can I Make Money Running a Lightning Node?
Not really. Anyone can set up a node, and so it’s a race to the bottom on fees. In practice, we may see the network use a nominal fee and not change very much, which only provides an incremental incentive to route on a node you’re going to use yourself, and not enough to run one merely for fees. Having clients use criteria other than fees (e.g. randomness, diversity) in route selection will also help this.
What is the release date for Lightning on Mainnet?
Lightning is already being tested on the Mainnet Twitter Link but as for a specific date, Jameson Lopp says it best
Would there be any KYC/AML issues with certain nodes?
Nope, because there is no custody ever involved. It's just like forwarding packets. -- Source
What is the delay time for the recipient of a transaction receiving confirmation?
Furthermore, the Lightning Network scales not with the transaction throughput of the underlying blockchain, but with modern data processing and latency limits - payments can be made nearly as quickly as packets can be sent. -- Source
How does the lightning network prevent centralization?
Bitcoin Stack Exchange Answer
What are Channel Factories and how do they work?
Bitcoin Stack Exchange Answer
How does the Lightning network work in simple terms?
Bitcoin Stack Exchange Answer
How are paths found in Lightning Network?
Bitcoin Stack Exchange Answer
How would the lightning network work between exchanges?
Each exchange will get to decide and need to implement the software into their system, but some ideas have been outlined here: Google Doc - Lightning Exchanges
Note that by virtue of the usual benefits of cost-less, instantaneous transactions, lightning will make arbitrage between exchanges much more efficient and thus lead to consistent pricing across exchange that adopt it. -- Source
How do lightning nodes find other lightning nodes?
Stack Exchange Answer
Does every user need to store the state of the complete Lightning Network?
According to Rusty's calculations we should be able to store 1 million nodes in about 100 MB, so that should work even for mobile phones. Beyond that we have some proposals ready to lighten the load on endpoints, but we'll cross that bridge when we get there. -- Source
Would I need to download the complete state every time I open the App and make a payment?
No you'd remember the information from the last time you started the app and only sync the differences. This is not yet implemented, but it shouldn't be too hard to get a preliminary protocol working if that turns out to be a problem. -- Source
What needs to happen for the Lightning Network to be deployed and what can I do as a user to help?
Lightning is based on participants in the network running lightning node software that enables them to interact with other nodes. This does not require being a full bitcoin node, but you will have to run "lnd", "eclair", or one of the other node softwares listed above.
All lightning wallets have node software integrated into them, because that is necessary to create payment channels and conduct payments on the network, but you can also intentionally run lnd or similar for public benefit - e.g. you can hold open payment channels or channels with higher volume, than you need for your own transactions. You would be compensated in modest fees by those who transact across your node with multi-hop payments. -- Source
Is there anyway for someone who isn't a developer to meaningfully contribute?
Sure, you can help write up educational material. You can learn and read more about the tech at You can test the various desktop and mobile apps out there (Lightning Desktop, Zap, Eclair apps). -- Source
Do I need to be a miner to be a Lightning Network node?
No -- Source
Do I need to run a full Bitcoin node to run a lightning node?
lit doesn't depend on having your own full node -- it automatically connects to full nodes on the network. -- Source
LND uses a light client mode, so it doesn't require a full node. The name of the light client it uses is called neutrino
How does the lightning network stop "Cheating" (Someone broadcasting an old transaction)?
Upon opening a channel, the two endpoints first agree on a reserve value, below which the channel balance may not drop. This is to make sure that both endpoints always have some skin in the game as rustyreddit puts it :-)
For a cheat to become worth it, the opponent has to be absolutely sure that you cannot retaliate against him during the timeout. So he has to make sure you never ever get network connectivity during that time. Having someone else also watching for channel closures and notifying you, or releasing a canned retaliation, makes this even harder for the attacker. This is because if he misjudged you being truly offline you can retaliate by grabbing all of its funds. Spotty connections, DDoS, and similar will not provide the attacker the necessary guarantees to make cheating worthwhile. Any form of uncertainty about your online status acts as a deterrent to the other endpoint. -- Source
How many times would someone need to open and close their lightning channels?
You typically want to have more than one channel open at any given time for redundancy's sake. And we imagine open and close will probably be automated for the most part. In fact we already have a feature in LND called autopilot that can automatically open channels for a user.
Frequency will depend whether the funds are needed on-chain or more useful on LN. -- Source
Will the lightning network reduce BTC Liquidity due to "locking-up" funds in channels?
Stack Exchange Answer
Can the Lightning Network work on any other cryptocurrency? How?
Stack Exchange Answer
When setting up a Lightning Network Node are fees set for the entire node, or each channel when opened?
You don't really set up a "node" in the sense that anyone with more than one channel can automatically be a node and route payments. Fees on LN can be set by the node, and can change dynamically on the network. -- Source
Can Lightning routing fees be changed dynamically, without closing channels?
Yes but it has to be implemented in the Lightning software being used. -- Source
How can you make sure that there will be routes with large enough balances to handle transactions?
You won't have to do anything. With autopilot enabled, it'll automatically open and close channels based on the availability of the network. -- Source
How does the Lightning Network stop flooding nodes (DDoS) with micro transactions? Is this even an issue?
Stack Exchange Answer

Unanswered Questions

How do on-chain fees work when opening and closing channels? Who pays the fee?
How does the Lightning Network work for mobile users?
What are the best practices for securing a lightning node?
What is a lightning "hub"?
How does lightning handle cross chain (Atomic) swaps?

Special Thanks and Notes

  • Many links found from awesome-lightning-network github
  • Everyone who submitted a question or concern!
  • I'm continuing to format for an easier Mobile experience!
submitted by codedaway to Bitcoin [link] [comments]

Groestlcoin September 2019 Development Release/Update!

For a more interactive view of changes, click here
In our current world; bordering on financial chaos, with tariff wars, Brexit and hyperinflation rife, you can count on Groestlcoin to consistently produce innovation that strikes to take the power away from the few and into the many, even after a full five and a half years of solid development.
Here is what the team has already announced in the last 3 months since the last development update:

What's Being Released Today?

Groestl Nodes

What am I?

Groestl Nodes aims to map out and compare the status of the Groestlcoin mainnet and testnet networks. Even though these networks share the same protocol, there is currently no way to directly compare these coins in a single location. These statistics are essential to evaluate the relative health of both networks.


Source - Website

Groestlcoin Transaction Tool

What am I?

This is a tool for creating unsigned raw Groestlcoin transactions and also to verify existing transactions by entering in the transaction hex and converting this to a human-readable format to verify that a transaction is correct before it is signed.



Groestlcoin AGCore

What am I?

AGCore is an Android app designed to make it easier to run a Groestlcoin Core node on always-on Android appliances such as set-top boxes, Android TVs and repurposed tablets/phones. If you are a non-technical user of Groestlcoin and want an Android app that makes it easy to run a Groestlcoin Core node by acting as a wrapper, then AG Core is the right choice for you.

What's Changed?

Source - Download

Groestlcoin Electrum

What's Changed?

Android Electrum-Specific

OSXWindowsWindows StandaloneWindows PortableLinux - Android
Server SourceServer Installer SourceClient SourceIcon SourceLocale Source

Android Wallet – Including Android Wallet Testnet

What am I?

Android Wallet is a BIP-0032 compatible hierarchial deterministic Groestlcoin Wallet, allowing you to send and receive Groestlcoin via QR codes and URI links.

V7.11.1 Changes

Groestlcoin Java Library SourceSource - DownloadTestnet Download


What am I?

Groestlwallet is designed to protect you from malware, browser security holes, even physical theft. With AES hardware encryption, app sandboxing, keychain and code signatures, groestlwallet represents a significant security advance over web and desktop wallets, and other mobile platforms.
Simplicity is groestlwallet's core design principle. Because groestlwallet is "deterministic", your balance and entire transaction history can be restored from just your recovery phrase.

iOS 0.7.3 Changes

Android v89 Changes

iOS SourceAndroid Source - Android DownloadiOS Download

Groestlcoinomi Released

What am I?

Groestlcoinomi is a lightweight thin-client Groestlcoin wallet based on a client-server protocol.

Groestlcoinomi v1.1 Desktop Changes

Groestlcoinomi Android v1.6 Changes

Groestlcoin Java Library SourceAndroid Source
Android DownloadWindows DownloadMac OS DownloadLinux Download

Groestlcoin BIP39 Tool

What's Changed?

Source - Download
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Subreddit Stats: Monero top posts from 2019-01-07 to 2020-01-05 20:57 PDT

Period: 363.37 days
Submissions Comments
Total 1000 32255
Rate (per day) 2.75 88.32
Unique Redditors 413 4359
Combined Score 87276 146123

Top Submitters' Top Submissions

  1. 11193 points, 116 submissions: dEBRUYNE_1
    1. 'Monero in many respects is closer to what Bitcoin was intended to be than Bitcoin itself' - binaryFate (245 points, 61 comments)
    2. "It was a huge misstep that Satoshi’s original design has weak privacy. It set in stone an expectation that digital assets must have worse privacy than cash. Didn’t have to be this way." - Udi Wertheimer ‏ (215 points, 61 comments)
    3. 'Privacy should not be optional (and that’s why we made it a default).' - Firefox (214 points, 24 comments)
    4. Monero receives 'not a security' rating (best possible rating) by Crypto Rating Council (joint council created by Coinbase, Kraken, Circle/Poloniex, Bittrex, Paxos/itBit, Cumberland, Genesis and Grayscale) (214 points, 30 comments)
    5. GUI v0.14.1.0 'Boron Butterfly' (with Ledger Nano X and Trezor Model T support) released! (213 points, 243 comments)
    6. 'Apple CEO Tim Cook says privacy isn't a feature that should be built into products after the fact' (212 points, 39 comments)
    7. "you’ve been asking... we finally delivered! $XMR is live in [Exodus] Eden version 19.2.2" (202 points, 68 comments)
    8. The Exchange has listed Monero (190 points, 73 comments)
    9. Preliminary information thread regarding the scheduled protocol upgrade of November 30 (183 points, 141 comments)
    10. GUI v0.15.0.1 'Carbon Chamaeleon' released! (177 points, 278 comments)
  2. 3214 points, 41 submissions: SamsungGalaxyPlayer
    1. Some generous donor(s) topped off ALL of the proposals in funding required! (193 points, 38 comments)
    2. Tentative Monero 0.15 Release Schedule (162 points, 51 comments)
    3. Monero: Monero Adds Blockchain Pruning and Improves Transaction Efficiency (143 points, 23 comments)
    4. Logs from the 2.5 hr dev meeting on Monero's PoW (124 points, 124 comments)
    5. New logo for the Monero Community Workgroup YouTube channel, courtesy of u/anhdres! (119 points, 19 comments)
    6. Announcing the "Beware of Bitcoin" campaign for Mastering Monero (117 points, 98 comments)
    7. Preliminary support for Monero on BTCPayServer has been merged! (116 points, 19 comments)
    8. OpenBazaar dev call tomorrow discussing proof of concept for Monero integration (111 points, 21 comments)
    9. "Linking Anonymous Transactions via Remote Side-Channel Attacks" - Now-Fixed Network Analysis Attacks on Monero and Zcash (102 points, 50 comments)
    10. Monero added to Exodus mobile (100 points, 33 comments)
  3. 3157 points, 32 submissions: OsrsNeedsF2P
    1. Alright everybody pack it up. US Attorney General says encryption creates a security risk; if your wallet requires a password to unlock, you're doing acts that are used by terrorists, and it's time to stop. (317 points, 56 comments)
    2. What a shame Monero isn't included ¯_(ツ)_/¯ (254 points, 47 comments)
    3. Linus Tovalds believes processor vendors are approaching the end of Moore's Law, and optimization of code is going to be needed to increase performance (245 points, 61 comments)
    4. Fluffypony Appreciation Thread (199 points, 62 comments)
    5. IRS wants to subpoena Google, Apple & Microsoft to see if users have downloaded cryptocurrency related applications (190 points, 96 comments)
    6. Soon ™ (151 points, 55 comments)
    7. Privacy matters: Bitpay donations to Hong Kong Free Press not going through (141 points, 20 comments)
    8. IBM, MIT and Elliptic release world’s largest labeled dataset of bitcoin transactions to help identify "Bad Actors" (119 points, 22 comments)
    9. Celebrating 10 years of Tails (114 points, 5 comments)
    10. Former CTO of Purism, the developers of the Librem 5 Linux mobile phone, notes the PR momentum they got with GNOME, Matrix, and Monero (96 points, 12 comments)
  4. 2106 points, 29 submissions: ErCiccione
    1. Church Of Monero: Enough is enough - How the leader of the Church tried to fool the community to make look like the Church is organizing the Monero Konferenco and even adding his own Monero address on the flyer (166 points, 268 comments)
    2. [URGENT]Call for translators! - We have two days to submit as many translations as possible for the next release of the GUI wallet! We need your help! (123 points, 46 comments)
    3. Monero translators, we need you to make one final sprint! The code freeze is imminent. (112 points, 15 comments)
    4. 2 new projects joined the Monero Ecosystem! MoneroBox, a plug-and-play, zero-configuration Monero full node and Monero-Javascript, Monero wallet and daemon JavaScript API (107 points, 12 comments)
    5. PSA: We've posted an announcement regarding the potentially compromised CLI binaries on (101 points, 47 comments)
    6. New language for Monerujo: Esperanto! Will be available in next release (97 points, 6 comments)
    7. Monero Python - A comprehensive Python module for handling Monero cryptocurrency, has officially joined the Monero Ecosystem Project! (94 points, 12 comments)
    8. is now available in German! (89 points, 16 comments)
    9. updated: New user friendly download page, Welcome video in Brazilian Portuguese, 5 new merchants accepting Monero and more (76 points, 12 comments)
    10. My last proposal as coordinator of the Localization Workgroup has ended. A recap, some updates, plans for the future of the internationalization of Monero and a huge thanks (73 points, 22 comments)
  5. 1257 points, 14 submissions: xmrhaelan
    1. A response to the Reuters article about Monero (183 points, 28 comments)
    2. CoinDesk research shows Monero is #4 by Reddit post volume community metrics. Kudos to you all! (172 points, 57 comments)
    3. A response to Coinbase regarding their criticism of Monero’s approach to PoW security (171 points, 91 comments)
    4. Graphic idea for Boron Butterfly release, courtesy of Monero Outreach (170 points, 36 comments)
    5. PSA: Seeking Volunteer Reviewers for PoW RandomX (104 points, 55 comments)
    6. PSA: Mine Monero to Support the Network (77 points, 80 comments)
    7. Looking for ways to help, volunteer, or contribute to the Monero community? Look no further! (70 points, 20 comments)
    8. SWOT Analysis of Monero [draft] (59 points, 35 comments)
    9. Monero Konferenco Press Release (55 points, 9 comments)
    10. A Simplified Guide to Monero Wallets, from Monero Outreach (40 points, 9 comments)
  6. 1220 points, 9 submissions: geonic_
    1. Monero is second only to Bitcoin in terms of number of commits for the past 4 years! (269 points, 59 comments)
    2. Joe Weisenthal (Bloomberg): Until true anonymity (or near anonymity) is developed into Bitcoin, it's still incomplete, and not delivering on its promise. Without anonymity, there's no censorship resistance, and no store of value. (173 points, 38 comments)
    3. Nick Szabo puts Monero on an equal footing with Bitcoin: “deeply safe Bitcoin & Monero” (170 points, 41 comments)
    4. Chainalysis: Bitcoin is the most popular cryptocurrency accepted on dark markets, followed by Monero. Dark web spending to reach $1B this year. (150 points, 39 comments)
    5. BTC maximalist QOTD: “If you send me bitcoin, I would prefer if you used coinjoin first. I would prefer to not know the history of your sats. Don't put that liability on me. Thanks.” (142 points, 45 comments)
    6. Peter Todd wishes Bitcoin had perpetual inflation -- 2140 is much closer than you think (101 points, 89 comments)
    7. nopara73, creator of Wasabi Wallet: "Compared to privacy coins Wasabi is just a temporary hack. I think without Confidential Transactions, as the transaction fees grow, privacy will be priced out of Bitcoin's main chain." (95 points, 48 comments)
    8. Scott Stornetta, inventor of the first blockchain: “When I first read the Bitcoin white paper I thought [...] there’s no privacy at all here! What you’ve got is a completely traceable record of what’s going on.” @12:00 (68 points, 17 comments)
    9. Let's discuss: is Monero a privacy tool (i.e. Tor, CoinJoin, etc.) or a secure layer one protocol (https)? how aligned is it with Bitcoin ideologically (consider current vs original Bitcoin ideology)? is Monero's blockchain a temporary solution? (52 points, 27 comments)
  7. 1186 points, 12 submissions: hyc_symas
    1. RandomX Audit Status (148 points, 29 comments)
    2. RandomX Status Update (134 points, 82 comments)
    3. RandomX Audit Status - Final (130 points, 54 comments)
    4. RandomX Audit Status (116 points, 9 comments)
    5. RandomX Audit Status (110 points, 24 comments)
    6. RandomX testnet (99 points, 23 comments)
    7. Blockchain Growth stats (87 points, 26 comments)
    8. RandomX Auditor Selection (86 points, 47 comments)
    9. CCS: RandomX Audit now in Funding Required (78 points, 45 comments)
    10. RandomX Audit Funding Request (76 points, 14 comments)
  8. 1171 points, 13 submissions: Thunderosa
    1. Blend in the Crowd with Carbon Chamaeleon v0.15.0.0 (161 points, 25 comments)
    2. @monero Twitter banner (141 points, 25 comments)
    3. A little Christmas card for my favorite freaks. Happy Holidays! (136 points, 4 comments)
    4. Boron Butterfly ASCII (117 points, 23 comments)
    5. Monero Torch (111 points, 73 comments)
    6. Konferenco funding! (105 points, 19 comments)
    7. supportxmr-gui Update - Twice the features, half the size. All vanilla. (98 points, 15 comments)
    8. Happy 5th (70 points, 16 comments)
    9. Explore the expert speakers and important topics of Monero Konferenco 2019! (57 points, 11 comments)
    10. RandomX - Monero and Arweave to Validate New Proof-of-Work Algorithm (52 points, 12 comments)
  9. 1129 points, 14 submissions: pinkphloid
    1. [NEWS] CAKE WALLET for Monero has crossed 20,000 unique installs on iOS. (123 points, 69 comments)
    2. [PUBLIC BETA] Cake Wallet for Monero is now available on Android! (104 points, 48 comments)
    3. Going to the Monero Konferenco? Don’t miss MoneroTalk’s party Saturday night Casa De Monero! It’s THE party of the weekend! (99 points, 13 comments)
    4. [UPDATE] Cake Wallet version 3.1.7, now with Address book, Back-up to iCloud and other locations, and BCH is back in the exchange! (92 points, 70 comments)
    5. [UPDATE] Cake Wallet version 3.1.17 with Hidden balance mode plus other new useful features! (90 points, 16 comments)
    6. Cake Wallet is hiring! (88 points, 14 comments)
    7. If you like using Cake Wallet, please vote! Thank you 🙏🏼🙏🏼 (87 points, 20 comments)
    8. NYC Monero meetup featuring guest speaker Justin Ehrenhofer of XMR Community Work Group. - by Cake Wallet and Monero Talk (82 points, 10 comments)
    9. [UPDATE] Cake Wallet - Version 3.1.20 Black Forest Cake Edition (73 points, 23 comments)
    10. Cake Wallet (small news) - we have acquired the domain! (67 points, 16 comments)
  10. 1054 points, 13 submissions: jman76358
    1. Monero receives A rating (194 points, 43 comments)
    2. Exodus Wallet now supports Monero (128 points, 38 comments)
    3. I tell a lot of people about Monero who don't know anything about crypto and they instantly get it. They ask me the same thing over and over, so why do people still use Bitcoin? (127 points, 119 comments)
    4. How trustyworthy is the Cake wallet for iOS? (80 points, 43 comments)
    5. Why don't other coin devs like talking about fungibility? They seem to shrug it off even though it's a necessary component to being a currency. (77 points, 85 comments)
    6. Any idea what's going on with the Official Monero Twitter page? (67 points, 33 comments)
    7. Should Quantum Resistance research for XMR be started soon? I would love to see what the great minds of the dev community could come up with ! (64 points, 55 comments)
    8. The End of Mainstream Privacy is Upon Us (62 points, 28 comments)
    9. Non-KYC exchanges coming to an end, even for small amounts. DEX with Monero as main coin when? (57 points, 18 comments)
    10. I find it funny that people think the gov doesn’t want people to use bitcoin, trust me , they’re estatic that people want to voluntarily be tracked and surveilled. (55 points, 45 comments)

Top Commenters

  1. dEBRUYNE_1 (9070 points, 1572 comments)
  2. OsrsNeedsF2P (5373 points, 757 comments)
  3. hyc_symas (2954 points, 332 comments)
  4. gingeropolous (2345 points, 313 comments)
  5. SamsungGalaxyPlayer (1897 points, 271 comments)
  6. rbrunner7 (1844 points, 299 comments)
  7. spirtdica (1835 points, 544 comments)
  8. pebx (1596 points, 318 comments)
  9. SarangNoether (1244 points, 115 comments)
  10. Same_As_It_Ever_Was (1234 points, 248 comments)

Top Submissions

  1. VLC accepts XMR for donations. Owner has turned down millions to keep it open source and ad-free. by tempMonero123 (468 points, 34 comments)
  2. Monero’s New Mascot by deepdarksea (433 points, 33 comments)
  3. Monero fashion spotted in the wild by Peterb88 (406 points, 34 comments)
  4. Found this in Basel, Switzerland. Then bought 0.968745 with no ID. by _0_1 (395 points, 120 comments)
  5. Bye-bye ASIC's! :-) by TheFuzzStone (357 points, 167 comments)
  6. Art by me by nikitko13 (328 points, 58 comments)
  7. Analysis: More than 85% of the current Monero Hashrate is ASICs and each machine is doing 128 kh/s by MoneroCrusher (324 points, 427 comments)
  8. Hi guys, long time no see 😁 this is what I do when not painting. Tools are printed on 3D printer. by cryptopaintings (322 points, 47 comments)
  9. Alright everybody pack it up. US Attorney General says encryption creates a security risk; if your wallet requires a password to unlock, you're doing acts that are used by terrorists, and it's time to stop. by OsrsNeedsF2P (317 points, 56 comments)
  10. India's ban could be Monero's boon by whotookmycrypto (313 points, 60 comments)

Top Comments

  1. 175 points: MoneroTipsBot's comment in Soon ™
  2. 139 points: MoneroCrusher's comment in Analysis: More than 85% of the current Monero Hashrate is ASICs and each machine is doing 128 kh/s
  3. 132 points: jonaemahina's comment in Kidnappers demand Monero ransom for wife of one of the Richest men in Norway.
  4. 116 points: leonardochaia's comment in Monero's Fluffypony reveals why he stepped down
  5. 111 points: katiecharm's comment in Tax Ramifications of Buying Coffee with Cryptocurrency
  6. 102 points: AlexAnarcho's comment in Kidnappers demand Monero ransom for wife of one of the Richest men in Norway.
  7. 100 points: fluffyponyza's comment in Fluffypony Appreciation Thread
  8. 96 points: Same_As_It_Ever_Was's comment in [Moderation Announcement] Religion related posts are now considered off-topic and will be removed
  9. 94 points: Flenst's comment in Security Warning: CLI binaries available on may have been compromised at some point during the last 24h.
  10. 93 points: moneroh's comment in Name Monero 0.14!
Generated with BBoe's Subreddit Stats
submitted by subreddit_stats to subreddit_stats [link] [comments]

Transcript of the community Q&A with Steve Shadders and Daniel Connolly of the Bitcoin SV development team. We talk about the path to big blocks, new opcodes, selfish mining, malleability, and why November will lead to a divergence in consensus rules. (Cont in comments)

We've gone through the painstaking process of transcribing the linked interview with Steve Shadders and Daniell Connolly of the Bitcoin SV team. There is an amazing amount of information in this interview that we feel is important for businesses and miners to hear, so we believe it was important to get this is a written form. To avoid any bias, the transcript is taken almost word for word from the video, with just a few changes made for easier reading. If you see any corrections that need to be made, please let us know.
Each question is in bold, and each question and response is timestamped accordingly. You can follow along with the video here:


Connor: 02:19.68,0:02:45.10
Alright so thank You Daniel and Steve for joining us. We're joined by Steve Shadders and Daniel Connolly from nChain and also the lead developers of the Satoshi’s Vision client. So Daniel and Steve do you guys just want to introduce yourselves before we kind of get started here - who are you guys and how did you get started?
Steve: 0,0:02:38.83,0:03:30.61
So I'm Steve Shadders and at nChain I am the director of solutions in engineering and specifically for Bitcoin SV I am the technical director of the project which means that I'm a bit less hands-on than Daniel but I handle a lot of the liaison with the miners - that's the conditional project.
Hi I’m Daniel I’m the lead developer for Bitcoin SV. As the team's grown that means that I do less actual coding myself but more organizing the team and organizing what we’re working on.
Connor 03:23.07,0:04:15.98
Great so we took some questions - we asked on Reddit to have people come and post their questions. We tried to take as many of those as we could and eliminate some of the duplicates, so we're gonna kind of go through each question one by one. We added some questions of our own in and we'll try and get through most of these if we can. So I think we just wanted to start out and ask, you know, Bitcoin Cash is a little bit over a year old now. Bitcoin itself is ten years old but in the past a little over a year now what has the process been like for you guys working with the multiple development teams and, you know, why is it important that the Satoshi’s vision client exists today?
Steve: 0:04:17.66,0:06:03.46
I mean yes well we’ve been in touch with the developer teams for quite some time - I think a bi-weekly meeting of Bitcoin Cash developers across all implementations started around November last year. I myself joined those in January or February of this year and Daniel a few months later. So we communicate with all of those teams and I think, you know, it's not been without its challenges. It's well known that there's a lot of disagreements around it, but some what I do look forward to in the near future is a day when the consensus issues themselves are all rather settled, and if we get to that point then there's not going to be much reason for the different developer teams to disagree on stuff. They might disagree on non-consensus related stuff but that's not the end of the world because, you know, Bitcoin Unlimited is free to go and implement whatever they want in the back end of a Bitcoin Unlimited and Bitcoin SV is free to do whatever they want in the backend, and if they interoperate on a non-consensus level great. If they don't not such a big problem there will obviously be bridges between the two, so, yeah I think going forward the complications of having so many personalities with wildly different ideas are going to get less and less.
Cory: 0:06:00.59,0:06:19.59
I guess moving forward now another question about the testnet - a lot of people on Reddit have been asking what the testing process for Bitcoin SV has been like, and if you guys plan on releasing any of those results from the testing?
Daniel: 0:06:19.59,0:07:55.55
Sure yeah so our release will be concentrated on the stability, right, with the first release of Bitcoin SV and that involved doing a large amount of additional testing particularly not so much at the unit test level but at the more system test so setting up test networks, performing tests, and making sure that the software behaved as we expected, right. Confirming the changes we made, making sure that there aren’t any other side effects. Because of, you know, it was quite a rush to release the first version so we've got our test results documented, but not in a way that we can really release them. We're thinking about doing that but we’re not there yet.
Steve: 0:07:50.25,0:09:50.87
Just to tidy that up - we've spent a lot of our time developing really robust test processes and the reporting is something that we can read on our internal systems easily, but we need to tidy that up to give it out for public release. The priority for us was making sure that the software was safe to use. We've established a test framework that involves a progression of code changes through multiple test environments - I think it's five different test environments before it gets the QA stamp of approval - and as for the question about the testnet, yeah, we've got four of them. We've got Testnet One and Testnet Two. A slightly different numbering scheme to the testnet three that everyone's probably used to – that’s just how we reference them internally. They're [1 and 2] both forks of Testnet Three. [Testnet] One we used for activation testing, so we would test things before and after activation - that one’s set to reset every couple of days. The other one [Testnet Two] was set to post activation so that we can test all of the consensus changes. The third one was a performance test network which I think most people have probably have heard us refer to before as Gigablock Testnet. I get my tongue tied every time I try to say that word so I've started calling it the Performance test network and I think we're planning on having two of those: one that we can just do our own stuff with and experiment without having to worry about external unknown factors going on and having other people joining it and doing stuff that we don't know about that affects our ability to baseline performance tests, but the other one (which I think might still be a work in progress so Daniel might be able to answer that one) is one of them where basically everyone will be able to join and they can try and mess stuff up as bad as they want.
Daniel: 0:09:45.02,0:10:20.93
Yeah, so we so we recently shared the details of Testnet One and Two with the with the other BCH developer groups. The Gigablock test network we've shared up with one group so far but yeah we're building it as Steve pointed out to be publicly accessible.
Connor: 0:10:18.88,0:10:44.00
I think that was my next question I saw that you posted on Twitter about the revived Gigablock testnet initiative and so it looked like blocks bigger than 32 megabytes were being mined and propagated there, but maybe the block explorers themselves were coming down - what does that revived Gigablock test initiative look like?
Daniel: 0:10:41.62,0:11:58.34
That's what did the Gigablock test network is. So the Gigablock test network was first set up by Bitcoin Unlimited with nChain’s help and they did some great work on that, and we wanted to revive it. So we wanted to bring it back and do some large-scale testing on it. It's a flexible network - at one point we had we had eight different large nodes spread across the globe, sort of mirroring the old one. Right now we scaled back because we're not using it at the moment so they'll notice I think three. We have produced some large blocks there and it's helped us a lot in our research and into the scaling capabilities of Bitcoin SV, so it's guided the work that the team’s been doing for the last month or two on the improvements that we need for scalability.
Steve: 0:11:56.48,0:13:34.25
I think that's actually a good point to kind of frame where our priorities have been in kind of two separate stages. I think, as Daniel mentioned before, because of the time constraints we kept the change set for the October 15 release as minimal as possible - it was just the consensus changes. We didn't do any work on performance at all and we put all our focus and energy into establishing the QA process and making sure that that change was safe and that was a good process for us to go through. It highlighted what we were missing in our team – we got our recruiters very busy recruiting of a Test Manager and more QA people. The second stage after that is performance related work which, as Daniel mentioned, the results of our performance testing fed into what tasks we were gonna start working on for the performance related stuff. Now that work is still in progress - some of the items that we identified the code is done and that's going through the QA process but it’s not quite there yet. That's basically the two-stage process that we've been through so far. We have a roadmap that goes further into the future that outlines more stuff, but primarily it’s been QA first, performance second. The performance enhancements are close and on the horizon but some of that work should be ongoing for quite some time.
Daniel: 0:13:37.49,0:14:35.14
Some of the changes we need for the performance are really quite large and really get down into the base level view of the software. There's kind of two groups of them mainly. One that are internal to the software – to Bitcoin SV itself - improving the way it works inside. And then there's other ones that interface it with the outside world. One of those in particular we're working closely with another group to make a compatible change - it's not consensus changing or anything like that - but having the same interface on multiple different implementations will be very helpful right, so we're working closely with them to make improvements for scalability.
Connor: 0:14:32.60,0:15:26.45
Obviously for Bitcoin SV one of the main things that you guys wanted to do that that some of the other developer groups weren't willing to do right now is to increase the maximum default block size to 128 megabytes. I kind of wanted to pick your brains a little bit about - a lot of the objection to either removing the box size entirely or increasing it on a larger scale is this idea of like the infinite block attack right and that kind of came through in a lot of the questions. What are your thoughts on the “infinite block attack” and is it is it something that that really exists, is it something that miners themselves should be more proactive on preventing, or I guess what are your thoughts on that attack that everyone says will happen if you uncap the block size?
Steve: 0:15:23.45,0:18:28.56
I'm often quoted on Twitter and Reddit - I've said before the infinite block attack is bullshit. Now, that's a statement that I suppose is easy to take out of context, but I think the 128 MB limit is something where there’s probably two schools of thought about. There are some people who think that you shouldn't increase the limit to 128 MB until the software can handle it, and there are others who think that it's fine to do it now so that the limit is increased when the software can handle it and you don’t run into the limit when this when the software improves and can handle it. Obviously we’re from the latter school of thought. As I said before we've got a bunch of performance increases, performance enhancements, in the pipeline. If we wait till May to increase the block size limit to 128 MB then those performance enhancements will go in, but we won't be able to actually demonstrate it on mainnet. As for the infinitive block attack itself, I mean there are a number of mitigations that you can put in place. I mean firstly, you know, going down to a bit of the tech detail - when you send a block message or send any peer to peer message there's a header which has the size of the message. If someone says they're sending you a 30MB message and you're receiving it and it gets to 33MB then obviously you know something's wrong so you can drop the connection. If someone sends you a message that's 129 MB and you know the block size limit is 128 you know it’s kind of pointless to download that message. So I mean these are just some of the mitigations that you can put in place. When I say the attack is bullshit, I mean I mean it is bullshit from the sense that it's really quite trivial to prevent it from happening. I think there is a bit of a school of thought in the Bitcoin world that if it's not in the software right now then it kind of doesn't exist. I disagree with that, because there are small changes that can be made to work around problems like this. One other aspect of the infinite block attack, and let’s not call it the infinite block attack, let's just call it the large block attack - it takes a lot of time to validate that we gotten around by having parallel pipelines for blocks to come in, so you've got a block that's coming in it's got a unknown stuck on it for two hours or whatever downloading and validating it. At some point another block is going to get mined b someone else and as long as those two blocks aren't stuck in a serial pipeline then you know the problem kind of goes away.
Cory: 0:18:26.55,0:18:48.27
Are there any concerns with the propagation of those larger blocks? Because there's a lot of questions around you know what the practical size of scaling right now Bitcoin SV could do and the concerns around propagating those blocks across the whole network.
Steve 0:18:45.84,0:21:37.73
Yes, there have been concerns raised about it. I think what people forget is that compact blocks and xThin exist, so if a 32MB block is not send 32MB of data in most cases, almost all cases. The concern here that I think I do find legitimate is the Great Firewall of China. Very early on in Bitcoin SV we started talking with miners on the other side of the firewall and that was one of their primary concerns. We had anecdotal reports of people who were having trouble getting a stable connection any faster than 200 kilobits per second and even with compact blocks you still need to get the transactions across the firewall. So we've done a lot of research into that - we tested our own links across the firewall, rather CoinGeeks links across the firewall as they’ve given us access to some of their servers so that we can play around, and we were able to get sustained rates of 50 to 90 megabits per second which pushes that problem quite a long way down the road into the future. I don't know the maths off the top of my head, but the size of the blocks that can sustain is pretty large. So we're looking at a couple of options - it may well be the chattiness of the peer-to-peer protocol causes some of these issues with the Great Firewall, so we have someone building a bridge concept/tool where you basically just have one kind of TX vacuum on either side of the firewall that collects them all up and sends them off every one or two seconds as a single big chunk to eliminate some of that chattiness. The other is we're looking at building a multiplexer that will sit and send stuff up to the peer-to-peer network on one side and send it over splitters, to send it over multiple links, reassemble it on the other side so we can sort of transition the great Firewall without too much trouble, but I mean getting back to the core of your question - yes there is a theoretical limit to block size propagation time and that's kind of where Moore's Law comes in. Putting faster links and you kick that can further down the road and you just keep on putting in faster links. I don't think 128 main blocks are going to be an issue though with the speed of the internet that we have nowadays.
Connor: 0:21:34.99,0:22:17.84
One of the other changes that you guys are introducing is increasing the max script size so I think right now it’s going from 201 to 500 [opcodes]. So I guess a few of the questions we got was I guess #1 like why not uncap it entirely - I think you guys said you ran into some concerns while testing that - and then #2 also specifically we had a question about how certain are you that there are no remaining n squared bugs or vulnerabilities left in script execution?
Steve: 0:22:15.50,0:25:36.79
It's interesting the decision - we were initially planning on removing that cap altogether and the next cap that comes into play after that (next effective cap is a 10,000 byte limit on the size of the script). We took a more conservative route and decided to wind that back to 500 - it's interesting that we got some criticism for that when the primary criticism I think that was leveled against us was it’s dangerous to increase that limit to unlimited. We did that because we’re being conservative. We did some research into these log n squared bugs, sorry – attacks, that people have referred to. We identified a few of them and we had a hard think about it and thought - look if we can find this many in a short time we can fix them all (the whack-a-mole approach) but it does suggest that there may well be more unknown ones. So we thought about putting, you know, taking the whack-a-mole approach, but that doesn't really give us any certainty. We will fix all of those individually but a more global approach is to make sure that if anyone does discover one of these scripts it doesn't bring the node to a screaming halt, so the problem here is because the Bitcoin node is essentially single-threaded, if you get one of these scripts that locks up the script engine for a long time everything that's behind it in the queue has to stop and wait. So what we wanted to do, and this is something we've got an engineer actively working on right now, is once that script validation goad path is properly paralyzed (parts of it already are), then we’ll basically assign a few threads for well-known transaction templates, and a few threads for any any type of script. So if you get a few scripts that are nasty and lock up a thread for a while that's not going to stop the node from working because you've got these other kind of lanes of the highway that are exclusively reserved for well-known script templates and they'll just keep on passing through. Once you've got that in place, and I think we're in a much better position to get rid of that limit entirely because the worst that's going to happen is your non-standard script pipelines get clogged up but everything else will keep keep ticking along - there are other mitigations for this as well I mean I know you could always put a time limit on script execution if they wanted to, and that would be something that would be up to individual miners. Bitcoin SV's job I think is to provide the tools for the miners and the miners can then choose, you know, how to make use of them - if they want to set time limits on script execution then that's a choice for them.
Daniel: 0:25:34.82,0:26:15.85
Yeah, I'd like to point out that a node here, when it receives a transaction through the peer to peer network, it doesn't have to accept that transaction, you can reject it. If it looks suspicious to the node it can just say you know we're not going to deal with that, or if it takes more than five minutes to execute, or more than a minute even, it can just abort and discard that transaction, right. The only time we can’t do that is when it's in a block already, but then it could decide to reject the block as well. It's all possibilities there could be in the software.
Steve: 0:26:13.08,0:26:20.64
Yeah, and if it's in a block already it means someone else was able to validate it so…
Cory: 0,0:26:21.21,0:26:43.60
There’s a lot of discussions about the re-enabled opcodes coming – OP_MUL, OP_INVERT, OP_LSHIFT, and OP_RSHIFT up invert op l shift and op r shift you maybe explain the significance of those op codes being re-enabled?
Steve: 0:26:42.01,0:28:17.01
Well I mean one of one of the most significant things is other than two, which are minor variants of DUP and MUL, they represent almost the complete set of original op codes. I think that's not necessarily a technical issue, but it's an important milestone. MUL is one that's that I've heard some interesting comments about. People ask me why are you putting OP_MUL back in if you're planning on changing them to big number operations instead of the 32-bit limit that they're currently imposed upon. The simple answer to that question is that we currently have all of the other arithmetic operations except for OP_MUL. We’ve got add divide, subtract, modulo – it’s odd to have a script system that's got all the mathematical primitives except for multiplication. The other answer to that question is that they're useful - we've talked about a Rabin signature solution that basically replicates the function of DATASIGVERIFY. That's just one example of a use case for this - most cryptographic primitive operations require mathematical operations and bit shifts are useful for a whole ton of things. So it's really just about completing that work and completing the script engine, or rather not completing it, but putting it back the way that it was it was meant to be.
Connor 0:28:20.42,0:29:22.62
Big Num vs 32 Bit. I've seen Daniel - I think I saw you answer this on Reddit a little while ago, but the new op codes using logical shifts and Satoshi’s version use arithmetic shifts - the general question that I think a lot of people keep bringing up is, maybe in a rhetorical way but they say why not restore it back to the way Satoshi had it exactly - what are the benefits of changing it now to operate a little bit differently?
Daniel: 0:29:18.75,0:31:12.15
Yeah there's two parts there - the big number one and the L shift being a logical shift instead of arithmetic. so when we re-enabled these opcodes we've looked at them carefully and have adjusted them slightly as we did in the past with OP_SPLIT. So the new LSHIFT and RSHIFT are bitwise operators. They can be used to implement arithmetic based shifts - I think I've posted a short script that did that, but we can't do it the other way around, right. You couldn't use an arithmetic shift operator to implement a bitwise one. It's because of the ordering of the bytes in the arithmetic values, so the values that represent numbers. The little endian which means they're swapped around to what many other systems - what I've considered normal - or big-endian. And if you start shifting that properly as a number then then shifting sequence in the bytes is a bit strange, so it couldn't go the other way around - you couldn't implement bitwise shift with arithmetic, so we chose to make them bitwise operators - that's what we proposed.
Steve: 0:31:10.57,0:31:51.51
That was essentially a decision that was actually made in May, or rather a consequence of decisions that were made in May. So in May we reintroduced OP_AND, OP_OR, and OP_XOR, and that was also another decision to replace three different string operators with OP_SPLIT was also made. So that was not a decision that we've made unilaterally, it was a decision that was made collectively with all of the BCH developers - well not all of them were actually in all of the meetings, but they were all invited.
Daniel: 0:31:48.24,0:32:23.13
Another example of that is that we originally proposed OP_2DIV and OP_2MUL was it, I think, and this is a single operator that multiplies the value by two, right, but it was pointed out that that can very easily be achieved by just doing multiply by two instead of having a separate operator for it, so we scrapped those, we took them back out, because we wanted to keep the number of operators minimum yeah.
Steve: 0:32:17.59,0:33:47.20
There was an appetite around for keeping the operators minimal. I mean the decision about the idea to replace OP_SUBSTR, OP_LEFT, OP_RIGHT with OP_SPLIT operator actually came from Gavin Andresen. He made a brief appearance in the Telegram workgroups while we were working out what to do with May opcodes and obviously Gavin's word kind of carries a lot of weight and we listen to him. But because we had chosen to implement the May opcodes (the bitwise opcodes) and treat the data as big-endian data streams (well, sorry big-endian not really applicable just plain data strings) it would have been completely inconsistent to implement LSHIFT and RSHIFT as integer operators because then you would have had a set of bitwise operators that operated on two different kinds of data, which would have just been nonsensical and very difficult for anyone to work with, so yeah. I mean it's a bit like P2SH - it wasn't a part of the original Satoshi protocol that once some things are done they're done and you know if you want to want to make forward progress you've got to work within that that framework that exists.
Daniel: 0:33:45.85,0:34:48.97
When we get to the big number ones then it gets really complicated, you know, number implementations because then you can't change the behavior of the existing opcodes, and I don't mean OP_MUL, I mean the other ones that have been there for a while. You can't suddenly make them big number ones without seriously looking at what scripts there might be out there and the impact of that change on those existing scripts, right. The other the other point is you don't know what scripts are out there because of P2SH - there could be scripts that you don't know the content of and you don't know what effect changing the behavior of these operators would mean. The big number thing is tricky, so another option might be, yeah, I don't know what the options for though it needs some serious thought.
Steve: 0:34:43.27,0:35:24.23
That’s something we've reached out to the other implementation teams about - actually really would like their input on the best ways to go about restoring big number operations. It has to be done extremely carefully and I don't know if we'll get there by May next year, or when, but we’re certainly willing to put a lot of resources into it and we're more than happy to work with BU or XT or whoever wants to work with us on getting that done and getting it done safely.
Connor: 0:35:19.30,0:35:57.49
Kind of along this similar vein, you know, Bitcoin Core introduced this concept of standard scripts, right - standard and non-standard scripts. I had pretty interesting conversation with Clemens Ley about use cases for “non-standard scripts” as they're called. I know at least one developer on Bitcoin ABC is very hesitant, or kind of pushed back on him about doing that and so what are your thoughts about non-standard scripts and the entirety of like an IsStandard check?
Steve: 0:35:58.31,0:37:35.73
I’d actually like to repurpose the concept. I think I mentioned before multi-threaded script validation and having some dedicated well-known script templates - when you say the word well-known script template there’s already a check in Bitcoin that kind of tells you if it's well-known or not and that's IsStandard. I'm generally in favor of getting rid of the notion of standard transactions, but it's actually a decision for miners, and it's really more of a behavioral change than it is a technical change. There's a whole bunch of configuration options that miners can set that affect what they do what they consider to be standard and not standard, but the reality is not too many miners are using those configuration options. So I mean standard transactions as a concept is meaningful to an arbitrary degree I suppose, but yeah I would like to make it easier for people to get non-standard scripts into Bitcoin so that they can experiment, and from discussions of I’ve had with CoinGeek they’re quite keen on making their miners accept, you know, at least initially a wider variety of transactions eventually.
Daniel: 0:37:32.85,0:38:07.95
So I think IsStandard will remain important within the implementation itself for efficiency purposes, right - you want to streamline base use case of cash payments through them and prioritizing. That's where it will remain important but on the interfaces from the node to the rest of the network, yeah I could easily see it being removed.
Cory: 0,0:38:06.24,0:38:35.46
*Connor mentioned that there's some people that disagree with Bitcoin SV and what they're doing - a lot of questions around, you know, why November? Why implement these changes in November - they think that maybe the six-month delay might not cause a split. Well, first off what do you think about the ideas of a potential split and I guess what is the urgency for November?
Steve: 0:38:33.30,0:40:42.42
Well in November there's going to be a divergence of consensus rules regardless of whether we implement these new op codes or not. Bitcoin ABC released their spec for the November Hard fork change I think on August 16th or 17th something like that and their client as well and it included CTOR and it included DSV. Now for the miners that commissioned the SV project, CTOR and DSV are controversial changes and once they're in they're in. They can't be reversed - I mean CTOR maybe you could reverse it at a later date, but DSV once someone's put a P2SH transaction into the project or even a non P2SH transaction in the blockchain using that opcode it's irreversible. So it's interesting that some people refer to the Bitcoin SV project as causing a split - we're not proposing to do anything that anyone disagrees with - there might be some contention about changing the opcode limit but what we're doing, I mean Bitcoin ABC already published their spec for May and it is our spec for the new opcodes, so in terms of urgency - should we wait? Well the fact is that we can't - come November you know it's bit like Segwit - once Segwit was in, yes you arguably could get it out by spending everyone's anyone can spend transactions but in reality it's never going to be that easy and it's going to cause a lot of economic disruption, so yeah that's it. We're putting out changes in because it's not gonna make a difference either way in terms of whether there's going to be a divergence of consensus rules - there's going to be a divergence whether whatever our changes are. Our changes are not controversial at all.
Daniel: 0:40:39.79,0:41:03.08
If we didn't include these changes in the November upgrade we'd be pushing ahead with a no-change, right, but the November upgrade is there so we should use it while we can. Adding these non-controversial changes to it.
Connor: 0:41:01.55,0:41:35.61
Can you talk about DATASIGVERIFY? What are your concerns with it? The general concept that's been kind of floated around because of Ryan Charles is the idea that it's a subsidy, right - that it takes a whole megabyte and kind of crunches that down and the computation time stays the same but maybe the cost is lesser - do you kind of share his view on that or what are your concerns with it?
Daniel: 0:41:34.01,0:43:38.41
Can I say one or two things about this – there’s different ways to look at that, right. I'm an engineer - my specialization is software, so the economics of it I hear different opinions. I trust some more than others but I am NOT an economist. I kind of agree with the ones with my limited expertise on that it's a subsidy it looks very much like it to me, but yeah that's not my area. What I can talk about is the software - so adding DSV adds really quite a lot of complexity to the code right, and it's a big change to add that. And what are we going to do - every time someone comes up with an idea we’re going to add a new opcode? How many opcodes are we going to add? I saw reports that Jihan was talking about hundreds of opcodes or something like that and it's like how big is this client going to become - how big is this node - is it going to have to handle every kind of weird opcode that that's out there? The software is just going to get unmanageable and DSV - that was my main consideration at the beginning was the, you know, if you can implement it in script you should do it, because that way it keeps the node software simple, it keeps it stable, and you know it's easier to test that it works properly and correctly. It's almost like adding (?) code from a microprocessor you know why would you do that if you can if you can implement it already in the script that is there.
Steve: 0:43:36.16,0:46:09.71
It’s actually an interesting inconsistency because when we were talking about adding the opcodes in May, the philosophy that seemed to drive the decisions that we were able to form a consensus around was to simplify and keep the opcodes as minimal as possible (ie where you could replicate a function by using a couple of primitive opcodes in combination, that was preferable to adding a new opcode that replaced) OP_SUBSTR is an interesting example - it's a combination of SPLIT, and SWAP and DROP opcodes to achieve it. So at really primitive script level we've got this philosophy of let's keep it minimal and at this sort of (?) philosophy it’s all let's just add a new opcode for every primitive function and Daniel's right - it's a question of opening the floodgates. Where does it end? If we're just going to go down this road, it almost opens up the argument why have a scripting language at all? Why not just add a hard code all of these functions in one at a time? You know, pay to public key hash is a well-known construct (?) and not bother executing a script at all but once we've done that we take away with all of the flexibility for people to innovate, so it's a philosophical difference, I think, but I think it's one where the position of keeping it simple does make sense. All of the primitives are there to do what people need to do. The things that people don't feel like they can't do are because of the limits that exist. If we had no opcode limit at all, if you could make a gigabyte transaction so a gigabyte script, then you can do any kind of crypto that you wanted even with 32-bit integer operations, Once you get rid of the 32-bit limit of course, a lot of those a lot of those scripts come up a lot smaller, so a Rabin signature script shrinks from 100MB to a couple hundred bytes.
Daniel: 0:46:06.77,0:47:36.65
I lost a good six months of my life diving into script, right. Once you start getting into the language and what it can do, it is really pretty impressive how much you can achieve within script. Bitcoin was designed, was released originally, with script. I mean it didn't have to be – it could just be instead of having a transaction with script you could have accounts and you could say trust, you know, so many BTC from this public key to this one - but that's not the way it was done. It was done using script, and script provides so many capabilities if you start exploring it properly. If you start really digging into what it can do, yeah, it's really amazing what you can do with script. I'm really looking forward to seeing some some very interesting applications from that. I mean it was Awemany his zero-conf script was really interesting, right. I mean it relies on DSV which is a problem (and some other things that I don't like about it), but him diving in and using script to solve this problem was really cool, it was really good to see that.
Steve: 0:47:32.78,0:48:16.44
I asked a question to a couple of people in our research team that have been working on the Rabin signature stuff this morning actually and I wasn't sure where they are up to with this, but they're actually working on a proof of concept (which I believe is pretty close to done) which is a Rabin signature script - it will use smaller signatures so that it can fit within the current limits, but it will be, you know, effectively the same algorithm (as DSV) so I can't give you an exact date on when that will happen, but it looks like we'll have a Rabin signature in the blockchain soon (a mini-Rabin signature).
Cory: 0:48:13.61,0:48:57.63
Based on your responses I think I kinda already know the answer to this question, but there's a lot of questions about ending experimentation on Bitcoin. I was gonna kind of turn that into – with the plan that Bitcoin SV is on do you guys see like a potential one final release, you know that there's gonna be no new opcodes ever released (like maybe five years down the road we just solidify the base protocol and move forward with that) or are you guys more on the idea of being open-ended with appropriate testing that we can introduce new opcodes under appropriate testing.
Steve: 0:48:55.80,0:49:47.43
I think you've got a factor in what I said before about the philosophical differences. I think new functionality can be introduced just fine. Having said that - yes there is a place for new opcodes but it's probably a limited place and in my opinion the cryptographic primitive functions for example CHECKSIG uses ECDSA with a specific elliptic curve, hash 256 uses SHA256 - at some point in the future those are going to no longer be as secure as we would like them to be and we'll replace them with different hash functions, verification functions, at some point, but I think that's a long way down the track.
Daniel: 0:49:42.47,0:50:30.3
I'd like to see more data too. I'd like to see evidence that these things are needed, and the way I could imagine that happening is that, you know, that with the full scripting language some solution is implemented and we discover that this is really useful, and over a period of, like, you know measured in years not days, we find a lot of transactions are using this feature, then maybe, you know, maybe we should look at introducing an opcode to optimize it, but optimizing before we even know if it's going to be useful, yeah, that's the wrong approach.
Steve: 0:50:28.19,0:51:45.29
I think that optimization is actually going to become an economic decision for the miners. From the miner’s point of view is if it'll make more sense for them to be able to optimize a particular process - does it reduce costs for them such that they can offer a better service to everyone else? Yeah, so ultimately these decisions are going to be miner’s main decisions, not developer decisions. Developers of course can offer their input - I wouldn't expect every miner to be an expert on script, but as we're already seeing miners are actually starting to employ their own developers. I’m not just talking about us - there are other miners in China that I know have got some really bright people on their staff that question and challenge all of the changes - study them and produce their own reports. We've been lucky with actually being able to talk to some of those people and have some really fascinating technical discussions with them.
submitted by The_BCH_Boys to btc [link] [comments]

Instalasi Bitcoin qt dan Setup Testnet Ravencoin Asset Creation on Testnet Apertus 0.3 How to activate the bitcoin core testnet Create A Wallet (Testnet V0.2) Cardano Explorers and Shelley Testnet Stats

A Bitcoin Core instance can be started with the ‘-testnet’ flag to connect to the Testnet blockchain instead of the main blockchain. From an Ubuntu machine: download Bitcoin Core and start with the following commands (check for the latest version): Bitcoin. Omni Layer. Ethereum. Bitcoin Cash. Litecoin. DogeCoin. Dash. Ethereum Classic. Zilliqa. XRP. Blockchains keyboard_arrow_right Bitcoin Omni Layer Ethereum Bitcoin Cash Attention: This is a Testnet! Blockchain Data. Litecoin . Difficulty . Block Height . Total Txs . Market Data. Market Cap . Supply . Volume (24h) Change (1h) Change Bitcoin Testnet Explorer Bitcoin . Bitcoin Testnet Explorer . Apr 7, 2018 DTN Staff. twitter. pinterest. google plus. facebook. Setting Up And Testing Lnd With The Testnet Lightning Faucet The testnet is an alternative Bitcoin block chain, to be used for testing.Testnet coins are separate and distinct from actual bitcoins, and are never supposed to have any value. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain. The Explorer provides block, transaction, and address data for the Bitcoin Cash (BCH) and Bitcoin (BTC) chains. The data is displayed within an. Blockstream Explorer is an open source block explorer providing detailed blockchain data across Bitcoin, Testnet, and Liquid. Supports Tor and tracking- free.

[index] [2635] [9083] [4552] [4744] [14236] [3047] [2540] [828] [4580] [731]

Instalasi Bitcoin qt dan Setup Testnet

Untuk set up bitcoin-qt yang baru diinstal , pastikan ia dapat berjalan di testnet. Caranya, edit dit berkaspada direktori “~/.bitcoin” yang bernama “bitcoin.conf” Subscribe chanel saya ... How to Setup a Electrum Bitcoin Wallet on Testnet & Free Bitcoin Faucet PIAIC Description: Electrum Wallet Download : Free T... Buy Bitcoin with your credit card here: Secure your Bitcoin with the Ledger Nano S Hardware Wallet: Buy Sell and Trade Crypto Currencies at Creating a Local Bitcoin Testnet / Regtest - Programming Bitcoin - Duration: ... Fast Bitcoin miner. How to download and start mining. - Duration: 4:59. ... Crypto Explorer 42,837 views. Use Cardano ADA Testnet Wallets to Claim Real Rewards on Incentivized Cardano ... Binance Cloud, Bitcoin Is The New Gold! - Duration: 10:38. Kaizen Crypto 725 views. 10:38. Shelley Testnet is Fast ...