Dear Gavin, Andreas,
I'd see standardisation (or at least suggested standards) for error
handling as positive for consistency of user experience. I do see what
you mean about over-specification, however.
Thanks for the feedback, I've taken the main points and created two pull
requests:
I'd be very cautious of security implications of embedding files into
the payment request. Even file formats one would presume safe, such as
images, have had security issues (i.e.
https://technet.microsoft.com/library/security/ms11-006 )
Longer term I was wondering about embedding the
Dear all,
Still going through the payment protocol specifications... the MIME
types in BIP0071 aren't IANA registered, and honestly look unlikely to
be accepted if they were submitted as-is.
Latest RFC on media type registration is RFC 6838, which very strictly
restricts what can go in the
For what it's worth, there was consideration of replacing protocol
buffers when modifying BIP70 to function with the altcoin I work on
(changes were required anyway in eliminate any risk that payment
requests could not be accidentally applied to the wrong blockchain). The
eventual conclusion was
That was essentially what we did in the end, we replaced the network
identifier (main/test) with the genesis block hash. The result is
never going to accidentally work with Bitcoin Core (nor vice-versa), but
is readily extensible to any other altcoins that want to use the
specification without
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arriving slightly late to the discussion, apologies.
Personally I wouldn't have written that patch, but I know development of
hostile patches happens out of sight, and if it can be written, we have
to presume it will be written eventually. I'd have
Dear all,
I've been looking at atomic cross-chain trading (
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
Bitcoin and Dogecoin blockchains, and have a mostly functional
prototype. However as it stands if the refund transaction is relayed
before the actual spend transaction,
On 04/01/15 17:04, Gregory Maxwell wrote:
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk wrote:
Dear all,
I've been looking at atomic cross-chain trading (
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
Bitcoin and Dogecoin blockchains, and have a mostly
On 04/01/15 17:35, Gregory Maxwell wrote:
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll j...@jrn.me.uk wrote:
Grabbing a simple test case:
https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
- that won't lock until 0028 UTC on the 5th.
I've tried
On 04/01/15 17:44, Gregory Maxwell wrote:
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Can you send me the actual raw transaction (that site doesn't appear
have a way to get it, only some cooked json output; which doesn't
include the sequence number).
Nevermind,
I'm presuming that schedule is just an example, as you'd end up with
insanely large block sizes in a few years.
Absolutely, yes, an increase schedule is an option if people agree on
it, and I think the better option, as the current limit too low, but
jumping straight to a value big enough for
Can I just add my own support for this - as has been stated elsewhere in
this discussion, hard forks are difficult, and risky. The earlier we
have a decision, and the earlier the change goes into the code, the
easier that is.
Even if the decision was the actual block size change is fine to
I think potential fee subsidies for cleaning up UTXO (and/or penalties
for creating more UTXO than you burn) are worth thinking about. As
Gavin's post ( gavinandresen.ninja/utxo-uhoh ) indicates, UTXO cost is
far higher than block storage, so charging differently for the in/out
mismatches
wrote:
On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote:
I may disagree with Mike Gavin on timescale, but I do believe there's
a likelihood inaction will kill Bitcoin
An honest question: who is proposing inaction? I haven't seen anyone in this
whole, agonizing debate arguing that 1MB
I'm struggling to illustrate how incredibly low 7 transactions per
second is, not just for a payment network, but even just for a clearance
network (i.e. to balance transactions between institutions and/or
chains). As an example, the Clearing House Interbank Payments System
(CHIPS) is a
Dear Gavin, all,
Going over the payment protocol specifications, I've noticed that
there's appears to be a lack of specificity on handling of error states.
In most cases there are reasonably obvious solutions, however it would
seem positive to formalise processes to ensure consistency. I'm
The concern is that if you can monitor traffic in and out of a single
node, you can determine which transactions originate from it vs those
which it relays. That's not great, certainly, but how many nodes
actually require that level of security, and surely they can use Tor or
VPN services if so?
17 matches
Mail list logo
