On Fri, Dec 22, 2017 at 12:30 AM, Mark Friedenbach via bitcoin-dev
wrote:
> Every transaction is replace-by-fee capable already. Opt-in replace by fee
> as specified in BIP 125 is a fiction that held sway only while the income
> from fees or fee replacement was so much smaller than subsidy.
The d
Every transaction is replace-by-fee capable already. Opt-in replace by fee as
specified in BIP 125 is a fiction that held sway only while the income from
fees or fee replacement was so much smaller than subsidy.
> On Dec 21, 2017, at 3:35 PM, Paul Iverson via bitcoin-dev
> wrote:
>
> I agree
I agree with Greg. What is happening is a cause for celebration: it is the
manifestation of our long-desired fee market in action. That people are
willing to pay upwards of $100 per transaction shows the huge demand to
transact on the world's most secure ledger. This is what success looks
like, f
Hi,
This is the first time I post on this list.
First of all, Thank you Jameson for the interview you gave yesterday, it’s been
a model of calm and self-control for all of us.
I deeply believe the high average fees we experience right now are mostly due
to the miscalculations of most of the ha
Thank you... I've updated.
> New schemes should probably NOT be based on the current one.
Fair enough... I still think there are those who would still like an
existing sign/verify BIP to reference.
On Thu, Dec 21, 2017 at 5:09 PM, Luke Dashjr wrote:
> On Thursday 21 December 2017 10:26:25 PM D
On Thursday 21 December 2017 10:26:25 PM Dan Bryant via bitcoin-dev wrote:
> https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki
It's not even correct... Your first "verify message" step is not possible; you
can't get a public key from an address.
What is actually done, is
Personally, I'm pulling out the champaign that market behaviour is
indeed producing activity levels that can pay for security without
inflation, and also producing fee paying backlogs needed to stabilize
consensus progress as the subsidy declines.
I'd also personally prefer to pay lower fees-- cur
It seems that the exchanges are doing everything that they can to slow things.
Not only have the major exchanges not implemented segwit yet, but a bigger,
less addressed issue is that they have start applying transfer limits on crypto
as well as cash. They do not respond for months to requests t
https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki
Although this is a well established functionality, it has never been
published in a BIP. My proposal is simply to provide a reference point for
future expansion of these capabilities into new address schemes.
Original refe
legacy message sign verify BIP to get the ball rolling.
early draft:
https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki
On Tue, Dec 19, 2017 at 3:36 PM, Pavol Rusnak wrote:
> On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> > I know there are posts, and an issue ope
I'd hope that the incentives are in place to encourage high volume senders
to be more efficient in their use of block space by batching transactions
and implementing SegWit, though this may not be the case for providers that
pass transaction fees along to their users.
We've been trying to be more
I asked adam back at hcpp how the block chain would be secured in the long
term, once the reward goes away. The base idea has always been that fees
would replace the block reward.
At that time fees were approximately 10% of the block reward, but have now
reached 45%, with 50% potentially being cr
You might be interested in this proposal, which is very similar. The repo
contains a very basic implementation in typescript:
https://github.com/bitauth/bitauth2017/blob/master/bips/0-bitauth.mediawiki
https://github.com/bitauth/bitauth2017/
On Tue, Dec 19, 2017 at 4:59 PM Mark Friedenbach via bi
It doesn’t matter what it does under the hood. The api could be the same.
> On Dec 21, 2017, at 3:19 AM, Damian Williamson via bitcoin-dev
> wrote:
>
> In all seriousness, being able to sign a message is an important feature
> whether it is with Bitcoin Core or, with some other method. It is a
Just to clarify two points:
> The good part is that it does not have to be adopted by exchanges. If popular
> exchanges do not adopt it, it is trivial to make an adapter service which
> translate COX to whatever proprietary API of the exchange.
Be sure to elaborate on the difference in trust as
In all seriousness, being able to sign a message is an important feature
whether it is with Bitcoin Core or, with some other method. It is a good
feature and it would be worthwhile IMHO to update it for SegWit addresses. I
don't know about renewing it altogether, I like the current simplicity.
Thanks a lot for the feedback
> I think this could be quite useful, although I don’t know if it will get
adopted.
The good part is that it does not have to be adopted by exchanges. If
popular exchanges do not adopt it, it is trivial to make an adapter service
which translate COX to whatever propr
17 matches
Mail list logo
