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

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 > si

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

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 fa

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

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 s

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

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

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

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 d

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

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 op

[bitcoin-dev] Optimization of Codes for Electrum

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 yo

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

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, si

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

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.

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

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 desi

[bitcoin-dev] Simplicity: An alternative to Script

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

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

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 euphemismsanctuarysecti

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

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, > > > >

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

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/checksu

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

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

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

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

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

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-de

[bitcoin-dev] Visually Differentiable - Bitcoin Addresses

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 tak