Discussion:
OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"
(too old to reply)
Chris Priest via bitcoin-dev
2015-11-24 17:34:35 UTC
Permalink
Here is the problem I'm trying to solve with this idea:

Lets say you create an address, publish the address on your blog, and
tell all your readers to donate $0.05 to that address if they like
your blog. Lets assume you receive 10,000 donations this way. This all
adds up to $500. The problem is that because of the way the bitcoin
payment protocol works, a large chunk of that money will go to fees.
If one person sent you a single donation of $500, you would be able to
spend most of the $500, but since you got this coin by many smaller
UTXO's, your wallet has to use a higher tx fee when spending this
coin.

The technical reason for this is that you have to explicitly list each
UTXO individually when making bitcoin transactions. There is no way to
say "all the utxos". This post describes a way to achieve this. I'm
not yet a bitcoin master, so there are parts of this proposal that I
have not yet figured out entirely, but I'm sure other people who know
more could help out.

**OP_CHECKWILDCARDSIGVERIFY**

First, I propose a new opcode. This opcode works exactly the same as
OP_CHECKSIGVERIFY, except it only evaluates true if the signature is a
"wildcard signature". What is a wildcard signature you ask? This is
the part that I have not yet 100% figured out yet. It is basically a
signature that was created in such a way that expresses the private
key owners intent to make this input a *wildcard input*

** wildcard inputs **

A wildcard input is defined as a input to a transaction that has been
signed with OP_CHECKWILDCARDSIGVERIFY. The difference between a
wildcard input and a regular input is that the regular input respects
the "value" or "amount" field, while the wildcard input ignores that
value, and instead uses the value of *all inputs* with a matching
locking script.

** coalescing transaction"

A bitcoin transaction that
Gavin Andresen via bitcoin-dev
2015-11-24 20:32:37 UTC
Permalink
On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
The technical reason for this is that you have to explicitly list each
UTXO individually when making bitcoin transactions. There is no way to
say "all the utxos". This post describes a way to achieve this. I'm
not yet a bitcoin master, so there are parts of this proposal that I
have not yet figured out entirely, but I'm sure other people who know
more could help out.
So every input has:
32-byte hash (transaction being spent)
4-byte output (output being spent)
4-byte sequence number
... plus the scriptSig. Which is as small as about 73 bytes if you're
spending a raw OP_CHECKSIG (which you can't do as a bitcoin address, but
could via the BIP70 payment protocol), and which is at least two serialized
bytes.

Best case for any scheme to coalesce scriptSigs would to somehow make
all-but-the-first scriptSig zero-length, so the inputs would be 42 bytes
instead of 40+73 bytes -- the coalesce transaction would be about one-third
the size, so instead of paying (say) $1 in transaction fees you'd pay 37
cents.

That's in the gray are of the "worth doing" threshold-- if it was a 10x
improvement (pay 10 cents instead of $1) it'd be in my personal "definitely
worth the trouble of doing" category.

RE: the scheme: an OP_RINGSIGVERIFY is probably the right way to do this:
https://en.wikipedia.org/wiki/Ring_signature

The funding transactions would be: <public key> OP_RINGSIGVERIFY
... which might could be redeemed with <ring signature> for one input and
then... uhh... maybe just <index_to_input_with_signature> for the other
inputs that are part of the same ring signature group (OP_0 if the first
input has the signature that is good for all the other public keys, which
would be the common case).
--
--
Gavin Andresen
Chris Priest via bitcoin-dev
2015-11-24 21:01:26 UTC
Permalink
A coalescing transaction in my scheme is the same size as a normal
transaction. You only include one UTXO, the rest are implied based on
the presence of the OP_CHECKWILDCARDSIGVERIFY opcode.

The code that determines if a UTXO is spent or not will need to be
modified to include a check to see if any matching coalescing
transactions exist in any later block. Maybe there should be a
"coalescing pool" containing all coalescing transactions that make
such a check faster.

