|
Mike's work on bitcoinj enabled most mobile wallets and by that a big part of mainstream adoption.
His lighthouse project is one of the finest demonstrations of what Bitcoin, as is, is capable of.
His view might be too pessimistic, but community lost a good engineer.
|
|
|
|
|
A copy of wallet.dat contains all information you need to spend or transfer your coins at any later date (except the scenario described by teukon).
I would however advise against long term storage using wallet.dat for practical reasons:
Chances are rather good that in a few years
a) a current Bitcoin Core will not even have a wallet, therefore unable to import wallet.dat
b) your old Bitcoin Core might not be able to join the network, e.g. because current nodes use a different chain download protocol and you can't find old nodes.
c) your old Bitcoin Core might create transactions that are no longer forwarded/accepted by the network because they violate some later introduced soft-fork rule
d) your choice of new wallet might not be able to import wallet.dat
There are developments in Core that support assumptions a-c and d is probable because all modern wallets use HD key generation instead of a random key chain, that is wallet.dat.
I suggest you move your coins to a more modern wallet, e.g. the TREZOR and store its recovery seed in your long term store. Also assume that you may need to move on again later.
It is a bit like converting your videos to a newer codec. Ignore the development and will become a pain, but will work with sufficient expertise.
|
|
|
|
1/2500 = 0.04% is far from impossible. Not even really that unlikely.
*Lots of pointless dribble* 1 in 2500 chance that any block a pool solves is 99.96% CDF or worse. That is a fact. Slush has solved just under 25,000 blocks. Over an infinite number of samples of pools with 25,000 blocks solved, you would expect the mean number times the pool encountered a 99.96% CDF or worse block to be 10. Now if you go through slush's history and find 20 times that there were 99.96% CDF (or worse) blocks, then you might have something. Or maybe if you find that in the last 5000 rounds it has happened 5 times, you might have something. Otherwise you're trying to claim something shouldn't happen when it clearly SHOULD and WILL happen multiple times in the lifetime of that particular pool. I have not claimed it should not happen, but that the event is less likely than temporary technical problems. I also presented a model for the appropriate trigger levels of investigation, since a pool operator who has to explain production outcome to investors needs a model more precise than ..... your dribble. |
|
|
|
1/2500 = 0.04% is far from impossible. Not even really that unlikely.
Not only is it not unlikely, it's extremely likely and has SHOULD have happened multiple times. It's not 0.04% of it happening ever in the lifetime of the universe. It's 0.04% chance *on any block* that the pool solves. Yes it is 1/2500, that means it is expected once in 7 years within the continous operation of a pool of that size. No, it is not linked with lifetime of the universe or with *any block*. That gap was confirmed by slush, it is not a problem on his website. This was an improbable event, lets not argue about the adjectives. What I claim is: The assumption it was linked to e.g. a technical problem, a withholding attack etc. is much stronger than that it was bad luck. Because having e.g. technical problems more often than once in 7 years is quite feasible. It was also disappointing if the discussion of this topic was about adjectives and Slush' operation and not about using more advanced metrics for pool audit. I used the above probability metrics while running the mining operation of CoinTerra, (was 3-5% of the total network in 2014) and they were helpful to define error levels where an investigation of infrastructure was triggered. The below graph shows the alert levels we used. The trigger was no block for n hours (y axis) with a maret share as of x axis. The lines are: - blue (watch) : check systems - red (alert): elevated manual checks - yellow (panic): search for a problem until you find it (You see that slush' example is deep in that range) One might set different levels but the shapes should be ike this. We applied the model overall and on data centre level.  |
|
|
|
We know that the expected production of a mining pool is linearly proportional to its market share (x%), it is 24*6*x% blocks per day. The actual production however follows the Possion distribution for reasons you find in the first paragraph of https://en.wikipedia.org/wiki/Poisson_distribution "... the Poisson distribution ... expresses the probability of a given number of events occurring in a fixed interval of time and/or space if these events occur with a known average rate and independently of the time since the last event."The probability of not finding a block within a time span in which one would expect n blocks is simply e^-n Remark: This is the CDF with i = 0 and lambda = nThis means one can assign probability to an observed production outcome and quantify how likely is it. A probability measure is more informative than "luck" used on many sites and you only need a pocket calculator for the check.Historic Example:Slush did not mine a single block for two consecutive days between 19 and 21. Jun 2015 while reporting 9.516 PH/s miner at pool. see https://mining.bitcoin.cz/stats/blocksThe difficulty implied a network total in the same period was 355.711 PH/s, see https://bitcoinwisdom.com/bitcoin/difficultyThis translates to a historical market share of 2.68% With that market share one would have expected 2*24*6*0.0268 (means nearly 8 ) blocks in two days. How probable was not having any blocks in the same time just bad luck? Exp[-2*24*6*0.0268] = 0.04% for me that falls into the practically impossible bucket. |
|
|
|
- snip -
the probability of 5 blocks within next 40 mins is 15%.
Do I understand it correctly then if I say that the probability of 5 or more blocks within the next 40 minutes (and therefore within the 40 minutes immediately following the broadcast of a block) is 26%? The probability of 5 or more blocks within the next 40 minutes is 1 - N[CDF[PoissonDistribution[4], 4]] = 37%, I made a correction in my first reply, see striketrhough. Since events are independent, it does not matter if you are just after a block or not. Probability of 5 or more blocks includes probabilty of 5, probability of 6 .... The way you deal with this is using cummulative probability function as I enumerated in the previous post. Using that table you can compute the probability of any block number range withing 3 hours. Examples: The probability of less or equal 15 blocks is 28.6 % The probability of more than 20 blocks in 3 hours is 1-0.73072 = 26.9% The probability of 16-20 blocks is 0.73072 - 0.286653 = 44.4% |
|
|
|
Based on what I have seen, however, I wish I had another plot, this time the Poisson distribution as you have presented it, only for lambda = 18 (3 hour expected network block production), and running out to k = 36.
While I am wishing, I also want a numeric table of the cumulative distribution function for the same distribution.
here you are: 1. probability of exactly n block within 3 hours:  2. cummulative numeric, that is probability to have <= n blocks within 3 hours: {
{0, 1.523E-8},
{1, 2.8937E-7},
{2, 2.75663E-6},
{3, 0.0000175602},
{4, 0.0000841761},
{5, 0.000323993},
{6, 0.00104345},
{7, 0.00289347},
{8, 0.00705601},
{9, 0.0153811},
{10, 0.0303663},
{11, 0.0548874},
{12, 0.0916692},
{13, 0.142598},
{14, 0.208077},
{15, 0.286653},
{16, 0.37505},
{17, 0.468648},
{18, 0.562245},
{19, 0.650916},
{20, 0.73072},
{21, 0.799124},
{22, 0.85509},
{23, 0.89889},
{24, 0.93174},
{25, 0.955392},
{26, 0.971766},
{27, 0.982682},
{28, 0.9897},
{29, 0.994056},
{30, 0.996669},
{31, 0.998187},
{32, 0.99904},
{33, 0.999506},
{34, 0.999752},
{35, 0.999879},
{36, 0.999942},
{37, 0.999973},
{38, 0.999988}
}
|
|
|
|
|
Yes, as you see on the plot I added in parallel to my first reply, the probability of 5 blocks within next 40 mins is 15%.
|
|
|
|
In probability theory and statistics, the Poisson distribution (French pronunciation [pwasɔ̃]; in English usually /ˈpwɑːsɒn/), named after French mathematician Siméon Denis Poisson, is a discrete probability distribution that expresses the probability of a given number of events occurring in a fixed interval of time and/or space if these events occur with a known average rate and independently of the time since the last event. From: https://en.wikipedia.org/wiki/Poisson_distributionMathematica says that: N[PDF[PoissonDistribution[4], 6]] is 10.4 % that is the prpbability of exactly 6 blocks per 40 min. The probability of 6 or more blocks in 40 minutes is: 1 - N[CDF[PoissonDistribution[4], 6]] or 11% 1 - N[CDF[PoissonDistribution[4], 5]] or 21% Below the plot of probabilty of n blocks per 40 min:  |
|
|
|
|
If that is the idea, it does not work for reasons:
- further spend attempts will not be broadcasted by a node after one of the attempts is included into the mempool
- people will figure soon that miner have advantage grabbing the outputs and stop trying.
Therefore the attack, if that is the purpose, is pretty lame.
|
|
|
|
Yes. I would also like to know how much data Bits_of_Proof has about trezor users' habits that have connected to mytrezor.com that will become the property of Digital Assets Holdings? Does Bits-of_Proof have any of the following: - data about IP addresses used by mytrezor.com users connecting to mytrezor.com - data about bitcoin public addresses used by mytrezor.com users - data about timing of bitcoin transactions by mytrezor.com users - data about sizes of bitcoin transactions by mytrezor.com users ?? Appreciate your candid and timely reply in ensuring faith with the open source community of trezor users and contributors. Bits of Proof has no access to the servers of myTREZOR. Bits of Proof wrote the software behind myTREZOR. It was a more than year ahead of alternate solutions, enabled the TREZOR product offer in the first place and has been serving thousands of customer daily since then. The software was delivered in source code to Satoshilabs, was compiled and deployed by Satoshilabs. There were a few source code patches delivered and applied to the orginal code base, last in February this year. They were again applied and deployed by Satoshilabs. I offered them a patch a few weeks ago for a marginal issue, they did not even reply to that message. I have no Idea if they used it. |
|
|
|
Here is a fragment that works for me. Not complete but you get the idea how to deal with ipv4 or 6. It is used to connect you, assuming your node was accepting incoming connections. If so, you should indicate in the service bits. Address a;
Writer writer;
.....
a.address = InetAddress.getLocalHost ();
a.port = myport;
writer.writeAddress (a, getVersion (), true);
class Writer {
.....
public void writeAddress (Address address, long version, boolean versionMessage)
{
if ( !versionMessage && version > 31402 )
{
writeUint32 (address.time);
}
writeUint64 (address.services);
byte[] a = address.address.getAddress ();
if ( a.length == 4 )
{
byte[] prefix = new byte[10];
writeBytes (prefix);
writeUint16 (0xffffl);
}
writeBytes (a);
bs.write ((int) (0xFF & (address.port >> 8)));
bs.write ((int) (0xFF & address.port));
}
|
|
|
|
|
Actually the generation of the word lists from a given entropy does not increase it, if the dictionary is known and fixed, just like hashing does not.
Therefore the key set is size is determined by the entropy generator. I was overestimating the entropy using the stats of the language.
|
|
|
|
If those words were used as an alphabet then they would define a 2048^12 or 132 bit key space.
The word lists are instead hashed (see BIP39) which gives an approximate entropy of 2.62*4.5*12 = 141 bits.
FYI BIP-39 (and Electrum 2.x) starts with a specific amount of entropy, and then derives the words from that entropy, not the other way around as you implied. Typically, this is 128, 192, or 256 bits for 12, 18, or 24-word long mnemonics. (and of course the hashing which follows does nothing to increase that initial entropy) Yes, the user would be a worse source of entropy if he was to chose the words directly. My point is, that if you are able to encode entropy into 12 words then it can not be more than entropy represented by 12 words, no matter of its source. You are right, that there are options generating a longer list, but I think default is 12 in popular wallets. |
|
|
|
|
ok here in detail how and why it works:
1. payer and payee agree on a 2-of-2 address and own addresses
2. payer crafts a bond transaction that deposits X to the common address, but sends only the hash (outpoint) of it to payee. payer does not yet broadcast it, hence no risk to him.
3. payee crafts and signs a refund transaction that spends the outpoint back to payee time locked, such that it can not be included into the block chain until that time point. Payee can safely sign since if he does not own any coin with the outpoint.
4. payer verifies that the refund transaction if counter-signed and broadcasted by him would return the bond to him and if so broadcasts the bond transaction. He can safely do so, since if payee would not proceed, but he could get his money back on his own after the timeout.
5. now payer wanst to use some service of payee and crafts and signs a settlement transaction spending the same outpoint that pays him X-delta and delta to payee. The transaction is not yet valid since it needs payee's signature, hence payer can not broadcast it. Payer sends it to Payee.
6. Payee verifies that the settlement transaction has valid signature of payer and that it gives him enough to offer the service. Payee could countersign and broadcast the settlement transaction thereby closing the channel and also invalidating (double spending) the refund transaction.
7. Payer keeps sending new versions of the settlement transaction with increasing deltas while using the service. If delta does not increase sufficiently Payee closes the channel.
8. At close of the channel Payee will counter-sign and broadcast latest version, since that is most favorable to him.
9. Payee will close the channel well before the refund timout to avoid a race of the two alternatives.
|
|
|
|
|
Bob does not broadcast the refund at start as it would not be included to the block chain or mem pool until its time has come.
The point of micropayment channell is not to broadcast anything but the final version of the settlement transaction.
The payee can flush the latest version of the settlement transaction any time to the block chain which then double spends and thereby invalidates
the refund. If this happens long before the refund timeout then malleability is not a concern.
The payer signs new versions of the settlement transaction and sends them to payee. Payer can not broadcast them as they are only signed by payer.
The payee will sign and broadcast the most favorable to him and that is the regular close of the channel.
|
|
|
|
Is irreversibility not a feature of the blockchain? I think irreversibility has always been by design. yes, indeed; it's a good thing. Strictly speaking the block chain is not irreversible, in contrary it is able to reorganize in any depth. Actually a valid critique of the technology that convergence to global consensus is not guaranteed within a time span of any length. Consensus just becomes less and less feasible to change with time. |
|
|
|
If you like playing with those numbers also consider that private keys in modern wallets are generated from word lists of length 12. If those words were used as an alphabet then they would define a 2048^12 or 132 bit key space. The word lists are instead hashed (see BIP39) which gives an approximate entropy of 2.62*4.5*12 = 141 bits. Therefore the attainable private key set in modern wallets is smaller than the 160 bit range of addresses. Using entropy estimates from here: http://people.seas.harvard.edu/~jones/cscie129/papers/stanford_info_paper/entropy_of_english_9.htm |
|
|
|
|
Show Posts
