On 3/2/2016 12:53 PM, Gregory Maxwell via bitcoin-dev wrote:
> What you are proposing makes sense only if it was believed that a very
> large difficulty drop would be very likely.
>
> This appears to be almost certainly untrue-- consider-- look how long
> ago since hashrate was 50% of what it is
I think the next hard fork should require a safety rule for TX fees.
https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08
15 BTC TX fee for < 7 BTC of outputs.
Probably either a typo or client bug.
My guess is the user was using a client that does not adj
On Thu, March 3, 2016 10:02 am, Peter Todd via bitcoin-dev wrote:
> On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev
> wrote:
>> > A 6 month investment with 3 months on the high subsidy and 3 months on
>> low subsidy would not be madeâ¦
>>
>>
>>
>> Yes, this is the essential
It makes sense to me that there might be objective conditions under which
we would want to use a number smaller than 2016. A good example would be a
mean time between blocks of more than 20 minutes over the last 144 blocks
(one - two days). If such an occurrence ever happened, and the software
t
Hi,
I think there is no need to do a hardfork for this. Rather it should
be implemented as a safety-mechanism in the client. Perhaps a warning
can pop up, if one of your conditions A) or B) is met.
All the best
Henning Kopp
On Thu, Mar 03, 2016 at 05:02:11AM -0800, Alice Wonder via bitcoin-dev w
Hi
> My guess is the user was using a client that does not adjust TX fee, and
> needed to manually set it in order to get the TX in the block sooner,
> and meant 15 mBTC or something.
>
> I suggest that either :
>
> A) TX fee may not be larger than sum of outputs
> B) TX fee per byte may not be
On Thu, Mar 03, 2016 at 04:04:18PM +0100, Henning Kopp via bitcoin-dev wrote:
> Hi,
> I think there is no need to do a hardfork for this. Rather it should
> be implemented as a safety-mechanism in the client. Perhaps a warning
> can pop up, if one of your conditions A) or B) is met.
Bitcoin Core a
There's an absurd fee (non-consensus) check already. Maybe that check can
be improved, but probably the wallet layer is more appropriate for this.
On Mar 3, 2016 16:23, "Henning Kopp via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
> I think there is no need to do a hardfork
2016-03-03 16:28 GMT+01:00 Peter Todd via bitcoin-dev
:
> Bitcoin Core already implements this safety limit with the "absurd fee"
> limit of 1 * the minimum relay fee. This limit is active in both the
> wallet and the sendrawtransaction RPC call. Additionally for the wallet
> there is a user co
It would be a shame to prohibit someone from rewarding whoever mines their
transaction. A good example would be a transaction designed to record some
information which is damning to powerful authorities, sort of like the
service cryptograffiti offers. When we try to protect others by
prohibiting
On 03/02/2016 03:02 PM, Peter Todd wrote:
> On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev wrote:
>>> A 6 month investment with 3 months on the high subsidy and 3 months on low
>>> subsidy would not be made…
>>
>> Yes, this is the essential point. All capital investments ar
Since the root cause of what you are trying to address is the reward
having, I'd suggest considering an adjustment to the having schedule.
Instead of their being a large supply shock every four years, perhaps the
reward could drop every 52,500 blocks (yearly), or even at each difficulty
adjustment,
12 matches
Mail list logo
