Justus Ranvier | 25 Apr 04:34 2015
Picon

Re: Fwd: Reusable payment codes

On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell <gmaxwell <at> gmail.com> wrote:
On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
<justus.ranvier <at> monetas.net> wrote:
> Taking the hash of the secret would then require an extra step to make sure
> the hash is valid for secp256k1.

The x value may not be a valid member of the group, effectively the
same as with a hash. Its also very unequally distributed, as only
about half the possible values are points on the curve.

ack
 
> With 97 byte standard OP_RETURN values the ephemeral public
> key could be appended to the chain code, but that's undesirable for other reasons.

Can you elaborate?  Storing a ~33 byte (deterministically generated)
ephemeral key should be all that is required. Everything else,
including the chain code could be derived from it. What reason do you
have to include additional data?

The goal of the notification transaction is to send the same payment code to every recipient, but obscure the identity of the sender of the notification transaction from third party blockchain observers.

The shared secret is used for that purpose, and the sender's public key used for ECDH can't be one derived from the payment code since the recipient doesn't yet know the payment code.

The notification transaction needs to communicate the 65 byte payment code along with one ephemeral public key used for ECDH. If that ephemeral key is not located in a signature script, it has to be somewhere else (such as in the same OP_RETURN output as the payment code.)
 
> Taking the SHA512 of something less than 512 bits seemed wrong.

Why should it?  Adding the Y does not increase the entropy at all.  As
an aside, I think this can be reformulated to only need 256 bits of
output, and then the need for yet-another-hash-function could be
avoided in some cases.

Already fixed in https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 but it would be good to get confirmation of whether the way I fixed it is valid. 

> In this proposal I optimized for non-reliance on third party services

The requirement for inputs is a guaranteed dependency on third party
services; so if thats whats being optimized for here it must go (well,
I think it must go for the reason of avoiding blocking users from
using other schemes to control their coins too..).

I'm not sure what you mean by "the requirement for inputs is a guaranteed dependency on third party
services" 

At the proposal currently stands, an SPV wallet will have no trouble sending or receiving notification transactions without access to a third party service. The recipient just needs to see the transactions associated with its notification address.

The point about restricting the types of scripts used as inputs is valid, but I think workarounds are available. If nothing else, the sender can make a suitable input using it's own (suitably mixed) coins first.

> I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes.

A prior stealth address proposal here handled them fine with only a
single ephemeral point in the op_return. It does result in a longer
address (is that what you're referring to with '80 bytes'?)

I considered defining an additional path level for deterministic m-of-n multisig and adding a few bytes to the payment code to express those parameters, but thought it would be too limiting since it would preclude multisig with truly independent keys. It is a thing that could be done, however.

> Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer.
> In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations.

But this mandates horrible key management practices, reliance on a
single "hardcoded" private key which you cannot change; even if it
might be compromised or lost to the wind. It's less horrible than
sticking to a single address because it doesn't wedge privacy, I
agree; but care should be taken that a tortured dance for confused
regulatory cargo-cult reasons doesn't mandate people not engage in
sound practices like periodic key rotation. :)

Cold storage is still available (if admittedly less convenient than in traditional wallets).

I would expect exchanges in practice to allow for payment codes to be changed, just with non-trivial waiting periods and plenty of human overview. It would be an infrequent event compared to the frequency of withdrawals.

Various schemes which use public key authentication instead of passwords for web site authentication could be used to continually verify that the user hasn't lost access to the key.
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Justus Ranvier | 25 Apr 02:22 2015
Picon

Fwd: Reusable payment codes

Taking the hash of the secret would then require an extra step to make sure the hash is valid for secp256k1.

Using the x value directly avoids the need for that check.

On Fri, Apr 24, 2015 at 10:35 PM, Patrick Mccorry (PGR) <patrick.mccorry <at> newcastle.ac.uk> wrote:
When computing the diffie Hellman secret - why do you choose the x co-ordinate instead of the hash of the secret which is standard practice for stealth addresses 

Sent from my iPhone

On 24 Apr 2015, at 21:27, Justus Ranvier <justus.ranvier <at> monetas.net> wrote:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1


https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki


