Re: [Bitcoin-development] Bitcoin Protocol Specification
This is probably the best, most complete resource available for those who don't want to (or don't know how to) wade through the code. Well done. On 7 July 2014 19:57, JMOlmos GMail coloniz...@gmail.com wrote: And for translation's facility :P 2014-07-07 14:57 GMT-03:00 JMOlmos GMail coloniz...@gmail.com: And for translation's facility :P 2014-07-02 22:21 GMT-03:00 Isidor Zeuner cryptocurrenc...@quidecco.de: Hello Krzysztof, [...] As before, it can be found under: http://enetium.com/resources/Bitcoin.pdf I hope it will prove useful to the community and thank in advance for any further improvement proposals. I think it's great work and provides a good reference for those who want to get some insight into Bitcoin's design. Have you considered putting the document source under version control, which may facilitate tracking future protocol improvements in the document easily? Best regards, Isidor -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bits: Unit of account
I have a rather off-beat suggestion. Perhaps decimal was not satoshi's intention. In old English money 1 guinea is 21 shillings. I wonder if 1 million guineas is more or less the total number of bitcoins = 21 million shillings. There was also the notion of bits (two bob bits = 1 florin = 2 shillings). I quite like the idea as it's absolutely not expected. Old English money is a funny mix of decimal and imperial (base12) measures but may have some interesting properties, one of which would be to have multiple names for overlapping layers not just the 2 or 3 that has been mentioned here and elsewhere. I wonder in the long run if this will not just naturally occur anyway. Regards Chris D'Costa Email: chris_dco...@meek.io Sent from my iPhone On 23 Apr 2014, at 11:56, Tamas Blummer ta...@bitsofproof.com wrote: The problem is µBTC that bit tries to solve. BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The mixed use of them leads to misunderstanding. I think adoption would benefit of a single unit with easily remembered and associated name that has no smaller than 1/100 fractions called satoshis. Regards, Tamás Blummer Founder, CEO email.png http://bitsofproof.com On 23.04.2014, at 11:44, Danny Hamilton danny.hamil...@gmail.com wrote: It seems to me that xbit is no more distinct or intuitive than µbit. In either case it's simply an arbitrary character in front of the word bit. Of course, for the majority of the world familiar with SI, the µ actually adds additional meaning that is lost with the x. Furthermore, given the multiple concerns voiced about the overuse of the word bit, µBTC seems to solve the problem. Since we are talking about how it would be displayed in software, we don't need to be concerned about how people will pronounce it, or what the nickname will be. If most of the wallets start displaying amounts in µBTC quantities, it will be obvious that a µBTC is a different magnitude than a BTC. Nobody is going to look at their 100,000 µBTC balance and think they have 100,000 BTC. People will immediately make the mental adjustment to the new order of magnitude even if they don't specifically know that µ means micro, or that micro means 1e-6. Nicknames will form organically (much like buck, fin, large, k, grand, and benny for U.S. currency), I've always been partial to milly (or millie) and mike (or micky) as nicknames for mBTC and µBTC. I've personally used those when speaking with people, and they seem to catch on pretty quickly. As has already been mentioned, you're going to be hard pressed to find software that denotes U.S. balances in bucks. There isn't any good reason to be coding a nickname like bit, xbit, or mike into wallet software. - Danny Hamilton On Tue, Apr 22, 2014 at 8:51 AM, Aaron Axvig aa...@axvigs.com wrote: That piece of horse equipment is called a bit in the US too. But the point stands: most people don't use bit on a daily basis other than referring to a little bit of something. -Original Message- From: Wladimir [mailto:laa...@gmail.com] Sent: Sunday, April 20, 2014 11:27 AM To: Chris Pacia Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] bits: Unit of account On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia ctpa...@gmail.com wrote: The term bit is really only overloaded for those who are techy. 95% of the population never uses the term bit in their daily lives and I doubt most could even name one use of the term. Plus bit used to be a unit of money way back when, so this is kind of reclaiming it. I think it's a great fit. That's a very anglocentric way of thinking. Here in the Netherlands, a bit is something you put in a horses's mouth. It's also used as imported word (in the information sense). We've never used the term for money. Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists
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
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 https://lists.sourceforge.net/lists
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
Re: [Bitcoin-development] secure assigned bitcoin address directory
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
Re: [Bitcoin-development] secure assigned bitcoin address directory
The idea was not to register profiles or any human identity, or associate it with any other identity directly. Neither was it to have a massive BlockChain, or use proof of work. In this case proof of work is detrimental to security - you want as many people to know about your keys as quickly as possible. I want to add that this implies a shadow p2p network. Also it's just a point if view, but I thought it better not to have any specific link to a person's identity, or their Bitcoin identity by which I mean no connection to their public addresses. The device keys are not meant to be a permanent identity or to store encrypted data either (think what happens if the device changes hands), so the use case is only to establish secure communications, and to verify signatures whilst still in use by the owner. A new owner would need to establish a new device key - again this is in the details and probably more specific to the project. Regards Chris D'Costa On 31 Mar 2014, at 13:46, Natanael natanae...@gmail.com wrote: This sounds like Namecoin. You can already register profiles with it, including keypairs. onename.io is a web-based client you can use to register on the Namecoin blockchain. On Mon, Mar 31, 2014 at 1:14 PM, 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Post to list request
Hello I wonder if I could be granted access to post to the dev list. My project is the Meek hardware wallet, and we are working on a solution to avoid MITM attacks when communicating a pay-to information over a non-secure transport mechanism. Regards Chris -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development