Intro to Multisigs and an Example with Darkcoin/Bitcoin ...

Entertaining example of bitcoin's "fungiblity"(also a reminder of the importance of multisig!)

submitted by Vespco to Monero [link] [comments]

Intro to Multisigs and an Example with Darkcoin/Bitcoin Core

Intro to Multisigs and an Example with Darkcoin/Bitcoin Core submitted by fgumo to DRKCoin [link] [comments]

Intro to Multisigs and an Example with Darkcoin/Bitcoin Core - Let's Talk Bitcoin

Intro to Multisigs and an Example with Darkcoin/Bitcoin Core - Let's Talk Bitcoin submitted by fgumo to Bitcoin [link] [comments]

Proposal: The Sia Foundation

Vision Statement

A common sentiment is brewing online; a shared desire for the internet that might have been. After decades of corporate encroachment, you don't need to be a power user to realize that something has gone very wrong.
In the early days of the internet, the future was bright. In that future, when you sent an instant message, it traveled directly to the recipient. When you needed to pay a friend, you announced a transfer of value to their public key. When an app was missing a feature you wanted, you opened up the source code and implemented it. When you took a picture on your phone, it was immediately encrypted and backed up to storage that you controlled. In that future, people would laugh at the idea of having to authenticate themselves to some corporation before doing these things.
What did we get instead? Rather than a network of human-sized communities, we have a handful of enormous commons, each controlled by a faceless corporate entity. Hey user, want to send a message? You can, but we'll store a copy of it indefinitely, unencrypted, for our preference-learning algorithms to pore over; how else could we slap targeted ads on every piece of content you see? Want to pay a friend? You can—in our Monopoly money. Want a new feature? Submit a request to our Support Center and we'll totally maybe think about it. Want to backup a photo? You can—inside our walled garden, which only we (and the NSA, of course) can access. Just be careful what you share, because merely locking you out of your account and deleting all your data is far from the worst thing we could do.
You rationalize this: "MEGACORP would never do such a thing; it would be bad for business." But we all know, at some level, that this state of affairs, this inversion of power, is not merely "unfortunate" or "suboptimal" – No. It is degrading. Even if MEGACORP were purely benevolent, it is degrading that we must ask its permission to talk to our friends; that we must rely on it to safeguard our treasured memories; that our digital lives are completely beholden to those who seek only to extract value from us.
At the root of this issue is the centralization of data. MEGACORP can surveil you—because your emails and video chats flow through their servers. And MEGACORP can control you—because they hold your data hostage. But centralization is a solution to a technical problem: How can we make the user's data accessible from anywhere in the world, on any device? For a long time, no alternative solution to this problem was forthcoming.
Today, thanks to a confluence of established techniques and recent innovations, we have solved the accessibility problem without resorting to centralization. Hashing, encryption, and erasure encoding got us most of the way, but one barrier remained: incentives. How do you incentivize an anonymous stranger to store your data? Earlier protocols like BitTorrent worked around this limitation by relying on altruism, tit-for-tat requirements, or "points" – in other words, nothing you could pay your electric bill with. Finally, in 2009, a solution appeared: Bitcoin. Not long after, Sia was born.
Cryptography has unleashed the latent power of the internet by enabling interactions between mutually-distrustful parties. Sia harnesses this power to turn the cloud storage market into a proper marketplace, where buyers and sellers can transact directly, with no intermediaries, anywhere in the world. No more silos or walled gardens: your data is encrypted, so it can't be spied on, and it's stored on many servers, so no single entity can hold it hostage. Thanks to projects like Sia, the internet is being re-decentralized.
Sia began its life as a startup, which means it has always been subjected to two competing forces: the ideals of its founders, and the profit motive inherent to all businesses. Its founders have taken great pains to never compromise on the former, but this often threatened the company's financial viability. With the establishment of the Sia Foundation, this tension is resolved. The Foundation, freed of the obligation to generate profit, is a pure embodiment of the ideals from which Sia originally sprung.
The goals and responsibilities of the Foundation are numerous: to maintain core Sia protocols and consensus code; to support developers building on top of Sia and its protocols; to promote Sia and facilitate partnerships in other spheres and communities; to ensure that users can easily acquire and safely store siacoins; to develop network scalability solutions; to implement hardforks and lead the community through them; and much more. In a broader sense, its mission is to commoditize data storage, making it cheap, ubiquitous, and accessible to all, without compromising privacy or performance.
Sia is a perfect example of how we can achieve better living through cryptography. We now begin a new chapter in Sia's history. May our stewardship lead it into a bright future.
 

Overview

Today, we are proposing the creation of the Sia Foundation: a new non-profit entity that builds and supports distributed cloud storage infrastructure, with a specific focus on the Sia storage platform. What follows is an informal overview of the Sia Foundation, covering two major topics: how the Foundation will be funded, and what its funds will be used for.

Organizational Structure

The Sia Foundation will be structured as a non-profit entity incorporated in the United States, likely a 501(c)(3) organization or similar. The actions of the Foundation will be constrained by its charter, which formalizes the specific obligations and overall mission outlined in this document. The charter will be updated on an annual basis to reflect the current goals of the Sia community.
The organization will be operated by a board of directors, initially comprising Luke Champine as President and Eddie Wang as Chairman. Luke Champine will be leaving his position at Nebulous to work at the Foundation full-time, and will seek to divest his shares of Nebulous stock along with other potential conflicts of interest. Neither Luke nor Eddie personally own any siafunds or significant quantities of siacoin.

Funding

The primary source of funding for the Foundation will come from a new block subsidy. Following a hardfork, 30 KS per block will be allocated to the "Foundation Fund," continuing in perpetuity. The existing 30 KS per block miner reward is not affected. Additionally, one year's worth of block subsidies (approximately 1.57 GS) will be allocated to the Fund immediately upon activation of the hardfork.
As detailed below, the Foundation will provably burn any coins that it cannot meaningfully spend. As such, the 30 KS subsidy should be viewed as a maximum. This allows the Foundation to grow alongside Sia without requiring additional hardforks.
The Foundation will not be funded to any degree by the possession or sale of siafunds. Siafunds were originally introduced as a means of incentivizing growth, and we still believe in their effectiveness: a siafund holder wants to increase the amount of storage on Sia as much as possible. While the Foundation obviously wants Sia to succeed, its driving force should be its charter. Deriving significant revenue from siafunds would jeopardize the Foundation's impartiality and focus. Ultimately, we want the Foundation to act in the best interests of Sia, not in growing its own budget.

Responsibilities

The Foundation inherits a great number of responsibilities from Nebulous. Each quarter, the Foundation will publish the progress it has made over the past quarter, and list the responsibilities it intends to prioritize over the coming quarter. This will be accompanied by a financial report, detailing each area of expenditure over the past quarter, and forecasting expenditures for the coming quarter. Below, we summarize some of the myriad responsibilities towards which the Foundation is expected to allocate its resources.

Maintain and enhance core Sia software

Arguably, this is the most important responsibility of the Foundation. At the heart of Sia is its consensus algorithm: regardless of other differences, all Sia software must agree upon the content and rules of the blockchain. It is therefore crucial that the algorithm be stewarded by an entity that is accountable to the community, transparent in its decision-making, and has no profit motive or other conflicts of interest.
Accordingly, Sia’s consensus functionality will no longer be directly maintained by Nebulous. Instead, the Foundation will release and maintain an implementation of a "minimal Sia full node," comprising the Sia consensus algorithm and P2P networking code. The source code will be available in a public repository, and signed binaries will be published for each release.
Other parties may use this code to provide alternative full node software. For example, Nebulous may extend the minimal full node with wallet, renter, and host functionality. The source code of any such implementation may be submitted to the Foundation for review. If the code passes review, the Foundation will provide "endorsement signatures" for the commit hash used and for binaries compiled internally by the Foundation. Specifically, these signatures assert that the Foundation believes the software contains no consensus-breaking changes or other modifications to imported Foundation code. Endorsement signatures and Foundation-compiled binaries may be displayed and distributed by the receiving party, along with an appropriate disclaimer.
A minimal full node is not terribly useful on its own; the wallet, renter, host, and other extensions are what make Sia a proper developer platform. Currently, the only implementations of these extensions are maintained by Nebulous. The Foundation will contract Nebulous to ensure that these extensions continue to receive updates and enhancements. Later on, the Foundation intends to develop its own implementations of these extensions and others. As with the minimal node software, these extensions will be open source and available in public repositories for use by any Sia node software.
With the consensus code now managed by the Foundation, the task of implementing and orchestrating hardforks becomes its responsibility as well. When the Foundation determines that a hardfork is necessary (whether through internal discussion or via community petition), a formal proposal will be drafted and submitted for public review, during which arguments for and against the proposal may be submitted to a public repository. During this time, the hardfork code will be implemented, either by Foundation employees or by external contributors working closely with the Foundation. Once the implementation is finished, final arguments will be heard. The Foundation board will then vote whether to accept or reject the proposal, and announce their decision along with appropriate justification. Assuming the proposal was accepted, the Foundation will announce the block height at which the hardfork will activate, and will subsequently release source code and signed binaries that incorporate the hardfork code.
Regardless of the Foundation's decision, it is the community that ultimately determines whether a fork is accepted or rejected – nothing can change that. Foundation node software will never automatically update, so all forks must be explicitly adopted by users. Furthermore, the Foundation will provide replay and wipeout protection for its hard forks, protecting other chains from unintended or malicious reorgs. Similarly, the Foundation will ensure that any file contracts formed prior to a fork activation will continue to be honored on both chains until they expire.
Finally, the Foundation also intends to pursue scalability solutions for the Sia blockchain. In particular, work has already begun on an implementation of Utreexo, which will greatly reduce the space requirements of fully-validating nodes (allowing a full node to be run on a smartphone) while increasing throughput and decreasing initial sync time. A hardfork implementing Utreexo will be submitted to the community as per the process detailed above.
As this is the most important responsibility of the Foundation, it will receive a significant portion of the Foundation’s budget, primarily in the form of developer salaries and contracting agreements.

Support community services

We intend to allocate 25% of the Foundation Fund towards the community. This allocation will be held and disbursed in the form of siacoins, and will pay for grants, bounties, hackathons, and other community-driven endeavours.
Any community-run service, such as a Skynet portal, explorer or web wallet, may apply to have its costs covered by the Foundation. Upon approval, the Foundation will reimburse expenses incurred by the service, subject to the exact terms agreed to. The intent of these grants is not to provide a source of income, but rather to make such services "break even" for their operators, so that members of the community can enrich the Sia ecosystem without worrying about the impact on their own finances.

Ensure easy acquisition and storage of siacoins

Most users will acquire their siacoins via an exchange. The Foundation will provide support to Sia-compatible exchanges, and pursue relevant integrations at its discretion, such as Coinbase's new Rosetta standard. The Foundation may also release DEX software that enables trading cryptocurrencies without the need for a third party. (The Foundation itself will never operate as a money transmitter.)
Increasingly, users are storing their cryptocurrency on hardware wallets. The Foundation will maintain the existing Ledger Nano S integration, and pursue further integrations at its discretion.
Of course, all hardware wallets must be paired with software running on a computer or smartphone, so the Foundation will also develop and/or maintain client-side wallet software, including both full-node wallets and "lite" wallets. Community-operated wallet services, i.e. web wallets, may be funded via grants.
Like core software maintenance, this responsibility will be funded in the form of developer salaries and contracting agreements.

Protect the ecosystem

