From janez at janezurevc.name Mon Feb 5 09:07:33 2018 From: janez at janezurevc.name (Janez Urevc) Date: Mon, 5 Feb 2018 10:07:33 +0100 Subject: [Bitcoin-ml] Formal bitcoin protocol specification - project proposal In-Reply-To: <97112363-ca87-7eb1-25f5-89a33d5aa02f@cispa.saarland> References: <5e1669af-79eb-43f2-7e13-e4750bc6e120@gmail.com> <97112363-ca87-7eb1-25f5-89a33d5aa02f@cispa.saarland> Message-ID: Hi, I'd like to express my interest in this project. I have 10 years of professional experience in software development in open source space. I was leading major initiatives for a big open source project (unrelated to Bitcoin, but still...) where I, among other things, wrote many plans, specification papers, roadmaps, etc. I recently started getting into Bitcoin development and soon realized how big of an improvement a formal secification would be. I also feel that working on a specification project would give me more insight into the protocol and help me learn more about it. If such project and/or workshop would be started I am ready to jump on board and help with it. Best regards, Janez Urevc -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at bitcrust.org Fri Feb 9 20:45:17 2018 From: tomas at bitcrust.org (Tomas) Date: Fri, 09 Feb 2018 21:45:17 +0100 Subject: [Bitcoin-ml] [Research] Masterblocks: Scaling Blockchain by summarizing balances In-Reply-To: <5a84ce8c-1c42-c3ea-2364-b13222bcb3cb@mailbox.org> References: <5a84ce8c-1c42-c3ea-2364-b13222bcb3cb@mailbox.org> Message-ID: <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> On Wed, Jan 10, 2018, at 08:11, Christoph Bergmann via bitcoin-ml wrote:> If I'm not wrong, UTXO commitments allow a node to sync the UTXO only > / to first sync UTXO, than the rest of the chain.> Masterblocks as described here adds a snapshot to cut the length of > the historical blockchain relevant for consensus. The only > cryptocurrency of snapshots I know of is IOTA. If you have the UTXO set and it is committed, you don't need the rest of the chain. The UTXO set *is* the snapshot. Current full node implementations assume that all blocks before some block X are valid and don't verify the signatures. The *only* reason to download them is to update the UTXO state. If X includes a UTXO commitment, (and we've included the rule that if present it must be valid), downloading old blocks becomes pointless. I don't really understand the benefit of adding another block type for this. Tomas van der Wansem -------------- next part -------------- An HTML attachment was scrubbed... URL: From al4321 at gmail.com Fri Feb 9 21:59:09 2018 From: al4321 at gmail.com (Alexey Eromenko) Date: Fri, 9 Feb 2018 23:59:09 +0200 Subject: [Bitcoin-ml] [Research] Masterblocks: Scaling Blockchain by summarizing balances In-Reply-To: <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> References: <5a84ce8c-1c42-c3ea-2364-b13222bcb3cb@mailbox.org> <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> Message-ID: If you don't download all blocks (which includes all UTXO), how do you know balances? You can't ! My idea allows to download only a subset of blocks (all blocks since Masterblock) for a new node setup. On Fri, Feb 9, 2018 at 10:45 PM, Tomas via bitcoin-ml wrote: > > On Wed, Jan 10, 2018, at 08:11, Christoph Bergmann via bitcoin-ml wrote: > > If I'm not wrong, UTXO commitments allow a node to sync the UTXO only / to > first sync UTXO, than the rest of the chain. > > Masterblocks as described here adds a snapshot to cut the length of the > historical blockchain relevant for consensus. The only cryptocurrency of > snapshots I know of is IOTA. > > > If you have the UTXO set and it is committed, you don't need the rest of the > chain. The UTXO set *is* the snapshot. > > Current full node implementations assume that all blocks before some block X > are valid and don't verify the signatures. The *only* reason to download > them is to update the UTXO state. If X includes a UTXO commitment, (and > we've included the rule that if present it must be valid), downloading old > blocks becomes pointless. > > I don't really understand the benefit of adding another block type for this. > > Tomas van der Wansem > > > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -- -Alexey Eromenko "Technologov" From jaredr26 at gmail.com Fri Feb 9 22:30:12 2018 From: jaredr26 at gmail.com (Jared Lee Richardson) Date: Fri, 9 Feb 2018 14:30:12 -0800 Subject: [Bitcoin-ml] [Research] Masterblocks: Scaling Blockchain by summarizing balances In-Reply-To: References: <5a84ce8c-1c42-c3ea-2364-b13222bcb3cb@mailbox.org> <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> Message-ID: > If you don't download all blocks (which includes all UTXO), how do you know balances? You can't ! You download a single block with a UTXO commitment. Then you download the utxo state matching that commitment. Then you hash the UTXO's you got and make sure they are exactly the same as the UTXO commitment you know from the block header. Then you know all the balances. On Fri, Feb 9, 2018 at 1:59 PM, Alexey Eromenko via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > If you don't download all blocks (which includes all UTXO), how do you > know balances? You can't ! > My idea allows to download only a subset of blocks (all blocks since > Masterblock) for a new node setup. > > On Fri, Feb 9, 2018 at 10:45 PM, Tomas via bitcoin-ml > wrote: > > > > On Wed, Jan 10, 2018, at 08:11, Christoph Bergmann via bitcoin-ml wrote: > > > > If I'm not wrong, UTXO commitments allow a node to sync the UTXO only / > to > > first sync UTXO, than the rest of the chain. > > > > Masterblocks as described here adds a snapshot to cut the length of the > > historical blockchain relevant for consensus. The only cryptocurrency of > > snapshots I know of is IOTA. > > > > > > If you have the UTXO set and it is committed, you don't need the rest of > the > > chain. The UTXO set *is* the snapshot. > > > > Current full node implementations assume that all blocks before some > block X > > are valid and don't verify the signatures. The *only* reason to download > > them is to update the UTXO state. If X includes a UTXO commitment, (and > > we've included the rule that if present it must be valid), downloading > old > > blocks becomes pointless. > > > > I don't really understand the benefit of adding another block type for > this. > > > > Tomas van der Wansem > > > > > > > > _______________________________________________ > > bitcoin-ml mailing list > > bitcoin-ml at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > > > > > -- > -Alexey Eromenko "Technologov" > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From al4321 at gmail.com Fri Feb 9 23:22:08 2018 From: al4321 at gmail.com (Alexey Eromenko) Date: Sat, 10 Feb 2018 01:22:08 +0200 Subject: [Bitcoin-ml] [Research] Masterblocks: Scaling Blockchain by summarizing balances In-Reply-To: References: <5a84ce8c-1c42-c3ea-2364-b13222bcb3cb@mailbox.org> <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> Message-ID: And is it better or worse compared to 'Masterblocks' idea? (Which is really a UTXO summary) I don't know what an "UTXO commitment" is... I know standard Bitcoin. -- -Alexey Eromenko "Technologov" From christoph.bergmann at mailbox.org Sun Feb 11 12:29:44 2018 From: christoph.bergmann at mailbox.org (Christoph Bergmann) Date: Sun, 11 Feb 2018 13:29:44 +0100 Subject: [Bitcoin-ml] [Research] Masterblocks: Scaling Blockchain by summarizing balances In-Reply-To: <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> References: <5a84ce8c-1c42-c3ea-2364-b13222bcb3cb@mailbox.org> <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> Message-ID: Isn't the major problem that to add utxo commitments you need to calculate some kind of merkle tree of some gigabyte of data, which makes it very impractical to do it every block? Does anyone know how Parity Ethereum does this? They have a warp sync to get the state, imho it is offchain between the parity nodes. Am 09.02.2018 um 21:45 schrieb Tomas via bitcoin-ml: > > On Wed, Jan 10, 2018, at 08:11, Christoph Bergmann via bitcoin-ml wrote: >> >> If I'm not wrong, UTXO commitments allow a node to sync the UTXO only >> / to first sync UTXO, than the rest of the chain. >> >> Masterblocks as described here adds a snapshot to cut the length of >> the historical blockchain relevant for consensus. The only >> cryptocurrency of snapshots I know of is IOTA. > > If you have the UTXO set and it is committed, you don't need the rest > of the chain. The UTXO set *is* the snapshot. > > Current full node implementations assume that all blocks before some > block X are valid and don't verify the signatures. The *only* reason > to download them is to update the UTXO state. If X includes a UTXO > commitment, (and we've included the rule that if present it must be > valid), downloading old blocks becomes pointless. > > I don't really understand the benefit of adding another block type for > this. > > Tomas van der Wansem > > > > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -- Christoph Bergmann Bitcoinblog.de christoph.bergmann at mailbox.org 2C18 DD55 1D85 A487 652B 943F 0693 B927 00B1 BAF8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaraboyraz.2605m at gmail.com Mon Feb 12 13:44:36 2018 From: zaraboyraz.2605m at gmail.com (Mehmet Boyraz) Date: Mon, 12 Feb 2018 05:44:36 -0800 Subject: [Bitcoin-ml] (no subject) In-Reply-To: References: Message-ID: Mehmet Boyraz -------------- next part -------------- An HTML attachment was scrubbed... URL: From bangly631 at gmail.com Sat Feb 17 22:14:14 2018 From: bangly631 at gmail.com (Bang Ly) Date: Sun, 18 Feb 2018 05:14:14 +0700 Subject: [Bitcoin-ml] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.bergmann at mailbox.org Tue Feb 20 09:46:13 2018 From: christoph.bergmann at mailbox.org (Christoph Bergmann) Date: Tue, 20 Feb 2018 10:46:13 +0100 Subject: [Bitcoin-ml] OP_Codes Message-ID: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Hello everyone, did we just agree on adding a lot of new OP_Codes without having it discussed in a single mail on this list? Can someone give an overview about them? best Christoph -- Christoph Bergmann Bitcoinblog.de christoph.bergmann at mailbox.org 2C18 DD55 1D85 A487 652B 943F 0693 B927 00B1 BAF8 From tomh at thinlink.com Fri Feb 23 00:52:39 2018 From: tomh at thinlink.com (Tom Harding) Date: Thu, 22 Feb 2018 16:52:39 -0800 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: Christoph, There is a working group developing a specification here https://github.com/bitcoincashorg/spec/pull/54 It would be great if any of those people would give an overview. On 2/20/2018 1:46 AM, Christoph Bergmann via bitcoin-ml wrote: > Hello everyone, > > did we just agree on adding a lot of new OP_Codes without having it > discussed in a single mail on this list? > > Can someone give an overview about them? > > best > > Christoph > From al4321 at gmail.com Fri Feb 23 00:54:21 2018 From: al4321 at gmail.com (Alexey Eromenko) Date: Fri, 23 Feb 2018 02:54:21 +0200 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: What are the downsides for each OPCODE enablement ? From shadders.del at gmail.com Fri Feb 23 04:21:44 2018 From: shadders.del at gmail.com (Steve Shadders) Date: Fri, 23 Feb 2018 14:21:44 +1000 Subject: [Bitcoin-ml] Formal bitcoin protocol specification - project proposal In-Reply-To: References: <5e1669af-79eb-43f2-7e13-e4750bc6e120@gmail.com> <97112363-ca87-7eb1-25f5-89a33d5aa02f@cispa.saarland> Message-ID: <69be2653-c135-20d8-0884-7b60971f2bf3@gmail.com> Hi Janez, Janosch, A telegram workgroup has been formed to progress the coodination of this as a project.? I would like to invite you to join. Details here: https://github.com/bitcoincashorg/workgroups/blob/master/wg-protocol-spec/workgroup.md On 5/02/2018 7:07 PM, Janez Urevc via bitcoin-ml wrote: > Hi, > > I'd like to express my interest in this project. > > I have 10 years of professional experience in software development in > open source space. I was leading major initiatives for a big open > source project (unrelated to Bitcoin, but still...) where I, among > other things, wrote many plans, specification papers, roadmaps, etc. I > recently started getting into Bitcoin development and soon realized > how big of an improvement a formal secification would be. I also feel > that working on a specification project would give me more insight > into the protocol and help me learn more about it. > > If such project and/or workshop would be started I am ready to jump on > board and help with it. > > Best regards, > > Janez Urevc > > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -------------- next part -------------- An HTML attachment was scrubbed... URL: From deadalnix at gmail.com Fri Feb 23 05:46:39 2018 From: deadalnix at gmail.com (=?UTF-8?Q?Amaury_S=C3=A9chet?=) Date: Fri, 23 Feb 2018 06:46:39 +0100 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: The downside depends on op_codes. Maybe you have question about specific op_codes ? 2018-02-23 1:54 GMT+01:00 Alexey Eromenko via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org>: > What are the downsides for each OPCODE enablement ? > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From louiedixon11 at gmail.com Fri Feb 23 06:41:30 2018 From: louiedixon11 at gmail.com (Louie Dixon) Date: Fri, 23 Feb 2018 01:41:30 -0500 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: I sm not bitcoin please stop lou On Feb 20, 2018 04:46, "Christoph Bergmann via bitcoin-ml" < bitcoin-ml at lists.linuxfoundation.org> wrote: > Hello everyone, > > did we just agree on adding a lot of new OP_Codes without having it > discussed in a single mail on this list? > > Can someone give an overview about them? > > best > > Christoph > > -- > Christoph Bergmann > Bitcoinblog.de > christoph.bergmann at mailbox.org > 2C18 DD55 1D85 A487 652B 943F 0693 B927 00B1 BAF8 > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From al4321 at gmail.com Fri Feb 23 09:01:03 2018 From: al4321 at gmail.com (Alexey Eromenko) Date: Fri, 23 Feb 2018 09:01:03 +0000 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: Thats why I requested info per every op code, are there "dangerous " ones, that have downsides? On Fri, 23 Feb 2018 at 6:47 Amaury S?chet wrote: > The downside depends on op_codes. Maybe you have question about specific > op_codes ? > > 2018-02-23 1:54 GMT+01:00 Alexey Eromenko via bitcoin-ml < > bitcoin-ml at lists.linuxfoundation.org>: > >> What are the downsides for each OPCODE enablement ? >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> > -- -Alexey Eromenko "Technologov" -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvella at gmail.com Fri Feb 23 15:30:19 2018 From: lvella at gmail.com (Lucas Clemente Vella) Date: Fri, 23 Feb 2018 12:30:19 -0300 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience Message-ID: One user complained on Reddit that the new CashAddr that it is ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I dare say there is the same problem with 'o' and '0'. It is a problem because most users won't bother to know what characters comprises the base32 encoding. My proposed solution is simple: treat 'i', 'L' and '1' as the same encoded value of 31 when parsing input, but always record and display as 'L' (use lowercase or uppercase as recommended). Same thing with 'o' and '0': treat both as the same character with encoded value of 15 when parsing, but always display 0. We can make the adjustment in CashAddr spec and bump the version to 1.1. -- Lucas Clemente Vella lvella at gmail.com From cp368202 at ohiou.edu Fri Feb 23 17:35:08 2018 From: cp368202 at ohiou.edu (Chris Priest) Date: Fri, 23 Feb 2018 10:35:08 -0700 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: There already is a solution for this, it's called Base58. I propose we dump "CashAddr" and go back to Base58. On Fri, Feb 23, 2018 at 8:30 AM, Lucas Clemente Vella via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > One user complained on Reddit that the new CashAddr that it is > ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I > dare say there is the same problem with 'o' and '0'. It is a problem > because most users won't bother to know what characters comprises the > base32 encoding. > > My proposed solution is simple: treat 'i', 'L' and '1' as the same > encoded value of 31 when parsing input, but always record and display > as 'L' (use lowercase or uppercase as recommended). > > Same thing with 'o' and '0': treat both as the same character with > encoded value of 15 when parsing, but always display 0. > > We can make the adjustment in CashAddr spec and bump the version to 1.1. > > -- > Lucas Clemente Vella > lvella at gmail.com > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -- Chris Priest 786-531-5938 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.andrew.stone at gmail.com Fri Feb 23 18:10:34 2018 From: g.andrew.stone at gmail.com (G. Andrew Stone) Date: Fri, 23 Feb 2018 13:10:34 -0500 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: Here are the current opcode specifications. We would certainly appreciate your critical review for security flaws. OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_BIN2NUM, OP_NUM2BIN: https://github.com/shadders/uahf-spec/blob/reenable-op-codes/reenable-op-codes.md OP_DATASIGVERIFY: https://github.com/gandrewstone/BitcoinUnlimited/blob/op_datasigverify/doc/opdatasigverify.md OP_GROUP: https://github.com/gandrewstone/BitcoinUnlimited/blob/opgroup_fullnode/doc/opgroup-tokens.md On Fri, Feb 23, 2018 at 4:01 AM, Alexey Eromenko via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > Thats why I requested info per every op code, are there "dangerous " ones, > that have downsides? > > > > On Fri, 23 Feb 2018 at 6:47 Amaury S?chet wrote: > >> The downside depends on op_codes. Maybe you have question about specific >> op_codes ? >> >> 2018-02-23 1:54 GMT+01:00 Alexey Eromenko via bitcoin-ml < >> bitcoin-ml at lists.linuxfoundation.org>: >> >>> What are the downsides for each OPCODE enablement ? >>> _______________________________________________ >>> bitcoin-ml mailing list >>> bitcoin-ml at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >>> >> -- > -Alexey Eromenko "Technologov" > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grarpamp at gmail.com Fri Feb 23 18:18:09 2018 From: grarpamp at gmail.com (grarpamp) Date: Fri, 23 Feb 2018 13:18:09 -0500 Subject: [Bitcoin-ml] [Research] Masterblocks: Scaling Blockchain by summarizing balances In-Reply-To: References: <5a84ce8c-1c42-c3ea-2364-b13222bcb3cb@mailbox.org> <1518209117.1832462.1265709904.45183D01@webmail.messagingengine.com> Message-ID: > If you have the UTXO set and it is committed, you don't need the rest of the > chain. The UTXO set *is* the snapshot. Bitcoin Private (BTCP) has done this using coinbase inputs to bootstrap a fork. https://btcprivate.org/ https://btcprivate.org/whitepaper.pdf https://github.com/BTCPrivate/BitcoinPrivate While cool, it's more of an export import operation, not so much a live consensus. To get consensus and pruneability in a live coin, mining code would have to trigger a scrape and mine utxo operation into checkpoint blocks every N blocks [1]. Thereafter each, it could be possible to purge history. The network doesn't have to freeze during that, but it might want to only collate utxo's over D days destroyed, buffer inbound utxo tx's into mempool till complete, etc. [1] Perhaps every 50k, or dynamic threshold if operations consume disk space sooner, From thorkilk at gmail.com Fri Feb 23 18:38:19 2018 From: thorkilk at gmail.com (=?UTF-8?Q?Thorkil_V=C3=A6rge?=) Date: Fri, 23 Feb 2018 19:38:19 +0100 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: Can't client-side JavaScript solve this problem? Bitcoin Cash already has an error-correcting checksum such that errors can be spotted. On 23 Feb 2018 18.35 <20%2018%2018%2035>, "Chris Priest via bitcoin-ml" < bitcoin-ml at lists.linuxfoundation.org> wrote: > There already is a solution for this, it's called Base58. I propose we > dump "CashAddr" and go back to Base58. > > On Fri, Feb 23, 2018 at 8:30 AM, Lucas Clemente Vella via bitcoin-ml < > bitcoin-ml at lists.linuxfoundation.org> wrote: > >> One user complained on Reddit that the new CashAddr that it is >> ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I >> dare say there is the same problem with 'o' and '0'. It is a problem >> because most users won't bother to know what characters comprises the >> base32 encoding. >> >> My proposed solution is simple: treat 'i', 'L' and '1' as the same >> encoded value of 31 when parsing input, but always record and display >> as 'L' (use lowercase or uppercase as recommended). >> >> Same thing with 'o' and '0': treat both as the same character with >> encoded value of 15 when parsing, but always display 0. >> >> We can make the adjustment in CashAddr spec and bump the version to 1.1. >> >> -- >> Lucas Clemente Vella >> lvella at gmail.com >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> > > > > -- > Chris Priest > 786-531-5938 > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From umohjah5 at gmail.com Fri Feb 23 18:42:24 2018 From: umohjah5 at gmail.com (Friday Umoh) Date: Fri, 23 Feb 2018 19:42:24 +0100 Subject: [Bitcoin-ml] Bitcoin request Message-ID: Help me out for follow up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From umohjah5 at gmail.com Fri Feb 23 18:44:39 2018 From: umohjah5 at gmail.com (Friday Umoh) Date: Fri, 23 Feb 2018 19:44:39 +0100 Subject: [Bitcoin-ml] Bitcoin bonus and exchange Message-ID: Let me know please how to follow up and help me out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvella at gmail.com Fri Feb 23 18:59:18 2018 From: lvella at gmail.com (Lucas Clemente Vella) Date: Fri, 23 Feb 2018 15:59:18 -0300 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: Yes, that is a matter of client side encoding. Must be done before getting to error correction (i.e. both 'o' and '0' are the same thing, doesn't need to be 'corrected'). Doesn't mean it is not worth updating the specification. Em 23 de fev de 2018 3:38 PM, "Thorkil V?rge via bitcoin-ml" < bitcoin-ml at lists.linuxfoundation.org> escreveu: Can't client-side JavaScript solve this problem? Bitcoin Cash already has an error-correcting checksum such that errors can be spotted. On 23 Feb 2018 18.35 <20%2018%2018%2035>, "Chris Priest via bitcoin-ml" < bitcoin-ml at lists.linuxfoundation.org> wrote: > There already is a solution for this, it's called Base58. I propose we > dump "CashAddr" and go back to Base58. > > On Fri, Feb 23, 2018 at 8:30 AM, Lucas Clemente Vella via bitcoin-ml < > bitcoin-ml at lists.linuxfoundation.org> wrote: > >> One user complained on Reddit that the new CashAddr that it is >> ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I >> dare say there is the same problem with 'o' and '0'. It is a problem >> because most users won't bother to know what characters comprises the >> base32 encoding. >> >> My proposed solution is simple: treat 'i', 'L' and '1' as the same >> encoded value of 31 when parsing input, but always record and display >> as 'L' (use lowercase or uppercase as recommended). >> >> Same thing with 'o' and '0': treat both as the same character with >> encoded value of 15 when parsing, but always display 0. >> >> We can make the adjustment in CashAddr spec and bump the version to 1.1. >> >> -- >> Lucas Clemente Vella >> lvella at gmail.com >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> > > > > -- > Chris Priest > 786-531-5938 <(786)%20531-5938> > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > _______________________________________________ bitcoin-ml mailing list bitcoin-ml at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -------------- next part -------------- An HTML attachment was scrubbed... URL: From ematiu at gmail.com Fri Feb 23 19:10:42 2018 From: ematiu at gmail.com (Matias Alejo Garcia) Date: Fri, 23 Feb 2018 16:10:42 -0300 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: Please note that copy-pasting an address or QR scanning it is not affected by this issue. Also, note that cashaddr has a (strong) checksum that would prevent this issue: if the user types it wrong; or if a malware modifies it, the checksum will not verify). I'm afraid the change you propose is not minor, because it will need to be implemented, in a coordinated way, by every wallet, exchange, etc that currently use cashaddr. On Fri, Feb 23, 2018 at 12:30 PM, Lucas Clemente Vella via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > One user complained on Reddit that the new CashAddr that it is > ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I > dare say there is the same problem with 'o' and '0'. It is a problem > because most users won't bother to know what characters comprises the > base32 encoding. > > My proposed solution is simple: treat 'i', 'L' and '1' as the same > encoded value of 31 when parsing input, but always record and display > as 'L' (use lowercase or uppercase as recommended). > > Same thing with 'o' and '0': treat both as the same character with > encoded value of 15 when parsing, but always display 0. > > We can make the adjustment in CashAddr spec and bump the version to 1.1. > > -- > Lucas Clemente Vella > lvella at gmail.com > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -- Mat?as Alejo Garcia @ematiu Roads? Where we're going, we don't need roads! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvella at gmail.com Fri Feb 23 20:12:21 2018 From: lvella at gmail.com (Lucas Clemente Vella) Date: Fri, 23 Feb 2018 17:12:21 -0300 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: I agree it is an expensive change, but it is a backward compatible change that is useful in case users needs to type or write down an address. I dare say a situation where some wallets do support CashAddr 1.0 and others support CashAddr 1.1 is no worse than everybody supporting just 1.0, but almost certainly better. Can I think of very specific situations where the same address working on some wallets and don't working on others would cause a problem? Yes, I can. But given the fact that such address would most certainly come from a misread (as you said, copy-pasting and QR code scanning isn't affected), the user would already have a problem, anyway. For completeness, the link to the discussion were users argues CashAddr is harming UX: https://www.reddit.com/r/btc/comments/7zm1m1/psa_the_new_address_format_added_ambiguous/?st=je0dezmp&sh=3fa86513 2018-02-23 16:10 GMT-03:00 Matias Alejo Garcia : > Please note that copy-pasting an address or QR scanning it is not affected > by this issue. Also, note that cashaddr has a (strong) checksum that would > prevent this issue: if the user types it wrong; or if a malware modifies it, > the checksum will not verify). > > I'm afraid the change you propose is not minor, because it will need to be > implemented, in a coordinated way, by every wallet, exchange, etc that > currently use cashaddr. > > On Fri, Feb 23, 2018 at 12:30 PM, Lucas Clemente Vella via bitcoin-ml > wrote: >> >> One user complained on Reddit that the new CashAddr that it is >> ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I >> dare say there is the same problem with 'o' and '0'. It is a problem >> because most users won't bother to know what characters comprises the >> base32 encoding. >> >> My proposed solution is simple: treat 'i', 'L' and '1' as the same >> encoded value of 31 when parsing input, but always record and display >> as 'L' (use lowercase or uppercase as recommended). >> >> Same thing with 'o' and '0': treat both as the same character with >> encoded value of 15 when parsing, but always display 0. >> >> We can make the adjustment in CashAddr spec and bump the version to 1.1. >> >> -- >> Lucas Clemente Vella >> lvella at gmail.com >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > > > > -- > Mat?as Alejo Garcia > @ematiu > Roads? Where we're going, we don't need roads! -- Lucas Clemente Vella lvella at gmail.com From macoukji at gamesnet.org Fri Feb 23 21:50:20 2018 From: macoukji at gamesnet.org (George Macoukji) Date: Fri, 23 Feb 2018 15:50:20 -0600 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: I've already spotted an issue with the OP_CAT documentation. I'm not hugely familiar with Github. How do we report issues most effectively? With normal code, we can just open an issue or comment directly on the line in question. -- "I got an "A" in philosophy because I proved my professor didn't exist." -- Judy Tenuta On Fri, Feb 23, 2018 at 12:10 PM, G. Andrew Stone via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > Here are the current opcode specifications. We would certainly appreciate > your critical review for security flaws. > > OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_BIN2NUM, > OP_NUM2BIN: > https://github.com/shadders/uahf-spec/blob/reenable-op- > codes/reenable-op-codes.md > > > OP_DATASIGVERIFY: > https://github.com/gandrewstone/BitcoinUnlimited/ > blob/op_datasigverify/doc/opdatasigverify.md > > OP_GROUP: > https://github.com/gandrewstone/BitcoinUnlimited/ > blob/opgroup_fullnode/doc/opgroup-tokens.md > > On Fri, Feb 23, 2018 at 4:01 AM, Alexey Eromenko via bitcoin-ml < > bitcoin-ml at lists.linuxfoundation.org> wrote: > >> Thats why I requested info per every op code, are there "dangerous " >> ones, that have downsides? >> >> >> >> On Fri, 23 Feb 2018 at 6:47 Amaury S?chet wrote: >> >>> The downside depends on op_codes. Maybe you have question about specific >>> op_codes ? >>> >>> 2018-02-23 1:54 GMT+01:00 Alexey Eromenko via bitcoin-ml < >>> bitcoin-ml at lists.linuxfoundation.org>: >>> >>>> What are the downsides for each OPCODE enablement ? >>>> _______________________________________________ >>>> bitcoin-ml mailing list >>>> bitcoin-ml at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >>>> >>> -- >> -Alexey Eromenko "Technologov" >> >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> >> > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua2014 at protonmail.ch Fri Feb 23 22:02:55 2018 From: joshua2014 at protonmail.ch (Joshua) Date: Fri, 23 Feb 2018 17:02:55 -0500 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: Hi all, The interpreter code for the new opcodes is located on the bitcoin-abc phabricator instance at https://reviews.bitcoinabc.org/D1090. You can follow up through the related diffs by using going to the Revision Contents table and then clicking on Stack. If you prefer Github I've got a personal repo located here (https://github.com/joshuayabut/bitcoin-abc/commits/enable-opcodes-rc5) with the commits so far... We've got the scripting engine and unit tests implemented already. Please keep in mind the code is still under review and it is still lacking an activation mechanism (which I am currently working on). One thing that I think that may need to be worked on in the future is the benchmarking of opcode resource utilization; that way tx fees can be calculated in relationship to resource usage. I think we're all re-experiencing the decentralized nature of Bitcoin development so I'm open to any and all comments/suggestions in order to expedite upgrading bitcoin. As far as security issues are concerned, I get it... it's being factored throughout the development process as far as I can tell. Contribution Guidelines here: https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/CONTRIBUTING.md -Josh Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. ??????? Original Message ??????? On February 23, 2018 4:50 PM, George Macoukji via bitcoin-ml wrote: > I've already spotted an issue with the OP_CAT documentation. I'm not hugely familiar with Github. How do we report issues most effectively? With normal code, we can just open an issue or comment directly on the line in question. > > -- > "I got an "A" in philosophy because I proved my professor didn't exist." > -- Judy Tenuta > > On Fri, Feb 23, 2018 at 12:10 PM, G. Andrew Stone via bitcoin-ml wrote: > >> Here are the current opcode specifications. We would certainly appreciate your critical review for security flaws. >> >> OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_BIN2NUM, OP_NUM2BIN: >> https://github.com/shadders/uahf-spec/blob/reenable-op-codes/reenable-op-codes.md >> >> OP_DATASIGVERIFY: >> https://github.com/gandrewstone/BitcoinUnlimited/blob/op_datasigverify/doc/opdatasigverify.md >> >> OP_GROUP: >> https://github.com/gandrewstone/BitcoinUnlimited/blob/opgroup_fullnode/doc/opgroup-tokens.md >> >> On Fri, Feb 23, 2018 at 4:01 AM, Alexey Eromenko via bitcoin-ml wrote: >> >>> Thats why I requested info per every op code, are there "dangerous " ones, that have downsides? >>> >>> On Fri, 23 Feb 2018 at 6:47 Amaury S?chet wrote: >>> >>>> The downside depends on op_codes. Maybe you have question about specific op_codes ? >>>> >>>> 2018-02-23 1:54 GMT+01:00 Alexey Eromenko via bitcoin-ml : >>>> >>>>> What are the downsides for each OPCODE enablement ? >>>>> >>>>> _______________________________________________ >>>>> bitcoin-ml mailing list >>>>> bitcoin-ml at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >>> >>> -- >>> -Alexey Eromenko "Technologov" >>> >>> _______________________________________________ >>> bitcoin-ml mailing list >>> bitcoin-ml at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -------------- next part -------------- An HTML attachment was scrubbed... URL: From fathiabdoon at gmail.com Fri Feb 23 22:15:27 2018 From: fathiabdoon at gmail.com (fathi abdoon) Date: Fri, 23 Feb 2018 18:15:27 -0400 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: I would like to add my 2 cents in to this discussion. Addresses should not be manually typed. And if they are then they should not be encouraged. This is in part to avoid mistakes and / or loss of funds. The checksum surely will help prevent mistakes. I think it's really important to start thinking of providing a service that will be as easy as possible to use. Scanning a barcode, copy pasting an address, or a futuristic undiscovered clever simple UX way. End goal is to make it easy. We have cashAddr that we can live with for now and that should be it for now. We should move forward and think of other improvements and not recycle old ones. You should keep in mind that it took time for merchants to implement cashAddr even though there are still some that haven't yet. On Fri, Feb 23, 2018 at 4:12 PM, Lucas Clemente Vella via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > I agree it is an expensive change, but it is a backward compatible > change that is useful in case users needs to type or write down an > address. > > I dare say a situation where some wallets do support CashAddr 1.0 and > others support CashAddr 1.1 is no worse than everybody supporting just > 1.0, but almost certainly better. > > Can I think of very specific situations where the same address working > on some wallets and don't working on others would cause a problem? > Yes, I can. But given the fact that such address would most certainly > come from a misread (as you said, copy-pasting and QR code scanning > isn't affected), the user would already have a problem, anyway. > > For completeness, the link to the discussion were users argues > CashAddr is harming UX: > https://www.reddit.com/r/btc/comments/7zm1m1/psa_the_new_ > address_format_added_ambiguous/?st=je0dezmp&sh=3fa86513 > > 2018-02-23 16:10 GMT-03:00 Matias Alejo Garcia : > > Please note that copy-pasting an address or QR scanning it is not > affected > > by this issue. Also, note that cashaddr has a (strong) checksum that > would > > prevent this issue: if the user types it wrong; or if a malware modifies > it, > > the checksum will not verify). > > > > I'm afraid the change you propose is not minor, because it will need to > be > > implemented, in a coordinated way, by every wallet, exchange, etc that > > currently use cashaddr. > > > > On Fri, Feb 23, 2018 at 12:30 PM, Lucas Clemente Vella via bitcoin-ml > > wrote: > >> > >> One user complained on Reddit that the new CashAddr that it is > >> ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I > >> dare say there is the same problem with 'o' and '0'. It is a problem > >> because most users won't bother to know what characters comprises the > >> base32 encoding. > >> > >> My proposed solution is simple: treat 'i', 'L' and '1' as the same > >> encoded value of 31 when parsing input, but always record and display > >> as 'L' (use lowercase or uppercase as recommended). > >> > >> Same thing with 'o' and '0': treat both as the same character with > >> encoded value of 15 when parsing, but always display 0. > >> > >> We can make the adjustment in CashAddr spec and bump the version to 1.1. > >> > >> -- > >> Lucas Clemente Vella > >> lvella at gmail.com > >> _______________________________________________ > >> bitcoin-ml mailing list > >> bitcoin-ml at lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > > > > > > > > > -- > > Mat?as Alejo Garcia > > @ematiu > > Roads? Where we're going, we don't need roads! > > > > -- > Lucas Clemente Vella > lvella at gmail.com > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From macoukji at gamesnet.org Sat Feb 24 21:10:11 2018 From: macoukji at gamesnet.org (George Macoukji) Date: Sat, 24 Feb 2018 15:10:11 -0600 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: I fear there's something of a cavalier attitude towards use cases that stray beyond the mainstream here, and it doesn't serve the community well. I agree that in the ordinary course of a day, a user shouldn't have to type in an address. However, not all days are ordinary. There will be oddball scenarios where a user has to type addresses or even private keys by hand. (It happened to me; I printed and funded a paper wallet, and when I needed to spend it, I didn't have a camera handy to scan the QR code. So I had to type out the private key.) My experience with technical teams has been that they focus on the technology and dismiss usability concerns, particularly ones related to edge cases. This is not an indictment of tech teams; it's just the natural result of very smart people focusing on their area of specialization. To that end, I urge everyone to step back and question their point of view, any time they ask, "Why would you do that?" End users don't think like technical people, and they will always come up with cases that surprise technical teams. This thread is discussing a usability issue. A user has reported a usability problem, and the responses in this thread are more like, "It is technically functional, and therefore a non-issue." That misses the point. This isn't a technical problem. It's a usability one. -- "I got an "A" in philosophy because I proved my professor didn't exist." -- Judy Tenuta On Fri, Feb 23, 2018 at 4:15 PM, fathi abdoon via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > I would like to add my 2 cents in to this discussion. Addresses should not > be manually typed. And if they are then they should not be encouraged. > This is in part to avoid mistakes and / or loss of funds. The checksum > surely will help prevent mistakes. > > I think it's really important to start thinking of providing a service > that will be as easy as possible to use. > Scanning a barcode, copy pasting an address, or a futuristic undiscovered > clever simple UX way. End goal is to make it easy. > > We have cashAddr that we can live with for now and that should be it for > now. We should move forward and think of other improvements and not recycle > old ones. > You should keep in mind that it took time for merchants to implement cashAddr > even though there are still some that haven't yet. > > On Fri, Feb 23, 2018 at 4:12 PM, Lucas Clemente Vella via bitcoin-ml < > bitcoin-ml at lists.linuxfoundation.org> wrote: > >> I agree it is an expensive change, but it is a backward compatible >> change that is useful in case users needs to type or write down an >> address. >> >> I dare say a situation where some wallets do support CashAddr 1.0 and >> others support CashAddr 1.1 is no worse than everybody supporting just >> 1.0, but almost certainly better. >> >> Can I think of very specific situations where the same address working >> on some wallets and don't working on others would cause a problem? >> Yes, I can. But given the fact that such address would most certainly >> come from a misread (as you said, copy-pasting and QR code scanning >> isn't affected), the user would already have a problem, anyway. >> >> For completeness, the link to the discussion were users argues >> CashAddr is harming UX: >> https://www.reddit.com/r/btc/comments/7zm1m1/psa_the_new_add >> ress_format_added_ambiguous/?st=je0dezmp&sh=3fa86513 >> >> 2018-02-23 16:10 GMT-03:00 Matias Alejo Garcia : >> > Please note that copy-pasting an address or QR scanning it is not >> affected >> > by this issue. Also, note that cashaddr has a (strong) checksum that >> would >> > prevent this issue: if the user types it wrong; or if a malware >> modifies it, >> > the checksum will not verify). >> > >> > I'm afraid the change you propose is not minor, because it will need to >> be >> > implemented, in a coordinated way, by every wallet, exchange, etc that >> > currently use cashaddr. >> > >> > On Fri, Feb 23, 2018 at 12:30 PM, Lucas Clemente Vella via bitcoin-ml >> > wrote: >> >> >> >> One user complained on Reddit that the new CashAddr that it is >> >> ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I >> >> dare say there is the same problem with 'o' and '0'. It is a problem >> >> because most users won't bother to know what characters comprises the >> >> base32 encoding. >> >> >> >> My proposed solution is simple: treat 'i', 'L' and '1' as the same >> >> encoded value of 31 when parsing input, but always record and display >> >> as 'L' (use lowercase or uppercase as recommended). >> >> >> >> Same thing with 'o' and '0': treat both as the same character with >> >> encoded value of 15 when parsing, but always display 0. >> >> >> >> We can make the adjustment in CashAddr spec and bump the version to >> 1.1. >> >> >> >> -- >> >> Lucas Clemente Vella >> >> lvella at gmail.com >> >> _______________________________________________ >> >> bitcoin-ml mailing list >> >> bitcoin-ml at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> > >> > >> > >> > >> > -- >> > Mat?as Alejo Garcia >> > @ematiu >> > Roads? Where we're going, we don't need roads! >> >> >> >> -- >> Lucas Clemente Vella >> lvella at gmail.com >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> > > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shammah.chancellor at gmail.com Sat Feb 24 21:26:38 2018 From: shammah.chancellor at gmail.com (Shammah Chancellor) Date: Sat, 24 Feb 2018 13:26:38 -0800 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: <2B985A35-4D92-46A9-9994-2E98DC03C9B0@gmail.com> > > On Feb 23, 2018, at 7:30 AM, Lucas Clemente Vella via bitcoin-ml wrote: > > One user complained on Reddit that the new CashAddr that it is > ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I > dare say there is the same problem with 'o' and '0'. It is a problem > because most users won't bother to know what characters comprises the > base32 encoding. > > My proposed solution is simple: treat 'i', 'L' and '1' as the same > encoded value of 31 when parsing input, but always record and display > as 'L' (use lowercase or uppercase as recommended). > > Same thing with 'o' and '0': treat both as the same character with > encoded value of 15 when parsing, but always display 0. > > We can make the adjustment in CashAddr spec and bump the version to 1.1. > > -- > Lucas Clemente Vella > lvella at gmail.com > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml It's too bad that after over a year of bech32 and cashaddr specs being available (using the same charset) this issue wasn't raised more visibly. I think your suggestion is reasonable, why don't you make a PR to the specification? https://github.com/bitcoincashorg/spec -------------- next part -------------- An HTML attachment was scrubbed... URL: From cp368202 at ohiou.edu Sat Feb 24 23:24:50 2018 From: cp368202 at ohiou.edu (Chris Priest) Date: Sat, 24 Feb 2018 16:24:50 -0700 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: <2B985A35-4D92-46A9-9994-2E98DC03C9B0@gmail.com> References: <2B985A35-4D92-46A9-9994-2E98DC03C9B0@gmail.com> Message-ID: Bech32 came from the core camp. If you posted a criticism of it to one of their communities your post would get "moderated". Also as little as BCH's adoption of Bech32 is, it's still more prevalent here than it is in segwitland. Eventually core supporters would have discovered these problems too once more of them started using it. On Sat, Feb 24, 2018 at 2:26 PM, Shammah Chancellor via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > > On Feb 23, 2018, at 7:30 AM, Lucas Clemente Vella via bitcoin-ml < > bitcoin-ml at lists.linuxfoundation.org> wrote: > > One user complained on Reddit that the new CashAddr that it is > ambiguous, because lowcase 'L' looks like '1' and uppercase 'i'. I > dare say there is the same problem with 'o' and '0'. It is a problem > because most users won't bother to know what characters comprises the > base32 encoding. > > My proposed solution is simple: treat 'i', 'L' and '1' as the same > encoded value of 31 when parsing input, but always record and display > as 'L' (use lowercase or uppercase as recommended). > > Same thing with 'o' and '0': treat both as the same character with > encoded value of 15 when parsing, but always display 0. > > We can make the adjustment in CashAddr spec and bump the version to 1.1. > > -- > Lucas Clemente Vella > lvella at gmail.com > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > > It's too bad that after over a year of bech32 and cashaddr specs being > available (using the same charset) this issue wasn't raised more visibly. > > I think your suggestion is reasonable, why don't you make a PR to the > specification? > > https://github.com/bitcoincashorg/spec > > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > -- Chris Priest 786-531-5938 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cismk90 at gmail.com Sun Feb 25 03:05:57 2018 From: cismk90 at gmail.com (P C) Date: Sun, 25 Feb 2018 03:05:57 +0000 Subject: [Bitcoin-ml] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at bitcrust.org Tue Feb 27 13:13:53 2018 From: tomas at bitcrust.org (Tomas) Date: Tue, 27 Feb 2018 14:13:53 +0100 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: References: Message-ID: <1519737233.3135511.1285005008.48EB47CE@webmail.messagingengine.com> On Fri, Feb 23, 2018, at 19:59, Lucas Clemente Vella via bitcoin-ml wrote:> Yes, that is a matter of client side encoding. > > Must be done before getting to error correction (i.e. both 'o' and '0' > are the same thing, doesn't need to be 'corrected'). Doesn't mean it > is not worth updating the specification.> > I disagree. A client implementation can do all kinds of fancy stuff to make the input easier:* Auto-remove trailing spaces and newlines that may be accidentally included on pasting* Change 1 to l as you type * Transform friendly names to addresses from a local address book * Auto prepend the bitcoincash: prefix * Reject and beep on typing a non-bech32 character What do any of these have to do with the address *format*? Such tricks or not in scope of a format specification. Tomas bitcrust -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvella at gmail.com Tue Feb 27 14:53:13 2018 From: lvella at gmail.com (Lucas Clemente Vella) Date: Tue, 27 Feb 2018 11:53:13 -0300 Subject: [Bitcoin-ml] Upgrading CashAddr in order to improve user experience In-Reply-To: <1519737233.3135511.1285005008.48EB47CE@webmail.messagingengine.com> References: <1519737233.3135511.1285005008.48EB47CE@webmail.messagingengine.com> Message-ID: Em 27 de fev de 2018 10:14, "Tomas via bitcoin-ml" < bitcoin-ml at lists.linuxfoundation.org> escreveu: On Fri, Feb 23, 2018, at 19:59, Lucas Clemente Vella via bitcoin-ml wrote: Yes, that is a matter of client side encoding. Must be done before getting to error correction (i.e. both 'o' and '0' are the same thing, doesn't need to be 'corrected'). Doesn't mean it is not worth updating the specification. I disagree. A client implementation can do all kinds of fancy stuff to make the input easier: * Auto-remove trailing spaces and newlines that may be accidentally included on pasting * Change 1 to l as you type * Transform friendly names to addresses from a local address book * Auto prepend the bitcoincash: prefix * Reject and beep on typing a non-bech32 character What do any of these have to do with the address *format*? Such tricks or not in scope of a format specification. Let me point others: - Omit the bitcoincash: part, since it is obvious by the context it is a Bitcoin Cash address. - Indicate the precise position where a mistype happens, by highlighting only the wrong characters. But those two are part of the specification. What should be part of an address specification, which is an inherently UX matter, is whatever we want to be consistent across different implementations, and what we can document as a recurrent problem and help implementors to solve. Tomas bitcrust _______________________________________________ bitcoin-ml mailing list bitcoin-ml at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua2014 at protonmail.ch Wed Feb 28 02:42:28 2018 From: joshua2014 at protonmail.ch (Joshua) Date: Tue, 27 Feb 2018 21:42:28 -0500 Subject: [Bitcoin-ml] OP_Codes In-Reply-To: References: <319676fd-3797-bc93-a62f-0d3560f5b6e4@mailbox.org> Message-ID: Hi folks, Just a quick update... new fork activation and unit test code have been submitted to the Phabricator instance. It's also mirrored on my github for convenience: https://github.com/joshuayabut/bitcoin-abc/tree/enable-opcodes-rc6. -Josh Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. ??????? Original Message ??????? On February 23, 2018 5:02 PM, Joshua via bitcoin-ml wrote: > Hi all, > > The interpreter code for the new opcodes is located on the bitcoin-abc phabricator instance at https://reviews.bitcoinabc.org/D1090. You can follow up through the related diffs by using going to the Revision Contents table and then clicking on Stack. > > If you prefer Github I've got a personal repo located here (https://github.com/joshuayabut/bitcoin-abc/commits/enable-opcodes-rc5) with the commits so far... We've got the scripting engine and unit tests implemented already. Please keep in mind the code is still under review and it is still lacking an activation mechanism (which I am currently working on). > > One thing that I think that may need to be worked on in the future is the benchmarking of opcode resource utilization; that way tx fees can be calculated in relationship to resource usage. > > I think we're all re-experiencing the decentralized nature of Bitcoin development so I'm open to any and all comments/suggestions in order to expedite upgrading bitcoin. > > As far as security issues are concerned, I get it... it's being factored throughout the development process as far as I can tell. > > Contribution Guidelines here: https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/CONTRIBUTING.md > > -Josh > > Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. > > ??????? Original Message ??????? > On February 23, 2018 4:50 PM, George Macoukji via bitcoin-ml wrote: > >> I've already spotted an issue with the OP_CAT documentation. I'm not hugely familiar with Github. How do we report issues most effectively? With normal code, we can just open an issue or comment directly on the line in question. >> >> -- >> "I got an "A" in philosophy because I proved my professor didn't exist." >> -- Judy Tenuta >> >> On Fri, Feb 23, 2018 at 12:10 PM, G. Andrew Stone via bitcoin-ml wrote: >> >>> Here are the current opcode specifications. We would certainly appreciate your critical review for security flaws. >>> >>> OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_DIV, OP_MOD, OP_BIN2NUM, OP_NUM2BIN: >>> https://github.com/shadders/uahf-spec/blob/reenable-op-codes/reenable-op-codes.md >>> >>> OP_DATASIGVERIFY: >>> https://github.com/gandrewstone/BitcoinUnlimited/blob/op_datasigverify/doc/opdatasigverify.md >>> >>> OP_GROUP: >>> https://github.com/gandrewstone/BitcoinUnlimited/blob/opgroup_fullnode/doc/opgroup-tokens.md >>> >>> On Fri, Feb 23, 2018 at 4:01 AM, Alexey Eromenko via bitcoin-ml wrote: >>> >>>> Thats why I requested info per every op code, are there "dangerous " ones, that have downsides? >>>> >>>> On Fri, 23 Feb 2018 at 6:47 Amaury S?chet wrote: >>>> >>>>> The downside depends on op_codes. Maybe you have question about specific op_codes ? >>>>> >>>>> 2018-02-23 1:54 GMT+01:00 Alexey Eromenko via bitcoin-ml : >>>>> >>>>>> What are the downsides for each OPCODE enablement ? >>>>>> >>>>>> _______________________________________________ >>>>>> bitcoin-ml mailing list >>>>>> bitcoin-ml at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >>>> >>>> -- >>>> -Alexey Eromenko "Technologov" >>>> >>>> _______________________________________________ >>>> bitcoin-ml mailing list >>>> bitcoin-ml at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >>> >>> _______________________________________________ >>> bitcoin-ml mailing list >>> bitcoin-ml at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -------------- next part -------------- An HTML attachment was scrubbed... URL: