The question being asked here is why Bitcoin has no equivalent of an nlocktime which prevents a transaction from being confirmed after a particular time (instead of just the before direction), after a reorg such transactions may be unresurrectable even though there is no conflict, because the time has passed, because their wasn't enough room in the boundary block, etc.

It isn't the same thing at all, as it can cause irrecoverable loss even completely absent any misconduct on any party (and, in particular, any party involved in the transaction). It changes the loss criteria from if and only if there is a reorg and a conflicting spend and the conflicting spend wins in the reorg, to just if and only if there is a reorg.

Only if you're Tron and living inside the ENCOM blockchain. The rest of us users actually witness the reorg and may have potentially taken irreversible actions based on the prior state.

Please search the forum. This has been answered previously: https://bitcointalk.org/index.php?topic=380482.msg4083612#msg4083612

The answer there would appear to be that they expect significantly greater power efficiency.  Normally I would recommend extreme caution: Getting power estimates vastly off appears to be par for mining hardware companies— but in this case they apparently have a first chip in operation.

Interesting emails today:

The hashfast customers from the G-J section of the alphabet in the email leak have been chatting amongst themselves. It's a whole additional community with many people who haven't received their hardware and whom HF has cut communications with... many of whom were unaware of how widespread the issues were.

In the middle of all that someone posted:


To which a bunch of people responded along the lines of WTF WHY ARE YOU GETTING CHIPS WHEN I'M STILL WAITING!?

to which he replied

http://sourceforge.net/p/bitcoin/mailman/message/31306213/

I expect we'll make that change in Bitcoin-QT as a part of the change to libsecp256k1... though the most recent versions of openssl use something like H(message||private||rng_output) as the nonce, so even in the case of RNG failure you don't get a DSA leak.

It's also the case that OpenSSL uses its own internal randomness pool seeded initially from the OS. There isn't any particular reason that you couldn't send your dice input into that, though the seeding interface isn't exposed in Bitcoin currently, though perhaps it should be.

The double spend requires fraudulent (or at least gravely mistaken!) actions on the part of the users. The expiry just happens as a product of chance or due to actions by totally unrelated third parties. We've had some long reorgs during network events in the past which resulted in no losses, expirations would effectively guarantee losses in these cases and in general complicate the security analysis in accepting a transaction because now you not only need to worry about past fraud risk, you need to worry about past expiration exposure.

This fellow is spamming up a bunch of threads in the mining hardware subform with complaints about Israel. His posts have been some of the more diversely and heavily report-to-moded posts in recent memory. I've asked him to stop a number of times and he indicates that the only way to get him to stop will be to ban him, I think that would be unfortunate. His response has been to ask me how much bribe blood money I've been paid ... to prohibit his offtopic posting. :-/.

Sorry for the brief off-topic comment,

There is a forum user who is really upset that this is a product being sold by an Israeli company due to his complaints he has about the activities of the government there. This poster keeps making post after post in this thread and others. I've been trying to convince him to keep his complaints in the appropriate subforums, and have been moving or deleting posts that he makes in inappropriate places. It would be helpful everyone could avoid responding to him if he posts here again since it just makes for more posts I need to delete.

Eight hours after the original post and not a single thing of substance has been said, just more FUD and whining like the prior incidents with this poster. Soon I suppose we'll see requests for payment.

Since he's asking for signmessages in particular, let me guess that if we get anything at all it'll be repetitions of the same signature and different messages with different public keys, which is exactly how it's supposed to work (every validly encoded signature is valid, which is why bitcoind's veryify message functionality forces you to provide the expected address.)

E.g.

verifymessage '1NskFs6D7NYP9rpnaAVAdz7NhLLNkSjf1J 'Gyk26Le4ER0EUvZiFGUCXhJKWVEoTtQNU449puYZPaiUmYyrcozt2LuAMgLvnEgpoF6cw8ob9Mj/CjP9ATydO1k=' '1'

verifymessage '17aiPTrsQtAHpRFvzxGoYiZ1m63ujDX43K' 'Gyk26Le4ER0EUvZiFGUCXhJKWVEoTtQNU449puYZPaiUmYyrcozt2LuAMgLvnEgpoF6cw8ob9Mj/CjP9ATydO1k=' '2'

