Square obtains NY State cryptocurrency license
reuters.com
reuters.com
https://techcrunch.com/2017/11/14/square-cash-is-letting-som...
https://techcrunch.com/2018/01/31/square-cash-expands-bitcoi...
[1] https://www.ccn.com/i-hope-bitcoin-will-be-internets-native-...
I understand that the original goal was to have the value of the currency to be not controlled by a central bank.
Is there any other benefit to it? What does it mean that the currency needs to be "programmable" in this context?
See https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abst...
OP_IF
<Alice’s pubkey> OP_Checksig
OP_ELSE
“3 months” OP_CSV OP_DROP
<Heir’s pubkey> OP_Checksig
OP_ENDIF
Would you say that you need expensive programmers to audit/create an escrow contract on Bitcoin? Multisig contracts are simple, battletested and deployed in the blockchain.Given the number of high-profile smart-contract hacks we've seen, yes, you do need expensive programmers. (At least, to a greater extent than you need expensive lawyers. It's perfectly possible to write your own will without a lawyer, and frankly I'd have a lot more confidence in that than in my own smart contract, even as a programmer).
There have been no hacks of bitcoin multisig addresses. The hacks you're referring to are on ethereum because ethereum is a dumpster fire with a marketing team trying to con people into believing all number of unpractical solutions.
I think Bitcoin might be useful for storing and holding wealth, whereas Ethereum is much more active protocol, for active communication and interaction
Solidity et al are imperative languages which basically turn the never static ethereum blockchain into an absolute nightmare to reason about or write robust code for. See basically the once weekly massive security bugs in ethereum contracts. Turning completeness and imperative languages; I would not call that robust on the code execution level.
Ethereum is also not immutable, see DAO bailout. I would not call that robust.
Ethereum has architected their consensus choices such that miners can increase blocksize to push out competitors. That leads to coercion centralization. I wouldn’t call that robust. Even if we live in a future utopia where coercion isn’t a threat, then The system is a horribly inefficient AWS.
https://en.wikipedia.org/wiki/BitLicense
(I was only aware of the one that I knew Coinbase held.)
[1] https://en.wikipedia.org/w/index.php?title=BitLicense&action...
> With the Square approval, DFS has now approved nine firms for virtual currency charters or licenses, while denying those applications that did not meet DFS’s standards. DFS has also granted licenses to Xapo, Inc., Genesis Global Trading Inc., bitFlyer USA, Coinbase Inc., XRP II and Circle Internet Financial, and charters to Gemini Trust Company and Paxos (formerly itBit Trust Company).
from the Wiki citation [21]
https://www.dfs.ny.gov/about/press/pr1806181.htm
looks like two are charters, not sure how that's different than a full BitLicense.
https://www.dfs.ny.gov/legal/regulations/bitlicense_reg_fram...
Centralized exchanges are not really my thing, but legal compliance is pretty alright by me, and NY is a notoriously difficult regulatory climate. When I heard that Coinbase might be sending my information to the IRS, it was actually a relief.
(Given: I have managed to make not very much on crypto for someone who has been involved in the ecosystem for a while.)
news at 11
Given the state of the technology today, taking advantage of these cost savings in the most network-aligned way requires massive liquidity. Square creating a liquidity solution helps them and grants their customers something they want.
I see this mainly as a service they wish to provide to a segment of their customer. I also expect it to be a loss leader and shut down over time.
These escrow products already exist for customers on Bitcoin.
> Transactions that are computationally impractical to reverse would protect sellers from fraud.
Transaction fee on bitcoin presently is an average of 60c [1]. Visa is around 2% + 0.10. Thus for transfers over about 25 USD, bitcoin (presently) is cheaper. And that's not considering terminal fees, payment gateway fees, annual fees, monthly fees, early termination fees, statement fees and so on.
[1] https://bitinfocharts.com/comparison/bitcoin-transactionfees...
> Square creating a liquidity solution
How is putting transactions across the blockchain instead of ACH or Swift "more liquid"? I mean, I suppose if you want to evade taxes maybe, but I'm not clear how that actually helps the payment processor. Square doesn't benefit from "liquidity".
I've a system that has for years swapped NACHA files with a major bank for hundreds of thousands of accounts each day, and without fail it has worked 100% of the time! Guess what we use? SFTP whitelisted to specific IPs. A fixed width GPG encrypted file. That's it.
Can't say the same for most of these rubbish REST of an APIs out there that I've had to suffer through.
Some 70s technologies btw are great. There's nothing wrong with a well defined fixed width file with checksums. I wish all data files were those or CSVs.
Which is not part of the ACH spec... though I agree it is a good implementation
In other parts of the world you can transfer between accounts in almost real time, nobody uses checks anymore for rents or interpersonal transfers or intercompany money transfers.
Meanwhile the US still uses checks. ACH is jurassic.
Real-time transfers under $5,000 are free between most American banks. For real-time irreversible transfers up to any amount, the Fedwire system is available. Most banks let large account holders send and receive domestic wires for free. ACH is used for low-cost, gross-settled transfers--it is the cheap, reversible option.
This myth of slow, expensive bank transfers dies slowly.
This great visualization[1] showed up on my feed yesterday, you can see that most of the BTC transactions' fees are being measured in single-digit USD cents again. It compares BTC to BCH, and you have to wait a while to see what's happening, but I think it's a fairly unbiased and basically informative view of how the two on-chain transaction scaling strategies actually work.
(Spoiler: the number of BTC transactions is still massively outpacing the number of BCH transactions, in case you didn't guess that.)
[1]: https://bitcoinsubway.cash/
[edit: http_s_]
https://bitinfocharts.com/comparison/bitcoin-transactionfees...
At the present time, a transaction can be reasonably assured to be mined in the next 1-6 blocks by adding a fee of $0.20 for next block (or down to $0.10 for within ~6 blocks.)
This is not the only fee you pay when buying and selling, but it can be... exchanges like GDAX permit you to pay a fee to place a market order (buy/sell from the current limit ceiling or floor), or pay no fee to place a limit order (wait for the market price to cross your own preferred price), and those different kinds of exchanges will all have different fee structures, but most markets supporting limit orders I think should not charge fees. This kind of buy/sell fee is basically always a percent, maybe with a flat fee floor (eg. $1 min fee.)
The market order fee is really probably pretty insignificant unless you're actively trading all the time, in which case you'll definitely want to avoid paying them. On Coinbase, for example, you only buy and sell at the market price with a roughly percent-based fee structure, and the fees are low.
Ostensibly you can understand what's changed to be that, now that there are no-fee options available for high-volume traders, all of the high-volume traders are using those options so there is more room on the chain for small-time simple consumers to pay a low fee and keep things simple, doing their transaction in the traditional way. I don't want to run a Lightning node, but I can still benefit from the existence of that protocol through lower fees, because it means there's simply a lot less traffic on the chain.
I don't have numbers to back any of these assertions up about how it happened, other than the actual links I provided regarding the average fee value paid... but all of this reasoning about 'how' is hypothetical and I'm probably wrong about something.