[bitcoin-dev] Co-Author for ''Redefinition of the term address"
Hi, I need a co-author for this BIP: https://github.com/bitcoin/bips/pull/856 See the reasons mentioned by Marco Falke pEpkey.asc Description: application/pgp-keys ___ 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'
As the idea got positive feedback, I've written the BIP. The draft is available here: https://github.com/bitcoin/bips/pull/856 Am 17.10.19 um 15:23 schrieb Marco Falke via bitcoin-dev: > I also like the "bitcoin invoice address" term by Chris. Invoice is a > common term and easily translatable into other languages. > > Marco > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > pEpkey.asc Description: application/pgp-keys ___ 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'
> 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) I personally do not like the term bulla, it might be a perfect analogy but I personally don't believe that this term is well known. Tbh I didn't knew what a 'bulla' was before. > I propose Funding Codes. I'm neutral on this. With code I associate something that is slightly more permanent like a code to unlock your mobile phone or a code to unlock your bike if you know what I mean. These kind of codes change sometimes but not as often as a bitcoin address (should). I also agree that Payment Tokens might confuse with other currencies and block chain. > > - Invoices are problematic because they imply that they hold bitcoins and > they specify an amount. However addresses don't specify any amounts while > they themselves can be included inside a real invoice. I think it is wrong to > imply that the "thing" we are sending money to is temporary, because it > isn't. Lightning channels can stay open forever until closed but money > doesn't stay in an invoice for any amount of time. What is with 'Bitcoin Invoice Address'? This is the best of both worlds because it implies the temporary factor with 'invoice' and the way that you send something to something. Also, this is more a personal opinion but I thunk that 'funding' implies more to donate to something. I think this could lead to misunderstandings. To summarize it up, here are the following suggested terms: * Invoice ID * Payment Token * Bitcoin invoice (address) * Bitcoin invoice (path) * Bulla * Funding code 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
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
[bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
Hello dear mailing list subscribers. Before I'll explain my idea here, I need to define a term first 'address': When I use the terms address, pubkey, etc., I mean the same: The Base58 string Ok now let's get into it: As you should know, sending bitcoins to an address more than once is a very bad approach. In my opinion the problem why so many people are still doing this is because of the term 'address' which is used in lots of wallets, implementations, BIP 21 and so on. It is a design issue. With the term 'address' most people identify things that are fixed and don't change really often (e.g postal address, IP address [depends on provider], Domain, E-Mail address, ...). Because of this most people compare bitcoin addresses with e-mail addresses and use this address to send the recipient money multiple times. My suggestion would be to change the term address in wallets, the URI scheme and so on to something of the following options by a Informational/Process BIP: * Payment Password * Transaction Password * ... The guideline for the term should indicate that it is: * temporary * Something that identifies the recipient I've chosen 'password' because they can be used as a pseudonym to identify a person. This is already used in stuff like bank transfers where something like the transaction id should be used as the purpose or at universities there are student numbers. The first is probably a better example because student numbers aren't temporary. What do you think? Should I write a BIP for this or use another term? Feedback is most welcome :) 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
[bitcoin-dev] [BIP-able idea] Regular testnet reset
Hello, I'm thinking about writing a BIP about resetting the testnet on regular/scheduled basis The idea works like this: * Every 21 block is being used as the genesis of a completely new chain. * The old one gets forgotten * No chain can be longer than 21 blocks The problems are: * How to get this working with testnet3? Only a hardfork probably. * Is it that easy to change the chain while Bitcoin Core is running? Probably the blocks need to be appended to the cureent one. After a restart it would get patched * Could the the chain derive into multiple once at every reset? (Planned attacks) What do you think about the idea? 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
[bitcoin-dev] [Meta] bitcoin-dev moderation
In the last #bitcoin-core-dev IRC meeting, the mailing list moderation was slightly discussed. It was decided to do this discussion mainly on this mailing list (which makes sense). The current situation is that the moderation is slow and takes around >24h for a E-Mail to be on the mailing list. Jonas Schnelli proposed: "I propose that we add more moderators to shorten the moderation lag which has been between >24h, thus makes debates cumbersome" Beside this I had the idea of people who already contributed n e-mails to the mailing list don't need an approval for any e-mail anymore (Where n is the number of previous e-mails). Does this exists already? 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
Re: [bitcoin-dev] testnet4
Indeed a large testnet blockchain has advantages too. But because it is the testnet and the testnet coins have no value, the blockchain could be 'spammed' after a reset for some days/weeks until it has a certain size. Could this be realistic solution ? Am 16.06.19 um 22:25 schrieb Peter Todd: > On Sat, Jun 08, 2019 at 05:01:50PM +0200, Emil Engler via bitcoin-dev wrote: >> I don't get why the testnet shouldn't be resetted just because there is a >> (probably better) alternative for it. The testnet is still a thing and is >> also used. > > Remember that the size of testnet itself is an important test; I've argued in > that past that we should consider making testnet *larger* than mainnet. > There's > good arguments against that too, but I personally think the current size is a > reasonable compromise. > > Of course, I personally tend to do all my testing on either internal regtest > nodes, or directly on mainnet. But the fact that works for me is specific to > the exact type of development I do and may not be applicable to you. > -- https://www.emilengler.com pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 49, Issue 8
But using the testnet means that you actually need to deal with resets. There were 2 resets in the past but the last was in 2011. Am 09.06.19 um 16:55 schrieb Tim Menapace: >I don't get why the testnet shouldn't be >resetted just because there is >a (probably better) alternative for it. The >testnet is still a thing and >is also used. Like Bryan said, lot of miners test here. E.g. new firmware versions, hardware prototypes and operation services. Difficulty will be on current levels in a short period of time. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] testnet4
I don't get why the testnet shouldn't be resetted just because there is a (probably better) alternative for it. The testnet is still a thing and is also used. Am 08.06.19 um 16:21 schrieb Bryan Bishop: Be greeted Emil, On Sat, Jun 8, 2019 at 9:21 AM Emil Engler via bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: Hello, I tried myself with some Bitcoin development. For this I used of course the Bitcoin testnet. However it took me one hour to sync the blockchain with around 1538358 blocks. In my opinion that is too much for a testnet. Especially the blockchain size with around 26GB is so much. Would it be possible to reset the testnet with a new genesis block ? And if so, can we setup a fixed cycle for resetting the testnet (For example every second 1st of January) ? At the moment, I somewhat doubt this is likely to happen. Signet provides an alternative for configuring multiple separate private and public testing networks. If you would like to get involved, check out the recent discussion on the topic recorded here: http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/ - Bryan http://heybryan.org/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] testnet4
Hello, I tried myself with some Bitcoin development. For this I used of course the Bitcoin testnet. However it took me one hour to sync the blockchain with around 1538358 blocks. In my opinion that is too much for a testnet. Especially the blockchain size with around 26GB is so much. Would it be possible to reset the testnet with a new genesis block ? And if so, can we setup a fixed cycle for resetting the testnet (For example every second 1st of January) ? Greetings, Emil Engler ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