When it comes to cryptocurrency security, patching software vulnerabilities is table stakes; there are significant legal and social threats that we must be mindful of as well. As such, the Foundation will earmark a portion of its fund to defend the community from legal action. The Foundation will also safeguard the network from 51% attacks and other threats to network security by implementing softforks and/or hardforks where necessary.
The Foundation also intends to assist in the development of a new FOSS software license, and to solicit legal memos on various Sia-related matters, such as hosting in the United States and the EU.
In a broader sense, the establishment of the Foundation makes the ecosystem more robust by transferring core development to a more neutral entity. Thanks to its funding structure, the Foundation will be immune to various forms of pressure that for-profit companies are susceptible to.

Drive adoption of Sia

Although the overriding goal of the Foundation is to make Sia the best platform it can be, all that work will be in vain if no one uses the platform. There are a number of ways the Foundation can promote Sia and get it into the hands of potential users and developers.
In-person conferences are understandably far less popular now, but the Foundation can sponsor and/or participate in virtual conferences. (In-person conferences may be held in the future, permitting circumstances.) Similarly, the Foundation will provide prizes for hackathons, which may be organized by community members, Nebulous, or the Foundation itself. Lastly, partnerships with other companies in the cryptocurrency space—or the cloud storage space—are a great way to increase awareness of Sia. To handle these responsibilities, one of the early priorities of the Foundation will be to hire a marketing director.

Fund Management

The Foundation Fund will be controlled by a multisig address. Each member of the Foundation's board will control one of the signing keys, with the signature threshold to be determined once the final composition of the board is known. (This threshold may also be increased or decreased if the number of board members changes.) Additionally, one timelocked signing key will be controlled by David Vorick. This key will act as a “dead man’s switch,” to be used in the event of an emergency that prevents Foundation board members from reaching the signature threshold. The timelock ensures that this key cannot be used unless the Foundation fails to sign a transaction for several months.
On the 1st of each month, the Foundation will use its keys to transfer all siacoins in the Fund to two new addresses. The first address will be controlled by a high-security hot wallet, and will receive approximately one month's worth of Foundation expenditures. The second address, receiving the remaining siacoins, will be a modified version of the source address: specifically, it will increase the timelock on David Vorick's signing key by one month. Any other changes to the set of signing keys, such as the arrival or departure of board members, will be incorporated into this address as well.
The Foundation Fund is allocated in SC, but many of the Foundation's expenditures must be paid in USD or other fiat currency. Accordingly, the Foundation will convert, at its discretion, a portion of its monthly withdrawals to fiat currency. We expect this conversion to be primarily facilitated by private "OTC" sales to accredited investors. The Foundation currently has no plans to speculate in cryptocurrency or other assets.
Finally, it is important that the Foundation adds value to the Sia platform well in excess of the inflation introduced by the block subsidy. For this reason, the Foundation intends to provably burn, on a quarterly basis, any coins that it cannot allocate towards any justifiable expense. In other words, coins will be burned whenever doing so provides greater value to the platform than any other use. Furthermore, the Foundation will cap its SC treasury at 5% of the total supply, and will cap its USD treasury at 4 years’ worth of predicted expenses.
 
Addendum: Hardfork Timeline
We would like to see this proposal finalized and accepted by the community no later than September 30th. A new version of siad, implementing the hardfork, will be released no later than October 15th. The hardfork will activate at block 293220, which is expected to occur around 12pm EST on January 1st, 2021.
 
Addendum: Inflation specifics
The total supply of siacoins as of January 1st, 2021 will be approximately 45.243 GS. The initial subsidy of 1.57 GS thus increases the supply by 3.47%, and the total annual inflation in 2021 will be at most 10.4% (if zero coins are burned). In 2022, total annual inflation will be at most 6.28%, and will steadily decrease in subsequent years.
 

Conclusion

We see the establishment of the Foundation as an important step in the maturation of the Sia project. It provides the ecosystem with a sustainable source of funding that can be exclusively directed towards achieving Sia's ambitious goals. Compared to other projects with far deeper pockets, Sia has always punched above its weight; once we're on equal footing, there's no telling what we'll be able to achieve.
Nevertheless, we do not propose this change lightly, and have taken pains to ensure that the Foundation will act in accordance with the ideals that this community shares. It will operate transparently, keep inflation to a minimum, and respect the user's fundamental role in decentralized systems. We hope that everyone in the community will consider this proposal carefully, and look forward to a productive discussion.
submitted by lukechampine to siacoin [link] [comments]

Thought Experiment: Post-Hyperbitcoinization Sudden Quantitative Tightening

Imagine a post-hyperbitcoinization world where all capital and labor is denominated in sats (or milli-sats). There was probably some kind of transitional shock the world went through to get adjusted to the new global monetary system. Virtuous technological deflation becomes the norm, bringing prices down on all assets as capital increases and technology improves. Money printing and monetary policy adjustments are no longer possible. Etc, etc... But let's assume that at some point the global economic system stabilizes in some steady state with its new bitcoin standard monetary system.
Now my thought experiment is:
We know that we can't increase the amount of available bitcoin, but we know it can be decreased (via lost keys). So what happens to the world economy and the world in general if there is a sudden reduction in the amount of available Bitcoin? For example: some major exchange or company with a meaningful amount of the total supply of bitcoin (let's say 5%) in a single multisig wallet actually lost the keys to it?
The price per coin would probably go up and savers would win, as a first order effect, but what are the second order effects? Does the whole economy suffer a sudden wave of deflation? What happens to debts denominated in btc? What happens when thousands upon thousands of debtors are suddenly underwater over night?
submitted by facepalm5000 to Bitcoin [link] [comments]

How to perform strong verification of multisig receive addresses and limit trust in software wallets?

Example scenario: you've set up a 2-of-3 multisig watch only wallet in Electrum or some other desktop wallet, and you use it to generate receive addresses. How do you protect yourself from maliciously generated receive addresses for this wallet, in the case that the desktop software is compromised? How do you validate that the receive addresses are correct and not an attacker's receive address? how do you limit trust of the desktop software wallet?
With typical single-sig P2PKH and P2WPKH the receive addresses can be independently verified to belong to a known xpub key using any bitcoin software library and a small script. Hardware wallets can also be used to generate or verify receive addresses so the software wallet doesn't not need to be trusted. Some hardware wallets also verify the change address for a given transaction also belongs to the xpub key in question.
So how do you do this kind of verification for multisig wallets? Or are people not verifying and instead just trusting that their software wallet of choice is not compromised? I haven't found examples online to do this. It appears that in the Coldcard multisig set up process for a 2-of-3 setup, each device is aware of the other 2 xpubs, so presumably it has the information to perform this kind of verification, but I don't know if it actually does that verification.
submitted by facepalm5000 to Bitcoin [link] [comments]

Technical: Taproot: Why Activate?

This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given public key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

submitted by almkglor to Bitcoin [link] [comments]

Taproot, CoinJoins, and Cross-Input Signature Aggregation

It is a very common misconception that the upcoming Taproot upgrade helps CoinJoin.
TLDR: The upcoming Taproot upgrade does not help equal-valued CoinJoin at all, though it potentially increases the privacy of other protocols, such as the Lightning Network, and escrow contract schemes.
If you want to learn more, read on!

Equal-valued CoinJoins

Let's start with equal-valued CoinJoins, the type JoinMarket and Wasabi use. What happens is that some number of participants agree on some common value all of them use. With JoinMarket the taker defines this value and pays the makers to agree to it, with Wasabi the server defines a value approximately 0.1 BTC.
Then, each participant provides inputs that they unilaterally control, totaling equal or greater than the common value. Typically since each input is unilaterally controlled, each input just requires a singlesig. Each participant also provides up to two addresses they control: one of these will be paid with the common value, while the other will be used for any extra value in the inputs they provided (i.e. the change output).
The participants then make a single transaction that spends all the provided inputs and pays out to the appropriate outputs. The inputs and outputs are shuffled in some secure manner. Then the unsigned transaction is distributed back to all participants.
Finally, each participant checks that the transaction spends the inputs it provided (and more importantly does not spend any other coins it might own that it did not provide for this CoinJoin!) and that the transaction pays out to the appropriate address(es) it controls. Once they have validated the transaction, they ratify it by signing for each of the inputs it provided.
Once every participant has provided signatures for all inputs it registered, the transaction is now completely signed and the CoinJoin transaction is now validly confirmable.
CoinJoin is a very simple and direct privacy boost, it requires no SCRIPTs, needs only singlesig, etc.

Privacy

Let's say we have two participants who have agreed on a common amount of 0.1 BTC. One provides a 0.105 coin as input, the other provides a 0.114 coin as input. This results in a CoinJoin with a 0.105 coin and a 0.114 coin as input, and outputs with 0.1, 0.005, 0.014, and 0.1 BTC.
Now obviously the 0.005 output came from the 0.105 input, and the 0.014 output came from the 0.114 input.
But the two 0.1 BTC outputs cannot be correlated with either input! There is no correlating information, since either output could have come from either input. That is how common CoinJoin implementations like Wasabi and JoinMarket gain privacy.

Banning CoinJoins

Unfortunately, large-scale CoinJoins like that made by Wasabi and JoinMarket are very obvious.
All you have to do is look for a transactions where, say, more than 3 outputs are the same equal value, and the number of inputs is equal or larger than the number of equal-valued outputs. Thus, it is trivial to identify equal-valued CoinJoins made by Wasabi and JoinMarket. You can even trivially differentiate them: Wasabi equal-valued CoinJoins are going to have a hundred or more inputs, with outputs that are in units of approximately 0.1 BTC, while JoinMarket CoinJoins have equal-valued outputs of less than a dozen (between 4 to 6 usually) and with the common value varying wildly from as low as 0.001 BTC to as high as a dozen BTC or more.
This has led to a number of anti-privacy exchanges to refuse to credit custodially-held accounts if the incoming deposit is within a few hops of an equal-valued CoinJoin, usually citing concerns about regulations. Crucially, the exchange continues to hold private keys for those "banned" deposits, and can still spend them, thus this is effectively a theft. If your exchange does this to you, you should report that exchange as stealing money from its customers. Not your keys not your coins.
Thus, CoinJoins represent a privacy tradeoff:

Taproot

Let's now briefly discuss that nice new shiny thing called Taproot.
Taproot includes two components:
This has some nice properties:

Taproot DOES NOT HELP CoinJoin

So let's review!
CoinJoin:
Taproot:
There is absolutely no overlap. Taproot helps things that CoinJoin does not use. CoinJoin uses things that Taproot does not improve.

B-but They Said!!

A lot of early reporting on Taproot claimed that Taproot benefits CoinJoin.
What they are confusing is that earlier drafts of Taproot included a feature called cross-input signature aggregation.
In current Bitcoin, every input, to be spent, has to be signed individually. With cross-input signature aggregation, all inputs that support this feature are signed with a single signature that covers all those inputs. So for example if you would spend two inputs, current Bitcoin requires a signature for each input, but with cross-input signature aggregation you can sign both of them with a single signature. This works even if the inputs have different public keys: two inputs with cross-input signature aggregation effectively define a 2-of-2 public key, and you can only sign for that input if you know the private keys for both inputs, or if you are cooperatively signing with somebody who knows the private key of the other input.
This helps CoinJoin costs. Since CoinJoins will have lots of inputs (each participant will provide at least one, and probably will provide more, and larger participant sets are better for more privacy in CoinJoin), if all of them enabled cross-input signature aggregation, such large CoinJoins can have only a single signature.
This complicates the signing process for CoinJoins (the signers now have to sign cooperatively) but it can be well worth it for the reduced signature size and onchain cost.
But note that the while cross-input signature aggregation improves the cost of CoinJoins, it does not improve the privacy! Equal-valued CoinJoins are still obvious and still readily bannable by privacy-hating exchanges. It does not improve the privacy of CoinJoin. Instead, see https://old.reddit.com/Bitcoin/comments/gqb3udesign_for_a_coinswap_implementation_fo

