dekz

Perhaps a good starting point is spending a few minutes investigating how bitcoin works, perhaps with ChatGPT as a resource. You should attempt to understand it before forming an opinion and asking leading questions.

Bitcoin uses a UTXO model, a recipient address is specified for the remaining funds that are not intended to be spent. Similar to how you pay for a $20 item with a $50 note, you (recipient) receive $30 in change.

If Tether untethers there will be a rush to other assets, pushing them higher.

Shorts denominated in USDT will get absolutely decimated, pushing other assets higher.

Exchanges using Tether will enforce a maximum withdrawal, pushing other assets higher.

Smart money will buy USDT at a discount once their reserve details are made publicly available. If it's FUD they'll make an absolute killing.

There's 3 possibilities here: 1. Tether is completely backed 1:$1 (highly unlikely) 2. Tether is partially backed, the reserves are greater than the outstanding 3. Tether is partially backed, the reserves are less than outstanding

Only 3) will have a downward price correction. If they've been buying BTC like everyone here has suggested then 2) is the most probable, since you know BTC is at yet another ATH.

If it becomes public that tether has excess reserves, the FUD will disappear silently. Worst case Tether says they will slowly sell off to reach 1:$1 over the next 12 months.

Can't reply to OP but the RSA company setting ECDRBG as a "default" is not related to RSA the algorithm.

It's pretty clear when you validate the transactions

> /* start: pseudo test code */

run https://github.com/iancoleman/bip39 on an airgapped laptop

Your embedded video links to a random Vimeo Staff Pick

Countries affected by this are: Canada and Australia. [1]

1: https://support.coinbase.com/customer/en/portal/articles/288...

We have a FAQ[1] which is being fleshed out but take a look if it helps.

We are 100% non-rent seeking.

In Ethdex we incentivise Trading platforms by allowing fees to be charged in Eth, the natural currency of Ethereum. Not by creating a token and forcing its utility (ala ZRX and 0x).

We also support Multi-Relay, which is something 0x does not support. As a maker you can submit your order to every trading platform, every slack channel and every subreddit. Other platforms cannot do this.

We also don't have any obligations to VC's to ensure they make profit.

[1]: http://ethdex.io/faq

We are working on a platform for exchanging Ethereum (ERC20 tokens) at Ethdex. Exchange happens atomically and on chain. No counter party risk, unlike exchanges such as Bittrex. We aren't rent-seeking or forcing you to use a token.

http://ethdex.io

https://github.com/Ethdex/contracts

Each chain/dapp/offering usually has its own slack or discord.

coinfund.io/steemit.com

Ethereum had multiple Proof of Concepts before their ICO.

That's 86.5% miners signalling to signal support. Segwit2x is still yet to have a working and tested implementation.

Would you support something which has not been fundamentally tested?

It's because its a thin layer ontop of a Coinbase Referral (Coinbase only has BTC/ETH/LTC)

Interestingly enough, it is launching when BIP148 activates for Bitcoin.

Is this much different to nativefier? [1] I made previous use of this by wrapping different AWS console logins (personal, work, prod) so I could be logged into multiple at once.

[1]: https://github.com/jiahaog/nativefier

.env or ENV with AWS KMS

What was your use case where you needed pgdata in both the HOST and a container (or multiple)?

The comment you are replying to mentions once the docker image is built, referring to the built layers. These are guaranteed to be identical.

Building from scratch, is not always guaranteed to be identical.

How do you come to the conclusion that the entirety of Samsung don't understand or respect software, when they clearly show great contributions to OSS? [0].

[0]: http://linuxcontrib-inn.rhcloud.com/

That is great. What about services which convox doesn't support (yet)?

For example SNS. Would convox ever support terraform/cloudformation for an App, or would you add SQS service in convox, then create SNS outside of convox, and then join them together somewhere else?

How do you feel Convox deals with the Hybrid approach? Of wanting to use a PaaS App container service, but keep the app dependencies like Cache, ElasticSearch DB hosted by AWS.

Does Convox continue to use hosted AWS services?

I like the idea of the App being containerised and that workflow, but I cannot convince myself that running DB/Cache in something like Convox is a good idea (vs Hosted in AWS).

Can you give your thoughts?

It can still get tested and smoke tested before deploying directly to production. If you cant trust your automated tests and smoke tests then you're setting yourself up to fail.

I think Empire or Convox will be the right tool for us.

Flynn and Deis etc all seem to be writing their own schedulers and routing layer, where Convox and Empire just reuse AWS components. This to me is a huge plus, since those problems are already solved and rock solid.

But as a developer, I just want to push a docker image some where and scale it up later.

The context of the tweet seems to be about Rubinius' versioning, to me, it is crazy. Not knowing if your prod 2.10 is the same as your local development 2.10, absolutely bonkers.

  > In Rubinius, a "version" is a label on a git commit. To find exactly which commit (uniquely identified by its SHA) the version labels, you deference the corresponding git tag. [1]

Rubinius is so unwavering about their versioning process that they have asked to be removed from dev tools like rbenv and chruby. [2]

@brixen then offers conflicting statements on where he stands with regards to this:

Advocating removal:

  > Honestly, given the amount of time I've wasted with rbenv, RVM, and chruby bugs and insisting on telling me how Rubinius should build and package, it would be better if none of them installed Rubinius. [3]

Denying removal:

  > I didn't request that Rubinius be removed; that's @sstephenson's revisionism... [4]

[1]: https://github.com/rbenv/ruby-build/pull/860#issuecomment-16...

[2]: https://github.com/rbenv/ruby-build/issues/862#issuecomment-...

[3]: https://github.com/rbenv/ruby-build/pull/860#issuecomment-16...

[4]: https://github.com/rbenv/ruby-build/issues/862#issuecomment-...

  > Of course, choosing to build a system with a fundamental flaw in it is something they are perfectly free to do

What is displaying your "tabs" at the bottom of your terminal?

That is fantastic news!

Unfortunately kong still has a hard dependency on Cassandra.

https://github.com/Mashape/kong/issues/331

Wrap Feature B in a feature toggle if its development ready but not business ready. Then when it is business ready, flip that toggle.