What about 0 confirmation inputs?
Mightn't this make tiny "spam" transactions unsafely inexpensive?
> On May 12, 2014, at 20:21, Peter Grigor wrote:
>
>
> I propose the transaction fee should be calculated from a percentage of the
> input amount divided by the confirmations of the input multi
This was originally submitted to the bitcoin github issue manager. I'm
re-posting here.
I propose the transaction fee should be calculated from a percentage of the
input amount divided by the confirmations of the input multiplied by the
number of inputs.
By using a percentage of the input amount
Just a thought. Using the payment protocol for stealth would mean we
would likely have to return to backing up wallets all the time would it not?
The nonces cannot be derived from your wallet seed and, since they
aren't in the blockchain, would have to be stored in your wallet. I
suppose they coul
>
> It sounds OK to me, although we should all sleep on it for a bit. The
> reason this header exists is exactly because mobile code fetching random
> web resources can result in surprising security holes.
>
That's fair. From the server perspective, I'd argue that payment requests /
payments alrea
On Mon, May 12, 2014 at 10:01 AM, Matt Whitlock wrote:
> Why is there such a high bar to getting a number assigned to a BIP anyway?
> BIP 1 seems to suggest that getting a BIP number assigned is no big deal, but
> the reality seems to betray that casual notion. Even proposals with hours of
> wo
On Monday, 12 May 2014, at 9:53 am, Gregory Maxwell wrote:
> I've noticed some folks struggling to attach labels to their yet to be
> numbered BIPs.
>
> I'd recommend people call them "draft-- does>" like draft-maxwell-coinburning in the style of pre-WG IETF
> drafts.
Why is there such a high bar
I've noticed some folks struggling to attach labels to their yet to be
numbered BIPs.
I'd recommend people call them "draft--" like draft-maxwell-coinburning in the style of pre-WG IETF
drafts.
--
"Accelerate Dev Cycles w
On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote:
> On Fri, May 9, 2014 at 8:13 PM, Peter Todd wrote:
> > I don't think we're going to find that's practical unfortunately due to
> > change. Every payment I make ties up txouts, so if we try to base the
> > atomicity of payments on whet
Sorry to run on, a correction is needed. A much better approximation
requires that the rule-following minority finds the next TWO blocks, so
the cost is
(total miner revenue of block)*(fraction of hashpower following the rule)^2
So the lower bound cost in this very pessimistic scenario is .002
A Java implementation of what is called BIPSS in lack of an official number
can be found here:
https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/crypto/BipSs.java
(passing all test vectors)
Which is based on a GF2^8 implementation here:
https://github.co
>
> Would it be a terrible idea to amend BIP 70 to suggest implementors
> include a "Access-Control-Allow-Origin: *" response header for their
> payment request responses? I don't think this opens up any useful attack
> vectors.
>
It sounds OK to me, although we should all sleep on it for a bit. T
11 matches
Mail list logo