Why isn't cross-input signature aggregation in?

There's some fairly complex technical reasons why cross-input signature aggregation isn't in right now in the current Taproot proposal.
The primary reason was to reduce the technical complexity of Taproot, in the hope that it would be easier to convince users to activate (while support for Taproot is quite high, developers have become wary of being hopeful that new proposals will ever activate, given the previous difficulties with SegWit).
The main technical complexity here is that it interacts with future ways to extend Bitcoin.
The rest of this writeup assumes you already know about how Bitcoin SCRIPT works. If you don't understand how Bitcoin SCRIPT works at the low-level, then the TLDR is that cross-input signature aggregation complicates how to extend Bitcoin in the future, so it was deferred to let the develoeprs think more about it.
(this is how I understand it; perhaps pwuille or ajtowns can give a better summary.)
In detail, Taproot also introduces OP_SUCCESS opcodes. If you know about the OP_NOP opcodes already defined in current Bitcoin, well, OP_SUCCESS is basically "OP_NOP done right".
Now, OP_NOP is a do-nothing operation. It can be replaced in future versions of Bitcoin by having that operation check some condition, and then fail if the condition is not satisfied. For example, both OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY were previously OP_NOP opcodes. Older nodes will see an OP_CHECKLOCKTIMEVERIFY and think it does nothing, but newer nodes will check if the nLockTime field has a correct specified value, and fail if the condition is not satisfied. Since most of the nodes on the network are using much newer versions of the node software, older nodes are protected from miners who try to misspend any OP_CHECKLOCKTIMEVERIFY/OP_CHECKSEQUENCEVERIFY, and those older nodes will still remain capable of synching with the rest of the network: a dedication to strict backward-compatibility necessary for a consensus system.
Softforks basically mean that a script that passes in the latest version must also be passing in all older versions. A script cannot be passing in newer versions but failing in older versions, because that would kick older nodes off the network (i.e. it would be a hardfork).
But OP_NOP is a very restricted way of adding opcodes. Opcodes that replace OP_NOP can only do one thing: check if some condition is true. They can't push new data on the stack, they can't pop items off the stack. For example, suppose instead of OP_CHECKLOCKTIMEVERIFY, we had added a OP_GETBLOCKHEIGHT opcode. This opcode would push the height of the blockchain on the stack. If this command replaced an older OP_NOP opcode, then a script like OP_GETBLOCKHEIGHT 650000 OP_EQUAL might pass in some future Bitcoin version, but older versions would see OP_NOP 650000 OP_EQUAL, which would fail because OP_EQUAL expects two items on the stack. So older versions will fail a SCRIPT that newer versions will pass, which is a hardfork and thus a backwards incompatibility.
OP_SUCCESS is different. Instead, old nodes, when parsing the SCRIPT, will see OP_SUCCESS, and, without executing the body, will consider the SCRIPT as passing. So, the OP_GETBLOCKHEIGHT 650000 OP_EQUAL example will now work: a future version of Bitcoin might pass it, and existing nodes that don't understand OP_GETBLOCKHEIGHT will se OP_SUCCESS 650000 OP_EQUAL, and will not execute the SCRIPT at all, instead passing it immediately. So a SCRIPT that might pass in newer versions will pass for older versions, which keeps the back-compatibility consensus that a softfork needs.
So how does OP_SUCCESS make things difficult for cross-input signatur aggregation? Well, one of the ways to ask for a signature to be verified is via the opcodes OP_CHECKSIGVERIFY. With cross-input signature aggregation, if a public key indicates it can be used for cross-input signature aggregation, instead of OP_CHECKSIGVERIFY actually requiring the signature on the stack, the stack will contain a dummy 0 value for the signature, and the public key is instead added to a "sum" public key (i.e. an n-of-n that is dynamically extended by one more pubkey for each OP_CHECKSIGVERIFY operation that executes) for the single signature that is verified later by the cross-input signature aggregation validation algorithm00.
The important part here is that the OP_CHECKSIGVERIFY has to execute, in order to add its public key to the set of public keys to be checked in the single signature.
But remember that an OP_SUCCESS prevents execution! As soon as the SCRIPT is parsed, if any opcode is OP_SUCCESS, that is considered as passing, without actually executing the SCRIPT, because the OP_SUCCESS could mean something completely different in newer versions and current versions should assume nothing about what it means. If the SCRIPT contains some OP_CHECKSIGVERIFY command in addition to an OP_SUCCESS, that command is not executed by current versions, and thus they cannot add any public keys given by OP_CHECKSIGVERIFY. Future versions also have to accept that: if they parsed an OP_SUCCESS command that has a new meaning in the future, and then execute an OP_CHECKSIGVERIFY in that SCRIPT, they cannot add the public key into the same "sum" public key that older nodes use, because older nodes cannot see them. This means that you might need more than one signature in the future, in the presence of an opcode that replaces some OP_SUCCESS.
Thus, because of the complexity of making cross-input signature aggregation work compatibly with future extensions to the protocol, cross-input signature aggregation was deferred.
submitted by almkglor to Bitcoin [link] [comments]

The power of "import electrum" as a python bitcoin scripting engine

I've been a big fan of Electrum as a wallet for a while now. Traditionally, when I wanted to do bitcoin scripting I would use either trezorlib, pycoin, or bitcoinlib. But recently I was digging a bit deeper into the Electrum source and found it to be one of the simpler python libraries to use to craft bitcoin transactions.
One of the nicer things about Electrum as a scripting engine is that you can drop the standalone app or AppImage on a system and run your scripts directly through the console. This makes doing things on Tails or other locked down systems much easier. To run one one of your scripts (without the event loop) simply type (assuming you correct the file path):
with open(r"myscript.py", 'r') as s: exec(s.read())
Obviously only do this with scripts you've personally authored. Never run random code on your machine especially when wallet private keys are in play.
There are already some great scripting examples in the electrum\scripts folder, but most of these use the event loop which brings in a lot of overhead. I found simple TXN processing can easily be done without spawning an full electrum thread. I'd be happy to PR the samples if there is any interest in this style from the maintainers.
Here's two examples I put together that craft a BIP65 spending transaction. It turned out to be much simpler than I imagined. I did it both in bitcoinlib and electrum. The structure is very similar and should hopefully be easier to follow. Feel free to start a PythonRoastMe on it.
Two things of note. I had to disable R-value grinding (nuked while loop) so that I had parity with bitcoinlib, which hasn't rolled it out yet. This is why the TXIDs differ. I also had to override the the PartialTransaction.get_preimage_script method since it makes certain multisig assumptions that don't apply to generic scripting.
Reference: * Electrum script to spend an OP_HODL P2WSH address (txid 3a461e6...78de2b6) * Electrum script to spend an OP_HODL P2SH address (txid a8110bb...3dadc93) * BitcoinLib script to spend an OP_HODL P2WSH address (txid 3a461e6...78de2b6) * BitcoinLib script to spend an OP_HODL P2SH address (txid a8110bb...3dadc93) * TXID 3a461e6...78de2b6 (P2WSH) on the blockchain * TXID a8110bb...3dadc93 (P2SH) on the blockchain * BIP-0065: OP_CHECKLOCKTIMEVERIFY (aka OP_HODL) * BIP-0141: P2WSH symantics * BIP-0016: P2SH symantics
submitted by brianddk to Electrum [link] [comments]

hodlmon.sh: a UTXO monitoring methodology and script for true connoisseurs of security, paranoia and BTC maximalism

EDIT:
Disclaimer: the below script is provided for example purposes only. You're responsible for your own security. Don't trust, verify.
tldr: the script is literally just an example wrapper to call "gettxout" on your own node via cron to check if your own utxo has been spent yet
OK, since there are a few questions on security below, let me clarify: this script is only for people who are 1) already running their own nodes and 2) can understand the bash script below. And obviously, don't trust some random person on the internet, always verify. I provided this as an example for a way to monitor your own UTXOs with your existing node. Those of you who understand what the below script does will see it's painfully simple and obviously harmless. Those of you who don't understand it, just ignore this post, or better yet, research what the below means until you do understand it. What's important is the idea of monitoring your own UTXO, and this script is an example of how to do that with gettxout.
ORIGINAL POST:
Submitting this to help strengthen the community, and for review:
hodlmon.sh: a UTXO monitoring methodology and script for true connoisseurs of security, paranoia and BTC maximalism
Monitor canary UTXOs for early detection of compromised private keys BEFORE funds are lost, using your own full node for maximum privacy and trustlessness. Note that you will need to implement your own notification strategy (email, push, sms, etc). This script is intended to run on your full node, but can be run from any machine with RPC access to your full node.
hodlmon.sh is designed to check if a given UTXO (i.e. a specific output of a specific btc transaction) has been spent or not. This can be used for early and proactive detection if a seed phrase or private key has been compromised, so you have time to move your btc before full compromise happens. In order for this to work, a small amount of btc should be sent to an address controlled only by a given seedphrase, with that seedphrase being part of a multisig wallet or a seedphrase+passphrase wallet, and the majority of your funds controlled in the seedphrase+passphrase or multisig wallet. The idea is to leave the small amount of btc (the canary utxo) in the address, so that it never moves unless the seedphrase that controls it has been compromised and all funds in the wallet swept. In this way, you use those compromised sats to buy information about the current security status of your wallet(s).
Example usage:Set up a cron job to run hodlmon.sh every 30 min to check if transaction output at index "0" for transaction with id "123" has been spent already. Use "my_utxo_nickname" as a friendly name for the UTXO (to differentiate between multiple wallets)
*/30 * * * * /path/to/hodlmon.sh 123 0 my_utxo_nickname > /tmp/hodlmon_log 2> /tmp/hodlmon_err_log
Usage scenario #1: Seedphrase (A) + passphrase (A')Majority of funds are held in a wallet controlled by both the seedphrase and passphrase, A and A'. A token amount of btc is controlled only by seedphrase A.
A + A': majority of funds
A: canary UTXO
hodlmon.sh is used to monitor the canary funds locked by A, so that if it is discovered that A has been compromised, the funds locked by A and A' can be moved to a new wallet before the passphrase A' can be cracked and all your funds exfiltrated.
Usage scenario #2: multisig e.g. 2 of 3, with seed phrases A, B and CMajority of funds held in a multisig wallet controlled by 3 seedphrases A, B, and C. 3 small canary UTXOs are held in wallets each controlled by A, B or C, respectively.
A + B + C: majority of funds
A: canary UTXO 1
B: canary UTXO 2
C: canary UTXO 3
One benefit of multisig (e.g. 2 of 3) is that even if 1 key is compromised, your funds are safe, since at least 2 keys are needed to release funds. But how do you that none of the keys has yet been compromised? If you create separate wallets controlled each by only 1 of the individual keys, and use hodlmon.sh to monitor whether those UTXOs have been exfiltrated, then you can detect partial compromise of your setup before a full exfiltration event takes place, so you can move your funds to a new multisig wallet with freshly generated and uncompromised keys.
Example of 3 cronjobs to monitor all 3 canary UTXOs:
*/30 * * * * /path/to/hodlmon.sh 123 0 key1 > /tmp/hodlmon_log_1 2> /tmp/hodlmon_err_log_1
*/30 * * * * /path/to/hodlmon.sh 456 0 key2 > /tmp/hodlmon_log_2 2> /tmp/hodlmon_err_log_2
*/30 * * * * /path/to/hodlmon.sh 789 0 key3 > /tmp/hodlmon_log_3 2> /tmp/hodlmon_err_log_3

