Wladimir | 18 Oct 12:13 2014
Picon

Re: About watch-only addresses

On Fri, Oct 17, 2014 at 10:36 PM, Flavien Charlon
<flavien.charlon <at> coinprism.com> wrote:
> Hi,
>
> What is the status of watch-only addresses in Bitcoin Core? Is it merged in
> master and usable? Is there documentation on how to add a watch-only address
> through RPC.

It has been merged. There is the "importaddress" RPC call, which works
the same as "importprivkey" except that you a pass it an address.

> Also, I believe that is going towards the 0.10 release, is there a rough ETA
> for a release candidate?

Yes - aim is in a few months, probably by the end of the year.

AFAIK there are no nightly builds at this moment. Warren Togami was
building them for a while (at http://nightly.bitcoin.it/) but he
stopped some time around June.

It's not recommended to use master without at least a little bit of
development/debugging experience of yourself (to trace down problems
when they appear), so it's best to build it yourself if you're going
to test day-to-day development versions.

Wladimir

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
(Continue reading)

Flavien Charlon | 18 Oct 11:44 2014

Re: About watch-only addresses

Also, I was wondering if there were nightly builds I could try this from?

On Fri, Oct 17, 2014 at 9:36 PM, Flavien Charlon <flavien.charlon <at> coinprism.com> wrote:
Hi,

What is the status of watch-only addresses in Bitcoin Core? Is it merged in master and usable? Is there documentation on how to add a watch-only address through RPC.

Also, I believe that is going towards the 0.10 release, is there a rough ETA for a release candidate?

Thanks
Flavien

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Flavien Charlon | 17 Oct 22:36 2014

About watch-only addresses

Hi,

What is the status of watch-only addresses in Bitcoin Core? Is it merged in master and usable? Is there documentation on how to add a watch-only address through RPC.

Also, I believe that is going towards the 0.10 release, is there a rough ETA for a release candidate?

Thanks
Flavien
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Andy Schroder | 17 Oct 21:58 2014

Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

Hello,

I'd like to introduce two proposed BIPs. They are primarily focused on implementing the payment protocol using bluetooth connections. I've been working on automated point of sale devices and bluetooth communication is critical in my mind due to the potential lack of internet access at many points of sale, either due to lack of cellular internet coverage, lack of payee providing wireless internet, and/or due to financial constraints of the payer prohibiting them from maintaining a cellular internet service plan. These BIPs are largely modeled after the current functionality of Andreas Schildbach's android Bitcoin Wallet's bluetooth capability. I've discussed the communication scheme with him in depth and believe these proposals to clearly and accurately represent the communication scheme.

There is also an additional &h= parameter added to the bitcoin: URI scheme which applies to both bluetooth and http payment protocol requests which allows for a hash of the payment request to be included. This hash was proposed by Andreas as an amendment to BIP72, but others preferred not to amend BIP72 since it has already been put into place. The current version of Schildbach's bitcoin wallet already supports the "h parameter".

I'd appreciate feedback from everyone, particularly wallet developers as widespread bluetooth support among wallets is very important to me. I'm also very new to this mailing list as well as the BIP writing process, so I'd appreciate your understanding if my conventions are not standard. I am currently using the naming conventions "TBIP", so that I can propose temporary BIP numbers, and cross reference between the two. Obviously these will change if the BIPs are formally adopted. You can find a copy of these proposed BIPs at the following links:

If you are interested, you can see a demonstration of many of the proposed features using Schildbach's wallet and my fuel pump in a video I recently created: https://youtu.be/kkVAhA75k1Y . The main thing not implemented is multiple URLs for the payment protocol, so, as a hack, I'm just presenting https vi QR code and bluetooth via NFC on my fuel pump for now.



There are a few known issues that could be improved to this bluetooth communication scheme as well as the general payment protocol and myself and Andreas would like to receive feedback regarding concerns and potential solutions. Some of the known issues are:

  • There may seem to be some inconsistency in the connection header messages between the payment request connection and the payment connection. This is largely because it is how Andreas originally implemented the communication and is hesitant to change it since there are many instances of is software already deployed that implement this scheme.
  • The current method uses an unauthenticated bluetooth connection for bluetooth 2.1 and newer devices (subject to man in the middle attacks, but not passive eavesdroppers), and an unsecure and unauthenticated connection for older devices. The known concerns here are that someone within 100 meters of the payer could track the bitcoin addresses used for the transaction and could possibly replace the refund address by submitting a forged payment message to the payee. Requiring bluetooth 2.1 and authenticating the connection out of band unfortunately don't seem to be as straightforward/simple of a task with most bluetooth libraries (although I'd love for someone to prove me wrong). It's possible this communication scheme could be extended to use an https "like" protocol that would not care if the underlying bluetooth connection is authenticated or encrypted. It's actually possible that http over a bluetooth socket (instead of tcp socket) could be implemented, however it is presently uncertain whether this would be too slow, too much overhead (both on the devices software and communication), or if http could easily be run over bluetooth sockets on all platforms.
  • There is no acknowledgement failure message possible in the payment protocol, only an acknowledgement message or lack of acknowledgement message. This issue seems to be a concern and as a result, the memo field is used to send an "ack" or "nack" in Schildbach's wallet. Can we add a boolean status field to the payment acknowledgement message?
  • I'd personally like a new optional boolean field added to the "PaymentDetails" portion of the "PaymentRequest" to allow for the payer's wallet to match the "Output" optional "amount" fields as a total amount of all Outputs, rather than requiring the amount for each output to be matched exactly. As it currently is, the payee can specify multiple receiving addresses in order to require a payer split up the payments so that when the payee then goes to spend the funds later, they don't necessarily have to give their payees as much knowledge of their balances and spending and receiving habits and sources. As the payment protocol currently is requiring all output amounts to be matched exactly for each output, there is no flexibility given to the payer in order to reduce a merging or unnecessary diverging of account funds, which can reduce the privacy of both the payer and the payee. If the payee were given the option to allow the payer the option to divide the amounts amount the outputs intelligently, there can be some privacy gained.
  • Amount of data stored in QR codes may be getting large when a backwards compatible URL is used (for wallets that don't support the payment protocol) and can be difficult to scan with outdoor screens that have an extra weather resistant pane when in direct sunlight.
  • The number of offline transactions of a wallet is limited to the known unspent outputs when they go offline. Long term, I'd like to see wallet devices that can use systems such as Kryptoradio's DVB-T based broadcast (but this will need yet another radio!). Another project may be to develop a blockchain query protocol of some kind where retailers can provide access to blockchain data so that customer's wallets can update their known unspent outputs via bluetooth. It's possible such a bluetooth system could be used in combination of "Kryptoradio" like broadcasts to provide multiple blockchain references.
  • The additional payment_url approach is a bit sloppy of a solution in the PaymentDetails portion of the PaymentRequest. It would have been ideal to just change this from an optional field to a repeated field, however, the backwards compatibility in the protocol buffer format will provide the last item in the array for a repeated field (to a code that expects it to be an optional field), rather than the first. Because of this, backwards compatibility with https payment requests wouldn't work if the payment_url field is just changed to a repeated field.
    • Possible alternatives to what is described in the proposed BIP
      • Change payment_url to a repeated field and then reverse the order of the parameter numbers in the payment_url, compared to the bitcoin URL "r parameter".
      • Create an additional, new payment_url_multi repeated field (or some better name), and then leave the original payment_url field in there for backwards compatibility (and then maybe phase it out in the future).
    • Reference


Your comments and suggestions would be greatly appreciated.

-- Andy Schroder
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Wladimir | 15 Oct 10:47 2014
Picon

Proposed BIP status changes

These BIPs should go to Final state - they are implemented all over
the place, and are thus entirely fixed in place now. Any changes would
require a new BIP as amandment:

- BIP 14 (BIP Protocol Version and User Agent)

- BIP 21 (URI Scheme)

- BIP 22 (getblocktemplate - Fundamentals)

- BIP 31 (Pong Message)

- BIP 34 (Block v2, Height in coinbase)

- BIP 35 (mempool message)

- BIP 37 (Bloom filtering)

Let me know if you (don't) agree.

Wladimir

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Wladimir | 15 Oct 10:29 2014
Picon

BIP process

Hello,

I'm trying to create a bit of process around the
https://github.com/bitcoin/bips repository.

A) Currently a lot of pulls are open for various BIPs and it is not
clear who should comment on them, or who decides on changes to be
merged.

Currently all BIP changes have to go through the Bitcoin Core team,
which is a narrow bottleneck and makes little sense when you think
about it. But I don't want to go back to the wiki state in which
everyone can make arbitrary changes to any BIP - we need to distribute
the process somehow.

I'd like to propose to make the author (or someone they delegate to)
the primary contact for each BIP. They should comment on changes, and
either accept or reject them. If they accept them, the change will be
merged.

Of course this means that there is a responsibility for the author to
adhere to BIP 1. For example if your BIP is final, don't allow any
technical changes. To do small clarifications, spelling or adding
implementations or examples is OK, but changing or adding to a
protocol is not - this needs a new BIP. Changing your BIP status
without community consensus is also not OK.

B) I also think it makes sense to move the BIP discussion (both about
the BIP process and individual BIPs) to a separate mailing list.

