Chun Wang <1240902 gmail.com> writes:
> Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
FSS RBF is better than no RBF but we think it is better to use full RBF.
We think Full RBF is better for a number of reasons:
-user experience
-efficiency
-cost
-code complexity
We
Mike Hearn plan99.net> writes:
> It's the only way to keep a project making progress at a reasonable pace.
[SNIP]
If Bitcoin is managed with a linux kernel style dictator it would be
centralized (yet unlike linux, where people can fork without impacting others
in Bitcoin a hard fork puts at ri
Mike Hearn plan99.net> writes:
>
>
> I know you will ignore this as usual, but the entire replace-by-fee folly
is based on your fundamental misunderstanding of miner incentives.
I disagree, I think it is inevitable (but then of course I'm probably biased
and why wouldn't I disagree given I r
Andreas Schildbach schildbach.de> writes:
>
> What is the use of the Transactions message? Note the Payment message
> already contains a transactions field that could be signed. Can you
> briefly describe the whole flow of messages on an example, including the
> BIP70 messages?
Updated the BIP
Mike Hearn plan99.net> writes:
> As long as miners stick to Satoshi's first seen rule, which is the
default, it's useful:
>
>
> https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
>
>
>
>
> (this is the famous "snack machine" thread from 2010)
>
> If they decide to change to somet
Mike Hearn plan99.net> writes:
> Sure. I buy this. Although the credit card market is a great example of
what we don't want: a stagnant duopoly of trusted third parties who
rampantly abuse their position. So I'd hope we see either (a) nobody really
caring about this BIP because Bitcoin gives g
Mike Hearn plan99.net> writes:
> Actually Tom is running a page where he shows double spends detected by
his node or relayed by mine (there are only two nodes in this little
detection network currently), and it does show double spends that occur
seconds, minutes or even days apart.
I only mea
Mike Hearn plan99.net> writes:
> Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt miners (see bitundo) - can't be solved
this way.
I read the comments on the
Mike Hearn plan99.net> writes:
[snip]
> Daniel is right that putting every possible provider in the Payment
message might not scale in a world where there are huge numbers of instant-
confirmation providers, but I'm hoping that we never have to scale to that
size, because if we did that'd rather
Daniel Rice greenmangosystems.com> writes:
> If double spends are not resolved, there will be a million instant
providers in the long run and if double spends are resolved then this BIP
extension is completely unnecessary.
I am not sure if double spends can be resolved, at the moment they are
Andreas Schildbach schildbach.de> writes:
> Generally I like the simplicity of this BIP. Still, I have more questions:
>
> What is the use of the Transactions message? Note the Payment message
> already contains a transactions field that could be signed.
Transactions message sole purpose is
Andreas Schildbach schildbach.de> writes:
> Just a quick comment:
>
> The supports_instant field seems redundant to me. First, as per your
> spec, you can derive it from trusted_instant_providers. And second, why
> do you need it at all? Protobuf is designed so it will simply ignore
> fields yo
Hello,
I had the pleasure to meet some of you in Amsterdam and/or to speak on
#bitcoin-dev but this is actually my first message to the mailing list - I
feel a bit clumsy so apologies in advance if I make any mistake :)
Quick introduction/background: my name is Lawrence Nahum and I'm the
fo
13 matches
Mail list logo
