How to calculate transaction size before sending (Legacy ...

[OWL WATCH] Waiting for "IOTA TIME" 20; Hans's re-defined directions for DLT

Disclaimer: This is my editing, so there could be some misunderstandings...
--------------------------------------------
wellwho오늘 오후 4:50
u/Ben Royce****how far is society2 from having something clickable powered by IOTA?
Ben Royce오늘 오후 4:51
demo of basic tech late sep/ early oct. MVP early 2021
---------------------------------------------------
HusQy
Colored coins are the most misunderstood upcoming feature of the IOTA protocol. A lot of people see them just as a competitor to ERC-20 tokens on ETH and therefore a way of tokenizing things on IOTA, but they are much more important because they enable "consensus on data".
Bob
All this stuff already works on neblio but decentralized and scaling to 3500 tps
HusQy
Neblio has 8 mb blocks with 30 seconds blocktime. This is a throughput of 8 mb / 30 seconds = 267 kb per second. Transactions are 401+ bytes which means that throughput is 267 kb / 401 bytes = 665 TPS. IOTA is faster, feeless and will get even faster with the next update ...
-----------------------------------------------------------------------------
HusQy
Which DLT would be more secure? One that is collaboratively validated by the economic actors of the world (coporations, companies, foundations, states, people) or one that is validated by an anonymous group of wealthy crypto holders?
HusQy
The problem with current DLTs is that we use protection mechanisms like Proof of Work and Proof of Stake that are inherently hard to shard. The more shards you have, the more you have to distribute your hashing power and your stake and the less secure the system becomes.
HusQy
Real world identities (i.e. all the big economic actors) however could shard into as many shards as necessary without making the system less secure. Todays DLTs waste trust in the same way as PoW wastes energy.
HusQy
Is a secure money worth anything if you can't trust the economic actors that you would buy stuff from? If you buy a car from Volkswagen and they just beat you up and throw you out of the shop after you payed then a secure money won't be useful either :P
HusQy
**I believe that if you want to make DLT work and be successful then we need to ultimately incorporate things like trust in entities into the technology.**Examples likes wirecard show that trusting a single company is problematic but trusting the economy as a whole should be at ...
**... least as secure as todays DLTs.**And as soon as you add sharding it will be orders of magnitude more secure. DLT has failed to deliver because people have tried to build a system in vacuum that completely ignores things that already exist and that you can leverage on.
----------------------------------------------------------------------------------
HusQy
Blockchain is a bit like people sitting in a room, trying to communicate through BINGO sheets. While they talk, they write down some of the things that have been said and as soon as one screams BINGO! he hands around his sheet to inform everybody about what has been said.
HusQy
If you think that this is the most efficient form of communication for people sitting in the same room and the answer to scalability is to make bigger BINGO sheets or to allow people to solve the puzzle faster then you will most probably never understand what IOTA is working on.
--------------------------------------------------------------------------------
HusQy
**Blockchain does not work with too many equally weighted validators.****If 400 validators produce a validating statement (block) at the same time then only one can survive as part of a longest chain.**IOTA is all about collaborative validation.
**Another problem of blockchain is that every transaction gets sent twice through the network. Once from the nodes to the miners and a 2nd time from the miners as part of a block.**Blockchain will therefore always only be able to use 50% of the network throughput.
And****the last problem is that you can not arbitrarily decrease the time between blocks as it breaks down if the time between blocks gets smaller than the average network delay. The idle time between blocks is precious time that could be used for processing transactions.
-----------------------------------------------------------------------------
HusQy
I am not talking about a system with a fixed number of validators but one that is completely open and permissionless where any new company can just spin up a node and take part in the network.
------------------------------------------------------------------------
HusQy
Proof of Work and Proof of Stake are both centralizing sybil-protection mechanism. I don't think that Satoshi wanted 14 mining pools to run the network.
And "economic clustering" was always the "end game" of IOTA.
-----------------------------------------------------------------------------
HusQy
**Using Proof of Stake is not trustless. Proof of Stake means you trust the richest people and hope that they approve your transactions. The rich are getting richer (through your fees) and you are getting more and more dependant on them.**Is that your vision of the future?
----------------------------------------------------------------------------

HusQy
Please read again exactly what I wrote. I have not spoken of introducing governance by large companies, nor have I said that IOTA should be permissioned. We aim for a network with millions or even billions of nodes.

HusQy
That can't work at all with a permissioned ledger - who should then drop off all these devices or authorize them to participate in the network? My key message was the following: Proof of Work and Proof of Stake will always be if you split them up via sharding ...

HusQy
... less secure because you simply need fewer coins or less hash power to have the majority of the votes in a shard. This is not the case with trust in society and the economy. When all companies in the world jointly secure a DLT ...

HusQy
... then these companies could install any number of servers in any number of shards without compromising security, because "trust" does not become less just because they operate several servers. First of all, that is a fact and nothing else.

HusQy
Proof of Work and Proof of Stake are contrary to the assumption of many not "trustless" but follow the maxim: "In the greed of miners we trust!" The basic assumption that the miners do not destroy the system that generates income for them is fundamental here for the ...

HusQy
... security of every DLT. I think a similar assumption would still be correct for the economy as a whole: The companies of the world (and not just the big ones) would not destroy the system with which their customers pay them. In this respect, a system would be ...

HusQy
... which is validated by society and the economy as a whole probably just as "safely" as a system which is validated by a few anonymous miners. Why a small elite of miners should be better validators than any human and ...

HusQy
... To be honest, companies in this world do not open up to me. As already written in my other thread, safe money does not bring you anything if you have to assume that Volkswagen will beat you up and throw you out of the store after you ...

HusQy
... paid for a car. The thoughts I discussed say nothing about the immediate future of IOTA (we use for Coordicide mana) but rather speak of a world where DLT has already become an integral part of our lives and we ...

HusQy
... a corresponding number of companies, non-profit organizations and people have used DLT and where such a system could be implemented. The point here is not to create a governance solution that in any way influences the development of technology ...

HusQy
... or have to give nodes their OK first, but about developing a system that enables people to freely choose the validators they trust. For example, you can also declare your grandma to be a validator when you install your node or your ...

HusQy
... local supermarket. Economic relationships in the real world usually form a close-knit network and it doesn't really matter who you follow as long as the majority is honest. I also don't understand your criticism of censorship, because something like that in IOTA ...

HusQy
... is almost impossible. Each transaction confirms two other transactions which is growing exponentially. If someone wanted to ignore a transaction, he would have to ignore an exponential number of other transactions after a very short time. In contrast to blockchain ...

HusQy
... validators in IOTA do not decide what is included in the ledger, but only decide which of several double spends should be confirmed. Honest transactions are confirmed simply by having other transactions reference them ...

HusQy
... and the "validators" are not even asked. As for the "dust problem", this is indeed something that is a bigger problem for IOTA than for other DLTs because we have no fees, but it is also not an unsolvable problem. Bitcoin initially has a ...

HusQy
Solved similar problem by declaring outputs with a minimum amount of 5430 satoshis as invalid ( github.com/Bitcoin/Bitcoi…). A similar solution where an address must contain a minimum amount is also conceivable for IOTA and we are discussing ...

HusQy
... several possibilities (including compressing dust using cryptographic methods). Contrary to your assumption, checking such a minimum amount is not slow but just as fast as checking a normal transaction. And mine ...

HusQy
... In my opinion this is no problem at all for IOTA's use case. The important thing is that you can send small amounts, but after IOTA is feeless it is also okay to expect the recipients to regularly send their payments on a ...

HusQy
... merge address. The wallets already do this automatically (sweeping) and for machines it is no problem to automate this process. So far this was not a problem because the TPS were limited but with the increased TPS throughput of ...

HusQy
... Chrysalis it becomes relevant and appropriate solutions are discussed and then implemented accordingly. I think that was the most important thing first and if you have further questions just write :)

HusQy
And to be very clear! I really appreciate you and your questions and don't see this as an attack at all! People who see such questions as inappropriate criticism should really ask whether they are still objective. I have little time at the moment because ...

HusQy
... my girlfriend is on tour and has to take care of our daughter, but as soon as she is back we can discuss these things in a video. I think that the concept of including the "real world" in the concepts of DLT is really exciting and ...

HusQy
... that would certainly be exciting to discuss in a joint video. But again, that's more of a vision than a specific plan for the immediate future. This would not work with blockchain anyway but IOTA would be compatible so why not think about such things.
-----------------------------------------------------------------------

HusQy
All good my big one :P But actually not that much has changed. There has always been the concept of "economic clustering" which is basically based on similar ideas. We are just now able to implement things like this for the first time.
----------------------------------------------------------------------------------

HusQy
Exactly. It would mean that addresses "cost" something but I would rather pay a few cents than fees for each transaction. And you can "take" this minimum amount with you every time you change to a new address.

HusQy
All good my big one :P But actually not that much has changed. There has always been the concept of "economic clustering" which is basically based on similar ideas. We are just now able to implement things like this for the first time.
-----------------------------------------------------------------------------------

Relax오늘 오전 1:17
Btw. Hans (sorry for interrupting this convo) but what make people say that IOTA is going the permissioned way because of your latest tweets? I don't get why some people are now forecasting that... Is it because of missing specs or do they just don't get the whole idea?

Hans Moog [IF]오늘 오전 1:20
its bullshit u/Relaxan identity based system would still be open and permissionless where everybody can choose the actors that they deem trustworthy themselves but thats anyway just sth that would be applicable with more adoption
[오전 1:20]
for now we use mana as a predecessor to an actual reputation system

Sissors오늘 오전 1:31
If everybody has to choose actors they deem trustworthy, is it still permissionless? Probably will become a bit a semantic discussion, but still

Hans Moog [IF]오늘 오전 1:34
Of course its permissionless you can follow your grandma if you want to :p

Sissors오늘 오전 1:36
Well sure you can, but you will need to follow something which has a majority of the voting power in the network. Nice that you follow your grandma, but if others dont, her opinion (or well her nodes opinion) is completely irrelevant

Hans Moog [IF]오늘 오전 1:37
You would ideally follow the people that are trustworthy rather than your local drug dealers yeah

Sissors오늘 오전 1:38
And tbh, sure if you do it like that is easy. If you just make the users responsible for only connection to trustworthy nodes

Hans Moog [IF]오늘 오전 1:38
And if your grandma follows her supermarket and some other people she deems trustworthy then thats fine as well
[오전 1:38]
+ you dont have just 1 actor that you follow

Sissors오늘 오전 1:38
No, you got a large list, since yo uwant to follow those which actually matter. So you jsut download a standard list from the internet

Hans Moog [IF]오늘 오전 1:39
You can do that
[오전 1:39]
Is bitcoin permissionless? Should we both try to become miners?
[오전 1:41]
I mean miners that actually matter and not find a block every 10 trillion years 📷
[오전 1:42]
If you would want to become a validator then you would need to build up trust among other people - but anybody can still run a node and issue transactions unlike in hashgraph where you are not able to run your own nodes(수정됨)
[오전 1:48]
Proof of Stake is also not trustless - it just has a builtin mechanism that downloads the trusted people from the blockchain itself (the richest dudes)

Sissors오늘 오전 1:52
I think most agree it would be perfect if every person had one vote. Which is pr oblematic to implement of course. But I really wonder if the solution is to just let users decide who to trust. At the very least I expect a quite centralized network

Hans Moog [IF]오늘 오전 1:53
of course even a trust based system would to a certain degree be centralized as not every person is equally trustworthy as for example a big cooperation
[오전 1:53]
but I think its gonna be less centralized than PoS or PoW
[오전 1:53]
but anyway its sth for "after coordicide"
[오전 1:54]
there are not enough trusted entities that are using DLT, yet to make such a system work reasonably well
[오전 1:54]
I think the reason why blockchain has not really started to look into these kind of concepts is because blockchain doesnt work with too many equally weighted validators
[오전 1:56]
I believe that DLT is only going to take over the world if it is actually "better" than existing systems and with better I mean cheaper, more secure and faster and PoS and PoW will have a very hard time to deliver that
[오전 1:56]
especially if you consider that its not only going to settle value transfers

Relax오늘 오전 1:57
I like this clear statements, it makes it really clear that DLT is still in its infancy

Hans Moog [IF]오늘 오전 1:57
currently bank transfers are order of magnitude cheaper than BTC or ETH transactions

Hans Moog [IF]오늘 오전 1:57
and we you think that people will adopt it just because its crypto then I think we are mistaken
[오전 1:57]
The tech needs to actually solve a problem
[오전 1:57]
and tbh. currently people use PayPal and other companies to settle their payments
[오전 1:58]
having a group of the top 500 companies run such a service together is already much better(수정됨)
[오전 1:58]
especially if its fast and feeless
[오전 2:02]
and the more people use it, the more decentralized it actually becomes
[오전 2:02]
because you have more trustworthy entities to choose of

Evaldas [IF]오늘 오전 2:08
"in the greed of miners we trust"


submitted by btlkhs to Iota [link] [comments]

