[Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32
I've implemented an alternative to the BIP 32 proposal. I wanted a system based on a hierarchical string representation (rather than hierarchy of integers as BIP 32 proposes). For example I name keys like this: [hd1.7549].store.1. 1D7GM5dkUtxvGeWgn7SYtanBuyj1MD1EZy [hd1.7549].store.2. 1QAqDbzpNKViGSjVe1XmnGbmZtvz5hM7t1 [hd1.7549].store.3. 14XkSN92QLGeorYPpoVbG87DQhowEx3mFn [hd1.7549].store.4. 1JLcGdod6Wm33rMZuZZUmAEE6osLhM4QMn First draft of proposal: https://gist.github.com/4211704 I envision using this in services, so I've not done any work to recommend how the keys would be represented directly in the client (I just map from a seed value and a hierarchy string in order to deterministic ally derive ECDSA public and private keys). I'm happy to release my source code for this (Python). But I'd first like to get feedback about any security concerns with my scheme (I note that I don't introduce the enlarged key space that BIP 32 does with its chain code - I'm wondering if that represents a weakness of my scheme vs. BIP 32). On Mon, Dec 3, 2012 at 12:44 PM, Pieter Wuille pieter.wui...@gmail.comwrote: On Mon, Dec 03, 2012 at 06:48:34AM -0800, Amir Taaki wrote: ok, also what is the reasoning behind serialising points using a compressed format before going into the hash function? I'm looking at the sec1-v2.pdf and the compression format is a little confusing. I don't think there is a compelling reason to encourage uncompressed public keys anymore on the network. They take more space in the block chain for no additional value whatsoever. Software may of course continue supporting uncompressed keys if they wish to provide compatibility, but for a new standard, I think it makes sense to standardize on just compressed keys. And since that software thus needs to support the compressed encoding, there is no reason to use a different encoding inside the derivation scheme itself. Regarding the encoding itself, it is not hard: just 0x02 or 0x03 (depending on whether Y is even or odd) followed by the 32-byte encoding of X. Decoding is harder, but is never needed in the derivation. Software internally can use any representation (and it will), which in almost all circumstances stores both X and Y (and even more). Decoding compressed public keys is somewhat harder, as Y must be reconstructed (but the algorithm isn't hard) - this is only necessary when someone wants to import an extended public key though for watch-only wallets. -- Pieter -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Mike Koss CTO, CoinLab (425) 246-7701 (m) A Bitcoin Primer http://coinlab.com/a-bitcoin-primer.pdf - What you need to know about Bitcoins. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
The thing that bugged me most about the original spec was the sole reliance
on X.509 - glad to see you've made that optional. I think many people will
balk at deferring our identity trust to the existing CA's. I think it's a
fine bootstrap method, but I'd really like to see another option that
allows for out-of-band trust (based on ECDSA, probably).
It would also be really nice to migrate to textual representations of data
structures as opposed to binary ones. The most successful internet
standards are based on text, making them that much more accessible for
developers to deal with them. JSON would be my preferred candidate.
Why don't we sign the text representation of a (utf8) JSON, rather than
some complex encoding standard of JSON? That way the signatures are simple
- and you need only retain the original textual representation of a message
to validate the signature (as well as the decoded version, if you don't
want to alway re-parse the message when writing programs that use it).
On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen gavinandre...@gmail.comwrote:
Spec updated: https://gist.github.com/4120476
Changes are:
Version numbers: a couple of people asked privately about adding
version numbers to the messages. In general, Protocol Buffers don't
need version numbers if later versions add only optional fields.
And best-practice is to know what version of something you're
expecting BEFORE you start parsing that something.
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
Following that best-practice of knowing what you're parsing before you
parse it, I added an invoice_version field to the SignedInvoice
message. It is now:
message SignedInvoice {
required bytes pki_data = 1;
required string pki_type = 2 [default = x509];
required bytes serialized_invoice = 3;
required uint32 invoice_version = 4 [default = 1];
required bytes signature = 5;
}
Handling of receiptURI errors:
Following discussion here, I changed the spec to say:
Clients may handle errors communicating with the receiptURI server
however they like, but should assume that if they cannot communicate
at all with the server then the Payment should either be retried later
or immediately rejected.
and under Receipt added:
The Bitcoin client must be prepared to handle the case of an evil
merchant that returns accepted=false but broadcasts the transactions
anyway.
I also added a TODO Test Vectors section with base64-encoded
examples of everything.
--
--
Gavin Andresen
--
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer http://coinlab.com/a-bitcoin-primer.pdf - What you need
to know about Bitcoins.
--
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Near-term scalability
would scale perfectly and there would be no need for there to be some winners and some losers when it comes to confirmation time. There was discussion of some one-off changes to address the current situation, namely de-ranking transactions that re-use addresses. Gavin and myself were not keen on this idea, primarily because it just avoids the real problem and Bitcoin already has a good way to prioritize transactions via the fees mechanism itself. The real issue is that SatoshiDice does indeed pay fees and generates a lot of transactions, pushing more traditional traffic out due to artificial throttles. The following set of proposals were discussed: (1) Change the mining code to group transactions together with their mempool dependencies and then calculate all fees as a group. A tx with a fee of 1 BTC that depends on 5 txns with zero fees would result in all 6 transactions being considered to have a fee of 1BTC and therefore become prioritized for inclusion. This allows a transition to receiver pays model for fees. There are many advantages. One is that it actually makes sense ... it's always the receiver who wants confirmations because it's the receiver that fears double spends. Senders never do. What's more, whilst Bitcoin is designed to operate on a zero-trust model in the real world trust often exists and it can be used to optimize by passing groups of transactions around with their dependencies, until that group passes a trust boundary and gets broadcast with a send-to-self tx to add fees. Another advantage is it simplifies usage for end users who primarily buy rather than sell, because it avoids the need to guess at fees, one of the most problematic parts of Bitcoins design now. The disadvantages are that it can result in extra transactions that exist only for adding fees, and it requires a more modern payment protocol than the direct-IP protocol Satoshi designed. It would help address the current situation by avoiding angry users who want to buy things, but don't know what fee to set and so their transactions get stuck. (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to avoid paying excessive fees and queue-jumping. Guess that's on my plate. (3) Scalability improvements seem like a no brainer to everyone, it's just a case of how complicated they are. (4) Making the block size limit float is better than picking a new arbitrary threshold. On the forums Matt stated that block chain pruning was a no-go because it makes bitcoin more centralized. I think we've thrashed this one out sufficiently well by now that there should be a united opinion on it. There are technical ways to implement it such that there is no change of trust requirements. All the other issues (finding archival nodes, etc) can be again addressed with sufficient programming. For the case of huge blocks slowing down end user syncing and wasting their resources, SPV clients like MultiBit and Android Wallet already exist and will get better with time. If Jeff implements the bloom filtering p2p commands I'll make bitcoinj use them and that'll knock out excessive bandwidth usage and parse overheads from end users who are on these clients. At some point Bitcoin-Qt can have a dual mode, but who knows when that'll get implemented. Does that all sound reasonable? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Mike Koss CTO, CoinLab (425) 246-7701 (m) A Bitcoin Primer http://coinlab.com/a-bitcoin-primer.pdf - What you need to know about Bitcoins. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how
Re: [Bitcoin-development] Defeating the block withholding attack
I don't understand how your proposal will work for decentralized pools - can you explain it more concretely? What would the new block header look like? What is required for a share to to be earned? What is required for a block to be valid (added to Block Chain)? I don't think I understand what you mean by NextBlockCandidate. Perhaps a concrete example using difficulty 1.7 million would be instructive. On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr l...@dashjr.org wrote: On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote: As I understand the attack, the attacker gets compensated for the shares they earn, but the pool will be denied any valid blocks found. The attacker DOES NOT have access to the Bitcoins earned in the unreported block (only the mining pool has access to the Coinbase address and transactions in the block). With decentralized pools, the attacker does have access to the block, and can potentially submit it to the Bitcoin network directly bypassing the pool if it benefits them to do so. So it's a zero-net-cost attack for the attacker (but no chance of making a profit) to hurt the pool operator. Because of the above, there is a possibility an attacker can make a profit. The only way to detect such an attack now is to look for unlucky miners; at the current difficulty, you can't detect this cheat until many millions of shares have been earned w/o a qualifying block. Since an attacker can also create many fake identities, they can avoid detection indefinitely by abandoning each account after a million earned shares. There are other modes of detection, but nobody has bothered to implement them since attackers can easily do a simple workaround in an arms race. I don't understand your proposal for fixing this. You would have to come up with a scheme where: - The miner can detect a qualifying hash to earn a share. - Not be able to tell if the hash is for a valid block. With my proposal, miners can find shares, but won't know if it's a valid block until the subsequent block is also found (that subsequent block might not end up being a real block in the big picture). The way I would do this is to have a secret part (not shared with the miners) of a block that is part of the merkle hash, which is also used in a secondary hash. Difficulty is then divide into two parts: the first, solved by the miner (earning a share - e.g., 1 in 4 Billion hashes). And a second, solved by the pool (1 in Difficulty shares). A valid block would have to exhibit a valid Share Hash AND a valid Pool Hash in order to be accepted. This only works for centralized pools, which are contrary to the health of the Bitcoin network. Decentralized pools cannot have a secret. -- Mike Koss CTO, CoinLab (425) 246-7701 (m) A Bitcoin Primer http://coinlab.com/a-bitcoin-primer.pdf - What you need to know about Bitcoins. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Signature Blocks and URI Sign Requests
Alan, I'm coming in late to the conversation - do I understand that BIP 010 does not propose any changes to the protocol - but just an intermediate data format that other clients might use to collect the need key material to sign a multi-signature block? If so - one might ask what the role of BIP's are if they actually do not impact the protocol? If there is any encapsulated data format that is expected to be interpreted by clients - I'd call that a protocol change; but I take it in this instance that you will transmit these signature block out of band from the client ... yet they would have to be parsed and converted into a Transaction Script once collected by SOME client? Would we expect the standard client do so? Sorry if this has been discussed before - I'm trying to understand the proposal. On Tue, Apr 3, 2012 at 2:12 PM, Alan Reiner etothe...@gmail.com wrote: ** Just to clarify, I'm not proposing anything to the protocol itself. Simply that some applications might benefit from users being to sign messages with existing Bitcoin identities, and what can we do to accommodate that (out of band)? It's not a high priority, but I think it's potentially useful, and most codebases already have everything they need in place to implement it. On 04/03/2012 04:04 PM, Peter Vessenes wrote: I don't think it's minimally invasive to layer PGP's web of trust on top of Bitcoin, in fact, the opposite. From a certain angle, bitcoin exists as a sort of answer / alternate solution to the web of trust. Digital cash with an existing web of trust in place was a working concept in the mid-1990s, courtesy of David Chaum, I believe. I totally agree on the kitchen sink concern; I would personally like to see something like a one-year required discussion period on all non-security changes proposed to the blockchain protocol. We know almost nothing about how bitcoin will be used over the next 20 years; I believe it's a mistake to bulk up the protocol too rapidly right now. There's a famous phrase from the founder of Lotus about Lotus' engineering process: add lightness. The equivalent for protocol design might be add simplicity. I'd like to see us adding simplicity for now, getting a core set of tests together for alternate implementations like libbitcoin, and thinking hard about the dangers of cruft over a 10+ year period when it comes to a technology which will necessarily include a complete history of every crufty decision embodied in transaction histories. Peter On Tue, Apr 3, 2012 at 1:42 PM, Wladimir laa...@gmail.com wrote: On Tue, Apr 3, 2012 at 8:55 PM, Luke-Jr l...@dashjr.org wrote: On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote: We should avoid reinventing the wheel, if we can. I think we should extend existing standards whenever possible. I wonder if it's possible to make sigs compatible with PGP/EC ? Or we could take a step back, further into don't reinvent the wheel territory. Why not simply make use of PGP(/EC) to sign and verify messages? It has many advantages, like an already existing web-of-trust and keyserver infrastructure. I still feel like this is sign message stuff is dragging the kitchen sink into Bitcoin. It's fine for logging into a website, what you use it for, but anything that approaches signing email (such as S/MIME implementations and handling different character encodings) is going too far IMO. Wladimir -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free.http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Mike Koss CTO, CoinLab (425) 246-7701 (m