This link contains an RFC for a new type of Bitcoin address called a "payment code"


Payment codes are SPV-friendly alternatives to DarkWallet-style stealth addresses which provide useful features such as positively identifying senders to recipients and automatically providing for transaction refunds.


Payment codes can be publicly advertised and associated with a real-life identity without causing a loss of financial privacy.


Compared to stealth addresses, payment codes require less blockchain data storage.


Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair, while stealth addresses require 40 bytes per transaction.


-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1


iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd

JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa

Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz

QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG

NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR

o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo

2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h

/wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9

EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET

n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI

OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+

SGApMBd4Q89fKzL2djae

=Dypr

-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Justus Ranvier | 25 Apr 02:21 2015
Picon

Fwd: Reusable payment codes

I have pushed an updated version of the proposal which incorporates some of the received feedback and adds a note about the consequences of sharing a payment code-enabled walled on multiple devices:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki


On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <justus.ranvier <at> monetas.net> wrote:


On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell <at> gmail.com> wrote:
So this requires making dust payments to a constantly reused address
in order to (ab)use the blockchain as a messaging layer.

Indeed, this is more SPV compatible; but it seems likely to me that
_in practice_ it would almost completely undermine the privacy the
idea hoped to provide; because you'd have an observable linkage to a
highly reused address.

I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee.
 

It would also more than double the data sent for the application where
'stealth addresses' are most important: one-time anonymous donations
(in other contexts; you have two way communication between the
participants, and so you can just given them a one off address without
singling in the public network.)

Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses.

As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses.

This kind of binding was intentionally designed out of the stealth
address proposal;  I think this scheme can be made to work without any
increase in size by reusing the payment code as the ephemeral public
key (or actually being substantially smaller e.g. use the shared
secret as the chain code, but I should give it more thought)

With 97 byte standard OP_RETURN values the ephemeral public
key could be appended to the chain code, but that's undesirable for other reasons.

This is fundamentally more expensive to compute; please don't specify
"uncompressed".

Taking the SHA512 of something less than 512 bits seemed wrong.
 
This appears incompatible with multisignature; which is unfortunate.

I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes.
 
I'm disappointed that there isn't any thought given to solving the
scanning privacy without forcing non-private pure-overhead messaging
transactions on heavily reused addresses. Are you aware of the IBE
approach that allows someone to request a third party scan for them
with block by block control over their delegation of scanning?

I suspect this is a case where we just can't have all the features we want.

In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup.

Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile.

In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity.

Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address).

In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations.



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Justus Ranvier | 25 Apr 02:20 2015
Picon

Fwd: Reusable payment codes

On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell <at> gmail.com> wrote:
So this requires making dust payments to a constantly reused address
in order to (ab)use the blockchain as a messaging layer.

Indeed, this is more SPV compatible; but it seems likely to me that
_in practice_ it would almost completely undermine the privacy the
idea hoped to provide; because you'd have an observable linkage to a
highly reused address.

I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee.
 

It would also more than double the data sent for the application where
'stealth addresses' are most important: one-time anonymous donations
(in other contexts; you have two way communication between the
participants, and so you can just given them a one off address without
singling in the public network.)

Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses.

As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses.

This kind of binding was intentionally designed out of the stealth
address proposal;  I think this scheme can be made to work without any
increase in size by reusing the payment code as the ephemeral public
key (or actually being substantially smaller e.g. use the shared
secret as the chain code, but I should give it more thought)

With 97 byte standard OP_RETURN values the ephemeral public
key could be appended to the chain code, but that's undesirable for other reasons.

This is fundamentally more expensive to compute; please don't specify
"uncompressed".

Taking the SHA512 of something less than 512 bits seemed wrong.
 
This appears incompatible with multisignature; which is unfortunate.

I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes.
 
I'm disappointed that there isn't any thought given to solving the
scanning privacy without forcing non-private pure-overhead messaging
transactions on heavily reused addresses. Are you aware of the IBE
approach that allows someone to request a third party scan for them
with block by block control over their delegation of scanning?

I suspect this is a case where we just can't have all the features we want.

In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup.

Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile.

In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity.

Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address).

In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations.


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Justus Ranvier | 24 Apr 22:00 2015
Picon