bitcoin-development currently has a dual function: discussion of
Bitcoin Core implementation concerns, as well as global changes to
Bitcoin (in the form of BIPs).

This makes the list too busy for some people, but it is critical that
everyone writing a Bitcoin node or client is up-to-date with proposals
and can comment on them.

Wladimir

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Pieter Wuille | 14 Oct 04:34 2014
Picon

Malleable booleans

Hi all,

while working on a BIP62 implementation I discovered yet another type
of malleability: the interpretation of booleans.

Any byte array with non-zero bytes in it (ignoring the highest bit of
the last byte, which is the sign bit when interpreting as a number) is
interpreted as true, anything else as false. Other than numbers,
they're not even restricted to 4 bytes. Worse, the code for dealing
with booleans is not very consistent: OP_BOOLAND and OP_BOOLOR first
interpret their arguments as numbers, and then compare them to 0 to
turn them into boolean values.

This means that scripts that use booleans as inputs will be inherently
malleable. Given that that seems actually useful (passing in booleans
to guide some OP_IF's during execution of several alternatives), I
would like to change BIP62 to also state that interpreted booleans
must be of minimal encoded size (in addition to numbers).

Any opinions for or against?

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Daniel Murrell | 13 Oct 16:20 2014
Picon

OpenCryptocurrencyReview

Dear All

I'm not sure this is welcome here. Someone suggested I let the devs
know about it here. I've made an open forum on which to post
discussion about cryptocurrency related research:
www.opencryptocurrencyreview.com

Jeff helped me with the naming a bit some time ago. It's not had much
attention but then I've not advertised it much.

Please check it out and let me know if something like this is
worthwhile in this community. I'm not aware of much of the research
myself but a central repo of it seemed lacking and this adds
discussion capabilities to the repo.

If you guys have any potential use case for this, please consider
holding some of your discussions about research that interests you
here. If it gets core devs talking on it (if it's actually useful to
you that is), then I'm sure that others will be inspired to use it.
Even just one discussion thread will help if this regard.

It's not for profit so I'm not trying to make any money out of you.
It's just an experiment.

Kind regards
Daniel Murrell

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
Melvin Carvalho | 13 Oct 12:01 2014
Picon

Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)

