quote:
[...]
> On 4/24/14, Chris Pacia wrote:
> > It would work but it's an ugly hack IMO. What do people do if they don't
> > have extra to pay when making a purchase? I have 200 mbtc and want to buy a
> > 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.
> >
> > I would much pref
Den 17 jun 2014 17:59 skrev "Isidor Zeuner" :
>
> quote:
> > Mike Hearn, why don't we just have all nodes report attempted double
spends
> > through the node network. No need to involve the miners at all really,
or
> > do your suggestion but also report the double spend attempt. By waiting
> > mayb
>
> I think that's true if you assume that the instant provider list is based
> on a by hand created list of accepted instant providers. That's how VISA
> works now and that's why I was asking for an approach where the
> trusted_instant_providers list is scalable because that seems very
> dangerous
> I'm not sure this is actually important or useful; trusting someone not
to double spend is a pretty binary thing
I think that's true if you assume that the instant provider list is based
on a by hand created list of accepted instant providers. That's how VISA
works now and that's why I was askin
>
> - allowing multiple signatures ?
I'm not sure this is actually important or useful; trusting someone not to
double spend is a pretty binary thing. I'm not sure saying "you need to get
three independent parties to sign off on this" is worth the hassle,
especially because the first signature is
RE: most of Peter Todd's comments:
All of that should be separate pull requests. Big Honking Pull Requests
are harder to review and are more likely to be bike-shedded to death.
RE: not relaying/mining transactions with OP_NOPs so miners don't mine
up-version transactions that are invalid under
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
On Wed, Jun 18, 2014 at 5:23 AM, Wladimir wrote:
> Anyhow -- back to the original proposal. I'm fine with setting aside
> part of the service bit space for experiments.
ACK
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd wrote:
> For my replace-by-fee implementation(1) I used service bit 26 to let
> preferential peering work so that replace-by-fee nodes could easily find
> each other. Of course, that's a temporary/experimental usage that can be
> dropped after wider adop
Please, let's talk about other anti-double spend things on a separate
thread.
On Tue, Jun 17, 2014 at 5:58 PM, Isidor Zeuner wrote:
> What prevents the following steps from happening:
>
I linked to Satoshi's post on this earlier, he explains why it works there,
assuming people follow the origin
On Tue, Jun 17, 2014 at 9:40 PM, Gavin Andresen
wrote:
> Assuming there is rough consensus, I'll make this a pull request (see
> https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
> changes).
>
>
>
> Now that we are finally starting to see the use of multi-signature a
11 matches
Mail list logo
