Re: [bitcoin-dev] Simplicity: An alternative to Script

[Gregory Maxwell via bitcoin-dev]

On Mon, Oct 30, 2017 at 9:42 PM, Matt Corallo via bitcoin-dev
 wrote:
> I admittedly haven't had a chance to read the paper in full details, but I
> was curious how you propose dealing with "jets" in something like Bitcoin.
> AFAIU, other similar systems are left doing hard-forks to reduce the
> sigops/weight/fee-cost of transactions every time they want to add useful
> optimized drop-ins. For obvious reasons, this seems rather impractical and a
> potentially critical barrier to adoption of such optimized drop-ins, which I
> imagine would be required to do any new cryptographic algorithms due to the
> significant fee cost of interpreting such things.

For some framing-- I think we're still a long way off from proposing
something like this in Bitcoin, and _how_ it's ultimately proposed is
an open question.

There are many ways to use simplicity, for an extreme example:  one
could define a collection of high level operations and combinators at
the level of things in Bitcoin Script (op_sha256, op_equal, op_cat,
etc.)  and make an interpreter that implements these operations as
discounted jets and ONLY these operations at all.

At that point you have a system which is functionally like Bitcoin
Script-- with the same performance characteristics-- but with a pretty
much perfectly rigorous formal specification and which is highly
amenable to the formal analysis of smart contracts written in it.

At the other extreme, you expose a full on Bitmachine and allow
arbitrary simplicity--  But this is probably slow enough to not be
very useful.  Simplicity itself is so simple that it doesn't natively
have a concept of a _bit_, library code programs the concept of a bit,
then the concept of a half adder ... and so on.   As a result a
completely unjetted implementation is slow (actually remarkably fast
considering that it's effectively interpreting a circuit constructed
from pure logic).

The most useful way of using it would probably be in-between: a good
collection of high level functions, and mid-level functions (e.g.
arithmetic and string operations) making a wide space of useful but
general software both possible and high performance.  But to get there
we need enough experience with it to know what the requisite
collection of operations would be.

One challenge is that I don't think we have a clear mental model for
how nominal validation costs are allowed to be before there is a
negative impact.  It's probably safe to assume 'pretty darn nominal'
is a requirement, but there is still a lot that can be done within
that envelope.

As far as consensus discounted jets goes:

>From my perspective there are three related ideas around this:

Is a particular script-root jetted or not in an implementation?
 -- In and of itself this is not of consensus consequence; esp.
because a major design feature of simplicity is that it should be
possible using to prove that an optimized C implementation of a
simplicity program is complete and correct (using VST+COQ).

Is a particular script-root 'standard and known' in the P2P network:
 -- This means that you can skip communicating it when sending
witnesses to peers; but this is something that could be negotiated on
a peer by peer basis-- like compressing transactions, and isn't at all
consensus normative.

Is a particular jet discounted and what are the discounts:
 -- This is inherently a consensus question; as the bitmachine costing
for a program is consensus normative (assuming that you allow
arbitrary simplicity code at all).

A script-versioning like mechanism can provide for a straight-forward
way to upgrade discounted cost tables in a compatible way--  if you're
running old software that doesn't have the required jets to justify a
particular discount collection -- well that's okay, you won't validate
those scripts at all. (so they'll be super fast for you!)

Another potential tool is the idea of sunsetting cost limits that
sunset; e.g. after N years, the limits go away with an assumption that
updated limits have been softforked in that ativate at that time and
themselves expire in N years.  Old software would become slower
validating due to newly discounted code they lack jets for... but
would continue validating (at least until they run out of performance
headroom).

This is theoretically attractive in a number of regards, but
unfortunately I think our industry hasn't shown sufficient maturity
about engineering tradeoffs to make this a politically viable choice
in the mid-term-- I known I'm personally uncomfortable with the
outspokenness of parties that hold positions which I think can fairly
be summarized "We should remove all limits and if the system crashes
and burns as a result, we'll just make a new one! YOLO.". But it's
interesting to think about in the long term.

There are also hybrid approaches where you can imagine this decision
being made by node operators, e.g. continuing to validate code that
exceeds your effort limits on probabilistic and best effort basis;
even more 

Re: [bitcoin-dev] Simplicity: An alternative to Script

[Matt Corallo via bitcoin-dev]

OK, fair enough, just wanted to make sure we were on the same page.
"Thorny issues there and there hasn't been a ton of effort put into what
Bitcoin integration and maintainability looks like" is a perfectly fair
response :)

Matt