Example hodlmon script:
#########################################################################
#!/bin/bash
touch /tmp/hodlmon_last_run
echo "Transaction ID: $1"
echo "Output #: $2"
echo "Nickname: $3"
NODE_IP=127.0.0.1 #TODO: use actual value
USER=user#TODO: use actual value
PASS=pass #TODO: use actual value
PORT=8332 #TODO: use actual value
CHECK_CMD="/uslocal/bin/bitcoin-cli -rpcconnect=$NODE_IP -rpcuser=$USER -rpcpassword=$PASS -rpcport=$PORT gettxout $1 $2"
RESULT="$($CHECK_CMD)"
echo "${RESULT}"
if [ "$RESULT" == "" ]
then
echo "UTXO HAS BEEN SPENT! RED ALERT!!"
MSG="The UTXO for $3 from tx $1 output $2 has moved!"
#TODO: ADD YOUR FAVORITE NOTIFICATION STRATEGY E.G. EMAIL, PUSH NOTIFICATION, SMS
else
echo "UTXO is still on ice"
fi
############################################

submitted by facepalm5000 to Bitcoin [link] [comments]

Storing your coins safely while not risking loss of keys

This was originally an answer to a question that was asked here, but OP deleted their post.
This might help some newbies (especially the multisig edit at the end), so I want to make sure it's still accessible here.
The original question was whether the Electrum wallet stores a Trezor's private key when using a passphrase.
OP noticed that their Trezor wouldn't connect to their Electrum wallet when entering a different passphrase than they used when creating the wallet. Thus, OP (likely) assumed that the wallet stored the private key, as it somehow knew that a different private key was now used.
Here is my original answer (with some modifications):
IMPORTANT: I'm assuming here that you connected your Trezor by choosing the "hardware wallet" option in Electrum, rather than giving Electrum your 12/24 seed words.
TL;DR: No, your coins are safe :)
I'm assuming by passphrase) you mean the 25th (or 13th) word. When you have this feature enabled, a private key gets generated every time you enter a passphrase. When you enter the same passphrase you used to create the wallet, the wallet with your funds shows up.
Whenever you enter something different, a different private key is generated on your Trezor. This allows you to have multiple different wallets, for example by choosing the passphrases "First Wallet", "Second Wallet", "Third Wallet", or a secret wallet with a secret passphrase.
So whenever you enter a new passphrase when connecting your Trezor to Electrum, the Trezor will send a new public key to Electrum. Electrum will then derive addresses from this public key and check those for balances. It won't find any, as you used a new passphrase.
EDIT: I just realized that you said your wallet doesn't connect to Electrum when you use a different passphrase. This is simply because Electrum doesn't receive the correct public key from the Trezor and therefore Electrum thinks it's a different wallet (which it is).
When you enter the passphrase you used during creation of your wallet, the Trezor will send your actual public key to Electrum, which will then find addresses with balances, which it will show to you. EDIT (to clarify): Connecting your Trezor after creating the wallet is only necessary to send funds or verify addresses, as the public key is already stored in the wallet.dat.
The only thing Electrum actually stores is the public key, which can only be used to look at your Bitcoin, not to move them. You might want to keep this public key a secret as well though, since it links all your funds to you. This is what Electrum stores in the wallet.dat file, which you can just encrypt by choosing a password for it.
Well done using a passphrase by the way! Should someone get their hands on your Trezor, a sophisticated attacker can get the secret key off the device in 15 minutes. Using a passphrase makes this attack almost useless, as the both secret key AND the passphrase are needed to move your funds, and the passphrase is not stored on the device. A passphrase also allows you to hide funds from potential robbers that force you to unlock your wallet.
You can do this by activating the passphrase feature and sending your funds to a wallet with a secret passphrase (do NOT lose this, as losing your passphrase renders your funds inaccessible). Afterwards, you can safely deactivate the passphrase feature, so the device doesn't even ask for one should you get robbed. Simply reactivate it when you need to access your funds.
EDIT: Should you be worried that you might forget your passphrase, you should look into multisig wallets. Depending on how you set this up, you can make it more secure against theft and less likely for you to lose access to your funds.
Say for example you get four wallets: two hardware wallets, a well-protected (airgapped) laptop with Electrum, and a secure mobile wallet that allows for multisig (like Fully Noded).
You can then create a 2-of-4 multisig wallet that requires you to sign transactions with any two of these four wallets.
The increase in security comes from the fact that an attacker now needs full access to two of your devices (or their stored private keys) at once.
At the same time, the fact that you yourself now also need access to only half of your devices means that in the event of a total loss of one (or even two) of them, you can still move your funds to a new wallet.
As long as you do regular checks (e.g. first day of each month), ensuring that you still have access to all your devices' stored private keys, you can always catch a loss of keys and fix this without losing funds (by creating a new multisig wallet and sending the funds there).
This allows you to use a passphrase on your wallets without storing it anywhere physically or digitally. This would usually be very risky, as forgetting the passphrase would lead to a loss of funds, but this risk is now close to eliminated.
(The following part was not in the original answer)
Some IMPORTANT general secruity tips:
  1. Consider including trusted friends and/or family members as co-signers for a multisig wallet. This ensures that it's not even possible for you alone to hand over funds to an attacker. Depending on your level of trust, you might want to make sure that your co-signers can't collaborate to steal your funds (if you include 3 people, create at least a 4-of-n multisig). You could also deliberately make it possible for all or even just some of your co-signers to move your funds (3 co-signers, 3(or less)-of-n multisig) to make sure your funds aren't lost should pass away unexpectedly.
  2. Consider running your own full node and Electrum server (also check the alternatives), which you connect your Electrum wallet to. This ensures that you don't send your public key to anyone else. If someone knows your public key, they know how much BTC you own, making you a potential target.
  3. Always encrypt your wallet.dat (or whatever you called your wallet file), even if it's a watch-only wallet. This protects your public key (see 1. for why you want that).
  4. Create watch-only wallets: Use an airgapped) device to create a wallet with Electrum (make sure to back up the seed phrase) and export the public key. Then create a new watch-only wallet on another device (like your everyday laptop) with that public key to be able to check your funds. To create the initial wallet, you can also use any other hard- or software wallet that allows you to export the master public key.
  5. Hide, or (when using a hardware wallet with a passphrase) even delete your watch-only wallets. Hiding your funds makes you less of a target. When using a hardware wallet, recreating the watch-only wallet is fast and simple, so you don't need to store it if you don't want to check your funds every day. Note that this approach doesn't help much when you don't use a passphrase, as an attacker will obviously check the passphrase-less wallet no matter what.
  6. Keep some funds on your hardware wallet(s). If an attackers sees funds on the wallet(s), they might not force you to enter a passphrase or ask if you have any multisig wallets (lying under pressure is hard).
  7. Hide all your wallets in different places. If someone sees that you have multiple wallets lying around, they might realize you have a multisig wallet.
  8. Don't risk a robber getting (for example) two keys to your 2-of-4 multisig wallet and then racing them to move your funds with the other two keys when they leave. They're gonna come back and be pissed. If it comes to this, you need protection until the robber is caught. STAY SAFE!
  9. The easiest way to solve a problem is to never have it. Don't make yourself a target. If nobody even suspects that you have a multisig (or any wallet at all), they're probably not gonna look for it.
Please correct any mistakes you find and I will edit my post. I will also gladly add more tips to the list. I will of course credit anyone who helps.
Tip for devs who want something cool and important to work on: Make the creation and usage of multisig wallets as noob-friendly as possible. If someone expresses worries about losing access to their funds by forgetting the seed phrase, wallet pin, etc. (someone in my family actually brought this up to me), multisig wallets are the perfect solution as they add redundancy.
submitted by Fittiboy to Bitcoin [link] [comments]

[ Bitcoin ] Technical: Taproot: Why Activate?

Topic originally posted in Bitcoin by almkglor [link]
This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given private key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

almkglor your post has been copied because one or more comments in this topic have been removed. This copy will preserve unmoderated topic. If you would like to opt-out, please send a message using [this link].
[deleted comment]
[deleted comment]
[deleted comment]
submitted by anticensor_bot to u/anticensor_bot [link] [comments]

How to verify if a transaction is correctly signed?

Given an arbitrary signed raw transaction, how can we easily verify if all inputs are correctly signed (admiting all UTXOs are present and fee is higher than zero)? I know there is an RPC command in bitcoin core testmempoolaccept but this will also check if all inputs are available to be spent in the mempool/blockchain and I want to test a transaction that is a child to a parent transaction that has not yet been broadcasted.
The signed transaction instance could have the scriptPubKey of the used utxos stored as metadata (since it needs to know these to sign each input) and use the stored utxos to perform this validation - alternatively, the verification method could ask for the scriptPubKeys of the utxos as input. I was looking for some nice way to do this in python but was surprised how neglected this task is:
EDIT: converting to PSBT is not possible/easy so the last option I mentioned won't work. I have the transactions in serialized 'network' format (what you get from `bitcoin-cli getrawtransaction hex')
EDIT2: escalated to bitcoin stack exchange: https://bitcoin.stackexchange.com/questions/96759/how-to-verify-if-a-transaction-is-correctly-signed
submitted by johnturtle to BitcoinBeginners [link] [comments]

Amazing AMA from Douglas Horn

