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
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:
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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
25 matches
Mail list logo