On 10/30/17 18:32, Mark Friedenbach wrote:
> I was just making a factual observation/correction. This is Russell’s project 
> and I don’t want to speak for him. Personally I don’t think the particulars 
> of bitcoin integration design space have been thoroughly explored enough to 
> predict the exact approach that will be used.
> 
> It is possible to support a standard library of jets that are general purpose 
> enough to allow the validation of new crypto primitives, like reusing sha2 to 
> make Lamport signatures. Or use curve-agnostic jets to do Weil pairing 
> validation. Or string manipulation and serialization jets to implement 
> covenants. So I don’t think the situation is as dire as you make it sound.
> 
>> On Oct 30, 2017, at 3:14 PM, Matt Corallo  wrote:
>>
>> Are you anticipating it will be reasonably possible to execute more
>> complicated things in interpreted form even after "jets" are put in
>> place? If not its just a soft-fork to add new script operations and
>> going through the effort of making them compatible with existing code
>> and using a full 32 byte hash to represent them seems wasteful - might
>> as well just add a "SHA256 opcode".
>>
>> Either way it sounds like you're assuming a pretty aggressive soft-fork
>> cadence? I'm not sure if that's so practical right now (or are you
>> thinking it would be more practical if things were
>> drop-in-formally-verified-equivalent-replacements?).
>>
>> Matt
>>
>>> On 10/30/17 17:56, Mark Friedenbach wrote:
>>> Script versions makes this no longer a hard-fork to do. The script
>>> version would implicitly encode which jets are optimized, and what their
>>> optimized cost is.
>>>
 On Oct 30, 2017, at 2:42 PM, Matt Corallo via bitcoin-dev
 >>> > wrote:

 I admittedly haven't had a chance to read the paper in full details,
 but I was curious how you propose dealing with "jets" in something
 like Bitcoin. AFAIU, other similar systems are left doing hard-forks
 to reduce the sigops/weight/fee-cost of transactions every time they
 want to add useful optimized drop-ins. For obvious reasons, this seems
 rather impractical and a potentially critical barrier to adoption of
 such optimized drop-ins, which I imagine would be required to do any
 new cryptographic algorithms due to the significant fee cost of
 interpreting such things.

 Is there some insight I'm missing here?

 Matt

 On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev
 >>> > wrote:

I've been working on the design and implementation of an
alternative to Bitcoin Script, which I call Simplicity.  Today, I
am presenting my design at the PLAS 2017 Workshop
 on Programming Languages and
Analysis for Security.  You find a copy of my Simplicity paper at
https://blockstream.com/simplicity.pdf


Simplicity is a low-level, typed, functional, native MAST language
where programs are built from basic combinators.  Like Bitcoin
Script, Simplicity is designed to operate at the consensus layer. 
While one can write Simplicity by hand, it is expected to be the
target of one, or multiple, front-end languages.

Simplicity comes with formal denotational semantics (i.e.
semantics of what programs compute) and formal operational
semantics (i.e. semantics of how programs compute). These are both
formalized in the Coq proof assistant and proven equivalent.

Formal denotational semantics are of limited value unless one can
use them in practice to reason about programs. I've used
Simplicity's formal semantics to prove correct an implementation
of the SHA-256 compression function written in Simplicity.  I have
also implemented a variant of ECDSA signature verification in
Simplicity, and plan to formally validate its correctness along
with the associated elliptic curve operations.

Simplicity comes with easy to compute static analyses that can
compute bounds on the space and time resources needed for
evaluation.  This is important for both node operators, so that
the costs are knows before evaluation, and for designing
Simplicity programs, so that smart-contract participants can know
the costs of their contract before committing to it.

As a native MAST language, unused branches of Simplicity programs
are pruned at redemption time.  This enhances privacy, reduces t

Re: [bitcoin-dev] Simplicity: An alternative to Script

[Mark Friedenbach via bitcoin-dev]

I was just making a factual observation/correction. This is Russell’s project 
and I don’t want to speak for him. Personally I don’t think the particulars of 
bitcoin integration design space have been thoroughly explored enough to 
predict the exact approach that will be used.

It is possible to support a standard library of jets that are general purpose 
enough to allow the validation of new crypto primitives, like reusing sha2 to 
make Lamport signatures. Or use curve-agnostic jets to do Weil pairing 
validation. Or string manipulation and serialization jets to implement 
covenants. So I don’t think the situation is as dire as you make it sound.

> On Oct 30, 2017, at 3:14 PM, Matt Corallo  wrote:
> 
> Are you anticipating it will be reasonably possible to execute more
> complicated things in interpreted form even after "jets" are put in
> place? If not its just a soft-fork to add new script operations and
> going through the effort of making them compatible with existing code
> and using a full 32 byte hash to represent them seems wasteful - might
> as well just add a "SHA256 opcode".
> 
> Either way it sounds like you're assuming a pretty aggressive soft-fork
> cadence? I'm not sure if that's so practical right now (or are you
> thinking it would be more practical if things were
> drop-in-formally-verified-equivalent-replacements?).
> 
> Matt
> 
>> On 10/30/17 17:56, Mark Friedenbach wrote:
>> Script versions makes this no longer a hard-fork to do. The script
>> version would implicitly encode which jets are optimized, and what their
>> optimized cost is.
>> 
>>> On Oct 30, 2017, at 2:42 PM, Matt Corallo via bitcoin-dev
>>> >> > wrote:
>>> 
>>> I admittedly haven't had a chance to read the paper in full details,
>>> but I was curious how you propose dealing with "jets" in something
>>> like Bitcoin. AFAIU, other similar systems are left doing hard-forks
>>> to reduce the sigops/weight/fee-cost of transactions every time they
>>> want to add useful optimized drop-ins. For obvious reasons, this seems
>>> rather impractical and a potentially critical barrier to adoption of
>>> such optimized drop-ins, which I imagine would be required to do any
>>> new cryptographic algorithms due to the significant fee cost of
>>> interpreting such things.
>>> 
>>> Is there some insight I'm missing here?
>>> 
>>> Matt
>>> 
>>> On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev
>>> >> > wrote:
>>> 
>>>I've been working on the design and implementation of an
>>>alternative to Bitcoin Script, which I call Simplicity.  Today, I
>>>am presenting my design at the PLAS 2017 Workshop
>>> on Programming Languages and
>>>Analysis for Security.  You find a copy of my Simplicity paper at
>>>https://blockstream.com/simplicity.pdf
>>>
>>> 
>>>Simplicity is a low-level, typed, functional, native MAST language
>>>where programs are built from basic combinators.  Like Bitcoin
>>>Script, Simplicity is designed to operate at the consensus layer. 
>>>While one can write Simplicity by hand, it is expected to be the
>>>target of one, or multiple, front-end languages.
>>> 
>>>Simplicity comes with formal denotational semantics (i.e.
>>>semantics of what programs compute) and formal operational
>>>semantics (i.e. semantics of how programs compute). These are both
>>>formalized in the Coq proof assistant and proven equivalent.
>>> 
>>>Formal denotational semantics are of limited value unless one can
>>>use them in practice to reason about programs. I've used
>>>Simplicity's formal semantics to prove correct an implementation
>>>of the SHA-256 compression function written in Simplicity.  I have
>>>also implemented a variant of ECDSA signature verification in
>>>Simplicity, and plan to formally validate its correctness along
>>>with the associated elliptic curve operations.
>>> 
>>>Simplicity comes with easy to compute static analyses that can
>>>compute bounds on the space and time resources needed for
>>>evaluation.  This is important for both node operators, so that
>>>the costs are knows before evaluation, and for designing
>>>Simplicity programs, so that smart-contract participants can know
>>>the costs of their contract before committing to it.
>>> 
>>>As a native MAST language, unused branches of Simplicity programs
>>>are pruned at redemption time.  This enhances privacy, reduces the
>>>block weight used, and can reduce space and time resource costs
>>>needed for evaluation.
>>> 
>>>To make Simplicity practical, jets replace common Simplicity
>>>expressions (identified by their MAST root) and directly implement
>>>them with C code.  I anticipate developing a broad set of useful
>>>jets covering arithmetic operat

