On Tuesday, June 21, 2016 9:42:39 PM Erik Aronesty wrote:
> > What do you mean by "replacement addresses" and "UI confirms" here?
>
> "Replacement addresses" would take the place of BIP 32/47 support, if
> someone thought maybe that was too difficult to deal with. So each time i
> paid Alice,
Hi Akiva,
I have also given a little thought to partitioning, in a totally
different way a Merkel Tree Forrest. Generally the idea here would have be
to create new Merkel Trees every so often as currency supply was added. It
would partition the mining process and therefore improve the
On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Jun 20, 2016 at 05:33:32PM +, Erik Aronesty via bitcoin-dev
> wrote:
>
> > - missing an optional client supplied identification
>
> Note that "client supplied identification"
On Tue, Jun 21, 2016 at 10:50:36PM +, James MacWhyte wrote:
> > Note that "client supplied identification" is being pushed for AML/KYC
> > compliance, e.g. Netki's AML/KYC compliance product:
> >
> >
> >
> Note that "client supplied identification" is being pushed for AML/KYC
> compliance, e.g. Netki's AML/KYC compliance product:
>
>
> http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/
>
> This is an extremely undesirable feature to be baking into
On Mon, Jun 20, 2016 at 04:21:39PM +, zaki--- via bitcoin-dev wrote:
> Hi Peter,
>
> I didn't entirely understand the process of transaction linearization.
>
> What I see is a potential process where when the miner assembles the block,
> he strips all but one sigscript per tx. The selection
On Tue, Jun 21, 2016 at 08:44:37PM +, Luke Dashjr via bitcoin-dev wrote:
> X509 is entrenched, so it should remain supported. PGP might make sense for
> people already using it (it provides no real security for un-WoT-networked
> users), but unforunately, few people use it. Correct me if I'm
On Mon, Jun 20, 2016 at 05:33:32PM +, Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol. Not too late
> to
On Tue, Jun 21, 2016 at 08:44:37PM +, Luke Dashjr via bitcoin-dev wrote:
> On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> > BIP 0070 has been a a moderate success, however, IMO:
> >
> > - protocol buffers are inappropriate since ease of use and extensibility is
> >
> keybase spam
good point about keybase spam, but i think it's limited to once hash per
hour (?), not really too bad... the tx's are just root signatures, so you
can verify a whole keybase tree (up to the last hour) with very minimal
bitcoin blockchain impact.
> What do you mean by "replacement
Hey all,
Interestingly enough, the original BIP75 idea started by trying to move the
Payment Protocol to use JSON, but because of all of the reasons mentioned by
Andreas, we ended up with protobuf. There is quite a bit of language support on
both desktop and mobile platforms so that's become
Thanks for starting this discussion, Erik.
> Should this be a new BIP? I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
>
This is not quite accurate. BIP75 is designed to be independent of any name
resolution system. You could use
On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol. Not too late
> to
I am a long-time developer and I have some experience in process groups. I
am going to try to keep this short. If you are interested in pursuing this
idea please reply to me privately so we don't put a burden on the list.
As per Satoshi's paper, the blockchain implements a distributed timestamp
Bluetooth exchange of payment requests already has a noticeable lag with
protocol buffers, so that would be another reason to argue against JSON,
because JSON is less efficient size wise, correct? I will say that
although protocol buffers have good platform support, I don't know that
the
On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
> because of its strong types, less vulnerability to malleability and very
> good platform support. Having
Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
because of its strong types, less vulnerability to malleability and very
good platform support. Having coded both, I can say Protobuf is not more
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
based on
17 matches
Mail list logo