AMA Recap telos Foundation with Crypto Hunters
On August 02, 2020 at 12:00 WIB Indonesia Time / August 01 2020 at 10:00 PM ( PST ) in the Crypto Hunter Telegram Group, AMA TELOS started with Mr.Douglas as guest speaker and Gus Fahlev from Crypto Hunters as moderator. When campaigning, 10 lucky AMA participants when asking questions on Google forms and AMA sessions will get a total TELOS ( TLOS ) prize of $100.
The following is a summary of AMA questions and answers announced by the moderator and
Segment 1
Question 1: Can you explain us, what is Telos?
Answer: Telos is a blockchain platform for smart contracts. It is a low latency—a new block every half second, high capacity—currently in the top 2 blockchains in transactions per day, according to Blocktivity.info, and no transaction fee blockchain. Telos also has many unique features that allow developers to make better, dapps, such as our Telos Decide governance engine.
Question 2: what ecosystem is used by telos?
Answer: Telos is its own Layer-1 blockchain, not a token on another blockchain. The technology behind Telos is EOSIO, the same technology used by EOS and WAX, for example.
Question 3: I see that Telos uses EOSIO platform, what are the very significant advantages that distinguish Telos from other projects?
Answer: Telos uses the EOSIO platform but we have built several additional tools. Some of these add more security and resiliency to the blockchain, such as testing block producers and removing non-performant ones, but most are related to development. Telos provides attractive development tools that aren’t available elsewhere. Telos Decide is a governance platform that lets any group create self-governance tools easily. These run on Telos at very little cost and can provide all kinds of voting, elections, initiative ballots, committee management and funds allocation. Telos also has Telos EVM, an Ethereum virtual machine that can run Ethereum Solidity contracts at hundreds of times the speed of Ethereum and with no costs. Another Telos technology that is deploying soon is dStor, which is a decentralized cloud storage system associated with Telos so that dapps can store files controlled by blockchain contracts.
Question 4: At what stage is Teloa Road Map now? what are the latest updates currently being realized?
Answer: Telos launched its mainnet in December 2018 and has so far produced over 100,000,000 blocks without ever stopping or rolling back the chain. This is likely a record for a public blockchain. We have an ongoing group Telos Core Developers who build and maintain the code and are paid by our Telos Works funding system that is voted by the Telos token holders. Telos is a leader in blockchain governance and regularly amends its governance rules based on smart contract powered voting called Telos Amend. You can see the current Telos governance rules as stored live on the blockchain at tbnoa.org.
The most recent updates were adding new features to Telos Decide to make it more powerful, implementing EOSIO v2.0 which increased the capacity of Telos about 8-10 times what it previously was, and implementing Telos EVM on our Testnet.
We are currently working on better interfaces for Telos Decide voting, and building more infrastructure around Telos EVM so that it is ready to deploy on our mainnet.
Question 5: Is telos currently available on an exchange? and is it ready to be traded?
Answer: Telos has been trading on exchanges for over a year. The largest exchanges are Probit, CoinTiger, CoinLim, and P2PB2B. Other exchanges include Newdex and Alcor. We expect to be listed on larger exchanges in the near future.
Question 6: Now is the time when defi tokens begin to develop, can telos be categorized as a defi project? and what strategies for this year and in the years to come prepared by telos?
Answer: Telos is a smart contract platform, but it already has many DeFi tools built for it including REX staking rewards with a current yield of ~19% APR, smart contract controlled token swaps (like Bancor) with no counterparty called Telos Swaps, a common liquidity pool/order book shared by multiple DEXs to improve liquidity called EvolutionDEX. Wrapped BTC, ETH, XRP, EOS, and other tokens can be brought to Telos and exchanged or used via smart contracts through Transledger. We have more DeFi tools coming all the time including two new offerings in the next few weeks that will be the first of their kind.
Question 7: Governance is an important topic in blockchain and Telos is considered a leader in this area. Why is that?
Answer: Telos is among the top blockchain projects in terms of how it empowers its users to guide the growth of the chain—along the likes of Tezos or new DeFi tokens that offer governance coins. Telos users continuously elect the validating nodes, called Block Producers, that operate the network based on a set of governance documents such as the Telos Blockchain Network Operating Agreement (TBNOA). These are all stored entirely on-chain (viewable at tbnoa.org) and can be modified by smart contract through blockchain voting using Telos Amend. You can see examples of this at https://chainspector.io/governance/ratify-proposals Telos also has a robust user-voted funding mechanism called Telos Works that has funded many projects and is one of the more successful blockchain incubators around. Voting for all of these can be done in a number of ways including block explorers, wallets like Sqrl (desktop) and Telos Wallet (mobile), telos.net and Chainspector (https://chainspector.io/governance/telos-works). But Telos goes beyond any other chain-level governance by making all of these features and more available to any dapp on Telos through Telos Decide governance engine, making it easy for any dapp or DAO to add robust, highly customized voting.
Segment 2 from google form
Question 1: Defi projects are now trending whether telos will also go to Defi projects, to increase investors or the community?
Answer: Yes, we have several DeFi tools on Telos that can work together:
Telos Swaps is an automated, zero-counterparty token swapping smart contract where you can exchange any Telos tokens you may want at any time.
Telos has DEXs and uses a common order book called EvolutionDEX that's available to any DEX so that a buy order on one can be matched against a sell order on another. This greatly increases liquidity for traders.
We have staking rewards though the Resource EXchange (REX) with rewards currently at about 19% APR.
We also have "wrapped" BTC, ETH, and other tokens that can be traded on Telos or used by its smart contracts at half-second transaction times with no transaction fees. This makes Telos a Bitcoin or Ethereum second layer or state channel that's much faster even than Lightning Network and has no fees once the BTC has been brought to Telos.
Question 2: Telos aim is to build a new global economy could you explain how whole ecosystem works? There are already many centralized competitors so what is decentralization aspect in telos?
Answer: Telos is one of the most decentralized blockchain's in the world. It is operated by 51 validators (block producers) who validate blocks in any month. These are voted for on an ongoing basis by Telos account holders.
Telos is also economically decentralized with no large whales like Bitcoin, Ethereum, XRP or EOS because Telos never performed an ICO and limited the size of genesis accounts to 40,000 TLOS max.
Telos is also geographically decentralized with users and block producers on every continent but Antarctica and in numerous countries. The is a large amount in North America and Western Europe, but also in Asia, Australia, and large contingents in Latin America and Africa. Telos has had a Block Producer in Indonesia since the beginning and some dapps on Telos are based in Indonesia as well, like SEEDS, for example.
Question 3: Most investors focus only on the token price in the short term instead of the real value of the project.
Can #TELOS tell me the benefits for investors holding #TELOS the long term?
Answer: That's true about crypto speculators and traders, certainly. Traders are usually looking for coins with good positive momentuum that they hope will continue. But these are often pump and dumps where a few people get in early, pump the price, and then get out at the expense of new investors. That's very unfortunate. Telos isn't like this. One reason is that there aren't large whales who can easily manipulate the price.
Telos seems to be greatly undervalued compared to its peers. Telos has capacity like EOS and well above XRP, XML, Tron, Ethereum. But its value is miniscule relative to these. Telos is a leader in blockchain governance like Tezos but its marketcap is tiny in comparison. Telos onboarded 100,000 new accounts last month and is appearing in the leading crypto press every week with new dapps or developments. So there's some disconnect between the value of Telos and the price. In my experience, these tend to equalize once more people learn about a project.
Question 4: Eos Problems and How Telos Will Solve Them?
Answer: Telos originally set out to solve problems with EOS. It was successful in this and now Telos stands on it's own and our roadmap is more about empowering users. In short, these are some of the EOS problems we already solved:
RAM speculation - Telos had a plan to reduce RAM speculation through a published guidance price that has been extremely successful. The RAM price is guided by market forces but has remained within 10% of the guidance price since launch.
CPU resources - Telos implemented the Telos Resource Improved Management Plan many months ago which was a 7-point approach to making EIDOS-type resource mining unprofitable on Telos. It has largely been successful and Telos has not experienced any resource shortages.
Exchange Collusion/Voting - Telos governance does not permit Exchanges to vote with user tokens. This prevent voting situations seen on EOS or STEEM.
Block Producer collusion - Telos has minimum requirements for block producers and do not allow anyone to own more than one block producer. Those who are found doing so (there have been about 3 cases so far) have been removed and sanctioned in accordance with the rules of the TBNOA.
Question 5: What ecosystems do telos use? and why telos prefers to use EOS network over BEP2 or ERC20? what layer is used telos, can you please explain?
Answer: uses the EOSIO protocol because it is the fastest and most powerful in the world and it also receives the fastest upgrades and ongoing development compared to other blockchain technologies. EOS and WAX also use the EOSIO protocol but they are completely different chains.
Telos is a Layer 1 protocol, meaning that it is its own blockchain that other dapps and smart contracts deploy upon.
One thing that happens when a blockchain like Telos has much, much higher speed and capacity than others like Bitcoin or Ethereum is that Telos can actually run those other blockchains better on its own platform than they can natively. For example, a number of tokens can come in to Telos as wrapped tokens. BTC, ETH, XRP are all current examples of tokens that can be on Telos as wrapped tokens. Once there, these can all be moved around with half-second transaction times and no transaction fees, so they are a better second layer for Bitcoin or Ethereum than Lightning Network or Loom.
Telos can also emulate other chains, which we are doing using Telos EVM which emulates the Ethereum Virtual Machine at about 300 times faster and with no gas fees or congestion compared to Ethereum native deployment. Telos can run Ethereum (Solidity) smart contracts without any changes required. Telos EVM is already deployed on the Telos Testnet and will move to our mainnet soon. So anyone who wants to run ERC-20 tokens on Telos can do so easily and they will be faster and with much less cost than running the same contract on Ethereum.
Segment 3 free asking
Question: I am happy to see new things created by the Telos team. Like What concept did you build in 2020 to make Telos superior?
Answer: Currently, I think Telos Decide is the most unique and powerful feature we have built. There are all kinds of organizations that need to vote. Apartment buildings, school boards, unions, tribes, youth sports leagues, city councils. Voting is hard, time consuming, and expensive for many. Telos Decide makes voting easy, convenient, and transparent. That will be a major improvement and disrupt old style voting. It also goes for buisnesses and corporate governance. Even before COVID it was important, but now people can't really gather in one place so fraud-proof voting is very important. No one has the tools that Telos has. And if they try to copy us, well, we are already way out ahead working on the next features.
Question: If we look about partnerships, Telos has many partnership ! so what's the importance of that partnership for Telos? And How will you protect the value of Telos to your partners or investors ??
Answer: Many of the partnerships are dapps that have decided to deploy on Telos and receive some level of help from the TCD or Telos Foundation to do so. Once a dapp deploys on a chain, it really is like a long term partnership.
Many dapps will become block producers as well and join in the governance of Telos. I suspect that in a few years, most block producers will be the large dapps on the platform with just a few remaining like my company GoodBlock. Of course, we will have our own apps out as well so I guess we'll be developers too.
Telos is very fiscally responsible for investors. We spend little. There has not been any actual inflation on the chain in almost a year. (The token supply has remained unchanged at about 355M TLOS) we are actively working with dapps to bring more to Telos and exchanges and other services like fiat on- and off-ramps to increase value for users.
Question: In challenging crypto market condition any project is really difficult to survive and we are witnessing that there are many platforms . What is telos project plan for surviving in this long blockchain marathon? In this plan, what motivates long term investors and believers?
Answer: True.
While we currently have a low token price, Telos as a DPOS chain can be maintained and grow without a massive army of miners and still maintain BFT.
But the risk is really not whether Telos can continue. Already there are enough dapps that if the block producers went away somehow (not gonna happen) the dapps would just run the chain themselves.
But with 100,000 new users last month and new dapps all the time, we are looking to join the top 5 dapp platforms on DappRadar soon. Survival as a project is not in question.
One of the big reasons is that we never did any ICO and Telos is not a company. So regulatory risks aren't there and there's no company to go bankrupt or fail. We have already developed a bootstrapped system to pay block producers and core developers. So we aren't like a company that will run out of runway sometime.
Question: Could you explain what is DSTOR? What will it contribute to your ecosystem?
Answer: dStor is a decentralized cloud storage system that will have the performance of AWS or Azure with much lower costs and true decentralization. It's based on a highly modified version of IPFS that we have applied for patents for our implementation. It means that dapps will be able to store data like files, images, sound, etc. in a decentralized way.
Question: Trust and security is very important in any business , what makes investors , customer and users safe secure when working with TELOS??
Answer: Telos is decentralized in a way that's more like bitcoin than other blockchains (but without the whales who can manipulate price). There was never any single company that started Telos, so there's no company whose CEO could make decisions for the network. There are numerous block producers who decide on any operational issue that isn't clearly described in the TBNOA governance documents. And to get to an action, 15 of the 21 currently active BPs need to sign a multisig transaction. So that's a high threshold. But also, the TBNOA speaks to a large number of issues and so the BPs can't just make up their own rules.
Since there are really no whales, no one can vote in any kind of change or bring in their own BPs with their votes. This is also very different from other chains where there are whales. Telos is not located in any one country, so our rules can't be driven by one nation's politics.
All in all, this level of decentralization sets Telos apart from almost any blockchain project in existence. People don't have to trust Telos because the system is designed to make trust unnecessary.
submitted by TelosNetwork to TELOS [link] [comments]