Scaling Reddit Community Points with Arbitrum Rollup: a piece of cake

Scaling Reddit Community Points with Arbitrum Rollup: a piece of cake
https://preview.redd.it/b80c05tnb9e51.jpg?width=2550&format=pjpg&auto=webp&s=850282c1a3962466ed44f73886dae1c8872d0f31
Submitted for consideration to The Great Reddit Scaling Bake-Off
Baked by the pastry chefs at Offchain Labs
Please send questions or comments to [[email protected] ](mailto:[email protected])
1. Overview
We're excited to submit Arbitrum Rollup for consideration to The Great Reddit Scaling Bake-Off. Arbitrum Rollup is the only Ethereum scaling solution that supports arbitrary smart contracts without compromising on Ethereum's security or adding points of centralization. For Reddit, this means that Arbitrum can not only scale the minting and transfer of Community Points, but it can foster a creative ecosystem built around Reddit Community Points enabling points to be used in a wide variety of third party applications. That's right -- you can have your cake and eat it too!
Arbitrum Rollup isn't just Ethereum-style. Its Layer 2 transactions are byte-for-byte identical to Ethereum, which means Ethereum users can continue to use their existing addresses and wallets, and Ethereum developers can continue to use their favorite toolchains and development environments out-of-the-box with Arbitrum. Coupling Arbitrum’s tooling-compatibility with its trustless asset interoperability, Reddit not only can scale but can onboard the entire Ethereum community at no cost by giving them the same experience they already know and love (well, certainly know).
To benchmark how Arbitrum can scale Reddit Community Points, we launched the Reddit contracts on an Arbitrum Rollup chain. Since Arbitrum provides full Solidity support, we didn't have to rewrite the Reddit contracts or try to mimic their functionality using an unfamiliar paradigm. Nope, none of that. We launched the Reddit contracts unmodified on Arbitrum Rollup complete with support for minting and distributing points. Like every Arbitrum Rollup chain, the chain included a bridge interface in which users can transfer Community Points or any other asset between the L1 and L2 chains. Arbitrum Rollup chains also support dynamic contract loading, which would allow third-party developers to launch custom ecosystem apps that integrate with Community Points on the very same chain that runs the Reddit contracts.
1.1 Why Ethereum
Perhaps the most exciting benefit of distributing Community Points using a blockchain is the ability to seamlessly port points to other applications and use them in a wide variety of contexts. Applications may include simple transfers such as a restaurant that allows Redditors to spend points on drinks. Or it may include complex smart contracts -- such as placing Community Points as a wager for a multiparty game or as collateral in a financial contract.
The common denominator between all of the fun uses of Reddit points is that it needs a thriving ecosystem of both users and developers, and the Ethereum blockchain is perhaps the only smart contract platform with significant adoption today. While many Layer 1 blockchains boast lower cost or higher throughput than the Ethereum blockchain, more often than not, these attributes mask the reality of little usage, weaker security, or both.
Perhaps another platform with significant usage will rise in the future. But today, Ethereum captures the mindshare of the blockchain community, and for Community Points to provide the most utility, the Ethereum blockchain is the natural choice.
1.2 Why Arbitrum
While Ethereum's ecosystem is unmatched, the reality is that fees are high and capacity is too low to support the scale of Reddit Community Points. Enter Arbitrum. Arbitrum Rollup provides all of the ecosystem benefits of Ethereum, but with orders of magnitude more capacity and at a fraction of the cost of native Ethereum smart contracts. And most of all, we don't change the experience from users. They continue to use the same wallets, addresses, languages, and tools.
Arbitrum Rollup is not the only solution that can scale payments, but it is the only developed solution that can scale both payments and arbitrary smart contracts trustlessly, which means that third party users can build highly scalable add-on apps that can be used without withdrawing money from the Rollup chain. If you believe that Reddit users will want to use their Community Points in smart contracts--and we believe they will--then it makes the most sense to choose a single scaling solution that can support the entire ecosystem, eliminating friction for users.
We view being able to run smart contracts in the same scaling solution as fundamentally critical since if there's significant demand in running smart contracts from Reddit's ecosystem, this would be a load on Ethereum and would itself require a scaling solution. Moreover, having different scaling solutions for the minting/distribution/spending of points and for third party apps would be burdensome for users as they'd have to constantly shuffle their Points back and forth.
2. Arbitrum at a glance
Arbitrum Rollup has a unique value proposition as it offers a combination of features that no other scaling solution achieves. Here we highlight its core attributes.
Decentralized. Arbitrum Rollup is as decentralized as Ethereum. Unlike some other Layer 2 scaling projects, Arbitrum Rollup doesn't have any centralized components or centralized operators who can censor users or delay transactions. Even in non-custodial systems, centralized components provide a risk as the operators are generally incentivized to increase their profit by extracting rent from users often in ways that severely degrade user experience. Even if centralized operators are altruistic, centralized components are subject to hacking, coercion, and potential liability.
Massive Scaling. Arbitrum achieves order of magnitude scaling over Ethereum's L1 smart contracts. Our software currently supports 453 transactions-per-second for basic transactions (at 1616 Ethereum gas per tx). We have a lot of room left to optimize (e.g. aggregating signatures), and over the next several months capacity will increase significantly. As described in detail below, Arbitrum can easily support and surpass Reddit's anticipated initial load, and its capacity will continue to improve as Reddit's capacity needs grow.
Low cost. The cost of running Arbitrum Rollup is quite low compared to L1 Ethereum and other scaling solutions such as those based on zero-knowledge proofs. Layer 2 fees are low, fixed, and predictable and should not be overly burdensome for Reddit to cover. Nobody needs to use special equipment or high-end machines. Arbitrum requires validators, which is a permissionless role that can be run on any reasonable on-line machine. Although anybody can act as a validator, in order to protect against a “tragedy of the commons” and make sure reputable validators are participating, we support a notion of “invited validators” that are compensated for their costs. In general, users pay (low) fees to cover the invited validators’ costs, but we imagine that Reddit may cover this cost for its users. See more on the costs and validator options below.
Ethereum Developer Experience. Not only does Arbitrum support EVM smart contracts, but the developer experience is identical to that of L1 Ethereum contracts and fully compatible with Ethereum tooling. Developers can port existing Solidity apps or write new ones using their favorite and familiar toolchains (e.g. Truffle, Buidler). There are no new languages or coding paradigms to learn.
Ethereum wallet compatibility. Just as in Ethereum, Arbitrum users need only hold keys, but do not have to store any coin history or additional data to protect or access their funds. Since Arbitrum transactions are semantically identical to Ethereum L1 transactions, existing Ethereum users can use their existing Ethereum keys with their existing wallet software such as Metamask.
Token interoperability. Users can easily transfer their ETH, ERC-20 and ERC-721 tokens between Ethereum and the Arbitrum Rollup chain. As we explain in detail below, it is possible to mint tokens in L2 that can subsequently be withdrawn and recognized by the L1 token contract.
Fast finality. Transactions complete with the same finality time as Ethereum L1 (and it's possible to get faster finality guarantees by trading away trust assumptions; see the Arbitrum Rollup whitepaper for details).
Non-custodial. Arbitrum Rollup is a non-custodial scaling solution, so users control their funds/points and neither Reddit nor anyone else can ever access or revoke points held by users.
Censorship Resistant. Since it's completely decentralized, and the Arbitrum protocol guarantees progress trustlessly, Arbitrum Rollup is just as censorship-proof as Ethereum.
Block explorer. The Arbitrum Rollup block explorer allows users to view and analyze transactions on the Rollup chain.
Limitations
Although this is a bake-off, we're not going to sugar coat anything. Arbitrum Rollup, like any Optimistic Rollup protocol, does have one limitation, and that's the delay on withdrawals.
As for the concrete length of the delay, we've done a good deal of internal modeling and have blogged about this as well. Our current modeling suggests a 3-hour delay is sufficient (but as discussed in the linked post there is a tradeoff space between the length of the challenge period and the size of the validators’ deposit).
Note that this doesn't mean that the chain is delayed for three hours. Arbitrum Rollup supports pipelining of execution, which means that validators can keep building new states even while previous ones are “in the pipeline” for confirmation. As the challenge delays expire for each update, a new state will be confirmed (read more about this here).
So activity and progress on the chain are not delayed by the challenge period. The only thing that's delayed is the consummation of withdrawals. Recall though that any single honest validator knows immediately (at the speed of L1 finality) which state updates are correct and can guarantee that they will eventually be confirmed, so once a valid withdrawal has been requested on-chain, every honest party knows that the withdrawal will definitely happen. There's a natural place here for a liquidity market in which a validator (or someone who trusts a validator) can provide withdrawal loans for a small interest fee. This is a no-risk business for them as they know which withdrawals will be confirmed (and can force their confirmation trustlessly no matter what anyone else does) but are just waiting for on-chain finality.
3. The recipe: How Arbitrum Rollup works
For a description of the technical components of Arbitrum Rollup and how they interact to create a highly scalable protocol with a developer experience that is identical to Ethereum, please refer to the following documents:
Arbitrum Rollup Whitepaper
Arbitrum academic paper (describes a previous version of Arbitrum)
4. Developer docs and APIs
For full details about how to set up and interact with an Arbitrum Rollup chain or validator, please refer to our developer docs, which can be found at https://developer.offchainlabs.com/.
Note that the Arbitrum version described on that site is older and will soon be replaced by the version we are entering in Reddit Bake-Off, which is still undergoing internal testing before public release.
5. Who are the validators?
As with any Layer 2 protocol, advancing the protocol correctly requires at least one validator (sometimes called block producers) that is honest and available. A natural question is: who are the validators?
Recall that the validator set for an Arbitrum chain is open and permissionless; anyone can start or stop validating at will. (A useful analogy is to full nodes on an L1 chain.) But we understand that even though anyone can participate, Reddit may want to guarantee that highly reputable nodes are validating their chain. Reddit may choose to validate the chain themselves and/or hire third-party validators.To this end, we have begun building a marketplace for validator-for-hire services so that dapp developers can outsource validation services to reputable nodes with high up-time. We've announced a partnership in which Chainlink nodes will provide Arbitrum validation services, and we expect to announce more partnerships shortly with other blockchain infrastructure providers.
Although there is no requirement that validators are paid, Arbitrum’s economic model tracks validators’ costs (e.g. amount of computation and storage) and can charge small fees on user transactions, using a gas-type system, to cover those costs. Alternatively, a single party such as Reddit can agree to cover the costs of invited validators.
6. Reddit Contract Support
Since Arbitrum contracts and transactions are byte-for-byte compatible with Ethereum, supporting the Reddit contracts is as simple as launching them on an Arbitrum chain.
Minting. Arbitrum Rollup supports hybrid L1/L2 tokens which can be minted in L2 and then withdrawn onto the L1. An L1 contract at address A can make a special call to the EthBridge which deploys a "buddy contract" to the same address A on an Arbitrum chain. Since it's deployed at the same address, users can know that the L2 contract is the authorized "buddy" of the L1 contract on the Arbitrum chain.
For minting, the L1 contract is a standard ERC-20 contract which mints and burns tokens when requested by the L2 contract. It is paired with an ERC-20 contract in L2 which mints tokens based on whatever programmer provided minting facility is desired and burns tokens when they are withdrawn from the rollup chain. Given this base infrastructure, Arbitrum can support any smart contract based method for minting tokens in L2, and indeed we directly support Reddit's signature/claim based minting in L2.
Batch minting. What's better than a mint cookie? A whole batch! In addition to supporting Reddit’s current minting/claiming scheme, we built a second minting design, which we believe outperforms the signature/claim system in many scenarios.
In the current system, Reddit periodically issues signed statements to users, who then take those statements to the blockchain to claim their tokens. An alternative approach would have Reddit directly submit the list of users/amounts to the blockchain and distribute the tokens to the users without the signature/claim process.
To optimize the cost efficiency of this approach, we designed an application-specific compression scheme to minimize the size of the batch distribution list. We analyzed the data from Reddit's previous distributions and found that the data is highly compressible since token amounts are small and repeated, and addresses appear multiple times. Our function groups transactions by size, and replaces previously-seen addresses with a shorter index value. We wrote client code to compress the data, wrote a Solidity decompressing function, and integrated that function into Reddit’s contract running on Arbitrum.
When we ran the compression function on the previous Reddit distribution data, we found that we could compress batched minting data down to to 11.8 bytes per minting event (averaged over a 6-month trace of Reddit’s historical token grants)compared with roughly 174 bytes of on-chain data needed for the signature claim approach to minting (roughly 43 for an RLP-encoded null transaction + 65 for Reddit's signature + 65 for the user's signature + roughly 8 for the number of Points) .
The relative benefit of the two approaches with respect to on-chain call data cost depends on the percentage of users that will actually claim their tokens on chain. With the above figures, batch minting will be cheaper if roughly 5% of users redeem their claims. We stress that our compression scheme is not Arbitrum-specific and would be beneficial in any general-purpose smart contract platform.
8. Benchmarks and costs
In this section, we give the full costs of operating the Reddit contracts on an Arbitrum Rollup chain including the L1 gas costs for the Rollup chain, the costs of computation and storage for the L2 validators as well as the capital lockup requirements for staking.
Arbitrum Rollup is still on testnet, so we did not run mainnet benchmarks. Instead, we measured the L1 gas cost and L2 workload for Reddit operations on Arbitrum and calculated the total cost assuming current Ethereum gas prices. As noted below in detail, our measurements do not assume that Arbitrum is consuming the entire capacity of Ethereum. We will present the details of our model now, but for full transparency you can also play around with it yourself and adjust the parameters, by copying the spreadsheet found here.
Our cost model is based on measurements of Reddit’s contracts, running unmodified (except for the addition of a batch minting function) on Arbitrum Rollup on top of Ethereum.
On the distribution of transactions and frequency of assertions. Reddit's instructions specify the following minimum parameters that submissions should support:
Over a 5 day period, your scaling PoC should be able to handle:
  • 100,000 point claims (minting & distributing points)
  • 25,000 subscriptions
  • 75,000 one-off points burning
  • 100,000 transfers
We provide the full costs of operating an Arbitrum Rollup chain with this usage under the assumption that tokens are minted or granted to users in batches, but other transactions are uniformly distributed over the 5 day period. Unlike some other submissions, we do not make unrealistic assumptions that all operations can be submitted in enormous batches. We assume that batch minting is done in batches that use only a few percent on an L1 block’s gas, and that other operations come in evenly over time and are submitted in batches, with one batch every five minutes to keep latency reasonable. (Users are probably already waiting for L1 finality, which takes at least that long to achieve.)
We note that assuming that there are only 300,000 transactions that arrive uniformly over the 5 day period will make our benchmark numbers lower, but we believe that this will reflect the true cost of running the system. To see why, say that batches are submitted every five minutes (20 L1 blocks) and there's a fixed overhead of c bytes of calldata per batch, the cost of which will get amortized over all transactions executed in that batch. Assume that each individual transaction adds a marginal cost of t. Lastly assume the capacity of the scaling system is high enough that it can support all of Reddit's 300,000 transactions within a single 20-block batch (i.e. that there is more than c + 300,000*t byes of calldata available in 20 blocks).
Consider what happens if c, the per-batch overhead, is large (which it is in some systems, but not in Arbitrum). In the scenario that transactions actually arrive at the system's capacity and each batch is full, then c gets amortized over 300,000 transactions. But if we assume that the system is not running at capacity--and only receives 300,000 transactions arriving uniformly over 5 days-- then each 20-block assertion will contain about 200 transactions, and thus each transaction will pay a nontrivial cost due to c.
We are aware that other proposals presented scaling numbers assuming that 300,000 transactions arrived at maximum capacity and was executed in a single mega-transaction, but according to our estimates, for at least one such report, this led to a reported gas price that was 2-3 orders of magnitude lower than it would have been assuming uniform arrival. We make more realistic batching assumptions, and we believe Arbitrum compares well when batch sizes are realistic.
Our model. Our cost model includes several sources of cost:
  • L1 gas costs: This is the cost of posting transactions as calldata on the L1 chain, as well as the overhead associated with each batch of transactions, and the L1 cost of settling transactions in the Arbitrum protocol.
  • Validator’s staking costs: In normal operation, one validator will need to be staked. The stake is assumed to be 0.2% of the total value of the chain (which is assumed to be $1 per user who is eligible to claim points). The cost of staking is the interest that could be earned on the money if it were not staked.
  • Validator computation and storage: Every validator must do computation to track the chain’s processing of transactions, and must maintain storage to keep track of the contracts’ EVM storage. The cost of computation and storage are estimated based on measurements, with the dollar cost of resources based on Amazon Web Services pricing.
It’s clear from our modeling that the predominant cost is for L1 calldata. This will probably be true for any plausible rollup-based system.
Our model also shows that Arbitrum can scale to workloads much larger than Reddit’s nominal workload, without exhausting L1 or L2 resources. The scaling bottleneck will ultimately be calldata on the L1 chain. We believe that cost could be reduced substantially if necessary by clever encoding of data. (In our design any compression / decompression of L2 transaction calldata would be done by client software and L2 programs, never by an L1 contract.)
9. Status of Arbitrum Rollup
Arbitrum Rollup is live on Ethereum testnet. All of the code written to date including everything included in the Reddit demo is open source and permissively licensed under the Apache V2 license. The first testnet version of Arbitrum Rollup was released on testnet in February. Our current internal version, which we used to benchmark the Reddit contracts, will be released soon and will be a major upgrade.
Both the Arbitrum design as well as the implementation are heavily audited by independent third parties. The Arbitrum academic paper was published at USENIX Security, a top-tier peer-reviewed academic venue. For the Arbitrum software, we have engaged Trail of Bits for a security audit, which is currently ongoing, and we are committed to have a clean report before launching on Ethereum mainnet.
10. Reddit Universe Arbitrum Rollup Chain
The benchmarks described in this document were all measured using the latest internal build of our software. When we release the new software upgrade publicly we will launch a Reddit Universe Arbitrum Rollup chain as a public demo, which will contain the Reddit contracts as well as a Uniswap instance and a Connext Hub, demonstrating how Community Points can be integrated into third party apps. We will also allow members of the public to dynamically launch ecosystem contracts. We at Offchain Labs will cover the validating costs for the Reddit Universe public demo.
If the folks at Reddit would like to evaluate our software prior to our public demo, please email us at [email protected] and we'd be more than happy to provide early access.
11. Even more scaling: Arbitrum Sidechains
Rollups are an excellent approach to scaling, and we are excited about Arbitrum Rollup which far surpasses Reddit's scaling needs. But looking forward to Reddit's eventual goal of supporting hundreds of millions of users, there will likely come a time when Reddit needs more scaling than any Rollup protocol can provide.
While Rollups greatly reduce costs, they don't break the linear barrier. That is, all transactions have an on-chain footprint (because all calldata must be posted on-chain), albeit a far smaller one than on native Ethereum, and the L1 limitations end up being the bottleneck for capacity and cost. Since Ethereum has limited capacity, this linear use of on-chain resources means that costs will eventually increase superlinearly with traffic.
The good news is that we at Offchain Labs have a solution in our roadmap that can satisfy this extreme-scaling setting as well: Arbitrum AnyTrust Sidechains. Arbitrum Sidechains are similar to Arbitrum Rollup, but deviate in that they name a permissioned set of validators. When a chain’s validators agree off-chain, they can greatly reduce the on-chain footprint of the protocol and require almost no data to be put on-chain. When validators can't reach unanimous agreement off-chain, the protocol reverts to Arbitrum Rollup. Technically, Arbitrum Sidechains can be viewed as a hybrid between state channels and Rollup, switching back and forth as necessary, and combining the performance and cost that state channels can achieve in the optimistic case, with the robustness of Rollup in other cases. The core technical challenge is how to switch seamlessly between modes and how to guarantee that security is maintained throughout.
Arbitrum Sidechains break through this linear barrier, while still maintaining a high level of security and decentralization. Arbitrum Sidechains provide the AnyTrust guarantee, which says that as long as any one validator is honest and available (even if you don't know which one will be), the L2 chain is guaranteed to execute correctly according to its code and guaranteed to make progress. Unlike in a state channel, offchain progress does not require unanimous consent, and liveness is preserved as long as there is a single honest validator.
Note that the trust model for Arbitrum Sidechains is much stronger than for typical BFT-style chains which introduce a consensus "voting" protocols among a small permissioned group of validators. BFT-based protocols require a supermajority (more than 2/3) of validators to agree. In Arbitrum Sidechains, by contrast, all you need is a single honest validator to achieve guaranteed correctness and progress. Notice that in Arbitrum adding validators strictly increases security since the AnyTrust guarantee provides correctness as long as any one validator is honest and available. By contrast, in BFT-style protocols, adding nodes can be dangerous as a coalition of dishonest nodes can break the protocol.
Like Arbitrum Rollup, the developer and user experiences for Arbitrum Sidechains will be identical to that of Ethereum. Reddit would be able to choose a large and diverse set of validators, and all that they would need to guarantee to break through the scaling barrier is that a single one of them will remain honest.
We hope to have Arbitrum Sidechains in production in early 2021, and thus when Reddit reaches the scale that surpasses the capacity of Rollups, Arbitrum Sidechains will be waiting and ready to help.
While the idea to switch between channels and Rollup to get the best of both worlds is conceptually simple, getting the details right and making sure that the switch does not introduce any attack vectors is highly non-trivial and has been the subject of years of our research (indeed, we were working on this design for years before the term Rollup was even coined).
12. How Arbitrum compares
We include a comparison to several other categories as well as specific projects when appropriate. and explain why we believe that Arbitrum is best suited for Reddit's purposes. We focus our attention on other Ethereum projects.
Payment only Rollups. Compared to Arbitrum Rollup, ZK-Rollups and other Rollups that only support token transfers have several disadvantages:
  • As outlined throughout the proposal, we believe that the entire draw of Ethereum is in its rich smart contracts support which is simply not achievable with today's zero-knowledge proof technology. Indeed, scaling with a ZK-Rollup will add friction to the deployment of smart contracts that interact with Community Points as users will have to withdraw their coins from the ZK-Rollup and transfer them to a smart contract system (like Arbitrum). The community will be best served if Reddit builds on a platform that has built-in, frictionless smart-contract support.
  • All other Rollup protocols of which we are aware employ a centralized operator. While it's true that users retain custody of their coins, the centralized operator can often profit from censoring, reordering, or delaying transactions. A common misconception is that since they're non-custodial protocols, a centralized sequencer does not pose a risk but this is incorrect as the sequencer can wreak havoc or shake down users for side payments without directly stealing funds.
  • Sidechain type protocols can eliminate some of these issues, but they are not trustless. Instead, they require trust in some quorum of a committee, often requiring two-third of the committee to be honest, compared to rollup protocols like Arbitrum that require only a single honest party. In addition, not all sidechain type protocols have committees that are diverse, or even non-centralized, in practice.
  • Plasma-style protocols have a centralized operator and do not support general smart contracts.
13. Concluding Remarks
While it's ultimately up to the judges’ palate, we believe that Arbitrum Rollup is the bakeoff choice that Reddit kneads. We far surpass Reddit's specified workload requirement at present, have much room to optimize Arbitrum Rollup in the near term, and have a clear path to get Reddit to hundreds of millions of users. Furthermore, we are the only project that gives developers and users the identical interface as the Ethereum blockchain and is fully interoperable and tooling-compatible, and we do this all without any new trust assumptions or centralized components.
But no matter how the cookie crumbles, we're glad to have participated in this bake-off and we thank you for your consideration.
About Offchain Labs
Offchain Labs, Inc. is a venture-funded New York company that spun out of Princeton University research, and is building the Arbitrum platform to usher in the next generation of scalable, interoperable, and compatible smart contracts. Offchain Labs is backed by Pantera Capital, Compound VC, Coinbase Ventures, and others.
Leadership Team
Ed Felten
Ed Felten is Co-founder and Chief Scientist at Offchain Labs. He is on leave from Princeton University, where he is the Robert E. Kahn Professor of Computer Science and Public Affairs. From 2015 to 2017 he served at the White House as Deputy United States Chief Technology Officer and senior advisor to the President. He is an ACM Fellow and member of the National Academy of Engineering. Outside of work, he is an avid runner, cook, and L.A. Dodgers fan.
Steven Goldfeder
Steven Goldfeder is Co-founder and Chief Executive Officer at Offchain Labs. He holds a PhD from Princeton University, where he worked at the intersection of cryptography and cryptocurrencies including threshold cryptography, zero-knowledge proof systems, and post-quantum signatures. He is a co-author of Bitcoin and Cryptocurrency Technologies, the leading textbook on cryptocurrencies, and he has previously worked at Google and Microsoft Research, where he co-invented the Picnic signature algorithm. When not working, you can find Steven spending time with his family, taking a nature walk, or twisting balloons.
Harry Kalodner
Harry Kalodner is Co-founder and Chief Technology Officer at Offchain Labs where he leads the engineering team. Before the company he attended Princeton as a Ph.D candidate where his research explored economics, anonymity, and incentive compatibility of cryptocurrencies, and he also has worked at Apple. When not up at 3:00am writing code, Harry occasionally sleeps.
submitted by hkalodner to ethereum [link] [comments]

TKEYSPACE — blockchain in your mobile

TKEYSPACE — blockchain in your mobile

https://preview.redd.it/w8o3bcvjrtx41.png?width=1400&format=png&auto=webp&s=840ac3872156215b30e708920edbef4583190654
Someone says that the blockchain in the phone is marketing. This is possible for most applications, but not for Tkeycoin. Today we will talk about how the blockchain works in the TkeySpace app.
Who else is not in the topic, TkeySpace is a financial application for decentralized and efficient management of various cryptocurrencies, based on a distributed architecture without using a client-server.
In simple words, it is a blockchain in the user’s mobile device that excludes hacking and hacker attacks, and all data is encrypted using modern cryptographic methods.
https://preview.redd.it/8uku6thlrtx41.png?width=1280&format=png&auto=webp&s=e1a610244da53100a5bc6b821ee5c799c6493ac4

Blockchain

Let’s start with the most important thing — the blockchain works on the principles of P2P networks, when there is no central server and each device is both a server and a client, such an organization allows you to maintain the network performance with any number and any combination of available nodes.
For example, there are 12 machines in the network, and anyone can contact anyone. As a client (resource consumer), each of these machines can send requests for the provision of some resources to other machines within this network and receive them. As a server, each machine must process requests from other machines in the network, send what was requested, and perform some auxiliary and administrative functions.
With traditional client-server systems, we can get a completely disabled social network, messenger, or another service, given that we rely on a centralized infrastructure — we have a very specific number of points of failure. If the main data center is damaged due to an earthquake or any other event, access to information will be slowed down or completely disabled.
With a P2P solution, the failure of one network member does not affect the network operation in any way. P2P networks can easily switch to offline mode when the channel is broken — in which it will exist completely independently and without any interaction.
Instead of storing information in a single central point, as traditional recording methods do, multiple copies of the same data are stored in different locations and on different devices on the network, such as computers or mobile devices.

https://i.redd.it/2c4sv7rnrtx41.gif
This means that even if one storage point is damaged or lost, multiple copies remain secure in other locations. Similarly, if one part of the information is changed without the consent of the rightful owners, there are many other copies where the information is correct, which makes the false record invalid.
The information recorded in the blockchain can take any form, whether it is a transfer of money, ownership, transaction, someone’s identity, an agreement between two parties, or even how much electricity a light bulb used.
However, this requires confirmation from multiple devices, such as nodes in the network. Once an agreement, otherwise known as consensus, is reached between these devices to store something on the blockchain — it can’t be challenged, deleted, or changed.
The technology also allows you to perform a truly huge amount of computing in a relatively short time, which even on supercomputers would require, depending on the complexity of the task, many years or even centuries of work. This performance is achieved because a certain global task is divided into a large number of blocks, which are simultaneously performed by hundreds of thousands of devices participating in the project.

P2P messaging and syncing in TkeySpace

TkeySpace is a node of the TKEY network and other supported networks. when you launch the app, your mobile node connects to an extensive network of supported blockchains, syncs with full nodes to validate transactions and incoming information between nodes, so the nodes organize a graph of connections between them.
You can always check the node information in the TkeySpace app in the ⚙ Settings Contact and peer info App Status;

https://preview.redd.it/co1k25kqrtx41.png?width=619&format=png&auto=webp&s=e443a436b11d797b475b00a467cd9609cac66b83
TkeySpace creates initiating connections to servers registered in the blockchain Protocol as the main ones, from these servers it gets the addresses of nodes to which it can join, in turn, the nodes to which the connection occurred share information about other nodes.

https://i.redd.it/m21pw88srtx41.gif
TkeySpace sends network messages to nodes from supported blockchains in the app to get up-to-date data from the network.
The Protocol uses data structures for communication between nodes, such as block propagation over the network, so before network messages are read, nodes check the “magic number”, check the first bytes, and determine the type of data structure. In the blockchain, the “magic number” is the network ID used to filter messages and block traffic from other p2p networks.
Magic numbers are used in computer science, both for files and protocols. They identify the type of file/data structure. A program that receives such a file/data structure can check the magic number and immediately find out the intended type of this file/data structure.
The first message that your node sends is called a Version Message. In response, the node waits for a Verack message to establish a connection between other peers. The exchange of such messages is called a “handshake”.

https://preview.redd.it/b6gh0hitrtx41.png?width=785&format=png&auto=webp&s=0101eaec6469fb53818486fa13da110f6a4a851d
After the “handshake” is set, TkeySpace will start connecting to other nodes in the network to determine the last block at the end of the required blockchain. At this point — nodes request information about blocks they know using GetBlock messages — in response, your node receives an inv (Inventory Message) from another node with the information that it has the information that was requested by the TkeySpace node.
In response to the received message, inv — TkeySpace sends a GetData message containing a list of blocks starting immediately after the last known hash.

https://preview.redd.it/lare5lsurtx41.png?width=768&format=png&auto=webp&s=da8d27110f406f715292b439051ca221fab47f77

Loading and storing blocks

After exchanging messages, the block information is loaded and transactions are uploaded to your node. To avoid storing tons of information and optimize hard disk space and data processing speed, we use RDBMS — PostgreSQL in full nodes (local computer wallet).
In the TkeySpace mobile app, we use SQLite, and validation takes place by uploading block headers through the Merkle Tree, using the bloom filter — this allows you to optimize the storage of your mobile device as much as possible.
The block header includes its hash, the hash of the previous block, transaction hashes, and additional service information.
Block headers in the Tkeycoin network=84 bytes due to the extension of parameters to support nChains, which will soon be launched in “combat” mode. The titles of the Bitcoin block, Dash, Litecoin=80 bytes.

https://preview.redd.it/uvv3qz7wrtx41.png?width=1230&format=png&auto=webp&s=5cf0cd8b6d099268f3d941aac322af05e781193c
And so, let’s continue — application nodes receive information from the blockchain by uploading block headers, all data is synchronized using the Merkle Tree, or rather your node receives and validates information from the Merkle root.
The hash tree was developed in 1979 by Ralph Merkle and named in his honor. The structure of the system has received this name also because it resembles a tree.
The Merkle tree is a complete binary tree with leaf vertexes containing hashes from data blocks, and inner vertexes containing hashes from adding values in child vertexes. The root node of the tree contains a hash from the entire data set, meaning the hash tree is a unidirectional hash function. The Merkle tree is used for the efficient storage of transactions in the cryptocurrency blockchain. It allows you to get a “fingerprint” of all transactions in the block, as well as effectively verify transactions.

https://preview.redd.it/3hmbthpxrtx41.png?width=677&format=png&auto=webp&s=cca3d54c585747e0431c6c4de6eec7ff7e3b2f4d
Hash trees have an advantage over hash chains or hash functions. When using hash trees, it is much less expensive to prove that a certain block of data belongs to a set. Since different blocks are often independent data, such as transactions or parts of files, we are interested in being able to check only one block without recalculating the hashes for the other nodes in the tree.
https://i.redd.it/f7o3dh7zrtx41.gif
The Merkle Tree scheme allows you to check whether the hash value of a particular transaction is included in Merkle Root, without having all the other transactions in the block. So by having the transaction, block header, and Merkle Branch for that transaction requested from the full node, the digital wallet can make sure that the transaction was confirmed in a specific block.

https://i.redd.it/88sz13w0stx41.gif
The Merkle tree, which is used to prove that a transaction is included in a block, is also very well scaled. Because each new “layer” added to the tree doubles the total number of “leaves” it can represent. You don’t need a deep tree to compactly prove transaction inclusion, even among blocks with millions of transactions.

Statistical constants and nChains

To support the Tkeycoin cryptocurrency, the TkeySpace application uses additional statistical constants to prevent serialization of Merkle tree hashes, which provides an additional layer of security.
Also, for Tkeycoin, support for multi-chains (nChains) is already included in the TkeySpace app, which will allow you to use the app in the future with most of the features of the TKEY Protocol, including instant transactions.

The Bloom Filter

An additional level of privacy is provided by the bloom filter — which is a probabilistic data structure that allows you to check whether an element belongs to a set.

https://preview.redd.it/7ejkvi82stx41.png?width=374&format=png&auto=webp&s=ed75cd056949fc3a2bcf48b4d7ea78d3dc6d81f3
The bloom filter looks for whether a particular transaction is linked to Alice, not whether Alice has a specific cryptocurrency. In this way, transactions and received IDs are analyzed through a bloom filter. When “Alice wants to know about transaction X”, an ID is requested for transaction X, which is compared with the filled segments in her bloom filter. If “Yes” is received, the node can get the information and verify the transaction.

https://preview.redd.it/gjpsbss3stx41.png?width=1093&format=png&auto=webp&s=4cdcbc827849d13b7d6f0b7e7ba52e65ddc03a82

HD support

The multi-currency wallet TkeySpace is based on HD (or hierarchical determinism), a privacy-oriented method for generating and managing addresses. Each wallet address is generated from an xPub wallet (or extended public key). The app is completely anonymous — and individual address is generated for each transaction to accept a particular cryptocurrency. Even for low-level programming, using the same address is negative for the system, not to mention your privacy. We recommend that you always use a new address for transactions to ensure the necessary level of privacy and security.
The EXT_PUBLIC_KEY and EXT_SECRET_KEY values for DASH, Bitcoin, and Litecoin are completely identical. Tkeycoin uses its values, as well as other methods for storing transactions and blocks (RDBMS), and of course — nChains.

Secret key

Wallets in the blockchain have public and private keys.
https://preview.redd.it/br9kk8n5stx41.png?width=840&format=png&auto=webp&s=a36e4c619451735469a9cff57654d322467e4fba
Centralized applications usually store users’ private keys on their servers, which makes users’ funds vulnerable to hacker attacks or theft.
A private key is a special combination of characters that provides access to cryptocurrencies stored on the account. Only a person who knows the key can move and spend digital assets.
TkeySpace — stores the encrypted key only on the user’s device and in encrypted form. The encrypted key is displayed as a mnemonic phrase (backup phrase), which is very convenient for users. Unlike complex cryptographic ciphers, the phrase is easy to save or write. A backup keyword provides the maximum level of security.
A mnemonic phrase is 12 or 24 words that are generated using random number entropy. If a phrase consists of 12 words, then the number of possible combinations is 204⁸¹² or 21¹³² — the phrase will have 132 security bits. To restore the wallet, you must enter the mnemonic phrase in strict order, as it was presented after generation.

Result

Now we understand that your application TkeySpace is a node of the blockchain that communicates with other nodes using p2p messages, stores block headers and validate information using the Merkle Tree, verifies transactions, filters information using the bloom filter, and operates completely in a decentralized model. The application code contains all the necessary blockchain settings for communicating with the network, the so-called chain parameters.
TkeySpace is a new generation mobile app. A completely new level of security, easy user-friendly interfaces and all the necessary features that are required to work with cryptocurrency.
submitted by tkeycoin to Tkeycoin_Official [link] [comments]

Technical: More channel mechanisms!

This is a followup of my older post about the history of payment channel mechanisms.
The "modern" payment channel system is Lightning Network, which uses bidirectional indefinite-lifetime channels, using HTLCs to trustlessly route through the network.
However, at least one other payment channel mechanism was developed at roughly the same time as Lightning, and there are also further proposals that are intended to replace the core payment channel mechanism in use by Lightning.
Now, in principle, the "magic" of Lightning lies in combining two ingredients:
  1. Offchain updateable systems.
  2. HTLCs to implement atomic cross-system swaps.
We can replace the exact mechanism implementing an offchain updateable system. Secondly we can replace the use of HTLCs with another atomic cross-system swap, which is what we would do when we eventually switch to payment points and scalars from payment hashes and preimages.
So let's clarify what I'll be discussing here:
Now I might use "we" here to refer to what "we" did to the design of Bitcoin, but it is only because "we" are all Satoshi, except for Craig Steven Wright.
So, let's present the other payment channel mechanisms. But first, a digression.

Digression: the new nSequence and OP_CHECKSEQUENCEVERIFY

The new relative-timelock semantics of nSequence.
Last time we used nSequence, we had the unfortunate problem that it would be easy to rip off people by offering a higher miner fee for older state where we own more funds, then convince the other side of the channel to give us goods in exchange for a new state with tiny miner fees, then publish both the old state and the new state, then taunt the miners with "so which state is gonna earn you more fees huh huh huh?".
This problem, originally failed by Satoshi, was such a massive facepalm that, in honor of miners doing the economically-rational thing in the face of developer and user demands when given a non-final nSequence, we decided to use nSequence as a flag for the opt-in replace-by-fee.
Basically, under opt-in replace-by-fee, if a transaction had an nSequence that was not 0xFFFFFFFF or 0xFFFFFFFE, then it was opt-in RBF (BIP125). Because you'd totally abuse nSequence to bribe miners in order to steal money from your bartender, especially if your bartender is not a werebear.
Of course, using a 4-byte field for a one-bit flag (to opt-in to RBF or not) was a massive waste of space, so when people started proposing relative locktimes, the nSequence field was repurposed.
Basically, in Bitcoin as of the time of this writing (early 2020) if nSequence is less than 0x80000000 it can be interpreted as a relative timelock. I'll spare you the details here, BIP68 has them, but basically nSequence can indicate (much like nLockTime) either a "real world" relative lock time (i.e. the output must have been confirmed for X seconds before it can be spent using a transaction with a non-zero nSequence) or the actual real world, which is measured in blocks (i.e. the output must have been confirmed for N blocks before it can be spent using a transaction with a non-zero nSequence). Of course, this is the Bitcoin universe and "seconds" is a merely human delusion, so we will use blocks exclusively.
And similarly to OP_CHECKLOCKTIMEVERIFY, we also added OP_CHECKSEQUENCEVERIFY in BIP112. This ensures that the nSequence field is a relative-locktime (i.e. less than 0x80000000) and that it is the specified type (block-based or seconds-based) and that it is equal or higher to the specified minimum relative locktime.
It is important to mention the new, modern meaning of nSequence, because it is central to many of the modern payment channel mechanisms, including Lightning Poon-Dryja.
Lessons learned?

Decker-Wattenhofer "Duplex Micropayment Channels"

Mechanisms-within-mechanisms for a punishment-free bidirectional indefinite-lifetime payment channel.
The Decker-Wattenhofer paper was published in 2015, but the Poon-Dryja "Lightning Network" paper was published in 2016. However, the Decker-Wattenhofer paper mentions the Lightning mechanism, specifically mentioning the need to store every old revocation key (i.e. the problem I mentioned last time that was solved using RustyReddit shachains). Maybe Poon-Dryja presented the Lightning Network before making a final published paper in 2016, or something. Either that or cdecker is the Bitcoin time traveler.
It's a little hard to get an online copy now, but as of late 2019 this seems to work: copy
Now the interesting bit is that Decker-Wattenhofer achieves its goals by combining multiple mechanisms that are, by themselves, workable payment channel mechanisms already, except each has some massive drawbacks. By combining them, we can minimize the drawbacks.
So let's go through the individual pieces.

Indefinite-lifetime Spilman channels

As mentioned before, Spilman channels have the drawback that they have a limited lifetime: the lock time indicated in the backoff transaction or backoff branch of the script. However, instead of an absolute lock time, we can use a relative locktime.
In order to do so, we use a "kickoff" transaction, between the backoff transaction and the funding transaction. Our opening ritual goes this way, between you and our gender-neutral bartender-bancho werebear:
  1. First, you compute the txid for the funding transaction and the kickoff transaction. The funding transaction takes some of your funds and puts it into a 2-of-2 between you and the bartender, and the kickoff is a 1-input 1-output transaction that spends the funding transaction and outputs to another 2-of-2 between you and the bartender.
  2. Then, you generate the backoff transaction, which spends the kickoff transaction and returns all the funds to you. The backoff has a non-zero nSequence, indicating a delay of a number of blocks agreed between you, which is a security/convenience tradeoff parameter
  3. You sign the backoff transaction, then send it to the bartender.
  4. The bartender signs the backoff, and gives back the fully-signed transaction to you.
  5. You sign the kickoff transaction, then send it to the bartender.
  6. The bartender signs the kickoff, and gives it back to you fully signed.
  7. You sign and broadcast the funding transaction, and both of you wait for the funding transaction to be deeply confirmed.
The above setup assumes you're using SegWit, because transaction malleability fix.
At any time, either you or the bartender can broadcast the kickoff transaction, and once that is done, this indicates closure of the channel. You do this if you have drunk enough alcoholic beverages, or the bartender could do this when he or she is closing the bar.
Now, to get your drinks, you do:
  1. Sign a transaction spending the kickoff, and adding more funds to the bartender, to buy a drink. This transaction is not encumbered with an nSequence.
  2. Hand the signed transaction to the bartender, who provides you with your next drink.
The channel is closed by publishing the kickoff transaction. Both of you have a fully-signed copy of the kickoff, so either of you can initiate the close.
On closure (publication and confirmation of the kickoff transaction), there are two cases:
  1. You fail to pick up any chicks at the bar (I prefer female humans of optimum reproductive age myself rather than nestling birds, but hey, you do you) so you didn't actually spend for drinks at all. In this case, the bartender is not holding any transactions that can spend the kickoff transaction. You wait for the agreed-upon delay after the kickoff is confirmed, and then publish the backoff transaction and get back all the funds that you didn't spend.
  2. You spend all your money on chicks and end up having to be kicked into a cab to get back to your domicile, because even juvenile birds can out-drink you, you pushover. The bartender then uses the latest transaction you gave (the one that gives the most money to him or her --- it would be foolish of him or her to use an earlier version with less money!), signs it, and broadcasts it to get his or her share of the money from the kickoff transaction.

Decrementing nSequence channels

Enforcing order by reducing relative locktimes.
I believe this to be novel to the Decker-Wattenhofer mechanism, though I might be missing some predecessor.
This again uses the new relative-locktime meaning of nSequence. As such, it also uses a kickoff transaction like the above indefinite-lifetime Spilman channel. Set up is very similar to the setup of the above indefinite-lifetime Spilman channel, except that because this is bidirectional, we can actually have both sides put money into the initial starting backoff transaction.
We also rename the "backoff" transaction to "state" transaction. Basically, the state transaction indicates how the money in the channel is divided up between the two participants. The "backoff" we sign during the funding ritual is now the first state transaction. Both sides keep track of the current state transaction (which is initialized to the first state transaction on channel establishment).
Finally, the starting nSequence of the first state transaction is very large (usually in the dozens or low hundreds of blocks).
Suppose one participant wants to pay the other. The ritual done is then:
  1. A new version of the current state transaction is created with more money in the payee side.
  2. This new version has nSequence that is one block lower than the current state transaction (in practice it should be a few blocks lower, not just one, because sometimes miners find blocks in quick succession).
  3. Both sides exchange signatures for the new state transaction.
  4. Both sides set the new state transaction as the current state transaction that will be the basis for the next payment.
When the channel is closed by publication of the kickoff transaction, then the transaction with the lowest nSequence becomes valid earlier than the other state transactions. This is enough to enforce that the most recent state transaction (the one with the lowest nSequence, and thus the first to become valid) is published.

Mechanism-within-mechanism

Combining the ingredients of the Decker-Wattenhofer Duplex Micropayment Channels concoction.
Of note is that we can "chain" these mechanisms together in such a way that we strengthen their strengths while covering their weaknesses.
A note is that both the indefinite-lifetime nSequence Spilman variant, and the above decrementing nSequence mechanism, both have "kickoff" transactions.
However, when we chain the two mechanisms together, it turns out that the final transaction of one mechanism also serves as the kickoff of the next mechanism in the chain.
So for example, let's chain two of those decrementing nSequence channels together. Let's make them 144 blocks maximum delay each, and decrement in units of 4 blocks, so each of the chained mechanisms can do 37 updates each.
We start up a new channel with the following transactions:
  1. A funding transaction paying to a 2-of-2, confirmed deeply onchain. All other transactions are offchain until closure.
  2. A kickoff transaction spending the funding transaction output, paying to a 2-of-2.
  3. A "stage 1" decrementing nSequence state transaction, spending the kickoff, with current nSequence 144, paying to a 2-of-2.
  4. A "stage 2" decrementing nSequence state transaction, spending the stage 1, with current nSequence 144, paying to the initial state of the channel.
When we update this channel, we first update the "stage 2" state transaction, replacing it with an nSequence lower by 4 blocks. So after one update our transactions are:
  1. A funding transaction paying to a 2-of-2, confirmed deeply onchain. All other transactions are offchain until closure.
  2. A kickoff transaction spending the funding transaction output, paying to a 2-of-2.
  3. A "stage 1" decrementing nSequence state transaction, spending the kickoff, with current nSequence 144, paying to a 2-of-2.
  4. A "stage 2" decrementing nSequence state transaction, spending the stage 1, with current nSequence 140, paying to the second state of the channel.
The first 3 transactions are the same, only the last one is replaced with a state transaction with lower `nSequence.
Things become interesting when we reach the "stage 2" having nSequence 0. On the next update, we create a new "stage 1", with an nSequence that is 4 lower, and "reset" the "stage 2" back to an nSequence of 144.
This is safe because even though we have a "stage 2" with shorter nSequence, that stage 2 spends a stage 1 with an nSequence of 144, and the stage 1 with nSequence of 140 would beat it to the blockchain first.
This results in us having, not 36 + 36 updates, but instead 36 * 36 updates (1296 updates). 1296 updates is still kinda piddling, but that's much better than just a single-stage decrementing nSequence channel.
The number of stages can be extended indefinitely, and your only drawback would be the amount of blockchain space you'd spend for a unilateral close. Mutual cooperative closes can always shortcut the entire stack of staged transactions and cut it to a single mutual cooperative close transaction.
But that's not all! You might be wondering about the term "duplex" in the name "Duplex Micropayment Channels".
That's because the last decrementing nSequence stage does not hold the money of the participants directly. Instead, the last stage holds two indefinite-lifetime Spilman channels. As you might remember, Spilman channels are unidirectional, so the two Spilman channels represent both directions of the channel. Thus, duplex.
Let's go back to you and your favorite werebear bartender. If you were using a Decker-Wattenhofer Duplex Micropayment Channel, you'd have several stages of decrementing nSequence, terminated in two Spilman channels, a you-to-bartender channel and a bartender-to-you channel.
Suppose that, while drinking, the bartender offers you a rebate on each drink if you do some particular service for him or her. Let us not discuss what service this is and leave it to your imagination. So you pay for a drink, decide you want to get the rebate, and perform a service that the bartender finds enjoyable. So you transfer some funds on the you-to-bartender direction, and then later the bartender transfers some funds in the bartender-to-you channel after greatly enjoying your service.
Suppose you now exhaust the you-to-bartender direction. However, you note that the rebates you've earned are enough to buy a few more drinks. What you do instead is to update the staged decrementing nSequence mechanisms, and recreate the two Spilman directions such that the you-to-bartender direction contains all your current funds and the bartender-to-you direction contains all the bartender's funds. With this, you are now able to spend even the money you earned from rebates. At the same time, even if the staged decrementing nSequence mechanisms only have a few hundred thousand updates, you can still extend the practical number of updates as long as you don't have to reset the Spilman channels too often.

Burchert-Decker-Wattenhofer Channel Factories

Because you like channels so much, you put channels inside channels so you could pay while you pay. I N C E P T I O N
The Decker-Wattenhofer Duplex Micropayment Channels introduced the possibility of nesting a channel mechanism inside another channel mechanism. For example, it suggests nesting a decrementing-nSequence mechanism inside another decrementing-nSequence mechanism, and having as well an unlimited-lifetime Spilman channel at the end. In the Decker-Wattenhofer case, it is used to support the weakness of one mechanism with the strength of another mechanism.
One thing to note is that while the unlimited-lifetime Spilman channel variant used is inherently two-participant (there is one payer and one payee), the decrementing-nSequence channel mechanism can be multiparticipant.
Another thing of note is that nothing prevents one mechanism from hosting just one inner mechanism, just as it is perfectly fine for a Lightning Network channel to have multiple HTLCs in-flight, plus the money in your side, plus the money in the counterparty's side. As these are "just" Bitcoin-enforceable contracts, there is no fundamental difference between an HTLC, and a payment channel mechanism.
Thus the most basic idea of the Burchert-Decker-Wattenhofer Channel Factories paper is simply that we can have a multiparticipant update mechanism host multiple two-party update mechanisms. The outer multiparticipant update mechanism is called a "channel factory" while the inner two-party update mechanisms are called "channels".
The exact mechanism used in the Burchert-Decker-Wattenhofer paper uses several decrementing-nSequence mechanisms to implement the factory, and Decker-Wattenhofer Duplex Micropayment Channels to implement the channel layer.
However, as noted before, there is no fundamental difference between a Poon-Dryja channel and an HTLC. So it is in fact possible to have chained Decker-Wattenhofer decrementing-nSequence mechanisms to implement the factory level, while the channels are simply Poon-Dryja channels.

Conclusion

So this concludes for now an alternative mechanism to the classic Poon-Dryja that Lightning uses. The tradeoffs are significantly different between Decker-Wattenhofer vs Poon-Dryja:

Copyright

Copyright 2020 Alan Manuel K. Gloria. Released under CC-BY.
submitted by almkglor to Bitcoin [link] [comments]

The BCH blockchain is 165GB! How good can we compress it? I had a closer look

Someone posted their results for compressing the blockchain in the telegram group, this is what they were able to do:
Note, bitcoin by its nature is poorly compressible, as it contains a lot of incompressible data, such as public keys, addresses, and signatures. However, there's also a lot of redundant information in there, e.g. the transaction version, and it's usually the same opcodes, locktime, sequence number etc. over and over again.
I was curious and thought, how much could we actually compress the blockchain? This is actually very relevant: As I established in my previous post about the costs of a 1GB full node, the storage and bandwidth costs seem to be one of the biggest bottlenecks, and that CPU computation costs are actually the cheapest part, as were able almost to get away with ten year old CPUs.
Let's have a quick look at the transaction format and see what we can do. I'll have a TL;DR at the end if you don't care about how I came up with those numbers.
Before we just in, don't forget that I'll be streaming today again building a SPV node, as I've already posted about here. Last time we made some big progress, I think! Check it out here https://dlive.tv/TobiOnTheRoad. It'll start at around 15:00 UTC!

Version (32 bits)

There's currently two transaction types. Unless we add new ones, we can compress it to 1 bit (0 = version 1; and 1 = version 2).

Input/output count (8 to 72 bits)

This is the number of inputs the transaction has (see section 9 of the whitepaper). If the number of inputs is below 253, it will take 1 byte, and otherwise 2 to 8 bytes. This nice chart shows that, currently, 90% of Bitcoin transactions only have 2 inputs, sometimes 3.
A byte can represent 256 different numbers. Having this as the lowest granularity for input count seems quite wasteful! Also, 0 inputs is never allowed in Bitcoin Cash. If we represent one input with 00₂, two inputs with 01₂, three inputs with 10₂ and everything else with 11₂ + current format, we get away with only 2 bits more than 90% of the time.
Outputs are slightly higher, 3 or less 90% of the time, but the same encoding works fine.

Input (>320 bits)

There can be multiple of those. It has the following format:

Output (≥72 bits)

There can be multiple of those. They have the following format:

Lock time (32 bits)

This is FF FF FF FF most of the time and only occasionally transactions will be time-locked, and only change the meaning if a sequence number for an input is not FF FF FF FF. We can do the same trick as with the sequence number, such that most of the time, this will be just 1 bit.

Total

So, in summary, we have:
Nice table:
No. of inputs No. of outputs Uncompressed size Compressed size Ratio
1 1 191 bytes (1528 bits) 128 bytes (1023 bits) 67.0%
1 2 226 bytes (1808 bits) 151 bytes (1202 bits) 66.5%
2 1 339 bytes (2712 bits) 233 bytes (1861 bits) 68.6%
2 2 374 bytes (2992 bits) 255 bytes (2040 bits) 68.2%
2 3 408 bytes (3264 bits) 278 bytes (2219 bits) 68.0%
3 2 520 bytes (4160 bits) 360 bytes (2878 bits) 69.2%
3 3 553 bytes (4424 bits) 383 bytes (3057 bits) 69.1%
Interestingly, if we take a compression of 69%, if we were to compress the 165 GB blockchain, we'd get 113.8GB. Which is (almost) exactly the amount which 7zip was able to give us given ultra compression!
I think there's not a lot we can do to compress the transaction further, even if we only transmit public keys, signatures and addresses, we'd at minimum have 930 bits, which would still only be at 61% compression ratio (and missing outpoint and value). 7zip is probably also able to utilize re-using of addresses/public keys if someone sends to/from the same address multiple times, which we haven't explored here; but it's generally discouraged to send to the same address multiple times anyway so I didn't explore that. We'd still have signatures clocking in at 512 bits.
Note that the compression scheme I outlined here operates on a per transaction or per block basis (if we compress transacted satoshis per block), unlike 7zip, which compresses per blockchain.
I hope this was an interesting read. I expected the compression ratio to be higher, but still, if it takes 3 weeks to sync uncompressed, it'll take just 2 weeks compressed. Which can mean a lot for a business, actually.

I'll be streaming again today!

As I've already posted about here, I will stream about building an SPV node in Python again. It'll start at 15:00 UTC. Last time we made some big progress, I think! We were able to connect to my Bitcoin ABC node and send/receive our first version message. I'll do a nice recap of what we've done in that time, as there haven't been many present last time. And then we'll receive our first headers and then transactions! Check it out here: https://dlive.tv/TobiOnTheRoad.
submitted by eyeofpython to btc [link] [comments]

Day 9: I will post this guide regularly until available solutions like SegWit, order batching, and Lightning payment channels are mass adopted, the mempool is empty once again, and tx fees are low. Have you done your part?

BACKGROUND
Segregated Witness (SegWit) was activated on the Bitcoin network August 24 2017 as a soft fork that is backward compatible with previous bitcoin transactions (Understanding Segregated Witness). Since that time wallets and exchanges have been slow to deploy SegWit, and the majority of users have not made the switch themselves.
On Dec 18 2017 Subhan Nadeem has pointed out that: If every transaction in the Bitcoin network was a SegWit transaction today, blocks would contain up to 8,000 transactions, and the 138,000 unconfirmed transaction backlog would disappear instantly. Transaction fees would be almost non-existent once again.
Mass SegWit use alone could empty the mempool, result in blocks that are not completely full, and make it possible to include transactions with $0 fee once again.
On Jan 11 2018 when BTC sends went offline at Coinbase the mempool began to rapidly empty. Later in the day when service was restored there was a sharp spike up in the mempool. Subsequently, that afternoon Brian Armstrong finally had to break his silence on the topic and admitted Coinbase is working on SegWit but has still not deployed it. It appears that this is an important data point that indicates if just a few major exchanges would deploy SegWit the high fees bitcoin is experiencing would be eliminated.
SegWit is just one technique available to exchanges and users to reduce pressure on the Bitcoin network. You can make the switch to SegWit on your next transaction, and pressure exchanges to deploy SegWit NOW along with other actions that will reduce their transaction impact on the network. You can help by taking one or more of the action steps below.
ACTION STEPS
  1. If your favorite wallet has not yet implemented SegWit, kindly ask them to do so immediately. If your wallet is not committed to implementing SegWit fast, speak out online any way you can and turn up the pressure. In the meantime start using a wallet that has already implemented SegWit.
  2. If your favorite exchange has not yet implemented SegWit, try to avoid making any further purchases of bitcoin at that exchange and politely inform them that if they do not enable SegWit within 30-days they will lose your business. Sign-up for an account at a SegWit deployed/ready exchange now and initiate the verification process so you'll be ready to bail
  3. Help educate newcomers to bitcoin about the transaction issue, steer them towards SegWit wallets from day one, and encourage them to avoid ever purchasing bitcoin through non-SegWit ready exchanges that are harming bitcoin.
  4. Spread the word! Contact individuals, websites, etc that use bitcoin, explain the benefits of SegWit to everyone, and request they make the switch. Use social media to point out the benefits of SegWit adoption.
IMPORTANT NOTE: The mempool is currently still quite backlogged. If you are a long-term holder and really have no reason to move your bitcoins at this time, wait until the mempool starts to clear and transaction fees go down before moving your bitcoins to a SegWit address or SegWit friendly exchange.
BEYOND SEGWIT - BATCHING, PAYMENT CHANNELS, LIGHTNING
Batching is another great way that exchanges can reduce their fees. See: Saving up to 80% on Bitcoin transaction fees by batching payments. Despite the benefits of batching, some exchanges have been slow to implement it. Users should demand this or walk.
Beyond SegWit & Batching, Lightning Network integration will have even more effect. Lightning is now active and exchanges could setup payment channels between each other so that on-chain transactions need not take place. Some ideas have to outline how that might work are here: Google Doc - Lightning Exchanges. Which two bitcoin exchanges will be the first to establish a lightning channel between themselves and offer free/instant transfers between them for their customers? This will happen in 2018
MEMPOOL/SEGWIT STATISTICS
NEWS/DEVELOPMENTS/VICTORIES
SELECTED TOP EXCHANGES BY BATCHING & SEGWIT STATUS
Exchange Segwit Status Batching Status
Binance NOT READY Yes
Bitfinex Ready Yes
Bitonic Ready Yes
Bitstamp Deployed Yes
Bittrex ? Yes
Coinbase/GDAX NOT READY No
Gemini Ready No
HitBTC Deployed Yes
Huboi ? ?
Kraken Deployed Yes
LocalBitcoins Deployed Yes
OKEx ? ?
Poloniex ? Yes
QuadrigaCX Deployed Yes
Shapeshift Deployed No
Note: all exchanges that have deployed SegWit are currently only sending to p2sh SegWit addresses for now. No exchange will send to a bech32 address like the ones that Electrum generates
Source 1: BitcoinCore.org
Source 2: /Bitcoin
Official statements from exchanges:
SELECTED WALLETS THAT HAVE SEGWIT ALREADY
Make sure you have a SegWit capable wallet installed and ready to use for your next bitcoin transaction
SegWit Enabled Wallets Wallet Type
Ledger Nano S Hardware
Trezor Hardware
Electrum Desktop
Armory Desktop
Edge iOS
GreenAddress iOS
BitWallet iOS
Samourai Android
GreenBits Android
Electrum Android
SegWitAddress.org Paper
FAQs
If I'm a HODLer, will it help to send my BTC to a SegWit address now?
No, just get ready now so that your NEXT transaction will be to a SegWit wallet. Avoid burdening the network with any unnecessary transactions for now.
Why is SegWit adoption going so slowly? Is it a time-consuming process, is there risk involved, is it laziness, or something else?
SegWit will require some extra work to be done right and securely. Also, most exchanges let the user pay the fee, and up to now users have not been overly concerned about fees so for some exchanges it hasn't been a priority.
Once Segwit is FULLY adopted, what do we see the fees/transaction times going to?
Times stay the same - fees will go down. How much and for how long depends on what the demand for transactions will be at that time.
What determines bitcoin transaction fees, to begin with?
Fees are charged per byte of data and are bid up by users. Miners will typically include the transaction with the highest fee/byte first.
Can you please tell me how to move my bitcoins to SegWit address in Bitcoin core wallet? Does the sender or receiver matter?
The Bitcoin core wallet does not yet have a GUI for its SegWit functionality. Download the latest version of Electrum to generate a SegWit address.
A transaction between two SegWit addresses is a SegWit transaction.
A transaction sent from a SegWit address to a non-SegWit address is a SegWit transaction.
A transaction sent from a non-SegWit address to a SegWit address is NOT a SegWit transaction. You can send a SegWit Tx if the sending address is a SegWit address.
Source: HowToToken
What wallet are you using to "batch your sends"? And how can I do that?
Using Electrum, the "Tools" menu option: "Pay to many".
Just enter your receive addresses and the amounts for each, and you can send multiple transactions for nearly the price of one.
Why doesn't the Core Wallet yet support SegWit?
The Core Wallet supports SegWit, but its GUI doesn't. The next update will likely have GUI support built-in
Why isn't a large exchange like Coinbase SegWit ready & deployed when much smaller exchanges already are? Why do they default to high fees? Where is the leadership there?
Draw your own conclusions based on their own words:
March 2016 - Coinbase CEO Brian Armstrong has reservations about Core
Dec 2017 - Coinbase is STILL working on Segwit
P2SH/bech32 FAQs
What are the two SegWit address formats and why do they exist?
It's been a challenge for wallet developers to implement SegWit in a way that users can easily and without too much disruption migrate from legacy to SegWit addresses. The first wallets to enable SegWit addresses – Ledger, Trezor, Core, GreenAddress – use so-called “nested P2SH addresses.” This means they take the existing Pay 2 Script Hash address – starting with a “3” – and put a SegWit address into it. This enables a high grade of compatibility to exist wallets as every wallet is familiar with these addresses, but it is a workaround which results in SegWit transactions needing around 10 percent more space than they otherwise would.
Electrum 3.0 was the first wallet to use bech32 addresses instead of nested p2sh addresses.
Source: BTCManager.com
What is the difference in address format between SegWit address formats P2SH and bech32?
P2SH starts with "3..."
bech32 starts with "bc1..."
Which addresses can I send from/to?
P2SH Segwit addresses can be sent to using older Bitcoin software with no Segwit support. This supports backward compatibility
bech32 can only be sent to from newer Bitcoin software that support bech32. Ex: Electrum
Source: BitcoinTalk.org
Why did ThePirateBay put up two Bitcoin donation addresses on their frontpage, one bech32 and one not?
The address starting with a "3..." is a P2SH SegWit address that can be sent BTC from any bitcoin address including a legacy address. The address starting with a "bc1..." is a bech32 SegWit address that can only be sent to from newer wallets that support bech32.
SEGWIT BLOG GUIDES
PREVIOUS DAY'S THREADS
There's lots of excellent info in the comments of the previous threads:
submitted by Bastiat to Bitcoin [link] [comments]

Day 7: I will post this guide regularly until available solutions like SegWit & order batching are mass adopted, the mempool is empty once again, and tx fees are low. Do you want low tx fees, because this is how you get low tx fees

TL/DR
Bitcoin users can help lower transaction fees and improve bitcoin by switching to SegWit addresses and encourage wallets/exchanges to do the same.
SUMMARY
Segregated Witness (SegWit) was activated on the Bitcoin network August 24 2017 as a soft fork that is backward compatible with previous bitcoin transactions (Understanding Segregated Witness). Since that time wallets and exchanges have been slow to deploy SegWit, some admitting in December 2017 that they have not even started work on integrating it. Others, such as Zebpay in India have already implemented SegWit and are reaping the benefits of reduced transaction fees. If bitcoin users demand SegWit now it will temporarily relieve the transaction backlog while more even more advanced solutions such as Lightning are developed.
Batching is another great way that exchanges can reduce their fees. See: Saving up to 80% on Bitcoin transaction fees by batching payments. Despite the benefits of batching, some exchanges have been slow to implement it.
There is an opportunity now for all bitcoin users to individually contribute to help strengthen and improve the bitcoin protocol. At this point, the process requires a bit of work/learning on the part of the user, but in doing so you'll actually be advancing bitcoin and leaving what could turn out to be a multi-generational legacy for humanity.
MEMPOOL/SEGWIT STATISTICS
BACKGROUND
On Dec 18 Subhan Nadeem has pointed out that:
If every transaction in the Bitcoin network was a SegWit transaction today, blocks would contain up to 8,000 transactions, and the 138,000 unconfirmed transaction backlog would disappear instantly. Transaction fees would be almost non-existent once again.
A few thousand bitcoin users from /Bitcoin switching to making their next transactions SegWit transactions will help take pressure off the network now, and together we can encourage exchanges/wallets to rapidly deploy SegWit for everyone ASAP. Let's make 80%+ SegWit happen fast. You can help by taking one or more of the action steps below.
ACTION STEPS
  1. If your favorite wallet has not yet implemented SegWit, kindly ask them to do so immediately. In the meantime start using a wallet that has already implemented SegWit.
  2. If your favorite exchange has not yet implemented SegWit, try to avoid making any further purchases of bitcoin at that exchange and politely inform them that if they do not enable SegWit within 30-days they will lose your business. Sign-up for an account at a SegWit deployed/ready exchange now and initiate the verification process so you'll be ready to bail
  3. Help educate newcomers to bitcoin about the transaction issue, steer them towards SegWit wallets from day one, and encourage them to avoid ever purchasing bitcoin through non-SegWit ready exchanges that are harming bitcoin.
  4. Spread the word! Conact individuals, websites, etc that use bitcoin, explain the benefits of SegWit to everyone, and request they make the switch
IMPORTANT NOTE: The mempool is currently still quite backlogged. If you are a long-term holder and really have no reason to move your bitcoins at this time, wait until the mempool starts to clear and transaction fees go down before moving your bitcoins to a SegWit address or SegWit friendly exchange.
SELECTED TOP EXCHANGES BY BATCHING & SEGWIT STATUS
Exchange Segwit Status Batching Status
Binance NOT READY Yes
Bitfinex Ready Yes
Bitonic Ready Yes
Bitstamp Deployed Yes
Bittrex ? Yes
Coinbase/GDAX NOT READY No
Gemini Ready No
HitBTC Deployed Yes
Huboi ? ?
Kraken Deployed Yes
LocalBitcoins Ready Yes
OKEx ? ?
Poloniex ? Yes
QuadrigaCX Deployed Yes
Shapeshift Deployed No
Note: all exchanges that have deployed SegWit are currently only sending to p2sh SegWit addresses for now. No exchange will send to a bech32 address like the ones that Electrum generates
Source 1: BitcoinCore.org
Source 2: /Bitcoin
Official statements from exchanges:
SELECTED WALLETS THAT HAVE SEGWIT ALREADY
Make sure you have a SegWit capable wallet installed and ready to use for your next bitcoin transaction
SegWit Enabled Wallets Wallet Type
Ledger Nano S Hardware
Trezor Hardware
Electrum Desktop
Armory Desktop
Edge iOS
GreenAddress iOS
BitWallet iOS
Samourai Android
GreenBits Android
Electrum Android
SegWitAddress.org Paper
FAQs
If I'm a HODLer, will it help to send my BTC to a SegWit address now?
  • No, just get ready now so that your NEXT transaction will be to a SegWit wallet. Avoid burdening the network with any unneccessary transactions for now.
Why is SegWit adoption going so slowly? Is it a time-consuming process, is there risk involved, is it laziness, or something else?
  • SegWit will require some extra work to be done right and securely. Also, most exchanges let the user pay the fee, and up to now users have not been overly concerned about fees so for some exchanges it hasn't been a priority.
Once Segwit is FULLY adopted, what do we see the fees/transaction times going to?
  • Times stay the same - fees will go down. How much and for how long depends on what the demand for transactions will be at that time.
What determines bitcoin transaction fees, to begin with?
  • Fees are charged per byte of data and are bid up by users. Miners will typically include the transaction with the highest fee/byte first.
Can you please tell me how to move my bitcoins to SegWit address in Bitcoin core wallet? Does the sender or receiver matter?
  • The Bitcoin core wallet does not yet have a GUI for its SegWit functionality. Download Electrum v3.0.3 to generate a SegWit address.
    A transaction between two SegWit addresses is a SegWit transaction.
    A transaction sent from a SegWit address to a non-SegWit address is a SegWit transaction.
    A transaction sent from a non-SegWit address to a SegWit address is NOT a SegWit transaction. You can send a SegWit Tx if the sending address is a SegWit address.
    Source: HowToToken
What wallet are you using to "batch your sends"? And how can I do that?
  • Using Electrum, the "Tools" menu option: "Pay to many".
    Just enter your receive addresses and the amounts for each, and you can send multiple transactions for nearly the price of one.
Why doesn't the Core Wallet yet support SegWit?
  • The Core Wallet supports SegWit, but its GUI doesn't. The next update will likely have GUI support built-in
Why isn't a large exchange like Coinbase SegWit ready & deployed when much smaller exchanges already are? Why do they default to high fees? Where is the leadership there?
P2SH/bech32 FAQs
What are the two SegWit address formats and why do they exist?
  • It's been a challenge for wallet developers to implement SegWit in a way that users can easily and without too much disruption migrate from legacy to SegWit addresses. The first wallets to enable SegWit addresses – Ledger, Trezor, Core, GreenAddress – use so-called “nested P2SH addresses.” This means they take the existing Pay 2 Script Hash address – starting with a “3” – and put a SegWit address into it. This enables a high grade of compatibility to existing wallets as every wallet is familiar with these addresses, but it is a workaround which results in SegWit transactions needing around 10 percent more space than they otherwise would.
    Electrum 3.0 was the first wallet to use bech32 addresses instead of nested p2sh addresses.
    Source: BTCManager.com
What is the difference in address format between SegWit address formats P2SH and bech32?
  • P2SH starts with "3..."
    bech32 starts with "bc1..."
Which addresses can I send from/to?
  • P2SH Segwit addresses can be sent to using older Bitcoin software with no Segwit support. This supports backwards compatibility
    bech32 can only be sent to from newer Bitcoin software that support bech32. Ex: Electrum
    Source: BitcoinTalk.org
Why did ThePirateBay put up two Bitcoin donation addresses on their frontpage, one bech32 and one not?
  • The address starting with a "3..." is a P2SH SegWit address that can be sent BTC from any bitcoin address including a legacy address. The address starting with a "bc1..." is a bech32 SegWit address that can only be sent to from newer wallets that support bech32.
SEGWIT BLOG GUIDES
PREVIOUS DAY'S THREADS
There's lots of excellent info in the comments of the previous threads:
submitted by Bastiat to Bitcoin [link] [comments]

Day 8: I will post this guide regularly until available solutions like SegWit, order batching, and Lightning payment channels are mass adopted, the mempool is empty once again, and tx fees are low. BTC Core SegWit GUI coming May 1, Coinbase incompetence exposed, more exchanges deploy SegWit

BACKGROUND
Segregated Witness (SegWit) was activated on the Bitcoin network August 24 2017 as a soft fork that is backward compatible with previous bitcoin transactions (Understanding Segregated Witness). Since that time wallets and exchanges have been slow to deploy SegWit, and the majority of users have not made the switch themselves.
On Dec 18 2017 Subhan Nadeem has pointed out that: If every transaction in the Bitcoin network was a SegWit transaction today, blocks would contain up to 8,000 transactions, and the 138,000 unconfirmed transaction backlog would disappear instantly. Transaction fees would be almost non-existent once again.
Mass SegWit use alone could empty the mempool, result in blocks that are not completely full, and make it possible to include transactions with $0 fee once again.
On Jan 11 2018 when BTC sends went offline at Coinbase the mempool began to rapidly empty. Later in the day when service was restored there was a sharp spike up in the mempool. Subsequently, that afternoon Brian Armstrong finally had to break his silence on the topic and admitted Coinbase is working on SegWit but has still not deployed it. It appears that the high fees bitcoin is experiencing could be easily addressed and need not exist.
SegWit is just one technique available to exchanges and users to reduce pressure on the Bitcoin network. You can make the switch to SegWit on your next transaction, and pressure exchanges to deploy SegWit NOW along with other actions that will reduce their transaction impact on the network. You can help by taking one or more of the action steps below.
ACTION STEPS
  1. If your favorite wallet has not yet implemented SegWit, kindly ask them to do so immediately. If your wallet is not committed to implementing SegWit fast, speak out online any way you can and turn up the pressure. In the meantime start using a wallet that has already implemented SegWit.
  2. If your favorite exchange has not yet implemented SegWit, try to avoid making any further purchases of bitcoin at that exchange and politely inform them that if they do not enable SegWit within 30-days they will lose your business. Sign-up for an account at a SegWit deployed/ready exchange now and initiate the verification process so you'll be ready to bail
  3. Help educate newcomers to bitcoin about the transaction issue, steer them towards SegWit wallets from day one, and encourage them to avoid ever purchasing bitcoin through non-SegWit ready exchanges that are harming bitcoin.
  4. Spread the word! Contact individuals, websites, etc that use bitcoin, explain the benefits of SegWit to everyone, and request they make the switch. Use social media to point out the benefits of SegWit adoption.
IMPORTANT NOTE: The mempool is currently still quite backlogged. If you are a long-term holder and really have no reason to move your bitcoins at this time, wait until the mempool starts to clear and transaction fees go down before moving your bitcoins to a SegWit address or SegWit friendly exchange.
BEYOND SEGWIT - BATCHING, PAYMENT CHANNELS, LIGHTNING
Batching is another great way that exchanges can reduce their fees. See: Saving up to 80% on Bitcoin transaction fees by batching payments. Despite the benefits of batching, some exchanges have been slow to implement it. Users should demand this or walk.
Beyond SegWit & Batching, Lightning Network integration will have even more effect. Lightning is now active and exchanges could setup payment channels between each other so that on-chain transactions need not take place. Some ideas have to outline how that might work are here: Google Doc - Lightning Exchanges. Which two bitcoin exchanges will be the first to establish a lightning channel between themselves and offer free/instant transfers between them for their customers? This will happen in 2018
MEMPOOL/SEGWIT STATISTICS
NEWS/DEVELOPMENTS/VICTORIES
SELECTED TOP EXCHANGES BY BATCHING & SEGWIT STATUS
Exchange Segwit Status Batching Status
Binance NOT READY Yes
Bitfinex Ready Yes
Bitonic Ready Yes
Bitstamp Deployed Yes
Bittrex ? Yes
Coinbase/GDAX NOT READY No
Gemini Ready No
HitBTC Deployed Yes
Huboi ? ?
Kraken Deployed Yes
LocalBitcoins Deployed Yes
OKEx ? ?
Poloniex ? Yes
QuadrigaCX Deployed Yes
Shapeshift Deployed No
Note: all exchanges that have deployed SegWit are currently only sending to p2sh SegWit addresses for now. No exchange will send to a bech32 address like the ones that Electrum generates
Source 1: BitcoinCore.org
Source 2: /Bitcoin
Official statements from exchanges:
SELECTED WALLETS THAT HAVE SEGWIT ALREADY
Make sure you have a SegWit capable wallet installed and ready to use for your next bitcoin transaction
SegWit Enabled Wallets Wallet Type
Ledger Nano S Hardware
Trezor Hardware
Electrum Desktop
Armory Desktop
Edge iOS
GreenAddress iOS
BitWallet iOS
Samourai Android
GreenBits Android
Electrum Android
SegWitAddress.org Paper
FAQs
If I'm a HODLer, will it help to send my BTC to a SegWit address now?
No, just get ready now so that your NEXT transaction will be to a SegWit wallet. Avoid burdening the network with any unnecessary transactions for now.
Why is SegWit adoption going so slowly? Is it a time-consuming process, is there risk involved, is it laziness, or something else?
SegWit will require some extra work to be done right and securely. Also, most exchanges let the user pay the fee, and up to now users have not been overly concerned about fees so for some exchanges it hasn't been a priority.
Once Segwit is FULLY adopted, what do we see the fees/transaction times going to?
Times stay the same - fees will go down. How much and for how long depends on what the demand for transactions will be at that time.
What determines bitcoin transaction fees, to begin with?
Fees are charged per byte of data and are bid up by users. Miners will typically include the transaction with the highest fee/byte first.
Can you please tell me how to move my bitcoins to SegWit address in Bitcoin core wallet? Does the sender or receiver matter?
The Bitcoin core wallet does not yet have a GUI for its SegWit functionality. Download the latest version of Electrum to generate a SegWit address.
A transaction between two SegWit addresses is a SegWit transaction.
A transaction sent from a SegWit address to a non-SegWit address is a SegWit transaction.
A transaction sent from a non-SegWit address to a SegWit address is NOT a SegWit transaction. You can send a SegWit Tx if the sending address is a SegWit address.
Source: HowToToken
What wallet are you using to "batch your sends"? And how can I do that?
Using Electrum, the "Tools" menu option: "Pay to many".
Just enter your receive addresses and the amounts for each, and you can send multiple transactions for nearly the price of one.
Why doesn't the Core Wallet yet support SegWit?
The Core Wallet supports SegWit, but its GUI doesn't. The next update will likely have GUI support built-in
Why isn't a large exchange like Coinbase SegWit ready & deployed when much smaller exchanges already are? Why do they default to high fees? Where is the leadership there?
Draw your own conclusions based on their own words:
March 2016 - Coinbase CEO Brian Armstrong has reservations about Core
Dec 2017 - Coinbase is STILL working on Segwit
P2SH/bech32 FAQs
What are the two SegWit address formats and why do they exist?
It's been a challenge for wallet developers to implement SegWit in a way that users can easily and without too much disruption migrate from legacy to SegWit addresses. The first wallets to enable SegWit addresses – Ledger, Trezor, Core, GreenAddress – use so-called “nested P2SH addresses.” This means they take the existing Pay 2 Script Hash address – starting with a “3” – and put a SegWit address into it. This enables a high grade of compatibility to exist wallets as every wallet is familiar with these addresses, but it is a workaround which results in SegWit transactions needing around 10 percent more space than they otherwise would.
Electrum 3.0 was the first wallet to use bech32 addresses instead of nested p2sh addresses.
Source: BTCManager.com
What is the difference in address format between SegWit address formats P2SH and bech32?
P2SH starts with "3..."
bech32 starts with "bc1..."
Which addresses can I send from/to?
P2SH Segwit addresses can be sent to using older Bitcoin software with no Segwit support. This supports backward compatibility
bech32 can only be sent to from newer Bitcoin software that support bech32. Ex: Electrum
Source: BitcoinTalk.org
Why did ThePirateBay put up two Bitcoin donation addresses on their frontpage, one bech32 and one not?
The address starting with a "3..." is a P2SH SegWit address that can be sent BTC from any bitcoin address including a legacy address. The address starting with a "bc1..." is a bech32 SegWit address that can only be sent to from newer wallets that support bech32.
SEGWIT BLOG GUIDES
PREVIOUS DAY'S THREADS
There's lots of excellent info in the comments of the previous threads:
submitted by Bastiat to Bitcoin [link] [comments]

Day 6: I will post this guide regularly until available solutions like SegWit & order batching are mass adopted, the mempool is empty once again, and tx fees are low. Refer a friend to SegWit today. There's no $10 referral offer, but you'll both get lower fees and help strengthen the BTC protocol

TL/DR
Bitcoin users can help lower transaction fees and contribute to bitcoin by switching to SegWit addresses and encourage wallets/exchanges to do the same.
SUMMARY
Segregated Witness (SegWit) was activated on the Bitcoin network August 24 2017 as a soft fork that is backward compatible with previous bitcoin transactions (Understanding Segregated Witness). Since that time wallets and exchanges have been slow to deploy SegWit, some admitting in December 2017 that they have not even started work on integrating it. Others, such as Zebpay in India have already implemented SegWit and are reaping the benefits of reduced transaction fees. If bitcoin users demand SegWit now it will temporarily relieve the transaction backlog while more even more advanced solutions such as Lightning are developed.
Batching is another great way that exchanges can reduce their fees. See: Saving up to 80% on Bitcoin transaction fees by batching payments. Despite the benefits of batching, some exchanges have been slow to implement it.
There is an opportunity now for all bitcoin users to individually contribute to help strengthen and improve the bitcoin protocol. At this point, the process requires a bit of work/learning on the part of the user, but in doing so you'll actually be advancing bitcoin and leaving what could turn out to be a multi-generational legacy for humanity.
MEMPOOL/SEGWIT STATISTICS
BACKGROUND
On Dec 18 Subhan Nadeem has pointed out that:
If every transaction in the Bitcoin network was a SegWit transaction today, blocks would contain up to 8,000 transactions, and the 138,000 unconfirmed transaction backlog would disappear instantly. Transaction fees would be almost non-existent once again.
A few thousand bitcoin users from /Bitcoin switching to making their next transactions SegWit transactions will help take pressure off the network now, and together we can encourage exchanges/wallets to rapidly deploy SegWit for everyone ASAP. Let's make 80%+ SegWit happen fast. You can help by taking one or more of the action steps below.
ACTION STEPS
  1. If your favorite wallet has not yet implemented SegWit, kindly ask them to do so immediately. In the meantime start using a wallet that has already implemented SegWit.
  2. If your favorite exchange has not yet implemented SegWit, try to avoid making any further purchases of bitcoin at that exchange and politely inform them that if they do not enable SegWit within 30-days they will lose your business. Sign-up for an account at a SegWit deployed/ready exchange now and initiate the verification process so you'll be ready to bail
  3. Help educate newcomers to bitcoin about the transaction issue, steer them towards SegWit wallets from day one, and encourage them to avoid ever purchasing bitcoin through non-SegWit ready exchanges that are harming bitcoin.
  4. Spread the word! Conact individuals, websites, etc that use bitcoin, explain the benefits of SegWit to everyone, and request they make the switch
IMPORTANT NOTE: The mempool is currently still quite backlogged. If you are a long-term holder and really have no reason to move your bitcoins at this time, wait until the mempool starts to clear and transaction fees go down before moving your bitcoins to a SegWit address or SegWit friendly exchange.
SELECTED TOP EXCHANGES BY BATCHING & SEGWIT STATUS
Exchange Segwit Status Batching Status
Binance NOT READY Yes
Bitfinex Ready Yes
Bitonic Ready Yes
Bitstamp Deployed Yes
Bittrex ? Yes
Coinbase/GDAX NOT READY No
Gemini Ready No
HitBTC Deployed Yes
Huboi ? ?
Kraken Deployed Yes
LocalBitcoins Ready Yes
OKEx ? ?
Poloniex ? Yes
QuadrigaCX Deployed Yes
Shapeshift Deployed No
  • Note: all exchanges that have deployed SegWit are currently only sending to p2sh SegWit addresses for now. No exchange will send to a bech32 address like the ones that Electrum generates
Source 1: BitcoinCore.org
Source 2: /Bitcoin
Official statements from exchanges:
SELECTED WALLETS THAT HAVE SEGWIT ALREADY
Make sure you have a SegWit capable wallet installed and ready to use for your next bitcoin transaction
SegWit Enabled Wallets Wallet Type
Ledger Nano S Hardware
Trezor Hardware
Electrum Desktop
Armory Desktop
Edge iOS
GreenAddress iOS
BitWallet iOS
Samourai Android
GreenBits Android
Electrum Android
FAQs
If I'm a HODLer, will it help to send my BTC to a SegWit address now?
  • No, just get ready now so that your NEXT transaction will be to a SegWit wallet. Avoid burdening the network with any unneccessary transactions for now.
Why is SegWit adoption going so slowly? Is it a time-consuming process, is there risk involved, is it laziness, or something else?
  • SegWit will require some extra work to be done right and securely. Also, most exchanges let the user pay the fee, and up to now users have not been overly concerned about fees so for some exchanges it hasn't been a priority.
Once Segwit is FULLY adopted, what do we see the fees/transaction times going to?
  • Times stay the same - fees will go down. How much and for how long depends on what the demand for transactions will be at that time.
What determines bitcoin transaction fees, to begin with?
  • Fees are charged per byte of data and are bid up by users. Miners will typically include the transaction with the highest fee/byte first.
Can you please tell me how to move my bitcoins to SegWit address in Bitcoin core wallet? Does the sender or receiver matter?
  • The Bitcoin core wallet does not yet have a GUI for its SegWit functionality. Download Electrum v3.0.3 to generate a SegWit address.
    A transaction between two SegWit addresses is a SegWit transaction.
    A transaction sent from a SegWit address to a non-SegWit address is a SegWit transaction.
    A transaction sent from a non-SegWit address to a SegWit address is NOT a SegWit transaction. You can send a SegWit Tx if the sending address is a SegWit address.
    Source: HowToToken
What wallet are you using to "batch your sends"? And how can I do that?
  • Using Electrum, the "Tools" menu option: "Pay to many".
    Just enter your receive addresses and the amounts for each, and you can send multiple transactions for nearly the price of one.
Why doesn't the Core Wallet yet support SegWit?
  • The Core Wallet supports SegWit, but its GUI doesn't. The next update will likely have GUI support built-in
Why isn't a large exchange like Coinbase SegWit ready & deployed when much smaller exchanges already are? Why do they default to high fees? Where is the leadership there?
P2SH/bech32 FAQs
What are the two SegWit address formats and why do they exist?
  • It's been a challenge for wallet developers to implement SegWit in a way that users can easily and without too much disruption migrate from legacy to SegWit addresses. The first wallets to enable SegWit addresses – Ledger, Trezor, Core, GreenAddress – use so-called “nested P2SH addresses.” This means they take the existing Pay 2 Script Hash address – starting with a “3” – and put a SegWit address into it. This enables a high grade of compatibility to existing wallets as every wallet is familiar with these addresses, but it is a workaround which results in SegWit transactions needing around 10 percent more space than they otherwise would.
    Electrum 3.0 was the first wallet to use bech32 addresses instead of nested p2sh addresses.
    Source: BTCManager.com
What is the difference in address format between SegWit address formats P2SH and bech32?
  • P2SH starts with "3..."
    bech32 starts with "bc1..."
Which addresses can I send from/to?
  • P2SH Segwit addresses can be sent to using older Bitcoin software with no Segwit support. This supports backwards compatibility
    bech32 can only be sent to from newer Bitcoin software that support bech32. Ex: Electrum
    Source: BitcoinTalk.org
Why did ThePirateBay put up two Bitcoin donation addresses on their frontpage, one bech32 and one not?
  • The address starting with a "3..." is a P2SH SegWit address that can be sent BTC from any bitcoin address including a legacy address. The address starting with a "bc1..." is a bech32 SegWit address that can only be sent to from newer wallets that support bech32.
SEGWIT BLOG GUIDES
PREVIOUS DAY'S THREADS
There's lots of excellent info in the comments of the previous threads:
submitted by Bastiat to Bitcoin [link] [comments]

Bitcoin ATMs - How To Use Them - YouTube Given a number n, count the number of 1's (set bits) in ... Denarium “Physical Blockchain tutorial 31: Base-32 encoding How to Calculate Bitcoin Transaction Size

Titan Bitcoin is going after the premium market with the priciest Titan One Gold coin priced at $2,279, but then again it contains 1 troy ounce of 24-karat gold and one bitcoin.The Titan One ... A nibble is 4 bits. Byte. Today, a byte is 8 bits. 1 character, e.g., "a", is one byte. Kilobyte (KB) A kilobyte is 1,024 bytes. 2 or 3 paragraphs of text. Megabyte (MB) A megabyte is 1,048,576 bytes or 1,024 kilobytes. 873 pages of plain text (1,200 characters). 4 books (200 pages or 240,000 characters). Gigabyte (GB) At today’s value, for instance, one bit is about US$0.011 according to this helpful tool. Likewise, one mBTC is worth just over $11. So at today’s rate, a pair of socks for 100 bits would be quite a good deal indeed at just over one dollar. Bitcoin Satoshi Chart. Here is a chart showing the Bitcoin Divisibility amounts, taken from ... 5 bits - 32 6 bits - 64 7 bits - 128 8 bits - 256 - one byte Mathematically: n bits yields 2 n patterns (2 to the nth power) One Byte - 256 Patterns (demo) 1 byte is group of 8 bits 8 bits can make 256 different patterns How to use the 256 patterns? How to store a number in a byte? Start with 0, go up, one pattern per number, until run out of ... Which transactions, of all the ones broadcasted, are included is very dependent on the miner, as he/she is the one who groups them up and includes them in the block. As Nate noted below, there is also a 1MB block size limit which limits how many transactions can be included in a block. This limit is to prevent huge blocks that clog the network and may be removed if the number of transactions ...

[index] [2735] [20496] [31913] [31171] [30703] [48107] [25262] [26409] [15024] [23679]

Bitcoin ATMs - How To Use Them - YouTube

Mining #MangoCoinz on my old LG GT-450. You can do it yourself every day. Keep your mangoz or sell them for #bitcoin. Unlike fiat currency, bitcoin has no centralized issuing authority.[57][58][59] The network is programmed to increase the money supply as a geometric series until the total number of bitcoins ... As an Amazon Associate I earn from qualifying purchases. DISCLAIMER: This video and description contains affiliate links, which means that if you click on one of the product links, I’ll receive ... Supplement to the cryptocurrency video: How hard is it to find a 256-bit hash just by guessing and checking? What kind of computer would that take? Cryptocur... Every time we send a bitcoin transaction, we pay a fee relative to its size. Strangely, this has almost nothing to do with how much money is being sent -- the blockchain world just isn't that ...

#