Bitcoin Forum
July 02, 2022, 11:43:41 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Bitcoin / Mining / Audit your pool with better stats on: August 25, 2015, 04:21:37 PM
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 = n

This 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/blocks

The difficulty implied a network total in the same period was 355.711 PH/s, see https://bitcoinwisdom.com/bitcoin/difficulty
This 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.


2  Bitcoin / Development & Technical Discussion / Dust outputs redeemable with obvious brain wallet keys, for what? on: July 08, 2015, 12:57:43 PM
What is the purpose of creating tons of trivially redeemable outputs?
 
See:
https://blockchain.info/address/162TRPRZvdgLVNksMoMyGJsYBfYtB4Q8tM

Anyone could claim the 0.04 BTC there (at the moment) with a key derivable as SHA256("cat").
Rational miner will claim them for themselves, that however leads to a block stuffed with a big transaction like:
https://blockchain.info/block/000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe
since the 0.04 is distributed to hundreds of outputs.

The redemption attempts of non-miner will be included into the mempool by nodes in some non-conflicting combination until they are purged as doublespend.

Is this a troll, a DoS, trying to prove some point or engineered to drive up fees?
3  Bitcoin / Bitcoin Discussion / Introduce reorg limit for guaranteed settlement and attack resilience? on: February 20, 2015, 11:21:19 AM
TL;DR: Suggest limiting Bitcoin's ability to automatically reorg to 6-72 blocks, for non-technical reasons.

While it technically makes sense to re-org whatever it takes to switch to the fork with more POW, this ability if unconstrained is incompatible with the business need of a final settlement.

Think of a bank account statement mailed to you. Do you think any jusrisdiction would allow the bank to revise the statement today and re-mail it with yesterday's date? Nope. Especially not for an IT reason. If there are errors then adjustments could be made, but with today's date and clearly flagged as adjustment, not just through presenting a new backdated reality.

Current financial technology works with settlement cycles, usually a few per day. Funds that settled at the last cycle can not un-settle in the next for a reason unrelated to the parties involved. If an adjustment is requested by either party or for a technical reason, then they are flagged as such and are not processed with the same workflow, but often trigger human review and decision on the matter. This is not because technology in banks was bad, but because final settlement of claims is of value to the bank's customer, it simplifies their business process and is the primary reason they use a bank account to settle claims.

To deliver the same value to business, Bitcoin transactions have to be final after a time horizon comparable to settlement cycles, that is a few hours.

An implementation for final settlement would disallow automated reorgs longer than few hours' of blocks, that is 6-72.

Assuming a reorg limit of N was implemented, businesses could be certain that transactions with at least N confirmation are final and this would greatly simplify their business process. B2B systems would likely use only transacions with N confirmations and they would love the network for its simplicity and reliability.

What would happen if a reorg longer than N is justified by POW?

Following Gavin's thoughts at https://gist.github.com/gavinandresen/630d4a6c24ac6144482a this would be the result of either a long network split or an attack.

A network split should not come as a surprise, since previous significant drop in block frequency would indicate that something is fishy. IT would check connections and stand ready to accept a longer fork as connections are restored. Customer could be notified that settlement cycles are suspended until the problem is resolved. Once the network is reunited longest chain was accepted no matter how long it reorgs and some time later customer notified that business is again as usual.

An attack would rather look like sudden increase of hash rate. Should it reorg more than N, then the network would, by default, ignore it thereby making the attack even more expensive. Since IT teams would not stand ready to act as in the split case, the manual switch to the longer "attack" chain was delayed indefinitelly. More likely than action of the majority it was the rougue miner who would learn that playing by the rules (that is mining on the tip) is more profitable.

For above reasons I think Bitcoin would become more attractive for business use and be more resilient to "51%" attack if it had a limit to automatic reorg, and could only be overridden with a manual action.
4  Bitcoin / Development & Technical Discussion / Did satoshi not know that public key is recoverable from ECDSA signature? on: January 29, 2015, 08:18:28 PM
I was remembered to https://bitcointalk.org/index.php?topic=6430.0 where sipa points to a paper desribing how to extract public key from the signature and the signed digest.

Satoshi eliminated every redundant byte in transactions and blocks, think of the compressed encoding of difficulty or the 32 bit date.

Why did he miss this significant opportunity of transaction size reduction?
Was it not known by 2009 or was it not known to him or is there more in this decision ?
5  Bitcoin / Development & Technical Discussion / What if 50%+ attack starts at a disadvantage and has to succeed qucikly ? on: January 12, 2015, 09:18:24 AM
I was thinking about the scenario where an attacker bundles 50%+ computing power, to revise some transaction already confirmed several times.