How to Cold Store Your Cryptocurrency for Safekeeping

According to CipherTrace (which specializes in litigation tools and services for cryptographic markets), between 2018 and 2019, the amount of theft from cryptographic wallets exceeds $2 billion. Thefts and break-ins are caused by a variety of reasons: simple incompetence in cryptographic storage, as well as by companies that provide storage services. It is not unusual for holders of crypto currency to lose access to their wallets by themselves, one of the last known cases occurred in Ireland: ,57 million dollars couldn’t be confiscated from a detained drug dealer, which were stored in bitcoins. The problem was that the wallets keys were lost.
The most secure way is a cold storage — all account data and private keys are kept offline and all transactions are manual. This storage method is great because it is fully protected from hacking and interception of data, but it is not suitable for those who make daily transfers of cryptocurrency, it is simply inconvenient.
If you compare “cold and hot” wallets, you can give a simple example: A hot wallet can be compared to a wallet that can be lost and stolen. But you can always access your funds. A cold wallet is safe, and access to it is not permanent. You can also take or put money, but it will require a special code.
In this article we will tell you about the most popular types of cold wallets and we will analyze their pros and cons.

Types of cold wallets

All cold wallets have one common thing — the data is stored offline. However, there are several types of cold wallets, which differ in the degree of protection, physical embodiment and cost of the wallet.

Desktop wallet

Desktop wallets are also known for a high level of protection, in addition to the ability to store crypto currency offline. There are so-called “light” wallets weighing less than 1 gb, and “heavy” wallets weighing more than 1 gb. Two of the desktop wallets can be distinguished:

Exodus Wallet

Multicurrency wallet. It was created in 2016 and supports more than 100 crypto currencies, since 2019 has a phone application. The wallet allows you to export private keys that are created locally, and then to upload them back. Private keys can be discounted to removable media and downloaded only when the transaction is completed. If the user decides to leave private keys on the same computer where the wallet is located, keys are securely encrypted. In order to use your wallet ,there is no need to register or to download the entire blockchain — synchronization is taking place online. In addition to wallet services Exodus Wallet provides an integrated crypto-exchange. The installation file weighs 85 mb.

Bitcoin Core

Bitcoin Core is the official Bitcoin wallet. The size of the wallet is 160 gb, but according to the developers of the company, it’s better to give it a separate winchester with the size of 500 gb. From the security viewpoint, it’s suggested to install a security code or a seed phrase, which may consist 8 words. It is also suggested to copy wallet.dat file. — private wallet key, which will allow you to restore access to your funds.

Hardware wallets

Appears like a regular flash drive with an interface (screen, control keys). This wallet can safely store information about the balance and keys, full functionality is available only when connected to a computer, but the latest models have a special button that allows you to confirm the transaction without connecting to a PC. Each time the device offers to generate a new code-password to confirm the transaction, which significantly reduces the probability of hacking. After generating the code, you need to set a mnemonic phrase (seed) — it consists of 12 or 24 words, which are not related to each other in any way. Such type of wallets has a special protection system that allows you to connect even to potentially infected PCs. The wallets themselves won’t be affected by malware.
The obvious cons of hardware wallets are the following:
  1. It is also possible to lose a device that is so small in size.
  2. A physical device can easily fail due to a variety of damages.
  3. It is not recommended to buy such wallets from “hand”, even from friends, as they can be pre-installed with malware.
As you can see, storing crypto currency with a hardware wallets is very safe and secure, however you should take care about the device. Many people who hold a large amount of crypto currency, in order to not to lose a hardware wallet, store it in a safe deposit box, depriving someone of access to it.

Popular Hardware Wallets models

Trezor One

The first hardware wallet produced in 2013 by the Czech company Satoshi Labs. The device has an OLED display with a pin code, public addresses and Seed phrases. Trezor One has won recognition from users due to its multicurrency and affordable price ($65), it is also considered one of the most secure hardware wallets.
Ledger Nano S
The wallet was released in 2016 by the French company Ledger SAS. Distinctive feature from the other wallets, is the Secure Element controller, which meets banking standards and is certified CC EAL 5+. Also, in order to work with each crypto currency you need to install a special application for this currency on the device, it is not quite convenient, however more secure. The average price of the device is $85.
KeepKey
The purse was released in 2015 in the U.S.. Distinctive feature is OLED display — 256 by 64 pixels. Due to this, you can fully see both the address of the wallet, and the seed phrase. Also, the wallet has a built-in exchange service ShapeShift — an opportunity to exchange crypto currency without entering the exchange. The average price of the device is $50.
BitBox01
Ionos Schnelly’s wallet was invented in Switzerland. In size it’s almost the most compact among all representatives of the hardware wallets. A distinctive feature is the availability of a backup — the card can be multiplied and kept in several places, by analogy with the seed-phrase. In November 2020, support for these wallets will be discontinued, but all owners will be given a 30% discount on the new model. The average price of the device is $55.
CoolWalletS
Developed in Taiwan by CoolBitX, which has long been manufacturing components for Visa and MasterCard. As well as Ledger Nano S has a security standard CC EAL 5+. This wallet works only through smartphones, connecting to them through Bluetooch. The average price of the device is $100.

Paper Wallet

In the age of technological process, plain paper has become a rather reliable method for storing cryptocurrency. With the help of special services, such as bitaddress.org, you can generate public and private keys, then writing them down on paper. You can also print keys as a QR code. To accept transactions with such a wallet, you provide the sender with a public key. To access the funds, you need to find any online wallet that supports your crypto currency. Enter your private key into your online wallet, thus integrating your funds into the system. However, you should understand that after this procedure your wallet will become “hot”.
The best of this storage method — paper wallet is free, its safety depends only from you. When storing a paper wallet to protect it from the fire, water and aging. Also, do not tell other people about where your paper wallet is hidden.
The disadvantages of this storage:
  1. If your wallet is lost, it will be impossible to restore it.
  2. Exposed to a physical damage.
  3. After sending the transaction, you will have to create a new cold wallet.

Offline transaction signature

For this storage method, you will need two PCs. The essence is that the secret keys are never in contact with the Internet, but are stored digitally. Offline transaction method is suitable for people who do not make a daily transactions and have an access to two devices. The process is below:
  1. A hot wallet is installed on a PC with the Internet. The transaction is created without entering private keys and authorization.
  2. The file with transaction is copied and transferred to the second PC without Internet, where private keys are stored.
  3. The transaction is signed offline, copied and transferred back to the PC with the Internet.
In fact, you can do it with one PC and a USB drive. The USB drive will store private keys. Also, you can create a transaction without entering private keys and authorization, after disconnecting the Internet, connect the flash drive, sign the transaction, turn on the Internet. In this case, you should take care of the antivirus system.
The disadvantages of this method:
  1. Using two PCs or a USB drive involves a lot of actions, which is time consuming.
  2. You need to back up your keys in case your PC or flash drive fails.

Multi-signature wallet

This method implies the creation of a wallet, which can be only withdrawn on condition that the transaction is verified by a predetermined number of users. The maximum number of users who can hold private keys of the wallet- is 15. It is considered as one of the most reliable ways of storage, in fact private keys are not only stored offline, but also divided between different people. Often the wallet with multisignatures is used by large crypto-companies, whose management believes that individually employees can not spend the budget. Moreover, when creating this wallet, the number of required multisignatures is minimal. For example: if one of the six keys is lost, the remaining ones will be enough for the transaction.
The disadvantages of this storage:
  1. If most of the keys are lost, access to the funds cannot be restored.
  2. You will not be able to make transactions on your own without the participation of other key holders.

Private Key Fragmentation

The private wallet key consists of 64 symbols. The key is divided into several fragments. They don’t represent anything separately, but if you put all the fragments together, you can access the funds. The key fragments are similar to multisignatures, but in this case you don’t need a multisig-wallet, and the whole process can be done manually.
The disadvantages of this method:
  1. If one fragment is lost, access to funds will be lost.
  2. The maximum level of protection can only be reached when key fragments are distributed to different places, for example: bookshelf, safe deposit box, car. If you divide the key fragments and put them in different boxes — the required level of protection will not be achieved.
When writing down key fragments on paper, protect the key from fire, water and aging.

Conclusion

Digital currencies are not physically expressed and exist only in the digital code, so cold wallets that doesn’t have an access to the Internet, protect cryptocurrencies from the most important and common problem — hacker theft. However, holders of cold wallets need to understand that the safety of a private key depends only on them. There are different ways to store private keys outside the network, but each of them makes it difficult for the user to make transactions.
Hardware wallets that have been specifically designed for this purpose are considered to be the best option for storing cryptocurrencies. With their help it is possible both to store funds off the network and to make transactions easily, without risking the safety of a private key. If you use other cold wallets, it is recommended to combine them with hot wallets. Keep the required crypto currency for daily transfers on hot wallets, and keep all other crypto on cold wallets.
Please don’t forget to follow us on Telegram and stay updated!
YOUR CRYPTO BOSS
submitted by yourcryptoboss19 to u/yourcryptoboss19 [link] [comments]

Whales Latest update

Whales Platform is currently in better testing phase. as its currently hunting bugs, making sure that all integrations are working, i.e dealing process is to be made easy for users understand.
Whales project is moving to the Next phase, by starting to adding more ERC20 tokens with the hope of expecting raise in swapping volume.
After that we will add forensic check for Bitcoin, ETH and ERC20 tokens. This is where we expect strong volume growth. A tool to swap Bitcoin of know quality (like freshly mined) to Bitcoin or Ethereum of lower quality (after mixer for example) without custody and on-chain is deferentially something that crypto world needs.
Then we will add add support for more Blockchains. We currently support Bitcoin, Omni (USDT), Ethereum, Litecoin and Bitcoin Cash. We want to add support for Monero, Zcash, EOS, Tron and Dash. Each blockchain support is tricky, as there is no good multisig wallets build for each of them. Hence, we partnered with Guarda wallet, as they support 46 blockchains, and integrating multisigs for each blockchain we adding a support for into their wallet. This is a where we expect rapid growing phase.
Then we will add one-to-many deals and this where real fun starts. You will be able to sell large amount of currency X to hundreds of people on a single deal each of them paying in of 10 currencies you decided to accept. and on top of that you will receive all 10 currencies that went though a forensic check. Tool suitable for any sale volume for any grade of selletrader.
Enjoy benefit of whalesheaven by partcipating in bounty campaign: https://bitcointalk.org/index.php?topic=5254541.0
submitted by Debasco59 to whalesheaven [link] [comments]

08-05 12:35 - 'My software is one of the most secure way to store and protect your bitcoins.' (self.Bitcoin) by /u/passio-777 removed from /r/Bitcoin within 184-194min

'''
Hi, I would like to show you my software to encrypt and store Bitcoin access (seed) on QR Code.This is an ONLINE version and it must NOT be used with real seeds, it's only for test. If you want to use it, you have to use it on OFFLINE computer that will never be connected again to the internet.This online software will allow you to encrypt any text data in a QR Code.For example, this is for me the BEST way to store your recovery seed for a Ledger.This is also the best way to store your Seed for electrum wallet...But for me, the best way to use it is to create a Multisig 2-3 with electrum, encrypt 3 seeds and you can store 1 seed encrypted on QR code in cloud, and you can give the encrypted QR Code to different friends and members of your family.Please, tell me what you think about it :[[link]2
The best is that you can decrypt the QR code with a Linux Session only by Using terminal, you don't have to be afraid about lose your bitcoin if you lose this software access.
'''
My software is one of the most secure way to store and protect your bitcoins.
Go1dfish undelete link
unreddit undelete link
Author: passio-777
1: qryp***.tk/ 2: *ry*t*r.tk/]^*1
Unknown links are censored to prevent spreading illicit content.
submitted by removalbot to removalbot [link] [comments]