Re: [bitcoin-dev] Simplicity: An alternative to Script

[Matt Corallo via bitcoin-dev]

Are you anticipating it will be reasonably possible to execute more
complicated things in interpreted form even after "jets" are put in
place? If not its just a soft-fork to add new script operations and
going through the effort of making them compatible with existing code
and using a full 32 byte hash to represent them seems wasteful - might
as well just add a "SHA256 opcode".

Either way it sounds like you're assuming a pretty aggressive soft-fork
cadence? I'm not sure if that's so practical right now (or are you
thinking it would be more practical if things were
drop-in-formally-verified-equivalent-replacements?).

Matt

On 10/30/17 17:56, Mark Friedenbach wrote:
> Script versions makes this no longer a hard-fork to do. The script
> version would implicitly encode which jets are optimized, and what their
> optimized cost is.
> 
>> On Oct 30, 2017, at 2:42 PM, Matt Corallo via bitcoin-dev
>> > > wrote:
>>
>> I admittedly haven't had a chance to read the paper in full details,
>> but I was curious how you propose dealing with "jets" in something
>> like Bitcoin. AFAIU, other similar systems are left doing hard-forks
>> to reduce the sigops/weight/fee-cost of transactions every time they
>> want to add useful optimized drop-ins. For obvious reasons, this seems
>> rather impractical and a potentially critical barrier to adoption of
>> such optimized drop-ins, which I imagine would be required to do any
>> new cryptographic algorithms due to the significant fee cost of
>> interpreting such things.
>>
>> Is there some insight I'm missing here?
>>
>> Matt
>>
>> On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev
>> > > wrote:
>>
>> I've been working on the design and implementation of an
>> alternative to Bitcoin Script, which I call Simplicity.  Today, I
>> am presenting my design at the PLAS 2017 Workshop
>>  on Programming Languages and
>> Analysis for Security.  You find a copy of my Simplicity paper at
>> https://blockstream.com/simplicity.pdf
>> 
>>
>> Simplicity is a low-level, typed, functional, native MAST language
>> where programs are built from basic combinators.  Like Bitcoin
>> Script, Simplicity is designed to operate at the consensus layer. 
>> While one can write Simplicity by hand, it is expected to be the
>> target of one, or multiple, front-end languages.
>>
>> Simplicity comes with formal denotational semantics (i.e.
>> semantics of what programs compute) and formal operational
>> semantics (i.e. semantics of how programs compute). These are both
>> formalized in the Coq proof assistant and proven equivalent.
>>
>> Formal denotational semantics are of limited value unless one can
>> use them in practice to reason about programs. I've used
>> Simplicity's formal semantics to prove correct an implementation
>> of the SHA-256 compression function written in Simplicity.  I have
>> also implemented a variant of ECDSA signature verification in
>> Simplicity, and plan to formally validate its correctness along
>> with the associated elliptic curve operations.
>>
>> Simplicity comes with easy to compute static analyses that can
>> compute bounds on the space and time resources needed for
>> evaluation.  This is important for both node operators, so that
>> the costs are knows before evaluation, and for designing
>> Simplicity programs, so that smart-contract participants can know
>> the costs of their contract before committing to it.
>>
>> As a native MAST language, unused branches of Simplicity programs
>> are pruned at redemption time.  This enhances privacy, reduces the
>> block weight used, and can reduce space and time resource costs
>> needed for evaluation.
>>
>> To make Simplicity practical, jets replace common Simplicity
>> expressions (identified by their MAST root) and directly implement
>> them with C code.  I anticipate developing a broad set of useful
>> jets covering arithmetic operations, elliptic curve operations,
>> and cryptographic operations including hashing and digital
>> signature validation.
>>
>> The paper I am presenting at PLAS describes only the foundation of
>> the Simplicity language.  The final design includes extensions not
>> covered in the paper, including
>>
>> - full convent support, allowing access to all transaction data.
>> - support for signature aggregation.
>> - support for delegation.
>>
>> Simplicity is still in a research and development phase.  I'm
>> working to produce a bare-bones SDK that will include
>>
>> - the formal semantics and correctness proofs in Coq
>> - a Haskell implementation for constructing Simplicity programs
>> - and a C interpreter for Simplicity.
>>
>>

