[Bitcoin-development] Testnet3 difficulty transition problem?

2012-12-22 Thread Andreas Schildbach
Both blocks

38304 015bb4069249fa1f41ae61d8a7447aaacc33c50dacd3c3654377fa43

and

40320 8011f56b8c92ff27fb502df5723171c5374673670ef0eee3696aee6d

are difficulty transition blocks. However, block 40320 has a difficulty
of 1. I know there is this special testnet rule that allows mining a
block at difficulty 1, but I always thought you can't use this exception
on difficulty transition blocks.

As a result, bitcoinj based clients do not advance their blockchain past
block 40319.


--
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

2012-12-22 Thread Mark Friedenbach
I hope that this input does not come too late; I haven't had time to review
the proposal until now.

For alt-chains that have time-varying value (Freicoin[1], currently), it is
necessary in some applications to include a reference height in the
invoice. Since the bitcoin protocol does not assume a universally
agreed-upon time source, Freicoin (and presumably other
yet-to-be-implemented time-varying chains) uses blocktime as the clock for
time-value calculations: outputs lose 2**-20 of their value with each
passing block. The reference height for an invoice is the blocktime at
which amount values are specified and the reference point for time-varying
calculations. As a concrete example, an invoice for payment of 50 frc today
could be satisfied by 49.99313402 frc tomorrow.

To implement this, we would require an optional uint64 refheight field in
the invoice structure. refheight or nRefHeight is what we call this
value internally, but blocktime or blockheight would work as well.

Github is currently down, so I apologize if a suitable field has already
been added.

Cheers,
Mark Friedenbach

[1] http://freico.in/ Freicoin: a P2P digital currency delivering freedom
from usury.


On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen gavinandre...@gmail.comwrote:

 This is the next big lets all agree to do things the same way thing
 I think we should tackle. I'm particularly looking for feedback from
 other bitcoin client developers, even if it is just a quick looks
 reasonable, if everybody else is going to do it then I will
 (eventually) too...

 Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
 suggestions and brainstorming.

 This document is online at https://gist.github.com/4120476

 If you respond to this message, please be considerate of people who
 subscribe to the digest version of this mailing list and trim your
 response.


 Invoices, Payments and Receipts for Bitcoin Transactions
 

 This document proposes protocol buffer-based formats for signed,
 authenticated invoices and receipts -- requests for payment, and
 proof-of-payment.

 Separate documents propose an extension to the Bitcoin URI syntax and
 new MIME types to support them.

 Motivation
 ==

 The idea of a payment protocol to improve on Bitcoin addresses has
 been around for over a year. Users have been asking for some features
 in this proposal (like the ability to provide a refund address so
 overpayments or refunds can be returned to customers without the need
 to ask them for their address) for two or three years, and have
 started to work around shortcomings in the Bitcoin payment process
 with creative (but inefficient) uses of transactions.

 The key features of this proposal are:

 + Requests for payment (Invoices) are tied to authenticated identities
 using the only widely-deployed identity authentication system we have
 right now (X.509 certificates signed by root certificate authorities)
 + Invoices include a user-friendly description of what the payment is for
 + Payments include where refunds should be sent
 + At the end of the payment process, the customer holds a
 cryptographically signed Receipt that can be used as proof-of-payment
 if there is any dispute with the merchant.


 Specification
 =

 Invoice/SignedInvoice
 -

 An Invoice is a request for payment from a merchant to a customer:

 ::

 message Output {
 optional uint64 amount = 1;
 required bytes script = 2;
 }

 amount: Number of satoshis (0.0001 BTC) to be paid. If not given
 or zero, then the customer will be asked how much to pay.

 script: a TxOut script to which the customer should direct payment.
 This will normally be one of the standard Bitcoin transaction script
 (e.g. pubkey OP_CHECKSIG).

 ::

 message Invoice {
 repeated bytes x509chain = 1;
 repeated Output outputs = 2;
 required uint64 time = 3;
 optional uint64 expires = 4;
 optional bool single_use = 5 [default = true];
 optional string memo = 6;
 optional string receiptURI = 7;
 optional bytes merchant_data = 8;
 }

 outputs: one or more outputs where Bitcoins are to be sent.

 x509chain: one or more DER-encoded X.509 certificates that identifies
 the merchant. See the Certificates section below for details.

 time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was
 created.

 expires: Unix timestamp after which the Invoice should be considered
 invalid. If not given, the Invoice may be re-used until the earliest
 certificate expiration date in the X509chain.

 single_use: If true, this Invoice should be used for only one payment.
 If false, it may be added to the user's address book and used
 repeatedly until it expires (e.g. for donations or a recurring
 payment).

 memo: UTF-8 encoded, plain-text (no formatting) note that should be
 displayed to the customer, explaining what this