This would mean that the attacker has to fork from an earlier block and catch up with the tip of the chain. The probability that he manages to catch up is 1, but the time needed to carry out the attack depends on his margin of majority and the disadvantage he starts from.

Add to the scenario that the attacker has to complete the attack within a limited period of time, then it becames apparent, that 50%+ power is still not a guarantee for success.

Assuming the probabilty that the honest minority finds the next block is p (and the attacker has (1-p) > 0.5) then the expected time to catch up is proportional to

advantage/(1-2p)

showing that expected catch up time goes to inifite while margin over 50% is approaching 0. Constraining the expected catch up time raises the required margin exponentially.

While evaluating feasibility of a practical attack, not only its expected value but the variance of the outcome is of importance. The variance of success will be also huge if margin over 50% is small.

Am I right?
6  Bitcoin / Bitcoin Discussion / Bitcoin's biggest problem is the language we use to describe it on: January 07, 2015, 08:32:13 AM
It appears to me that the language we use determines and limits the adoption of the block chain technology.

We often use words like: mining, payment, de-centralisation, trustless operation that lead to the perception we talk about some obscure virtual currency for speculation and a tool for illicit activity.

We know that there is more to it, but our communication is as if we were trying to explain the Internet is by elaborating on what http:// stands for (Hyper Text Transport Protocol). Explaining Hyper Text is as useless for the purpose of teaching Internet, as e.g. explaining digital signatures for block chain technology. Those technological marvels help us to get it, but they are not on the path of understanding for most others.

Nick Szabo made a remarkable progress by coining the term Trustworthy Computing in http://unenumerated.blogspot.hu/2014/12/the-dawn-of-trustworthy-computing.html

We need more of these words and terms, that trigger the right intuition without a recourse to technical details.

Please point me to similar if you came accross.
7  Bitcoin / Bitcoin Discussion / The HODL faucet challenge on: September 26, 2014, 07:06:37 PM
Today I announced on my Facebook feed that I send 10,000 bits to the first 10 Bitcoin address posted as reply.
I gave links to an Android and an iPhone wallet to support newcomer, it created at least 10 new Bitcoin users by pouring 0.1 BTC of my own.

This is the HODL faucet challenge I now pass on to all of my fellow HODL-ers!

It will feel like ice water for you, but it will spread the word and create thousands of new Bitcoin converts, we need badly.
8  Bitcoin / Bitcoin Discussion / One of the oldest addresses spends to Dorian on: March 12, 2014, 01:09:25 PM
The Bitcoin address 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv was first used on January 16, 2009 where it received two 50 BTC coinbases sent on March 7, 2014 to the 1Dorian address.
9  Bitcoin / Development & Technical Discussion / Speculation: How to lose significant funds through malleability on: March 01, 2014, 09:11:45 AM
While thinking through implications of malleability and the story of Empty Gox, I came up with a speculative idea how one could burn significant funds while facing a malleability attack.

This is pure speculation, a thought exercise to elaborate what to watch out for if developing a custom wallet.

Assume one have a set of coins, that is UTXOs and a set of keys that are able to spend them.

Now for some reason, that could be withdraw or even internal reshuffling one spends some of them in a transaction t1. Since the wallet is privacy aware, the change of t1 goes to a new key and is added to the key set. Since the change of t1 only depends on own transaction, one might fall for the assumption that this new UTXO is as good as any other in the pool and spend it in a subsequent step with t2 before it is confirmed. We know that this scheme could blow up if t1 is confirmed with a different hash as t2 will loose its input and become invalid.

This is an inconvenience but not really a big deal since t2 can be recreated referring to new t1 hash. WAIT there is one other thing you need that is the key to unlock t1. I believe that the key could fall victim to an aggressive optimization of the key set. Why keep a key around for coins spent?

Once one sees the trap it becomes obvious that even confirmed transactions that come in with a new hash after a reorganization of the chain might trigger the need for a key that was previously considered useless for good.

I read in some thread that satoshi said there is no reason to ever delete a key. He is right as usual. In a high demand environment such as an exchange that creates tons of keys a day (because it is also privacy aware) keeping all keys at hand that were ever used is a significant burden.

An efficient storage of that amount of keys can only be algorithmic, that is HD. Good that I build exchanges with that...


10  Economy / Service Discussion / Lost or stolen cold storage at Gox? on: February 27, 2014, 08:44:37 PM
If that is the case, then how about giving the MtGox answer to the questions raised by Stephen Gornick in his post above?