Reusable payment codes

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1


https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki


This link contains an RFC for a new type of Bitcoin address called a "payment code"


Payment codes are SPV-friendly alternatives to DarkWallet-style stealth addresses which provide useful features such as positively identifying senders to recipients and automatically providing for transaction refunds.


Payment codes can be publicly advertised and associated with a real-life identity without causing a loss of financial privacy.


Compared to stealth addresses, payment codes require less blockchain data storage.


Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair, while stealth addresses require 40 bytes per transaction.


-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1


iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd

JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa

Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz

QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG

NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR

o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo

2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h

/wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9

EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET

n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI

OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+

SGApMBd4Q89fKzL2djae

=Dypr

-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Kalle Rosenbaum | 23 Apr 16:39 2015

Re: Proof of Payment

Hi Martin,

Thank you very much for your comments. See my answers inline:

Den 23 apr 2015 03:28 skrev "Martin Lie" <martin <at> datamagi.no>:
>
> Hej, Kalle.
>
> I love the idea of standardised PoPs, including a protocol for requesting/sending them as an extension of BIP-70.
>

Me too!

>
> A couple of comments:
>
> 1. You admit that the txid is just a convenience and not strictly necessary. Perhaps this should be reflected in the sequence of bits/bytes in the record you're proposing, e.g. "OP_RETURN POP_LITERAL <nonce> <txid>"?
>

I was thinking that txid should be mandatory just as the nonce so the order was arbitrarily chosen. I think you may be right that it's more intuitive to put txid last if it's not mandatory in a future version. It makes sense to swap order. I'll put that on my todo list.

> 2. Building on #1, perhaps there could be other identifying information than a txid? Perhaps a txid field shouldn't be "hardcoded" into the standard at all?
>
> How about taking the same approach as BIP-43 (and others) and use a prefix that determines how the rest of the records should be interpreted, i.e. a "type" (or "purpose" or "version" or whatever you'd like to call it) field. This would allow for different purposes/versions of a PoP, including as of now unforeseen ones.
>
> The new structure would then be:
> OP_RETURN POP_PREFIX POP_TYPE POP_NONCE POP_PAYLOAD
>
> POP_PREFIX (? bytes): I'll leave it up to you to specify the exact bits (and length) of the POP_PREFIX, but if your literal is used, it'd be 3 bytes: 0x506f50.
>
> Literals in Bitcoin protocols generally seem to be of the "binary" sort as opposed to human-readable text, so perhaps the devs wouldn't ACK something as "wasteful" as using 3 bytes just to identify it as a PoP record? Obviously, this is a small detail that can be changed at short notice, but as with all standards - once people start using it, you're mostly stuck with what you have. ;)
>

Yes, maybe we could drop POP_PREFIX altogether. The server is expecting a pop and can therefore just assume it's a pop. No need to explicitly write that inside the pop. Can you think of a scenario where it is actually needed. Keeping the POP_PREFIX makes sense only if other transaction-like data structures with OP_RETURN appears in the same contexts as pops. What do you think?

> POP_TYPE: (1 byte): 0x01 for your "standard" version, which would mean that the payload contains a txid.
>

This is a good idea. Todo!

> POP_NONCE: (4 bytes): "2^32 re-uses should be enough for everyone", no? ;)
>

Euhm, well, I don't know... The bigger the better. If we drop POP_PREFIX we could allow for 2 bytes version and 6 bytes nonce. Or 1 byte version and 7 bytes nonce.

> POP_PAYLOAD (32+ bytes): The contents of which is determined by POP_TYPE, e.g. a txid or possibly extra nonce data. Or perhaps some text that makes the purpose or context of this PoP human-readable? (This could then be stored by wallets in order to show a list of what kind of proofs you've sent.)
>

For now I think I'll stick to "txid is mandatory".

>
> 3. I noticed that your post-OP_RETURN structure included exactly 40 bytes. Is that due to the 40-byte limitation on OP_RETURN's "data"? Are you aware that it will be increased to 80 bytes? Cf. https://github.com/bitcoin/bitcoin/pull/5286
>

Yes, I deliberately limited the data to 40 bytes for that reason. With versioning, this may change in the future.

> :)
>
>
> Vennlig hilsen
> Martin Lie

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Wladimir J. van der Laan | 21 Apr 09:22 2015
Picon