Re: [bitcoin-dev] Simplicity: An alternative to Script

[Mark Friedenbach via bitcoin-dev]

Script versions makes this no longer a hard-fork to do. The script version 
would implicitly encode which jets are optimized, and what their optimized cost 
is.

> On Oct 30, 2017, at 2:42 PM, Matt Corallo via bitcoin-dev 
>  wrote:
> 
> I admittedly haven't had a chance to read the paper in full details, but I 
> was curious how you propose dealing with "jets" in something like Bitcoin. 
> AFAIU, other similar systems are left doing hard-forks to reduce the 
> sigops/weight/fee-cost of transactions every time they want to add useful 
> optimized drop-ins. For obvious reasons, this seems rather impractical and a 
> potentially critical barrier to adoption of such optimized drop-ins, which I 
> imagine would be required to do any new cryptographic algorithms due to the 
> significant fee cost of interpreting such things.
> 
> Is there some insight I'm missing here?
> 
> Matt
> 
> On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev 
>  wrote:
> I've been working on the design and implementation of an alternative to 
> Bitcoin Script, which I call Simplicity.  Today, I am presenting my design at 
> the PLAS 2017 Workshop  on Programming 
> Languages and Analysis for Security.  You find a copy of my Simplicity paper 
> at https://blockstream.com/simplicity.pdf 
> 
> 
> Simplicity is a low-level, typed, functional, native MAST language where 
> programs are built from basic combinators.  Like Bitcoin Script, Simplicity 
> is designed to operate at the consensus layer.  While one can write 
> Simplicity by hand, it is expected to be the target of one, or multiple, 
> front-end languages.
> 
> Simplicity comes with formal denotational semantics (i.e. semantics of what 
> programs compute) and formal operational semantics (i.e. semantics of how 
> programs compute). These are both formalized in the Coq proof assistant and 
> proven equivalent.
> 
> Formal denotational semantics are of limited value unless one can use them in 
> practice to reason about programs. I've used Simplicity's formal semantics to 
> prove correct an implementation of the SHA-256 compression function written 
> in Simplicity.  I have also implemented a variant of ECDSA signature 
> verification in Simplicity, and plan to formally validate its correctness 
> along with the associated elliptic curve operations.
> 
> Simplicity comes with easy to compute static analyses that can compute bounds 
> on the space and time resources needed for evaluation.  This is important for 
> both node operators, so that the costs are knows before evaluation, and for 
> designing Simplicity programs, so that smart-contract participants can know 
> the costs of their contract before committing to it.
> 
> As a native MAST language, unused branches of Simplicity programs are pruned 
> at redemption time.  This enhances privacy, reduces the block weight used, 
> and can reduce space and time resource costs needed for evaluation.
> 
> To make Simplicity practical, jets replace common Simplicity expressions 
> (identified by their MAST root) and directly implement them with C code.  I 
> anticipate developing a broad set of useful jets covering arithmetic 
> operations, elliptic curve operations, and cryptographic operations including 
> hashing and digital signature validation.
> 
> The paper I am presenting at PLAS describes only the foundation of the 
> Simplicity language.  The final design includes extensions not covered in the 
> paper, including
> 
> - full convent support, allowing access to all transaction data.
> - support for signature aggregation.
> - support for delegation.
> 
> Simplicity is still in a research and development phase.  I'm working to 
> produce a bare-bones SDK that will include 
> 
> - the formal semantics and correctness proofs in Coq
> - a Haskell implementation for constructing Simplicity programs
> - and a C interpreter for Simplicity.
> 
> After an SDK is complete the next step will be making Simplicity available in 
> the Elements project  so that anyone can start 
> experimenting with Simplicity in sidechains. Only after extensive vetting 
> would it be suitable to consider Simplicity for inclusion in Bitcoin.
> 
> Simplicity has a long ways to go still, and this work is not intended to 
> delay consideration of the various Merkelized Script proposals that are 
> currently ongoing.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Simplicity: An alternative to Script

[Matt Corallo via bitcoin-dev]

I admittedly haven't had a chance to read the paper in full details, but I was 
curious how you propose dealing with "jets" in something like Bitcoin. AFAIU, 
other similar systems are left doing hard-forks to reduce the 
sigops/weight/fee-cost of transactions every time they want to add useful 
optimized drop-ins. For obvious reasons, this seems rather impractical and a 
potentially critical barrier to adoption of such optimized drop-ins, which I 
imagine would be required to do any new cryptographic algorithms due to the 
significant fee cost of interpreting such things.

Is there some insight I'm missing here?

Matt

On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev 
 wrote:
>I've been working on the design and implementation of an alternative to
>Bitcoin Script, which I call Simplicity.  Today, I am presenting my
>design
>at the PLAS 2017 Workshop  on
>Programming
>Languages and Analysis for Security.  You find a copy of my Simplicity
>paper at https://blockstream.com/simplicity.pdf
>
>Simplicity is a low-level, typed, functional, native MAST language
>where
>programs are built from basic combinators.  Like Bitcoin Script,
>Simplicity
>is designed to operate at the consensus layer.  While one can write
>Simplicity by hand, it is expected to be the target of one, or
>multiple,
>front-end languages.
>
>Simplicity comes with formal denotational semantics (i.e. semantics of
>what
>programs compute) and formal operational semantics (i.e. semantics of
>how
>programs compute). These are both formalized in the Coq proof assistant
>and
>proven equivalent.
>
>Formal denotational semantics are of limited value unless one can use
>them
>in practice to reason about programs. I've used Simplicity's formal
>semantics to prove correct an implementation of the SHA-256 compression
>function written in Simplicity.  I have also implemented a variant of
>ECDSA
>signature verification in Simplicity, and plan to formally validate its
>correctness along with the associated elliptic curve operations.
>
>Simplicity comes with easy to compute static analyses that can compute
>bounds on the space and time resources needed for evaluation.  This is
>important for both node operators, so that the costs are knows before
>evaluation, and for designing Simplicity programs, so that
>smart-contract
>participants can know the costs of their contract before committing to
>it.
>
>As a native MAST language, unused branches of Simplicity programs are
>pruned at redemption time.  This enhances privacy, reduces the block
>weight
>used, and can reduce space and time resource costs needed for
>evaluation.
>
>To make Simplicity practical, jets replace common Simplicity
>expressions
>(identified by their MAST root) and directly implement them with C
>code.  I
>anticipate developing a broad set of useful jets covering arithmetic
>operations, elliptic curve operations, and cryptographic operations
>including hashing and digital signature validation.
>
>The paper I am presenting at PLAS describes only the foundation of the
>Simplicity language.  The final design includes extensions not covered
>in
>the paper, including
>
>- full convent support, allowing access to all transaction data.
>- support for signature aggregation.
>- support for delegation.
>
>Simplicity is still in a research and development phase.  I'm working
>to
>produce a bare-bones SDK that will include
>
>- the formal semantics and correctness proofs in Coq
>- a Haskell implementation for constructing Simplicity programs
>- and a C interpreter for Simplicity.
>
>After an SDK is complete the next step will be making Simplicity
>available
>in the Elements project  so that anyone
>can
>start experimenting with Simplicity in sidechains. Only after extensive
>vetting would it be suitable to consider Simplicity for inclusion in
>Bitcoin.
>
>Simplicity has a long ways to go still, and this work is not intended
>to
>delay consideration of the various Merkelized Script proposals that are
>currently ongoing.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Optimization of Codes for Electrum

[Daryl - . via bitcoin-dev]

Dear Bitcoin-Dev,

I’m writing in to enquire on the post 
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/002916.html) 
and I’d like to seek your help and understanding on the codes you modified in 
order to optimize the syncing of blockchain. For instance, the functions that 
you modified/variables/values that may lead to a better performance. I’m 
currently working on further optimising Electrum in terms of syncing and any 
help will be greatly appreciated.

Thank you and I really look forward to your prompt reply soon.

Regards,
Daryl
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Moral Agent via bitcoin-dev]

Or like keyart:
https://pthree.org/2014/04/18/the-drunken-bishop-for-openpgp-keys/

Images would definitely be quicker to verify by a human, but I don't think
humans can RELIABLY verify anything close to 25 bytes through an image.

Our visual processing system is designed wrong for this purpose, since it
subconsciously "corrects" visual input to whatever we expect to see.

It isn't enough to say that any small change produces a "significantly"
different image. What you need is for it to be (practically) impossible to
construct an image that looks similar but is wrong, which is a far higher
standard. For example, any change to a private key renders a significantly
different address -- but it is possible for an attacker to grind their way
to a similar-looking address.

I would recommend displaying 16 words in a 4 x 4 grid, but otherwise with
no visual distractions.

For example, don't provide an image next to the words as a help. Don't use
colors to differentiate two different sets of 16 words. What will happen is
people will see a pattern that triggers a sensation of familiarity, and
they will not carefully verify all of the words -- which is what security
requires.

For higher security keys, you could grind an address with enough zeros at
the beginning to be expressed by fewer words. For example, you could grind
to an address that could be fully expressed with a 12 word (4 x 3) grid
that would be easier for a human to verify reliably.

On Mon, Oct 30, 2017 at 12:15 PM, Danny Thorpe 
wrote:

> Humans are very visually oriented, recognizing differences in images more
> easily than differences in text.
>
> What about generating an image based on the bytes of an address, using
> something like identicon, used by gravatar? Any small change to the text
> input produces a significantly different image.
>
> -Danny
>
> On Oct 30, 2017 7:43 AM, "Moral Agent via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> If you are going to rely on human verification of addresses, the best way
>> might be map it to words.
>>
>> For example, with a 6000 word list, a 25 byte address (with a checksum)
>> could be mapped to 16 words like this:
>>
>> vocally   acquireremoved unfounded
>> euphemismsanctuarysectional driving
>> entreefrecklesaloof   vertebrae
>> scribble  surround  prelaw effort
>>
>> In my opinion, that is much faster to verify than this:
>>
>> 13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ
>>
>> or
>>
>> bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
>>
>> Although I really do love Bech32.
>>
>> On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
>>> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is
>>> 62 bytes ! This is very very long. This will create lot of usability
>>> problems in
>>>
>>> - Blockexplorers (atleast user should be visually able to compare in a
>>> transaction having multiple outputs which one his address)
>>> - Mobiles
>>> - Payment terminals
>>>
>>> From my limited understanding, the purpose of inventing a bitcoin
>>> address format is for usability and ease of identification (versus a ECDSA
>>> public key), While I get the error/checksum capabilities Bech32 brings, any
>>> user would prefer a 20 byte address with a checksum  over an address that
>>> would wrap several lines !!
>>>
>>>
>>> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
>>> thompson.benedictja...@gmail.com> wrote:
>>>
 Checking the first few bytes of a Bitcoin Address should not be
 considered sufficient for ensuring that it is correct as it takes less than
 a second to generate a 3 character vanity address that matches the first 3
 characters of an address.

 On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> When I copy and paste bitcoin address, I double check the first few