If you want (replaced CampBX with MtGox and replies in bold for readability):

 - Does [MtGox] use cold storage (an offline wallet that cannot be accessed should the exchange's service become compromised)

Yes.

 - Is there a target as to how much of customer's funds are kept in cold storage?  (e.g., percent of total, or perhaps relative to recent withdrawal requirements)?

On average 98% of customer bitcoins are held in cold storage, with possible variations on large bitcoin moves (large deposits or customers asking for large withdrawals).

 - Do new deposits go to cold storage?  (if the hot wallet is compromised, new deposits made (e.g., automated payouts by mining pools) would still be secure)

No, this wouldn't be practical in terms of number of bitcoin addresses to keep in cold storage. This could change thanks to BIP 0032 which we are working on implementing. It should be noted however that we are using a hardware security module for the hot wallet

 - Does the offline wallet where the cold storage resides remain protected due to an "air gap" (no access to it electronically, not connected to the network)?

Offline wallets are generated from an offline system and kept in paper format in three separate locations, using a technology based on raid. It will likely be changed to use Shamir's Secret-Sharing method in the future, and all existing offline wallets will be converted to this.

And I have other questions that I'ld like to now the answers to:

 - Does [MtGox] maintain full reserve?  (i.e., [MtGox] controls bank accounts with all customer USD funds and controls wallets with 100% of BTC funds.  None of these amounts loaned out.)

As described in our Terms of Service, customer funds are kept in full, and none are loaned.

There are three alternatives:

a) all above is a lie
b) cold storage no longer accessible through incompetence
c) cold storage stolen by an insider

Since incompetence was proven by Gox at every chance given, I vote for b.

11  Bitcoin / Development & Technical Discussion / why transactions with zero fee are preferred above one with 0.000139 fee? on: February 09, 2014, 05:51:59 PM
I have a transaction pending in the mempool since hours because it pays less fee than required, not zero. The fee should be 0.0002 but it pays 0.000139.

I would understand that it takes longer than those paying the right amount, but am pissed to see that transactions with zero fee are getting included but not this one.
This is just not logical.
12  Bitcoin / Development & Technical Discussion / KDF or BIP39 on: February 02, 2014, 10:14:22 AM
With BIP39 128 bits of random key can be conveniently encoded into 12 words.
 
Assuming the key is really random, is there a need for a KDF, or is it OK to use the 12 words as a kind of brain wallet?
13  Bitcoin / Bitcoin Discussion / who is next? on: January 16, 2014, 06:50:28 PM
Jeff - BitPay
Gavin - Coinbase
Mike - Circle

Does this remain a community project?
14  Bitcoin / Bitcoin Discussion / Why Bitcoin does not work for porn on: December 30, 2013, 10:23:41 PM
At the first sight Bitcoin is ideal for porn since it protects customer privacy and cuts payment processing costs for the provider. Like many in the community I expected for long that Bitcoin will pick up in that industry and kept wondering why it takes so long...

... until today, when I learned from an industry insider why Bitcoin is not accepted at porn sites:

1. Because nearly all porn sites have introductory offers that lead to a subscription with recurring billing on the credit card until the customer explicitly recalls it. The fees are calculated with the assumption that most customers forget to cancel at least a couple of times or not even recognize that they pay for a service that they no longer use.

2. Because affiliates - those who direct traffic to the porn site - want a share of those fees in upfront. An affiliate receives a multiple of the introductory offer immediately if someone he directed to the site subscribes for a plan. Affiliates do not want the site to use bitcoin either.

3. Porn sites have difficulties working with payment processors and are called 'high risk' industries, but not because of their customers or products, but because they themselves misuse the credit card re-bill features (see 1) and cause lots of customer complaints at the credit card issuer.

4. Biggest porn sites therefore have their own credit card processor.

Summary: Bitcoin would be beneficial for customer of porn but will not happen until the industry has any other choice.
15  Bitcoin / Development & Technical Discussion / why is this nonstandard on: December 09, 2013, 10:23:24 AM
Anybody could give me a hint why satoshi says the below transaction would be:

ERROR: CTxMemPool::accept() : nonstandard transaction input

As far as I see it only uses PUSH operators in scriptSig.

