Yeah that is still wrong no matter how many times you repeat it.   There are plenty of entropy sources which don't involve time.  


If you are referring to entries like this:


They are not references to NTP.  It is comparisons of the local machine clock against the network median time.  It isn't used to seed the PRNG but to limit how far miners can drift the timestamps of blocks.

Should have good news to report regarding this by the end of the week.

It is somewhat surprising.  I would have imagined that the cold storage of major exchanges would be secured by m of n  P2SH scripts.  We know that none of them do that simply because the total value encumbered by all ScriptHashes & Raw scripts is <0.16% of all BTC.

Haven't had much free time to do more analysis of the blockchain but found an interesting test case in this tx:
https://blockchain.info/tx/5143cf232576ae53e8991ca389334563f14ea7a7c507a3e081fbef2538c84f6e

This tx has (or had as of the snapshot block) 3073 unspent outputs.  It is the largest tx when measured by the number of unspent outputs.

256 bit ECDSA keys only have 128 bit security.  Half of an ECDSA key would be 64 bit security.  While a naive attack would be to increment all possible private keys there are more sophisticated attacks ( https://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm_for_logarithms ) which are of complexity O( n^(1/2) ) steps where n is the key length.

64 bit security would be breakable but it is very likely the cost to break they key would be greater than the reward.  Although if this isn't a hypothetical I would recommend transferring the coins now.

There IS no such function.  The max length of the digest that can be signed is <256 bits (<32 ASCII characters).  This is a limitation of how ECDSA works.  As there is almost no use for signing a message directly with that limitation a hash is used instead.  So even in cases where the message IS less than 256 bits it is still customary to take a hash of the message and sign that rather than deal with this extreme edge case differently than all other messages >256 bits.  

It sounds like you are trying to use the wrong tool for the job.   The purpose of a digital SIGNATURE algorithm is to digitally SIGN not ENCRYPT messages.

The purpose of signing is not to hide the message it is to authenticate the message.  It sounds like you wish to have the message encrypted not signed.

There are encryption algorithms which work using ECC keys and curves but none of them are used by bitcoin.  The bitcoin protocol uses no encryption at all (although some client side encryption is used to protect private keys). 

Here is an example of a ECC based encryption protocol:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

No.  public key cryptography is particularly expensive so a hash of the message is always taken.    If the cryptographic hash is secure then it serves as a proxy for the actual message (which can be of arbitrary length) as one can't change the message without producing a different hash.   Since text messages are short you in theory could sign the message directly however this would be non-standard, it isn't just not supported by the bitcoin source code, it wouldn't be supported by any standard crypto library either.  The message would also need to be less than the n parameter of the curve which for secp256k1 is 256 bits or ~32 bytes (characters).  You could write custom code to implement this but it would be very proprietary, extremely limited, wouldn't be verifiable by any standard library, and I am not sure what you gain over just signing the hash of an arbitrary message.

If you can send a bank wire you can get bitcoins the same day (usually within an hour of when the funds clear) by using BitSimple ( https://bitsimple.com ).

Once again you are completely wrong.  Please stop stating as fact things that you incorrectly believe are true.  Take this from someone who has spent more than you make in a year on legal counsel. There is NO threshold for money transmission.  Note that in your incorrectly quoted section, money transmission is not included in the list for which a min amount applies.  The other categories are referenced by name but money transmission is not.  Did you not find that interesting?  Did you think FinCEN just forgot and happened to name 5 of the 6 categories but not left one out by accident?

What is interesting is you managed to quote the wrong portion of the text when the very next paragraph clearly shows you are wrong.   I guess by pure luck you just happened to not read past the portion you quoted because if you did you would have noticed your error.  Either you have very bad reading comprehension skills or you took a selective quote out of context to support an incorrect statement.  You do understand that someone relying on your false claims could face a felony conviction and potentially decades in prison.   Do you not believe you have an ethical obligation to ensure your statements are correct, property cited, and well researched before making them?

Here is the full content from FinCEN so others can judge for themselves:

Reference: http://www.fincen.gov/financial_institutions/msb/definitions/msb.html

Of course that segment is just provided as an overview.  The real regulations are found in 31 CFR 1010.100
http://www.ecfr.gov/cgi-bin/text-idx?SID=a56fa205f5db4227d1cc044b26575e09&node=31:3.1.6.1.2.1.3.1&rgn=div8
Note a lack of any threshold amount.

Please stop giving "advice".   There is no exempt amount for money transmitters and FinCEN has declared the minting of coins or the exchanging of virtual currency for "real" currency to be a money transmitter.   If you make a 1 satoshi coin it would be money transmission.   Of course you can try to fight it out in court but until you win your "advice" is negligent.

To the OP, the guidance from FinCEN isn't law but rather interpretation of existing law.  It has not been testing in court but understand through the guidance, FinCEN it showing you their gameplan.  Essentially they are saying we believe this activity is regulated because of x, y, and z.   If you engage in that activity and don't follow their regulations you should EXPECT to eventually end up in court.  It shouldn't come as a surprise.  The only reason to do so would be to seek a legal precedent.   Still understand you would be playing with fire.  There are both civil and criminal penalties for violations of the BSA (which FinCEN says applies by the classification of this activity as money transmission).  If you win, FinCEN doesn't really lose anything other than having to scale back the scope of the activities they are able to regulate.  If FinCEN wins, you could potentially lose everything you own, your future income, and even your freedom.   The law isn't always fair.  You should get some competent legal counsel for engaging in activity that an agency says is regulated.  Under the MSB regulations yo have the right to file for an administrative ruling from FinCEN.  In essence you describe in detail your specific business activity and they will clarify if it is regulated or not and why.

Lastly I would say that personally I believe that FinCEN's guidance is contradictory, reaching, and probably extends beyond the scope that the statute was intended.  Of course none of that matters.  If FinCEN convinces an old guy in a black robe that your activity does indeed fall under the scope of the BSA, well that would be very bad so you should at least go in with your eyes wide open.

The is no unified view of the memory pool between all nodes.  Different nodes may have different views of what txs exist at any point in time.  Say a node publishes a block which has a high score (ratio) for the tx in that block but that block contains tx your node isn't aware of and/or doesn't include some tx that your node is aware of.  Is the block valid or invalid?

One could engage in mining PoH blocks by continually creating a new slightly different tx (and thus different tx hash) to change the hash of the tx set until the miner/attacker finds one which gives it the best ratio and publishing only that block.

Things like this make selfish mining much easier.  I find a block with a very good ratio with all txs and I don't publish it.  I then try to find an inferior but still good enough and publish that one.  Once my competitors start working on the false chain in secret I mine off the better one and if I find a block I publish both back to back.  If I don't find a block I publish the better one before whatever max latency limit passes and I have lost nothing.  Unlike selfish mining where the longest chain wins, I have nothing to lose by engaging in selfish mining.  I have essentially stacked the deck because some blocks are better than others and I can make sure that I always know about the better one.

It is an interesting idea but as presented would be non-deterministic and thus very easy to game.  There would be no reason to "mine" fairly and plenty of incentive to mine unfairly.  This would make reorgs more frequent and deeper and would discount the security of transactions.  6 confirms is considered very secure not because 6 is a magic number but because the probability of reorgs more than 6 blocks deep is very rare unless an attacker has a majority of the hashrate, if reorgs are more frequent and deeper then one would need a higher number of confirmations to have similar assurances of security.

That is not correct for all wallets and certainly isn't correct for the OP wallet.


The Bitcoin Core wallet will continually attempt to rebroadcast a transaction forever.  It doesn't allow tx which won't be relayed to be created and then assumes it will eventually be included in a block.  There are ways to double spend the original but they user intervention and third party utilities.

It probably would be overly complicated (given the very small window , limited scope, and limited utility of the attack) but one could make this (almost) trustless by having the service sign first.

So
1) user spends some coins
2) service partially signs first
3) offline user partially signs but doesn't broadcast the tx yet.
At this point only the user has the final tx and hash
4) User provides the service but the hash but the not tx
5) Service creates and partially signs the "refund" ntimelock tx.
6) User verifies the refund tx is valid and broadcasts the tx from #3 to the network.

