Exchange | Batching Status | Segwit (p2sh) | Send to bech32 |
---|---|---|---|
Binance | Yes | No | No |
Bitfinex | Yes | No | No |
Bitonic | ? | No | No |
Bitstamp | Yes | Yes | No |
Bittrex | Yes | ? | ? |
Coinbase/GDAX | No | No | No |
Gemini | No | No | No |
HitBTC | Yes | Yes | ? |
Huboi | ? | ? | ? |
Kraken | No | Yes | ? |
LocalBitcoins | No | ? | ? |
OKEx | ? | ? | ? |
Poloniex | ? | Yes | ? |
QuadrigaCX | Yes | Yes | ? |
Shapeshift | Yes | No | No |
SegWit Enabled Wallets | Wallet Type |
---|---|
Ledger Nano S | Hardware |
Trezor | Hardware |
Electrum | Desktop |
Armory | Desktop |
Edge | iOS |
GreenAddress | iOS |
BitWallet | iOS |
Samourai | Android |
GreenBits | Android |
Electrum | Android |
Non-Segwit Transactions | ||
---|---|---|
non-Segwit address | to… | |
non-Segwit address | OK | |
3..... (Segwit) | OK | |
bc1.... (Segwit) | No (no support for them yet) | |
Segwit Transactions | ||
3... address (Segwit) | to… | |
non-Segwit address | OK | |
3..... (Segwit) | OK | |
bc1.... (Segwit) | No (no support for them yet) | |
bc1... address (Segwit) | to… | |
non-Segwit address | OK | |
3..... (Segwit) | OK | |
bc1.... (Segwit) | OK |
![]() | submitted by benohanlon to komodoplatform [link] [comments] https://preview.redd.it/0yq7rwnkjdq11.png?width=1500&format=png&auto=webp&s=950dd49d7e1f7f1e421f7074bd030aec064e6ac7 A total prize pool of 7,000 KMD in our infographic contest Calling all creatives to take part in our infographic contest and compete for a prize of 7,000 KMD. The winning infographic will explain the architecture of Komodo Platform’s technology. Winners will be those who are able to communicate our architecture and tech visually. This contest will run primarily on Reddit, with the exception of resources being posted to Medium and a master twitter thread for submissions on Twitter. You'll find links at the bottom of this post. Prizes for winning infographics.Are you a creative designer? Here's what you can win…
Prizes for sharing and giving feedback!Not a designer? That's OK. You can still participate and win! We'll award five lucky winners 100 KMD each for sharing and promoting the contest. Winners will be picked in a raffle. If you'd like to take part click here https://gleam.io/MwMtO/komodos-20-infographic-contest-5000-kmd-grand-prize and share this post with your friends.Your Goals
Our Criteria to JudgePlease note that upvotes and shares are not the only criteria we'll use to judge winners. While useful, we will value creativity, good questions and discussion on Reddit highly. When sharing your posts you will score more highly if people comment, provide feedback and are engaged.
How do you win?You may submit up to two infographics. By submitting an infographic, you understand Komodo may post and use your submissions on our digital channels during and after the contest. Each infographic must have it's own post.
Contest Timeline Guide (these dates indicative and are subject to change).
ResourcesIf you need help please post in this thread, or email [[email protected]](mailto:[email protected]) with ‘Infographic Contest’ in the subject line.
Entries and submissions for the infographic contest. You can click here to see them all in a scrollable thread on Twitter.
25/09/18 - First Round of FeedbackInfographics should use graphical design elements to visually represent the Komodo Architecture Story found here: https://komodoplatform.com/komodo-platform-a-brief-overview/ included in our ‘required reading’. There’s also a bullet point aid: https://medium.com/@benohanlon/bullet-point-aid-to-help-you-the-history-of-komodos-architecture-dced35b29965 you may find useful.
If you’ve not been included in the first round it’s because the submission hadn’t been made when the team reviewed. Don’t worry though because we’re organising hangouts and further feedback to help.
We hosted a round of live feedback sessions via Zoom. The recording is here:https://soundcloud.com/blockchainists/zoom-call-first-round-of-feedback-for-komodos-infographic-contest#t=3:50TimelineThe first block in the KMD blockchain was mined just under two years ago, on September 13, 2016 to 9:04 PM. Since then, Komodo has demonstrated a commitment to innovation and established a history of execution.
Achievements
If you would like to update your post, please edit and add to the post so people can see the different iterations. Entries and submissions for the infographic contest. You can click here to see them all in a scrollable thread on Twitter. |
Exchange | Segwit Status | Batching Status |
---|---|---|
Binance | NOT READY | Yes |
Bitfinex | Ready | ? |
Bitonic | Ready | |
Bitstamp | Deployed | Yes |
Bittrex | ? | Yes |
Coinbase/GDAX | NOT READY | No |
Gemini | Ready | No |
HitBTC | Deployed | Yes |
Huboi | ? | ? |
Kraken | Ready | Yes |
LocalBitcoins | Ready | ? |
OKEx | ? | ? |
Poloniex | ? | Yes |
QuadrigaCX | Deployed | Yes |
Shapeshift | Deployed | No |
SegWit Enabled Wallets | Wallet Type |
---|---|
Ledger Nano S | Hardware |
Trezor | Hardware |
Electrum | Desktop |
Armory | Desktop |
Edge | iOS |
GreenAddress | iOS |
BitWallet | iOS |
Samourai | Android |
GreenBits | Android |
Electrum | Android |
![]() | Tezos is a decentralized blockchain that simplifies formal verification, a method that mathematically proves the accuracy of the code controlling transactions. The Tezos blockchain has its own cryptocurrency called Tezos (XTZ), a cryptocurrency with two main functions – a self-administration system and the ability to form launch contracts using its own programming language – Michelson. submitted by SimpleSwapExchange to tezos [link] [comments] If you decide to convert your fiat savings into Tezos or exchange other cryptocurrencies for XTZ, you may have to make a choice among reliable wallets for this. In this article we will look into the best Tezos Wallets so that can help you understand them better. Hardware WalletsHardware wallets are not liable to spam, viruses, phishing attacks, or malicious of the system. Moreover, they provide a high degree of protection to the private keys. Below is the list of hardware wallets that can be used for XTZ.https://preview.redd.it/j79t9vbgeth31.jpg?width=800&format=pjpg&auto=webp&s=d828387479fc4a2efed4fc857eb9bdf03f9878e9
Web WalletsWeb wallets can be a simple way to get started investing in cryptocurrency. All web wallets can be used right from a browser without the need of downloading software. Beyond that, many of web wallets offer free mobile apps.
https://preview.redd.it/zmnx9fwpeth31.png?width=1696&format=png&auto=webp&s=d926f570fb736dd6fcd338fae270cdcfebad9654
Mobile WalletsMobile wallets are used on your smartphone via an app. Similar to Apple or Google Pay, you can use mobile wallets when shopping in physical shops as cryptocurrencies become more popular and acceptable. Mobile wallets may be safer compared to online wallets and also be easy to use on the go.
https://preview.redd.it/ckrma5aueth31.png?width=1400&format=png&auto=webp&s=f37213bf83c82028b97837545536c353664a8368
Desktop WalletsDesktop wallet can be downloaded and installed on a computer. Desktop wallets may be safer if your computer is not, or more preferably, has never used the Internet connection. Desktop Wallets are perfect for storing large amounts of crypto that you don’t want to use on an everyday basis.
https://preview.redd.it/apv4gpe0fth31.png?width=1686&format=png&auto=webp&s=dc5602c0eda220594b427c0b42923b8bacd727ae
How to keep your wallet safeA cryptocurrency wallet can be regarded as a regular wallet with money, but it has advanced features, which increases the level of risk. Simple rules will help prevent the loss of your own savings:
Feel free to follow our updates and news on Twitter, Facebook, Telegram and BitcoinTalk. Read what the customers say about SimpleSwap on Trustpilot. Don’t hesitate to contact us with any questions you may have via [[email protected]](mailto:[email protected]). |
Exchange | Segwit Status | Batching Status |
---|---|---|
Binance | NOT READY | Yes |
Bitfinex | Ready | Yes |
Bitonic | Ready | Yes |
Bitstamp | Deployed | Yes |
Bittrex | ? | Yes |
Coinbase/GDAX | NOT READY | No |
Gemini | Ready | No |
HitBTC | Deployed | Yes |
Huboi | ? | ? |
Kraken | Deployed | Yes |
LocalBitcoins | Deployed | Yes |
OKEx | ? | ? |
Poloniex | ? | Yes |
QuadrigaCX | Deployed | Yes |
Shapeshift | Deployed | No |
SegWit Enabled Wallets | Wallet Type |
---|---|
Ledger Nano S | Hardware |
Trezor | Hardware |
Electrum | Desktop |
Armory | Desktop |
Edge | iOS |
GreenAddress | iOS |
BitWallet | iOS |
Samourai | Android |
GreenBits | Android |
Electrum | Android |
SegWitAddress.org | Paper |
No, just get ready now so that your NEXT transaction will be to a SegWit wallet. Avoid burdening the network with any unnecessary transactions for now.
SegWit will require some extra work to be done right and securely. Also, most exchanges let the user pay the fee, and up to now users have not been overly concerned about fees so for some exchanges it hasn't been a priority.
Times stay the same - fees will go down. How much and for how long depends on what the demand for transactions will be at that time.
Fees are charged per byte of data and are bid up by users. Miners will typically include the transaction with the highest fee/byte first.
The Bitcoin core wallet does not yet have a GUI for its SegWit functionality. Download the latest version of Electrum to generate a SegWit address.
A transaction between two SegWit addresses is a SegWit transaction.
A transaction sent from a SegWit address to a non-SegWit address is a SegWit transaction.
A transaction sent from a non-SegWit address to a SegWit address is NOT a SegWit transaction. You can send a SegWit Tx if the sending address is a SegWit address.
Source: HowToToken
Using Electrum, the "Tools" menu option: "Pay to many".
Just enter your receive addresses and the amounts for each, and you can send multiple transactions for nearly the price of one.
The Core Wallet supports SegWit, but its GUI doesn't. The next update will likely have GUI support built-in
Draw your own conclusions based on their own words:
March 2016 - Coinbase CEO Brian Armstrong has reservations about Core
Dec 2017 - Coinbase is STILL working on Segwit
It's been a challenge for wallet developers to implement SegWit in a way that users can easily and without too much disruption migrate from legacy to SegWit addresses. The first wallets to enable SegWit addresses – Ledger, Trezor, Core, GreenAddress – use so-called “nested P2SH addresses.” This means they take the existing Pay 2 Script Hash address – starting with a “3” – and put a SegWit address into it. This enables a high grade of compatibility to exist wallets as every wallet is familiar with these addresses, but it is a workaround which results in SegWit transactions needing around 10 percent more space than they otherwise would.
Electrum 3.0 was the first wallet to use bech32 addresses instead of nested p2sh addresses.
Source: BTCManager.com
P2SH starts with "3..."
bech32 starts with "bc1..."
P2SH Segwit addresses can be sent to using older Bitcoin software with no Segwit support. This supports backward compatibility
bech32 can only be sent to from newer Bitcoin software that support bech32. Ex: Electrum
Source: BitcoinTalk.org
The address starting with a "3..." is a P2SH SegWit address that can be sent BTC from any bitcoin address including a legacy address. The address starting with a "bc1..." is a bech32 SegWit address that can only be sent to from newer wallets that support bech32.
Exchange | Segwit Status | Batching Status |
---|---|---|
Binance | Yes | |
Bitfinex | Ready | ? |
Bitonic | Ready | ? |
Bitstamp | Deployed | Yes |
Bittrex | ? | Yes |
Coinbase/GDAX | NOT READY | No |
Gemini | Ready | No |
HitBTC | Yes | |
Huboi | ? | ? |
Kraken | Ready | Yes |
LocalBitcoins | Ready | ? |
OKEx | ? | ? |
Poloniex | ? | Yes |
QuadrigaCX | Deployed | Yes |
Shapeshift | Deployed | No |
SegWit Enabled Wallets | Wallet Type |
---|---|
Ledger Nano S | Hardware |
Trezor | Hardware |
Electrum | Desktop |
Armory | Desktop |
Edge | iOS |
GreenAddress | iOS |
BitWallet | iOS |
Samourai | Android |
GreenBits | Android |
Electrum | Android |
Exchange | Segwit Status | Batching Status |
---|---|---|
Binance | NOT READY | Yes |
Bitfinex | Ready | Yes |
Bitonic | Ready | Yes |
Bitstamp | Deployed | Yes |
Bittrex | ? | Yes |
Coinbase/GDAX | NOT READY | No |
Gemini | Ready | No |
HitBTC | Deployed | Yes |
Huboi | ? | ? |
Kraken | Deployed | Yes |
LocalBitcoins | Deployed | Yes |
OKEx | ? | ? |
Poloniex | ? | Yes |
QuadrigaCX | Deployed | Yes |
Shapeshift | Deployed | No |
SegWit Enabled Wallets | Wallet Type |
---|---|
Ledger Nano S | Hardware |
Trezor | Hardware |
Electrum | Desktop |
Armory | Desktop |
Edge | iOS |
GreenAddress | iOS |
BitWallet | iOS |
Samourai | Android |
GreenBits | Android |
Electrum | Android |
SegWitAddress.org | Paper |
No, just get ready now so that your NEXT transaction will be to a SegWit wallet. Avoid burdening the network with any unnecessary transactions for now.
SegWit will require some extra work to be done right and securely. Also, most exchanges let the user pay the fee, and up to now users have not been overly concerned about fees so for some exchanges it hasn't been a priority.
Times stay the same - fees will go down. How much and for how long depends on what the demand for transactions will be at that time.
Fees are charged per byte of data and are bid up by users. Miners will typically include the transaction with the highest fee/byte first.
The Bitcoin core wallet does not yet have a GUI for its SegWit functionality. Download the latest version of Electrum to generate a SegWit address.
A transaction between two SegWit addresses is a SegWit transaction.
A transaction sent from a SegWit address to a non-SegWit address is a SegWit transaction.
A transaction sent from a non-SegWit address to a SegWit address is NOT a SegWit transaction. You can send a SegWit Tx if the sending address is a SegWit address.
Source: HowToToken
Using Electrum, the "Tools" menu option: "Pay to many".
Just enter your receive addresses and the amounts for each, and you can send multiple transactions for nearly the price of one.
The Core Wallet supports SegWit, but its GUI doesn't. The next update will likely have GUI support built-in
Draw your own conclusions based on their own words:
March 2016 - Coinbase CEO Brian Armstrong has reservations about Core
Dec 2017 - Coinbase is STILL working on Segwit
It's been a challenge for wallet developers to implement SegWit in a way that users can easily and without too much disruption migrate from legacy to SegWit addresses. The first wallets to enable SegWit addresses – Ledger, Trezor, Core, GreenAddress – use so-called “nested P2SH addresses.” This means they take the existing Pay 2 Script Hash address – starting with a “3” – and put a SegWit address into it. This enables a high grade of compatibility to exist wallets as every wallet is familiar with these addresses, but it is a workaround which results in SegWit transactions needing around 10 percent more space than they otherwise would.
Electrum 3.0 was the first wallet to use bech32 addresses instead of nested p2sh addresses.
Source: BTCManager.com
P2SH starts with "3..."
bech32 starts with "bc1..."
P2SH Segwit addresses can be sent to using older Bitcoin software with no Segwit support. This supports backward compatibility
bech32 can only be sent to from newer Bitcoin software that support bech32. Ex: Electrum
Source: BitcoinTalk.org
The address starting with a "3..." is a P2SH SegWit address that can be sent BTC from any bitcoin address including a legacy address. The address starting with a "bc1..." is a bech32 SegWit address that can only be sent to from newer wallets that support bech32.
Exchange | Segwit Status | Batching Status |
---|---|---|
Binance | NOT READY | Yes |
Bitfinex | Ready | Yes |
Bitonic | Ready | Yes |
Bitstamp | Deployed | Yes |
Bittrex | ? | Yes |
Coinbase/GDAX | NOT READY | No |
Gemini | Ready | No |
HitBTC | Deployed | Yes |
Huboi | ? | ? |
Kraken | Deployed | Yes |
LocalBitcoins | Ready | Yes |
OKEx | ? | ? |
Poloniex | ? | Yes |
QuadrigaCX | Deployed | Yes |
Shapeshift | Deployed | No |
SegWit Enabled Wallets | Wallet Type |
---|---|
Ledger Nano S | Hardware |
Trezor | Hardware |
Electrum | Desktop |
Armory | Desktop |
Edge | iOS |
GreenAddress | iOS |
BitWallet | iOS |
Samourai | Android |
GreenBits | Android |
Electrum | Android |
SegWitAddress.org | Paper |
claimAll will not work for most users. When you get to the claim step, please use the following tutorial: https://steemit.com/eos/@koyn/minimizing-the-cost-of-gas-when-claiming-eos-using-myetherwallet
REMEMBER YOU ONLY NEED TO REGISTER YOUR TOKENS IF YOU BOUGHT THEM ON AN EXCHANGE. YOU DON'T NEED TO CLAIM THEM.
So PLEASE REGISTER your Ethereum address NOW, don't forget about it, or plan on doing it some time in the near future.
- Go to the EOS website https://eos.io
- Scroll down and select "GET EOS"
- Tick all the required boxes and click "Continue"
- Scroll down and click "Register"
- Select Metamask, MyEtherWallet, or Ethereum Wallet
- Follow the guide.
- Remember that the reason you need to register your Ethereum ERC-20 address is to include your EOS tokens in order for the balance of your EOS Tokens to be included in the Snapshot if a Snapshot is created, you must register your Ethereum address with an EOS public key. The EOS snapshot will take place prior to the 1 June 2018. After this point your ERC-20 EOS tokens will be frozen. And you will be issued EOS tokens on the EOS blockchain.
“EOS.IO software utilizes the only known decentralized consensus algorithm proven capable of meeting the performance requirements of applications on the blockchain, Delegated Proof of Stake (DPOS). Under this algorithm, those who hold tokens on a blockchain adopting the EOS.IO software may select block producers through a continuous approval voting system. Anyone may choose to participate in block production and will be given an opportunity to produce blocks, provided they can persuade token holders to vote for them.
The EOS.IO software enables blocks to be produced exactly every 0.5 second and exactly one producer is authorized to produce a block at any given point in time. If the block is not produced at the scheduled time, then the block for that time slot is skipped. When one or more blocks are skipped, there is a 0.5 or more second gap in the blockchain.
Using the EOS.IO software, blocks are produced in rounds of 126 (6 blocks each, times 21 producers). At the start of each round 21 unique block producers are chosen by preference of votes cast by token holders. The selected producers are scheduled in an order agreed upon by 15 or more producers.
Byzantine Fault Tolerance is added to traditional DPOS by allowing all producers to sign all blocks so long as no producer signs two blocks with the same timestamp or the same block height. Once 15 producers have signed a block the block is deemed irreversible. Any byzantine producer would have to generate cryptographic evidence of their treason by signing two blocks with the same timestamp or blockheight. Under this model a irreversible consensus should be reachable within 1 second."
"The EOS Tokens do not have any rights, uses, purpose, attributes, functionalities or features, express or implied, including, without limitation, any uses, purpose, attributes, functionalities or features on the EOS Platform."
"In sum, Defendants capitalized on the recent enthusiasm for blockchain technology and cryptocurrencies to raise funds through the ICO, illegally sold unqualified and unregistered securities, used a Swiss-based entity in an unsuccessful attempt to evade U.S. securities laws, and are now admittedly engaged in the conversion, selling, and possible dissipation of the proceeds that they collected from the Class through their unregistered offering."To ensure EOS tokens are not classed as a unregistered security block.one has made it clear that they are creating the EOS software only and won’t launching a public blockchain themselves. This task is left down to the community, or more precisely, the Block Producers (BPs). The following disclaimer is seen after posts from block.one:
"block.one is a software company and is producing the EOS.IO software as free, open source software. This software may enable those who deploy it to launch a blockchain or decentralized applications with the features described above. block.one will not be launching a public blockchain based on the EOS.IO software. It will be the sole responsibility of third parties and the community and those who wish to become block producers to implement the features and/or provide the services described above as they see fit. block.one does not guarantee that anyone will implement such features or provide such services or that the EOS.IO software will be adopted and deployed in any way.”It is expected that many blockchains using eos.io software will emerge. To ensure DAPPs are created on an ecosystem that aligns with the interests of block.one a $1bn fund will be has been created to incentivise projects to use this blockchain.
“A lot of token distributions only allow a small amount of people to participate. The EOS Token distribution structure was created to provide a sufficient period of time for people to participate if they so choose, as well as give people the opportunity to see the development of the EOS.IO Software prior to making a decision to purchase EOS Tokens.”
“block.one intends to engage an independent third party auditor who will release an independent audit report providing further assurances that block.one has not purchased EOS Tokens during the EOS Token distribution period or traded EOS Tokens (including using proceeds from the EOS Token distribution for these purposes). This report will be made available to the public on the eos.io website.”
"DDoS'ing a block producing is not as simple as knowing their IP address and hitting "go". We have distributed systems engineers in each of our candidate groups that have worked to defend DDoS systems in their careers. Infrastructure can be built in a way to minimize the exposure of the Block Producing node itself and to prevent a DDoS attack. We haven't published our full architecture yet but let's take a look at fellow candidate EOSphere to see what we mean. As for the launch of the network, we are assuming there will be attacks on the network as we launch. It is being built into the network launch plans. I will reach out to our engineers to get a more detailed answer for you. What also must be considered is that there will be 121 total producing and non-producing nodes on the network. To DDoS all 121 which are located all around the world with different security configurations at the exact same time would be a monumental achievement."
"The only way to maintain the integrity of a community is for the community to have control over its own composition. This means that open-entry systems built around anonymous participation will have no means expelling bad actors and will eventually succumb to profit-driven corruption. You cannot use stake as a proxy for goodness whether that stake is held in a bond or a shareholder’s vote. Goodness is subjective and it is up to each community to define what values they hold as good and to actively expel people they hold has bad.
The community I want to participate in will expel the rent-seeking vote-buyers and reward those who use their elected broadcasting power for the benefit of all community members rather than special interest groups (such as vote-buyers). I have faith that such a community will be far more competitive in a market competition for mindshare than one that elects vote buyers."
Dev meeting? Would say so, yes The people are still exhausted from the payment ID meeting :) Guess we could ping some people vtnerd, moneromooo, hyc, gingeropolous, TheCharlatan, sarang, suraeNoether, jtgrassie Anyone up for a meeting? Yep I'm here Here o/ Perhaps we should just start and people will eventually hop in? oof sorry guys, I'm working on the new FFS and I forgot all about this. Got a couple of new volunteers. This literally might be able to launch tomorrow. I know that. It's called "flow" :) I could run if you're out of time? go for it dEBRUYNE you guys are going to like this new FFS. We're like 99% done. Hi rehrar: someone else do the milestone thing already? All right, jtgrassie, perhaps you'd to start w/ briefly describing your most recent PR? https://github.com/monero-project/monero/pull/5091 oneiric, xiphon did everything like....everything As far as I can see, it allows the user to push his transaction over I2P, thereby masking the origin IP of the sendeuser great And it hooks into vtnerd's PR right? Sure. It basically just builds on vtnerds Tor stuff. sorry dEBRUYNE Really not much added. I have it running and tested. From the perspective of the user, what needs to be configured exactly? Nice Assuming the PR is included in the release binaries I'm using knacccs i2p-zero duirng testing but will of course work with any i2p setup sorry dEBRUYNE <= Np Looks a little like dams breaking, now that we have some dark clouds over Kovri and people take matters into their own hands ... User needs to run i2p, expose a socks service and and inbound tunnel. Basically same as Tor Okay, so should be reasonable as long as we write proper documentation for it (e.g. an elaborate guide) rbrunner, yes, knaccc credit for jumping on i2p-zero really dEBRUYNE: documentation monero side is kindof done. i2p side is very much implementation specific. I suppose we could write some guides for the most popular implementations? e.g. i2p-zero aims to be zero conf, but i2pd or Kovri would be differnet. I see, great vtnerd___: Do you want to add anything? could amend the current kovri guide for monero use from --exclusive-peer to the new proxy support Now I have i2p-zero running and tested with the #5091, I plan to jump back over to helping knaccc on getting that polished. I added support for socks proxy in the basic wallets ^ excellent Yes vtnerd___ I havent tested it yet but looks sweet. So connections to `monerod` over Toi2p are possible within wallet cli and wallet rpc Awesome This also implies auth+encryption even if ssl is not in use (when using an onion or i2p address) All right moneromooo: are you here? If so, could you perhaps share what you've been working on? I am. I revived the SSL PR, more stuff on multi sender txes, an implementation of ArticMine's new block size algorithm. I presume a multi sender tx works similar to multisig insofar as the senders have to exchange data before the transaction can be performed right? Yes. There are 2 SSL PRs. What's the diff? Theoretically this would also allow the sender to provide an output right? Which would be kind of similar to Bitcoin's P2EP The second one adds some things like selecting a cert by fingerprint. Yes. (for the first sentence) All right, awesome For anyone reading, this breaks the assumption of the inputs belonging to a single sender, which makes analysis more difficult Nice side-effect. Much work coming for the various wallets to support that rbrunner: Anything you'd like to share in the meeting btw? Yes, just a little info I have started to seriously investigate what it would mean to integrate Monero into OpenBazaar I have already talked with 2 of their devs, was very interesting In maybe 2 or 3 weeks I intend to write a report Too early to tell much more :) Soon^tm I guess :) Yep Currently wrestling with Go debugging whole new world moneromooo: Has pony recently shared any insights regarding the upcoming 0.14 release btw? No. All right I would love to see the tor & i2p PR's merged sooner rather than later so we can get more testing done. ^ +1 Isn't that famous early code freeze already on the horizon? fluffypony, luigi1111 ^ I suppose I could provide a little update regarding the GUI btw As always, lots of bug fixes and improvements :-P selsta has recently added a feature to support multi accounts dsc_ has revamped the wizard and will now start working on implementing the different modes and a white theme dsc_ is working fulltime on the GUI already? yes :) dsc_ is bae In light of the recent payment ID discussion, we've also, by default, disabled the option to add a payment ID unless the user explicitely activates the option on the settings page rehrar ^ nice I spoke about this yesterday at the coffee chat, this is not a good decision. How does it handle integrated addresses? The same way? rehrar ? For the next many months, we are still stuck with PAyment IDs in the ecosystem. Making it harder for people to access them will make Monero suck so hard to use for the average person for many months. i agree with rehrar Remove the option of Payment IDs when we remove Payment IDs rehrar: The new GUI release won't be live until probably mid march though Which is a few weeks in advance of the scheduled protocol upgrade Payment ID removal comes in October right, but Payment IDs are not removed in March Did we not have loose consensus on removing the old, unencrypted payment IDs in march? they are removed in October We had discussed a deprecation in March and a ban in October ok, then if we are going to do that, we have to commit to it and contact the exchanges like Binance that use them and get rid of them in the next few months (of unencrypted) Binance is huge, and if they still use them, then people will be very upset that they can't deposit or use Payment IDs easily I'm just speaking from a UX perspective. I thought it was unencrypted in April and possibly encrypted in October Yes I do agree Timeline and notes: https://github.com/monero-project/meta/issues/299 impossible to remove them for march, many exchanges still use them We can defer it to the 0.15 release if needed Well, that wasn't the impression for them log that I just read today This was all discussed in the earlier meeting linked above We have to force the ecosystem off of Payment IDs before we remove them from the UI, is all I'm saying Remove != make difficult to use ... or make them more difficult there, right? ping sgp_ sarang, I understand, and I agreed with you during that meeting. But then I started thinking of it as a UX person, which I am. And that huge massive problem leapt out at me i think making them difficult to generate is a good idea but making them difficult to consume and use is a bad idea well, maybe not a good idea, but a better idea ^ If we defer the decision to depriciate long payment IDs to october, won't we have the same issue then? The UI can gave an expandable payment ID field like MyMonero and we can still call it deprecated It is foolhardy to remove an option that the ecosystem uses. So I suggest we keep the Payment ID in the UI until October when they are completely banned. no dEBRYUNE, because they will be banned via consensus sgp_ imo it may be a misdirection of dev resources to add that since things are proceeding in the short term rather than long term but this is a relatively minor point Nothing matters til exchanges change All right The issue is that consensus will still have them in April, and exchanges won't upgrade because they are still allowed. Thus they must still be in the UI. endogenic these changes are already merged in the GUI to hide it like you do ok But when they are banned, exchanges are forced to upgrade or stop using Monero, so we can remove them safely because they won't be in use rehrar: that's a strong assumption sarang that they will upgrade? yes if they don't, then they can't use Monero If exchanges require pid, users need a way to set a pid. Making it hard for the user in the interim is just going to be a nightmare. we have decided to take our "stand" in October A way that is not too hard, then To be clear, we still intend to deprecate long encrypted payment IDs in April right? But no enforcement until October the term "deprecated" doesn't mean much if it's still allowed, and used in popular places yes, as far as I understand it jtgrassie, exactly True I suppose dEBRUYNE: we need to be more specific when talking about deprecation the person who suffers is the user There are two proposals for GUI deprecation: 1. Hide it in the send screen with a simple option to expand (currently merged iirc) 2. Hide it completely in the send screen unless users enable the field in advanced settings (PR'd but not merged yet iirc) What are the arguments for 2? Both are poor options, but 1 is better than 2 by a long shot Well the people who need to be made to "suffer" are the exchanges. And I don't see a way to make exchanges "suffer" other than by having their suffering customers complain to them constantly that they need to update. ^ CLI has something similar where users need to set a manual payment ID transfer mode. Not sure if it's merged yet the way to make the exchanges suffer is when we ban PIDs. They either upgrade or don't use Monero. exact;y Agree with rerahr here have exchanges been provided with clear, practical, sufficient technical upgrade plans for supporting what they're doing with PIDs but with subaddrs? Both are poor options, but 1 is better than 2 by a long shot <= I wouldn't call 1. a poor option. Have you actually checked how it looks? Because it states "Payment ID" and a user has to click on the + to expand the field endogenic: yes the email when out. Blog post coming soon, but contains the same info as the email also the exhcnages' users are often using wallets that don't support subaddresses ok great as well, it should be noted that the timeline for exchanges to upgrade is September, not October when the fork is. Which wallets are that? Rehrar: I don't see option 1. causing any issues/confusion i guess it doesnt matter too much if withdrawing as a personal user the main address should suffice Because September is when the new versions will be coming out without PIDs in the UI If there's opposition to 2, 1 is fine. We can still call it deprecated which is the optics we need anyway exchange users are often just using other exchanges lol. No wallets involved. dsc_ dEBRUYNE, ok, I trust you guys here then rbrunner: i was thinking mymonero last i heard Ok pigeons: rbrunner yes receiving on subaddresses won't be supported yet sending to them has been possible though and yes as learnandlurkin says often they withdraw to other systems like exhcnages that also dont yet support subaddresses I really can't come up with any good argument for 2. right now endogenic: seems not much of an issue then. Exchanges will typically support withdrawals to both subaddresses and plain addresses (especially if we are going to force them to use subaddresses) For deposits, MyMonero works properly if the user sends to a subaddress Actually the second solution was already merged: https://github.com/monero-project/monero-gui/pull/1866 Maybe not enough eyes watching :) The important thing is to have done something to justify having a big "DEPRECATED IN APRIL" stamp on PIDs to spook exchanges in the interim This was for solution 1: https://github.com/monero-project/monero-gui/pull/1855 The Monero Community Workgroup will start making noise everywhere we can to exchanges, and everywhere else that will listen. Try to get on those garbage news sites also. So everyone knows that deprecated in April, and banned in September Hey, for solution 1, write "Payment ID (optional, deprecated)" or similar there rbrunner: noted rehrar: probably wait until the blog post, but it should only be a few days Maybe a Reddit sticky post would be useful? With the blog post If people are over freaking out about the hashrate or terabyte blockchain :) sigh Any questions for the MRL side? Is someone checking ArticMine's block size changes for weird behaviour in some cases etc ? How would such testing work? Private blockchain?