> bytes, to make sure I copied the correct one. This is to make sure some
> rogue software is not changing the address, or I incorrectly pasted the
> wrong address.
>
>
> With Bech32 address, its seems like in this department we are taking
> as step in the backward direction. With the traditional address, I could
> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can 
> see
> and compare which is likely to be same anyway. Note that most users will
> only compare the first few bytes only (since addresses themselves are very
> long and will overflow in a mobile text box).
>
> Is there anyway to make the Bech32 addresses format more visually
> distinct (atleast the first few bytes) ?
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.or

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Danny Thorpe via bitcoin-dev]

Humans are very visually oriented, recognizing differences in images more
easily than differences in text.

What about generating an image based on the bytes of an address, using
something like identicon, used by gravatar? Any small change to the text
input produces a significantly different image.

-Danny

On Oct 30, 2017 7:43 AM, "Moral Agent via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If you are going to rely on human verification of addresses, the best way
> might be map it to words.
>
> For example, with a 6000 word list, a 25 byte address (with a checksum)
> could be mapped to 16 words like this:
>
> vocally   acquireremoved unfounded
> euphemismsanctuarysectional driving
> entreefrecklesaloof   vertebrae
> scribble  surround  prelaw effort
>
> In my opinion, that is much faster to verify than this:
>
> 13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ
>
> or
>
> bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
>
> Although I really do love Bech32.
>
> On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
>> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is
>> 62 bytes ! This is very very long. This will create lot of usability
>> problems in
>>
>> - Blockexplorers (atleast user should be visually able to compare in a
>> transaction having multiple outputs which one his address)
>> - Mobiles
>> - Payment terminals
>>
>> From my limited understanding, the purpose of inventing a bitcoin address
>> format is for usability and ease of identification (versus a ECDSA public
>> key), While I get the error/checksum capabilities Bech32 brings, any user
>> would prefer a 20 byte address with a checksum  over an address that would
>> wrap several lines !!
>>
>>
>> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
>> thompson.benedictja...@gmail.com> wrote:
>>
>>> Checking the first few bytes of a Bitcoin Address should not be
>>> considered sufficient for ensuring that it is correct as it takes less than
>>> a second to generate a 3 character vanity address that matches the first 3
>>> characters of an address.
>>>
>>> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Hi,

 When I copy and paste bitcoin address, I double check the first few
 bytes, to make sure I copied the correct one. This is to make sure some
 rogue software is not changing the address, or I incorrectly pasted the
 wrong address.


 With Bech32 address, its seems like in this department we are taking as
 step in the backward direction. With the traditional address, I could
 compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
 and compare which is likely to be same anyway. Note that most users will
 only compare the first few bytes only (since addresses themselves are very
 long and will overflow in a mobile text box).

 Is there anyway to make the Bech32 addresses format more visually
 distinct (atleast the first few bytes) ?
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Simplicity: An alternative to Script

[Mark Friedenbach via bitcoin-dev]

So enthused that this is public now! Great work. 

Sent from my iPhone

> On Oct 30, 2017, at 8:22 AM, Russell O'Connor via bitcoin-dev 
>  wrote:
> 
> I've been working on the design and implementation of an alternative to 
> Bitcoin Script, which I call Simplicity.  Today, I am presenting my design at 
> the PLAS 2017 Workshop on Programming Languages and Analysis for Security.  
> You find a copy of my Simplicity paper at 
> https://blockstream.com/simplicity.pdf
> 
> Simplicity is a low-level, typed, functional, native MAST language where 
> programs are built from basic combinators.  Like Bitcoin Script, Simplicity 
> is designed to operate at the consensus layer.  While one can write 
> Simplicity by hand, it is expected to be the target of one, or multiple, 
> front-end languages.
> 
> Simplicity comes with formal denotational semantics (i.e. semantics of what 
> programs compute) and formal operational semantics (i.e. semantics of how 
> programs compute). These are both formalized in the Coq proof assistant and 
> proven equivalent.
> 
> Formal denotational semantics are of limited value unless one can use them in 
> practice to reason about programs. I've used Simplicity's formal semantics to 
> prove correct an implementation of the SHA-256 compression function written 
> in Simplicity.  I have also implemented a variant of ECDSA signature 
> verification in Simplicity, and plan to formally validate its correctness 
> along with the associated elliptic curve operations.
> 
> Simplicity comes with easy to compute static analyses that can compute bounds 
> on  the space and time resources needed for evaluation.  This is important 
> for both node operators, so that the costs are knows before evaluation, and 
> for designing Simplicity programs, so that smart-contract  participants can 
> know the costs of their contract before committing to it.
> 
> As a native MAST language, unused branches of Simplicity programs are pruned 
> at redemption time.  This enhances privacy, reduces the block weight used, 
> and can reduce space and time resource costs needed for evaluation.
> 
> To make Simplicity practical, jets replace common Simplicity expressions 
> (identified by their MAST root) and directly implement them with C code.  I 
> anticipate developing a broad set of useful jets covering arithmetic 
> operations, elliptic curve operations, and cryptographic operations including 
> hashing and digital signature validation.
> 
> The paper I am presenting at PLAS describes only the foundation of the 
> Simplicity language.  The final design includes extensions not covered in the 
> paper, including
> 
> - full convent support, allowing access to all transaction data.
> - support for signature aggregation.
> - support for delegation.
> 
> Simplicity is still in a research and development phase.  I'm working to 
> produce a bare-bones SDK that will include 
> 
> - the formal semantics and correctness proofs in Coq
> - a Haskell implementation for constructing Simplicity programs
> - and a C interpreter for Simplicity.
> 
> After an SDK is complete the next step will be making Simplicity available in 
> the Elements project so that anyone can start experimenting with Simplicity 
> in sidechains. Only after extensive vetting would it be suitable to consider 
> Simplicity for inclusion in Bitcoin.
> 
> Simplicity has a long ways to go still, and this work is not intended to 
> delay consideration of the various Merkelized Script proposals that are 
> currently ongoing.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Simplicity: An alternative to Script

