Re: [Bitcoin-development] secure assigned bitcoin address directory
On 31 Mar 2014, at 20:57, Roy Badami wrote: Is namecoin actively maintained these days? That's a very good quest. It was one of the reasons why we ruled out namecoin, but not the only one. Although in principle it is a similar concept to namecoin + PGP, in practice at least for our device, that felt like a hammer to crack a nut, How could this operate if the device was carried to one of the non-3G countries i.e. with no direct internet access? How could we syncronise the chain in a low bandwidth environment, if at all? Could at least some of the chain be pre-loaded at the factory? What would the risks be if it was?. These are just a few of the practical considerations that we are addressing, and our feeling is that when we can get the proposed distributed ledger to work properly at the lowest common denominator level, then everything above is easier. On one other point, I don't ever see the Bitcoin software using a second blockchain, like namecoin, in order just to provide safe communication of a non-face-to-face, person-to-person, pay-to address (far too many hyphens), but I do see some other standard emerging that provides the equivalent of BIP70 for this use case. In this context, when we posed these questions, Why do we have to provide a reward for a ledger of information? Why do we have to wait for confirmation when no money is at risk? What is the worst that can happen if your device key is discovered or replaced?, it did not make sense to include all the incumbent coin stuff just to arrive at a distributed ledger for a set of ultimately disposable keys.-- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] secure assigned bitcoin address directory
Re-reading this, even with the most recent message, is still isn't clear _precisely_ how your technology works, or why it is better than namecoin. User profiles (and distributed ledgers) need to reflect the latest updates, and a stream of updates of over time is precisely what bitcoin technology secures. Keys expire or are compromised, and the public ledger needs to reflect that. There is a lot of computer science involved in making sure the public ledger you see is not an outdated view. A log-like stream of changes is not the only way to do things, but other methods need less hand-wavy details (show the code) before they are well recognized as useful. On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa chris.dco...@meek.io wrote: Security of transmission of person-to-person pay-to addresses is one of the use cases that we are addressing on our hardware wallet. I have yet to finish the paper but in a nutshell it uses a decentralised ledger of, what we refer to as, device keys. These keys are not related in any way to the Bitcoin keys, (which is why I'm hesitating about discussing it here) neither do they even attempt to identify the human owner if the device. But they do have a specific use case and that is to provide advanced knowledge of a publickey that can be used for encrypting a message to an intended recipient, without the requirement for a third-party CA, and more importantly without prior dialogue. We think it is this that would allow you to communicate a pay-to address to someone without seeing them in a secure way. As I understand it the BlockChain uses time bought through proof of work to establish a version of the truth, we are using time in the reverse sense : advanced knowledge of all pubkeys. Indeed all devices could easily check their own record to identify problems on the ledger. There is of course more to this, but I like to refer to the distributed ledger of device keys as the Web-of-trust re-imagined although that isn't strictly true. Ok there you have it. The cat is out of the bag, feel free to give feedback, I have to finish the paper, apologies if it is not a topic for this list. Regards Chris D'Costa On 31 Mar 2014, at 12:21, vv01f vv...@riseup.net wrote: Some users on bitcointalk[0] would like to have their vanity addresses available for others easily to find and verify the ownership over a kind of WoT. Right now they sign their own addresses and quote them in the forums. As I pointed out there already the centralized storage in the forums is not secury anyhow and signed messages could be swapped easily with the next hack of the forums. Is that use case taken care of in any plans already? I thought about abusing pgp keyservers but that would suit for single vanity addresses only. It seems webfinger could be part of a solution where servers of a business can tell and proof you if a specific address is owned by them. [0] https://bitcointalk.org/index.php?topic=502538 [1] https://bitcointalk.org/index.php?topic=505095 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] secure assigned bitcoin address directory
The code will be available as soon as we are ready, and apologies again for it not being a more meaningful conversation - I did say I hesitated about posting it ;) I think it is fair to say that we have not assumed anything about other technologies, without asking if they can answer all (not just some) of the questions I raised. I have yet to be convinced that anything existing meets those requirements, namecoin included, hence why we are looking at creating an alternative (non-coin by the way) but this alternative has some of the important properties that the distributed ledger provides. To answer the question about expiry, we're looking at something we'll call proof-of-life for the device keys. In a nutshell on of the pieces of information stored with the device public key will be a last heard from date - a date which is sent only by the device from time to time. Records that are expired are devices that have not been heard from for a given period (to be decided). As the device keys are not related to the Bitcoin keys it will be safe to expire a device key by default. An expired device would require reinitialisation, which would make a new device key set, a new proof of life date and then the Bitcoin keys (BIP32) can be restored. Regards Chris D'Costa Sent from my iPhone On 1 Apr 2014, at 13:32, Jeff Garzik jgar...@bitpay.com wrote: Re-reading this, even with the most recent message, is still isn't clear _precisely_ how your technology works, or why it is better than namecoin. User profiles (and distributed ledgers) need to reflect the latest updates, and a stream of updates of over time is precisely what bitcoin technology secures. Keys expire or are compromised, and the public ledger needs to reflect that. There is a lot of computer science involved in making sure the public ledger you see is not an outdated view. A log-like stream of changes is not the only way to do things, but other methods need less hand-wavy details (show the code) before they are well recognized as useful. On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa chris.dco...@meek.io wrote: Security of transmission of person-to-person pay-to addresses is one of the use cases that we are addressing on our hardware wallet. I have yet to finish the paper but in a nutshell it uses a decentralised ledger of, what we refer to as, device keys. These keys are not related in any way to the Bitcoin keys, (which is why I'm hesitating about discussing it here) neither do they even attempt to identify the human owner if the device. But they do have a specific use case and that is to provide advanced knowledge of a publickey that can be used for encrypting a message to an intended recipient, without the requirement for a third-party CA, and more importantly without prior dialogue. We think it is this that would allow you to communicate a pay-to address to someone without seeing them in a secure way. As I understand it the BlockChain uses time bought through proof of work to establish a version of the truth, we are using time in the reverse sense : advanced knowledge of all pubkeys. Indeed all devices could easily check their own record to identify problems on the ledger. There is of course more to this, but I like to refer to the distributed ledger of device keys as the Web-of-trust re-imagined although that isn't strictly true. Ok there you have it. The cat is out of the bag, feel free to give feedback, I have to finish the paper, apologies if it is not a topic for this list. Regards Chris D'Costa On 31 Mar 2014, at 12:21, vv01f vv...@riseup.net wrote: Some users on bitcointalk[0] would like to have their vanity addresses available for others easily to find and verify the ownership over a kind of WoT. Right now they sign their own addresses and quote them in the forums. As I pointed out there already the centralized storage in the forums is not secury anyhow and signed messages could be swapped easily with the next hack of the forums. Is that use case taken care of in any plans already? I thought about abusing pgp keyservers but that would suit for single vanity addresses only. It seems webfinger could be part of a solution where servers of a business can tell and proof you if a specific address is owned by them. [0] https://bitcointalk.org/index.php?topic=502538 [1] https://bitcointalk.org/index.php?topic=505095 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] secure assigned bitcoin address directory
I posted some code on Reddit a while back around adding a simple x509 digital signature to a Bitcoin address URL, since you could gain the benefit of an x.509 authenticated Bitcoin address without having to do a full BIP70 implementation. It's not WoT, but x509, for all its flaws, works very well in the real world almost all of the time. For added authentication, one could always wrap the URL with a PGP signature. After lurking on this list for a while, I assumed there's some reason this hasn't already been implemented, likely based in the general disgust around x509. Anyway, here's my idea (complete with working Java source): http://www.reddit.com/r/BitcoinSerious/comments/1sebj0/proposal_bitcoin_invoice_signatures/ FWIW. --Daryl On Tue, Apr 1, 2014 at 7:20 AM, Chris D'Costa chris.dco...@meek.io wrote: The code will be available as soon as we are ready, and apologies again for it not being a more meaningful conversation - I did say I hesitated about posting it ;) I think it is fair to say that we have not assumed anything about other technologies, without asking if they can answer all (not just some) of the questions I raised. I have yet to be convinced that anything existing meets those requirements, namecoin included, hence why we are looking at creating an alternative (non-coin by the way) but this alternative has some of the important properties that the distributed ledger provides. To answer the question about expiry, we're looking at something we'll call proof-of-life for the device keys. In a nutshell on of the pieces of information stored with the device public key will be a last heard from date - a date which is sent only by the device from time to time. Records that are expired are devices that have not been heard from for a given period (to be decided). As the device keys are not related to the Bitcoin keys it will be safe to expire a device key by default. An expired device would require reinitialisation, which would make a new device key set, a new proof of life date and then the Bitcoin keys (BIP32) can be restored. Regards Chris D'Costa Sent from my iPhone On 1 Apr 2014, at 13:32, Jeff Garzik jgar...@bitpay.com wrote: Re-reading this, even with the most recent message, is still isn't clear _precisely_ how your technology works, or why it is better than namecoin. User profiles (and distributed ledgers) need to reflect the latest updates, and a stream of updates of over time is precisely what bitcoin technology secures. Keys expire or are compromised, and the public ledger needs to reflect that. There is a lot of computer science involved in making sure the public ledger you see is not an outdated view. A log-like stream of changes is not the only way to do things, but other methods need less hand-wavy details (show the code) before they are well recognized as useful. On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa chris.dco...@meek.io wrote: Security of transmission of person-to-person pay-to addresses is one of the use cases that we are addressing on our hardware wallet. I have yet to finish the paper but in a nutshell it uses a decentralised ledger of, what we refer to as, device keys. These keys are not related in any way to the Bitcoin keys, (which is why I'm hesitating about discussing it here) neither do they even attempt to identify the human owner if the device. But they do have a specific use case and that is to provide advanced knowledge of a publickey that can be used for encrypting a message to an intended recipient, without the requirement for a third-party CA, and more importantly without prior dialogue. We think it is this that would allow you to communicate a pay-to address to someone without seeing them in a secure way. As I understand it the BlockChain uses time bought through proof of work to establish a version of the truth, we are using time in the reverse sense : advanced knowledge of all pubkeys. Indeed all devices could easily check their own record to identify problems on the ledger. There is of course more to this, but I like to refer to the distributed ledger of device keys as the Web-of-trust re-imagined although that isn't strictly true. Ok there you have it. The cat is out of the bag, feel free to give feedback, I have to finish the paper, apologies if it is not a topic for this list. Regards Chris D'Costa On 31 Mar 2014, at 12:21, vv01f vv...@riseup.net wrote: Some users on bitcointalk[0] would like to have their vanity addresses available for others easily to find and verify the ownership over a kind of WoT. Right now they sign their own addresses and quote them in the forums. As I pointed out there already the centralized storage in the forums is not secury anyhow and signed messages could be swapped easily with the next hack of the forums. Is that use case taken care of in any plans already? I thought
[Bitcoin-development] Finite monetary supply for Bitcoin
Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! Thanks, -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1. :-) On Tuesday, 1 April 2014, at 9:00 pm, Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! Thanks, -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 1, 2014 at 12:00 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 A minor nitpick: It is well known that the Bitcoin core developers are some of the most active TypeScript coders around, E.g. http://osrc.dfm.io/sipa and http://osrc.dfm.io/gavinandresen But I think this is an important step forward: Seminal alternative crypto-currencies such as SolidCoin showed us that economic parameters can be freely changed at any time, for any (or no) reason at all; and so we should take this opportunity to demonstrate our commitment to adopting innovative features like non-inflation regardless of their origins in other crypto-currencies. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
This proposal will destroy Bitcoin. I would expect nothing less coming from a Google employee. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! I cleaned it up a bit. By 2214, we should be using tonal numbers after all: https://gist.github.com/luke-jr/9920788 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
luke, you might enjoy the book Topos of Music. It's a complete mathematical music theory by a student of Grothendieck. He advanced Euler's theories of harmony based on advanced category theory. I'm sure there are many applications to Bitcoin. On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr l...@dashjr.org wrote: On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! I cleaned it up a bit. By 2214, we should be using tonal numbers after all: https://gist.github.com/luke-jr/9920788 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
Please, *music* is obsolete, but inline replies *are not*! On Tuesday, April 01, 2014 7:16:42 PM Benjamin Cordes wrote: luke, you might enjoy the book Topos of Music. It's a complete mathematical music theory by a student of Grothendieck. He advanced Euler's theories of harmony based on advanced category theory. I'm sure there are many applications to Bitcoin. On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr l...@dashjr.org wrote: On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! I cleaned it up a bit. By 2214, we should be using tonal numbers after all: https://gist.github.com/luke-jr/9920788 - - ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
I disagree with this proposal both in spirit and in practice. We all know satoshi was the best programmer like no one ever was. Clearly he intended this monetary supply from the beginning, who are we but mere mortals to go against satoshi's will? Also, should we really do this with a soft fork when we can take this opportunity to redesign the whole system with a hard fork? This is out chance to switch to a whole new script engine! Matt On April 1, 2014 3:00:07 PM EDT, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! Thanks, -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
I've sat on this for some time after starting this. I have forked this from bitcoin core and am working on a secure tax mode for bitcoin. It is written in Autoit. I know I know, scripting language alert! I would like people to look at: http://www.githubb.com/bitcoin/bitcoin Look at it, and let's have an open dialog about it. I want to know the good, the bad, and the ugly! -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 01, 2014 at 09:00:07PM +0200, Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 What's interesting about this bug is we could also fix the problem - the economic shock - by first implementing the OP_CHECKLOCKTIMEVERIFY opcode in a soft-fork, followed by a second soft-fork requiring miners to pay-forward a percentage of their coinbase outputs to the future. (remember that whomever mines a block controls what recently-made-available anyone-can-spend txouts are included in their block) We could then pick the distribution rate fairly arbitrarily; I propose the following linear distribution: Each gold mine produces 21,000,000 coins over 210,000*64 blocks, or 1.5625 BTC/block evenly distributed. Measured as an absolute against the monetary the inflation rate will converge towards zero; measured against the actual economic monetary supply the value will converge towards some low value of inflation. In the short run we get an immediate reduction in inflation, which can help our currently sluggish price. Either outcome should be acceptable to any reasonable goldbug - fortunately our community is almost entirely made up of such calm and reasonable people. Meanwhile maintaining a miner reward has significant advantages in terms of the long-term sustainability of the system - everyone needs PoW security regardless of whether or not you do transactions, thus we should all pay into it. As for your example of Python, I'm sure they'll accept a pull-req changing the behavior in the language. -- 'peter'[:-1]@petertodd.org f4f5ba334791a4102917e4d3f22f6ad7f2c4f15d97307fe2 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 1, 2014 at 10:00 PM, Peter Todd p...@petertodd.org wrote: On Tue, Apr 01, 2014 at 09:00:07PM +0200, Pieter Wuille wrote: The text can be found here: https://gist.github.com/sipa/9920696 What's interesting about this bug is we could also fix the problem - the economic shock - by first implementing the OP_CHECKLOCKTIMEVERIFY opcode in a soft-fork, followed by a second soft-fork requiring miners to pay-forward a percentage of their coinbase outputs to the future. (remember that whomever mines a block controls what recently-made-available anyone-can-spend txouts are included in their block) We could then pick the distribution rate fairly arbitrarily; I propose the following linear distribution: Interesting idea, but perhaps we can keep that change for a future hard fork, as Matt suggested? That means it could be implemented much more concisely too. Mike, I'm sad to hear you feel that way. I'll move your name in the document from ACKnowledgements to NAKnowledgements. As this is a relatively urgent matter - we risk forks within 250 years otherwise, I'd like to move this forward quickly. In case there are no further objections (excluding from people who disagree with me), I'd like to request a BIP number for this. Any number is fine, I guess, as long as it's finite. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 1, 2014 at 9:04 PM, Matt Whitlock b...@mattwhitlock.name wrote: The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1. Thanks - fixed! -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On 4/1/14, Matt Corallo bitcoin-l...@bluematt.me wrote: Also, should we really do this with a soft fork when we can take this opportunity to redesign the whole system with a hard fork? This is out chance to switch to a whole new script engine! +1 The hard fork also forces the whole community and not a few miners to decide. Well, if it is possible for the community to reach an agreement with such a short time frame... Matt On April 1, 2014 3:00:07 PM EDT, Pieter Wuille pieter.wui...@gmail.com wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! Thanks, -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com wrote: In case there are no further objections (excluding from people who disagree with me), I'd like to request a BIP number for this. Any number is fine, I guess, as long as it's finite. With ten people commenting on this proposal there are quite a few ways in which you could partition their views. Only one possible integer partitioning has everyone in the same partition, so consensus seems unlikely. But owing to a rather large bribe (or at least not less large than any other offered by competing parties) I hereby assign BIP 42 for this proposal. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 1, 2014 at 4:47 PM, Gregory Maxwell gmaxw...@gmail.com wrote: But owing to a rather large bribe (or at least not less large than any other offered by competing parties) I hereby assign BIP 42 for this proposal. What about BIP 420? Everyone knows if you add zero it's still the same number. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
I move to reclaim bip 42 as reserved for a bip containing either a reference to musical dolphins or towels in the name. Matt On April 1, 2014 5:47:34 PM EDT, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com wrote: In case there are no further objections (excluding from people who disagree with me), I'd like to request a BIP number for this. Any number is fine, I guess, as long as it's finite. With ten people commenting on this proposal there are quite a few ways in which you could partition their views. Only one possible integer partitioning has everyone in the same partition, so consensus seems unlikely. But owing to a rather large bribe (or at least not less large than any other offered by competing parties) I hereby assign BIP 42 for this proposal. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 1, 2014 at 5:51 PM, Daryl Banttari dbantt...@gmail.com wrote: What about BIP 420? Everyone knows if you add zero it's still the same number. Similarly, everyone knows if you multiply both sides by zero, the result is always a true statement. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tue, Apr 1, 2014 at 11:47 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com wrote: But owing to a rather large bribe (or at least not less large than any other offered by competing parties) I hereby assign BIP 42 for this proposal. Submitted as BIP 42 (https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki) through PR #42 (https://github.com/bitcoin/bips/pull/42). Thanks! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] secure assigned bitcoin address directory
Chris, Thank you for taking the time to look at my proposal. 1) pay to addresses are not fixed - ie you can have a different address for each transaction (which is why BIP70 is necessary to allow per transaction addresses via https.) This is certainly true for a published address; however a new address (and URL) can be generated for each one-off peer-to-peer transaction. However, I'd expect that most of the time this use case will be handed by BIP70. Still, this could allow someone to implement a authenticated, non-repudiable payment request without having to go through the hassle of a full BIP70 implementation. 2) unless you are already aware of the public key of the signature, you do not know if the signature is made by the person you think it is supposed to be from. See recent concern over fake key for Gavin Andresen. Ie a signature can always be verified with a valid public key, the question is was it the real person's key. That is what WoT tried to resolve with so-called signing parties, nowadays keys posted to a public forum by a known user, but it's not a standard and not ideal. My proposal leverages the existing SSL key system (yes, PKI), so there is a reasonable expectation that if the signature verifies, it came from the party indicated on the cert. While SSL (and the PKI system underpinning it) have its faults, the example you highlighted was specifically a problem with WoT, not PKI. Can a compromised web server cause payments to be made to the wrong party? Of course-- but that's already true. And that's not something BIP70 solves (or attempts to solve) either. (To explain [better than I could] why I feel PKI is a pragmatic solution, I defer to Mike Hearn 's article: https://medium.com/bitcoin-security-functionality/b64cf5912aa7) --Daryl -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] secure assigned bitcoin address directory
Hi Daryl My proposal leverages the existing SSL key system Ok I thought you were suggesting wrapping the URL in an additional PGP signature. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