Recap of Binance English Kava AMA (May 2020)

This AMA was conducted within the Binance English Telegram channel prior to Kava's June 10th launch of its DeFi Lending Platform.

Q1:

Can you give us a little history of KAVA?

Q2:

Could you please tell me what KAVA cryptocurrency is? What problem does it solve?

  • Answer - KAVA is the staking, governance, and reserve asset of the Kava DeFi platform. KAVA is required by node operators to secure transactions on the blockchain. Additionally, when lending fees are paid, they are converted to Kava and burned reducing the overall supply of KAVA tokens. As more users use the Kava lending platform, KAVA should become more scarce overtime.

Q3:

What is the advantage of keeping the KAVA token for a long and short term?

  • Answer - In the short term, if you stake KAVA you can earn additional block rewards every day, block by block. This provides a nice steady return on the Kava usually in the range of 3-20% depending on the number of people staking.
  • We will be opening the gates of DeFi to many top tier assets such as BNB, XRP, ATOM, and BTC which have never been able to use lending, stablecoins, or other DeFi Services. If you are a KAVA hodler you can benefit from owning and having a stake in the network as we grow because as the network grows, Kava is burned and it becomes more scarce as a resource.

Q4:

Chainlink is KAVA’s partner, can you explain more about this partnership?

  • Answer - Yes, this is not the usual chainlink partnership where a blockchain consumes data from Chainlink’s oracle solution.
  • No oracle solution adequate for DeFi applications on Cosmos was available. For this reason, Kava has teamed up with Chainlink to bring its data and reliable oracle solution to the Cosmos ecosystem. Chainlink nodes now will be able to securely publish data directly on the Kava blockchain where it can be used or easily transported to other Cosmos-based blockchains and applications. Chainlink oracles on Kava utilize all the industry-leading technologies of Chainlink, while enabling more frequent price updates and improving the reach and distribution of where that data can be used.
  • Since Kava’s blockchain is built using Tendermint, Tendermint-based blockchains within the Cosmos ecosystem (Binance, Terra, OKChain, Cosmos Hub, Agoric, Aragon, and others) will now be able to retrieve market data such as cryptocurrency, FX, and commodity prices. For DEX’s like Binance this will enable them to create futures, options, and other derivative products they were not able to do so before.
  • TLDR: Kava + Chainlink Data creates the ideal hub for all blockchains and applications to get their DeFi services and Data, and as result makes Kava a natural hub for the growing Cosmos ecosystem.

Q5:

What is the KAVA CDP product? Do you have any exciting things down the pipeline that you can share?

  • Answer - First, let me clarify that CDP simply means “collateralized-debt-position” similar to CDOs that exist in the traditional finance world. What it means is a loan using collateral to back the loan.
  • Kava’s lending platform offers collateralized loans to users who have crypto. Getting a loan with Kava’s platform is great if you don’t want to sell your crypto position, but need short term cash for payments or if you want to use the loan to get a levered / margin position without going through KYC.
  • As for news! Kava’s lending platform is scheduled to officially launch on the mainnet June 10th.
  • At this time, DeFi will be made available to BNB for the first time ever. Also at this time, the Kava DeFi platform will be awarding the first users that have BNB extremely high rewards for being early adopters.
  • Each week, 74,000 KAVA will be given out to all the users who have taken out loans on Kava. Yes, you get free KAVA, for taking out a loan using BNB!
  • If you want to participate, you can learn more about how to do it here!
  • Medium

Q6:

Why should BNB users use KAVA’s lending platform and take out USDX? And how to mint USDX with BNB on KAVA CDP?

  • Answer - Free- maybe let's call it rewards for being good users 😉
  • The rewards are platform growth incentives so that we can grow the platform quickly.
  • Well at launch, definitely the KAVA rewards are a huge reason for BNB users to use it.
  • As for the product long-term, the major use case for our lending platform is to get a levered position without needing an exchange or to go through KYC.
  • How it works is that a BNB holder can deposit their BNB and take out USDX loans - this capital they will take and buy more BNB with it. Most people will use the loan this way to get 2-3x the original BNB amount. If the price goes up on BNB, they win 2-3x the gains!
  • Of course if the price goes down and they cannot repay their loan, the BNB collateral might get liquidated, so be careful, it works just like a margin trading account.

Q7:

Brian do you have any more information or links for our community about this?

Q8:

KAVA was initially planned to launch on Ripple network but later switched to Cosmos Tendermint Core. [email protected] is that something you see in Tendermint Core that is not available anywhere?

  • Answer - For clarification, Kava was never planned to be on Ripple. However, Ripple is a Kava investor, shareholder, and partner.
  • We selected the Cosmos-SDK featuring the Tendermint BFT consensus because during our past work with Ripple, MakerDao, ETH, and other layer 2 work we learned the value of “finality” of blockchains. For example, on ETH, the finality of blocks do not happen right away. You need to reach 15+ blocks to be confirmed on Ethereum to really know a transaction has passed. This results in really slow user experiences that aren’t acceptable in finance or any application really.
  • Tendermint solves this because it makes every transaction final and occur in seconds.
  • Additionally, we chose the Cosmos-SDK as the framework to build our stand alone blockchain, Kava because it allowed us to create our own security model and design which enables Kava as a DeFi platform responsible for millions of dollars of collateral to be very secure in a way we could net get if we built it on any other network.

Q9:

KAVA does cross-chain support. Compared to other DeFi platforms, KAVA offer collateralized loans and stable coins to users too. How will volatility be managed there with so many different collateral systems in CDP?

  • Answer - Volatility is an important consideration and accurate and timely price reference data is needed to make sure the system works.
  • All the collateral positions rely on price feeds from oracles to determine if they are safe or need to be liquidated. Kava has created a novel partnership with Chainlink, where Chainlink oracles that normally run on Ethereum, operate nodes directly on Kava where they can post prices. This Kava to avoid network congestion, high gas fees, and other less desirable issues found on Ethereum, while enabling the oracles with Kava’s fast blocktimes and finality so they can actually deliver price updates 10-20x more frequently than is possible elsewhere. This makes Kava’s price feed data very reliable.
  • In times of volatility, if liquidations occur, the Kava platform automatically auctions collateral off for USDX on the market and burns the USDX. This mechanism keeps the system balanced and USDX algorithmically stable and always fully collateralized by real assets.
  • And it does this transparently, unlike the real world CDOs which caused the world issues in 2008 due to the lack of transparency in their assets and risk.

Q10:

Recently, Binance has released a white paper on BSC, a Binance smart chain. So, what can I get by staking through Binance Coin BNB?

  • Answer - Yay for smart contracts!
  • What can we get by staking bnb?
  • Staking BNB on Kava, or depositing it in a CDP and creating USDX from it earns users KAVA in rewards everyweek. A lot of rewards. In addition, you get USDX to hold which also pays out a savings rate each block that is much better than say what USD in a checking account could do.

Q11:

Various platforms are in Ethereum. So why is Kava not at Ethereum?

  • Answer - I could speak about this for ages, but there is a reason for Ethereum being the home to many hacks and bugs.
  • Kava is not on ethereum because we couldn’t build our system there. The main reasons. as I have mentioned are:
  • (1) Ethereum has congestion, oracle issues, high fees, and slow block times.
  • (2) Ethereum’s open smart contracting system can do anything. This is great for building crypto kitties, but horrible for financial software as it makes all code have infinite attack vectors that hackers can use which are impossible to test for. We built our own chain so we could scope the code and limit what attack vectors are possible.
  • (3) Building in solidity, the language of Ethereum, is horrible. The development environment is bad, testnets don’t work, and many other things are painful. Kava is primarily built in GO which is far superior for financial applications in most respects.
  • (4) The future is Cosmos. Binance, Okchain, terra, Cosmos Hub(ATOM), and Kava all are created using the Cosmos-SDK framework. I believe this is the future and the blockchain developers are moving to this in mass. Over 110 projects now are building with the Cosmos-SDK.

Q12:

What are ways by which Kava project generates profit/revenue to maintain project. What is your revenue model?

  • Answer - Kava is a for-profit financial DAO with over 80 different businesses staking Kava and voting on its evolution. They want to see Kava succeed so they vote to fund operations and developments that drive user growth in Kava. Due to fees paid in Kava and the burning mechanism, as the system grows in users, the Kava supply decreases making those that hold Kava win due to scarcity.

Q13:

Lending/Borrowing has been introduced by Binance. How can this affect the Kava since people can directly borrow BUSD from Binance with BNB used as collateral than going to Kava?

  • Answer - Kava will be featured on Binance as well. The main benefit of Kava is that there is no counterparty. The capital is minted on demand not sourced from somewhere. Binance and other centralized parties on the otherhand need to find capital to provide loans, creating a cost of capital. Kava is much more efficient at providing capital and avoids a lot of regulator issues.
  • I'll add I think BUSD in the future might be usable for collateral to Kava's loans as well. It would be cool 🙂

Q14:

What's your opinions on Future of DeFi & DApps? Do you think that DeFi is the future of current Financial world? Also, How do you see the future of KAVA?

  • Answer - I believe Centralized Finance and the existing infrastructure has a place. It has a lot of issues that cause things like the 2008 crisis and the current insolvency issues that are happening across the world due to trust-based debt with no actual backers other than the people which end up bailing out banks and other financial institutions that have made poor decisions.
  • DeFi's future is bright because it solves this fundamental issue. It removes trust and adds transparency. Kava is right at the foundation for all of DeFi as things grow and mature.

Q15:

Recently, we have seen some big hacks in DeFi platforms. How will KAVA deal with these bad actors of crypto and what security measures have been taken by KAVA for the safety of users' funds?"

  • Answer - Unlike a lot of DeFi startups, we take things seriously. We don't ""move fast and break things"" as Mark Zuckerberg would say.
  • We do a thorough analysis before suggesting to deploy code. Our internal team works very hard to run tests and simulations, once it passes internally, we give it to 3rd party auditors who try and game it and break the code. If it passes there, we give the code to the community to review and vote into the mainnet. In this way, I’d estimate about 100+ people review our code and test it before it goes live and consumers can touch it. I don't know many other project teams that due things with such diligence.

Q16:

Binance for KAVA is a very valuable partner in terms of increasing the number of users, but what is KAVA ready to give equivalent to Binance users? What applications will be integrated into Binance to expand the ecosystem?

  • Answer - Kava gives the BNB users loans. It gives the DEX a stablecoin and the ability to offer margin products. Kava’s connection to binance chain and chainlink data also enables Binance DEX to offer trustless derivatives like options and futures products going forward.

Q17:

Cosmos has limitations on working with PoW coins. How do you technically solve the problem of implementing DeFi products for bitcoin?

  • Answer - Cosmos is great for hard-to-work-with blockchains like BTC. It's flexible in how you can construct bridges. For example, the validator set can have a multisig private key split up into pieces in order to create a trustless escrow and control of assets on other blockchains. In this way, we can create peg zones with Cosmos for the best assets in the world. Once a zone is established, it can be used on Kava and other Cosmos chains.

