* Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
@ 2016-07-01 3:25 99% ` Rusty Russell
2016-07-01 22:42 99% ` Zooko Wilcox
0 siblings, 1 reply; 42+ results
From: Rusty Russell @ 2016-07-01 3:25 UTC (permalink / raw)
To: Ethan Heilman, Bitcoin Protocol Discussion
Ethan Heilman <eth3rs@gmail•com> writes:
>>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). But that's probably just my crypto ignorance...
>
> SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of
> the length extension property of SHA256.
>
> If I have a tag y = SHA256(key|cipher-type|mesg), I can without
> knowing key or msg compute a value y' such that
> y' = SHA256(key|cipher-type|mesg|any values I want).
Not quite, there's an important subtlety that SHA256 appends the
bitlength, so you can only create:
y' = SHA256(key|cipher-type|mesg|padding|bitlength|any values I want).
But we're not using this for a MAC in BIP151, we're using this to
generate the encryption keys.
Arthur Chen <arthur.chen@btcc•com> said:
> HMAC has proven security property.
> It is still secure even when underlying crypto hashing function has
> collision resistant weakness.
> For example, MD5 is considered completely insecure now, but HMAC-MD5 is
> still considered secure.
> When in doubt, we should always use HMAC for MAC(Message Authentication
> Code) rather than custom construction
Bitcoin already relies on SHA256's robustness, but again, we don't need
a MAC here.
I'm happy to buy "we just copied ssh" if that's the answer, and I can't
see anything wrong with using HMAC here, it just seems odd...
Thanks!
Rusty.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
2016-07-01 3:25 99% ` Rusty Russell
@ 2016-07-01 22:42 99% ` Zooko Wilcox
2016-07-04 1:23 99% ` Arthur Chen
2016-07-04 6:37 99% ` Jonas Schnelli
0 siblings, 2 replies; 42+ results
From: Zooko Wilcox @ 2016-07-01 22:42 UTC (permalink / raw)
To: Rusty Russell, Bitcoin Protocol Discussion
I haven't been able to find the beginning of this thread, so apologies
if I've misunderstood what this is for, but it _sounds_ like we're
re-inventing HKDF.
I'd recommend reading the paper about HKDF. It stands out among crypto
papers for having a nice clear justification for each of its design
decisions, so you can see why they did it (very slightly) differently
than the various constructions proposed up-thread.
https://eprint.iacr.org/2010/264
Also, of course, it is a great idea to re-use a standard
(https://tools.ietf.org/html/rfc5869) and widely-understood crypto
algorithm to reduce risk of both cryptographer errors and implementor
errors.
Of course, the cost of that is the you sometimes end up computing
something that is a tiny bit more complicated or inefficient than a
custom algorithm for our current use case. IMHO that's a cheap price
to pay.
Regards,
Zooko
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 151
@ 2016-07-02 9:44 99% ` Chris Priest
0 siblings, 0 replies; 42+ results
From: Chris Priest @ 2016-07-02 9:44 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion
On 6/30/16, Erik Aronesty via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> I would like to see a PGP-like "web of trust" proposal for both the
> security of the bitcoin network itself /and/ (eventually) of things like
> transmission of bitcoin addresses.
>
> Something where nodes of any kind (full, spv, mobile wallets) can
> /optionally/ accumulate trust over time and are capable of verifying the
> identity of other nodes in that web.
>
Isn't the system already functioning in this way already? Bitcoin
exchanges and block explorers already have a reputation earned by so
many years of serving the community. Their HTTPS certificate acts like
a public/private key, and when your wallet makes a request to their
server, the keys are automatically checked for validity by the
underlying http library.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd
@ 2016-07-02 18:43 99% ` Peter Todd
2016-07-02 19:20 99% ` Johnson Lau
0 siblings, 1 reply; 42+ results
From: Peter Todd @ 2016-07-02 18:43 UTC (permalink / raw)
To: Johnson Lau, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5204 bytes --]
On Wed, Jun 29, 2016 at 12:22:45AM +0800, Johnson Lau via bitcoin-dev wrote:
> Thanks for Peter Todd’s detailed report:
> https://petertodd.org/2016/segwit-consensus-critical-code-review
>
> I have the following response.
>
> >Since the reserve value is only a single, 32-byte value, we’re setting ourselves up for the same problem again7.
>
> Please note that unlimited space has been reserved after the witness commitment:
>
> block.vtx[0].vout[o].scriptPubKey.size() >= 38
>
> Which means anything after 38 bytes has no consensus meaning. Any new consensus critical commitments/metadata could be put there. Anyway, there is no efficient way to add a new commitment with softfork.
Sure - equally you could say you could add additional commitments as other
coinbase txouts.
My point is that the extensible commitment - specifically the thing described
in the BIP - can't be easily used for the purpose of extending segwit due to a
design flaw.
> > the fact that we do this has a rather odd result: a transaction spending a witness output with an unknown version is valid even if the transaction doesn’t have any witnesses!
>
> I don’t see any reason to have such check. We simply leave unknown witness program as any-one-can-spend without looking at the witness, as described in BIP141.
It will lead to a special case in code that does things with witness
transactions, as we can spend a witness output without a witness.
> > Bizzarely segwit has an additonal pay-to-witness-pubkey-hashP2WPKH that lets you use a 160-bit (20 byte) commitment……
>
> Since ~90% of current transactions are P2PKH, we expect many people will keep using this type of transaction in the future. P2WPKH gives the same level of security as P2PKH, and smaller scriptPubKey.
>
> >give users the option instead to choose to accept the less secure 160-bit commitment if their use-case doesn’t need the full 256-bit security level
>
> This is actually discussed on the mailing list. P2WSH with multi-sig is subject to birthday attack, and therefore 256-bit is used to provide 128-bit security. P2WPKH is used as single sig and therefore 160-bit is enough.
I'm aware of that - there are many P2SH scripts where birthday attacks are not
an issue. In fact, _most_ usage of P2SH right now - multifactor wallets -
doesn't have a birthday attack problem.
> >Secondly, if you are going to give a 160-bit commitment option, you don’t need the extra level of indirection in the P2SH case: just make the segwit redeemScript be: <version> <serialized witness script>
>
> Something wrong here? In P2WPKH, the witness is <sig> <pubkey>
Huh? That still another level of indirection.
Anyway, the right argument against my proposal for pay-to-pubkey-hash
functionality, is that taking into account the witness discount, my proposal is
slightly less efficient. In P2WPKH in P2SH the witness program in the
redeemScript is 22 bytes:
<1-byte version> <1-byte length> <20 byte pubkey hash>
And the witness len(sig) + 34 bytes:
<sig> <1 byte length> <33 bytes pubkey>
Taking into account the discount, that results in 22*4 + 34 + len(sig) = 122 bytes + len(sig)
My proposal would have a 37 byte redeemScript:
<1-byte version> <1-byte witness script length> {<1-byte pubkey length> <33 byte pubkey> OP_CHECKSIG}
and a len(sig) length witness:
<sig>
Taking into account the discount, that results in 37*4 + len(sig) = 148 bytes + len(sig)
Meanwhile for any more complex script, you'd certainly want to use the 256-bit
hash instead, due to the witness discount.
This suggests an obvious alternative: let users choose to use 160-bit security,
and make 256-bit and 160-bit witness programm commitments just be different
hash functions. P2PKH functionality implemented this way would be a single
extra byte vs. special-casing it.
Thus you could summarize the argument for the P2PKH special case as "We don't
want to make it possible to use 160-bit commitments for multisig, which _might_
need 256-bit security. But we do want to special-case pubkeys to save a few
bytes."
> >The only downside is the serialized witness script is constrained to 520 bytes max
>
> 520 is the original limit. BIP141 tries to mimic the existing behaviour as much as possible. Anyway, normally nothing in the current scripts should use a push with more than 75 bytes
No, you're quite confused at my point: the witness script is otherwise
constrained to 10,000 bytes, as the first item in the witness is special-cased
for version 0 to be not be subject to the 520 byte rule.
> >we haven’t explicitly ensured that signatures for the new signature hash can’t be reused for the old signature hash
>
> How could that be? That’d be a hash collision.
Nope. The problem is it might not be a hash collission, if the actual bytes
signed can be interpreted in two different ways, by different types of
signature hashes.
This is the same reason the signmessage functionality prepends the message
being signed with the "Bitcoin Signed Message:\n" magic string.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd
2016-07-02 18:43 99% ` Peter Todd
@ 2016-07-02 19:20 99% ` Johnson Lau
2016-07-04 23:27 99% ` Peter Todd
0 siblings, 1 reply; 42+ results
From: Johnson Lau @ 2016-07-02 19:20 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
>
>>> the fact that we do this has a rather odd result: a transaction spending a witness output with an unknown version is valid even if the transaction doesn’t have any witnesses!
>>
>> I don’t see any reason to have such check. We simply leave unknown witness program as any-one-can-spend without looking at the witness, as described in BIP141.
>
> It will lead to a special case in code that does things with witness
> transactions, as we can spend a witness output without a witness.
It is trivial to softfork a new rule to require the witness must not be empty for a witness output. However, does it really make the code simpler?
>
> Thus you could summarize the argument for the P2PKH special case as "We don't
> want to make it possible to use 160-bit commitments for multisig, which _might_
> need 256-bit security. But we do want to special-case pubkeys to save a few
> bytes.”
Actually I would like to see even shorter hash and pubkey to be used. Storing 1 BTC for a few months does not really require the security level of P2PKH.
>
>>> we haven’t explicitly ensured that signatures for the new signature hash can’t be reused for the old signature hash
>>
>> How could that be? That’d be a hash collision.
>
> Nope. The problem is it might not be a hash collission, if the actual bytes
> signed can be interpreted in two different ways, by different types of
> signature hashes.
>
> This is the same reason the signmessage functionality prepends the message
> being signed with the "Bitcoin Signed Message:\n" magic string.
>
In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes (hashPrevouts) is a hash of all prevouts. (in the case of ANYONECANPAY, the bytes following would be zero, as you proposed)
In the original sig, first 4 bytes in nVersion, next 4 bytes is number of inputs, and the next 32 bytes is a txid.
For a signature to be valid for both schemes, the last 28 bytes of the hashPrevouts must also be the first 28 bytes of a valid txid. This is already impossible. And this is just one of the many collisions required. In such case SHA256 would be insecure and adding a zero after the nVersion as you suggest would not be helpful at all.
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 671 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
2016-07-01 22:42 99% ` Zooko Wilcox
@ 2016-07-04 1:23 99% ` Arthur Chen
2016-07-04 1:44 99% ` Arthur Chen
2016-07-04 6:37 99% ` Jonas Schnelli
1 sibling, 1 reply; 42+ results
From: Arthur Chen @ 2016-07-04 1:23 UTC (permalink / raw)
To: Zooko Wilcox, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]
I strongly agree!
In crypto we should always follow well-studied open standard rather than
custom construction.
On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I haven't been able to find the beginning of this thread, so apologies
> if I've misunderstood what this is for, but it _sounds_ like we're
> re-inventing HKDF.
>
> I'd recommend reading the paper about HKDF. It stands out among crypto
> papers for having a nice clear justification for each of its design
> decisions, so you can see why they did it (very slightly) differently
> than the various constructions proposed up-thread.
>
> https://eprint.iacr.org/2010/264
>
> Also, of course, it is a great idea to re-use a standard
> (https://tools.ietf.org/html/rfc5869) and widely-understood crypto
> algorithm to reduce risk of both cryptographer errors and implementor
> errors.
>
> Of course, the cost of that is the you sometimes end up computing
> something that is a tiny bit more complicated or inefficient than a
> custom algorithm for our current use case. IMHO that's a cheap price
> to pay.
>
> Regards,
>
> Zooko
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC
[-- Attachment #2: Type: text/html, Size: 2375 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
2016-07-04 1:23 99% ` Arthur Chen
@ 2016-07-04 1:44 99% ` Arthur Chen
2016-07-04 6:47 99% ` Jonas Schnelli
0 siblings, 1 reply; 42+ results
From: Arthur Chen @ 2016-07-04 1:44 UTC (permalink / raw)
To: Zooko Wilcox, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign
On Mon, Jul 4, 2016 at 1:23 AM, Arthur Chen <arthur.chen@btcc•com> wrote:
> I strongly agree!
> In crypto we should always follow well-studied open standard rather than
> custom construction.
>
> On Fri, Jul 1, 2016 at 10:42 PM, Zooko Wilcox via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> I haven't been able to find the beginning of this thread, so apologies
>> if I've misunderstood what this is for, but it _sounds_ like we're
>> re-inventing HKDF.
>>
>> I'd recommend reading the paper about HKDF. It stands out among crypto
>> papers for having a nice clear justification for each of its design
>> decisions, so you can see why they did it (very slightly) differently
>> than the various constructions proposed up-thread.
>>
>> https://eprint.iacr.org/2010/264
>>
>> Also, of course, it is a great idea to re-use a standard
>> (https://tools.ietf.org/html/rfc5869) and widely-understood crypto
>> algorithm to reduce risk of both cryptographer errors and implementor
>> errors.
>>
>> Of course, the cost of that is the you sometimes end up computing
>> something that is a tiny bit more complicated or inefficient than a
>> custom algorithm for our current use case. IMHO that's a cheap price
>> to pay.
>>
>> Regards,
>>
>> Zooko
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Xuesong (Arthur) Chen
> Senior Principle Engineer
> BlockChain Technologist
> BTCC
>
--
Xuesong (Arthur) Chen
Senior Principle Engineer
BlockChain Technologist
BTCC
[-- Attachment #2: Type: text/html, Size: 3157 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
2016-07-01 22:42 99% ` Zooko Wilcox
2016-07-04 1:23 99% ` Arthur Chen
@ 2016-07-04 6:37 99% ` Jonas Schnelli
1 sibling, 0 replies; 42+ results
From: Jonas Schnelli @ 2016-07-04 6:37 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 702 bytes --]
> I haven't been able to find the beginning of this thread, so apologies
> if I've misunderstood what this is for, but it _sounds_ like we're
> re-inventing HKDF.
> I'd recommend reading the paper about HKDF. It stands out among crypto
> papers for having a nice clear justification for each of its design
> decisions, so you can see why they did it (very slightly) differently
> than the various constructions proposed up-thread.
Thanks Zooko
I think HKDF instead of a single HMAC_SHA512 seams reasonable and
something we should consider.
I'll try to evaluate the implications of using HKDF over HMAC_SHA512 and
will update the BIP if there are no concerns about it.
</jonas>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
2016-07-04 1:44 99% ` Arthur Chen
@ 2016-07-04 6:47 99% ` Jonas Schnelli
0 siblings, 0 replies; 42+ results
From: Jonas Schnelli @ 2016-07-04 6:47 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 329 bytes --]
Hi Arthur
>
> I strongly agree!
> In crypto we should always follow well-studied open standard rather
> than custom construction.
I totally agree.
BIP151 does not introduce new cipher types.
The BIP uses ECDH together with ChaCha20-Poly1305@openssh.
Both very well known and broad used crypo.
/jonas
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd
2016-07-02 19:20 99% ` Johnson Lau
@ 2016-07-04 23:27 99% ` Peter Todd
0 siblings, 0 replies; 42+ results
From: Peter Todd @ 2016-07-04 23:27 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]
On Sun, Jul 03, 2016 at 03:20:42AM +0800, Johnson Lau wrote:
> >>> the fact that we do this has a rather odd result: a transaction spending a witness output with an unknown version is valid even if the transaction doesn’t have any witnesses!
> >>
> >> I don’t see any reason to have such check. We simply leave unknown witness program as any-one-can-spend without looking at the witness, as described in BIP141.
> >
> > It will lead to a special case in code that does things with witness
> > transactions, as we can spend a witness output without a witness.
>
> It is trivial to softfork a new rule to require the witness must not be empty for a witness output. However, does it really make the code simpler?
The Bitcoin Core codebase, no, but it does reduce the number of special cases
other codebases have to contend with.
Probably not worth changing now, but it was I think a weird design choice to
make.
> > Thus you could summarize the argument for the P2PKH special case as "We don't
> > want to make it possible to use 160-bit commitments for multisig, which _might_
> > need 256-bit security. But we do want to special-case pubkeys to save a few
> > bytes.”
>
> Actually I would like to see even shorter hash and pubkey to be used. Storing 1 BTC for a few months does not really require the security level of P2PKH.
How short? 128 bits? 80 bits? 64 bits?
It's hard to know what's the point where you're going to risk massive losses
due to theft... and as we've seen with the DAO, those kinds of losses can lead
to very undesirable pressure for devs to act as a central authority and
intervene.
> >>> we haven’t explicitly ensured that signatures for the new signature hash can’t be reused for the old signature hash
> >>
> >> How could that be? That’d be a hash collision.
> >
> > Nope. The problem is it might not be a hash collission, if the actual bytes
> > signed can be interpreted in two different ways, by different types of
> > signature hashes.
> >
> > This is the same reason the signmessage functionality prepends the message
> > being signed with the "Bitcoin Signed Message:\n" magic string.
> >
>
> In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes (hashPrevouts) is a hash of all prevouts. (in the case of ANYONECANPAY, the bytes following would be zero, as you proposed)
>
> In the original sig, first 4 bytes in nVersion, next 4 bytes is number of inputs, and the next 32 bytes is a txid.
>
> For a signature to be valid for both schemes, the last 28 bytes of the hashPrevouts must also be the first 28 bytes of a valid txid. This is already impossible. And this is just one of the many collisions required. In such case SHA256 would be insecure and adding a zero after the nVersion as you suggest would not be helpful at all.
Why isn't this carefully documented in the BIPs then?
Again, as I said in my summary:
In a number of places we either have a belt, or suspenders, when given the
importance of this code we’d rather have both a belt and suspenders.
Tagged hashing is an excellent way to absolutely sure that signatures can't be
reused in different contexts; if it happens to be overkill in a specific
context, the overhead of hashing another few bytes is trivial; the gain of
being absolutely sure you haven't missed a vulnerability can't be easily
dismissed.
Equally, I think in most cases simply XORing the digest obtained by hashing
with a magic tag prior to using it (e.g. by signing it) should be sufficient
for signature applications, and the overhead of doing that is ~zero.
Essentially you can think of the magic tag that's XORed with the raw digest as
making clear the intent of the signature: "this is why I think I'm signing this
digest"
However, the XOR option does have one potentially big downside in other
contexts, like general use in committed data structures: it's incompatible with
timestamping schemes like OpenTimestamps that rely on all operations being
cryptographically secure.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP Number Request: Open Asset
@ 2016-07-05 17:46 99% ` Peter Todd
2016-07-06 1:22 99% ` Luke Dashjr
0 siblings, 1 reply; 42+ results
From: Peter Todd @ 2016-07-05 17:46 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion; +Cc: Nicolas Dorier
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote:
> > Author: Flavien Charlon <flavien@charlon•net>
What's the status of this BIP? Will it be assigned?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP Number Request: Open Asset
2016-07-05 17:46 99% ` Peter Todd
@ 2016-07-06 1:22 99% ` Luke Dashjr
2016-07-06 2:14 99% ` James MacWhyte
0 siblings, 1 reply; 42+ results
From: Luke Dashjr @ 2016-07-06 1:22 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion, Nicolas Dorier
On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
> On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev wrote:
> > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev wrote:
> > > Author: Flavien Charlon <flavien@charlon•net>
>
> What's the status of this BIP? Will it be assigned?
I was waiting for clarification on the Author thing, but Nicholas hasn't
responded yet. I am unaware of any reason NOT to assign it, and there appear
to be no objections, so let's call it BIP 160.
Luke
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP Number Request: Open Asset
2016-07-06 1:22 99% ` Luke Dashjr
@ 2016-07-06 2:14 99% ` James MacWhyte
2016-07-06 6:49 99% ` Alex Mizrahi
0 siblings, 1 reply; 42+ results
From: James MacWhyte @ 2016-07-06 2:14 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion, Peter Todd; +Cc: Nicolas Dorier
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
I'm curious to hear the answers to the questions Luke asked earlier. I also
read through the documentation and wasn't convinced it was thought out well
enough to actually build something on top of, but there's no reason it
can't get a number as a work-in-progress.
I hope it does continue to get worked on, though. The lack of response or
discussion worries me that it might become an abandoned project.
On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
> > On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev
> wrote:
> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
> wrote:
> > > > Author: Flavien Charlon <flavien@charlon•net>
> >
> > What's the status of this BIP? Will it be assigned?
>
> I was waiting for clarification on the Author thing, but Nicholas hasn't
> responded yet. I am unaware of any reason NOT to assign it, and there
> appear
> to be no objections, so let's call it BIP 160.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1866 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP Number Request: Open Asset
2016-07-06 2:14 99% ` James MacWhyte
@ 2016-07-06 6:49 99% ` Alex Mizrahi
0 siblings, 0 replies; 42+ results
From: Alex Mizrahi @ 2016-07-06 6:49 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of,
>
There are many colored coin protocols in use. OpenAssets is probably the
most popular one, but it has many critical flaws IMHO.
https://github.com/bitcoinx/colored-coin-tools/wiki/OpenAssets-deficiencies
> but there's no reason it can't get a number as a work-in-progress.
>
The protocol is not a work-in-progress, it is already in use, you cannot
change it without breaking stuff.
The doc can be improved, though. There is a lot of fluff but the actual
important stuff gets just few ambiguous sentences.
I hope it does continue to get worked on, though. The lack of response or
> discussion worries me that it might become an abandoned project.
>
The original author, Flavien, have abandoned it, he now does a private
blockchain thing, OpenChain.
There are others who still use OpenAssets, e.g. Nicolas, but the protocol
can't be changed.
There are other colored coin protocols in existence/in development, though.
[-- Attachment #2: Type: text/html, Size: 2020 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113
@ 2016-07-15 16:08 99% Luke Dashjr
2016-07-15 16:31 99% ` Peter Todd
0 siblings, 1 reply; 42+ results
From: Luke Dashjr @ 2016-07-15 16:08 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Daniel Cousens opened the issue a few weeks ago, that BIP 9 should progress to
Accepted stage. However, as an informational BIP, it is not entirely clear on
whether it falls in the Draft/Accepted/Final classification of proposals
requiring implementation, or the Draft/Active classification like process
BIPs. Background of this discussion is at:
https://github.com/bitcoin/bips/pull/413
(Discussion on the GitHub BIPs repo is *NOT* recommended, hence bringing this
topic to the mailing list)
Reviewing the criteria for status changes, my opinion is that:
- BIPs 68, 112, 113, and 141 are themselves implementations of BIP 9
-- therefore, BIP 9 falls under the Draft/Accepted/Final class
- BIPs 68, 112, and 113 have been deployed to the network successfully
-- therefore, BIP 9 has satisfied the conditions of not only Accepted status,
but also Final status
-- therefore, BIPs 68, 112, and 113 also ought to be Final status
If there are no objections, I plan to update the status to Final for BIPs 9,
68, 112, and 113 in one month. Since all four BIPs are currently Draft, I also
need at least one author from each BIP to sign-off on promoting them to (and
beyond) Accepted.
BIP 9: Pieter Wuille <pieter.wuille@gmail•com>
Peter Todd <pete@petertodd•org>
Greg Maxwell <greg@xiph•org>
Rusty Russell <rusty@rustcorp•com.au>
BIP 68: Mark Friedenbach <mark@friedenbach•org>
BtcDrak <btcdrak@gmail•com>
Nicolas Dorier <nicolas.dorier@gmail•com>
kinoshitajona <kinoshitajona@gmail•com>
BIP 112: BtcDrak <btcdrak@gmail•com>
Mark Friedenbach <mark@friedenbach•org>
Eric Lombrozo <elombrozo@gmail•com>
BIP 113: Thomas Kerin <me@thomaskerin•io>
Mark Friedenbach <mark@friedenbach•org>
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113
2016-07-15 16:08 99% [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113 Luke Dashjr
@ 2016-07-15 16:31 99% ` Peter Todd
0 siblings, 0 replies; 42+ results
From: Peter Todd @ 2016-07-15 16:31 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]
On Fri, Jul 15, 2016 at 04:08:51PM +0000, Luke Dashjr via bitcoin-dev wrote:
> Daniel Cousens opened the issue a few weeks ago, that BIP 9 should progress to
> Accepted stage. However, as an informational BIP, it is not entirely clear on
> whether it falls in the Draft/Accepted/Final classification of proposals
> requiring implementation, or the Draft/Active classification like process
> BIPs. Background of this discussion is at:
> https://github.com/bitcoin/bips/pull/413
> (Discussion on the GitHub BIPs repo is *NOT* recommended, hence bringing this
> topic to the mailing list)
As of writing the text of BIP68 says:
'This BIP is to be deployed by "versionbits" BIP9 using bit 0.'
Essentially including BIP9 as part of the BIP68 standard; BIP68 could have
equally been written by including some or all of the text of BIP9. If it had
done that, that text would be part of a "Standard BIP" rather than
"Informational BIP", thus I'll argue that BIP9 should also be a "Standard BIP"
Also, note that if we ever modified BIP9, we'd most likely do so with a new
BIP, and in soft-forks using that new standard, would refer to the new BIP #.
> Reviewing the criteria for status changes, my opinion is that:
> - BIPs 68, 112, 113, and 141 are themselves implementations of BIP 9
> -- therefore, BIP 9 falls under the Draft/Accepted/Final class
> - BIPs 68, 112, and 113 have been deployed to the network successfully
> -- therefore, BIP 9 has satisfied the conditions of not only Accepted status,
> but also Final status
> -- therefore, BIPs 68, 112, and 113 also ought to be Final status
>
> If there are no objections, I plan to update the status to Final for BIPs 9,
> 68, 112, and 113 in one month. Since all four BIPs are currently Draft, I also
> need at least one author from each BIP to sign-off on promoting them to (and
> beyond) Accepted.
>
> BIP 9: Pieter Wuille <pieter.wuille@gmail•com>
> Peter Todd <pete@petertodd•org>
> Greg Maxwell <greg@xiph•org>
> Rusty Russell <rusty@rustcorp•com.au>
ACK "Final" status.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Merkle trees and mountain ranges
@ 2016-07-15 23:00 99% ` Bram Cohen
0 siblings, 0 replies; 42+ results
From: Bram Cohen @ 2016-07-15 23:00 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4273 bytes --]
On Sat, Jun 18, 2016 at 4:01 PM, Peter Todd <pete@petertodd•org> wrote:
>
>
Have you seen how BLAKE2 omits padding when the data to be hashed happens
> to be
> exactly one block in size? It's significantly faster than SHA256, and
> that's a
> standard part of the algorithm already.
>
That's very convenient! I didn't know it, but had 'look up how blake2 does
padding' in my list of stuff to do. I'm leaning heavily towards using
blake2b at this point, at least for internal hashing.
>
> > At the root there's a branch block. It consists of all nodes up to some
> > fixed depth - let's say 12 - with that depth set so that it roughly fits
> > within a single memory page. Branch blocks are arranged with the nodes in
> > fixed position defined by the prefix they correspond to, and the
> terminals
> > have outpointers to other blocks. Because they're all clustered
> together, a
> > lookup or update will only require a single
>
> A single....?
>
Okay, I've figured out the root cause of general confusion here. It's
mostly my fault.
There are a few different media on which data can be stored, with different
properties in terms of how long it takes to retrieve data from them, and
how much of a readahead they typically have. I was misreading the l2 cache
size as the main memory readahead amount, which is... probably wrong? The
readahead properties of memory aren't well documented and apparently vary a
lot. On SSDs it typically pulls down a kilobyte at once and they call them
pages, hence my use of that term above. But since my real point is that my
implementation should act as a silver bullet which can have acceptable
performance even on extremely bad devices, I'll give an analysis of how
well it works when everything is stored on a regular spinning hard drive.
Let's say you're storing 100 million items, which will fit within 10
gigabytes. If you set the block depths to about 10 bits they'll be about
32K, and if you set the size of leaf blocks to be about the same then
memory efficiency will be good because the leaf blocks will store twigs of
about 2^7 in size while having 2^10 space so they'll fit reasonably. Almost
everything will be three blocks from root, so updates will generally
require two disk seeks (plus one more for a write but those are generally
faster because they get batched.)
For latency numbers, I'm going off these:
https://gist.github.com/jboner/2841832
If the blockchain is very full of simple transactions and a disk seek takes
15 milliseconds, then going with the assumption that a block is about 600
seconds and the blockchain can handle 4 transactions per second and each of
them is 3 updates (one utxo spent plus two new ones created) that's 15 *
600 * 4 * 3 * 2 milliseconds per block, or about 200 seconds per block, so
if the uxto roots trail by a few blocks even a ludicrously underpowered
node could keep up.
On an SSD keeping up is completely trivial, the problem becomes one of how
quickly you can validate an entire blockchain history. There a read takes
about 0.15 milliseconds and you have to do 5 of them instead of 2 because
the natural memory block size is 4k, so it's about 1 millisecond per
update, or 600 * 4 * 3 total time for each block, which is about 7 seconds.
That's large enough that making the utxo root trail by two blocks is still
a good idea, but small enough that it isn't a big factor in the cost of
running a node. It's enough that validating a complete block history might
take a while though, and even validating just the last year would take a
few days. This is very conservative and it's assuming that *everything* is
kept on an SSD though. If the numbers work better and a few layers are kept
in regular memory validating a whole year of history might only take a few
hours.
Hopefully that all makes a fairly good case that raw merkle tree utxo root
trailing by a few blocks is a viable strategy. The data structures in the
MMR proposal are fairly complicated and the analysis of them talks in
somewhat vague terms about things being fast and slow. A similar analysis
of the MMR proposal specifying storage media and expectations of latency
numbers would clarify the reasoning a lot.
(By the way, sorry for the slow response - I got preempted by a bunch of
other work duties.)
[-- Attachment #2: Type: text/html, Size: 5665 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP draft: HTLC transactions
@ 2016-07-20 4:35 99% Sean Bowe
2016-07-20 5:46 99% ` Peter Todd
0 siblings, 1 reply; 42+ results
From: Sean Bowe @ 2016-07-20 4:35 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions
in Bitcoin.
HTLC transactions allow you to pay for the preimage of a hash. CSV/CLTV can
be used to recover your funds if the other party is not cooperative. These
scripts take the following general form:
[HASHOP] <digest> OP_EQUAL
OP_IF
<seller pubkey>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP <buyer pubkey>
OP_ENDIF
OP_CHECKSIG
These transactions are useful for both the Lightning network and in
zero-knowledge contingent payments. This very script (using CLTV and
SHA256) was used as part of our "pay-to-sudoku" ZKCP demo earlier this
year: https://github.com/zcash/pay-to-sudoku
Members of the community have expressed the desire for a BIP to submitted
in coordination with changes to Bitcoin Core that support these
transactions in the wallet.
Please review my draft BIP here:
https://gist.github.com/ebfull/8306903041d46e4119a39442f72a3741
An implementation is being worked on here:
https://github.com/bitcoin/bitcoin/pull/7601
Thanks!
Sean Bowe
Zcash
[-- Attachment #2: Type: text/html, Size: 1632 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP draft: HTLC transactions
2016-07-20 4:35 99% [bitcoin-dev] BIP draft: HTLC transactions Sean Bowe
@ 2016-07-20 5:46 99% ` Peter Todd
2016-07-20 6:17 99% ` Luke Dashjr
0 siblings, 1 reply; 42+ results
From: Peter Todd @ 2016-07-20 5:46 UTC (permalink / raw)
To: Sean Bowe, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote:
> I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions
> in Bitcoin.
>
> HTLC transactions allow you to pay for the preimage of a hash. CSV/CLTV can
> be used to recover your funds if the other party is not cooperative. These
> scripts take the following general form:
>
> [HASHOP] <digest> OP_EQUAL
> OP_IF
> <seller pubkey>
> OP_ELSE
> <num> [TIMEOUTOP] OP_DROP <buyer pubkey>
> OP_ENDIF
> OP_CHECKSIG
Note that because you're hashing the top item on the stack regardless
scriptSig's that satisfy HTLC's are malleable: that top stack item can be
changed anything in the digest-not-provided case and the script still passes.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP draft: HTLC transactions
2016-07-20 5:46 99% ` Peter Todd
@ 2016-07-20 6:17 99% ` Luke Dashjr
0 siblings, 0 replies; 42+ results
From: Luke Dashjr @ 2016-07-20 6:17 UTC (permalink / raw)
To: bitcoin-dev, Peter Todd
On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote:
> On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote:
> > I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions
> > in Bitcoin.
> >
> > HTLC transactions allow you to pay for the preimage of a hash. CSV/CLTV
> > can be used to recover your funds if the other party is not cooperative.
> > These
> >
> > scripts take the following general form:
> > [HASHOP] <digest> OP_EQUAL
> > OP_IF
> >
> > <seller pubkey>
> >
> > OP_ELSE
> >
> > <num> [TIMEOUTOP] OP_DROP <buyer pubkey>
> >
> > OP_ENDIF
> > OP_CHECKSIG
>
> Note that because you're hashing the top item on the stack regardless
> scriptSig's that satisfy HTLC's are malleable: that top stack item can be
> changed anything in the digest-not-provided case and the script still
> passes.
OP_SIZE
OP_IF
[HASHOP] <digest> OP_EQUALVERIFY
<seller pubkey>
OP_ELSE
<num> [TIMEOUTOP]
<buyer pubkey>
OP_ENDIF
OP_CHECKSIG
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Bitcoin Core 0.13.0 release candidate 1 available
@ 2016-07-20 8:07 99% Wladimir J. van der Laan
0 siblings, 0 replies; 42+ results
From: Wladimir J. van der Laan @ 2016-07-20 8:07 UTC (permalink / raw)
To: bitcoin-dev, bitcoin-core-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Binaries for bitcoin Core version 0.13.0rc1 are available from:
https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc1/
Source code can be found on github under the signed tag
https://github.com/bitcoin/bitcoin/tree/v0.13.0rc1
This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.
Preliminary release notes for the release can be found at
https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes.md
Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.13.0.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJXjzAsAAoJEHSBCwEjRsmmv48IALAQw9GTDt63ST9dWBdlB1uz
9JOxIZLsd/u9lcBUMzUoLRsdYVu/OTJKoDDD1vE6YmtO+FLEYJgqKjkaIE1AzxD+
kwKP4KemZEsbk/e+eywZB1MKHvLyYY/W31k5kjQm8iDNNQs+1jJEfvgaZzdLBA2L
vKRPYg7P+maBWa7m6LjoUZFvjXfZ6eu80QjsH6ujM3aObQOmcAM1bgOCDH7sqzH8
ckgyUJlSWzJyTgdKEUapMoHdCiHyb7axZHAICIsOR7DPVsLc1oiAmxAfyKJvKIhm
0hclCziCu6I38dVqbAFcuwHaTD/dgyN92lanoB67XxExY1y+IP1RW5qc2Bt+wew=
=RJAl
-----END PGP SIGNATURE-----
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Reasons to add sync flags to Bitcoin
@ 2016-07-26 12:47 99% Moral Agent
2016-07-26 13:51 99% ` Tom
` (2 more replies)
0 siblings, 3 replies; 42+ results
From: Moral Agent @ 2016-07-26 12:47 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 8353 bytes --]
I posted this to /r/bitcoin yesterday but it got minimal comments. One uses
suggested I try the mailing list so here it is:
The idea presented here could have the following benefits:
1. Improve mining decentralization
2. Reduce variance in mining profitability
3. Reduce or eliminate SPV mined blocks
4. Reduce or eliminate empty blocks, smoothing out resource usage
5. Reduce or eliminate the latency bottleneck on throughput
6. Make transaction stuffing by miners be either obvious or costly
7. Gives miners something to do while they wait for attractive transactions
to appear
8. Can be easily done with a soft fork
#Basic idea:
Ideally, all miners would begin hashing the next block at exactly the same
time. Miners with a head start are more profitable, and the techniques that
help miners receive and validate blocks quickly create centralization
pressure.
What if there was something that acted like the starting flag at a race,
which could suddenly wave and cause all of the miners to simultaneously
begin hashing the next block?
#Implementation:
Let a sync flag be a message consisting of:
1. Hash of the previous block.
2. Bitcoin address
3. Nonce
This tiny message could propagate through the network at maximum speed. If
miners had to include the hash of this flag in the next block, then all
miners wait for this flag, and when it suddenly spread through the network,
all miners could simultaneously begin hashing the next block.
The sync flag should not be produced too quickly. You want to give everyone
enough time to be ready to hash the next block. Let's say that the hash of
the sync flag is a proof of work that is targeted for 2 minutes.
To fund this proof of work, the protocol is modified to demand that the
block produced 10 blocks after the sync flag must allocate 25% of the block
reward to the address published by the sync flag. In this way, sync flags
are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
minutes total.
Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)
Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png
#Explanation of reasons:
**Improve mining decentralization**
One factor driving centralization is the imperative miners have to achieve
low latency in receiving and validating blocks. To achieve low latency, it
helps a lot if you have expensive low-latency internet connections, curated
network topologies, and large pools that have a plausible chance of finding
consecutive blocks. If miners are expected (or forced) to validate a block
prior to mining on top of it, the rational end game would be to outsource
the validation step to a trusted third party specialist who can choose
optimal locations on the globe to serve their (multiple?) mining pool
clients. These are all less decentralized than the mining situation Satoshi
and others imagined.
**Reduce variance in mining revenue**
Currently, there are about 144 opportunities per day for a pool or solo
miner to see any revenue at all. With sync flags, that number doubles to
288. Sync flags are only worth 25% of what a block is worth, but this still
represents a significant reduction in variance. This variance is one factor
causing solo miners to group into pools, and large pools to be more
attractive than small pools.
**Reduce or eliminate SPV mined blocks**
One way miners have sought to make
full-block-transmission-and-validation-latency irrelevant has been through
"SPV" mining or "Head-first" mining. There is some evidence that these
techniques may be widely used, and that badgering the miners about it is an
ineffective strategy to stop them.
In SPV mining, a miner would simply accept any block header that shows the
correct proof of work. All other validation is entrusted to other miners.
This practice is quite dangerous as the SPV miners can wander off on some
invalid chain, taking SPV nodes with them. If this occurs during a soft
fork, these blind miners can also fool unupgraded fully validating nodes
into following them.
"Head-first" mining means that miners start hashing as soon as they receive
the block header with the correct POW, but they simultaneously validate the
block, and abandon it if is not valid. I consider this to be pretty safe,
as it strictly limits the length of an invalid chain that can result from
mining without validating. However, "Head-first" mining can plausibly
generate 2 or 3 confirmations of an invalid block. It would be nice if such
confirmations did not happen.
The sync flag technique is similar to head-first mining, but rather than
hashing the next block while they wait for transmission and validation of
the prior block, they hash the sync flag. Nodes can differentiate between
sync flags and blocks, and can ignore sync flags when counting
confirmations.
**Reduce or eliminate empty blocks, smoothing out resource usage**
Empty blocks are another consequence of SPV or Headfirst mining, because
the miner cannot safely include any transactions in the block they are
hashing until they have validated the prior block. By delaying the start of
hashing the next block until after validation, miners would not have this
reason to mine empty blocks.
**Reduce or eliminate the latency bottleneck on throughput**
Centralization pressure due to latency issues has been a major
preoccupation over the last year. If latency mattered much less, it could
represent a scalability improvement that could enable higher throughput.
**Make transaction stuffing by miners be either obvious or costly**
Currently, the entire block reward goes to the miner who mines it. One
unfortunate consequence of this is that it does not cost the miner anything
to covertly stuff the block with transactions. These transactions would pay
fees and be indistinguishable from ordinary transactions, but the fees are
paid by the miner and then immediately returned to the miner.
With sync flags, the miner must share these transaction fees with the
address contained in the sync flag 10 blocks prior. This means that if the
miner gives the transactions a normal looking fee, they will incur a cost
that will be paid to the sync flag. If the miner wants to avoid this, they
must give their stuffing transactions a zero fee, which provides evidence
that they are stuffing.
Also, when miners stuff with transactions using a zero fee, they cannot
manipulate the perception of how much fee it takes to get into a block.
Note that miners could still try to covertly stuff blocks that will pay a
sync flag that they themselves created. if this is a big concern, it can be
addressed by forcing blocks to pay multiple sync flags.
**Gives miners something to do while they wait for attractive transactions
to appear**
From the Montreal scaling workshop last year, we have [this talk](
https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf)
which worried that as the block subsidy reduced and transactions became a
more important fraction of miner revenue, it would be rational for miners
to turn off their mining equipment for a "gap" phase after a block is
found, to allow time to pass as more lucrative transactions entered the
mempool.
I don't know whether this will actually happen. The presence of a suitable
backlog of transactions would help prevent this dynamic from emerging. But
if such idling behavior was the optima mining strategy, it could create a
serious vulnerability. Idle hands are the devil's workshop as the saying
goes, and idle miners represent a pool of inert hashpower that is available
to rent for all kinds of destabilizing purposes. It would be better to put
those miners to profitable work mining a sync flag while they wait.
Also, this creates a more efficient price discovery mechanism for
transactions, because you allow transactions paying high fees time to
arrive to the marketplace, rather than take whatever anyone is offering
because all the "good" transactions got gobbled up in the prior block.
**Can be easily done with a soft fork**
Although a hard fork would be more efficient, sync flags could be easily
implemented using a soft fork by introducing the following rule:
Every block must include a transaction which pays 25% of the block reward
to the address given by the 10th previous sync flag, and commits to the
hash of the 1st previous sync flag.
[-- Attachment #2: Type: text/html, Size: 9745 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
2016-07-26 12:47 99% [bitcoin-dev] Reasons to add sync flags to Bitcoin Moral Agent
@ 2016-07-26 13:51 99% ` Tom
2016-07-26 17:27 99% ` Erik Aronesty
2016-07-26 22:03 99% ` Nick ODell
2016-07-28 16:41 99% ` Moral Agent
2 siblings, 1 reply; 42+ results
From: Tom @ 2016-07-26 13:51 UTC (permalink / raw)
To: bitcoin-dev, Moral Agent
> #Basic idea:
>
> Ideally, all miners would begin hashing the next block at exactly the same
> time. Miners with a head start are more profitable, and the techniques that
> help miners receive and validate blocks quickly create centralization
> pressure.
>
> What if there was something that acted like the starting flag at a race,
> which could suddenly wave and cause all of the miners to simultaneously
> begin hashing the next block?
>
> #Implementation:
>
> Let a sync flag be a message consisting of:
>
> 1. Hash of the previous block.
> 2. Bitcoin address
> 3. Nonce
>
> This tiny message could propagate through the network at maximum speed. If
> miners had to include the hash of this flag in the next block, then all
> miners wait for this flag, and when it suddenly spread through the network,
> all miners could simultaneously begin hashing the next block.
What you describe in this part of your message can be done with no forks
whatsoever and I think that this is enough. Don't really see the reason for
any change in funding.
The idea of sending out a block header is essentially what I called
"optimistic mining" and has been described in more detail in my blog here;
http://zander.github.io/posts/Innovation%20-%20OnlineScaling/
The video explains with graphics too...
You may find this interesting :)
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
2016-07-26 13:51 99% ` Tom
@ 2016-07-26 17:27 99% ` Erik Aronesty
0 siblings, 0 replies; 42+ results
From: Erik Aronesty @ 2016-07-26 17:27 UTC (permalink / raw)
To: Tom, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]
- Flags will be mined selfishly, and not published until the advantage
gained from withholding is less than the mining reward. This effect may
kill the decentralization features, since big miners will be the only ones
that can selfish-mine flags. Indeed, collusion would be encouraged... just
ship the flag to the miners you do business with, and no one else. At the
expense of loss of flag revenue, your in-group would gain a massive
advantage in main-chain mining.
On Tue, Jul 26, 2016 at 9:51 AM, Tom via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> > #Basic idea:
> >
> > Ideally, all miners would begin hashing the next block at exactly the
> same
> > time. Miners with a head start are more profitable, and the techniques
> that
> > help miners receive and validate blocks quickly create centralization
> > pressure.
> >
> > What if there was something that acted like the starting flag at a race,
> > which could suddenly wave and cause all of the miners to simultaneously
> > begin hashing the next block?
> >
> > #Implementation:
> >
> > Let a sync flag be a message consisting of:
> >
> > 1. Hash of the previous block.
> > 2. Bitcoin address
> > 3. Nonce
> >
> > This tiny message could propagate through the network at maximum speed.
> If
> > miners had to include the hash of this flag in the next block, then all
> > miners wait for this flag, and when it suddenly spread through the
> network,
> > all miners could simultaneously begin hashing the next block.
>
> What you describe in this part of your message can be done with no forks
> whatsoever and I think that this is enough. Don't really see the reason for
> any change in funding.
>
> The idea of sending out a block header is essentially what I called
> "optimistic mining" and has been described in more detail in my blog here;
> http://zander.github.io/posts/Innovation%20-%20OnlineScaling/
>
> The video explains with graphics too...
>
> You may find this interesting :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3007 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP proposal: derived mnemonics
@ 2016-07-26 18:31 99% millibitcoin
2016-07-26 20:10 99% ` Jonas Schnelli
0 siblings, 1 reply; 42+ results
From: millibitcoin @ 2016-07-26 18:31 UTC (permalink / raw)
To: bitcoin-dev
(not sure so sent again after subscribing (one use case added))
Dear Bitcoin developers,
Below is provided a draft BIP proposal for a master mnemonic sentence
from which other mnemonics sentences can be derived in a deterministic
non-reversible way (on an offline computer). This would make it much
easier to split funds into smaller fractions and use those in a
HD-wallet when appropriate (just by inserting 12 or more words), without
ever putting the master mnemonic at risk on an online computer. But
there are many more use cases.
A reference implementation, specifically for use with a Trezor, has been
generated and can be found at:
http://thebitcoinecosystem.info/DerivedMnemonics.html
I'm not a professional programmer or cryptographer, so the idea and
reference implementation will probably need a lot of reviewing but I do
think Bitcoin needs this extension and the corresponding ease of use and
improved security model.
In the hope you like the idea,
Regards,
sumBTC
<pre>
BIP: ???
Title: Derived mnemonics from a master mnemonic.
Author: sumBTC <millibitcoins@gmail•com>
Status: For Discussion
Type:
Created: 2016-07-24
</pre>
==Abstract==
This BIP??? uses a master mnemonic sentence, as described in BIP39, for
the deterministic generation of derived mnemonic sentences. The derived
mnemonics are of the same format as the master mnemonic but can consist
of a higher or lower number of words.
Binary seeds can then be generated for derived mnemonics (and master
mnemonic) as described in BIP39. Each of these seeds can be used to
generate deterministic wallets using BIP-0032 or similar methods.
==Motivation==
A mnemonic code or sentence is superior for human interaction as
described in BIP39 and can, for example, be written on paper or even
memorized. However, once a mnemonic has been used online, even through
the use of a hardware wallet, the mnemonic could be compromised. This
should be considered a bad practice from a security standpoint.
We therefore propose the generation of a master mnemonic offline and
from this generate (also offline) multiple derived mnemonics in a
deterministic way for online use. The master mnemonic is never used
online and the master mnemonic cannot be obtained from the derived
mnemonics. Examples of use cases are described below.
==Generating the master mnemonic==
The master mnemonic is first derived as a standard mnemonic as described
in BIP39.
==From master mnemonic to derived mnemonics==
From the master mnemonic a new string is created:
string = MasterMnemonic + " " + Count + " " + Strength;
Here, MasterMnemonic are the space separated words of the master
mnemonic. Count = 0, 1, 2 denotes the different derived mnemonics of a
given strength and Strength = numWords / 3 * 32, where numWords is the
number of words desired for the derived mnemonic and only integer
arithmetic is used in the calculation (e.g. for numWords = 14, Strength
= 128). Both Count and Strength are converted to strings.
This string is then hashed using sha512:
hash = sha512(string);
and turned into a byte array:
for (var i=0; i<strength/8; i++) {
byteArray[i] = (hash[Math.floor((i%64)/4)] >>> ((i%4)*8)) & 0b11111111;
}
This byte array is then used to generate a new mnemonic as shown in the
reference implementation using the method described in BIP39. The core
of the new code in the reference manual can be found by jumping to
"start: new code" in the reference software.
A passphrase for the master mnemonic has the same effect on the derived
mnemoncis (so must be included).
==Reference Implementation==
The reference implementation generates addresses based on BIP44 for a 24
word master mnemonic and is available from
http://thebitcoinecosystem.info/DerivedMnemonics.html
or
github (not yet)
==Checking the derived mnemonics using Electrum==
The displayed addresses in each of the reference implementations can be
easily checked using Electrum in the following manner:
move the directory ~/.electrum to a backup directory.
start Electrum and choose:
Restore a wallet or import keys
Hardware wallet
Restore Electum wallet from device seed words
TREZOR wallet
Insert one of the mnemonics and check that the same addresses are
generated by Electrum
Check the private keys:
move the directory ~/.electrum to a backup directory.
start Electrum and choose:
Restore a wallet or import keys
Standard wallet
Import one of the private keys and check that the correct address has
been generated.
Some checks should include a passphrase.
==Examples of Use Cases==
A person with 25 bitcoin splits funds using 5 derived mnemonics and
sends 5 bitcoins to the first address of each derived mnemonic. He can
then use a (hardware) HD-wallet and simply insert one of the derived
mnemonics to put only 5 bitcoins online and at risk at once. All funds
can be recovered from the master mnemonic.
A person wants to give 10 bitcoin to each of his family members, giving
each participant a derived mnemonic and sending bitcoin to each of them.
The donating person can always recover the derived mnemonic if one of
his family members loses his derived mnemonic.
For his Trezor wallet, someone wants to memorize only a 12 words master
seed but wants to insert a 24 words derived seed so a key logger on his
computer has 24! possibilities to check and not 12! (not a possibility
for the current reference implementation but trivial to add).
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal: derived mnemonics
2016-07-26 18:31 99% [bitcoin-dev] BIP proposal: derived mnemonics millibitcoin
@ 2016-07-26 20:10 99% ` Jonas Schnelli
2016-07-27 10:39 99% ` Jochen Hoenicke
0 siblings, 1 reply; 42+ results
From: Jonas Schnelli @ 2016-07-26 20:10 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 1956 bytes --]
Hi
> ==Generating the master mnemonic==
>
> The master mnemonic is first derived as a standard mnemonic as described
> in BIP39.
> ==From master mnemonic to derived mnemonics==
>
> From the master mnemonic a new string is created:
>
> string = MasterMnemonic + " " + Count + " " + Strength;
>
> Here, MasterMnemonic are the space separated words of the master
> mnemonic. Count = 0, 1, 2 denotes the different derived mnemonics of a
> given strength and Strength = numWords / 3 * 32, where numWords is the
> number of words desired for the derived mnemonic and only integer
> arithmetic is used in the calculation (e.g. for numWords = 14, Strength
> = 128). Both Count and Strength are converted to strings.
>
> This string is then hashed using sha512:
>
> hash = sha512(string);
1)
My humble cryptographic understanding tells me that you should probably
use sha512_hmac where you add an passphrase and a salt.
2)
Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I
personally consider "not enough" to protect a serious amount of funds.
Also the checksum based on the predetermined wordlist has some security
downsides over using a plain 32byte entropy (64hex chars) or a
base58check encoded extended private master key.
3)
Another idea:
What would speak against deriving a child key after bip32, lets say at
m/88'/0'/n' and use the derived 256bits to encode your mnemonic?
This would at least require your master mnemonic passphrase to derive a
valid "child mnemonic".
4)
I'm still not convinced if we should encourage users to "only store and
backup" the bip39 mnemonic.
Reconstructing funds from a seed can be difficult especially if you
don't have access to a trusted TX-indexed full node (~150GB of data
required).
Novice users might also underestimate the risk of losing metadata
coupled with their transactions when they only store the wallet seed.
</jonas>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Reasons to add sync flags to Bitcoin
@ 2016-07-26 20:58 99% Martijn Meijering
2016-07-26 21:45 99% ` Tier Nolan
0 siblings, 1 reply; 42+ results
From: Martijn Meijering @ 2016-07-26 20:58 UTC (permalink / raw)
To: bitcoin-dev
- Flags will be mined selfishly, and not published until the advantage
gained from withholding is less than the mining reward. This effect may
kill the decentralization features, since big miners will be the only ones
that can selfish-mine flags. Indeed, collusion would be encouraged... just
ship the flag to the miners you do business with, and no one else. At the
expense of loss of flag revenue, your in-group would gain a massive
advantage in main-chain mining.
---
Is there a reason miners would be more likely to engage in selfish
mining of sync flags than they are now with ordinary blocks?
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
2016-07-26 20:58 99% [bitcoin-dev] Reasons to add sync flags to Bitcoin Martijn Meijering
@ 2016-07-26 21:45 99% ` Tier Nolan
0 siblings, 0 replies; 42+ results
From: Tier Nolan @ 2016-07-26 21:45 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]
On Tue, Jul 26, 2016 at 9:58 PM, Martijn Meijering via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Is there a reason miners would be more likely to engage in selfish
> mining of sync flags than they are now with ordinary blocks?
>
This proposal has the same effect as adding mandatory empty blocks.
POW targeted at 2 minutes means that the POW for the flag is 25% of the
block POW. That gives a flag every 2 minutes and a block every 8 minutes.
It has the feature that the conversion rate from hashing power to reward is
the same for the flags and the blocks. A flag get 25% of the reward for
25% of the effort.
A soft fork to add this rule would have a disadvantage relative to a
competing chain. It would divert 20% of its hashing power to the flag
blocks, which would be ignored by legacy nodes. The soft fork would need
55% of the hashing power to win the race.
This isn't that big a deal if a 75% activation threshold is used. It might
be worth bumping it up to 80% in that case.
This rule would mean that headers first clients would have to download more
information to verify the longest chain. If they only download the
headers, they are missing 20% of the POW.
[-- Attachment #2: Type: text/html, Size: 1639 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
2016-07-26 12:47 99% [bitcoin-dev] Reasons to add sync flags to Bitcoin Moral Agent
2016-07-26 13:51 99% ` Tom
@ 2016-07-26 22:03 99% ` Nick ODell
2016-07-27 14:42 99% ` Moral Agent
2016-07-28 16:41 99% ` Moral Agent
2 siblings, 1 reply; 42+ results
From: Nick ODell @ 2016-07-26 22:03 UTC (permalink / raw)
To: Moral Agent, Bitcoin Protocol Discussion
Moral,
Mining the sync flag isn't compatible with the payout structure of non
hot-wallet pools like Eligius or decentralized pools like p2pool.
Those need the ability to split a reward among multiple parties.
Instead of giving an address to send the funds to, you could include
the hash of the transaction allowed to spend the sync flag output.
You'd have to zero the previous outpoint of the transaction before
hashing, since you don't know what the hash of the coinbase ten blocks
from now will be.
On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I posted this to /r/bitcoin yesterday but it got minimal comments. One uses
> suggested I try the mailing list so here it is:
>
> The idea presented here could have the following benefits:
>
> 1. Improve mining decentralization
> 2. Reduce variance in mining profitability
> 3. Reduce or eliminate SPV mined blocks
> 4. Reduce or eliminate empty blocks, smoothing out resource usage
> 5. Reduce or eliminate the latency bottleneck on throughput
> 6. Make transaction stuffing by miners be either obvious or costly
> 7. Gives miners something to do while they wait for attractive transactions
> to appear
> 8. Can be easily done with a soft fork
>
> #Basic idea:
>
> Ideally, all miners would begin hashing the next block at exactly the same
> time. Miners with a head start are more profitable, and the techniques that
> help miners receive and validate blocks quickly create centralization
> pressure.
>
> What if there was something that acted like the starting flag at a race,
> which could suddenly wave and cause all of the miners to simultaneously
> begin hashing the next block?
>
> #Implementation:
>
> Let a sync flag be a message consisting of:
>
> 1. Hash of the previous block.
> 2. Bitcoin address
> 3. Nonce
>
> This tiny message could propagate through the network at maximum speed. If
> miners had to include the hash of this flag in the next block, then all
> miners wait for this flag, and when it suddenly spread through the network,
> all miners could simultaneously begin hashing the next block.
>
> The sync flag should not be produced too quickly. You want to give everyone
> enough time to be ready to hash the next block. Let's say that the hash of
> the sync flag is a proof of work that is targeted for 2 minutes.
>
> To fund this proof of work, the protocol is modified to demand that the
> block produced 10 blocks after the sync flag must allocate 25% of the block
> reward to the address published by the sync flag. In this way, sync flags
> are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
> minutes total.
>
>
> Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)
>
> Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png
>
>
> #Explanation of reasons:
>
> **Improve mining decentralization**
>
> One factor driving centralization is the imperative miners have to achieve
> low latency in receiving and validating blocks. To achieve low latency, it
> helps a lot if you have expensive low-latency internet connections, curated
> network topologies, and large pools that have a plausible chance of finding
> consecutive blocks. If miners are expected (or forced) to validate a block
> prior to mining on top of it, the rational end game would be to outsource
> the validation step to a trusted third party specialist who can choose
> optimal locations on the globe to serve their (multiple?) mining pool
> clients. These are all less decentralized than the mining situation Satoshi
> and others imagined.
>
> **Reduce variance in mining revenue**
>
> Currently, there are about 144 opportunities per day for a pool or solo
> miner to see any revenue at all. With sync flags, that number doubles to
> 288. Sync flags are only worth 25% of what a block is worth, but this still
> represents a significant reduction in variance. This variance is one factor
> causing solo miners to group into pools, and large pools to be more
> attractive than small pools.
>
> **Reduce or eliminate SPV mined blocks**
>
> One way miners have sought to make
> full-block-transmission-and-validation-latency irrelevant has been through
> "SPV" mining or "Head-first" mining. There is some evidence that these
> techniques may be widely used, and that badgering the miners about it is an
> ineffective strategy to stop them.
>
> In SPV mining, a miner would simply accept any block header that shows the
> correct proof of work. All other validation is entrusted to other miners.
> This practice is quite dangerous as the SPV miners can wander off on some
> invalid chain, taking SPV nodes with them. If this occurs during a soft
> fork, these blind miners can also fool unupgraded fully validating nodes
> into following them.
>
> "Head-first" mining means that miners start hashing as soon as they receive
> the block header with the correct POW, but they simultaneously validate the
> block, and abandon it if is not valid. I consider this to be pretty safe, as
> it strictly limits the length of an invalid chain that can result from
> mining without validating. However, "Head-first" mining can plausibly
> generate 2 or 3 confirmations of an invalid block. It would be nice if such
> confirmations did not happen.
>
> The sync flag technique is similar to head-first mining, but rather than
> hashing the next block while they wait for transmission and validation of
> the prior block, they hash the sync flag. Nodes can differentiate between
> sync flags and blocks, and can ignore sync flags when counting
> confirmations.
>
> **Reduce or eliminate empty blocks, smoothing out resource usage**
>
> Empty blocks are another consequence of SPV or Headfirst mining, because the
> miner cannot safely include any transactions in the block they are hashing
> until they have validated the prior block. By delaying the start of hashing
> the next block until after validation, miners would not have this reason to
> mine empty blocks.
>
> **Reduce or eliminate the latency bottleneck on throughput**
>
> Centralization pressure due to latency issues has been a major preoccupation
> over the last year. If latency mattered much less, it could represent a
> scalability improvement that could enable higher throughput.
>
> **Make transaction stuffing by miners be either obvious or costly**
>
> Currently, the entire block reward goes to the miner who mines it. One
> unfortunate consequence of this is that it does not cost the miner anything
> to covertly stuff the block with transactions. These transactions would pay
> fees and be indistinguishable from ordinary transactions, but the fees are
> paid by the miner and then immediately returned to the miner.
>
> With sync flags, the miner must share these transaction fees with the
> address contained in the sync flag 10 blocks prior. This means that if the
> miner gives the transactions a normal looking fee, they will incur a cost
> that will be paid to the sync flag. If the miner wants to avoid this, they
> must give their stuffing transactions a zero fee, which provides evidence
> that they are stuffing.
>
> Also, when miners stuff with transactions using a zero fee, they cannot
> manipulate the perception of how much fee it takes to get into a block.
>
> Note that miners could still try to covertly stuff blocks that will pay a
> sync flag that they themselves created. if this is a big concern, it can be
> addressed by forcing blocks to pay multiple sync flags.
>
> **Gives miners something to do while they wait for attractive transactions
> to appear**
>
> From the Montreal scaling workshop last year, we have [this
> talk](https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf)
> which worried that as the block subsidy reduced and transactions became a
> more important fraction of miner revenue, it would be rational for miners to
> turn off their mining equipment for a "gap" phase after a block is found, to
> allow time to pass as more lucrative transactions entered the mempool.
>
> I don't know whether this will actually happen. The presence of a suitable
> backlog of transactions would help prevent this dynamic from emerging. But
> if such idling behavior was the optima mining strategy, it could create a
> serious vulnerability. Idle hands are the devil's workshop as the saying
> goes, and idle miners represent a pool of inert hashpower that is available
> to rent for all kinds of destabilizing purposes. It would be better to put
> those miners to profitable work mining a sync flag while they wait.
>
> Also, this creates a more efficient price discovery mechanism for
> transactions, because you allow transactions paying high fees time to arrive
> to the marketplace, rather than take whatever anyone is offering because all
> the "good" transactions got gobbled up in the prior block.
>
> **Can be easily done with a soft fork**
>
> Although a hard fork would be more efficient, sync flags could be easily
> implemented using a soft fork by introducing the following rule:
>
> Every block must include a transaction which pays 25% of the block reward to
> the address given by the 10th previous sync flag, and commits to the hash of
> the 1st previous sync flag.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal: derived mnemonics
2016-07-26 20:10 99% ` Jonas Schnelli
@ 2016-07-27 10:39 99% ` Jochen Hoenicke
2016-07-27 10:53 99% ` Jonas Schnelli
2016-07-27 20:59 99% ` Gregory Maxwell
0 siblings, 2 replies; 42+ results
From: Jochen Hoenicke @ 2016-07-27 10:39 UTC (permalink / raw)
To: Jonas Schnelli, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
schrieb am Di., 26. Juli 2016 um 22:10 Uhr:
> Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I
> personally consider "not enough" to protect a serious amount of funds.
>
>
But what are the alternatives? Put an expensive processor and a decent
amount of memory in every hardware wallet to support scrypt? Use a million
iterations and just wait 10 minutes after entering you passphrase? Or
compute the secret key on your online computer instead?
Also, how many iterations are secure? A million? Then just add two random
lower-case letters to the end of your passphrase and you have a better
protection with 2048 iterations. If you want to be able to use your
passphrase with cheap hardware and be protected against a high-end computer
with multiple GPUs that is almost a mllion times faster, then you have to
choose a good passphrase. Or just make sure nobody steals your seed; it is
not a brainwallet that is only protected by the passphrase after all.
Regards,
Jochen
[-- Attachment #2: Type: text/html, Size: 1536 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal: derived mnemonics
2016-07-27 10:39 99% ` Jochen Hoenicke
@ 2016-07-27 10:53 99% ` Jonas Schnelli
2016-07-27 20:59 99% ` Gregory Maxwell
1 sibling, 0 replies; 42+ results
From: Jonas Schnelli @ 2016-07-27 10:53 UTC (permalink / raw)
To: Jochen Hoenicke, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 1673 bytes --]
> But what are the alternatives? Put an expensive processor and a decent
> amount of memory in every hardware wallet to support scrypt? Use a
> million iterations and just wait 10 minutes after entering you
> passphrase? Or compute the secret key on your online computer instead?
What the Digital Bitbox team does, is, PBKDF2 the user entered
passphrase on the computer with >20'000 iterations, then PBKDF2 again
onchip with the 2048 rounds.
If somebody manages to steal your backup (in that case a file/SDCard or
printed PDF), it would at least required > 22'048 iterations to derive
the key from a passphrase which I consider "stronger" then just using
2048 iterations.
> Also, how many iterations are secure? A million? Then just add two
> random lower-case letters to the end of your passphrase and you have a
> better protection with 2048 iterations.
I guess you shouldn't delegate KDF security to the user. But sure, this
could help as well. This is part of the UI.
On the other hand, forcing the user to select a long/more-secure
passphrase will very likely lead to many funds get lost behind
encryption because of lost/forgotten passphrases.
> If you want to be able to use
> your passphrase with cheap hardware and be protected against a high-end
> computer with multiple GPUs that is almost a mllion times faster, then
> you have to choose a good passphrase. Or just make sure nobody steals
> your seed; it is not a brainwallet that is only protected by the
> passphrase after all.
Agree.
But IMO this fact should not be an excuse to reduce/use low iterations
during KDF (especially SHA2 based KDFs).
</jonas>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
2016-07-26 22:03 99% ` Nick ODell
@ 2016-07-27 14:42 99% ` Moral Agent
0 siblings, 0 replies; 42+ results
From: Moral Agent @ 2016-07-27 14:42 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 12417 bytes --]
I made a repo to be a home for sync_flags here:
https://github.com/moral-agent/sync_flags
If you see any personally identifying information, please be a good sport
and let me know. I'm a nobody, but I'd still prefer not to get doxxed.
Two changes to the proposal (see repo for explanations)
1. Sync flags now would have the same difficulty as blocks.
2. Blocks now donate to 5 sync flags instead of 1
I also added comments about selfish mining and invalid block spam.
Response to replies:
tomz@freedommail•ch: What is the advantage over optimistic mining?
1. Sync flags can be somewhat smaller than block headers.
2. Sync flags improve variance by doubling the number of chances to win
3. Sync flags can be distinguished from normal blocks, so SPV clients can
ignore them as confirmations.
4. Sync flags reward all miners equally. Optimistic blocks have to be empty
unless you mined the previous block, which damages decentralization.
5. Sync flags result in fewer empty blocks, smoothing out resource usage
6. Sync flags make transaction stuffing by miners either obvious or costly
7. Sync flags give miners something to do while they wait for attractive
transactions to appear.
erik@q32•com: Flags will be selfish mined.
I agree that flags would likely be selfish mined. I have modified the
proposal to say that flags have the same POW target as blocks, so the
selfish mining vulnerability should be equal to the current protocol.
martijn.meijering@mevs•nl: Why expect more selfish mining?
Because flags had small POW relative to blocks. After you find a block, why
not hide it while you take a crack at the flag?
tier.nolan@gmail•com: Effect is same as mandatory empty blocks.
Not quite the same:
1. Sync flags can be somewhat smaller than block headers.
2. Sync flags can be distinguished from normal blocks, so SPV clients can
ignore them as confirmations.
3. Sync flags make transaction stuffing by miners either obvious or costly
4. No one pays for empty blocks, except for the block subsidy. Some miners
may choose to only mine the non-empty blocks, resulting in
hashpower-for-rent to make mischief or hashpower that oscillates, creating
a situation where empty blocks take longer to mine than full blocks.
nickodell@gmail•com: Payout mechanism incompatible with certain mining pools
Hopefully some kind of smart contract structure could be implemented as you
suggested.
On Tue, Jul 26, 2016 at 6:03 PM, Nick ODell <nickodell@gmail•com> wrote:
> Moral,
>
> Mining the sync flag isn't compatible with the payout structure of non
> hot-wallet pools like Eligius or decentralized pools like p2pool.
> Those need the ability to split a reward among multiple parties.
> Instead of giving an address to send the funds to, you could include
> the hash of the transaction allowed to spend the sync flag output.
> You'd have to zero the previous outpoint of the transaction before
> hashing, since you don't know what the hash of the coinbase ten blocks
> from now will be.
>
>
> On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > I posted this to /r/bitcoin yesterday but it got minimal comments. One
> uses
> > suggested I try the mailing list so here it is:
> >
> > The idea presented here could have the following benefits:
> >
> > 1. Improve mining decentralization
> > 2. Reduce variance in mining profitability
> > 3. Reduce or eliminate SPV mined blocks
> > 4. Reduce or eliminate empty blocks, smoothing out resource usage
> > 5. Reduce or eliminate the latency bottleneck on throughput
> > 6. Make transaction stuffing by miners be either obvious or costly
> > 7. Gives miners something to do while they wait for attractive
> transactions
> > to appear
> > 8. Can be easily done with a soft fork
> >
> > #Basic idea:
> >
> > Ideally, all miners would begin hashing the next block at exactly the
> same
> > time. Miners with a head start are more profitable, and the techniques
> that
> > help miners receive and validate blocks quickly create centralization
> > pressure.
> >
> > What if there was something that acted like the starting flag at a race,
> > which could suddenly wave and cause all of the miners to simultaneously
> > begin hashing the next block?
> >
> > #Implementation:
> >
> > Let a sync flag be a message consisting of:
> >
> > 1. Hash of the previous block.
> > 2. Bitcoin address
> > 3. Nonce
> >
> > This tiny message could propagate through the network at maximum speed.
> If
> > miners had to include the hash of this flag in the next block, then all
> > miners wait for this flag, and when it suddenly spread through the
> network,
> > all miners could simultaneously begin hashing the next block.
> >
> > The sync flag should not be produced too quickly. You want to give
> everyone
> > enough time to be ready to hash the next block. Let's say that the hash
> of
> > the sync flag is a proof of work that is targeted for 2 minutes.
> >
> > To fund this proof of work, the protocol is modified to demand that the
> > block produced 10 blocks after the sync flag must allocate 25% of the
> block
> > reward to the address published by the sync flag. In this way, sync flags
> > are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
> > minutes total.
> >
> >
> > Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)
> >
> > Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png
> >
> >
> > #Explanation of reasons:
> >
> > **Improve mining decentralization**
> >
> > One factor driving centralization is the imperative miners have to
> achieve
> > low latency in receiving and validating blocks. To achieve low latency,
> it
> > helps a lot if you have expensive low-latency internet connections,
> curated
> > network topologies, and large pools that have a plausible chance of
> finding
> > consecutive blocks. If miners are expected (or forced) to validate a
> block
> > prior to mining on top of it, the rational end game would be to outsource
> > the validation step to a trusted third party specialist who can choose
> > optimal locations on the globe to serve their (multiple?) mining pool
> > clients. These are all less decentralized than the mining situation
> Satoshi
> > and others imagined.
> >
> > **Reduce variance in mining revenue**
> >
> > Currently, there are about 144 opportunities per day for a pool or solo
> > miner to see any revenue at all. With sync flags, that number doubles to
> > 288. Sync flags are only worth 25% of what a block is worth, but this
> still
> > represents a significant reduction in variance. This variance is one
> factor
> > causing solo miners to group into pools, and large pools to be more
> > attractive than small pools.
> >
> > **Reduce or eliminate SPV mined blocks**
> >
> > One way miners have sought to make
> > full-block-transmission-and-validation-latency irrelevant has been
> through
> > "SPV" mining or "Head-first" mining. There is some evidence that these
> > techniques may be widely used, and that badgering the miners about it is
> an
> > ineffective strategy to stop them.
> >
> > In SPV mining, a miner would simply accept any block header that shows
> the
> > correct proof of work. All other validation is entrusted to other miners.
> > This practice is quite dangerous as the SPV miners can wander off on some
> > invalid chain, taking SPV nodes with them. If this occurs during a soft
> > fork, these blind miners can also fool unupgraded fully validating nodes
> > into following them.
> >
> > "Head-first" mining means that miners start hashing as soon as they
> receive
> > the block header with the correct POW, but they simultaneously validate
> the
> > block, and abandon it if is not valid. I consider this to be pretty
> safe, as
> > it strictly limits the length of an invalid chain that can result from
> > mining without validating. However, "Head-first" mining can plausibly
> > generate 2 or 3 confirmations of an invalid block. It would be nice if
> such
> > confirmations did not happen.
> >
> > The sync flag technique is similar to head-first mining, but rather than
> > hashing the next block while they wait for transmission and validation of
> > the prior block, they hash the sync flag. Nodes can differentiate between
> > sync flags and blocks, and can ignore sync flags when counting
> > confirmations.
> >
> > **Reduce or eliminate empty blocks, smoothing out resource usage**
> >
> > Empty blocks are another consequence of SPV or Headfirst mining, because
> the
> > miner cannot safely include any transactions in the block they are
> hashing
> > until they have validated the prior block. By delaying the start of
> hashing
> > the next block until after validation, miners would not have this reason
> to
> > mine empty blocks.
> >
> > **Reduce or eliminate the latency bottleneck on throughput**
> >
> > Centralization pressure due to latency issues has been a major
> preoccupation
> > over the last year. If latency mattered much less, it could represent a
> > scalability improvement that could enable higher throughput.
> >
> > **Make transaction stuffing by miners be either obvious or costly**
> >
> > Currently, the entire block reward goes to the miner who mines it. One
> > unfortunate consequence of this is that it does not cost the miner
> anything
> > to covertly stuff the block with transactions. These transactions would
> pay
> > fees and be indistinguishable from ordinary transactions, but the fees
> are
> > paid by the miner and then immediately returned to the miner.
> >
> > With sync flags, the miner must share these transaction fees with the
> > address contained in the sync flag 10 blocks prior. This means that if
> the
> > miner gives the transactions a normal looking fee, they will incur a cost
> > that will be paid to the sync flag. If the miner wants to avoid this,
> they
> > must give their stuffing transactions a zero fee, which provides evidence
> > that they are stuffing.
> >
> > Also, when miners stuff with transactions using a zero fee, they cannot
> > manipulate the perception of how much fee it takes to get into a block.
> >
> > Note that miners could still try to covertly stuff blocks that will pay a
> > sync flag that they themselves created. if this is a big concern, it can
> be
> > addressed by forcing blocks to pay multiple sync flags.
> >
> > **Gives miners something to do while they wait for attractive
> transactions
> > to appear**
> >
> > From the Montreal scaling workshop last year, we have [this
> > talk](
> https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf
> )
> > which worried that as the block subsidy reduced and transactions became a
> > more important fraction of miner revenue, it would be rational for
> miners to
> > turn off their mining equipment for a "gap" phase after a block is
> found, to
> > allow time to pass as more lucrative transactions entered the mempool.
> >
> > I don't know whether this will actually happen. The presence of a
> suitable
> > backlog of transactions would help prevent this dynamic from emerging.
> But
> > if such idling behavior was the optima mining strategy, it could create a
> > serious vulnerability. Idle hands are the devil's workshop as the saying
> > goes, and idle miners represent a pool of inert hashpower that is
> available
> > to rent for all kinds of destabilizing purposes. It would be better to
> put
> > those miners to profitable work mining a sync flag while they wait.
> >
> > Also, this creates a more efficient price discovery mechanism for
> > transactions, because you allow transactions paying high fees time to
> arrive
> > to the marketplace, rather than take whatever anyone is offering because
> all
> > the "good" transactions got gobbled up in the prior block.
> >
> > **Can be easily done with a soft fork**
> >
> > Although a hard fork would be more efficient, sync flags could be easily
> > implemented using a soft fork by introducing the following rule:
> >
> > Every block must include a transaction which pays 25% of the block
> reward to
> > the address given by the 10th previous sync flag, and commits to the
> hash of
> > the 1st previous sync flag.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
[-- Attachment #2: Type: text/html, Size: 15287 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal: derived mnemonics
2016-07-27 10:39 99% ` Jochen Hoenicke
2016-07-27 10:53 99% ` Jonas Schnelli
@ 2016-07-27 20:59 99% ` Gregory Maxwell
1 sibling, 0 replies; 42+ results
From: Gregory Maxwell @ 2016-07-27 20:59 UTC (permalink / raw)
To: Jochen Hoenicke, Bitcoin Protocol Discussion
On Wed, Jul 27, 2016 at 10:39 AM, Jochen Hoenicke via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> schrieb am Di., 26. Juli 2016 um 22:10 Uhr:
>>
>> Side-note: Bip39 does still use PBKDF2 with 2048 iterations which I
>> personally consider "not enough" to protect a serious amount of funds.
>>
>
> But what are the alternatives? Put an expensive processor and a decent
> amount of memory in every hardware wallet to support scrypt? Use a million
> iterations and just wait 10 minutes after entering you passphrase? Or
> compute the secret key on your online computer instead?
>
> Also, how many iterations are secure? A million? Then just add two random
> lower-case letters to the end of your passphrase and you have a better
> protection with 2048 iterations. If you want to be able to use your
> passphrase with cheap hardware and be protected against a high-end computer
> with multiple GPUs that is almost a mllion times faster, then you have to
> choose a good passphrase. Or just make sure nobody steals your seed;
Jochen, two alternatives were raised in public discussion:
Use a scheme which supports delegatable hardening-- (there are two
broad classes proposed, one where the delegated party learns
information that would let them bypass the part of the hardening they
perform but only that part, and another where the delegation is
information theoretically private.)
or
Eschew the pretextual 'hardening' that serves no purpose but to cause
users to think the scheme is more secure than it is, and which makes
the system more complex to implement.
Both were rejected by the authors of that spec.
> it is
> not a brainwallet that is only protected by the passphrase after all.
This ignores the history of that spec and the widespread use. Because
of the design, the check value can't be computed without a fixed
dictionary, and many people do use it as a brainwallet-- which is what
that BIP originally specified, in fact.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
2016-07-26 12:47 99% [bitcoin-dev] Reasons to add sync flags to Bitcoin Moral Agent
2016-07-26 13:51 99% ` Tom
2016-07-26 22:03 99% ` Nick ODell
@ 2016-07-28 16:41 99% ` Moral Agent
2 siblings, 0 replies; 42+ results
From: Moral Agent @ 2016-07-28 16:41 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]
If there is concern about the
block-with-valid-header-but-invalid-transactions-spam-attack, I have a
strategy using sync flags that may drastically reduce the problem.
Sync flags documented here:
https://github.com/moral-agent/sync_flags/blob/master/README.md)
The strategy to defeat the above attack is illustrated here:
https://s32.postimg.org/e94tqdqat/sync_flag_invalid_block.png
The key is to relax the requirement that a flag commit to a completely
valid block. The flag is valid if it commits to a valid block header, even
if the block body is invalid.
From the perspective of an individual miner, they can safely commence
mining a flag the moment they obtain (or discover) a valid block header.
As soon as the spam is discovered, miners can choose to either abandon the
flag and return to mining on the previous block, or they can continue
mining on the flag.
It's difficult for me to game out which of these strategies would be
preferable. My first thought is that the miners should have the incentive
to mine whichever option has the fewest miners, which should result in a
50/50 split.
However, the miners who continue mining the flag have a chance of ending up
in a situation where they mine the flag before anyone mines a valid block.
If this happens, it is sub-optimal for them. They can start mining for the
next valid block but if someone else broadcasts a valid block header they
will be in the same pickle that miners under the current protocol are: they
must either keep mining for a valid block, or SPV mine the newly arrived
block while they do validation. The third option, of mining a flag, is not
available to them, because the flag has already been mined for this cycle.
As a result of the above, it may be most rational for miners to (upon
learning that they are mining a flag on top of an invalid block) split
their hashpower unevenly between the flag and continuing to mine for a
valid block. The hashpower split reflects their estimates of the cost of
the above negative outcome. I think the split would be pretty close to
50/50, but deviations from 50/50 would not necessarily be bad. For example,
if they split 52/48, with more hashpower toward finding the valid block
instead of the flag, then that decreases the likelyhood that the flag will
be discovered before the next valid block, which is good for all of the
miners. So it's a nice positive feedback.
*****
This approach mostly neutralizes the harm done by the (currently very rare)
invalid block spam attack. As a kind of amazing side effect, the work done
to produce the spam is incorporated into the blockchain cumulative Proof of
Work, and the spammer is not paid for this contribution.
[-- Attachment #2: Type: text/html, Size: 3682 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security
@ 2016-07-28 21:07 99% ` Leo Wandersleb
0 siblings, 0 replies; 42+ results
From: Leo Wandersleb @ 2016-07-28 21:07 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4016 bytes --]
gmaxwell just made me aware of this mail thread [0]. Some days ago I had
independently and naively started implementing "something similar" [1].
My version totally ignored the commitment and signing part but I'm pretty sure
that 12GB is overkill. My code is currently broken and I have no time to work on
it much but I thought it might be helpful to chime in.
At this point in time the difference between 80GB and 3GB (as my current 1.5GB
of only outputs would suggest if I had covered the inputs) or even 12GB makes
the difference of being able to store it on a phone, vs. not being able to. 80GB
"compressed" to 3GB is not that bad at all. Unfortunately, with segWit this will
be worse, with the higher transaction count per MB.
Regards,
Leo
[0]
https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/d5ux6aq
[1] https://github.com/Giszmo/TransactionFinder
On 05/11/2016 10:29 PM, Bob McElrath via bitcoin-dev wrote:
> Eerrrr....let me revise that last paragraph. That's 12 *GB* of filters at
> today's block height (at fixed false-positive rate 1e-6. Compared to block
> headers only which are about 33 MB today. So this proposal is not really
> compatible with such a wallet being "light"...
>
> Damn units...
>
> Bob McElrath via bitcoin-dev [bitcoin-dev@lists•linuxfoundation.org] wrote:
>> I like this idea, but let's run some numbers...
>>
>> bfd--- via bitcoin-dev [bitcoin-dev@lists•linuxfoundation.org] wrote:
>>> A Bloom Filter Digest is deterministically created of every block
>> Bloom filters completely obfuscate the required size of the filter for a desired
>> false-positive rate. But, an optimal filter is linear in the number of elements
>> it contains for fixed false-positive rate, and logarithmic in the false-positive
>> rate. (This comment applies to a RLL encoded Bloom filter Greg mentioned, but
>> that's not the only way) That is for N elements and false positive rate
>> \epsilon:
>>
>> filter size = - N \log_2 \epsilon
>>
>> Given that the data that would be put into this particular filter is *already*
>> hashed, it makes more sense and is faster to use a Cuckoo[1] filter, choosing a
>> fixed false-positive rate, given expected wallet sizes. For Bloom filters,
>> multiply the above formula by 1.44.
>>
>> To prevent light clients from downloading more blocks than necessary, the
>> false-positive rate should be roughly less than 1/(block height). If we take
>> the false positive rate to be 1e-6 for today's block height ~ 410000, this is
>> about 20 bits per element. So for todays block's, this is a 30kb filter, for a
>> 3% increase in block size, if blocks commit to the filter. Thus the required
>> size of the filter commitment is roughly:
>>
>> filter size = N \log_2 H
>>
>> where H is the block height. If bitcoin had these filters from the beginning, a
>> light client today would have to download about 12MB of data in filters. My
>> personal SPV wallet is using 31MB currently. It's not clear this is a bandwidth
>> win, though it's definitely a win for computing load on full nodes.
>>
>>
>> [1] https://www.cs.cmu.edu/~dga/papers/cuckoo-conext2014.pdf
>>
>> --
>> Cheers, Bob McElrath
>>
>> "For every complex problem, there is a solution that is simple, neat, and wrong."
>> -- H. L. Mencken
>>
>>
>>
>> !DSPAM:5733934b206851108912031!
>
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> !DSPAM:5733934b206851108912031!
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and wrong."
> -- H. L. Mencken
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?
@ 2016-07-30 23:18 99% Paul Sztorc
2016-07-31 1:31 99% ` Bryan Bishop
2016-07-31 5:18 99% ` Luke Dashjr
0 siblings, 2 replies; 42+ results
From: Paul Sztorc @ 2016-07-30 23:18 UTC (permalink / raw)
To: Bitcoin Dev
Dear list,
As we know, it would be desirable for Alice, running an SPV client, to tip (say $5) anyone who can prove to her that a given block has invalid content.
If no one takes these tips, then this is weak evidence that the entire block is valid. Alice gets validation, full nodes can get paid...this idea goes back to Satoshi's whitepaper.
In my view, "alerts" are relatively straightforward: a new OP CODE (details below) st. the txn only succeeds if it references invalid block content on a "pretender block".
However, my background reading seems to reveal that "fraud proofs" (as they are now called) require some kind of tremendous engineering overhaul. Can anyone point me to these large problem(s)?
Regards,
Paul Sztorc
------------------------------------
Fraud Proof, Simple (?)
1. "OP FraudProof", which:
1. Contains arguments [a] block number (from Alice), [b] block header, and [c] merkle path from header to an invalid transaction*.
2. Checks to see if the provided header _is_ in the position which Alice requested.
2. Checks to see if the header _is_ valid (ie, has sufficient work).
3. Checks to see if the merkle path _does_ lead from the header to "something invalid"*.
2. This OP Code can then be used in a transaction of the form:
Inputs:
1 from Alice
0.2 from X**
Output:
1.2 to Alice, timelocked
(or)
1.2 to X, OP FraudProof .
3. Alice could sign this txn and circulate it, waiting for "X" to add the second signature.
"Eric", for example, might sign. As soon as Alice get's Eric's signature, she [1] assumes the block *is* invalid, and [2] stops offering to buy FraudProofs on it.
If Eric does not deliver the fraud proof, Alice gets her money back + 0.2 BTC from Eric (for wasting her time). Alice can't lose -- she either buys a fraud proof for 1, or she gets a free 0.2.
Eric can't lose either. Either he doesn't sign (and nothing happens), or he places himself in a position to trade a FraudProof for 1 BTC.
- FraudProof can use "OP Equal" to request fraud for a certain block.
- This can all happen through the lightning network.
* "invalid transaction" is defined either [1] as a script which fails, or [2] a double-spend (headers/paths to 2 txns spending the same input). This definition does not catch bad coinbase transactions, but this doesn't concern me. Those outputs aren't spendable for 100 blocks, and anyway, SPV clients could be programmed to never accept them (it would be annoying, but possible).
** For simplicity, I assume that "FraudProof sellers" will pre-identify themselves (and their unspent outputs, etc, by making them "watching only" or whatever).
---
Now, I wouldn't describe this as a "weekend project", but I wouldn't describe it as an "engineering overhaul" either. Just a new OP Code, and code to create / scan for these "Alert Transactions". So, if the idea is 5+ years old, what's the hold up?
I've also heard that segwit will help, but don't understand why.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?
2016-07-30 23:18 99% [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ? Paul Sztorc
@ 2016-07-31 1:31 99% ` Bryan Bishop
2016-07-31 5:18 99% ` Luke Dashjr
1 sibling, 0 replies; 42+ results
From: Bryan Bishop @ 2016-07-31 1:31 UTC (permalink / raw)
To: Paul Sztorc, Bitcoin Protocol Discussion, Bryan Bishop
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On Sat, Jul 30, 2016 at 6:18 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> I've also heard that segwit will help, but don't understand why.
>
There are some helpful discussions that happened over here:
https://botbot.me/freenode/bitcoin-core-dev/2015-12-28/?msg=56907496&page=2
- Bryan
http://heybryan.org/
1 512 203 0507
[-- Attachment #2: Type: text/html, Size: 971 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP114 MAST updated
@ 2016-07-31 2:03 99% Johnson Lau
0 siblings, 0 replies; 42+ results
From: Johnson Lau @ 2016-07-31 2:03 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
I have published a new version for BIP114 MAST. It's a bit more complicated with some new features:
1. It allows different parties in a contract not to expose their scripts to each other until redemption.
2. It includes a field to indicate the script language version so new opcodes could be added without touching the version byte nor the witness program.
You can find the updated BIP and code at:
https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
https://github.com/jl2012/bitcoin/tree/bip114v2
The old version:
https://github.com/bitcoin/bips/blob/7478ee3260c0d3c0cef39233931b307691764edc/bip-0114.mediawiki
https://github.com/jl2012/bitcoin/tree/segwit_mast
[-- Attachment #2: Type: text/html, Size: 1158 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?
2016-07-30 23:18 99% [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ? Paul Sztorc
2016-07-31 1:31 99% ` Bryan Bishop
@ 2016-07-31 5:18 99% ` Luke Dashjr
1 sibling, 0 replies; 42+ results
From: Luke Dashjr @ 2016-07-31 5:18 UTC (permalink / raw)
To: bitcoin-dev, Paul Sztorc
On Saturday, July 30, 2016 11:18:36 PM Paul Sztorc via bitcoin-dev wrote:
> In my view, "alerts" are relatively straightforward: a new OP CODE (details
> below) st. the txn only succeeds if it references invalid block content on
> a "pretender block".
>
> However, my background reading seems to reveal that "fraud proofs" (as they
> are now called) require some kind of tremendous engineering overhaul. Can
> anyone point me to these large problem(s)?
Essentially this comes down to attackers being able to construct a block for
which invalidity cannot be proven. While you could always show a proof for an
invalid transaction within a well-formed block, you cannot show a proof that a
block is not well-formed. For example, the merkle tree that ought to represent
a set of transactions may be corrupted in such a manner that the transaction
paying Alice can have a SPV proof made, but the links in the merkle path have
no known data (transactions) behind them. This could even be a perfectly valid
block, but with some of the transactions withheld until it is stale - full
nodes and miners cannot accept it without knowing the entire block's
transactions. The only solution to this I am aware of, is for Alice to be told
"hey, block XYZHASH is incomplete and cannot be checked", and then Alice
demands the full block from the attacker. But of course this makes it trivial
to DoS Alice by giving her bogus incomplete-block claims and forcing her to
use the same bandwidth as a full node - which is a major problem if she lacks
the bandwidth to run a full node (presumably her reason for using SPV in the
first place).
Luke
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Bitcoin Core 0.13.0 release candidate 2 available
@ 2016-07-31 13:44 99% Wladimir J. van der Laan
0 siblings, 0 replies; 42+ results
From: Wladimir J. van der Laan @ 2016-07-31 13:44 UTC (permalink / raw)
To: bitcoin-dev, bitcoin-core-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Binaries for bitcoin Core version 0.13.0rc2 are available from:
https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc2/
Source code can be found on github under the signed tag
https://github.com/bitcoin/bitcoin/tree/v0.13.0rc2
This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.
Preliminary release notes for the release can be found at
https://github.com/bitcoin/bitcoin/blob/0.13/doc/release-notes.md
Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.13.0.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
Notable changes since rc1:
### Build system
- - #8373 `1fe7f40` Fix OSX non-deterministic dmg (theuni)
- - #8358 `cfd1280` Gbuild: Set memory explicitly (default is too low) (MarcoFalke)
### GUI
- - #8407 `45eba4b` Add dbcache migration path (jonasschnelli)
### Wallet
- - #8378 `ebea651` Move SetMinVersion for FEATURE_HD to SetHDMasterKey (pstratem)
- - #8390 `73adfe3` Correct hdmasterkeyid/masterkeyid name confusion (jonasschnelli)
- - #8206 `18b8ee1` Add HD xpriv to dumpwallet (jonasschnelli)
- - #8389 `c3c82c4` Create a new HD seed after encrypting the wallet (jonasschnelli)
### P2P protocol and network code
- - #8408 `b7e2011` Prevent fingerprinting, disk-DoS with compact blocks (sdaftuar)
### Consensus
- - #8412 `8360d5b` libconsensus: Expose a flag for BIP112 (jtimon)
### Mining
- - #8362 `86edc20` Scale legacy sigop count in CreateNewBlock (sdaftuar)
### Block and transaction handling
- - #8381 `f84ee3d` Make witness v0 outputs non-standard (jl2012)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJXngBiAAoJEHSBCwEjRsmmS5kIAMFiXFua9ruR8Vwu1fNgnWTb
X4tsNOdPScm7jwsFavcwygqZQlDNDURjcocQFcehHgEickBrk6eaplTuB4VJidPG
Aqw+nLrd6M//Ohy+7eke7aCg5/QV7poplM3glwow4gQfoSBvL0ywMEhWEzGL7EPH
FH5pyY9o4QZw5wGdvMWxvYVTLPZkm0W2cSWCHZ0WgzWvTkZ7aMzSQ5F5TXPfjzED
DNuQQRMm9H1H3LJkmWAwjCXLzKNMzjmefLujyEII388s6UoWnA1ufosqb1kMqL+h
kuEelzef4cMBZEvHgfzsvlLmba2DLr7xhwudd3HK2NHSmO/wAUdhbQOQSts9NoY=
=rN68
-----END PGP SIGNATURE-----
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Proposal: Hard fork opt-out bits
@ 2016-07-31 18:01 99% Tom Harding
0 siblings, 0 replies; 42+ results
From: Tom Harding @ 2016-07-31 18:01 UTC (permalink / raw)
To: Bitcoin-Dev
[-- Attachment #1.1: Type: text/plain, Size: 1292 bytes --]
Your thoughts are sought on this simple proposal to allow transaction
authors to restrict execution to fewer than all blockchain forks where
the transaction would otherwise be valid.
Proposal
Node implementations select a bit from among the upper 8 bits of the
transaction version space to enforce as a hard fork opt-out bit.
To specify that a transaction NOT be mined by nodes that enforce a
particular bit, authors set that bit in the transaction version.
Opt-out is enforced by consensus among nodes enforcing each bit.
An implementation will relay, process and mine transactions that opt out
of other blockchain forks; just not those that opt out of its own fork.
Notes
Example: Via soft fork, all implementations may begin enforcing hard
fork opt-out bit 30. Post soft fork, setting this bit would make a
transaction invalid, unless a fork emerges that has stopped enforcing
bit 30.
Example: BIP109 implementations may stop enforcing bit 30 and begin
enforcing bit 28 when the BIP109 hard fork is activated for a chain they
are tracking.
Enforcing more than one hard fork opt-out bit would imply that an
implementation is actively participating in building more than one
blockchain fork, and therefore providing a way to opt out of each.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Introducing Flexible Transactions.
@ 2016-08-01 9:30 99% Tom
0 siblings, 0 replies; 42+ results
From: Tom @ 2016-08-01 9:30 UTC (permalink / raw)
To: bitcoin-dev
I've been asked one question quite regularly and recently with more force.
The question is about Segregated Witness and specifically what a hard
fork based version would look like.
This is available online at my blog;
http://zander.github.io/posts/Flexible_Transactions/
But I'll publish the actual text here as well, hoping to hear from others in
the Bitcoin industry what they think about this approach.
Segregated Witness (or SegWit for short) is complex. It tries to solve
quite a lot of completely different and not related issues and it tries to
do this in a backwards compatible manner. Not a small feat!
So, what exactly does SegWit try to solve? We can find info of that in the
[benefits](https://bitcoincore.org/en/2016/01/26/segwit-benefits/) document.
* Malleability Fixes
* Linear scaling of sighash operations
* Signing of input values
* Increased security for multisig via pay-to-script-hash (P2SH)
* Script versioning
* Reducing UTXO growth
* Compact fraud proofs
As mentioned above, SegWit tries to solve these problems in a backwards
compatible way. This requirement is there only because the authors of
SegWit set themselves this requirement. They set this because they wished
to use a softfork to roll out this protocol upgrade.
**This post is going to attempt to answer the question if that is indeed
the best way of solving these problems.**
Starting with Malleability, the problem is that a transaction between being
created by the owner of the funds and being mined in a block is possible to
change in such a way that it still is valid, but the transaction identifier
(TX-id) has been changed. But before we dive into the deep, lets have some
general look at the transaction data first.
If we look at a
[Transaction](http://bitcoinfactswiki.github.io/Transaction) as it is
today, we notice some issues.
<table>
<tr><td colspan=2>Version</td><td>4 bytes</td></tr>
<tr><td colspan=2>Number of inputs</td><td>VarInt (between 1 and 9
bytes)</td></tr>
<tr><td rowspan=5 class=vertical>inputs</td><td>Prev transaction
hash</td><td>32 bytes.
<font color="red">Stored in reverse</font></td></tr>
<tr><td>Prev transaction index</td><td>4 bytes</td></tr>
<tr><td>TX-in script length</td><td><font color=red>Compact-
int</font></td></tr>
<tr><td>TX-in script</td><td>This is the witness data</td></tr>
<tr><td>Sequence-no/<a
href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">CSV</a>
</td><td>4 bytes</td></tr>
<tr><td colspan=2>Number of outputs</td><td>VarInt (between 1 and 9
byte)</td></tr>
<tr><td rowspan=3 class=vertical>outputs</td><td>Value</td><td>Var
int</td></tr>
<tr><td>TX-out script length</td><td><font color=red>Compact-
int</font></td></tr>
<tr><td>TX-out script</td><td>bytearray</td></tr>
<tr><td colspan=2>NLockTime</td><td>4 bytes</td></tr>
</table>
</table>
The original transaction format as designed by
[Satoshi Nakamoto](http://bitcoinfactswiki.github.io/Satoshi_Nakamoto/)
had a 4 byte version. This design approach is common in the industry and
the way that this is used is that a new version is defined whenever any
field in the data structure needs changing. In Bitcoin we have not done
this and we are still at version 1.
What Bitcoin has done instead is make small, semi backwards-compatible,
changes.
For instance the [CHECKSEQUENCEVERIFY]
(http://bitcoinfactswiki.github.io/Script/#Locktime)
feature repurposes the sequence field as a way to add data
that would not break old clients. Incidentally, this specific change
(described in BIP68)
is not backwards compatible in the main clients as it depends on a
transaction version number being greater than 1, they all check for
Standard transactions and say that only version 1 is standard.
The design of having a version number implies that the designer wanted to
use hard forks for changes. A new client is required to know how to parse a
newly designed data structure, this should be obvious. So the idea is to
change the version number and so older clients would know they can't parse
this new transaction version. To keep operating, everyone would have to
upgrade to a client that supports this new transaction version.
Lets look at why we would want to change the version; I marked some items in
red that are confusing. Most specifically is that numbers are stored in 3
different, incompatible formats in transactions. Not really great and
certainly a source of bugs.
Transactions are cryptographically signed by the owner of the coin so
others can validate that he is actually allowed to move the coins.
The signature is stored in the `TX-in-script`.
Crypto-geeks may have noticed something weird that goes against any
textbooks knowledge. What this is is that a digital
signature has to be placed outside of the thing it signs. This is because
a digital signature protects against changes. But a signature itself would
cause this change. So you have to store the signature outside the thing you
sign.
Bitcoin's creator did something smart with how transactions are actually
signed so the signature actually doesn't have to be outside the
transaction. It works. Mostly. But we want it to work flawlessly
because currently this being too smart causes the dreaded malleability
issues where people have been known to lose money.
## What about SegWit?
SegWit actually solves only one of these items. It moves the signature out
of the transaction. SegWit doesn't fix any of the other problems in Bitcoin
transactions, it also doesn't change the version after making the
transaction's-meaning essentially unable to be understood by old clients.
Old clients will stop being able to check the SegWit type of transaction,
because the authors of SegWit made it so that SegWit transactions just have
a sticker of "All-Ok" on the car while moving the real data to the trailer,
knowing that the old clients will ignore the trailer.
SegWit wants to keep the data-structure of the transaction unchanged and it
tries to fix the data structure of the transaction. This causes friction
as you can't do both at the same time, so there will be a non-ideal
situation and hacks are to be expected.
The problem, then, is that SegWit introduces more technical debt, a term
software developers use to say the system-design isn't done and needs
significant more work. And the term 'debt' is accurate as over time
everyone that uses transactions will have to understand the defects to work
with this properly. Which is quite similar to paying interest.
Using a Soft fork means old clients will stop being able to validate
transactions, or even parses them fully. But these old clients are
themselves convinced they are doing full validation.
## Can we improve on that?
I want to suggest a way to **one-time** change the data-structure of the
transaction so it becomes much more future-proof and fix the issues it
gained over time as well. Including the malleability issue. It turns out
that this new data-structure makes all the other issues that SegWit fixes
quite trivial to fix.
I'm going to propose an upgrade I called;
> **Flexible Transactions**
Last weekend I wrote a little app (sources [here]
(http://zander.github.io/scaling/transactions))
that reads a transaction and then writes it out in a new format I've
designed for Bitcoin. Its based on ideas I've used for some time in other
projects as well, but this is the first open source version.
The basic idea is to change the transaction to be much more like modern
systems like JSON, HTML and XML. Its a 'tag' based format and has various
advantages over the closed binary-blob format.
For instance if you add a new field, much like tags in HTML, your old
browser will just ignore that field making it backwards compatible and
friendly to future upgrades.
Further advantages;
* Solving the malleability problem becomes trivial.
* tag based systems allow you to skip writing of unused or default values.
* Since we are changing things anyway, we can default to use only var-int
encoded data instead of having 3 different types in transactions.
* Adding a new tag later, (for instance ScriptVersion) is easy and doesn't
require further changes to the transaction data structure. All old clients
can still make sense of all the known data.
* The actual transaction turns out to be about 3% shorter average (calculated
over 200K transactions)
* Where SegWit adds a huge amount of technical debt, my Flexible
Transactions proposal instead amortizes a good chunk of technical debt.
An average **Flexible Transaction** will look like this;
<table>
<tr><td colspan=2>TxStart (Version)</td><td>0x04</td>
<td rowspan=5 class="vertical">TX-ID data</td></tr>
<tr><td rowspan=2 class=vertical>inputs</td><td>TX-ID I try to spent</td><td>1
+ 32 bytes</td></tr>
<tr><td>Index in prev TX-ID</td><td>varint</td></tr>
<tr><td rowspan=2 class=vertical>outputs</td><td>TX-out Value (in
Satoshis)</td><td>VarInt</td></tr>
<tr><td>TX-out script</td><td>bytearray</td></tr>
<tr><td>inputs</td><td>TX-in-script (Witness data)<td>bytearray</td>
<td rowspan=2 class=vertical>WID-data</td></tr>
<tr><td colspan=2>TxEnd</td><td>0x2C</td></tr>
</table>
Notice how the not used tags are skipped. The `NLockTime` and the
`Sequence` were not used, so they are skipped in the transaction.
The Flexible Transaction proposal uses a list of tags. Like JSON; `"Name:"
"Value"`. Which makes the content very flexible and extensible. Just
instead of using text, Flexible Transactions use a binary format.
The biggest change here is that the `TX-in-script` (aka the witness data) is
moved to be at the end of the transaction. When a wallet generates this new
type of transaction they will append the witness data at the end but the
transaction ID is calculated by hashing the data that ends before the
witness data.
The witness data typically contains a public key as well as a signature.
In the Flexible Transactions proposal the signature is made by signing exactly
the same set of data as is being hashed to generate the TX-input. Thereby
solving the malleability issue. If someone would change the transaction, it
would invalidate the signature.
I took 187000 recent transactions and checked what this change would do to
the size of a transaction with my test app I linked to above.
* Transactions went from a average size of 1712 bytes to 1660 bytes and a
median size of 333 to 318 bytes.
* Transactions can be pruned (removing of signatures) after they have been
confirmed. Then the size goes down to an average of 450 bytes or a median
of 101 bytes
* In contrary to SegWit new transactions get smaller for all clients with this
upgrade.
* Transactions, and blocks, where signatures are removed can expect up to
75% reduction in size.
## Broken OP_CHECKSIG scripting instruction
To actually fix the malleability issues at its source we need to fix this
instruction. But we can't change the original until we decide to make a
version 2 of the Script language.
This change is not really a good trigger to do a version two, and it
would be madness to do that at the same time as we roll out a new format of
the transaction itself. (too many changes at the same time is bound to
cause issues)
This means that in order to make the Flexible Transaction proposal actually
work we need to use one of the NOP codes unused in Script right now and
make it do essentially the same as OP_CHECKSIG, but instead of using the
overly complicated manner of deciding what it will sign, we just define it
to sign exactly the same area of the transaction that we also use to create
the TX-ID. (see right most column in the above table)
This new opcode should be relatively easy to code and it becomes really
easy to clean up the scripting issues we introduce in a future version of
script.
## So, how does this compare to SegWit.
First of all, introducing a new version of a transaction doesn't mean we
stop supporting the current version. So all this is perfectly backwards
compatible because clients can just continue making old style transactions.
Naturally, with the problems that had, but nobody will end up stuck.
Using a tagged format for a transaction is a one time hard fork to upgrade
the protocol and allow many more changes to be made with much lower impact
on the system in the future. There are parallels to SegWit, it strives for
the same goals, after-all. But where SegWit tries to adjust a static
memory-format by re-purposing existing fields, Flexible transactions presents
a coherent simple design that removes lots of conflicting concepts.
Most importantly, years after Flexible transactions has been introduced we
can continue to benefit from the tagged system to extend and fix issues we
find then we haven't thought of today. In the same, consistent, concepts.
We can fit more transactions in the same (block) space similarly to SegWit,
the
signatures (witness part) can be pruned by full nodes without causing any
security implications in both solutions. What SegWit doesn't do is
allowing unused features to not use space. So if a transaction doesn't use
NLockTime (which is near 100% of them) they will take space in SegWit but
not in this proposal. Expect your transactions to be smaller and thus lower
fee!
On size, SegWit proposes to gain 60% space. Which is by removing the
signatures minus the overhead introduced. In my tests Flexible
transactions showed 75% gain.
SegWit also describes changes how data is stored in the block. It creates
an extra 'branch' in the merkle tree. The Flexible Transactions proposal
is in essence solving the same problem as SegWit and the same solution for
blocks can be applied. Which means we can have that merkle tree solution
as well. No change.
At the start of the blog I mentioned a list of advantages that the authors
of SegWit included. It turns out that those advantages themselves are
completely not related to each other and they each have a very separate
solution to their individual problems. The tricky part is that due to the
requirement of old clients staying forwards-compatible they are forced to
push them all into the one 'fix'.
Lets go over them individually;
### Malleability Fixes
Using this new version of a transaction data-structure solves all forms of
known malleability.
### Linear scaling of sighash operations
This has been fixed in the BIP109 2MB hardfork quite some months ago.
### Signing of input values
This is included in this proposal.
### Increased security for multisig via pay-to-script-hash (P2SH)
The *Flexible transactions* proposal outlined in this document makes many
of the additional changes in SegWit really easy to add at a later time.
This change is one of them.
Bottom line, changing the security with a bigger hash in SegWit is only
included in SegWit because SegWit didn't solve the transaction versioning
problem making it trivial to do separately.
With flexible transactions this change can now be done at any time in the
future with minimal impact.
### Script versioning
Notice that this *only* introduces the versioning byte. It doesn't actually
introduce a new version of script.
This is an excellent example where tagged formats shine brighter than a
static memory format that SegWit uses because adding such a versioning tag
is much cleaner and much easier and less intrusive to do with
flexible transactions. Just add a new tag that defaults to version 1 so the
old transactions not having the tag stay consistent.
Imagine having to include "body background=white" in each and every html
page because it was not allowed to leave it out. Thats what SegWit does
right now. Even though it doesn't actually support changing it yet.
### Reducing UTXO growth
I suggest you read this
[point](https://bitcoincore.org/en/2016/01/26/segwit-benefits/#reducing-utxo-growth)
for yourself, its rather interestingly technical and I'm sure many will not
fully grasp the idea. The bottom line of that they are claiming the
UTXO database will avoid growing because SegWit doesn't allow more
customers to be served.
I don't even know how to respond to such a solution. Its throwing out the
baby with the bath water.
Database technology has matured immensely over the last 20 years, the
database is tiny in comparison to what free and open source databases can
do today. Granted, the UTXO database is slightly unfit for a normal SQL
database, but telling customers to go elsewhere has never worked out for
products in the long term.
### Compact fraud proofs
Again, not really included in SegWit, just started as a basis. The exact
same basis is suggested for flexible transactions, and as such this is
identical.
### What do we offer that SegWit doesn't offer?
* A transaction becomes extensible. Future modifications are cheap.
* A transaction gets smaller. Using less features also takes less space.
* We only use one instead of 3 types of encodings for integers.
* We remove technical debt and simplify implementations. SegWit does the
opposite.
## Conclusions
SegWit has some good ideas and some needed fixes. Stealing all the good
ideas and improving on them can be done, but require a hard fork. This post
shows that the advantages are quite significant and certainly worth it.
We introduced a tagged data structure. Conceptually like JSON and XML in
that it is flexible, but the proposal is a compact and fast binary format.
Using the Flexible Transaction data format allows many future
innovations to be done cleanly in a consistent and, at a later stage, a
more backwards compatible manner than SegWit is able to do, even if given
much more time. We realize that separating the fundamental issues that
SegWit tries to fix all in one go, is possible and each becomes much lower
risk to Bitcoin as a system.
After SegWit has been in the design stage for a year and still we find
show-stopping issues, delaying the release, I would argue that dropping
the requirement of staying backwards compatible should be on the table.
The introduction of the *Flexible Transaction* upgrade has big benefits
because the transaction design becomes extensible.
A hardfork is done once to allow us to do soft upgrades in the future.
The Flexible transaction solution lowers the amount of changes required in
the entire ecosystem. Not just for full nodes. Especially considering that
many tools and wallets use shared libraries between them to actually create
and parse transactions.
The Flexible Transaction upgrade proposal should be considered by anyone
that cares about the protocol stability because its risk of failures
during or after upgrading is several magnitudes lower than SegWit is and
it removes technical debt that will allow us to innovate better into the
future.
Flexible transactions are smaller, giving significant savings after pruning
over SegWit.
Thanks
^ permalink raw reply [relevance 99%]
Results 1-42 of 42 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2016-05-09 8:26 [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd
2016-05-11 20:06 ` Bob McElrath
2016-05-11 20:29 ` Bob McElrath
2016-07-28 21:07 99% ` Leo Wandersleb
2016-05-26 2:50 [bitcoin-dev] BIP Number Request: Open Asset Nicolas Dorier
2016-05-26 3:53 ` Luke Dashjr
2016-07-05 17:46 99% ` Peter Todd
2016-07-06 1:22 99% ` Luke Dashjr
2016-07-06 2:14 99% ` James MacWhyte
2016-07-06 6:49 99% ` Alex Mizrahi
2016-06-15 0:14 [bitcoin-dev] Merkle trees and mountain ranges Bram Cohen
2016-06-16 0:10 ` Peter Todd
2016-06-16 1:16 ` Bram Cohen
2016-06-16 3:26 ` Peter Todd
2016-06-16 9:07 ` Bram Cohen
2016-06-17 4:34 ` Peter Todd
2016-06-18 2:43 ` Bram Cohen
2016-06-18 23:01 ` Peter Todd
2016-07-15 23:00 99% ` Bram Cohen
2016-06-28 2:31 [bitcoin-dev] BIP 151 use of HMAC_SHA512 Rusty Russell
2016-06-28 7:17 ` [bitcoin-dev] BIP 151 Eric Voskuil
2016-06-28 8:26 ` Jonas Schnelli
2016-06-28 19:55 ` Gregory Maxwell
2016-06-28 23:33 ` Eric Voskuil
2016-06-29 1:01 ` Gregory Maxwell
2016-06-30 9:57 ` Eric Voskuil
2016-06-30 13:36 ` Erik Aronesty
2016-07-02 9:44 99% ` Chris Priest
2016-06-28 7:19 ` [bitcoin-dev] BIP 151 use of HMAC_SHA512 Jonas Schnelli
2016-06-29 1:00 ` Rusty Russell
2016-06-29 1:56 ` Ethan Heilman
2016-07-01 3:25 99% ` Rusty Russell
2016-07-01 22:42 99% ` Zooko Wilcox
2016-07-04 1:23 99% ` Arthur Chen
2016-07-04 1:44 99% ` Arthur Chen
2016-07-04 6:47 99% ` Jonas Schnelli
2016-07-04 6:37 99% ` Jonas Schnelli
2016-06-28 16:22 [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd Johnson Lau
2016-07-02 18:43 99% ` Peter Todd
2016-07-02 19:20 99% ` Johnson Lau
2016-07-04 23:27 99% ` Peter Todd
2016-07-15 16:08 99% [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113 Luke Dashjr
2016-07-15 16:31 99% ` Peter Todd
2016-07-20 4:35 99% [bitcoin-dev] BIP draft: HTLC transactions Sean Bowe
2016-07-20 5:46 99% ` Peter Todd
2016-07-20 6:17 99% ` Luke Dashjr
2016-07-20 8:07 99% [bitcoin-dev] Bitcoin Core 0.13.0 release candidate 1 available Wladimir J. van der Laan
2016-07-26 12:47 99% [bitcoin-dev] Reasons to add sync flags to Bitcoin Moral Agent
2016-07-26 13:51 99% ` Tom
2016-07-26 17:27 99% ` Erik Aronesty
2016-07-26 22:03 99% ` Nick ODell
2016-07-27 14:42 99% ` Moral Agent
2016-07-28 16:41 99% ` Moral Agent
2016-07-26 18:31 99% [bitcoin-dev] BIP proposal: derived mnemonics millibitcoin
2016-07-26 20:10 99% ` Jonas Schnelli
2016-07-27 10:39 99% ` Jochen Hoenicke
2016-07-27 10:53 99% ` Jonas Schnelli
2016-07-27 20:59 99% ` Gregory Maxwell
2016-07-26 20:58 99% [bitcoin-dev] Reasons to add sync flags to Bitcoin Martijn Meijering
2016-07-26 21:45 99% ` Tier Nolan
2016-07-30 23:18 99% [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ? Paul Sztorc
2016-07-31 1:31 99% ` Bryan Bishop
2016-07-31 5:18 99% ` Luke Dashjr
2016-07-31 2:03 99% [bitcoin-dev] BIP114 MAST updated Johnson Lau
2016-07-31 13:44 99% [bitcoin-dev] Bitcoin Core 0.13.0 release candidate 2 available Wladimir J. van der Laan
2016-07-31 18:01 99% [bitcoin-dev] Proposal: Hard fork opt-out bits Tom Harding
2016-08-01 9:30 99% [bitcoin-dev] Introducing Flexible Transactions Tom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox