I'd suggest looking at how Dogecoin's mining schedule has worked out,
for how halvings tend to actually affect the market. Part of Dogecoin's
design was that it would halve very quickly (around every 75 days, in
fact), so it's essentially illustrating worst case scenario.
Firstly, miners do no
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, i
On 04/01/15 17:04, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll 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 D
On 04/01/15 17:35, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll wrote:
>> Grabbing a simple test case:
>> https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
>> - that won't lock until 0028 UTC on the 5th
On 04/01/15 17:44, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell 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 guess.
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 th
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 p
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 lea
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
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 shoul
I've got a few thoughts on this, but they don't really attach well to a
single message, so starting a fresh message in the same thread. I'm
going to try being brief.
There's a lot of talk about not forking. Sorry, but they're going to
happen, planned and unplanned. Even if no intentional forks
tlock 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
&
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 US-only
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:
BIP-0070:
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 PaymentReque
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 defaul
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?
F
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
wonderi
19 matches
Mail list logo