Even here in theory the service could detect the relayed tx, mutate it and broadcast it to one or more miners hoping that a variant of the tx is what ends up in the block (and thus makes the refund tx invalid) but this is a very difficult attack to pull off as it is very likely the users tx broadcast in #6 will win the race to all miners.  Optimally bitcoin will eventually have immutable txids (can be done via a softfork and then eventually deprecation of non-canonical forms in a future block via a hard fork).   With immutable txs, I am not aware of any attack vector.


Yes although it goes by block time so keep in in mind block times can be "fudged" by up to two hours.  In most applications this will not be an issue as the locktime will be sufficiently far in the future.  

There are two issues with a system like that
a) Bitcoin has no mechanism for detecting the first broadcaster.  Say you hold the tx for five years, and then you broadcast it, the miner including it in a block could simply take credit.  There may be a novel way to avoid this but it isn't a solved problem.  The reverse is also true.  A node could collect a fee in advance but then could simply delete the tx without loss.

b) The fee system is designed to prevent attacks which degrade the performance of the network.  With a finalized tx the tx will eventually end up in a block and thus the network can be assured the fee means a real cost to the user.  An attacker trying to degrade the network would need to a pay a steep fee to do so.   With locktime transactions the fee doesn't guarantee a cost.   A user could spam the network with millions, potentially billions of future txs all with hefty fee and then end up paying for none of them by creating another tx prior to the locktime and broadcasting that making all those held txs invalid and thus the fees promised, never paid.

