slush | 23 Jan 15:51 2015
Picon

SIGHASH_WITHINPUTVALUE

Hi,

is any progress or even discussion in this area? 


I don't insist on any specific solution, but this is becoming a real issue as hardware wallets are more widespread. I'm sitting next to TREZOR for 40 minutes already, because it streams and validate some complex transaction. By using proposed solution, such signature would be a matter of few seconds.

That's also not just about time/resource/hw cost optimization. I'm talking about possibility of huge simplification of the firmware (=security FTW), because 50% of actual codebase is solving this particular downside of Bitcoin protocol.

So, there's real world problem. On which solution can we as a community find a wide agreement?

Best,
Marek
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Jonathan Brown | 22 Jan 11:20 2015

Ensuring security of funds and preserving anonymity when using Bitcoin for e-commerce

I wrote a blog post entitled "Ensuring security of funds and preserving anonymity when using Bitcoin for e-commerce".

I thought the readers of this list might be interested.

http://jonathanpatrick.me/blog/bitcoin-ecommerce
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
U.Mutlu | 22 Jan 10:36 2015

Securing wallet on paper

I don't know yet the details of how a wallet looks like internally,
but I think it should be possible to print the wallet incl. acct nbr
out on classical paper (as base16 or base64 etc.) for filing it
in a physical home or bank safe.

Later, typing it from paper to a small converter program that recreates the 
wallet file.

IMO this is a good security against possible computer hardware disasters.

Of course one has to secure this further with encryption against bank 
fraud/theft etc.
Ie. the output on paper should be encrypted, and the owner
should place the key somewhere else.

I would suggest the developers make such functionality available for the user.

cu
Uenal

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
21E14 | 21 Jan 07:07 2015
Picon

Why Bitcoin is and isn't like the Internet

This is a response to a wonderfully insightful recent post by Joichi Ito, the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board Member of ICANN, offered his thoughts on "Why Bitcoin is and isn't like the Internet" and asked a most pertinent question: "Whether there is an ICANN equivalent needed for Bitcoin." As suggested in recent posts to the mailing list, I believe there might be, but for a reason that may not seem obvious at first.

Alan Reiner expressed the need this way: "I think one of the biggest issues facing Bitcoin right now is not the lack of a 'killer app.' It is lack of insurance options. Early adopters would like to believe that the majority of users will hold their own Bitcoin, but I believe that is not a realistic option when life-changing quantities of Bitcoin are involved. We should not trust Grandma to secure her own retirement savings via complicated computer maneuvers. More to the point, she should not trust herself or anyone else (sic!) to hold it unless there is a strong protection against loss events. Right now the solution is for Grandma to avoid keeping her money in Bitcoin. Bitcoin needs a strong backbone of insured storage options so that Grandma can confidently participate in this new technology." This is certainly an observation to take heed of coming from the founder of Armory Technologies.

The protection against loss events ought to be understood in the broadest sense. What is needed is a disaster recovery mechanism. Andreas Antonopoulos remarks expressed this candidly last year: "Bitcoin doesn't have a middle of the road mediocre growth model. It basically either dies, because of a fundamental flaw in the Bitcoin system. Not an external factor, an internal factor: We blow it up by accident. And that could happen... Bitcoin will play out in the next three years. In the next three years we're going to see Bitcoin arrive on the global stage and make a substantial impact, both in financial terms and in political terms. It will happen. Or it will die. Either way. I'm not sure. In which case we'll reboot another currency."

A body, not entirely unlike ICANN, can manage the nexus to the physical world, and help address Bitcoin's catastrophic failure modes. Bitcoin's coin ownership protocol would thus join the ranks of its payment protocol, coin issuance protocol, consensus mechanism and inflation control that pose no lethal threat to the ecosystem. In addition to their coin-agnostic nature, I suspect the high valuation of large Bitcoin hubs relative to Bitcoin's market cap at this stage in its lifecycle is partly reflective of the sneaking suspicion that a custodial bitcoin (a bitcoin attached to an identity) may be worth more than a non-custodial one. With this in mind, I'll pitch in for the ticket should Dr. Ito decide to join the next month's DevCore Boston conference aimed at supporting the future development of Bitcoin. It's an hour's walk from MIT after all.
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Pieter Wuille | 21 Jan 01:35 2015
Picon