The part I'm not too sure about is the "wildcard signature". I'm not
too versed in cryptography to know how exactly to pull this off, but I
think it should be simple.
You'd just have to some way inject a flag into the signing process
that can be verified later.

I originally wanted the "wildcardness" of the transaction expressed by
the transaction version number.
Basically any input that exists within a "version 2 transaction" is
viewed as a wildcard input. Then I realized whats to stop someone from
modifying the transaction from version 1 to version 2 and stealing
someones funds. The "wildcardness" must be expressed in the signature
so you know that the private key holder intended all inputs to be
included. Hence the need for a new opcode.

btw, this scheme is definitely in the 10x or higher gain. You could
potentially spend an unlimited number of UTXOs this way.
Post by Gavin Andresen via bitcoin-dev
On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
The technical reason for this is that you have to explicitly list each
UTXO individually when making bitcoin transactions. There is no way to
say "all the utxos". This post describes a way to achieve this. I'm
not yet a bitcoin master, so there are parts of this proposal that I
have not yet figured out entirely, but I'm sure other people who know
more could help out.
32-byte hash (transaction being spent)
4-byte output (output being spent)
4-byte sequence number
... plus the scriptSig. Which is as small as about 73 bytes if you're
spending a raw OP_CHECKSIG (which you can't do as a bitcoin address, but
could via the BIP70 payment protocol), and which is at least two serialized
bytes.
Best case for any scheme to coalesce scriptSigs would to somehow make
all-but-the-first scriptSig zero-length, so the inputs would be 42 bytes
instead of 40+73 bytes -- the coalesce transaction would be about one-third
the size, so instead of paying (say) $1 in transaction fees you'd pay 37
cents.
That's in the gray are of the "worth doing" threshold-- if it was a 10x
improvement (pay 10 cents instead of $1) it'd be in my personal "definitely
worth the trouble of doing" category.
https://en.wikipedia.org/wiki/Ring_signature
The funding transactions would be: <public key> OP_RINGSIGVERIFY
... which might could be redeemed with <ring signature> for one input and
then... uhh... maybe just <index_to_input_with_signature> for the other
inputs that are part of the same ring signature group (OP_0 if the first
input has the signature that is good for all the other public keys, which
would be the common case).
--
--
Gavin Andresen
Bryan Bishop via bitcoin-dev
2015-11-24 21:51:12 UTC
Permalink
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
near near "09:50" (apologies for having no anchor links):
http://gnusha.org/bitcoin-wizards/2015-11-24.log

- Bryan
http://heybryan.org/
1 512 203 0507
Dave Scotese via bitcoin-dev
2015-11-24 23:28:33 UTC
Permalink
What is required to spend bitcoin is that input be provided to the UTXO
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a requirement
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.

This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and be
a signature of some kind of message to that effect. I imagine the cost of
re-scanning the UTXO set to find them all would justify a special extra
mining fee for any transaction that used this opcode.

Please be blunt about any of my own misunderstandings that this email makes
clear.

On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
Chris Priest via bitcoin-dev
2015-11-24 23:48:16 UTC
Permalink
Post by Dave Scotese via bitcoin-dev
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and be
a signature of some kind of message to that effect.
I think this is true. Not *all* transactions will be able to match the
wildcard. For instance if someone sent some crazy smart contract tx to
your address, the script associated with that tx will be such that it
will not apply to the wildcard. Most "vanilla" utxos that I've seen
have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
apply to the wildcard.

On 11/24/15, Dave Scotese via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
What is required to spend bitcoin is that input be provided to the UTXO
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a requirement
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and be
a signature of some kind of message to that effect. I imagine the cost of
re-scanning the UTXO set to find them all would justify a special extra
mining fee for any transaction that used this opcode.
Please be blunt about any of my own misunderstandings that this email makes
clear.
On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
Jannes Faber via bitcoin-dev
2015-11-25 00:38:02 UTC
Permalink
Few issues I can think of:

1. In its basic form this encourages address reuse. Unless the wildcard can
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making HD moot
to begin with.