Still Locktime is a useful tool even when the tx is not relayed.  I will give just one example.  Say I operated a "green address' type site.  You have 1 key, I have 1 key.  The address requires 2 of 2.  I can't spend your coins without your permission and if a merchant trusts me to not approve a double spend then they can trust 0-confirm payments from you.  That would be a very useful service but while I can't steal your funds (2 of 2 remember) I can hold them hostage.  This could be for malicious reasons, governmental interference, or just due to incompetence (if I lose my key your funds are lost forever).  LockTime can be used to end that "stalemate", after each transaction I provide you a future locked tx which sends your coins back to an address you control.   If either one of us loses our key or refuses to sign a tx eventually that locktimed tx will become finalized and you can simply broadcast it to the network to recover your coins.  That LockedTimed tx acts like a "voucher" to recover all your coins in the event of a problem but one which can only be used in the future.  That is just one example but it shows how LockTimed tx don't need to be broadcast to the network prior to their LockTime to be useful.  Other nodes don't need to hold the locked tx because you have a very strong incentive to hold your own locked tx (i.e. in this case it lets you recover your coins).


 

I think you misinterpreted a prior post of mine.  Danny explains it well in that the subsidy probably is larger than what it needs to be right now, however Satoshi didn't know how fast Bitcoin would increase in value the subsidy simply halves every 4 years.  .  The subsidy is buying about $2M a day in security.  Would Bitcoin be fine with $1M a day, or $300K a day?  Given the current tx volume probably.  

Eventually Bitcoin will need to be supported by tx fees only.  So yes today if the block subsidy went from 25 BTC to zero then one of the following would happen:
a) fees would need to rise to $30 per tx
b) tx volume would need to increase 1000x overnight
c) the hashrate would fall >99% as miners turned off unprofitable hardware

The good news is the subsidy isn't going to zero overnight.  


Or tx volume increases significantly.  In 12 to 15 years, Bitcoin will either be gone or tx volume will be much much higher.  The "$40" number assumes the hashrate (or more correctly the cost of that hashrate) remains the same AND the tx volume remains the same.  avg tx fee * annual tx volume = total miner revenue.  

It isn't a protocol issue, it is more a human behavior issue and that is a lot harder to "fix".   Logically a miners largest cost is the electrical bill and electrical bills are only due once a month.  Even a pool with 2% of the hashrate will have a 95% confidence to be +/- 10% of the expected revenue after 30 days.   However most miners want a reward now, right now.  That probably isn't going to change. p2pool is a good example.  Right now p2pool shares are ~1000x easier than solo mining however most miners do use it.  Logically even if you radically changed the protocol such that solo mining was 1000x easier most miners would probably not use it. 

Still the risk of 51% attack from pools is overstated.  Lets say right now ghash had 70% of the hashrate.  How would they produce an attack chain?  Well they would need to stop mining the main chain.  ghash on average would go from producing say 8 blocks in a 2 hour period to producing zero.  They can't mine both the main chain and attack chain at the same time.

The risk is small but it could be made even smaller by making it easy for miners to verify they are extending the longest chain.  For example the current block hash of the last block in the longest chain is 0000000000000000302b107dcfdaf35d3b09366638e19aa24ffa91dd7f91d57c and thus all miners should currently be working on a block that extends that block.  Right now if all pool miners are extending block 0000000000000000302b107dcfdaf35d3b09366638e19aa24ffa91dd7f91d57c then you know that no 51% attack is ongoing.  Even if all pools were infiltrated the only thing an attacker could do is steal the mining revenue (by changing the coinbase tx). 