Bitcoin Core 0.10.1 release candidate 3 available


I've just uploaded Bitcoin Core 0.10.1rc3 executables to:

https://bitcoin.org/bin/bitcoin-core-0.10.1/test/

The source code can be found in git under the tag 'v0.10.1rc3' on the `0.10` branch.

New in this RC is another batch of bug fixes,

- `eae305f` Fix missing lock in submitblock
- `57d1f46` Fix CheckBlockIndex for reindex
- `bac6fca` Set nSequenceId when a block is fully linked
- `139cd81` Cap nAttempts penalty at 8 and switch to pow instead of a division loop
- `323de27` `7494e09` `df45564` Various initialization setup environment locale fixes

Full (preliminary) release notes for 0.10.1 can be found at
https://github.com/bitcoin/bitcoin/blob/v0.10.1rc3/doc/release-notes.md 

Thanks to everyone that participated in development or in the gitian build process. I sincerely hope that
this can be the final release candidate for 0.10.1,

Wladimir

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
gabe appleton | 16 Apr 04:14 2015
Picon

Where do I start?

Background: I'm a CS student quickly approaching his research project, and I'd like to do something meaningful with it.

Essentially, I'd like to know what issues someone up for their bachelor's degree might actually be able to help on, and where I can start. Obviously I'm not going to be able to just dive into a 6-year-running project without some prior research, so I'm looking for a start.

What are some current things that are lacking in Bitcoin core? Or am I better off making something else for the ecosystem?

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
s7r | 16 Apr 01:43 2015

75%/95% threshold for transaction versions

Hi,

Would it be wise to add a consensus rule like the one we have for blocks,

(if > 75% from last 1000 blocks are version 'n' mark version 'n' as
standard for blocks and if > 95% from the last 1000 blocks are version
'n' mark previous block versions as invalid)

but for transaction versions? In simple terms, if > 75% from all the
transactions in the latest 1000 blocks are version 'n', mark all
previous transaction versions as non-standard and if > 95% from all the
transactions in the latest 1000 blocks are version 'n' mark all previous
transaction versions as invalid.

At this moment, the standard in consensus is v1, but nothing is enforced
in the network related to transaction versions.

Regarding BIP62, as it can be read here [0] it is said that it requires
v2 transactions. It is also said that transaction version 2 will be
skipped and jump directly to v3, for an even version for transactions
and blocks (?). Might as well add the rule for invalidating previous
transaction versions if the majority updates - could this break anything
or affect functionality in any way?

BIP62 adds a newer transaction version which is optional and does not
mark previous v1 as non-standard or invalid. This means bitcoin core
will treat both v1 and v2/v3 transactions as standard and relay/mine
them with the same priority, regardless of the tx version?

Thanks.

[0]
https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
Pieter Wuille | 12 Apr 16:26 2015
Picon

Deprecating Bitcoin Core's regtest-specific `setgenerate` behaviour

Hello everyone,

Bitcoin Core's `setgenerate` RPC call has had a special meaning for -regtest (namely instantaneously mining a number of blocks, instead of starting a background CPU miner).

We're planning to deprecate that overloaded behaviour, and replace it with a separate RPC call `generate`. Is there any software or user who would need compatibility with the old behaviour? We're generally very conservative in changing RPC behaviour, but as this is not related to any production functionality, we may as well just switch it.

Note that the bitcoin.org developer documentation will need to be updated.

--
Pieter

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Wladimir J. van der Laan | 10 Apr 10:46 2015
Picon

Bitcoin Core 0.10.1 release candidate 2 available

Hello,

I've just uploaded Bitcoin Core 0.10.1rc2 executables to:

https://bitcoin.org/bin/bitcoin-core-0.10.1/test/

The source code can be found in git under the tag 'v0.10.1rc2'

The only change in comparison to rc1 is a fix by Gavin Andresen:

- `1c62e84` Keep mempool consistent during block-reorgs

Thanks to everyone that participated in the gitian build process,

Wladimir

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

Gmane