2. Sounds pretty dangerous during reorgs. Maybe such a transaction should
include a block height which indicates the maximum block that any utxo can
match. With the requirement that the specified block height is at least 100
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must be
in that minimum block).

3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect.
I think this is true. Not *all* transactions will be able to match the
wildcard. For instance if someone sent some crazy smart contract tx to
your address, the script associated with that tx will be such that it
will not apply to the wildcard. Most "vanilla" utxos that I've seen
have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
apply to the wildcard.
On 11/24/15, Dave Scotese via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
What is required to spend bitcoin is that input be provided to the UTXO
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a requirement
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect. I imagine the cost
of
Post by Dave Scotese via bitcoin-dev
re-scanning the UTXO set to find them all would justify a special extra
mining fee for any transaction that used this opcode.
Please be blunt about any of my own misunderstandings that this email
makes
Post by Dave Scotese via bitcoin-dev
clear.
On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
which
Post by Dave Scotese via bitcoin-dev
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Chris Priest via bitcoin-dev
2015-11-25 01:26:51 UTC
Permalink
1. Technically is it promoting address reuse, but in this case, I
think it's OK. The primary purpose of a coalescing transaction is to
clear out *all* funds associated with one address and send them to
another address (belonging to the same owner). If you coalesce the
inputs to the same address over and over again, you an do that, but
you'll run the risk of leaking your private key.

2. I see these transactions being broadcast in the background when the
user is not planning on sending or receiving any payments. By the time
the wallet user wants to spend funds from the address, the coalescing
transaction should be sufficiently deep enough in the blockchain to
avoid re-org tomfoolery. Exchanges and payment processors who take in
payments around the clock will probably never use these transactions,
at least not on "live" addresses.

3. I never thought of that, but thats a benefit too!

On 11/24/15, Jannes Faber via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
1. In its basic form this encourages address reuse. Unless the wildcard can
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making HD moot
to begin with.
2. Sounds pretty dangerous during reorgs. Maybe such a transaction should
include a block height which indicates the maximum block that any utxo can
match. With the requirement that the specified block height is at least 100
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must be
in that minimum block).
3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect.
I think this is true. Not *all* transactions will be able to match the
wildcard. For instance if someone sent some crazy smart contract tx to
your address, the script associated with that tx will be such that it
will not apply to the wildcard. Most "vanilla" utxos that I've seen
have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
apply to the wildcard.
On 11/24/15, Dave Scotese via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
What is required to spend bitcoin is that input be provided to the UTXO
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a requirement
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect. I imagine the cost
of
Post by Dave Scotese via bitcoin-dev
re-scanning the UTXO set to find them all would justify a special extra
mining fee for any transaction that used this opcode.
Please be blunt about any of my own misunderstandings that this email
makes
Post by Dave Scotese via bitcoin-dev
clear.
On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
which
Post by Dave Scotese via bitcoin-dev
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik via bitcoin-dev
2015-11-25 14:16:14 UTC
Permalink
Nice idea. I see it as an important feature because of several reasons:

Considering the website example, where most websites uses static
content, a bitcoin address could accumulate a dozen of transactions
before the webmaster changes the address to a new one.

Also consider a QR-code address printed on paper. That address is also
prone to multiple payments, which could be several small ones.

You ask someone to pay an amount of BTC. That person would be someone
that want you to actually don't get any money at all, so instead of
sending one payment, the person sends a lot of small TXes. It costs a
lot more to achieve this, but that doesn't bother the person sending the
transactions. What you see is the transactions to the address you've
agreed sum up to the amount you asked for. When you later try to spend
it, you can't because of that the size of all UXTOs is too high to even
overcome the tx fee.

If you use a wildcard transaction to bake them together into one UXTO,
you will not need to pay more than just one tx fee to solve the problem
you've got. Also the network will benefit from this because the
alternative is to not spend those UXTOs at all because it costs more
than it earns, leaving lots of UXTOs in the databases.