[Russell O'Connor via bitcoin-dev]

I've been working on the design and implementation of an alternative to
Bitcoin Script, which I call Simplicity.  Today, I am presenting my design
at the PLAS 2017 Workshop  on Programming
Languages and Analysis for Security.  You find a copy of my Simplicity
paper at https://blockstream.com/simplicity.pdf

Simplicity is a low-level, typed, functional, native MAST language where
programs are built from basic combinators.  Like Bitcoin Script, Simplicity
is designed to operate at the consensus layer.  While one can write
Simplicity by hand, it is expected to be the target of one, or multiple,
front-end languages.

Simplicity comes with formal denotational semantics (i.e. semantics of what
programs compute) and formal operational semantics (i.e. semantics of how
programs compute). These are both formalized in the Coq proof assistant and
proven equivalent.

Formal denotational semantics are of limited value unless one can use them
in practice to reason about programs. I've used Simplicity's formal
semantics to prove correct an implementation of the SHA-256 compression
function written in Simplicity.  I have also implemented a variant of ECDSA
signature verification in Simplicity, and plan to formally validate its
correctness along with the associated elliptic curve operations.

Simplicity comes with easy to compute static analyses that can compute
bounds on the space and time resources needed for evaluation.  This is
important for both node operators, so that the costs are knows before
evaluation, and for designing Simplicity programs, so that smart-contract
participants can know the costs of their contract before committing to it.

As a native MAST language, unused branches of Simplicity programs are
pruned at redemption time.  This enhances privacy, reduces the block weight
used, and can reduce space and time resource costs needed for evaluation.

To make Simplicity practical, jets replace common Simplicity expressions
(identified by their MAST root) and directly implement them with C code.  I
anticipate developing a broad set of useful jets covering arithmetic
operations, elliptic curve operations, and cryptographic operations
including hashing and digital signature validation.

The paper I am presenting at PLAS describes only the foundation of the
Simplicity language.  The final design includes extensions not covered in
the paper, including

- full convent support, allowing access to all transaction data.
- support for signature aggregation.
- support for delegation.

Simplicity is still in a research and development phase.  I'm working to
produce a bare-bones SDK that will include

- the formal semantics and correctness proofs in Coq
- a Haskell implementation for constructing Simplicity programs
- and a C interpreter for Simplicity.

After an SDK is complete the next step will be making Simplicity available
in the Elements project  so that anyone can
start experimenting with Simplicity in sidechains. Only after extensive
vetting would it be suitable to consider Simplicity for inclusion in
Bitcoin.

Simplicity has a long ways to go still, and this work is not intended to
delay consideration of the various Merkelized Script proposals that are
currently ongoing.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Moral Agent via bitcoin-dev]

If you are going to rely on human verification of addresses, the best way
might be map it to words.

For example, with a 6000 word list, a 25 byte address (with a checksum)
could be mapped to 16 words like this:

vocally   acquireremoved unfounded
euphemismsanctuarysectional driving
entreefrecklesaloof   vertebrae
scribble  surround  prelaw effort

In my opinion, that is much faster to verify than this:

13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ

or

bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3

Although I really do love Bech32.

On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62
> bytes ! This is very very long. This will create lot of usability problems
> in
>
> - Blockexplorers (atleast user should be visually able to compare in a
> transaction having multiple outputs which one his address)
> - Mobiles
> - Payment terminals
>
> From my limited understanding, the purpose of inventing a bitcoin address
> format is for usability and ease of identification (versus a ECDSA public
> key), While I get the error/checksum capabilities Bech32 brings, any user
> would prefer a 20 byte address with a checksum  over an address that would
> wrap several lines !!
>
>
> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
> thompson.benedictja...@gmail.com> wrote:
>
>> Checking the first few bytes of a Bitcoin Address should not be
>> considered sufficient for ensuring that it is correct as it takes less than
>> a second to generate a 3 character vanity address that matches the first 3
>> characters of an address.
>>
>> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi,
>>>
>>> When I copy and paste bitcoin address, I double check the first few
>>> bytes, to make sure I copied the correct one. This is to make sure some
>>> rogue software is not changing the address, or I incorrectly pasted the
>>> wrong address.
>>>
>>>
>>> With Bech32 address, its seems like in this department we are taking as
>>> step in the backward direction. With the traditional address, I could
>>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>>> and compare which is likely to be same anyway. Note that most users will
>>> only compare the first few bytes only (since addresses themselves are very
>>> long and will overflow in a mobile text box).
>>>
>>> Is there anyway to make the Bech32 addresses format more visually
>>> distinct (atleast the first few bytes) ?
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Ben Thompson via bitcoin-dev]