Code:
0100000002201ac3bea02ec2c3dcc86b123e5e0c53290e58ea5f7bf47154afbaec4f25c00700000000fdfe000000473044022022240b411509a86d9d092d0dfab636e981d36a19a5d3d20017f770173a3170ac02204fa7276400f3edea34b49edc9b0363e1be1ecdb017e8c74ba3ce56119715e2df0148304502205cd3a7972a7a4253b24b5607a18d60bdbc8d749de03ae1e68452ce5b0b559e75022100d929fb1cbf6191be76f379d4a24f6c5e89a58a4c45c437f3feaf27597688f33b014c695221031d11db38972b712a9fe1fc023577c7ae3ddb4a3004187d41c45121eecfdbb5b7210207ec36911b6ad2382860d32989c7b8728e9489d7bbc94a6b5509ef0029be128821024ea9fac06f666a4adc3fc1357b7bec1fd0bdece2b9d08579226a8ebde53058e453aeffffffff2312503f2491a2a97fcd775f11e108a540a5528b5d4dee7a3c68ae4add01dab300000000fd010100004930460221009f705343b234ce23814fb2487468bada931a87038194010dcb897e5fea48926e02210088e5fba6c25660fadc3f45f62590dbbf61eda188b42ecfcaa3f429405d31921e014930460221008ecf4cb533f31f160dcf1475fbfdb08768e8d89d058c61a3416ac69f7dda73e1022100829e47757b481413790846bb8c4f35ced12a52169eb53f3cecb39eaa618af095014c695221031d11db38972b712a9fe1fc023577c7ae3ddb4a3004187d41c45121eecfdbb5b7210207ec36911b6ad2382860d32989c7b8728e9489d7bbc94a6b5509ef0029be128821024ea9fac06f666a4adc3fc1357b7bec1fd0bdece2b9d08579226a8ebde53058e453aeffffffff02a0860100000000001976a914c9b99cddf847d10685a4fabaa0baf505f7c3dfab88ac701101000000000017a914b1ce99298d5f07364b57b1e5c9cc00be0b04a9548700000000
16  Bitcoin / Development & Technical Discussion / research and development grants? on: December 09, 2013, 05:59:31 AM
Alt coins contract research and development while Bitcoin still builds on voluntarism and donations.

I have not received a signgle satoshi of donation since the conference in San Jose in May.
Should I rather work on alts too?
17  Bitcoin / Development & Technical Discussion / Identity assertions with Bitcoin instead of CA in Payment Protocol? on: November 04, 2013, 07:58:45 AM
https://eprint.iacr.org/2013/622.pdf

The authors of the paper claim in the abstract:

Quote
In this work we propose a novel anonymous credential scheme that eliminates the need for a trusted
credential issuer. Our approach builds on recent results in the area of electronic cash and uses techniques |
such as the calculation of a distributed transaction ledger | that are currently in widespread deployment
in the Bitcoin payment system. Using this decentralized ledger and standard cryptographic primitives,
we propose and provide a proof of security for a basic anonymous credential system that allows users to
make exible identity assertions with strong privacy guarantees. Finally, we discuss a number of practical
applications for our techniques, including resource management in ad hoc networks and prevention of
Sybil attacks. We implement our scheme and measure its eciency.

If that holds shouldn't Payment Protocol's use of CA be revisited?
18  Bitcoin / Development & Technical Discussion / Incremental chain download using SPV proofs? on: November 02, 2013, 05:21:48 PM
What do you think of a protocol extension for SPV style chain download of the subset relevant for one's wallet?

A node would query SPV style proofs for transaction inputs relevant to it until proofs reach coin bases or verified by previous proofs.
19  Bitcoin / Development & Technical Discussion / How to frustrate a miner. on: October 17, 2013, 10:36:29 AM
I developed the following attack while discussing https://bitcointalk.org/index.php?topic=312668.0
Let me summarize it for a more targeted feedback if it would work:

Assume somebody is determined to frustrate a miner.

He prepares the attack by sending a sizable amount to his own new address. He repeats for every block. The transactions might build a chain, but do not have to.

As the disliked miner creates a block containing any of his prepared transactions he launches the attack by creating a transaction double spending that transaction to a script trivially redeemable and sending it to other miner.

Assuming miner act rationally and the trivially redeemable output is of tempting size, they will start working on a block parallel to that of the disliked miner and include the double spend and a transaction redeeming it to their own address.

If repeated the disliked miner will not be able to get a block to the trunk, hence no revenue.
20  Bitcoin / Project Development / Video mashup to create the best Bitcoin commercial from this.... on: October 13, 2013, 09:32:56 AM
The video https://www.youtube.com/watch?feature=player_embedded&v=oQ1zfn74VoQ
would need just a few cuts to become the best commercial for Bitcoin.

I will donate 0.1 Bitcoin to the creator and am sure other would follow.
Pages: [1] 2 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!