Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-05-31 Thread Alex Mizrahi
Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-05-31 Thread Alex Mizrahi
That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. This depends on how miners are connected. E.g. suppose there are three miners, A and B have fast connectivity between then, and C has a slow network. Suppose that A miners a block and B receives it in 1

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Alex Mizrahi
Stop trying to dictate block growth limits. Block size will be determined by competition between miners and availability of transactions, not through hard-coded limits. Do you even game theory, bro? It doesn't work that way. Mike Hearn described the problem in this article:

Re: [Bitcoin-development] Long-term mining incentives

2015-05-13 Thread Alex Mizrahi
With POW, a new node only needs to know the genesis block (and network rules) to fully determine which of two chains is the strongest. But this matters if a new node has access to the globally strongest chain. If attacker is able to block connections to legitimate nodes, a new node will

Re: [Bitcoin-development] Long-term mining incentives

2015-05-13 Thread Alex Mizrahi
Let's consider a concrete example: 1. User wants to accept Bitcoin payments, as his customers want this. 2. He downloads a recent version of Bitcoin Core, checks hashes and so on. (Maybe even builds from source.) 3. Let's it to sync for several hours or days. 4. After wallet is synced, he gives

Re: [Bitcoin-development] Long-term mining incentives

2015-05-13 Thread Alex Mizrahi
I don't really see how you can protect against total isolation of a node (POS or POW). You would need to find an alternative route for the information. Alternative route for the information is the whole point of weak subjectivity, no? PoS depends on weak subjectivity to prevent long term

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Alex Mizrahi
Adaptive schedules, i.e. those where block size limit depends not only on block height, but on other parameters as well, are surely attractive in the sense that the system can adapt to the actual use, but they also open a possibility of a manipulation. E.g. one of mining companies might try to

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Alex Mizrahi
Just to add to the noise, did you consider linear growth? Unlike exponential growth, it approximates diminishing returns (i.e. tech advances become slower with time). And unlike single step, it will give people time to adapt to new realities. E.g. 2 MB in 2016, 3 MB in 2017 and so on. So in 20

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Alex Mizrahi
To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Alex Mizrahi
Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. Scorched earth makes no sense by itself. However, it can be a part of a bigger picture. Imagine an insurance service which will make sure that merchants are compensated for every scorched-earth or

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Alex Mizrahi
The approach is how Bitcoin has always worked. Mike, you're making it worked before, and thus it will work in future kind of an argument. It is an extremely shitty kind of an argument. And it can be used to justify any kind of bullshit. E.g. any scamcoin which haven't yet collapsed will work

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Alex Mizrahi
Miners are *not* incentivised to earn the most money in the next block possible. They are incentivised to maximise their return on investment. This would be right if you assume that all Bitcoin miners act as a single entity. In that case it is true that that entity's goal is to maximize

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Alex Mizrahi
The goal is to have an opportunity cost to breaking the rules. You could as well have said The goal is to implement it in a specific way I want it to be implemented. This makes zero sense. You aren't even trying to compare properties of different possible implementations, you just outright

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Alex Mizrahi
Secure and client side validation don't really belong in the same sentence, do they? Well, client-side validation is mathematically secure, while SPV is economically secure. I.e. it is secure if you make several assumptions about economics of the whole thing. In my opinion the former is

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Alex Mizrahi
I think what Gareth was getting at was that with client-side validation there can be no concept of a soft-fork. And how certain are you that the consensus rules will never change? Yes, it is true that you can't do a soft-fork, but you can do a hard-fork. Using scheduled updates: client simply

Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-11-03 Thread Alex Mizrahi
For those following this thread, we have now written a paper describing the side-chains, 2-way pegs and compact SPV proofs. (With additional authors Andrew Poelstra Andrew Miller). http://blockstream.com/sidechains.pdf Haven't seen any material discussion of this paper in this mailing

Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-11-03 Thread Alex Mizrahi
From the introduction [...]Because signers prove computational work, rather than proving secret knowledge as is typical for digital signatures, we refer to them as miners. To achieve stable consensus on the blockchain history, economic incentives are provided where miners are rewarded with

Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Alex Mizrahi
This thread is, in my opinion, a waste of time. It's yet again another perennial bikeshedding proposal brought up many times since at least 2011, suggesting random changes for non-existing(/not-yet-existing) issues. There is a lot more complexity to the system than the subsidy schedule.

[Bitcoin-development] death by halving

2014-10-25 Thread Alex Mizrahi
# Death by halving ## Summary If miner's income margin are less than 50% (which is a healthy situation when mining hardware is readily available), we might experience catastrophic loss of hashpower (and, more importantly, catastrophic loss of security) after reward halving. ## A simple model

Re: [Bitcoin-development] death by halving

2014-10-25 Thread Alex Mizrahi
For the sake of argument, lets assume that somehow (quite unlikely) Why is it unlikely? Do you believe that the cost of electricity cannot be higher than expected mining revenue? Or do you expect miners to keep mining when it costs them money? half the mining equipment gets shut off. The

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-06 Thread Alex Mizrahi
I've heard about this idea from TierNolan. Here's some quick an dirty analysis: Suppose the last known block claimed a large tx fee of L. A miner who owns 1/N of the total hashrate needs to choose between two strategies: 1. Mine on top of that block and win usual reward R with probability 1/N.

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-05 Thread Alex Mizrahi
A distinction there is that they can only become invalid via a conflict— replaced by another transaction authored by the prior signers. If no other transaction could be created (e.g. you're a multisigner and won't sign it again) then there is no such risk. You need to check transaction's

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-28 Thread Alex Mizrahi
I can't remember who I saw discussing this idea. Might have been Vitalik Buterin? Yes, he described it in an article a couple of months ago: http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ but it is an old idea. For example, I've mentioned punishment of this

Re: [Bitcoin-development] BIP - Hash Locked Transaction

2014-04-25 Thread Alex Mizrahi
It is also useful for betting: an oracle will associate a hash with each possible outcome, and when outcome is know, it will reveal a corresponding preimage which will unlock the transaction. This approach has several advantages over approach with multi-sig script: 1. oracle doesn't need to be

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Alex Mizrahi
This is outright ridiculous. Zero-confirmation double-spending is a small problem, and possible solutions are known. (E.g. trusted third party + multi-sig addresses for small-value transactions.) On the other hand, protocol changes like described above might have game-theoretical implications

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Alex Mizrahi
And it still would. Non-collusive miners cast votes based on the outcome of their own attempts to double spend. Individually rational strategy is to vote for coinbase reallocation on every block. Yes, in that case nobody will get reward. It is similar to prisoner's dilemma: equilibrium has

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Alex Mizrahi
These sorts of proposals are all just ways of saying block chains kind of suck and we should go back to using trusted third parties. No. Different approaches have different trade-offs, and thus different areas of applicability. Proof-of-work's inherent disadvantage is that it takes some time

Re: [Bitcoin-development] Feedback request: colored coins protocol

2014-04-10 Thread Alex Mizrahi
At this point, I don't think what you are doing is even colored coins anymore. You might want to look into Counterparty or Mastercoin. Nope, it's still colored coins. The difference between colored coin model and Mastercoin model is that colored coins are linked to transaction outputs, while

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Alex Mizrahi
1) It's more private. Bloom filters gives away quite accurate statistical information about what coins you own to whom ever you happen to be connected too. An attacker can easily use this to deanonymize you even if you don't reuse addresses; Tor does not help much against this attack. There