Q18:

USDX is currently a little-known stable coin. Do you plan to add it to the top exchanges with good liquidity, including Binance?

  • Answer - USDX will be growing quickly. We have a plan to have it listed and get liquidity across several known exchanges shortly after launch.

Q19:

There are several options for using USDX on the KAVA platform, one of which is Margin Trading / Leverage. Is this a selection function or a compulsory function? Wondering since there are some investors who don`t like margin. What is the level of leverage and how does a CDP auction work?

  • Answer - Using Kava for Margin trading is 100% optional. You can choose how you want to use the margin loan. You don’t have to spend the USDX unless you want to. It could be used for everyday payments as well in the case you simply don’t want to sell your underlying collateral. If you don’t want the risk, do small loans with lots of collateral.

Q20:

Will your team have a plan to implement the DAO module on your platform, as it provides autonomy, decentralization and transparency?

  • Answer - DAO - Kava is a for-profit DAO and it’s fully functional already. We have on-chain governance and have underwent several votes and evolutions you can look at. You actually can see some current voting processes taking place here: https://kava.mintscan.io/proposals
  • We recently implemented a cool feature called committees, which enables the DAO to elect a small group of experts to make decisions without needing a vote of the whole user base. This enables the experts to have control over a small portion of the protocol - such as monitoring the debt limit, fees, etc and enables Kava to operate faster and be more adaptable in volatile market conditions.

Q21:

How can we address the possible overloads and security threats caused by increased users in the DeFi scene?

  • Answer - Yes, this is a huge issue for Ethereum, MakerDAO and everyone in the space. I don’t see a bright future for DeFi on Etheruem unfortunately. You can’t have a blockchain do everything well. Tether alone congests most of Ethereum and makes oracle price feeds lag the market. This can cause liquidations that should not happen and real people will lose real funds. It’s a huge issue.
  • The hope is for a dedicated system like Kava to provide a better backbone for DeFi applications going forward.
  • I should point out that Kava is not just a MakerDao for Cosmos or a CDP for Bitcoin. Kava is designed to be a foundational layer for DeFi services that every new blockchain and application will need.
  • Every blockchain will need DeFi services like lending, stablecoins, and data and they need it to be very secure. Kava does all this with its cross-chain lending plarform, USDX stablecoin, and Chainlink data in an incredibly secure, but accessible manner.
  • In this way, Kava aims to connect and serve all the major cryptocurrency communities and build it’s place at the center, where every developer can get what they need to build financial applications of the future."

Q22:

What distinguishes Kava from your existing competitors like Syntetix?

  • Answer - Synthetix isn't really a competitor, but it is an interesting project in terms of mechanism design. We share a lot of common investors and have similar token economic ideas with them. The only blockchain project that could be is MakerDAO, but they can only work with ETH assets due to their design. We are focused on the major cap assets - BTC, BNB, XRP, ATOM and others have a much larger market than ETH to address. BTC is 10x the size alone. Currently no one serves them with DeFi. We’re going after this opportunity and believe it to be a huge one.

Q23:

Why is the KAVA coin not used for Mint, why am I asking that because I see it can also make the value of KAVA coins grow naturally?

  • Answer - Why is Kava not used as a collateral? Well, it could be I suppose. The community might vote for this in the near future if they want us to be like synthetix. It makes the Kava token more valuable and it will incentivize much more locked-up Kava reducing overall circulating supply which is fairly favorable. The main reason we have not done this yet is that we(Kava and its community) are still weighing the risks of doing this given that Kava also functions as a reserve asset. I think it's likely Kava gets added as collateral at some point, but it will likely have a high debt-collateral ratio to address the issues similar to Synthetix which is 750%.

Q24:

How do you prevent in a manipulated KAVA Mint just to take advantage of a token prize when minting?

  • Answer - Minting rewards and manipulation. We’ve thought of this. Each week, the blockchain counts all the blocks, counts how many people had a loan in that period, then takes the average loan amount over time to calculate the rewards. If you open and close a loan - you will get very little rewards. You only get a large reward if you keep the loan open the full period.

Q25:

Who are your oracle providers? Are you also an oracle provider?

  • Answer - Kava may run 1 oracle in the future, but we will always have many and be the minority. Most chainlink oracle node operators are large players in the space that run staking infrastructure companies like cosmostation, chainlayer, chorus one, figment networks, etc. Binance will also be one of our oracles.

Q26:

If we look at all the different types of DeFi products _(decentralized exchanges, stablecoins, atomic swaps, insurance products, loan platforms, trade financing platforms, custody platforms, and crowdfunding platforms) currently covering important areas of traditional finance...where does Kava fit in?

  • Answer - To make any interesting financial product work you need capital, a stable store of value, and price data. These are really hard to get on current blockchain environments. Kava provides all of these.

Q27:

Many people describe Kava as similar to Maker (MKR). How is Kava different? Why do you think Kava has more potential?

  • Answer - MakerDAO is a smart contract with a singular purpose, to serve ETH. It sadly inherited the problems of ethereum. Kava is designed from the ground up for security and interoperability. We are targeting bigger and better assets and have more capabilities to serve them with what their developers and ecosystem need.

Q28:

What is the uniqueness of KAVA project that cannot be found in other project that´s been released so far ?

  • Answer - Well in June 10th, we will be the first ever blockchain project to bring DeFi to another blockchain in a real way. BNB users will have loans, stablecoins, and much more.

Q29:

The gas fee is an issue for blockchain besides scalability. Does your Kava provide a solution for gas?

  • Answer - gas fees are very low on Kava, only high enough to prevent spam. We dont need high fees for TX because validators are paid in block rewards. Additionally, we dont have competing transactions from crypto-kitties or other non-financial applications. This leaves all of Kava's throughput 100% dedicated to scaling financial transactions.

Q30:

Kava project works on DeFi (Decentralized Finance) But what’s the benefits of Decentralized Financial system? What are the possibilities of DeFi over Centralized Finance system?

  • Answer - Open access, no need for trust, and no censorship by singular governments or parties. Kava is accessible anywhere in the world, by anyone.

Q31:

Data supplied by oracles are false at times, how do you prevent this? How reliable are data received by KAVA?

  • Answer - This is why using premium / credentialed APIs is important for oracles. These data sources tend to be more accurate and better managed. Wrong prices can happen - for liquidation systems like Kava, we factor this into our design by using an average of data overtime form all oracles as part of the calculation.

Q32:

Can anyone become a KAVA validator, or is it just an invitation from the project itself? What are the requirements for becoming a KAVA verifier?

  • Answer - Anyone can become a validator, but you will need to stake or have enough stake delegated to you from others to be in the top 100 validators to earn block rewards.

Q33:

DEFI PULSE said that a total of 902M is currently locked. According to you, how will this number change in the next few years, and how will KAVA position itself as the top player in this market segment?

  • Answer - DeFi will only grow through 2020. And likely grow massively.
  • All projects on DeFi pulse are ""ethereum"" based. Kava is going to shake the blockchain world in the next few weeks by being the first ""multi-chain"" project on DeFi pulse and by my estimations we should quickly surpass a lot of the projects on that list.

Q34:

I am an testnet minter and the process seem Simplified, now I want to know if minting of USDX will continue when you launch Mainnet and do you have plans to build your own KAVA WALLET for easy minting on your mainnet

  • Answer - Simple blockchain experience?! high praise! Yes the process will be the same. Kava will not provide interfaces or wallets. Kava Labs builds software for the blockchain, our community members like Cosmostation, Frontier, Trust Wallet build support for people to interact with it.

Q35:

What business plans does Kava have with Seoul (South Korea) after partnering with Cosmostation? Do you plan to expand your products beyond Asia? Have you thought about harnessing the potential of South America?

  • Answer - South Korea is a perfect market for Kava's DeFi. Regulations prohibit fiat-backed stablecoins and margin trading. Kava's platform uses crypto-backed stabvlecoins and can enable users to get loans to margin trade. I am looking forward to further developing the Korean market for Kava, working with close partners like Cosmostation and showing the world real use cases of DeFi.

Q36:

Thank you for taking the time to conduct this AMA. Do you have any parting words, and where can the people go to keep up with all of the new happenings regarding Kava Labs?

  • Answer - Thanks for all the awesome questions! Amazingly thoughtful!
  • I've been promising the world cross-chain DeFi since June of last year. The IEO and mainnet went live Nov 2019. It's been a year of hard work - but an industry first is coming on June 10th. I'm excited. I hope you guys are.
  • Thanks for having me, I hope you become a USDX minter and get KAVA rewards. And last but not least, I love Binance - it's Kava's first home and I'm really happy to open up DeFi to BNB first.
  • To keep up to date w/ all things Kava: Website - Telegram - Telegram for Kava Trading Chat - Twitter - Medium
submitted by Kava_Mod to KavaUSDX [link] [comments]

XRPL MultiSigning Tool: demo Advanced Bitcoin Scripting -- Part 2: SegWit, Consensus, & Trustware Ryan Singer from CryptoCorp reveals their Bitcoin MultiSig features Bitcoin M-of-N Multisig Addresses - Well Tempered Hacker SF Bitcoin Devs Seminar: The BitGO API: A deep dive into Advanced Multisig!

Some examples of Multi Signatures in real life. Say a company desires to set up a Bitcoin wallet accessible by 3 of its employees, but requires 2 of them to be involved in any transaction exceeding $5,000. To do so, it creates a 2-of-3 multi-sig address where it holds one key and an outside policy-enforcer holds another. This process increases accountability and transparency among the ... An example for Darkcoin Core and Bitcoin Core wallets. Setting up a multisig address is super easy with Qt wallets. Receiving funds works exactly as it does when receiving them in a regular address. Spending is a bit trickier, but it can be easily mastered. It will take 30 minutes the first time and 5 once you are used to it. This is probably not the place for a super detailed step-by-step ... BitGo is a multisig Bitcoin wallet with a simple and intuitive interface and a high level of security. This multisig wallet got on the road in 2013 by BitGo Inc, the company that specializes in blockchain technology security. The wallet developers are the company co-founders Mike Belshe and Ben Davenport. BitGo represents the tools necessary for the purchase and management of cryptocurrency ... Bitcoin Multisig Script Examples Smartbit Bitcoin Addresses. Example code for iterating through the Blockchain and appears in the Blockchain is a or multisig script,41 with oneThese are the top rated real world PHP examples of bitwasp\bitcoin\script\ScriptFactory::multisig extracted from open source projects. This site aims to provide the docs you need to understand Bitcoin and start building Bitcoin-based applications.

[index] [27839] [47993] [42877] [38796] [22756] [37234] [41703] [22507] [19748] [41869]

XRPL MultiSigning Tool: demo

This is the first part of a more technical talk where Andreas explores Bitcoin script, with examples from the 2nd edition of Mastering Bitcoin, focusing on the use of conditional statements, flow ... https://www.e-coin.io Fiat and Digital currencies in one card. Another example might be a company wallet has 3 keys, 1 for the CEO, 1 for the CFO and one for the Accountant and the wallet requires any 2 of these 3 keys in order to send bitcoins. This would be ... So this doesn’t mean Bitcoin is going to go away. It just means Bitcoin and Bitcoin Cash offer different features which will suit different use cases. [orange] So this is people actually buying ... REST API concepts and examples - Duration: 8:53. WebConcepts Recommended for you. 8:53. ... How to create and use Multi Sig Bitcoin Wallets - Duration: 10:23. Hodl Hodl 5,580 views. 10:23 . Off ...

#