Some problems to consider is:
* Which addresses should be involved in a wildcard TX.
* How to not make it repeatable or delayed so that UXTOs not intended to
be in that TX wouldn't be included.
* How to make it impossible to sign an wildcard TX with a future date.
* How to limit outputs so they not are in risk being double-spent.
* How to guarantee that the output is actually calculated from all the
inputs involved and not less, making insane TX fees available.

I could see possible solutions to this problems:
* Using the highest block height number of transactions to include or
maybe better, the UXTO of one transaction destined to that address
involved in that block - that implies collecting all UXTOs in that block.
* Using a signature that includes the date. To let it be present more
times in the blockchain requires another timestamp that is newer than a
wildcard TX already existing in the blockchain. Also make the
transaction invalid to put in a block if the timestamp is behind a
certain time or in the future.
* Using the coinbase UXTO or the block hash from the latest block as
proof that the transaction isn't created earlier than that. Also makes
the wildcard TX invalid if that block isn't part of the blockchain
anymore. This also have a secondary effect of certifying the blockchain
itself making it more difficult to fork it from far behind because it
will effectively remove all transactions depending on a UXTO including
this type of certification.
* Either using a priority like way to determine what are being left to
wildcard in a block - all transactions spending UXTOs of that address is
removed before the wildcard TX if they occurs in the same block. Either
it is possible to set a rule that if a wildcard TX exists in one block,
it is invalid to include other UXTOs that is to be be included in the
wildcard from the same address in the same block. (Classic
double-spending rule)
* Using a special form of output specifying only one destination
address/script and the amount of fees to pay. If the amount of fees
could be payed, then the rest will be sent to the destination address.
This covers intentional delaying and also discourage forking the
blockchain by miners to making the signature UXTO appear later than more
recent transaction in a new fork to collect the later txes as fee.

This transaction type would in fact look like a time-limited offer to
the network to reduce the UXTO set of an address. I guess some miners
will then use a logic that prefers this types of TXes even if they are
low-fee because, if they removes lots of UXTOs, they benefits the network.

Sincerely,
Erik.
Post by Chris Priest via bitcoin-dev
1. Technically is it promoting address reuse, but in this case, I
think it's OK. The primary purpose of a coalescing transaction is to
clear out *all* funds associated with one address and send them to
another address (belonging to the same owner). If you coalesce the
inputs to the same address over and over again, you an do that, but
you'll run the risk of leaking your private key.
2. I see these transactions being broadcast in the background when the
user is not planning on sending or receiving any payments. By the time
the wallet user wants to spend funds from the address, the coalescing
transaction should be sufficiently deep enough in the blockchain to
avoid re-org tomfoolery. Exchanges and payment processors who take in
payments around the clock will probably never use these transactions,
at least not on "live" addresses.
3. I never thought of that, but thats a benefit too!
On 11/24/15, Jannes Faber via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
1. In its basic form this encourages address reuse. Unless the wildcard can
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making HD moot
to begin with.
2. Sounds pretty dangerous during reorgs. Maybe such a transaction should
include a block height which indicates the maximum block that any utxo can
match. With the requirement that the specified block height is at least 100
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must be
in that minimum block).
3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect.
I think this is true. Not *all* transactions will be able to match the
wildcard. For instance if someone sent some crazy smart contract tx to
your address, the script associated with that tx will be such that it
will not apply to the wildcard. Most "vanilla" utxos that I've seen
have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
apply to the wildcard.
On 11/24/15, Dave Scotese via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
What is required to spend bitcoin is that input be provided to the UTXO
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a requirement
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address, and
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect. I imagine the cost
of
Post by Dave Scotese via bitcoin-dev
re-scanning the UTXO set to find them all would justify a special extra
mining fee for any transaction that used this opcode.
Please be blunt about any of my own misunderstandings that this email
makes
Post by Dave Scotese via bitcoin-dev
clear.
On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
which
Post by Dave Scotese via bitcoin-dev
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Trevin Hofmann via bitcoin-dev
2015-11-25 15:41:01 UTC
Permalink
Post by Erik via bitcoin-dev
Considering the website example, where most websites uses static
content, a bitcoin address could accumulate a dozen of transactions
before the webmaster changes the address to a new one.