[softfork proposal] Strict DER signatures

Hello everyone,

We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The recent evens (see the thread titled
"OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection."
on this mailing list) have made it clear that the problem is very
real, however, and I would prefer to have a fundamental solution for
it sooner rather than later.

I therefore propose a softfork to make non-DER signatures illegal
(they've been non-standard since v0.8.0). A draft BIP text can be
found on:

    https://gist.github.com/sipa/5d12c343746dad376c80

The document includes motivation and specification. In addition, an
implementation (including unit tests derived from the BIP text) can be
found on:

    https://github.com/sipa/bitcoin/commit/bipstrictder

Comments/criticisms are very welcome, but I'd prefer keeping the
discussion here on the mailinglist (which is more accessible than on
the gist).

--

-- 
Pieter

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
Kristov Atlas | 20 Jan 19:52 2015
Picon

Request for Comment: Bitcoin Wallet Privacy Ratings Criteria

The Open Bitcoin Privacy Project is seeking public comment on our ratings criteria for Bitcoin wallet privacy. Please provide your feedback within the next week through Jan 23, 2015 to ensure that it will be considered for version 1.0 of the document.

https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/criteria.md

In conjunction with a scoring matrix that will determine the weight of each sub-category, this criteria will be used to evaluate and score a variety of Bitcoin wallets, which will be published on our website at openbitcoinprivacyproject.org.

Feedback through this mailing list is, of course, welcome; if you have a GitHub account, this is the preferred medium for proposing changes to the document.

The current version of the criteria was authored by myself, as well as other OBPP members including Justus Ranvier (Monetas), Chris Pacia (Bitcoin Authenticator), and Samuel Patterson (Open Bazaar).

Thank you in advance for your feedback,

Kristov Atlas
author <at> anonymousbitcoinbook.com
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Peter Todd | 20 Jan 18:15 2015

Re: The legal risks of auto-updating wallet software; custodial relationships

On Tue, Jan 20, 2015 at 08:43:57AM -0800, Daniel Stadulis wrote:
> Hey Peter,
> 
> What would you say to the argument: given developers have auto update
> capabilities they only have the ability to *give themselves* *the ability* to
> have custodial rights?

Heh, well, courts tend not to have the narrow-minded pedantic logic that
programmers do; quite likely that they'd see having the ability to give
themselves the ability as equivalent to simply having the ability. What
matters more is intent: the authors of an operating system had no intent
to have a custodial relationship over anyones' BTC, so they'd be off the
hook. The authors of a Bitcoin wallet on the other hand, depends on how
you go about it.

For instance Lighthouse has something called UpdateFX, which allows for
multi-signature updates. It also supports deterministic builds, and
allows users to chose whether or not they'll follow new updates
automatically, or only update on demand. In a court that could be all
brought up as examples of intent *not* to have a custodial relationship,
which may be enough to sway judge/jury, and certainly will help avoid
ending up in court in the first place by virtue of the fact that all
those protections help avoid theft, and increase the # of people that an
authority need to involve to seize funds via an update.

--

-- 
'peter'[:-1] <at> petertodd.org
00000000000000001a5e1dc75b28e8445c6e8a5c35c76637e33a3e96d487b74c
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Peter Todd | 20 Jan 16:46 2015

The legal risks of auto-updating wallet software; custodial relationships

I was talking to a lawyer with a background in finance law the other day
and we came to a somewhat worrying conclusion: authors of Bitcoin wallet
software probably have a custodial relationship with their users,
especially if they use auto-update mechanisms. Unfortunately this has
potential legal implications as custodial relationships tend to be
pretty highly regulated.

Why is this? Well, in most jurisdictions financial laws a custodial
relationship is defined as having the ability, but not the right, to
dispose of an asset. If you have the private keys for your users'
bitcoins - e.g. an exchange or "online" wallet - you clearly have the
ability to spend those bitcoins, thus you have a custodial relationship.
However if you can trivially obtain those private keys you can also
argue you have a custodial relationship. For instance StrongCoin was
able to seize funds stolen from OzCoin¹ with a small change to the
client-side Javascript their users download from them every time they
visit the site. Portraying that as "the ability to dispose of an asset"
in a court of law would be pretty easy. Equally on a technical level
this isn't much different from how auto-updating software works.

Now I'm sure people in this audience will immediately point out that by
that logic your OS vendor is also in a custodial relationship - they
after all can push an update that steals everyones' bitcoins regardless
of what local wallet you use. But the law isn't a deterministic
algorithm, it's a political process. Circle is easy to portray as having
a custodial relationship, StrongCoin and Blockchain.info are a little
harder, Android Wallet harder still, Bitcoin Core's multi-party
deterministicly compiled releases even harder.

But ultimately we're not going to know until court cases start
happening. In the meantime probably the best advice - other than getting
out of the wallet business! - is to do everything you can to prevent
losses through malicious auto-updates. Create systems where as many
people as possible have to sign off and review an update before it has
the opportunity to spend user funds. Not having auto-updates at all is a
(legally) safe way to achieve that goal; if you do have them make sure
the process by which an update happens is controlled by more than one
person and there are mechanisms in place to create good audit logs of
how exactly an update happened.

Finally keep in mind that one of the consequences of a custodial
relationship is that some legal authority might try to *force* you to
seize user funds. StrongCoin made it 100% clear to authorities that they
and sites like them are able to seize funds at will - I won't be
surprised if authorities use that power in the future. The more
automatic and less transparent an update is, the higher the chance some
authority will lean on you to seize funds. So don't make it easy for
yourself to meet those demands.

1) https://bitcoinmagazine.com/4273/ozcoin-hacked-stolen-funds-seized-and-returned-by-strongcoin/