It would be possible to modify the blockheader so that miners (and third party observers) can verify that they are mining the longest legit chain.  This could be done in a backwards compatible manner (won't break existing ASIC hardware) by including a partial block hash of the prior block in the last segment of the block header.  There is limited space in the final segment of the blockheader (the one that the miner adds the nonce and thus must always be provided in full by the pool) so the full blockheader is far too long.  By extending the blockheader and putting the rightmost 8 bytes of the prior blockhash (i.e. 4ffa91dd7f91d57c for the block above) in the last segment it would be easy to spot attempted misuse of miner computing power.  The mining software (using SPV protocol) would maintain an independent record of the longest chain (and the last block extending it) and would verify the work provided by the pool, extends that chain.  If the software detects a scenario where they are not mining the longest chain they would stop mining (or switch pools to a pool that is extending the longest block) and warn the user.   

This type of "verify I am on the longest chain" can be done without a change in the blockheader but it would require pools to send the full blockheader to miners.  For efficiency reasons they don't and that is unlikely to change.  Also if a pool doesn't it can't be forced to do so and most miners wouldn't see a lack of the verifying information as sufficient reason to not use the pool.  Changing the blockheader would ensure the necessary information is always sent to the miner.

As piotr_n pointed out the bitcoin expects the highest bit to be zero so if it isn't an extra zero byte is added.  This means that r & s will always be 32 or 33 bytes.  Don't quote me but I believe this is a bug in OpenSSL which was copied and now everyone has to keep the bug in the code to ensure it remains compatible.


Correct. A point in computed in the creation of the signature (k x G) but it is not the signature itself.  r & s are not an x & y value. 

Yes.


You will also need to know the sighash.  Given r,s, and sighash they are arranged in the following order:
<Len_sig><sequence = 0x30><len_rs><integer = 0x02><len_r><r_value><integer 0x02><len_s><s_value><sighash>

All elements are 1 byte except r & s which will be 32 or 33 bytes.  Also be sure to read up carefully on sighash because it is "moved" (for reasons that are beyond me).  Another Satoshi-ism I guess.

r_value = Convert r into a little endian byte array.  If the leading bit is not zero then prepend a zero value byte.
s_value = Convert s into a little endian byte array.  If the leading bit is not zero then prepend a zero value byte.
r_len = number of bytes for  r (always 20 or 21)
s_len = number of bytes for s (always 20 or 21)
sequence = always 0x30
integer = always 0x02
len_rs = r_len + s_len + 2 (two extra bytes for the two integer bytes)
len_sig = len_rs + 3 (three extra bytes for the len_rs byte, the sequence byte and the sighash byte

What follows next is whatever is needed to complete the script which is encumbering the outputs.  The PubKey then follows when redeeming Pay2PubKeyHash outputs but is not universally present in other output types (i.e. Pay2PubKey).  



Correct.  There is very little reason to use DER encoding other than satoshi did it that way.  A new version of the tx format could created which is more space efficient.  The major advantage of DER encoding is sharing information between incompatible systems.  It is excessively verbose to facilitate a data interchange.  Putting DER signature inside propreitary data makes no sense.  Knowing DER doesn't allow you to decode a Bitcoin tx, and if you can decode a Bitcoin tx you could just follow explicit rules to decode r,s, sighash, pubkeys, etc just like you need to follow explicit rules to decode the tx version, number of inputs, sequence, etc.

Once again an unspendable output isn't an output that is invalid, it is an output that is invalid.  An invalid output means an invalid tx, and any block including it would be an invalid block and thus never part of the longest chain.  For example a native multisig output which is greater than 3 of 3 is invalid.  It will never be included in a block.

Unspendable =/= Invalid.  Unspendable is just unspendable.  It could be unspendable on purpose ("burning coins" or by accident (wallet software errors) but it is unspendable all the same.


To date 135.20997146  BTC have been destroyed.
(305997-210000)*25 + 210000*50 = 12899925.00000000 BTC
12899925.00000000 - 12899789.79002854 = 135.20997146


I have no idea what you are talking about.  An unspendable output is an unspendable output no matter who creates it.  Nobody said anything about a pool creating an unspendable output.

On the off chance that your response wasn't just affiliate spam, there is a difference between an invalid tx and an unspendable output.  An invalid tx is simply dropped from the network.  It will never become part of a block and thus the coins will never be destroyed.  An example would be a tx which has 1BTC in inputs and a 1.1 BTC output.  That is an invalid output.   To destroy coins requires an unspendable output.  OP_RETURN is a valid but unspendable output.

Maybe. Entropy is probably the way to go.  I would put them in category 4 (post #8) as they are only probably lost.  Maybe one could make a entropy parser to flag potential keys to add to that list (semi-automated).  Humans are sometimes better at that kind of stuff.  If nothing else compiling such a list would be useful as test cases from an automated tool.