FYI:

This is an issue I filed related to adding secp256k1 into Web Crypto API which will be implemented natively in (some) web browsers.

If there is any feedback from crypto implementers, please feel free to add comments to this thread: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444

---------- Forwarded message ----------
From: <bugzilla <at> jessica.w3.org>
Date: 13 October 2014 09:18
Subject: [Bug 24444] Named Curve Registry (adding secp256k1)
To: melvincarvalho <at> gmail.com


https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444

Myron Davis <myrond <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |myrond <at> gmail.com
         Resolution|NEEDSINFO                   |---

--- Comment #2 from Myron Davis <myrond <at> gmail.com> ---
Could this be looked at again?

Last response was waiting for feedback from crypto implementors.

Currently secp256k1 is supported in the following SSL/TLS libraries now
Botan
NSS
openssl
LibreSSL
PolarSSL
JSSE

The three other curves are all all have parameters which do not define how they
were generated.  secp256k1 curve has some great advantages in faster signature
verification and how the values were determined for the curve.  (i.e. not
random).

http://www.ietf.org/rfc/rfc4492

The curve has had a lot of eyes on it with lots of hardware and software
supporting this curve.

With discovery of backdoor's in NIST's random number generator
(https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I would
like to see a determined parameter curve instead of a "random" curve option.

Thanks

--
You are receiving this mail because:
You reported the bug.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Pieter Wuille | 12 Oct 01:34 2014
Picon

Request for review/testing: headers-first synchronization in Bitcoin Core

Hi all,

I believe that a large change that I've been working on for Bitcoin
Core is ready for review and testing: headers-first synchronization.
In short, it changes the way the best chain is discovered, downloaded
and verified, with several advantages:
* Parallel block downloading (much faster sync on typical network connections).
* No more stalled downloads.
* Much more robust against unresponsive or slow peers.
* Removes a class of DoS attacks related to peers feeding you
low-difficulty valid large blocks on a side branch.
* Reduces the need for checkpoints in the code.
* No orphan blocks stored in memory anymore (reducing memory usage during sync).
* A major step step towards an SPV mode using the reference codebase.

Historically, this mode of operation has been known for years (Greg
Maxwell wrote up a description of a very similar method in
https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
in early 2012, but it was known before that), but it took a long time
to refactor these code enough to support it.

Technically, it works by replacing the single-peer blocks download by
a single-peer headers download (which typically takes seconds/minutes)
and verification, and simultaneously fetching blocks along the best
known headers chain from all peers that are known to have the relevant
blocks. Downloading is constrained to a moving window to avoid
unbounded unordering of blocks on disk (which would interfere with
pruning later).

At the protocol level, it increases the minimally supported version
for peers to 31800 (corresponding to bitcoin v3.18, released in
december 2010), as earlier versions did not support the getheaders P2P
message.

So, the code is available as a github pull request
(https://github.com/bitcoin/bitcoin/pull/4468), or packaged on
http://bitcoin.sipa.be/builds/headersfirst, where you can also find
binaries to test with.

Known issues:
* At the very start of the sync, especially before all headers are
processed, downloading is very slow due to a limited number of blocks
that are requested per peer simultaneously. The policies around this
will need some experimentation can certainly be improved.
* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support. If you are fully
synced, it may still be possible to go back to an earlier version.

Unknown issues:
* Who knows, maybe it will replace your familiy pictures with Nyan
Cat? Use at your own risk.

TL;DR: Review/test https://github.com/bitcoin/bitcoin/pull/4468 or
http://bitcoin.sipa.be/builds/headersfirst.

--

-- 
Pieter

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
Naveen Garg | 11 Oct 21:49 2014
Picon

Distributed anonymous bitcoin client using your friendly government postal service

Make a transaction with two outputs.  Output A is your payee.  Output B is a fee to whoever transmits the
transaction to the network.  Sign and print the transaction, along with private key controlling address
of output B.  Put it in the mail with instructions to 1 or more greedy people who don't know you.   

Does namecoin allow mixing outputs for name registration with pay to hash outputs ?  If so, you could use
namecoin for anonymous publishing via post.  Or just make output A in bitcoin scripted with op_return if
its a 40byte tweet.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho

Gmane