Who cares about political tweets from some random country's president when payment channels are a much more interesting and are actually capable of carrying value?
So let's have a short history of various payment channel techs!
Generation 0: Satoshi's Broken nSequence Channels
Because Satoshi's Vision included payment channels, except his implementation sucked so hard we had to go fix it and added RBF as a by-product.
Originally, the plan for nSequence was that mempools would replace any transaction spending certain inputs with another transaction spending the same inputs, but only if the nSequence field of the replacement was larger.
Since 0xFFFFFFFF was the highest value that nSequence could get, this would mark a transaction as "final" and not replaceable on the mempool anymore.
In fact, this "nSequence channel" I will describe is the reason why we have this weird rule about nLockTime and nSequence. nLockTime actually only works if nSequence is not 0xFFFFFFFF i.e. final. If nSequence is 0xFFFFFFFF then nLockTime is ignored, because this if the "final" version of the transaction.
So what you'd do would be something like this:
- You go to a bar and promise the bartender to pay by the time the bar closes. Because this is the Bitcoin universe, time is measured in blockheight, so the closing time of the bar is indicated as some future blockheight.
- For your first drink, you'd make a transaction paying to the bartender for that drink, paying from some coins you have. The transaction has an nLockTime equal to the closing time of the bar, and a starting nSequence of 0. You hand over the transaction and the bartender hands you your drink.
- For your succeeding drink, you'd remake the same transaction, adding the payment for that drink to the transaction output that goes to the bartender (so that output keeps getting larger, by the amount of payment), and having an nSequence that is one higher than the previous one.
- Eventually you have to stop drinking. It comes down to one of two possibilities:
- You drink until the bar closes. Since it is now the nLockTime indicated in the transaction, the bartender is able to broadcast the latest transaction and tells the bouncers to kick you out of the bar.
- You wisely consider the state of your liver. So you re-sign the last transaction with a "final" nSequence of 0xFFFFFFFF i.e. the maximum possible value it can have. This allows the bartender to get his or her funds immediately (nLockTime is ignored if nSequence is 0xFFFFFFFF), so he or she tells the bouncers to let you out of the bar.
Now that of course is a payment channel. Individual payments (purchases of alcohol, so I guess buying coffee is not in scope for payment channels). Closing is done by creating a "final" transaction that is the sum of the individual payments. Sure there's no routing and channels are unidirectional and channels have a maximum lifetime but give Satoshi a break, he was also busy inventing Bitcoin at the time.
Now if you noticed I called this kind of payment channel "broken". This is because the mempool rules are not consensus rules, and cannot be validated (nothing
about the mempool can be validated onchain: I sigh every time somebody proposes "let's make block size dependent on mempool size", mempool state cannot be validated by onchain data). Fullnodes can't see all of the transactions you signed, and then validate that the final one with the maximum nSequence is the one that actually is used onchain. So you can do the below:
- Become friends with Jihan Wu, because he owns >51% of the mining hashrate (he totally reorged Bitcoin to reverse the Binance hack right?).
- Slip Jihan Wu some of the more interesting drinks you're ordering as an incentive to cooperate with you. So say you end up ordering 100 drinks, you split it with Jihan Wu and give him 50 of the drinks.
- When the bar closes, Jihan Wu quickly calls his mining rig and tells them to mine the version of your transaction with nSequence 0. You know, that first one where you pay for only one drink.
- Because fullnodes cannot validate nSequence, they'll accept even the nSequence=0 version and confirm it, immutably adding you paying for a single alcoholic drink to the blockchain.
- The bartender, pissed at being cheated, takes out a shotgun from under the bar and shoots at you and Jihan Wu.
- Jihan Wu uses his mystical chi powers (actually the combined exhaust from all of his mining rigs) to slow down the shotgun pellets, making them hit you as softly as petals drifting in the wind.
- The bartender mutters some words, clothes ripping apart as he or she (hard to believe it could be a she but hey) turns into a bear, ready to maul you for cheating him or her of the payment for all the 100 drinks you ordered from him or her.
- Steely-eyed, you stand in front of the bartender-turned-bear, daring him to touch you. You've watched Revenant, you know Leonardo di Caprio could survive a bear mauling, and if some posh actor can survive that, you know you can too. You make a pose. "Drunken troll logic attack!"
- I think I got sidetracked here.
- Bears are bad news.
- You can't reasonably invoke "Satoshi's Vision" and simultaneously reject the Lightning Network because it's not onchain. Satoshi's Vision included a half-assed implementation of payment channels with nSequence, where the onchain transaction represented multiple logical payments, exactly what modern offchain techniques do (except modern offchain techniques actually work). nSequence (the field, but not its modern meaning) has been in Bitcoin since BitCoin For Windows Alpha 0.1.0. And its original intent was payment channels. You can't get nearer to Satoshi's Vision than being a field that Satoshi personally added to transactions on the very first public release of the BitCoin software, like srsly.
- Miners can totally bypass mempool rules. In fact, the reason why nSequence has been repurposed to indicate "optional" replace-by-fee is because miners are already incentivized by the nSequence system to always follow replace-by-fee anyway. I mean, what do you think those drinks you passed to Jihan Wu are, other than the fee you pay him to mine a specific version of your transaction?
- Satoshi made mistakes. The original design for nSequence is one of them. Today, we no longer use nSequence in this way. So diverging from Satoshi's original design is part and parcel of Bitcoin development, because over time, we learn new lessons that Satoshi never knew about. Satoshi was an important landmark in this technology. He will not be the last, or most important, that we will remember in the future: he will only be the first.
Incentive-compatible time-limited unidirectional channel; or, Satoshi's Vision, Fixed (if transaction malleability hadn't been a problem, that is).
Now, we know the bartender will turn into a bear and maul you if you try to cheat the payment channel, and now that we've revealed you're good friends with Jihan Wu, the bartender will no longer accept a payment channel scheme that lets one you cooperate with a miner to cheat the bartender.
Fortunately, Jeremy Spilman proposed a better way that would not let you cheat the bartender.
First, you and the bartender perform this ritual:
- You get some funds and create a transaction that pays to a 2-of-2 multisig between you and the bartender. You don't broadcast this yet: you just sign it and get its txid.
- You create another transaction that spends the above transaction. This transaction (the "backoff") has an nLockTime equal to the closing time of the bar, plus one block. You sign it and give this backoff transaction (but not the above transaction) to the bartender.
- The bartender signs the backoff and gives it back to you. It is now valid since it's spending a 2-of-2 of you and the bartender, and both of you have signed the backoff transaction.
- Now you broadcast the first transaction onchain. You and the bartender wait for it to be deeply confirmed, then you can start ordering.
The above is probably vaguely familiar to LN users. It's the funding process of payment channels! The first transaction, the one that pays to a 2-of-2 multisig, is the funding transaction that backs the payment channel funds.
So now you start ordering in this way:
- For your first drink, you create a transaction spending the funding transaction output and sending the price of the drink to the bartender, with the rest returning to you.
- You sign the transaction and pass it to the bartender, who serves your first drink.
- For your succeeding drinks, you recreate the same transaction, adding the price of the new drink to the sum that goes to the bartender and reducing the money returned to you. You sign the transaction and give it to the bartender, who serves you your next drink.
- At the end:
- If the bar closing time is reached, the bartender signs the latest transaction, completing the needed 2-of-2 signatures and broadcasting this to the Bitcoin network. Since the backoff transaction is the closing time + 1, it can't get used at closing time.
- If you decide you want to leave early because your liver is crying, you just tell the bartender to go ahead and close the channel (which the bartender can do at any time by just signing and broadcasting the latest transaction: the bartender won't do that because he or she is hoping you'll stay and drink more).
- If you ended up just hanging around the bar and never ordering, then at closing time + 1 you broadcast the backoff transaction and get your funds back in full.
Now, even if you pass 50 drinks to Jihan Wu, you can't give him the first transaction (the one which pays for only one drink) and ask him to mine it: it's spending a 2-of-2 and the copy you have only contains your own signature. You need the bartender's signature to make it valid, but he or she sure as hell isn't going to cooperate in something that would lose him or her money, so a signature from the bartender validating old state where he or she gets paid less isn't going to happen.
So, problem solved, right? Right? Okay, let's try it. So you get your funds, put them in a funding tx, get the backoff tx, confirm the funding tx...
Once the funding transaction confirms deeply, the bartender laughs uproariously. He or she summons the bouncers, who surround you menacingly.
"I'm refusing service to you," the bartender says.
"Fine," you say. "I was leaving anyway;" You smirk. "I'll get back my money with the backoff transaction, and posting about your poor service on reddit so you get negative karma, so there!"
"Not so fast," the bartender says. His or her voice chills your bones. It looks like your exploitation of the Satoshi nSequence payment channel is still fresh in his or her mind. "Look at the txid of the funding transaction that got confirmed."
"What about it?" you ask nonchalantly, as you flip open your desktop computer and open a reputable blockchain explorer.
What you see shocks you.
"What the --- the txid is different! You--- you changed my signature
?? But how? I put the only copy of my private key in a sealed envelope in a cast-iron box inside a safe buried in the Gobi desert protected by a clan of nomads who have dedicated their lives and their childrens' lives to keeping my private key safe in perpetuity!"
"Didn't you know?" the bartender asks. "The components of the signature are just very large numbers. The sign of one of the signature components can be changed, from positive to negative, or negative to positive, and the signature will remain valid. Anyone can do that, even if they don't know the private key. But because Bitcoin includes the signatures in the transaction when it's generating the txid, this little change also changes the txid." He or she chuckles. "They say they'll fix it by sep
arating the sig
natures from the transaction body. They're saying that these kinds of signature malleability won't affect transaction ids anymore after they do this, but I bet I can get my good friend Jihan Wu to delay this 'SepSig' plan for a good while yet. Friendly guy, this Jihan Wu, it turns out all I had to do was slip him 51 drinks and he was willing to mine a tx with the signature signs flipped." His or her grin widens. "I'm afraid your backoff transaction won't work anymore, since it spends a txid that is not existent and will never be confirmed. So here's the deal. You pay me 99% of the funds in the funding transaction, in exchange for me signing the transaction that spends with the txid that you see onchain. Refuse, and you lose 100% of the funds and every other HODLer, including me, benefits from the reduction in coin supply. Accept, and you get to keep 1%. I lose nothing if you refuse, so I won't care if you do, but consider the difference of getting zilch vs. getting 1% of your funds." His or her eyes glow. "GENUFLECT RIGHT NOW."
- Payback's a bitch.
- Transaction malleability is a bitchier bitch. It's why we needed to fix the bug in SegWit. Sure, MtGox claimed they were attacked this way because someone kept messing with their transaction signatures and thus they lost track of where their funds went, but really, the bigger impetus for fixing transaction malleability was to support payment channels.
- Yes, including the signatures in the hash that ultimately defines the txid was a mistake. Satoshi made a lot of those. So we're just reiterating the lesson "Satoshi was not an infinite being of infinite wisdom" here. Satoshi just gets a pass because of how awesome Bitcoin is.
CLTV-protected Spilman Channels
Using CLTV for the backoff branch.
This variation is simply Spilman channels, but with the backoff transaction replaced with a backoff branch in the SCRIPT you pay to. It only became possible after OP_CHECKLOCKTIMEVERIFY (CLTV) was enabled in 2015.
Now as we saw in the Spilman Channels discussion, transaction malleability means that any pre-signed offchain transaction can easily be invalidated by flipping the sign of the signature of the funding transaction while the funding transaction is not yet confirmed.
This can be avoided by simply putting any special requirements into an explicit branch of the Bitcoin SCRIPT. Now, the backoff branch is supposed to create a maximum lifetime for the payment channel, and prior to the introduction of OP_CHECKLOCKTIMEVERIFY this could only be done by having a pre-signed nLockTime transaction.
With CLTV, however, we can now make the branches explicit in the SCRIPT that the funding transaction pays to.
Instead of paying to a 2-of-2 in order to set up the funding transaction, you pay to a SCRIPT which is basically "2-of-2, OR this singlesig after a specified lock time".
With this, there is no backoff transaction that is pre-signed and which refers to a specific txid. Instead, you can create the backoff transaction later, using whatever txid the funding transaction ends up being confirmed under. Since the funding transaction is immutable once confirmed, it is no longer possible to change the txid afterwards.
Todd Micropayment Networks
The old hub-spoke model (that isn't how LN today actually works).
One of the more direct predecessors of the Lightning Network was the hub-spoke model discussed by Peter Todd. In this model, instead of payers directly having channels to payees, payers and payees connect to a central hub server. This allows any payer to pay any payee, using the same channel for every payee on the hub. Similarly, this allows any payee to receive from any payer, using the same channel.
Remember from the above Spilman example? When you open a channel to the bartender, you have to wait around for the funding tx to confirm. This will take an hour at best
. Now consider that you have to make channels for everyone you want to pay to. That's not very scalable.
So the Todd hub-spoke model has a central "clearing house" that transport money from payers to payees. The "Moonbeam" project takes this model. Of course, this reveals to the hub who the payer and payee are, and thus the hub can potentially censor transactions. Generally, though, it was considered that a hub would more efficiently censor by just not maintaining a channel with the payer or payee that it wants to censor (since the money it owned in the channel would just be locked uselessly if the hub won't process payments to/from the censored user).
In any case, the ability of the central hub to monitor payments means that it can surveill the payer and payee, and then sell this private transactional data to third parties. This loss of privacy would be intolerable today.
Peter Todd also proposed that there might be multiple hubs that could transport funds to each other on behalf of their users, providing somewhat better privacy.
Another point of note is that at the time such networks were proposed, only unidirectional (Spilman) channels were available. Thus, while one could be a payer, or payee, you would have to use separate channels for your income versus for your spending. Worse, if you wanted to transfer money from your income channel to your spending channel, you had to close both and reshuffle the money between them, both onchain activities.
Poon-Dryja Lightning Network
Bidirectional two-participant channels.
The Poon-Dryja channel mechanism has two important properties:
- No time limit.
Both the original Satoshi and the two Spilman variants are unidirectional: there is a payer and a payee, and if the payee wants to do a refund, or wants to pay for a different service or product the payer is providing, then they can't use the same unidirectional channel.
The Poon-Dryjam mechanism allows channels, however, to be bidirectional instead: you are not a payer or a payee on the channel, you can receive or send at any time as long as both you and the channel counterparty are online.
Further, unlike either of the Spilman variants, there is no time limit for the lifetime of a channel. Instead, you can keep the channel open for as long as you want.
Both properties, together, form a very powerful scaling property
that I believe most people have not appreciated. With unidirectional channels, as mentioned before, if you both earn and spend over the same network of payment channels, you would have separate channels for earning and spending. You would then need to perform onchain operations to "reverse" the directions of your channels periodically. Secondly, since Spilman channels have a fixed lifetime, even if you never used either channel, you would have to periodically "refresh" it by closing it and reopening.
With bidirectional, indefinite-lifetime channels, you may instead open some channels when you first begin managing your own money, then close them only after your lawyers have executed your last will and testament on how the money in your channels get divided up to your heirs: that's just two onchain transactions in your entire lifetime. That is the potentially very powerful scaling property that bidirectional, indefinite-lifetime channels allow.
I won't discuss the transaction structure needed for Poon-Dryja bidirectional channels --- it's complicated and you can easily get explanations with cute graphics elsewhere.
a weakness of Poon-Dryja that people tend to gloss over (because it was fixed very well by RustyReddit
- You have to store all the revocation keys of a channel. This implies you are storing 1 revocation key for every channel update, so if you perform millions of updates over your entire lifetime, you'd be storing several megabytes of keys, for only a single channel. RustyReddit fixed this by requiring that the revocation keys be generated from a "Seed" revocation key, and every key is just the application of SHA256 on that key, repeatedly. For example, suppose I tell you that my first revocation key is SHA256(SHA256(seed)). You can store that in O(1) space. Then for the next revocation, I tell you SHA256(seed). From SHA256(key), you yourself can compute SHA256(SHA256(seed)) (i.e. the previous revocation key). So you can remember just the most recent revocation key, and from there you'd be able to compute every previous revocation key. When you start a channel, you perform SHA256 on your seed for several million times, then use the result as the first revocation key, removing one layer of SHA256 for every revocation key you need to generate. RustyReddit not only came up with this, but also suggested an efficient O(log n) storage structure, the shachain, so that you can quickly look up any revocation key in the past in case of a breach. People no longer really talk about this O(n) revocation storage problem anymore because it was solved very very well by this mechanism.
Another thing I want to emphasize is that while the Lightning Network paper and many of the earlier presentations developed from the old Peter Todd hub-and-spoke model, the modern Lightning Network takes the logical conclusion of removing a strict separation between "hubs" and "spokes". Any node on the Lightning Network can very well work as a hub for any other node. Thus, while you might operate as "mostly a payer", "mostly a forwarding node", "mostly a payee", you still end up being at least partially a forwarding node ("hub") on the network, at least part of the time. This greatly reduces the problems of privacy inherent in having only a few hub nodes: forwarding nodes cannot get significantly useful data from the payments passing through them, because the distance between the payer and the payee can be so large that it would be likely that the ultimate payer and the ultimate payee could be anyone on the Lightning Network.
- We can decentralize if we try hard enough!
- "Hubs bad" can be made "hubs good" if everybody is a hub.
- Smart people can solve problems. It's kinda why they're smart.
After LN, there's also the Decker-Wattenhofer Duplex Micropayment Channels (DMC). This post is long enough as-is, LOL. But for now, it uses a novel "decrementing nSequence channel", using the new
relative-timelock semantics of nSequence (not the broken one originally by Satoshi). It actually uses multiple such "decrementing nSequence" constructs, terminating in a pair of Spilman channels, one in both directions (thus "duplex"). Maybe I'll discuss it some other time.
The realization that channel constructions could actually hold more channel constructions inside them (the way the Decker-Wattenhofer puts a pair of Spilman channels inside a series of "decrementing nSequence channels") lead to the further thought behind Burchert-Decker-Wattenhofer channel factories. Basically, you could host multiple two-participant channel constructs inside a larger multiparticipant "channel" construct (i.e. host multiple channels inside a factory).
Further, we have the Decker-Russell-Osuntokun or "eltoo" construction. I'd argue that this is "nSequence done right". I'll write more about this later, because this post is long enough.
- Bitcoin offchain scaling is more powerful than you ever thought.
I've taken the liberty of rounding up all the questions and answers provided from Hydro's most recent AMA hosted with BitcoinMarkets incase you missed it. Enjoy! Hydro Q&A’s Q (knonsu):
How does Snowflake relate to other identity protocols out there like Civic and uPort ? A.1 (Anurag):
We see snowflake as existing a layer below these types of projects. Even without blockchain, identity is a broad term. Different people around the world have different forms of identity (state ID, country ID, social media IDs, etc). Civic, uPort, and other blockchain projects help to build specific types of an on-chain identity for a user; however those IDs are meaningful in different ways to different observers. For instance, imagine that a government or business builds a system that accepts Civic as a form of identity while another government/business only recognizes uPort identities. On top of this, certain systems only care about information tied to a user’s social media profile. A user can maintain one standard Snowflake as a base layer and set each of these different forms of identity as a resolver. Snowflake eliminates the need for global unanimous adoption of a singular identity standard and rather allows systems to build business logic off of identity standards they themselves recognize. Follow up Q (knonsu):
thats cool. so its totally depends on the person/ institute utilizing it . One problem I found is how easy its to create fake identities (in their basic system). A.2 (Anurag):
Yup! So people can conduct off-chain verifications to prove that you own a snowflake, and then tie an on-chain verification to your Snowflake. This links real-world KYC to your on-chain ID, so sure you could mint another snowflake, but that same party won't validate it again for you. Anyone who trusts that party would be able to accept their validations, and people who don't trust that party can rely on a different validator they do trust.
— Q (kat):
How big is the team working specifically on Hydro products? Can we get a numbers breakdown of engineers, biz dev, etc? Do you have plans to scale this team as the Hydro project develops? A.1 (Andy):
Our Hydro team is 8 people.
Devlopers (Myself and Noah)
Product (Anurag and Shane)
Founders (Mike and Matt)
The nice thing about Hydrogen though is we have a team of 30 people who we can leverage for different things. For example, Noah and I do not build mobile apps, but we have a front end team that is well versed in mobile app development. So while they are not directly on the Hydro team they do have a direct impact on Hydro.
Hydrogen as a company is working to grow pretty rapidly. As we grow we will be filling out more positions in both blockchain and non-blockchain rolls. A.2 (Anurag):
To add to Andy's answer - pretty much everyone working for Hydrogen helps out with Hydro in some way, whether via design, front-end development, API support, business discussion, etc.
Here's our full team: https://www.hydrogenplatform.com/about
— Q (rocket man):
So in the age of ICOs, what motivated your team to not pursue that funding model and instead have a token distribution for developers? A (Andy):
This was something that we spent a very long time considering and discussing. We spent a lot of resources (time, money & energy) trying to find the best solution for us going forward. When it was all said and done, we decided on an airdrop because of two main things, getting the token into the hands of people who will actually use it and regulatory concerns.
We feel as though our distribution was the fairest approach that allowed for people with actual interest in the Hydro community to get involved. Overall, we have been very pleased with the level of community engagement from people who are interested in the utility of the Hydro token and we feel that a lot of this can be credited to our distribution strategy.
— Q (matheussiq8):
How hydro tokens will be used is still vague in the Snowflake whitepaper draft. Would the amount required to hold depend on the volume of API calls or some other parameter? For example, if I decide to implement raindrop and later snowflake in my small webshop would I need to hold the same amount of tokens as Binance (if they ever implement it of course…)? A (Noah):
as always, the permissionlessness of public blockchains is a double-edged sword. smart contracts partially solve the problem by letting us enforce certain things on-chain (minimum token balances, signature validity, etc.), but there are limits. so, re. your specific question: in raindrop we do not vary the staking requirement across users, because that would necessarily involve value judgements we are not comfortable making as a centralized entity. however, there are two types of staking required for raindrop:
- “institutional staking” requires entities who wish to sign up raindrop users *on their behalf* (i.e. passing new users’ addresses to the smart contract as parameters rather than new users transacting directly from their accounts) to stake a significant amount of hydro. these are the players we want to ensure are acting in the best interests of the community. in this model, hydro is simply one of many institutional stakers (where we sign up users on our kickass mobile app, which will be out soon).
- “user staking” requires individuals who wish to sign up for raindrop on their own, i.e. transact directly with the smart contract, are able to do so by staking a much smaller amount of hydro.
What this all means for you, as a potential customer of our API, is that you don’t actually have to worry about the staking requirement or signing up users at all, and can simply use our API in conjunction with the Hydro app.
Looking ahead to Snowflake, we have big plans to integrate increasing sophisticated uses of the token into the product. to some extent these are still up in the air, but rest assured that we are very focused on building a strong tokenomics structure. At a high level, the core token mechanism for snowflake will involve depositing tokens into the snowflake smart contract. These deposits will allow native staking/payment/incentive functionality denominated in hydro, without the hassle and worry of using ether with every call.
— Q (Hodlall):
When is raindrop Android app is releasing A (Andy):
It is currently under development. We have a bunch of android phones with different OS on the way. It is hard to give a set date as we don't know what unforeseen issues could come up during the process though. All I can say is it is literally all that our mobile development team is working on
— Q (Jeff_We_Cannafi):
To piggyback on matheussiq8’s question, how do these identity tokens compare to existing forms of identity authentication, and do you anticipate the tokens themselves will be traded on exchanges? A (Andy):
In my opinion, the main difference between what we are working towards and others like civic and uport is the scope of what we are aiming to do. We understand the value of having KYC on the blockchain and "One click signup", but really I think blockchain identity can be so much more than that. We are aiming to create a completely extendable and modular protocol which will allow for people to link anything they desire to their blockchain identity. Other protocols can tend to lean towards centralization (more a fault of current KYC procedures than the projects themselves) and we feel like this doesn't have to be the case. At least for now, something like KYC needs to have central authorities to verify user information, but why can't I also link my crypto kitties to my blockchain id or my linkedin profile to my blockchain id?
Overall, what we are trying to build will easily allow for other blockchain developers to create robust identity solutions for whatever application they feel fit with Snowflake being at the core of that. We feel that this is crucial to eventually creating a completely open and decentralized identity system. Anyone can join and anyone can add what THEY consider to be an identity, but I only have to accept what I consider to be an identity.
As far as trading, Snowflake Identity tokens will never be tradable. We feel that you identity should always be linked to you. This would be a dangerous road to a very easy black market for people's identities
— Q (Jrock):
What do you find the hardest part of pitching icos to regular companies?
Also what do you think needs to happen for widespread crypto adoption? A (Shane):
If you mean pitching Hydro to regular companies (we're not an ICO :stuck_out_tongue:), I would say the hardest part is getting the larger companies to move faster than a snail's pace. There are too many chefs in the kitchen and sometimes there is a lack of top-down strategy on blockchain, and it leaves large enterprises paralyzed sometimes. We try to resolve this by pitching how easy Hydro is to use, and how it connects to our broader Hydrogen ecosystem which can add value in a lot of places.
In my opinion, widespread crypto adoption is going to be dependent on how parallelization plays out. If crypto's only option is to create a new parallel economy, widespread adoption is going to be slow and arduous and will take decades. However, if blockchain is able to be infused or layered on some of the current systems we have in place, the adoption will be much faster and broader. Ultimately this comes down to the usage of private vs public chains - the more private and centralized chains that get implemented, the farther the mainstream adoption will get pushed out.
— Q (Luke):
One aspect of Hydro that is beginning to really intrigue me are the potential use cases and dapps that can be built by external developers ontop of the Hydro protocol layers for each phase.
- Having held various dev meetups and networking at various conferences, how are you finding the process of attracting developers to start building dapps and products in your ecosystem?
- I understand the HCDP is getting updated with various new rules and bounties for dapps to be built, have you approached any developers yet with this new offer, and if so, how has the reception been?
- How else do you intend to attract developers towards building on the Hydro protocols?
- Through our events, we're mainly focused on helping expand the blockchain-focused developer community. We help give exposure to projects we find to be doing neat, innovative work in the space and keep ongoing dialogue with these communities.
- In particular, to provide impetus to developers in the Hydro ecosystem, we've established the HCDP. The new process will involve putting out specific task requests. In the next week or so we'll have published specifications for dApps that can be built on top of Snowflake. We ourselves will not be building these dApps (they have nothing to do with Hydrogen's space as a company). This helps the ecosystem expand outside of Hydrogen-specific use-cases.
- ^^Through the above process to get them started. Eventually, we want the Hydro development process to be community-driven, so people are building on Hydro because it benefits their own programs and applications.
— Q (elmer_FUD):
Hey Hydro Team! Here's a few question I've got for you after checking out the Raindrop and Snowflake whitepapers:
How has your experience working in the Ethereum ecosystem been so far?
While you are currently focused on the financial sector, would you consider actively marketing to other sectors such as healthcare and education in the future?
It seems like both Raindrop and Snowflake would be useful in any environment that processes or stores sensitive data.
Do you have plans to release official Raindrop SDK packages in other languages in the future?
A bit more of a specific question: Raindrop is looks like a great product to use in a PCI-DSS environment - do you have thoughts on whether or not it the product is ready for primetime and do you think the industry standards and government regulation is prepared to handle these kinds of systems? A (Andy):
Thanks for the questions! I'm gonna answer each in a separate response in this thread
Overall it has been pretty solid. There is still a ton of room for growth in terms of documentation and stuff like that, but it is miles ahead of basically every other blockchain platform I have worked with. By far the biggest pain has been handling gas costs when considering the user experience. When trying to build actual products that people will want to use we feel that making it user friendly is something that many blockchain projects have not focused on nearly enough.
Yeah certainly. We focus on fintech as that is where the rest of our companies APIs focus and that is where we have the most connections, but much of what we are building is much further reaching than that. Just as far as authentication goes, it really can apply to any major field and we intend to market it as such.
We currently have Python and JS SDKs and have had a few java ones submitted through our community dev program. We have been revamping that program, but I anticipate we will be putting up more bounties for most major languages. I have considered making a few more myself, but we feel that they could be better suited as community projects.
I completely agree. Raindrop and blockchain authentication when handling anything around payments is a great application. I think the biggest thing is actually convincing regulatory bodies that the protocols we have build are secure (since many can still be scared of blockchain). I definitely see this as a direct use case though
— Q.1 (khonsu):
What kind of banking relations do you have as a company, do they (banks) understand what you are trying to do ? Any VCs approached you for funding ? explain your business model. A.1 (Shane):
Hydrogen has existed since 2009 in the form of Hedgeable. Hedgeable is a consumer-facing online investing app, and the tech behind it eventually spawned the Hydrogen tech platform. The story of how the transition happened goes essentially like this: (1) Hedgeable was disrupting banks & investing firms, (2) banks & investing firms started contacting us and seeing if we would help them digitize & automate their own businesses, (3) we started packaging up our tech and selling it to the banks. There was so much demand for this from financial institutions that we spun out a new company (Hydrogen).
So to get back to your original question: we have some long-standing relationships in the banking & finance world, and to this day we have inbound leads from that space coming in every week. The key thing to keep in mind is that these institutions move extremely slowly, but they do understand the core value prop of our platform. Many of these firms are still in the midst of basic digitization efforts (i.e. moving from really slow offline processes to simple digital infrastructure), and that is the primary thing we are helping them with in early stages. But they are also keen on blockchain tech and they will naturally turn to us for that once they reach that point. We do have a few relationships with big financial companies in which Hydro/blockchain are already part of the discussion.
We have revenue and don't need to rely on VCs. It is our general philosophy that building a business sustainably with actual clients and revenue is a good approach, but we would consider working with the right VC if that came to be and we wanted to scale more quickly. Right now, that is not an immediate concern for us.
Our business model is in charging developers and enterprises to access the Hydrogen technology platform, which currently consists of products like Atom, Ion, and Hydro. Developers pay a per-user fee to hit our core APIs, while large enterprises negotiate custom (usually multi-year) contracts with us that typically include recurring revenue. Hydro, specifically, is being offered for free right now, as we attempt to gain adoption. But it is important to note that Hydro is just one piece of our ecosystem. Q.2 (Joleen):
When you say fee - is this fee HYDRO? And when do you envisage HYDRO to no longer be offered FOC? A
**.2 (Shane):** Sorry if it wasn't clear, I meant free to use our Hydro tech/APIs. The usage of HYDRO tokens within that is a separate issue - they still need to have HYDRO and we do not give it away for free to clients
— Q (guacam0le):
Adoption of an identity management solution (etc) would potentially involve a lot of identities. Further, scalability is a hot topic w/ blockchain. Is this a potential bottleneck? What is or might be done to address such?
Tackling a competitor like Google or Authy's 2FA is no small feat. Also, not everyone is yet to embrace blockchain-based solutions. Have you found it difficult to interface with enterprises & get them excited about the idea of an overhaul? A (Anurag):
nowflake is designed to be relatively low-load on the blockchain. A user needs to conduct a single transaction to “mint” their Snowflake. Once this is complete, they would need to complete one-time transactions to set each of their different forms of identities as resolvers as needed. A Snowflake is designed to be built out via resolvers over the duration of a user’s lifetime, so there’s never a need for heavy, frequent transactional capability. Similarly, smart contracts simply need to be set as resolvers by users; they do not themselves transact. Network scalability improvements will increase the range of use-cases for smart contracts that can be tied to Snowflake, but they aren’t a necessary prerequisite to some important early use-cases such as KYC platforms, and a few basic user-interaction platforms.
As far as competition, we feel that current adoption of 2FA is, in general far short of where it should be, and any 2FA is generally better than none. Many businesses use text-message based 2FA, etc. In the short-run we are aiming toward pilot implementations with small businesses. To further this, we have put out many integration resources, guides, and documentation and accordingly believe implementation of Raindrop is a more straightforward workflow. As far as large enterprises go, Hydrogen has clients, so it is helpful for our project to have those connections. Large institutions are generally relatively slow-moving, but have expressed interest in using Raindrop, in particular for securing employee accounts. As the product grows, we may eventually move in this direction with Client Raindrop, but resources will always be available for any site that wants to adopt it. Additionally, we are looking into making a wordpress plug-in to make implementation much more accessible for many developers.
-- Q (Smithymethods):
I know Hydro is a fintech company, hydro plan to curb phishing and hacking to the bearest minimum we know that hacking is very rampant these days on MEW and with other wallet. Is Hydro planning to create a wallet that support hydro and other tokens using their raindrop Technology?
As this will put an end to the problem of phishing and also promote hydro A (Noah):
like everyone in the crypto space, we’re very worried about phishing, both personally and on behalf of all hydro token holders. we first want to reemphasize that preventing scams and fraud has to be a community-driven effort: teams and users need to be vigilant and promote best practices (never trusting links in public chats, shunning fake accounts, etc.). we are excited about raindrop’s potential to help combat phishing, though. we actually talked with someone about mycrypto about integrating raindrop into their desktop app. we’ve forked their code and are researching how feasible an implementation would be, stay tuned for updates!
— Q (Hodlall):
What security measures in place for hydro , I see lot of tokens being hacked nowadays , and money is stolen.. how does hydro make sure their team tokens are completely secured or as much as possible A (Andy):
We all have been in crypto for a while and are pretty well versed in securing our stuff. Our tokens that are currently locked are in cold storage. Others are held in hardware wallets
— Q (Joleen):
We know that the Hydrogen platform is going to be used by CI Investments, a large insurance firm and a world top 20 bank, have these companies already begun purchasing Hydro OTC? A (Andy):
This is something that we feel is best to be hands off with. It is really up to the discretion of our partners
— Q (khonsu’s mumaffi):
Ill be honest i have not yet fully read the whitepaper but id like to know other than investor growth do you truly believe there is interest in a model where users have to pay each time for access? How big do u expect this fee to be...for large companies dont you believe this is an unscalable practice? This may be a question more about most technologies built on token based economics too. A (Andy):
So we have 2 different authentication protocols. One happens less often and is in the same vein as OAuth. This is called Server-Side Raindrop. This requires tokens to be sent. This protocol would only happen once per day for a business when accessing something like an API. I don't feel that these values are extremely high for increased security.
Our second protocol, Client-Side Raindrop, functions much more like google auth. This logic actually does not require any tokens or even a transaction by the end user. It is 100% free for them to use and they will never have to pay for a transaction. Here the responsibility is on the implementing party to stake tokens. This allows them to onboard users and authenticate them.
We felt it was crucial to have an authentication that did not have a cost per user login as it is not scalable
— Q (khonsu’s mumaffi):
Also do u plan to tokenise atom and ion too and if not covered earlier how big of an impact do the market conditions have on your business A (Anurag):
Tough to say we're going to "tokenize" them since that word can carry a lot of different meanings in different contexts, but we do plan on integrating the entire Hydrogen platform with Hydro. This will most likely take the form of enhancements to systems leveraging Hydro. You can find a more detailed breakdown on our Hydro roadmap: https://medium.com/hydrogen-api/project-hydro-features-in-depth-look-39faa29f0d61
Market conditions don't really have an impact - we're still building the same tech on a day-to-day basis
— Q (ghost):
As a company in the space, do you see the fact that tokens have to be acquired on exchanges as an issue? How would a company that wants to develop with you acquire tokens? A (Anurag):
Depends on what they're developing. dApps developing using Hydro smart contracts to create native functionality to their applications would need to acquire those tokens on their own; however, companies using the Hydrogen API will not. Here's a detailed article outlining when a developer would need the token for the Client Raindrop smart contract: https://medium.com/hydrogen-api/how-to-use-client-raindrop-without-using-the-hydrogen-api-bb04934ae293
— Q (jarederaj):
Can you describe your stakeholders and give me a better sense of the exigency of your products? Who are you focused on serving with your platform and why are they motivated to use your platform? A (Shane):
The Hydrogen platform serves developers and enterprises who want to build applications. We are specifically targeting the financial services sector, including banks, investing firms, insurance providers, and financial advisors. This includes large enterprises, individual developers, and startups.
Our products are Atom (core digital infrastructure & engine for finserv), Ion (AutoML & business intelligence capabilities), and Hydro (blockchain & decentralization layer). Each has a different use case but these products combine to form an ecosystem of tools for developers to build sophisticated applications with.
The main pain point we are addressing is the resources required to build, launch, and run a digital financial application. These resources include both time and money.
Large enterprises have resources, but they waste years and millions of dollars trying to launch digital platforms (we've seen this first-hand), often unsuccessfully. The motivation here is obvious. Startups and smaller developers, on the other hand, do not have access to huge resource pools, so they are forced to look for solutions that make the process more efficient.
In the same way that Wordpress makes launching a blog easy and also allows for extended functionality, Hydrogen makes launching fintech application easy.
— Q (shujjishah):
When the app will be released??? A (Anurag):
We're going through our mobile development very iteratively. Since we work very closely with the product, there are things we can't recognize until we've got people beta testing the app. As we started Beta testing and conducting user-research, we realized that one aspect of the UI for the app was not intuitive to about half of our testers. We decided to make a few API changes to enable the mobile app to display a "linked" vs "unlinked" status in order to improve the user experience. Our front-end team is finalizing these changes, so our Beta testers will receive a new build in their testflight apps within the next few days. This new build will require another round of Beta testing to ensure that none of the code changes causes any problems on devices; if this change goes smoothly, and our mainnet testing goes smoothly, we will be able to release the app this month.
Since there isn't much precedent on releasing a product into the app store that connects users with the ethereum mainnet, our primary concern is making sure the product works fully as intended and provides an intuitive user experience. Misc Q&A’s Q (elmer_FUD):
What's your favorite thing to drink? A.1 (Andy):
Overall, I really love Baja Blast Mountain Dew. If I am drinking, I'm a big fan of fruity beers like Blue Moon and Shocktop. Also had a really good raspberry sour recently A.2 (Nahom):
Primary=water but i do enjoy Jamaican ginger ale/beer. We keep honest tea in the office too, i love it because it brings me back from the dead:skull_and_crossbones:, @Hydro Andy drinks most of it behind my back though :triumph: A.3 (Noah):
hard: tequila or picklebacks
soft: any sour beer
other: mango juice
i also crush like 2 nalgene’s worth of water every day at work A.4 (Shane):
For hard alcohol: whiskey/bourbon A.5 (Anurag):
ooh, went to the finback brewery last weekend; was wonderful
— Q (Joleen):
Do you HODL any other tokens personally? A.1 (Andy):
I do. I think it is probably best to not say which, but if you follow me enough in #altcoins I am sure you will see me talk about a few A.2 (Noah):
im a bit of an eth maximalist actually :grimacing: i do dabble though
— Q (Joleen):
Who got who in the World Cup sweepstakes? A.1 (Andy):
I'm going for Germany, but I know next to nothing about soccer A.2 (Shane):
I'm rooting for Portugal, but I don't think they're going to win the cup
— Q (Joleen):
Who's got the best banter in the office? And who has the worst? A.1 (Andy):
One of our backend devs, Paavan, typically has some great banter
and even better hot takes A.2 (Noah):
dont @ me for worst banter A.3 (Shane):
Sabih (BA @ Hydrogen) banter is by far the best
Bitcoin: Liechtenstein bringt als erste Land in Europa Gesetz auf den Weg. Erst kürzlich gab Binance, eine der größten Krypto-Börsen der Welt, bekannt, dass Hacker Bitcoins im Wert von umgerechnet 36 Millionen Euro gestohlen haben. Binance kündigte aber auch an, dass Nutzer dadurch keinen Schaden erleiden werden, sondern die Börse allein für den Schaden aufkommen werde. Die Technik war ... Binance users can now buy Bitcoin with practically all of the fiat currencies in existence; Binance, which is one of the leading cryptocurrency exchanges in the world, has partnered with the peer-to-peer crypto exchange Paxful. Via this partnership, Binance users can now use 167 different fiat currencies to buy Bitcoin. Trade over 40 cryptocurrencies and enjoy the lowest trading fees in America. This web public API was created by Binance. The Binance API endpoint is located at wss://stream.binance.com. You can find the Binance portal / hompage here.If you need Binance API support, you can contact support directly at [email protected], or reach out to their Twitter account at @binance_2017.For more information, check out their API Documentation. Binance is a paradigm of a successful, secure and reliable cryptocurrency exchange platform. Traders use Binance to perform a multitude of trading operations such as buying cryptocurrency, trading cryptocurrency and more. The platform harbors millions of users who exchange coins like Bitcoin, Litecoin, Ethereum and more. Binance Users Can Now Pay for Crypto With Credit Cards. Binance, the world's largest cryptocurrency exchange by adjusted trading volume, has just made it easier for users to buy cryptocurrencies. At launch, the exchange is supporting credit card purchase for bitcoin (BTC), ether (ETH), litecoin (LTC) and XRP. Der Zahlungsbetrag und Bitcoin-Adresse können auch als ein QR-Code angezeigt werden, die Sie mit einer Bitcoin-Wallet auf einem mobilen Gerät scannen können. Andernfalls müssen Sie manuell die Adresse und den Betrag in Ihre Bitcoin-Wallet zur Zahlung kopieren. Seien Sie vorsichtig, wenn Sie dies tun: Achten Sie darauf, die Bitcoin-Adresse und die Menge an Bitcoins sind genau richtig vor ... Binance CEO Changpeng Zhao has apologized for causing concern among the crypto community when he openly spoke about the possibility of a rollback for the Bitcoin blockchain following confirmation of a hack leading to the theft of USD 40 million worth of bitcoins on its platform.. The rollback had caused a sharp backlash, particularly among Bitcoin-only communities, aghast at the very concept ... TradingView. Sign In. Ticker Trading Ideas Educational Ideas Scripts People Trading Ideas Educational Ideas Scripts People
How to transfer fund from Binance to coins.ph #Binance #CoinsPh Buy Bitcoin on: https://coincompass.com/binance https://coincompass.com/coinbase Should I buy bitcoin on Coinbase or Binance? A comprehensive, pragmatic & be... Bitcoin Trading Guide If You're Trading Indian Market Binance ***** More Info ***** Website Link: https://nextlevelbot.com/ Binance... How to make an Arizona penny can alcohol stove - Duration: 19:40. JIUJITSU2000 Recommended for you. 19:40. BINANCE - COMO COMPRAR E VENDER BITCOINS RODRIGO MIRANDA - Duration: 30:19 ... #Binance Futures - Trade Bitcoin, altcoins and more with up to 125x leverage. Category Entertainment; Show more Show less. Loading... Chat Replay is disabled for this Premiere. how to open Binance exchange to buy bitcoin #cryptotradingexchange #binance # howtoopen Binance link: https://www.binancezh.pro/en/register?ref=XW91KRSO buyi... How to Short Bitcoin on Binance 125X Leverage Binance Futures Tutorial - Duration: 13:32. Hardc0re Crypt0 13,592 views. 13:32. Bitcoin ( BTC ) resurgence is continuing to sap capital from the altcoin markets as other cryptocurrencies are struggling to catch up to BTC. The DeFi Compos... Außerdem sehen wir uns an warum der Bitcoin Future von Bakkt an Fahrt aufgenomme hat und welche 5 Börsen das größte Handelsvolumen umsetzen. Viel Spaß! Viel Spaß! Today we look at ChainLink, Enjin coin and VET for possible moves to the upside. we also explore the S and P 500 breakout and how it effects BTC, Altcoin sea...