With the aux-block technique, we could release CoinCovenants from limbo  Llike the stuff I was proposing in the covenants thread: it feels like it has a lot of danger to be used in powerfully stupid ways that hurt fungibility. |
|
|
|
And yes, pretty much any hardfork short of changing the monetary supply can be done with a softfork using this technique. And even that can be done if auxcoins aren't redeemable 1:1 with mainchain bitcoins. That is why I opted not to release this idea. This is extremely powerful and must be handled with care. I didn't realize it is so powerful when I first proposed it. Now I believe everything can be done with a softfork, except changing the format of block header and coinbase tx. I wonder if Satoshi was aware of this when he designed the protocol. Anyway, I have (unintentionally) opened the Pandora's box. This reminds us that a 51% attacker could do a lot more than we usually think. |
|
|
|
They already ARE subject to regulatory risk
Right, because Bitcoins present the same regulatory risk as dollars. In the US Bitcoin exchangers are money transmitters. WU is a money transmitter. WU is registered with FinCEN WU has a MT license in every state which requires one. WU has surety bonds in every state which requires one (by the regs it is in excess of $20M face value) WU has an AML program. WU has AML training for employees. WU has a BSA compliance/audit team. WU collects and records KYC information. WU blocks suspicious transactions. WU files various MT related transaction reports with FinCEN. WU keeps transaction records as required by FinCEN and state regulators. WU implements per tx and per day limits for customers in accordance with FinCEN and State MT programs. WU has the legal teams, the size, and the industry contacts to get direct answers from regulators. Per FinCEN guidance WU is ALREADY doing everything they need to be a 100% compliant Bitcoin exchanger. So yeah if there is ANYONE on the planet which has the compliance structure already in place it would be WU. Still they aren't going to support Bitcoin until it is "game over" for the business model. If/when Bitcoin is is so pervasive that they are losing revenue, they will consider offering bitcoin exchange services not before. I think ButterCoin is trying to run the WU model. They will work with local licensed money transmitter to avoid all those compliance issues. |
|
|
|
It's just a transaction. You can't really tell its purpose |
|
|
|
And by your logic, these companies can't make any money because the problems they solve don't exist.
I think no one is saying that these problems don't exist. WU is already dealing with the risk of currency volatility, so this is nothing new to them. They can also use Winkelvoss ETF to hedge the risk. Where do they get the Bitcoins from? From bitcoin sellers. If that's not enough, buying from gox. What do they do with the Bitcoins they receive? Send to bitcoin buyers. If they hold too much, sell at gox. |
|
|
|
|
I think Western Union could bring bitcoin to everywhere in the world without any infrastructural change.
Users who want to buy bitcoin could pay at a WU outlet with an agreed exchange rate. They will fill-in a remittance form to indicate the recipient country as "Bitcoin" and the recipient address as a bitcoin address. The request will be forwarded to the WU headquarter, which will send the bitcoin to the destination.
Users who want to sell bitcoin will send bitcoin with the WU website, and collect fiat at the preferred WU outlet.
Since the outlets woun't touch bitcoin at all, basically they could bring bitcoin to everywhere in the world without upgrading any outlet. They just need to allow a new dummy country code called "Bitcoin", and allow a weird address as the recipient.
Thoughts?
|
|
|
|
In my opinion, before going further, we must request the opinion of security experts.
I am not an expert, but introducing a new relation in the set of the DSA equations is just a weakening of the security.
There is nothing related to DSA. just an alternative way to present binary data |
|
|
|
|
If that is really banking issues, why don't they use Western Union? I believe WU fee is much lower than 5%
|
|
|
|
I second this inquiry. I'm currently on the fence here on whether I should go for this method in a HW wallet prototype I'm working on.
I think the major task is to make a good word list. Coding is simple. |
|
|
|
虽然我也被796的股票坑过一次, 割掉了我好几个B(IPO的价格真有点坑)
上市前我就講過市盈率不合理 |
|
|
|
|
It seems there is not much discussion on BIP39 recently. Is there any progress? I wonder if we could extend it to non-English language to lower the barrier for more people.
|
|
|
|
|
如何證實代理身份? (騙子太多, 請勿見怪)
如果只買一張, 可以固定在atx機箱嗎?
|
|
|
|
|
Just problem of blockchain.info: use advanced mode and you will see what happened
|
|
|
|
下一步，796是否开展比特币买卖，还有香港银行卡冲值与提现业务？
对这块业务会有考虑，具体我们要等待香港方面律师确认具体业务范围 又开始忽悠了，你的主营业务在大陆，应该遵守大陆法律，香港方面律师确认只是确认你在香港开展相关业务。 796是純bitcoin服務, 請問你如何界定主營業務地點? |
|
|
|
用这牌照能进行比特币/法币的交易吗？
應該是的.  |
|
|
|
One of the advantages of the RIPEMD160 hash is that single use addresses are protected against an ECDSA break.
The hash function and the ECDSA would have to be broken at the same time for those coins to be stolen.
As long as they don't try to spend their coins once the ECDSA algorithm is broken, attackers can't access the coins, since they don't know the public key.
However, with deterministic wallets, this is not the case.
If an attacker obtains the root public key and the chaincode, then they can generate all private keys (assuming an ECDSA break). Even a weaker break, where they obtain 1 private keys gets the attacker all later keys in the chain.
It looks like the BIP_32 proposal has 2 chains for each "wallet", an internal and external one. Is this intended as some kind of protection against that?
One option would be to sweep all funds to alternative addresses whenever you spend anything. Inherently, that requires accessing the cold storage anyway.
It would be nice if there was a way to get the double protection of standard addresses. The core problem is that if the online computer can generate all the public keys, then an ECDSA break exposes all private keys.
Actually I think it is more secure to use a hash function instead of ECDSA to derive the private keys. In this case, however, the watch-only wallet won't be able to generate new addresses. |
|
|
|
按本月实际每股应分配红利0.0005366141007，计算0.12的发行价，将近27倍的市盈率啊，呵呵，居然还有人认为股价不高？
btc公司通常的市盈率2倍不错了吧，按此按计算，股价为0.012比较合理，呵呵，发行价的十分之一~~~~
0.12/(0.0005366141007*12) = 18.64 |
|
|
|
|
If we could not stop people from abusing the blockchain as timestamp service, we could do it in a centralized way to minimize the harm.
Here I assume zero value OP_RETURN outputs are standard, and transaction replacement with higher fee is relayed
One can establish a timestamp service, which collect hashes from users, calculate the merkle root, and send it to bitcoin network as a zero value "<merkle root> OP_RETURN" output. The service will collect fee from users, which part of this will pay miner. If new hashes arrived before confirmation, the timestamp transaction is replaced by paying higher fee.
When the timestamp transaction is confirmed, the service will either publish the full list of hashes through his webpage, or allow user to inquire the path of his hash to the merkle root. The latter option provides better confidentiality but requires more resources.
My only concern is such service would not be profitable due to tragedy of the commons. If this model is successful, other people will provide the same service. Instead of sending the merkle root to the blockchain directly, they could exploit another operator by pretending a normal user and requesting him to timestamp the merkle root, with a very low cost. Everyone will fail eventually.
|
|
|
|
This will allow any previous owners to DoS the latest owner by forcing him to redeem the coin on the blockchain.
Hm? You'd still have to provide a transcript that shows the coin being directed back to bitcoin via sending it to a special destination. You provide such a transcript to redeem the coin. Someone else can provide a conflicting transcript but only if its of a longer conflicting chain. So you can dos, but only if you're also reorganizing the secondary chain (or at least producing more POW than that chain). Sorry for the confusion. This comment is referring to the timeout mechanism for oracle-based system. |
|
|
|
|
Show Posts