--

-- 
'peter'[:-1] <at> petertodd.org
00000000000000001a5e1dc75b28e8445c6e8a5c35c76637e33a3e96d487b74c
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Richard Brady | 19 Jan 20:07 2015
Picon

BIP70: why Google Protocol Buffers for encoding?

Hi Gavin, Mike and co

Is there a strong driver behind the choice of Google Protocol Buffers for payment request encoding in BIP-0070?

Performance doesn't feel that relevant when you think that:
1. Payment requests are not broadcast, this is a request / response flow, much more akin to a web request.
2. One would be cramming this data into a binary format just so you can then attach it to a no-so-binary format such as HTTP. 

Some great things about protocols/encodings such as HTTP/JSON/XML are:
1. They are human readable on-the-wire. No Wireshark plugin required, tcpdump or ngrep will do.
2. There are tons of great open source libraries and API for parsing / manipulating / generating.
3. It's really easy to hand-craft a test message for debugging.
4. The standards are much easier to read and write. They don't need to contain code like BIP-0070 currently does and they can contain examples, which BIP70 does not. 
5. They are thoroughly specified by independent standards bodies such as the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
6. They're a family ;-)

Keen to hear your thoughts on this and very keen to watch the payment protocol grow regardless of encoding choice! My background is SIP / VoIP and I think that could be a fascinating use case for this protocol which I'm hoping to do some work on.

Best,
Richard

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Rune Kjær Svendsen | 17 Jan 21:45 2015
Picon

IMPULSE: Instant Payments using the Bitcoin protocol

Hi list

Found this on reddit: http://impulse.is/


I'd love to hear this list's thoughts.

/runeks
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Ruben de Vries | 16 Jan 11:16 2015

Re: convention/standard for sorting public keys for p2sh multisig transactions

Since we only need the sorting for creating the scriptPubKey, 
wouldn't it make the most sense to sort it by the way it represented in that context?


On Thu, Jan 15, 2015 at 2:03 PM, Wladimir <laanwj <at> gmail.com> wrote:
On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock <bip <at> mattwhitlock.name> wrote:
> On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
>> Internally, pubkeys are DER-encoded integers.
>
> I thought pubkeys were represented as raw integers (i.e., they're embedded in Script as a push operation whose payload is the raw bytes of the big-endian representation of the integer). As far as I know, DER encoding is only used for signatures. Am I mistaken?

OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
DER-encoded signature on the stack.

Possibly you're confused with OP_HASH160 <hash160> OP_EQUALVERIFY as
used in outputs, which compares the 160-bit hash of the pubkey against
the given hash (usually taken from a bitcoin address).

It doesn't help understanding to consider either as integers. They are
binary blob objects with either a fixed format (DER) or a fixed size
(hashes).

Wladimir



--
BlockTrail B.V.
Barbara Strozzilaan 201
1083HN Amsterdam
The Netherlands

Phone: +31 (0)612227277

BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Gmane