On Thursday, October 24, 2013 5:29:18 PM thoma...@gmx.de wrote:
> I would like to propose a new BIP, that replaces BIP0039.
BIP 39 is still a draft. Just suggest revisions to the author(s)...
--
October Webinars: Code for
On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd wrote:
> Eligius has contracts to do transaction mining, and it's currently 10%
> of the hashing power.
>
Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
the answer is "a small percentage."
So: there are multiple layers of
On Thu, Oct 24, 2013 at 9:32 PM, Jorge Timón wrote:
> This will probably sound stupid to most of you, but I'll say it anyway.
>
> The aim of mnemonics is to easily remember, isn't it?
>
Well, I would say more "retype" than "remember". I really don't think that
common user will memorize it. But o
On Thu, Oct 24, 2013 at 9:23 PM, Pieter Wuille wrote:
>
> This is a proposal I wrote a year ago, but never spent enough work to
> push it as a standard:
> https://bitcointalk.org/index.php?topic=102349.0
>
>
I think that PoW concept in your proposal is quite smart! However the
problem that it isn't
Thanks Christian, this is a really interesting bit of history. My own
personal experience from when I wrote my own client and BCCAPI-ish server
was that the protocol specification on the Wiki was hugely valuable, and
rarely sent me astray. Supplement that with the occasional questions on
#b
This will probably sound stupid to most of you, but I'll say it anyway.
The aim of mnemonics is to easily remember, isn't it?
But the approach of removing "offensive words" is probably
counterproductive to achieving that end. These words cause a greater
emotional impact in our human moral psyches.
This is probably too late in the discussion, and I certainly don't
want to derail any standard being formed. But if it is controversial,
I want to offer my own suggestion.
This is a proposal I wrote a year ago, but never spent enough work to
push it as a standard:
https://bitcointalk.org/index.php
On Thu, Oct 24, 2013 at 7:29 PM, wrote:
>
> My initial problem was that BIP0039 is not backward compatible with
> Electrum. When trying to solve that, I realized that the seed encoding used
> in Electrum does not help, because it does not contain a version number
> information. However, BIP0039 su
We've reflected many comments about BIP39 wordlist from the community and I
think the wordlist is much better now. Specifically we removed many of
theoretically offensive words as well as we implemented algorithm for
detecting words with similar characters (cat/eat) and we resolved these
duplicitie
On Thu, Oct 24, 2013 at 7:29 PM, wrote:
>
> My initial problem was that BIP0039 is not backward compatible with
> Electrum. When trying to solve that, I realized that the seed encoding used
> in Electrum does not help, because it does not contain a version number
> information. However, BIP0039 s
I would like to propose a new BIP, that replaces BIP0039.
My initial problem was that BIP0039 is not backward compatible with Electrum.
When trying to solve that, I realized that the seed encoding used in Electrum
does not help, because it does not contain a version number information.
However,
On Thu, Oct 24, 2013 at 04:46:41PM +0200, Mike Hearn wrote:
> Well, miners are all supposed to be more or less equivalent - modulo
> differences in tx acceptance policies - so I'd hope that having out of bad
> fee mechanisms yet still broadcasting the TX isn't that common. If it was
> broadcasted,
Well, miners are all supposed to be more or less equivalent - modulo
differences in tx acceptance policies - so I'd hope that having out of bad
fee mechanisms yet still broadcasting the TX isn't that common. If it was
broadcasted, it should get mined in short order, otherwise things are going
wrong
On Thu, Oct 24, 2013 at 04:38:16PM +0200, Mike Hearn wrote:
> On Thu, Oct 24, 2013 at 4:30 PM, Peter Todd wrote:
>
> > Quick thought on how to make blockchain-based fee estimates work better
> > in the context of out-of-band mining contracts: have miners advertise in
> > their coinbase's what fee
On Thu, Oct 24, 2013 at 4:30 PM, Peter Todd wrote:
> Quick thought on how to make blockchain-based fee estimates work better
> in the context of out-of-band mining contracts: have miners advertise in
> their coinbase's what fees were actually paid, as opposed to appear to
> have been paid.
This
"DisconnectBlock() : outputs still spent? database corrupted"
If you can't get your node up and running and see the above in your
debug.log there's a potential fix available:
https://github.com/bitcoin/bitcoin/pull/3143
Be warned: highly rushed and poorly tested, so you're best to ask a dev
in I
Quick thought on how to make blockchain-based fee estimates work better
in the context of out-of-band mining contracts: have miners advertise in
their coinbase's what fees were actually paid, as opposed to appear to
have been paid.
The logic is very simple: we assume miners aren't an effective car
I've just pushed updated wordlist which is filtered to similar characters
taken from this matrix.
BIP39 now consider following character pairs as similar:
similar = (
('a', 'c'), ('a', 'e'), ('a', 'o'),
('b', 'd'), ('b', 'h'), ('b', 'p'), ('b', 'q'), ('b', 'r'),
I'd like to add some historical background about how the "protocol
specification" came to be in the first place.
A bit over three years [1] ago I started an attempt to document the
network protocol, by reverse engineering it from the satoshi
client. My goal, back then, was to enable like-minded en
Yes. I had pointed people in IRC to Knuth's literate programming, as
an example of how we might document bitcoin.
On Thu, Oct 24, 2013 at 3:03 AM, Martin Sustrik wrote:
> On 23/10/13 23:07, Pieter Wuille wrote:
>
>> In short,
>> consistency is more important than correctness.
>
> That's a nice
https://bitcoinfoundation.org/blog/?p=290
Very excited about this, particularly the 80 bytes embeddable message. I
do believe satoshi mentioned he wanted to add short messages, at some point.
Great work Gavin & all!
--
O
On 23/10/13 23:07, Pieter Wuille wrote:
> In short,
> consistency is more important than correctness.
That's a nice and concise way to put it and any potential protocol
documentation should start with a statement like that.
> However, I do not think that making it hard to find information about
22 matches
Mail list logo
