> 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
A lot of this discussion has already occured. Some code was even
merged into master, then reverted.
See:
https://github.com/bitcoin/bitcoin/issues/4550
https://github.com/bitcoin/bitcoin/pull/4570
It would probably be a good idea to start from that code, as it
addresses many of the possible pitfa
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 wrote:
>
>
> -
ion, as in
more bits for large payments).
On Fri, Sep 12, 2014 at 11:25 AM, Christophe Biocca
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
> 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
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 att
https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
of the pooling-centralization problems. Unfortunately, it is opt-in,
and GHash.io doesn't support it.
Also most miners don't care and don't do the work to set it up. To do
transaction inclusion themselves, they'd need to run a f
Here's the relevant github issue: https://github.com/bitcoin/bitcoin/issues/4069
On Fri, May 16, 2014 at 10:22 AM, David Shares 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 list, in case it hasn'
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 block,
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 ar
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 b
ut, because you've got a much
longer time frame than 10 minutes, you can get manual confirmation
from other miners.
On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd wrote:
> On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
>> Actually Peter, coinbase confiscations are
Actually Peter, coinbase confiscations are a much worse mechanism for
enforcement of widespread censorship rules than simple orphaning. They
lose their power when the transaction miners are punished for can
build up over time without losing their usefulness:
Assume a world where 75% of the hashpow
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
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
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
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 mo
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 l
2014 at 3:30 PM, Tim Tuxworth Founder Go-taxi.biz
wrote:
> Is BIP70 limited to http only?
>
> What about face to face scenarios, or realtime like ticket sales or
> gambling, and socket and/or bluetooth type connections?
>
> Tim Tuxworth
> Founder Go-Taxi.biz
>
>
> ---
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 u
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 unsi
> 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 sig
if they only 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 wrote:
>> Comments:
>>
>> bc:
>> - Ultimately, this helps with block propagation latency
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
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 de
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 don
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 w
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 wh
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
speci
29 matches
Mail list logo