verifymessage '1AY1MXXY6aPHW1Raj9QVjJprMo8BewMdB9' 'Gyk26Le4ER0EUvZiFGUCXhJKWVEoTtQNU449puYZPaiUmYyrcozt2LuAMgLvnEgpoF6cw8ob9Mj/CjP9ATydO1k=' '3'
Which is just a property of public key recovery and isn't interesting or related to Bitcoin transactions. Every possible signature,message pair is valid for some public-key.

You got a negative trust rating because you've hyped bogus and deceptive security claims multiple times and tried to charge people for exploit tools that didn't. But hey, you could still collect on that 50 BTC bounty I offered you for your last set of claims, and I'll even remove the negative trust to boot.

You mean outright fraudulent alarms. You note even here he says "probably".

I call bullshit.  Real cryptanalysis is specific.

FWIW, for those curious— the thread on the encryption issues: http://sourceforge.net/p/bitcoin/mailman/message/32107008/   (I made several posts after the first one too)

Outright enforced expiration is not reorganization safe and can cause coins and their history to be suddenly invalidated even in the complete absence of an attacker. This exposure different for coins based on their depth would degrade the fungability of the coins, and avoiding it is one of the reason that generated coins cannot be spent for 100 blocks.

There is, however, some work going on towards allowing single transaction refunds that would allow you to easily spend a coin to an alternative output in order to cancel it after some time has passed.  This addresses some but not all of the use-cases for expiration (as well as many other use cases) without the risks. I should have a proposal on the mailing list in a few days— I'm still hammering out the details of exactly what I'll be proposing with a few other people first.

If Hashfast fails to deliver, as they're currently doing for may customers— including yourself, I believe— how will you make your buyers whole? You should also be aware that there are people currently suing hashfast and this may result in making it harder for them to deliver. You should also be aware that HF has a history of unilaterally changing terms and claiming that not adopting their new terms voids all their obligations.

Does your "Caveat Emptor" mean that if Hashfast does not deliver you will do nothing?

Beyond my basic moral reservations with giving more funds to a company who is currently ripping so many people off— I suggest that instead of just collecting funds from people and give them to the black hole of fraudulent behavior that is hasfast you collect funds into escrow (e.g. with bitrated.com) and only pay hashfast on delivery.

Works fine here:


[gmaxwell@helmholtz tmp]$ bitcoin-cli listlockunspent
[
]
[gmaxwell@helmholtz tmp]$ bitcoin-cli lockunspent false '[{"txid":"76a914a86e8ee2a05a44613904e18132e49b2448adc4e688ac","vout":0}]'
true
[gmaxwell@helmholtz tmp]$ bitcoin-cli listlockunspent
[
    {
        "txid" : "0000000000000076a914a86e8ee2a05a44613904e18132e49b2448adc4e688ac",
        "vout" : 0
    }
]
[gmaxwell@helmholtz tmp]$ bitcoin-cli lockunspent true '[{"txid":"76a914a86e8ee2a05a44613904e18132e49b2448adc4e688ac","vout":0}]'
true
[gmaxwell@helmholtz tmp]$ bitcoin-cli listlockunspent
[
]
[gmaxwell@helmholtz tmp]$

An address is just a human friendly way to encode a template for a scriptPubKey. Transactions do not contain an address for each of their outputs, however, just the resulting scriptPubKey. There is no guarantee that you can reverse the operation for all transactions.

Whoptie do, blocks are expectation 20 minutes for a month.

Difficulty being hesitant to change improves security against isolation and decreases the amount pumping of difficulty by variance.

The missing points are on an alternative curve (the quadratic twist) and have a discrete log (a private key). For some curves used for cryptography the twist is not cryptographically strong— meaning the discrete log is 'easily solved' there— though ours is acceptably strong. It's still important that any verifier check the that the pubkey is on the curve (and especially important for anything doing ECDH).

It's arguably that bc.i should display something more useful there... but at the end of the day the key point remains that the bitcoin system itself doesn't have addresses— addresses are a wallet layer construct and any attempt at mapping back from the chain to addresses is going to have some limitations.