Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
Hi Thread, This may not be the most practical information, but there actually did exist an almost perfect analogy for Bitcoin addresses from the ancient world: From wikipedia https://en.wikipedia.org/wiki/Bulla_(seal) "Transactions for trading needed to be accounted for efficiently, so the clay tokens were placed in a clay ball (bulla), which helped with dishonesty and kept all the tokens together. In order to account for the tokens, the bulla would have to be crushed to reveal their content. This introduced the idea of impressing the token onto the wet bulla before it dried, to insure trust that the tokens hadn't been tampered with and for anyone to know what exactly was in the bulla without having to break it." You could only use the bulla once because it had to be destroyed in order to get the tokens out! I think there are even examples of bulla with a kind of "signature" on them (an imprint with the seal of a noble family etc). "send me a Bitcoin bulla" has a nice ring to it! Sincerely, LL On Fri, Oct 11, 2019 at 2:44 AM Emil Engler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > * Sorry if this mail was sent multiple times, my E-Mail client went crazy * > > Thanks for all your feedback. > I came to the decision to write a BIP for this, even if it might not be > implemented by many wallets, a standardization is never wrong and this > would be the first step in the correct direction for better on-chain > privacy. > > However currently we still need a good term for the 'address' replacement. > > The current suggestions are: > * Invoice ID > * Payment Token > * Bitcoin invoice (address) > * Bitcoin invoice (path) > > Because of the LN term invoice I really like the term 'Bitcoin Invoice' > by Chris Belcher. > > So how do find a consensus about these terms? > > Greetings > Emil Engler > ___ > 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] BIPable-idea: Consistent and better definition of the term 'address'
I've proposed bitcoin invoice for awhile now. See https://twitter.com/kallewoof/status/1165841566105079808 I like bitcoin invoice address into bitcoin address as proposed by Chris. On Fri, Oct 11, 2019 at 12:45 AM Emil Engler via bitcoin-dev wrote: > > * Sorry if this mail was sent multiple times, my E-Mail client went crazy * > > Thanks for all your feedback. > I came to the decision to write a BIP for this, even if it might not be > implemented by many wallets, a standardization is never wrong and this > would be the first step in the correct direction for better on-chain > privacy. > > However currently we still need a good term for the 'address' replacement. > > The current suggestions are: > * Invoice ID > * Payment Token > * Bitcoin invoice (address) > * Bitcoin invoice (path) > > Because of the LN term invoice I really like the term 'Bitcoin Invoice' > by Chris Belcher. > > So how do find a consensus about these terms? > > Greetings > Emil Engler > ___ > 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] Chain width expansion
On 10/4/19 4:31 PM, Tier Nolan via bitcoin-dev wrote > [..] At root, the requirement is that peers can prove their total chain POW. > [...] Indeed, it's currently necessary to receive all of the chain headers to determine. It would be interesting to have a succinct chainwork proof for all cases. Chainwork being a sum of the total proof-of-work in a chain. Such proofs currently only require a few headers for common cases and the other cases can be identified. > In regard to your proposal, I think the key is to limit things by peer, > rather than globally. [...] Yeah, there should be enough width available for every active connection, only one chain of headers is requested at a time per peer. Peer based limiting is susceptible to Sybil attacks; A peer could broadcast a few low-work header chains, reconnect and repeat ad nauseam. The delay for the next set of headers is based on the chainwork of the last received headers from the peer. The peer could change identity and run into the same limit. The unrequested header rate is tracked per peer. A header chain with more chainwork will be requested at a faster rate than a header chain with less chainwork. The chainwork is compared to the current fully validated chain. Honest peers with more chainwork will have a time advantage over dishonest peers with less chainwork. For example, let's assume a case that the initial chain of headers was dishonest and with low chainwork. The initial block download retrieves the header chain from a single loader peer first. Once recent time is reached, header chains are downloaded from all outgoing peers. A single honest peer will have an advantage over many dishonest peers. Thus, as you have mentioned, there is a security assumption that there is at least one connected honest node. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
* Sorry if this mail was sent multiple times, my E-Mail client went crazy * Thanks for all your feedback. I came to the decision to write a BIP for this, even if it might not be implemented by many wallets, a standardization is never wrong and this would be the first step in the correct direction for better on-chain privacy. However currently we still need a good term for the 'address' replacement. The current suggestions are: * Invoice ID * Payment Token * Bitcoin invoice (address) * Bitcoin invoice (path) Because of the LN term invoice I really like the term 'Bitcoin Invoice' by Chris Belcher. So how do find a consensus about these terms? Greetings Emil Engler pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