Would this use case be a better match for something such as stealth
addresses or hierarchical deterministic addresses?

Trevin Hofmann
On Nov 25, 2015 8:16 AM, "Erik via bitcoin-dev" <
Post by Erik via bitcoin-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Considering the website example, where most websites uses static
content, a bitcoin address could accumulate a dozen of transactions
before the webmaster changes the address to a new one.
Also consider a QR-code address printed on paper. That address is also
prone to multiple payments, which could be several small ones.
You ask someone to pay an amount of BTC. That person would be someone
that want you to actually don't get any money at all, so instead of
sending one payment, the person sends a lot of small TXes. It costs a
lot more to achieve this, but that doesn't bother the person sending the
transactions. What you see is the transactions to the address you've
agreed sum up to the amount you asked for. When you later try to spend
it, you can't because of that the size of all UXTOs is too high to even
overcome the tx fee.
If you use a wildcard transaction to bake them together into one UXTO,
you will not need to pay more than just one tx fee to solve the problem
you've got. Also the network will benefit from this because the
alternative is to not spend those UXTOs at all because it costs more
than it earns, leaving lots of UXTOs in the databases.
* Which addresses should be involved in a wildcard TX.
* How to not make it repeatable or delayed so that UXTOs not intended to
be in that TX wouldn't be included.
* How to make it impossible to sign an wildcard TX with a future date.
* How to limit outputs so they not are in risk being double-spent.
* How to guarantee that the output is actually calculated from all the
inputs involved and not less, making insane TX fees available.
* Using the highest block height number of transactions to include or
maybe better, the UXTO of one transaction destined to that address
involved in that block - that implies collecting all UXTOs in that block.
* Using a signature that includes the date. To let it be present more
times in the blockchain requires another timestamp that is newer than a
wildcard TX already existing in the blockchain. Also make the
transaction invalid to put in a block if the timestamp is behind a
certain time or in the future.
* Using the coinbase UXTO or the block hash from the latest block as
proof that the transaction isn't created earlier than that. Also makes
the wildcard TX invalid if that block isn't part of the blockchain
anymore. This also have a secondary effect of certifying the blockchain
itself making it more difficult to fork it from far behind because it
will effectively remove all transactions depending on a UXTO including
this type of certification.
* Either using a priority like way to determine what are being left to
wildcard in a block - all transactions spending UXTOs of that address is
removed before the wildcard TX if they occurs in the same block. Either
it is possible to set a rule that if a wildcard TX exists in one block,
it is invalid to include other UXTOs that is to be be included in the
wildcard from the same address in the same block. (Classic
double-spending rule)
* Using a special form of output specifying only one destination
address/script and the amount of fees to pay. If the amount of fees
could be payed, then the rest will be sent to the destination address.
This covers intentional delaying and also discourage forking the
blockchain by miners to making the signature UXTO appear later than more
recent transaction in a new fork to collect the later txes as fee.
This transaction type would in fact look like a time-limited offer to
the network to reduce the UXTO set of an address. I guess some miners
will then use a logic that prefers this types of TXes even if they are
low-fee because, if they removes lots of UXTOs, they benefits the network.
Sincerely,
Erik.
Post by Chris Priest via bitcoin-dev
1. Technically is it promoting address reuse, but in this case, I
think it's OK. The primary purpose of a coalescing transaction is to
clear out *all* funds associated with one address and send them to
another address (belonging to the same owner). If you coalesce the
inputs to the same address over and over again, you an do that, but
you'll run the risk of leaking your private key.
2. I see these transactions being broadcast in the background when the
user is not planning on sending or receiving any payments. By the time
the wallet user wants to spend funds from the address, the coalescing
transaction should be sufficiently deep enough in the blockchain to
avoid re-org tomfoolery. Exchanges and payment processors who take in
payments around the clock will probably never use these transactions,
at least not on "live" addresses.
3. I never thought of that, but thats a benefit too!
On 11/24/15, Jannes Faber via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
1. In its basic form this encourages address reuse. Unless the
wildcard can
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making
HD moot
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
to begin with.
2. Sounds pretty dangerous during reorgs. Maybe such a transaction
should
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
include a block height which indicates the maximum block that any
utxo can
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
match. With the requirement that the specified block height is at
least 100
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must
be
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
in that minimum block).
3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address,
and
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect.
I think this is true. Not *all* transactions will be able to match the
wildcard. For instance if someone sent some crazy smart contract tx to
your address, the script associated with that tx will be such that it
will not apply to the wildcard. Most "vanilla" utxos that I've seen
have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
apply to the wildcard.
On 11/24/15, Dave Scotese via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
What is required to spend bitcoin is that input be provided to the
UTXO
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a
requirement
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address,
and
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect. I imagine the
cost
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
of
Post by Dave Scotese via bitcoin-dev
re-scanning the UTXO set to find them all would justify a special
extra
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
mining fee for any transaction that used this opcode.
Please be blunt about any of my own misunderstandings that this email
makes
Post by Dave Scotese via bitcoin-dev
clear.
On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you
need
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
which
Post by Dave Scotese via bitcoin-dev
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJWVcKuAAoJEJ51csApon2ofiYP/15DXthFvNg9pBPOaaboGOh1
DhN7R3SXnt4PTLygQGO3AkTRcDinQrZ0Q4GDLIgrOkaKJ4yr6FtnoEYGORQSfFkx
946eWtqkR4+IJi7gYIIn1yOfFjWKUp9l4OOWBA8Rxsn0tZUAQPXzf2f+dxAaj0Gd
fLrftYvK1XJ8BolhwNfonJ193RJGFynQfWqZ+XeQQMS5LW23RpQLyI26f495MPHG
Wug7M/Aq50JrJDe1OyhjnnjYxNV6Gdbg9o3YIdj2gaOsBKHzsPK+LjcLCdRqD/OI
TBwmwiI4vrOl3HzvtucHxQqnaP43wubydVhPfmjG97tDaj2cVLjadc17e77PzCVI
8N21oVIWDzyW6y14REoo1Zs4A9ALpHjXAGWdls71eP1NIFcfdFAJWhk2/giisw8o
ZsQTgq2mUHS+n4q3NjFEwGxS011yADE3Uf3ryjuTjp3HVQf3lZxn4E4Z7z/4gkXm
/h/3Ln7PkjEmOqp9htgHcYW7q5goeJzV0xNDBoY9wvOlJQcAh6nTiS4SJEiFJvXU
xVZIGZsisrdW/1CfcszOi7KFGaaV1VlAXQnuJHj1I3dJ2r68yi5TQk6voMNFprEz
2R4zuZKjIoH79rOjDV8l6XBIU1Kh92GEzCFlTicfvnAoa853fGZt+V/77ralftJW
E6sERK8uG8S3KdBSVQ7K
=1xdi
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dave Scotese via bitcoin-dev
2015-11-25 17:03:32 UTC
Permalink
The message could specify:
{ stib: 0x01,
TxnCount: (# of entries in the Indexes array)
Indexes: [{BLK: Block#,Txns:[TxIndex,TxIndex,...]},{BLK:
Block#,Txns:[...]}],
NewUTXO: (The script that will spend these coins)
}
*stib *is a Script Template Index Bitfield: Must (currently) be the byte
0x01, to indicate the "vanilla" script Chris identified. If other scripts
appear to fit the bill in the future, they can be assigned to other bits.
*Indexes *is a list of pairs that identify a block by its height and a list
of indexes into the block. This puts the onus on the transactor to
identify all the inputs instead of requiring the miner to scan for them.

If block heights and transaction indexes are 32-bit integers, this reduces
the per-input size cost by at least 100 bytes, if I did my math right.


On Wed, Nov 25, 2015 at 6:16 AM, Erik via bitcoin-dev <
Post by Erik via bitcoin-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Considering the website example, where most websites uses static
content, a bitcoin address could accumulate a dozen of transactions
before the webmaster changes the address to a new one.
Also consider a QR-code address printed on paper. That address is also
prone to multiple payments, which could be several small ones.
You ask someone to pay an amount of BTC. That person would be someone
that want you to actually don't get any money at all, so instead of
sending one payment, the person sends a lot of small TXes. It costs a
lot more to achieve this, but that doesn't bother the person sending the
transactions. What you see is the transactions to the address you've
agreed sum up to the amount you asked for. When you later try to spend
it, you can't because of that the size of all UXTOs is too high to even
overcome the tx fee.
If you use a wildcard transaction to bake them together into one UXTO,
you will not need to pay more than just one tx fee to solve the problem
you've got. Also the network will benefit from this because the
alternative is to not spend those UXTOs at all because it costs more
than it earns, leaving lots of UXTOs in the databases.
* Which addresses should be involved in a wildcard TX.
* How to not make it repeatable or delayed so that UXTOs not intended to
be in that TX wouldn't be included.
* How to make it impossible to sign an wildcard TX with a future date.
* How to limit outputs so they not are in risk being double-spent.
* How to guarantee that the output is actually calculated from all the
inputs involved and not less, making insane TX fees available.
* Using the highest block height number of transactions to include or
maybe better, the UXTO of one transaction destined to that address
involved in that block - that implies collecting all UXTOs in that block.
* Using a signature that includes the date. To let it be present more
times in the blockchain requires another timestamp that is newer than a
wildcard TX already existing in the blockchain. Also make the
transaction invalid to put in a block if the timestamp is behind a
certain time or in the future.
* Using the coinbase UXTO or the block hash from the latest block as
proof that the transaction isn't created earlier than that. Also makes
the wildcard TX invalid if that block isn't part of the blockchain
anymore. This also have a secondary effect of certifying the blockchain
itself making it more difficult to fork it from far behind because it
will effectively remove all transactions depending on a UXTO including
this type of certification.
* Either using a priority like way to determine what are being left to
wildcard in a block - all transactions spending UXTOs of that address is
removed before the wildcard TX if they occurs in the same block. Either
it is possible to set a rule that if a wildcard TX exists in one block,
it is invalid to include other UXTOs that is to be be included in the
wildcard from the same address in the same block. (Classic
double-spending rule)
* Using a special form of output specifying only one destination
address/script and the amount of fees to pay. If the amount of fees
could be payed, then the rest will be sent to the destination address.
This covers intentional delaying and also discourage forking the
blockchain by miners to making the signature UXTO appear later than more
recent transaction in a new fork to collect the later txes as fee.
This transaction type would in fact look like a time-limited offer to
the network to reduce the UXTO set of an address. I guess some miners
will then use a logic that prefers this types of TXes even if they are
low-fee because, if they removes lots of UXTOs, they benefits the network.
Sincerely,
Erik.
Post by Chris Priest via bitcoin-dev
1. Technically is it promoting address reuse, but in this case, I
think it's OK. The primary purpose of a coalescing transaction is to
clear out *all* funds associated with one address and send them to
another address (belonging to the same owner). If you coalesce the
inputs to the same address over and over again, you an do that, but
you'll run the risk of leaking your private key.
2. I see these transactions being broadcast in the background when the
user is not planning on sending or receiving any payments. By the time
the wallet user wants to spend funds from the address, the coalescing
transaction should be sufficiently deep enough in the blockchain to
avoid re-org tomfoolery. Exchanges and payment processors who take in
payments around the clock will probably never use these transactions,
at least not on "live" addresses.
3. I never thought of that, but thats a benefit too!
On 11/24/15, Jannes Faber via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
1. In its basic form this encourages address reuse. Unless the
wildcard can
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making
HD moot
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
to begin with.
2. Sounds pretty dangerous during reorgs. Maybe such a transaction
should
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
include a block height which indicates the maximum block that any
utxo can
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
match. With the requirement that the specified block height is at
least 100
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
blocks in the past. Maybe add a minimum block height as well to prevent
unnecessary scanning (with the requirement that at least one utxo must
be
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
in that minimum block).
3. Seems like a nice way to the reduce utxo set. But hard to say how
effective it would really be.
On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" <
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address,
and
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect.
I think this is true. Not *all* transactions will be able to match the
wildcard. For instance if someone sent some crazy smart contract tx to
your address, the script associated with that tx will be such that it
will not apply to the wildcard. Most "vanilla" utxos that I've seen
have the formula: OP_DUP OP_HASH160 [a hash corresponding to your
address] OP_EQUALVERIFY OP_CHECKSIG". Just UTXOs in that form could
apply to the wildcard.
On 11/24/15, Dave Scotese via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
What is required to spend bitcoin is that input be provided to the
UTXO
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a
requirement
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
that the secret be known. Granted, the secret is the only requirement in
most cases, but there is no built-in assumption that the script always
requires only that secret.
This idea could be applied by having the wildcard signature apply to all
UTXOs that are of a standard form and paid to a particular address,
and
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
be
Post by Dave Scotese via bitcoin-dev
a signature of some kind of message to that effect. I imagine the
cost
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
of
Post by Dave Scotese via bitcoin-dev
re-scanning the UTXO set to find them all would justify a special
extra
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
mining fee for any transaction that used this opcode.
Please be blunt about any of my own misunderstandings that this email
makes
Post by Dave Scotese via bitcoin-dev
clear.
On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev <
Post by Bryan Bishop via bitcoin-dev
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
Post by Chris Priest via bitcoin-dev
**OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you
need
Post by Chris Priest via bitcoin-dev
Post by Jannes Faber via bitcoin-dev
Post by Chris Priest via bitcoin-dev
Post by Dave Scotese via bitcoin-dev
a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
which
Post by Dave Scotese via bitcoin-dev
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJWVcKuAAoJEJ51csApon2ofiYP/15DXthFvNg9pBPOaaboGOh1
DhN7R3SXnt4PTLygQGO3AkTRcDinQrZ0Q4GDLIgrOkaKJ4yr6FtnoEYGORQSfFkx
946eWtqkR4+IJi7gYIIn1yOfFjWKUp9l4OOWBA8Rxsn0tZUAQPXzf2f+dxAaj0Gd
fLrftYvK1XJ8BolhwNfonJ193RJGFynQfWqZ+XeQQMS5LW23RpQLyI26f495MPHG
Wug7M/Aq50JrJDe1OyhjnnjYxNV6Gdbg9o3YIdj2gaOsBKHzsPK+LjcLCdRqD/OI
TBwmwiI4vrOl3HzvtucHxQqnaP43wubydVhPfmjG97tDaj2cVLjadc17e77PzCVI
8N21oVIWDzyW6y14REoo1Zs4A9ALpHjXAGWdls71eP1NIFcfdFAJWhk2/giisw8o
ZsQTgq2mUHS+n4q3NjFEwGxS011yADE3Uf3ryjuTjp3HVQf3lZxn4E4Z7z/4gkXm
/h/3Ln7PkjEmOqp9htgHcYW7q5goeJzV0xNDBoY9wvOlJQcAh6nTiS4SJEiFJvXU
xVZIGZsisrdW/1CfcszOi7KFGaaV1VlAXQnuJHj1I3dJ2r68yi5TQk6voMNFprEz
2R4zuZKjIoH79rOjDV8l6XBIU1Kh92GEzCFlTicfvnAoa853fGZt+V/77ralftJW
E6sERK8uG8S3KdBSVQ7K
=1xdi
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
Loading...