Re: [Bitcoin-development] we can all relax now

2013-11-06 Thread Christophe Biocca
I might try building this sometime soon. I think it may also serve an educational purpose when trying to understand the whole network's behaviour. What level of accuracy are we looking for though? Obviously we need to fully emulate the steps of the network protocol, and we need to be able to

Re: [Bitcoin-development] Bitcoin Network Simulator

2013-11-17 Thread Christophe Biocca
Beat me to it. My own implementation is here: https://github.com/christophebiocca/bitcoin-network-simulator Same basic principles, but I've been following the protocol message structure as much as possible/Theoretical support for transaction propagation (I really want to see zero-conf stuff, and

Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees

2014-01-16 Thread Christophe Biocca
To clarify, there are proposals to make miners recognize this situation and account for it, only eligius is running it at the moment IIRC: http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-large-miners-running-child-pays-for-parent-patch Right now if you were to try it likely

Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)

2014-01-18 Thread Christophe Biocca
Like any other mechanism that puts extra data in the blockchain, the sender pays the fees. This mechanism is to improve privacy for static addresses (donation links on websites and so on). I personally don't think it will be used nearly as much as BIP0032 or the payment protocol (both of which

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Christophe Biocca
I remember the wordlist choice getting bikeshedded to death a month ago. I would just include the wordlist as part of the standard (as a recommendation) so that fully compliant implementations can correct a user's typos regardless of the original generator. Those who don't like it will have to

Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.

2014-01-22 Thread Christophe Biocca
Comments: bc: - Ultimately, this helps with block propagation latency, but not with the bandwidth constraints themselves, because all transactions do need to be broadcast. - Most of the benefits of your approach can be obtained simply by prebroadcasting the entire merkle tree while you're working

Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.

2014-01-22 Thread Christophe Biocca
receive the hashes of the transactions? Will they mine on top of a block when they don't know if it's valid? On 1/22/14, Christophe Biocca christophe.bio...@gmail.com wrote: Comments: bc: - Ultimately, this helps with block propagation latency, but not with the bandwidth constraints themselves

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-01-29 Thread Christophe Biocca
But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... If the only concern is to make scan-to-pay work without reliance on SSL's PKI, it might be better to specify the payment protocol url *and* the public key used for

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-31 Thread Christophe Biocca
The merchant can always act maliciously by simply not delivering the goods. The only recourse the payment protocol provides at that point is that you have proof the merchant is acting maliciously (or at the very least his payment system is broken). Your scheme just adds an ACK of the specific

Re: [Bitcoin-development] BIP70: Canceling Payments

2014-02-03 Thread Christophe Biocca
Over http, the merchant doesn't have the ability to reach out to the consumer's bitcoin wallet on their own. So sending Cancel Payment Request to the user is impossible. If the customer doesn't want to send, nothing ever needs to happen. So sending a Reject Payment Request to the merchant is

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

2014-02-25 Thread Christophe Biocca
Given the enormous number of variations on time periods for a recurring payment, might it be better to simple allow a list of timestamps? It costs almost nothing, bandwidth wise, and shifts the thinking to the merchant platform. That doesn't give you an infinite time frame, but you just get a new

Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Christophe Biocca
If you absolutely want a name for some small unit (which may be valuable, not knocking that part of the idea), please use anything other than bits, which is already a massively overloaded term that will confuse the hell out of people: Harddrive costs measured in bits per gigabyte? An itunes movie

Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Christophe Biocca
Culturally neutral? bit in French phonetically collides with slang for phallus (bitte, with a silent e). Apparently it means louse in Turkish as well. Not that this really would be avoidable with any short word (all the short possible words are usually taken), but it's not neutral. On Sun, Apr

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

2014-04-23 Thread Christophe Biocca
Just a few issues with the idea as it currently stands: 1. This provides a very strong incentive to always vote for reallocating a block if it isn't yours, regardless of whether it's bad or not (there's a positive expected return to voting to reallocate coinbases from other miners). The incentive

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

2014-04-23 Thread Christophe Biocca
It's not necessary that this coinbase retribution be either profitable or risk-free for this scheme to work. I think we should separate out the different layers of the proposal: 1. Attacking the coinbase instead of orphaning allows for 100 blocks' time for a consensus to be reached, rather than

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

2014-04-24 Thread Christophe Biocca
minutes, you can get manual confirmation from other miners. On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd p...@petertodd.org wrote: On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote: Actually Peter, coinbase confiscations are a much worse mechanism for enforcement of widespread

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

2014-04-26 Thread Christophe Biocca
This seems like splitting hairs, no? A block isn't a guarantee (it can get orphaned). And as a user of bitcoin (as opposed to a miner), this change cannot affect any payment you ever receive. Some of the interpretation is already different for coinbase UTXO's (need a valid height, locked for 100

Re: [Bitcoin-development] bits: Unit of account

2014-05-03 Thread Christophe Biocca
Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are

Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk

2014-05-03 Thread Christophe Biocca
Unfortunately this could fork the network permanently, which is much worse than a double spend. There's no magic way to have a consensus, so it becomes trivial with a few tries to split the network into two halves: (tx1 before tx2, tx2 before tx1). Some nodes in the middle will accept either

Re: [Bitcoin-development] Someone put a virus signature into the blockchain

2014-05-16 Thread Christophe Biocca
Here's the relevant github issue: https://github.com/bitcoin/bitcoin/issues/4069 On Fri, May 16, 2014 at 10:22 AM, David Shares davidsha...@outlook.com wrote: http://www.reddit.com/r/Bitcoin/comments/25otbt/someone_put_a_virus_signature_in_the_bitcoin/ I just wanted to pass this into the dev

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Christophe Biocca
If your threat model is passive listeners, it seems to me that simply establishing a symmetric key for each connection at handshake time using diffie-hellman is all you need. No public private crypto needed at all. The whole thing seems like a bit of security theater unfortunately. The kind of

Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Christophe Biocca
What hash function would you recommend? Due to the properties of hash functions, you can just take the first x bits of a SHA256 sum and they're pretty much as good as an equally secure hash function of that length. In fact SHA512/224 and SHA512/256 are defined in that way (Plus different initial

Re: [Bitcoin-development] BIP72 amendment proposal

2014-09-12 Thread Christophe Biocca
, as in more bits for large payments). On Fri, Sep 12, 2014 at 11:25 AM, Christophe Biocca christophe.bio...@gmail.com wrote: What hash function would you recommend? Due to the properties of hash functions, you can just take the first x bits of a SHA256 sum and they're pretty much as good as an equally

Re: [Bitcoin-development] From block 0 to block 72499 the Merkle root is the same as the coinbase transaction id. Why is that?

2014-09-20 Thread Christophe Biocca
1. Not all of them (just the ones that have a coinbase transaction and nothing else). 2. The merkle root of a tree with just one item is the hash of that item. On Sat, Sep 20, 2014 at 11:38 AM, Peter Grigor pe...@grigor.ws wrote:

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

2014-10-28 Thread Christophe Biocca
The fact that it is known in advance is no counter argument to me. But it does change miner behaviour in pretty significant ways. Unlike difficulty forecasting, which seems near impossible to do accurately, miners can plan to purchase less hardware as they approach the revenue drop. You can do