The last few bytes can be generated to be the same also.

On Mon, 30 Oct 2017, 14:20 Ricardo Filipe via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> start double checking the last few bytes instead?
>
> 2017-10-30 8:56 GMT+00:00 shiva sitamraju via bitcoin-dev
> :
> > Hi,
> >
> > When I copy and paste bitcoin address, I double check the first few
> bytes,
> > to make sure I copied the correct one. This is to make sure some rogue
> > software is not changing the address, or I incorrectly pasted the wrong
> > address.
> >
> >
> > With Bech32 address, its seems like in this department we are taking as
> step
> > in the backward direction. With the traditional address, I could compare
> > first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see and
> > compare which is likely to be same anyway. Note that most users will only
> > compare the first few bytes only (since addresses themselves are very
> long
> > and will overflow in a mobile text box).
> >
> > Is there anyway to make the Bech32 addresses format more visually
> distinct
> > (atleast the first few bytes) ?
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Pieter Wuille via bitcoin-dev]

On Oct 30, 2017 15:21, "shiva sitamraju via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62
bytes !


...

While I get the error/checksum capabilities Bech32 brings, any user would
prefer a 20 byte address with a checksum  over an address that would wrap
several lines !!


That's an unfair comparison. You're pasting a P2WSH address which contains
a 256-bit hash.

A P2WPKH address (which only contains a 160-bit hash, just like P2PKH and
P2SH) in Bech32 is only 42 characters, not 62.

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[shiva sitamraju via bitcoin-dev]

For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62
bytes ! This is very very long. This will create lot of usability problems
in

- Blockexplorers (atleast user should be visually able to compare in a
transaction having multiple outputs which one his address)
- Mobiles
- Payment terminals

>From my limited understanding, the purpose of inventing a bitcoin address
format is for usability and ease of identification (versus a ECDSA public
key), While I get the error/checksum capabilities Bech32 brings, any user
would prefer a 20 byte address with a checksum  over an address that would
wrap several lines !!


On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
thompson.benedictja...@gmail.com> wrote:

> Checking the first few bytes of a Bitcoin Address should not be considered
> sufficient for ensuring that it is correct as it takes less than a second
> to generate a 3 character vanity address that matches the first 3
> characters of an address.
>
> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> When I copy and paste bitcoin address, I double check the first few
>> bytes, to make sure I copied the correct one. This is to make sure some
>> rogue software is not changing the address, or I incorrectly pasted the
>> wrong address.
>>
>>
>> With Bech32 address, its seems like in this department we are taking as
>> step in the backward direction. With the traditional address, I could
>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>> and compare which is likely to be same anyway. Note that most users will
>> only compare the first few bytes only (since addresses themselves are very
>> long and will overflow in a mobile text box).
>>
>> Is there anyway to make the Bech32 addresses format more visually
>> distinct (atleast the first few bytes) ?
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Ricardo Filipe via bitcoin-dev]

start double checking the last few bytes instead?

2017-10-30 8:56 GMT+00:00 shiva sitamraju via bitcoin-dev
:
> Hi,
>
> When I copy and paste bitcoin address, I double check the first few bytes,
> to make sure I copied the correct one. This is to make sure some rogue
> software is not changing the address, or I incorrectly pasted the wrong
> address.
>
>
> With Bech32 address, its seems like in this department we are taking as step
> in the backward direction. With the traditional address, I could compare
> first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see and
> compare which is likely to be same anyway. Note that most users will only
> compare the first few bytes only (since addresses themselves are very long
> and will overflow in a mobile text box).
>
> Is there anyway to make the Bech32 addresses format more visually distinct
> (atleast the first few bytes) ?
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[Ben Thompson via bitcoin-dev]

Checking the first few bytes of a Bitcoin Address should not be considered
sufficient for ensuring that it is correct as it takes less than a second
to generate a 3 character vanity address that matches the first 3
characters of an address.

On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> When I copy and paste bitcoin address, I double check the first few bytes,
> to make sure I copied the correct one. This is to make sure some rogue
> software is not changing the address, or I incorrectly pasted the wrong
> address.
>
>
> With Bech32 address, its seems like in this department we are taking as
> step in the backward direction. With the traditional address, I could
> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
> and compare which is likely to be same anyway. Note that most users will
> only compare the first few bytes only (since addresses themselves are very
> long and will overflow in a mobile text box).
>
> Is there anyway to make the Bech32 addresses format more visually distinct
> (atleast the first few bytes) ?
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Visually Differentiable - Bitcoin Addresses

[shiva sitamraju via bitcoin-dev]

Hi,

When I copy and paste bitcoin address, I double check the first few bytes,
to make sure I copied the correct one. This is to make sure some rogue
software is not changing the address, or I incorrectly pasted the wrong
address.


With Bech32 address, its seems like in this department we are taking as
step in the backward direction. With the traditional address, I could
compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
and compare which is likely to be same anyway. Note that most users will
only compare the first few bytes only (since addresses themselves are very
long and will overflow in a mobile text box).

Is there anyway to make the Bech32 addresses format more visually distinct
(atleast the first few bytes) ?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev