Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Stephen Morse]

It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?

Best,
Stephen

On Fri, Jun 19, 2015 at 6:39 AM, Peter Todd  wrote:

> Yesterday F2Pool, currently the largest pool with 21% of the hashing
> power, enabled full replace-by-fee (RBF) support after discussions with
> me. This means that transactions that F2Pool has will be replaced if a
> conflicting transaction pays a higher fee. There are no requirements for
> the replacement transaction to pay addresses that were paid by the
> previous transaction.
>
>
> I'm a user. What does this mean for me?
> ---
>
> In the short term, very little. Wallet software aimed at average users
> has no ability to reliably detect conditions where an unconfirmed
> transaction may be double-spent by the sender. For example, Schildbach's
> Bitcoin Wallet for Android doesn't even detect double-spends of
> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
> that propagate them. The least sophisticated double-spend attack
> possibly - simply broadcasting two conflicting transactions at the same
> time - has about 50% probability of success against these wallets.
>
> Additionally, SPV wallets based on bitcoinj can't even detect invalid
> transactions reliably, instead trusting the full node(s) it is connected
> too over the unauthenticated, unencrypted, P2P protocol to do validation
> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
> double-spends that spend the output of the conflicting transaction. I've
> personally tested this with Schildbach's Bitcoin Wallet for Android,
> which shows such invalid transactions as standard, unconfirmed,
> transactions.
>
> Users should continue to assume that unconfirmed transactions could be
> trivially reversed by the sender until the first confirmation. In
> general, only the sender can reverse a transaction, so if you do trust
> the sender feel free to assume an unconfirmed transaction will
> eventually confirm. However, if you do not trust the sender and/or have
> no other recourse if they double-spend you, wait until at least the
> first confirmation before assuming the transaction will go through.
>
> In the long term, miner support of full RBF has a number of advantages
> to users, allowing you to more efficiently make transactions, paying
> lower fees. However you'll need a wallet supporting these features; none
> exist yet.
>
>
> I'm a business. What does this mean for me?
> ---
>
> If you use your own node to verify transactions, you probably are in a
> similar situation as average users, so again, this means very little to
> you.
>
> If you use a payment processor/transaction API such as BitPay, Coinbase,
> BlockCypher, etc. you may or may not be accepting unconfirmed
> transactions, and they may or may not be "guaranteed" by your payment
> processor even if double-spent. If like most merchants you're using the
> API such that confirmations are required prior to accepting orders (e.g.
> taking a meaningful loss such as shipping a product if the tx is
> reversed) nothing changes for you. If not I recommend you contact your
> payment processor.
>
>
> I'm a miner. Why should I support replace-by-fee?
> -
>
> Whether full or first-seen-safe⁵ RBF support (along with
> child-pays-for-parent) is an important step towards a fully functioning
> transaction fee market that doesn't lead to users' transactions getting
> mysteriously "stuck", particularly during network flooding
> events/attacks. A better functioning fee market will help reduce
> pressure to increase the blocksize, particularly from the users creating
> the most valuable transactions.
>
> Full RBF also helps make use of the limited blockchain space more
> efficiently, with up to 90%+ transaction size savings possible in some
> transaction patterns. (e.g. long payment chains⁶) More users in less
> blockchain space will lead to higher overall fees per block.
>
> Finally as we'll discuss below full RBF prevents a number of serious
> threats to the existing level playing field that miners operate in.
>
>
> Why can't we make accepting unconfirmed txs from untrusted people safe?
> ---
>
> For a decentralized wallet, the situation is pretty bleak. These wallets
> only have a handful of connections to th

Re: [Bitcoin-development] Ninki Wallet view on blocksize debate

[Stephen Morse]

Ben,

How does your wallet calculate the fee that should be paid to miners? Do
they automatically adjust when transactions take a long time to be
confirmed? And how does it respond when transactions are not mined
successfully, such as when blocks are full?

I strongly urge Gavin to withdraw from this standoff and work with the
> bitcoin core devs via the existing and successful bip process.
>

The BIP process has not resulted in any hard forks, so this is a little
different. While I don't like M&G's proposed solution of convincing miners
and services to switch to Bitcoin-XT, I recognize that it is done out of a
sense of urgency. These types of changes take a long time to roll out, and
we should start them before it is too late.

This whole debate comes down to: what is more risky, a consensus hard fork
or letting bitcoin exceed its imposed capacity limits? The former could
result in many services not being compatible and even loss of funds. The
latter could result in software failures, instability, and inability to
transact: essentially, what bitcoin is supposed to be good at. Both are
dangerous and could result in a significant loss of public confidence.

Something needs to be done, that's for sure. In the short term, I think we
need to do one of two things:

   1. All miners and wallet developers need to upgrade to support
   first-safe RBF, to allow for double spending one's own transactions when
   they lack sufficient fees to merit confirmations. Wallets also need to
   randomly request transactions from blocks to see what kind of fees are
   being paid to get confirmations, so that fees can be paid dynamically
   instead of with hard-coded values.
   2. We can implement either Gavin's or Jeff Garzik's proposal to change
   the consensus parameters around the block size limit.

So Ben, if really don't think that going with #2 is the right way to go
(even though everyone agrees that we will need to increase the block size
limit eventually anyway, why not now?), then I hope you start to work hard
on implementing #1 so that your wallet software can handle hitting capacity
limits gracefully.

Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] User vote in blocksize through fees

[Stephen]

While this idea is theoretically interesting because it involves many 
stakeholders, rather than just miners, I think in practice this would not work 
very well. Users don't want to worry about this kind of technicality, they just 
want to be able to make a transaction and have it be processed. 

In addition, while this gives stakeholders some weight with the fees they 
supply, these fees are marginal compared to the block size subsidy. If this 
proposal were actually implemented, I think miners would vote for whatever they 
think is best, and users would not contradict them with their votes to ensure a 
fast confirmation time. Users are incentivized to be in agreement with miners 
because the miners provide them with the confirmations they need, but fees do 
not provide a great incentive for miners to be in agreement with users, and 
likely won't for some time. 

Best, 
Stephen 




> On Jun 12, 2015, at 2:11 PM, Peter Todd  wrote:
> 
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
> 
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
> 
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
> 
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
> 
> 
> See also John Dillon's proposal for proof-of-stake blocksize voting:
> 
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs

[Stephen]

Hi Kristov,

I like the idea. Mainly because having a standard reminds developers to 
consider this issue. In addition, we would have visibility into the portion of 
the network that adopts this strategy to enhance privacy. A few points of 
feedback:

 - I think your explanation of sorting could be significantly shortened and 
clarified by simply saying that the TXIDs of inputs should be compared as 
uint256 integers. 
 - The malleability of input TXIDs, as mentioned in the proposal, could cause 
inputs to be ordered in a non-standard way. Reordering then them would 
invalidate the signatures (assuming SIGHASH_ALL), so the transaction would be 
left with improperly ordered inputs. While not a huge issue, it's not ideal. I 
think the best way to get around this would be to use normalized TXIDs, but you 
might also be able to sort based on the previous outputs that each of the 
inputs are spending? These both require information that may not be readily 
available, however, and use of normalized transaction IDs is not fully 
developed yet. 

Best,
Stephen 



> On Jun 5, 2015, at 8:12 PM, Kristov Atlas  
> wrote:
> 
> Hello all,
> 
> I have written a draft of a BIP to standardize the sorting of tx inputs and 
> outputs for privacy and security reasons. A few colleagues have reviewed this 
> and provided feedback privately, but now it's ready for feedback from a wider 
> audience.
> 
> If there is positive sentiment about the proposal after feedback is 
> integrated, I aim for a bip number to be assigned and have it accepted into 
> https://github.com/bitcoin/bips 
> 
> Link: https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki
> 
> For your convenience, here's the abstract:
> 
> "Currently there is no standard for bitcoin wallet clients when ordering 
> transaction inputs and outputs. As a result, wallet clients often have a 
> discernible blockchain fingerprint, and can leak private information about 
> their users. By contrast, a standard for non-deterministic sorting could be 
> difficult to audit. This document proposes deterministic lexicographical 
> sorting, using hashes of previous transactions and output indices to sort 
> transaction inputs, as well as value and locking scripts to sort transaction 
> outputs."
> 
> Thanks,
> 
> Kristov Atlas
> Open Bitcoin Privacy Project Contributor, Blockchain.info Security Engineer, 
> etc.
> Twitter: @kristovatlas
> Blog: kristovatlas.com
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure

[Stephen Morse]

Vincent,

> Some changes:
>
> Votes need to be 100%, not 50.01%. That way small miners have a fair
> chance. A 50.01% vote means large miners call the shots.
>
While I like the idea of possibly requiring more than 50%, you wouldn't
want to have a situation where a minority of uncooperative (or just lazy)
miners don't add their votes and hold up progress. Maybe 2/3 instead of
1/2, though.

> Users (people who make transactions) need to vote. A vote by a miner
> shouldn't count without user votes. Fee incentives should attract
> legitimate votes from miners. A cheating miner will be defeated by another
> miner who includes those votes, and take the fees.
>
> This lets wallet providers and exchanges cast votes (few wallets will
> implement prompts and will just auto vote, so if you don't agree, switch
> wallets. Vote with your wallet).
>
The idea of voting with your wallet, while appealing, is technically
infeasible. Miners can fill their blocks with any type of transactions,
including their own specially designed transactions. And any fees from
these transactions can be collected right back into their coinbase
transaction.

- Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure

[Stephen Morse]

Pindar,

yes and it's a good idea to separate the hard/soft fork upgrades. The point
> being here is that we're also establishing a process for the community to
> self-determine the way forward in a transparent and verifiable manner.
>
> What's not to like? :)
>
> I'll probably have some time on Sunday to help hack something up but I
> don't think this is that heavy a coding lift? What am I missing?
>

As Matt mentioned, many members of the bitcoin community would be hesitant
about giving miners this much power. It essentially lets them vote to
change the rules of the system. But miners are not the only part of this
ecosystem, and they are not the only ones affected by the choice of block
size limit, so they probably shouldn't be the only ones with a vote.
Instead, we vote with the software we run, and all upgrade.

So, while I think an idea like this has its merits, I would bet that it's
fairly unlikely to get enough support to be merged into bitcoin core.

Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure

[Stephen Morse]

>
> Why do it as an OP_RETURN output? It could be a simple token in the
> coinbase input script, similar to how support for P2SH was signaled among
> miners. And why should there be an explicit token for voting for the status
> quo? Simply omitting any indication should be an implicit vote for the
> status quo. A miner would only need to insert an indicator into their block
> if they wished for a larger block.
>

I don't really care the exact location it's put in. I just thought there
wasn't an explicit need to put it in the header (via a bit of nVersion),
and the scriptSig is already used for many things (block height, merged
mining hash, "\"P2SH\"", miner identifier). And voting to keep the block
size the same by not voting is fine by me.


> That said, proposals of this type have been discussed before, and the
> objection is always that miners would want larger blocks than the rest of
> the network could bear. Unless you want Bitcoin to become centralized in
> the hands of a few large mining pools, you shouldn't hand control over the
> block size limits to the miners.
>

Yeah, that was the conclusion we came to chatting on #bitcoin-wizards the
other day. I now think that this could be useful to dynamically increase a
lower limit, but that there should still be a hard upper limit like 20 MB.
I think that just changing the upper limit might be simpler and better,
though.

- Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen Morse]

>
> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time.  That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>

Very good point.


>
> (Not a huge flexibility loss as you can implement "not after" by
> making it the previous holders responsibility to spend a "not before"
> back to themselves.)
>

Do you mean something like the below?

scriptPubKey:
  IF
{A's pub} CHECKSIGVERIFY
  ELSE
{curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY

This ensures that Alice has to spend the output in the next 100 blocks or
risk it being taken from her (she just has to put an OP_TRUE on the end of
her scriptSig). So, it seems we can forget about an inverted CLTV/CSV,
great!

Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen]

Do you think it would be useful to have an inverted version of both CSV and 
CLTV? To verify if an output is spent before a specific time. CLTV and CSV 
could be implemented by taking two stack arguments, an integer for the 
comparison and TRUE/FALSE. 

Now that I think about this more, the problem is that, for example, just having 
a lock time of less than some value doesn't actually mean it has to be spent 
before that script value, so this might not work. Likely any implementations of 
such a feature would have to provide the script execution environment with 
access to information that it doesn't have now, which is what we are trying to 
avoid. 

Best,
Stephen



> On Jun 2, 2015, at 12:16 AM, Mark Friedenbach  wrote:
> 
> You are correct! I am maintaining a 'checksequenceverify' branch in my git 
> repository as well, an OP_RCLTV using sequence numbers:
> 
> https://github.com/maaku/bitcoin/tree/checksequenceverify
> 
> Most of the interesting use cases for relative lock-time require an RCLTV 
> opcode. What is interesting about this architecture is that it possible to 
> cleanly separate the relative lock-time (sequence numbers) from the RCLTV 
> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like 
> CLTV, the CSV opcode only checks transaction data and requires no contextual 
> knowledge about block headers, a weakness of the other RCLTV proposals that 
> violate the clean separation between libscript and libconsensus. In a similar 
> way, this BIP proposal only touches the transaction validation logic without 
> any impact to script.
> 
> I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY 
> opcode and its enabling applications. But, well, one thing at a time.
> 
>> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse  
>> wrote:
>> Hi Mark,
>> 
>> Overall, I like this idea in every way except for one: unless I am missing 
>> something, we may still need an OP_RCLTV even with this being implemented. 
>> 
>> In use cases such as micropayment channels where the funds are locked up by 
>> multiple parties, the enforcement of the relative locktime can be done by 
>> the first-signing party. So, while your solution would probably work in 
>> cases like this, where multiple signing parties are involved, there may be 
>> other, seen or unforeseen, use cases that require putting the relative 
>> locktime right into the spending contract (the scriptPubKey itself). When 
>> there is only one signer, there's nothing that enforces using an nSequence 
>> and nVersion=2 that would prevent spending the output until a certain time. 
>> 
>> I hope this is received as constructive criticism, I do think this is an 
>> innovative idea. In my view, though, it seems to be less fully-featured than 
>> just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously 
>> that it saves transaction space by repurposing unused space, and would 
>> likely work for most cases where an OP_RCLTV would be needed.
>> 
>> Best,
>> Stephen
>> 
>>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach  
>>> wrote:
>>> I have written a reference implementation and BIP draft for a soft-fork 
>>> change to the consensus-enforced behaviour of sequence numbers for the 
>>> purpose of supporting transaction replacement via per-input relative 
>>> lock-times. This proposal was previously discussed on the mailing list in 
>>> the following thread:
>>> 
>>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>> 
>>> In short summary, this proposal seeks to enable safe transaction 
>>> replacement by re-purposing the nSequence field of a transaction input to 
>>> be a consensus-enforced relative lock-time.
>>> 
>>> The advantages of this approach is that it makes use of the full range of 
>>> the 32-bit sequence number which until now has rarely been used for 
>>> anything other than a boolean control over absolute nLockTime, and it does 
>>> so in a way that is semantically compatible with the originally envisioned 
>>> use of sequence numbers for fast mempool transaction replacement.
>>> 
>>> The disadvantages are that external constraints often prevent the full 
>>> range of sequence numbers from being used when interpreted as a relative 
>>> lock-time, and re-purposing nSequence as a relative lock-time precludes its 
>>> use in other contexts. The latter point has been partially addressed by 
>>> having the relative lock-time semantics be enforced only if the 
>>> most-significant bit of nSequence is set. This pres

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen Morse]

I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right
before, and then check that the input spending the prevout has nSequence
corresponds to at least the sequence specified by the stack value. Good
idea! Keeps the script code from depending on external chain specific data,
which is nice.

Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and
one for OP_CHECKSEQUENCEVERIFY. Very complementary.

Best,
Stephen


On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach 
wrote:

> You are correct! I am maintaining a 'checksequenceverify' branch in my git
> repository as well, an OP_RCLTV using sequence numbers:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify
>
> Most of the interesting use cases for relative lock-time require an RCLTV
> opcode. What is interesting about this architecture is that it possible to
> cleanly separate the relative lock-time (sequence numbers) from the RCLTV
> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
> CLTV, the CSV opcode only checks transaction data and requires no
> contextual knowledge about block headers, a weakness of the other RCLTV
> proposals that violate the clean separation between libscript and
> libconsensus. In a similar way, this BIP proposal only touches the
> transaction validation logic without any impact to script.
>
> I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
> opcode and its enabling applications. But, well, one thing at a time.
>
> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse  > wrote:
>
>> Hi Mark,
>>
>> Overall, I like this idea in every way except for one: unless I am
>> missing something, we may still need an OP_RCLTV even with this being
>> implemented.
>>
>> In use cases such as micropayment channels where the funds are locked up
>> by multiple parties, the enforcement of the relative locktime can be done
>> by the first-signing party. So, while your solution would probably work in
>> cases like this, where multiple signing parties are involved, there may be
>> other, seen or unforeseen, use cases that require putting the relative
>> locktime right into the spending contract (the scriptPubKey itself).
>> When there is only one signer, there's nothing that enforces using an
>> nSequence and nVersion=2 that would prevent spending the output until a
>> certain time.
>>
>> I hope this is received as constructive criticism, I do think this is an
>> innovative idea. In my view, though, it seems to be less fully-featured
>> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
>> obviously that it saves transaction space by repurposing unused space, and
>> would likely work for most cases where an OP_RCLTV would be needed.
>>
>> Best,
>> Stephen
>>
>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach 
>> wrote:
>>
>>> I have written a reference implementation and BIP draft for a soft-fork
>>> change to the consensus-enforced behaviour of sequence numbers for the
>>> purpose of supporting transaction replacement via per-input relative
>>> lock-times. This proposal was previously discussed on the mailing list in
>>> the following thread:
>>>
>>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>>
>>> In short summary, this proposal seeks to enable safe transaction
>>> replacement by re-purposing the nSequence field of a transaction input to
>>> be a consensus-enforced relative lock-time.
>>>
>>> The advantages of this approach is that it makes use of the full range
>>> of the 32-bit sequence number which until now has rarely been used for
>>> anything other than a boolean control over absolute nLockTime, and it does
>>> so in a way that is semantically compatible with the originally envisioned
>>> use of sequence numbers for fast mempool transaction replacement.
>>>
>>> The disadvantages are that external constraints often prevent the full
>>> range of sequence numbers from being used when interpreted as a relative
>>> lock-time, and re-purposing nSequence as a relative lock-time precludes its
>>> use in other contexts. The latter point has been partially addressed by
>>> having the relative lock-time semantics be enforced only if the
>>> most-significant bit of nSequence is set. This preserves 31 bits for
>>> alternative use when relative lock-times are not required.
>>>
>>> The BIP draft can be found at the following gist:
>>>
>>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>>
>>> The reference implemen

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Stephen Morse]

Hi Mark,

Overall, I like this idea in every way except for one: unless I am missing
something, we may still need an OP_RCLTV even with this being implemented.

In use cases such as micropayment channels where the funds are locked up by
multiple parties, the enforcement of the relative locktime can be done by
the first-signing party. So, while your solution would probably work in
cases like this, where multiple signing parties are involved, there may be
other, seen or unforeseen, use cases that require putting the relative
locktime right into the spending contract (the scriptPubKey itself). When
there is only one signer, there's nothing that enforces using an nSequence
and nVersion=2 that would prevent spending the output until a certain time.

I hope this is received as constructive criticism, I do think this is an
innovative idea. In my view, though, it seems to be less fully-featured
than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
obviously that it saves transaction space by repurposing unused space, and
would likely work for most cases where an OP_RCLTV would be needed.

Best,
Stephen

On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach 
wrote:

> I have written a reference implementation and BIP draft for a soft-fork
> change to the consensus-enforced behaviour of sequence numbers for the
> purpose of supporting transaction replacement via per-input relative
> lock-times. This proposal was previously discussed on the mailing list in
> the following thread:
>
> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>
> In short summary, this proposal seeks to enable safe transaction
> replacement by re-purposing the nSequence field of a transaction input to
> be a consensus-enforced relative lock-time.
>
> The advantages of this approach is that it makes use of the full range of
> the 32-bit sequence number which until now has rarely been used for
> anything other than a boolean control over absolute nLockTime, and it does
> so in a way that is semantically compatible with the originally envisioned
> use of sequence numbers for fast mempool transaction replacement.
>
> The disadvantages are that external constraints often prevent the full
> range of sequence numbers from being used when interpreted as a relative
> lock-time, and re-purposing nSequence as a relative lock-time precludes its
> use in other contexts. The latter point has been partially addressed by
> having the relative lock-time semantics be enforced only if the
> most-significant bit of nSequence is set. This preserves 31 bits for
> alternative use when relative lock-times are not required.
>
> The BIP draft can be found at the following gist:
>
> https://gist.github.com/maaku/be15629fe64618b14f5a
>
> The reference implementation is available at the following git repository:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
> I request that the BIP editor please assign a BIP number for this work.
>
> Sincerely,
> Mark Friedenbach
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

[Stephen Morse]

This exact question came up on the Bitcoin Stack Exchange once. I gave an
answer here:
http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303

On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips  wrote:

> Ok, I understand at least some of the reason that blocks have to be kept
> to a certain size. I get that blocks which are too big will be hard to
> propagate by relays. Miners will have more trouble uploading the large
> blocks to the network once they've found a hash. We need block size
> constraints to create a fee economy for the miners.
>
> But these all sound to me like issues that affect some, but not others. So
> it seems to me like it ought to be a configurable setting. We've already
> witnessed with last week's stress test that most miners aren't even
> creating 1MB blocks but are still using the software defaults of 730k. If
> there are configurable limits, why does there have to be a hard limit?
> Can't miners just use the configurable limit to decide what size blocks
> they can afford to and are thus willing to create? They could just as
> easily use that to create a fee economy. If the miners with the most
> hashpower are not willing to mine blocks larger than 1 or 2 megs, then they
> are able to slow down confirmations of transactions. It may take several
> blocks before a miner willing to include a particular transaction finds a
> block. This would actually force miners to compete with each other and find
> a block size naturally instead of having it forced on them by the protocol.
> Relays would be able to participate in that process by restricting the
> miners ability to propagate large blocks. You know, like what happens in a
> FREE MARKET economy, without burdensome regulation which can be manipulated
> through politics? Isn't that what's really happening right now? Different
> political factions with different agendas are fighting over how best to
> regulate the Bitcoin protocol.
>
> I know the limit was originally put in place to prevent spamming. But that
> was when we were mining with CPUs and just beginning to see the occasional
> GPU which could take control over the network and maliciously spam large
> blocks. But with ASIC mining now catching up to Moore's Law, that's not
> really an issue anymore. No one malicious entity can really just take over
> the network now without spending more money than it's worth -- and that's
> just going to get truer with time as hashpower continues to grow. And it's
> not like the hard limit really does anything anymore to prevent spamming.
> If a spammer wants to create thousands or millions of transactions, a hard
> limit on the block size isn't going to stop him.. He'll just fill up the
> mempool or UTXO database instead of someone's block database.. And block
> storage media is generally the cheapest storage.. I mean they could be
> written to tape and be just as valid as if they're stored in DRAM. Combine
> that with pruning, and block storage costs are almost a non-issue for
> anyone who isn't running an archival node.
>
> And can't relay nodes just configure a limit on the size of blocks they
> will relay? Sure they'd still need to download a big block occasionally,
> but that's not really that big a deal, and they're under no obligation to
> propagate it.. Even if it's a 2GB block, it'll get downloaded eventually.
> It's only if it gets to the point where the average home connection is too
> slow to keep up with the transaction & block flow that there's any real
> issue there, and that would happen regardless of how big the blocks are. I
> personally would much prefer to see hardware limits act as the bottleneck
> than to introduce an artificial bottleneck into the protocol that has to be
> adjusted regularly. The software and protocol are TECHNICALLY capable of
> scaling to handle the world's entire transaction set. The real issue with
> scaling to this size is limitations on hardware, which are regulated by
> Moore's Law. Why do we need arbitrary soft limits? Why can't we allow
> Bitcoin to grow naturally within the ever increasing limits of our
> hardware? Is it because nobody will ever need more than 640k of RAM?
>
> Am I missing something here? Is there some big reason that I'm overlooking
> why there has to be some hard-coded limit on the block size that affects
> the entire network and creates ongoing issues in the future?
>
> --
>
> *James G. Phillips IV*
> 
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
>  *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[Bitcoin-development] Max Block Size: Simple Voting Procedure

[Stephen Morse]

This is likely very similar to other proposals, but I want to bring voting
procedures back into the discussion. The goal here is to create a voting
procedure that is as simple as possible to increase the block size limit.

Votes are aggregated over each 2016 block period. Each coinbase transaction
may have an output at tx.vout[0] with OP_RETURN data in it of the format:

  OP_RETURN {OP_1 or OP_2}

OP_2 means the miner votes to increase the block size limit. OP_1 means the
miner votes to not increase the block size limit. *Not including such a
vote is equivalent to voting to NOT increase the block size. *I first
thought that not voting should mean that you vote with your block size, but
then decided that it would be too gameable by others broadcasting
transactions to affect your block size.

If in a 2016 block round there were more than 1008 blocks that voted to
increase the block size limit, then the max block size increases by 500 kb.
The votes can start when there is a supermajority of miners signaling
support for the voting procedure.

A few important properties of this simple voting:

   - It's not gameable via broadcasting transactions (assuming miners don't
   set their votes to be automatic, based on the size of recent blocks).
   - Miners don't have to bloat their blocks artificially just to place a
   vote for larger block sizes, and, similarly, don't need to exclude
   transactions even when they think the block size does not need to be raised.
   - The chain up until the point that this goes into effect may be
   interpreted as just lacking votes to increase the block size.

We can't trust all miners, but we have to trust that >50% of them are
honest for the system to work. This system makes it so that altering the
maximum block size requires >50% of miners (hash power) to vote to increase
the consensus-limit.

Thanks for your time. I think this is an important time in Bitcoin's
history. I'm not married to this proposal, but I think it would work. I
think a lot of the proposals mentioned on this mailing list would work. I
think it's time we just pick one and run with it.

Please let me know your thoughts. I will start working on a pull request if
this receives any support from miners/core devs/community members, unless
someone with more experience volunteers.

Best,
Stephen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Stephen Morse]

>
> An option would be that the height is included in the scriptSig for all
>> transactions, but for non-coinbase transctions, the height used is zero.
>>
> No need to add an extra field to the transaction just to include the
> height. We can just add a rule that the height specified in the scriptSig
> in coinbase transactions (and only coinbase transactions) is copied into
> the locktime of the transaction before computing the normalized transaction
> ID and leave the locktime untouched for all normal transactions
>

No need to replace lock times (or any other part of the transaction) at
all. If you have to, just serialize the height right before serializing the
transaction (into the same buffer). And you could pre-serialize 0 instead
of the height for all non-coinbase transactions. I don't really see what
that gets you, though, because the 0 is not really doing anything.

But, I don't see any reason you have to mess with the serialization this
much at all. Just do:

uint256 normalized_txid(CTransaction tx)
{
  // Coinbase transactions are already normalized
  if (!tx.IsCoinbase())
  {
foreach(CTxIn in : tx.vin)
{
  if (!ReplacePrevoutHashWithNormalizedHash(in.prevout))
throw NormalizationError("Could not lookup prevout");
  in.scriptSig.clear();
}
  }

  // Serialize
  CHashWriter ss(SER_GETHASH, 0);
  ss << tx;
  return ss.GetHash();
}

An alternative could be (although I like the above option better):

uint256 normalized_txid(CTransaction tx, int nHeight)
{
  foreach(CTxIn in : tx.vin)
  {
if (!in.prevout.IsNull() &&
!ReplacePrevoutHashWithNormalizedHash(in.prevout))
  throw NormalizationError("Could not lookup prevout");
in.scriptSig.clear();
  }

  // Serialize
  CHashWriter ss(SER_GETHASH, 0);

if (tx.IsCoinbase())
ss << nHeight;
// or:
// ss << (tx.IsCoinbase() ? nHeight : 0);

  ss << tx;
  return ss.GetHash();
}
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Stephen]

Comments in line:

> On May 8, 2015, at 11:08 PM, Peter Todd  wrote:
> 
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
> 
> Right now pools already get DoSed all the time through their work
> submission systems; getting DoS attacked via their nodes as well would
> be a disaster.

It seems that using a -miner flag to follow rules about smaller blocks would 
only reveal miner nodes if one sent the node a solved block that that was valid 
in every way except the block size. While not impossible, I wouldn't call this 
trivial, as it still requires wasting an entire block's worth of energy. 

>> When in "miner mode", the client would reject 4MB blocks and wouldn't build
>> on them.  The reference client might even track the miner and the non-miner
>> chain tip.
>> 
>> Miners would refuse to build on 5MB blocks, but merchants and general users
>> would accept them.
> 
> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
> 

I think this could be mitigated by counting confirmations differently. We 
should think of confirmations as only coming from blocks following the miners' 
more strict rule set. So if a merchant were to see payment for the first time 
in a block that met their own size restrictions but not the miners', then they 
would simply count it as unconfirmed. 

If they get deep enough in the chain, though, the client should probably count 
them as being confirmed anyway, even if they don't meet the client nodes' 
expectation of the miners' block size limit. This happening probably just means 
that the client has not updated their software (or -minermaxblocksize 
configuration, depending on how it is implemented) in a long time. 

I actually like Tier's suggestion quite a bit. I think we could have the 
default client limit set to some higher number, and have miners agree out of 
band on the latest block size limit. Or maybe even build in a way to vote into 
the blockchain. 

Best, 
Stephen
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Stephen]

We should make sure to consider how BIP34 affects normalized transaction ids, 
since the height of the block is included in the scriptSig ensuring that the 
txid will be different. We wouldn't want to enable replay attacks in the form 
of spending coinbase outputs in the same way they were spent from a previous 
block. 

So maybe normalized txids should strip the scriptSigs of all transactions 
except for coinbase transactions? This seems to make sense, since coinbase 
transactions are inherently not malleable anyway. 

Also, s7r linked to my 'Build your own nHashType' proposal (although V2 is 
here: 
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal_v2.md). I 
just wanted to add that I think even with normalized ids, it could still be 
useful to be able to apply these flags to choose which parts of the transaction 
become signed. I've also seen vague references to some kind of a merklized 
abstract syntax tree, but am not fully sure how that would work. Maybe someone 
on here could explain it? 

Best,
Stephen



> On May 15, 2015, at 5:54 AM, s7r  wrote:
> 
> Hello,
> 
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
> b) replays
> 
> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
> 
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, and I don't think it's the proper way to do it.
> 
> Something similar can be achieved if you would use a combination of
> flags from here:
> 
> https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
> 
> But this has some issues too.
> 
> I've read your draft but didn't understand how exactly will this prevent
> normal malleability as we know it, second level malleability and replays
> as well as how will we do the transition into mapping the txes in the
> blockchain to normalized txids. Looking forward to read more on this
> topic. Thanks for the brainstorming ;)
> 
> 
>> On 5/13/2015 3:48 PM, Christian Decker wrote:
>> Hi All,
>> 
>> I'd like to propose a BIP to normalize transaction IDs in order to
>> address transaction malleability and facilitate higher level protocols.
>> 
>> The normalized transaction ID is an alias used in parallel to the
>> current (legacy) transaction IDs to address outputs in transactions. It
>> is calculated by removing (zeroing) the scriptSig before computing the
>> hash, which ensures that only data whose integrity is also guaranteed by
>> the signatures influences the hash. Thus if anything causes the
>> normalized ID to change it automatically invalidates the signature. When
>> validating a client supporting this BIP would use both the normalized tx
>> ID as well as the legacy tx ID when validating transactions.
>> 
>> The detailed writeup can be found
>> here: 
>> https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
>> 
>> @gmaxwell: I'd like to request a BIP number, unless there is something
>> really wrong with the proposal.
>> 
>> In addition to being a simple alternative that solves transaction
>> malleability it also hugely simplifies higher level protocols. We can
>> now use template transactions upon which sequences of transactions can
>> be built before signing them.
>> 
>> I hesitated quite a while to propose it since it does require a hardfork
>> (old clients would not find the prevTx identified by the normalized
>> transaction ID and deem the spending transaction invalid), but it seems
>> that hardforks are no longer the dreaded boogeyman nobody talks about.
>> I left out the details of how the hardfork is to be done, as it does not
>> really matter and we may have a good mechanism to apply a bunch of
>> hardforks concurrently in the future.
>> 
>> I'm sure it'll take time to implement and upgrade, but I think it would
>> be a nice addition to the functionality and would solve a long standing
>> problem :-)
>> 
>> Please let me know what you think, the proposal is definitely not set in
>> stone at this point and I'm sure we can improve it further.
>> 
>> Regards,
>> Christian
>> 
>> 
>> --
>> One dashboard for servers and applications across Physical-Virtual-Cloud 
>> Widest out-of-the-box monito

Re: [Bitcoin-development] A way to create a fee market even without a block size limit (2013)

[Stephen]

Why do so many tie the block size debate to creating "a fee market", as if one 
didn't already exist? Yes, today we frequently see many low priority 
transactions included into the next block, but that does not mean there is not 
a marketplace for block space. It just means miners are not being sufficiently 
tough to create a *competitive* marketplace. 

But who are we to say that the marketplace should be more competitive, and to 
go further and try to force it by altering consensus rules like the block size 
limit? If miners want to see more competitive fees, then they need only to 
alter their block creation protocol. 

There are many arguments for and against changing the consensus limit on block 
size. I'm simply saying that "to force a marketplace for fees/block space" 
should not be one of them. Let the market develop on it's own. 

- Stephen



> On May 10, 2015, at 4:45 PM, Sergio Lerner  wrote:
> 
> Two years ago I presented a new way to create a fee market that does not 
> depend on the block chain limit.
> 
> This proposal has not been formally analyzed in any paper since then, but I 
> think it holds a good promise to untangle the current problem regarding 
> increasing the tps and creating the fee market. BTW, think the maximum tps 
> should be increased, but not by increasing the block size, but by increasing 
> the block rate (I'll expose why in my next e-mail).
> 
> The original post is here (I was overly optimistic back then): 
> https://bitcointalk.org/index.php?topic=147124.msg1561612#msg1561612
> 
> I'll summarize it here again, with a little editing and a few more questions 
> at the end:
> 
> The idea is simple, but requires a hardfork, but is has minimum impact in the 
> code and in the economics.
> 
> Solution: Require that the set of fees collected in a block has a dispersion 
> below a threshold. Use, for example, the Coefficient of Variation 
> (http://en.wikipedia.org/wiki/Coefficient_of_variation). If the CoVar is 
> higher than a fixed threshold, the block is considered invalid.
> 
> The Coefficient of variation is computed as the standard deviation over the 
> mean value, so it's very easy to compute. (if the mean is zero, we assume 
> CoVar=0). Note that the CoVar function does not depend on the scale, so is 
> just what a coin with a floating price requires.
> 
> This means that if there are many transactions containing high fees in a 
> block, then free transactions cannot be included.
> The core devs should tweak the transaction selection algorithm to take into 
> account this maximum bound.
> 
> Example
> 
> If the transaction fee set is: 0,0,0,0,5,5,6,7,8,7
> The CoVar is 0.85
> Suppose we limit the CoVar to a maximum of 1.
> 
> Suppose the transaction fee set is: 0,0,0,0,0,0,0,0,0,10
> Then the CoVar is 3.0
> 
> In this case the miner should have to either drop the "10" from the fee set 
> or drop the zeros. Obviously the miner will drop some zeros, and choose the 
> set: 0,10, that has a CoVar of 1.
> 
> Why it reduces the Tx spamming Problem?
> 
> Using this little modification, spamming users would require to use higher 
> fees, only if the remaining users in the community rises their fees. And 
> miners won't be able to include an enormous amounts of spamming txs.
> 
> Why it helps solving the tragedy-of-the-commons fee "problem"?
> 
> As miners are forced to keep the CoVar below the threshold, if people rises 
> the fees to confirm faster than spamming txs, automatically smamming txs 
> become less likely to appear in blocks, and fee-estimators will automatically 
> increase future fees, creating a the desired feedback loop.
> 
> Why it helps solving the block size problem?
> 
> Because if we increase the block size, miners that do not care about the fee 
> market won't be able to fill the block with spamming txs and destroy the 
> market that is being created. This is not a solution against an 
> attacker-miner, which can always fill the block with transactions.
> 
> Can the system by gamed? Can it be attacked?
> 
> I don't think so. An attacker would need to spend a high amount in fees to 
> prevent transactions with low fees to be included in a block. 
> However, a formal analysis would be required. Miller, Gun Sirer, Eyal.. Want 
> to give it a try?
> 
> Can create a positive feedback to a rise the fees to the top or push fess to 
> the bottom?
> 
> Again, I don't think so. This depends on the dynamics between the each node's 
> fee estimator and the transaction backlog. MIT guys? 
> 
> Doesn't it force miners to run more complex algorithms (such as linear 
> programming) to find the optimum tx subset 

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[Stephen Morse]

Hi Gregory,

In particular not covering the ID allows for transaction replay which
> can result in monetary losses far more severe than any possible
> mishandling of malleability could result in. Byzantine attackers can
> costlessly replay your old transactions any time anyone reuses an
> address, even accidentally (which cannot be easily prevented since
> they can race).
>

With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
specify that they are to be signed without the previous UTXO's
value/amount. This means that, at worst, replay attacks can send the money
to the same place it was sent before (which in many cases is likely not be
a loss of funds), and only if the amount sent to the reused address is the
exact same as it was before. I don't think this is worse than an attacker
being able to mutate their transaction and extort a merchant who accepts
zero-conf transactions. Anyway, not signing the input ID wouldn't exactly
be the norm, there would be a defined set of flags for standard use cases.
Not signing the input TXID would only be used in specialized cases, such as
setting up micropayment channels.


> There are no free lunches;  the proposal linked to there is itself a
> game of wack-a-mole with assorted masking flags;


I agree that it is also a bit of wac-a-mole, but the defined space of
issues is possibly more limited here. There are only X number of things
that can be signed/not signed in a transaction, and the 'Build your own
nHashType' proposal enables you to fully specify which of those are being
signed. If you don't want to get burned by not fully signing your
transactions, then don't use the non-standard sighash flags.

many of which we have
> no notion of if they're useful for any particular application(s);


A few of the flags, indeed, may not ever be useful. But we can't predict
the future, and I think it's better to build in a more flexible solution
now than to wish we had more flexible nHashTypes later.

To the original point of this thread, hopefully the suggested proposal
won't be necessary as wallets will upgrade to use version 3 transactions
and the rules associated with them over time.

Best,
Stephen
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[Stephen Morse]

Hi William,

I personally prefer this solution, since it nails the problem
> completely with one simple and obvious change. The BIP 62 approach is
> more like a game of wac-a-mole.
>

The two are complementary, not competing. BIP62 prevents *non-signers* from
mutating the transactions, which is very important. The 'Build your own
nHashType' proposal enables chained transactions even in the face of
*signers* mutating the transaction. I believe that integrating both will
lead to the best defense against transaction malleability, and will enable
more complicated uses of chained transactions (such as micropayment
channels).

Best,
Stephen
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Build your own nHashType

[Stephen Morse]

Hi Mike,

Hi Stephen,
>
> It's an interesting idea. I'm not sure that all the combinations make
> sense. Excluding the connected output script or value but still signing the
> prev tx hash appears pointless: the script cannot change anyway, and you
> still need to know what it is to actually calculate the inputs to it, so
> what is the point of this?
>

That's a good point, maybe SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY and
SIGHASH_WITHOUT_PREV_VALUE should be assumed false, since you need the data
anyway. That gets the total number of flags down to 17. If we eliminate
SIGHASH_WITHOUT_TX_VERSION (I can't think of any good reason for this one),
then we're down to a 2-byte nHashType. SIGHASH_SIGN_STACK_ELEMENT could
also be removed, I'm not convinced of the usefulness of that one either.


>
> I also worry that quite a few of these combinations could be unexpectedly
> dangerous. If you don't sign the prevout hash or value and combine it with
> a regular pay-to-address output then you've effectively written a blank
> cheque that can be used by anyone, to claim any money ever sent to that
> address ... no? And then any p2p
>
node or miner could do so, making the transaction pretty useless.
>
> That isn't inherently a problem as long as people understand which
> combinations have what effects or cannot be used for various reasons. But
> it would need good documentation and careful thought to explore each
> possibility people might use.
>

I don't think it's quite a blank check, but it would enable replay attacks
in the form of sending the money to the same place it was sent before if an
address ever receives coins again. Almost like auto-forwarding addresses.
If, in addition, you signed with just that input and no outputs as well,
then you're basically forfeiting your rights to any coins sent to that
address.

It allows for some dangerous combinations, but we already have some
dangerous nHashTypes. e.g. SIGHASH_NONE | SIGHASH_ANYONECANPAY. Good
documentation and careful developers shouldn't have any issues if they use
a standard set of sighash flag combinations for their standard use cases.
But developers that need special combinations can now use them, so long as
they are careful and think things through.


>
> I'll leave the soft fork business to one side for now. I think any change
> in CHECKSIG or new version of it would likely be ready around the same time
> as the hard fork we need for changing the block size limit anyway, and it's
> much cleaner to do it that way.
>
> The most important change that we need in sighash calculation, IMO, is
> ensuring that you don't have to hash data over and over again without a
> good reason. The current sighash definition is unfortunate because it's
> possible to make small transactions that involve hashing huge amounts of
> data. It's not clear to me that your proposal fixes that: ideally there
> would be one exactly one sighash for one transaction no matter how many
> checksigs are involved in verifying it.
>
>
It's hard, though, because there is different data needs to be signed for
each input. Although, I suppose if you signed your input with
SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, and the
equivalent of SIGHASH_ALL, then the hash that needs to be signed would be
the same for all of your inputs. Strangely enough, I think we might have
just found use cases for the flags that we had nearly dismissed.

Another possibility would be to put the previous scriptPubKey and previous
output value at the END of the serialized transaction, so that you could
make use of some sort of a signature hash midstate. But that feels a little
messy. It sort of makes sense to have a base serialization for a
transaction and then append it with whatever input/output specific
information you have, but still, messy.

Is hashing transaction data once for each input really a huge bottleneck,
though? Do mobile devices have an issue with this?

Best,
Stephen
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Build your own nHashType

[Stephen Morse]

Seeking feedback on a proposal that will allow a transaction signer to
explicitly specify what is to be serialized for the signature hash. The
basic idea is to make the nHashType general enough that we won't need a new
sighash flag every time a new use case comes up.

If implemented into bitcoin (via a soft fork), this would make malleability
almost a non-issue (the TXID referenced by inputs just need to be updated
previous TX changes) and would enable hardware wallets to securely sign
without needing to download/process each transaction it spends from.

Please let me know your thoughts.

https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies

[Stephen Reed]

You might consider the dimension taken by the cooperative mining approach of AI 
Coin, an altcoin that will launch April 27. The coin is an embodiment of 
principles described in my whitepaper last May, "Bitcoin Cooperative Proof of 
Stake". 
http://arxiv.org/abs/1405.5741

Currently we do not use staking, as network-wide algorithmic trustworthiness 
provides the security directly. Network operations, although highly automated 
with intelligent software agents, has a human-in-the-loop for oversight.

Our innovation enables immediate settlement of transactions. Peers in our 
network cooperate, taking turns creating new blocks. There is single version of 
the blockchain which is appended to by a single peer, and is replicated by the 
other peers. Our peers wrap Bitcoind instances, controlling transaction and new 
block routing to form a scalable super peer topology. Peers have self-signed 
X.509 certificates which encrypt messages and prevent impersonation. The 
tamper-evident technology that secures Bitcoin's blockchain and transactions is 
extended to secure the entire network. Inspired by an idea published by Nick 
Szabo, our peers maintain tamper-evident logs which are replayed, verified and 
signed by other peers. Aside from the whitepaper, more current technical 
information can be found on our forum - where I would be glad to answer 
questions and debate skeptics - instead of responding in this list off topic. 

http://ai-cointalk.org

I would like thank those here and on IRC who last year encouraged me think 
outside the box.

-Steve

CTO AI Coin, Inc.
512.791.7960
http://ai-coin.org

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Stephen Morse]

I agree with Gregory Maxwell, I don't think it would be as easy as just
changing IsCoinBase(), since there are places where the code assumes that
the coinbase's vin doesn't spend any prevouts and/or has size 1. For
example, here
<https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L617-620> and
here <https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L785-L808>
.

I think the motivation behind the original suggestion is to have a way to
pay specific miners upon solving a block without risking possibly paying
other miners through pay-to-fee. What I'm not sure about, though, is why
not just send them a transaction once you see that the miner has solved a
block? Not a pay-to-fee transaction, a pay to pubkeyhash or whatever type
of transaction you need to make to send the miner some coins.

Although I don't completely understand the motivation for making such
transactions, maybe this would this work. Have outputs in the coinbase
transaction which have nValue == 0, then only apply the COINBASE_MATURITY
rule to spending coinbase outputs which have non-zero value. That way you
could make a transactions which is only valid after the miner specified
solves a block with the coinbase having the same TxID referenced by the new
transaction's input. It's still a hard fork, but might be easier than
allowing the coinbase to spend prevouts. I guess, at that point though, why
not just hard fork to allow the coinbase to spend prevouts...

Best,
Stephen

On Tue, Dec 30, 2014 at 1:28 PM, Gregory Maxwell  wrote:

> On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
>  wrote:
> > Slight off-topic:
> > That looks like an abuse of the VM. Even P2SH is an abuse of the VM.
> > Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a
> > simple change that goes along the lines of Satoshi's original design.
> > Bitcoin was a beautiful design, and extra complexity is making it ugly.
> > We need Bitcoin to be simple to understand for new programmers so they
> > can keep the project going. It doesn't help the project that one needs
> > to be a guru to code for Bitcoin.
>
> Sergio there is no "abuse" there,  OP_NOP3 in that case would be
> redefined to OP_COINBASE_FOO_CONSISTENCY.
>
> (I say FOO because it's not clear what rule you actually hope to apply
> there.)
>
> What you suggested has no purpose by itself: it would need an
> additional change which overlays functionality in order to actually do
> something. Such a change would likely be "ugly"-- it's easy to be
> elegant when you do nothing.
>
>
> --
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper

[Stephen Reed]

I completed a whitepaper for Bitcoin a proof-of-stake version which uses a 
single nomadic verifiable mint agent and distributed replication of a single 
blockchain by compensated full nodes to achieve 6-hop, sub-second transaction 
acknowledgement times. Plus it pays dividends to holders instead of wasting it 
on miners. Subsidized transaction fees are thus lower.

https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE


Because the code is not yet written, this idea is half-baked so to speak. 
Comments appreciated on my project thread, which will be a development diary. I 
plan a hard fork of the Bitcoin blockchain in early 2016, after a year of 
public system testing, and conditioned on wide approval.

https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403

-Steve

Stephen L. Reed 
Austin, Texas, USA 
512.791.7860--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof-of-Stake branch?

[Stephen Reed]

My understanding is that sidechains require merged mining support and that 
sidechains create no coinbase transactions themselves. When Bitcoin Core 
supports the two-way peg then I would update my source code branch to 
incorporate that or any other change that is released. Ideally, when sidechains 
can work with PoW Bitcoin, then those same sidechains should work without any 
changes with PoS Bitcoin running in my testnet.

I will be examining PPC, NXT and whitepapers for ideas that I can implement in 
such a way as the result can be called Bitcoin. The only difference would be 
the absence of wasteful Proof-of-Work, and the presence of mining rewards 
distributed to full nodes in proportion to the amount of bitcoin each is 
willing to expose to the network. Coin age is a good starting point. A 
reference peer-to-peer pool developed by me would be responsible for fairly 
distributing the mining rewards as daily dividend payments to PoS full node 
pool members.

In a few days, I plan to establish a Proof-of-Stake Bitcoin project thread in 
the Project Development sub-forum of Bitcointalk. We can continue the technical 
discussion there, starting with a list of principles.


Stephen L. Reed 
Austin, Texas, USA 
512.791.7860

On Friday, April 25, 2014 4:42 AM, Jeffrey Paul  wrote:

Are proof of stake blockchains compatible with the sidechain/two-way peg system 
invented by Greg (and maybe others - reports unclear)?
>
>http://letstalkbitcoin.com/blockchain-2-0-let-a-thousand-chains-blossom/
>
>It's my limited understanding that any sidechains in such a model are somewhat 
>cryptographically tied to the PoW system that bitcoin's chain uses. I am 
>seriously curious if alternate decentralized consensus algorithms (proof of 
>execution, proof of stake, et c) are compatible with the sidechain universe as 
>envisioned. 
>
>Perhaps someone with a deeper technical understanding could explain how, if 
>so, or if my incomplete hunch (that alternate consensus algorithms cannot 
>retain compatibility with Bitcoin in a two way peg model) is correct.
>
>These sorts of "alternate universe" altcoin experiments with different proof 
>models take on a different cost/benefit ratio if they can't ever interoperate 
>as sidechains, which is why I'm curious. 
>
>Best,
>-jp
>
>-- 
>Jeffrey Paul   +1 (312) 361-0355
>5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
>
>
>> On 25.04.2014, at 00:33, Troy Benjegerdes  wrote:
>> 
>> This also might be an interesting application of the side
>> chains concept Peter Todd has discussed.
>
>  

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Proof-of-Stake branch?

[Stephen Reed]

Hello all.

I understand that Proof-of-Stake as a replacement for Proof-of-Work is a 
prohibited yet disputed change to Bitcoin Core. I would like to create a 
Bitcoin branch that provides a sandboxed testbed for researching the best PoS 
implementations. In the years to come, perhaps circumstances might arise, such 
as shifting of user opinion as to whether PoS should be moved from the 
prohibited list to the hard-fork list.
-

A poll I conducted today on bitcointalk, 
https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing 
title suggests some minority support for Bitcoin Proof-of-Stake. I invite any 
of you to critically comment on that thread.

"Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full nodes 
outnumber existing Proof-of-Work full nodes by three-to-one. What is your 
choice?"

"I do not care or do not know enough." - 5 (16.1%) 
"I would download and run the existing Proof-of-Work program to fight the 
change." - 14 (45.2%) 
"I would download and run the new Proof-of-Stake program to favor the change. " 
- 12 (38.7%) 
Total Voters: 31 
-

Before I branch the source code and learn the proper way of doing things in 
this community, I ask you simply if creating the branch is harmful? My goal is 
to develop, test and document PoS, while exploring its vulnerabilities and 
fixing them in a transparent fashion.

Thanks for taking a bit of your time to read this message.

-Steve

Stephen L. Reed

Austin, Texas, USA
512.791.7860 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Blocksize and off-chain transactions

[Stephen Pair]

On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille wrote:

> But we cannot just drop support for old nodes. It is completely
> unreasonable to put the
> _majority_ of the network on a fork, without even as much as a discussion
> about it.
> "Oh, you didn't get the memo? The rules implemented in your client are
> outdated." - that
> is not how Bitcoin works: the network defines the rules.
> ...
> Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This
> is something
> that requires widespread community consensus - far more than just miners
> and developers


The way I've started thinking about it is that there is a market for
securing a payment network.  In that market you have consumers (users of
bitcoin) and providers (miners).  It's not clear to me that if the
overwhelming majority of miners stayed on 0.8 that the 0.7 fork wouldn't
have still won out in the long run because effectively what you would have
had is a situation where the providers abandon a large portion of their
customers (0.7 users) and start providing a service that is in much less
demand.  Would everyone have upgraded to 0.8?  Maybe, but maybe not.  Maybe
many people would have made the rational decision to stay on earlier
versions and the small minority of miners that choose to service the 0.7
fork could have earned more Bitcoin on that fork...and maybe in the long
run, the majority of miners on 0.8 would realize this situation and start
to trickle back over to the 0.7 fork.  The flip side of the equation is
that the users have a pretty compelling reasons to use the services of the
most secure network (less risk of double spends).  So, the users very well
could have made the rational decision to consume the services of the most
powerful network and made the switch to 0.8.

What happened in reality is that the majority of the mining community made
the rational decision to service the largest pool of customers (0.8 as well
as 0.7 and earlier users).  It was rational because the risk of servicing
only the 0.8 users would have been much greater.

Because of this dynamic, I doubt there would ever be multiple forks of any
consequence in permanent coexistence.  I would even go so far as to say
that at this point, a successful competitor to Bitcoin would have to arise
as a fork of the UTXOs in the block chain (even if the competitor didn't
even use a block chain).  That competitor might even have to begin life in
lock step co-existence with Bitcoin, recognizing all Bitcoin transactions
for some period of time while it attempts to gain market share.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

[Stephen Pair]

Instead of thinking in terms of blocking uneconomical transactions (how
would a node even determine what's economical?), what about thinking in
terms of paying for a feed of economical (i.e. profitable) transactions?
There is a market for fee bearing, profitable transactions...if there is no
one willing to pay to receive a transaction, then no one will bother
propagating it.  Such a system would make it possible to determine the
probability of confirmation in a given timeframe for a given fee.


On Tue, Mar 12, 2013 at 3:49 AM, Peter Todd  wrote:

> On Sat, Mar 09, 2013 at 11:31:55PM -0500, Peter Todd wrote:
> > As discussed endlessly data in the UTXO set is more costly, especially
> > in the long run, than transaction data itself. The fee system is per KB
> > in a block, and thus doesn't properly capture the long-term costs of
> > UTXO creation.
>
> There's been a lot of discussion about this issue, and many people have
> asked that Bitcoin not arbitrarily block interesting potential uses of
> provably unspendable txouts for data applications, and similarly
> spendable txouts representing assets. I've changed my hardline position
> and now think we should support all that stuff. However, there is one
> remaining class of txout not yet talked about, unspendable but not
> provably so txouts. For instance we could make the following a standard
> transaction type:
>
> scriptPubKey: OP_HASH160 <20 byte digest> OP_EQUALVERIFY 
> scriptSig: 
>
> Of course, usually the 20 byte digest would be picked randomly, but it
> might not be, and thus all validating nodes will always have a copy of
> the data. With the 10KB limit on script sizes you can fit 9974 bytes of
> data per transaction output with very little waste.
>
> A good application is timestamping, with the advantage over
> coinbase/merkle tree systems in that you don't have to wait until your
> timestamp confirms, or even store the timestamp at all. Another
> application, quite possible with large block sizes and hence cheap or
> free transactions, is secure data backups. In particular such a service,
> perhaps called Google Chain Storage, can offer the unique guarantee that
> you can know you're data is secure by simply performing a successful
> Bitcoin transaction.
>
> --
> 'peter'[:-1]@petertodd.org
>
>
> --
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Stephen Pair, Co-Founder, CTO

Does *your* website accept cash? bitpay.com

[image: bitpay-small]

ABC6 C11B BF75 9E2B FC6A  B3E0 7B96 40B2 CAC0 C158
<>--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

[Stephen Pair]

On Thu, Feb 14, 2013 at 1:07 AM, Peter Todd  wrote:

> On Wed, Feb 13, 2013 at 09:44:11PM -0500, Stephen Pair wrote:
> > One of the beauties of bitcoin is that the miners have a very strong
> > incentive to distribute as widely and as quickly as possible the blocks
> > they find...they also have a very strong incentive to hear about the
> blocks
> > that others find.  There will not be an issue with blocks being
> "jealously
>
> The idea that miners have a strong incentive to distribute blocks as
> widely and as quickly as possible is a serious misconception. The
> optimal situation for a miner is if they can guarantee their blocks
> would reach just over 50% of the overall hashing power, but no more. The
> reason is orphans.
>

Perhaps, but a miner trying to target just over 50% of the network will run
the very real risk that they'll only reach 49%.

What about the case for centralization if the block size remains capped?  I
see a far greater risk of centralization in that scenario than if the cap
were to be removed.  The reason is very simple, bitcoin would ultimately
become useful only for very high value, settlement transactions.  Only the
mega corporations and banks would be using it directly, everyone else would
be doing daily transacting in centrally issued currencies of one form or
another.  As the banks and mega corps learned about the utility of bitcoin
and began to use it en masse, they would start to take the whole network
off the public internet and put it on a higher speed and more reliable
backbone.  Those corporations would establish mining agreements among
themselves to ensure none of the participants could take over the system
and compromise it, while at the same time keeping the operational costs to
a minimum.  Bitcoin is now a great alternative to the wire transfer system,
but has no value to the average person wanted to have cheap and private
transactions over the Internet.  Maybe Litecoin starts to fill that niche.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

[Stephen Pair]

On Wed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell wrote:

> On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair  wrote:
>  >(by which I mean the fee or cost associated with the bandwidth and
> validation that a transaction requires) with some amount of profit.  This
> means that the relay node will not fetch and propagate those transactions
> whose fee is too small (unless there was some other fee structure outside
> the miners fee).
>
> The only fee-or-cost they're worrying about is their own marginal
> costs.  This says nothing about the externalized cost of the hundreds
> of thousands of other nodes which also must validate the block they
> produce, many of which are not miners— if we are well distributed— and
> thus don't have any way to monetize fees.


But this is exactly the point I'm making...the thousands of other nodes do
have a way to monetize the work they do in relaying and validating
transactions.  Miners will pay them for the prompt delivery of profitable
transactions.  So, in effect, the block reward and transactions fees will
be paying not only for the mining work, but also the validation and
relaying work.  Such nodes would get paid in micro transactions from the
miners for that service.  This would be one way that full nodes could
operate profitably (there may be many other indirect ways).  I think
decentralization is pretty much guaranteed because anyone with profitable
transactions would only deliver them to miners or other peers that are
willing to pay for them.  This is in effect a rebate of a portion of the
transaction fee to the network for delivering the transaction to the miner.
 Wallet software might cut out the middle men and submit directly to
miners...other nodes with access to a large amounts of transactions and
good infrastructure might be able to reduce the infrastructure a miner has
to maintain and deliver a larger volume of fee bearing transactions.  And
everyone would have a very good sense of the market price for transaction
fees for a given level of service (speed of block inclusion).

The other side of it is that wallets will need to receive valid, wallet
relevant transactions.  They may also need to connect with multiple nodes
for independent verification of the validity of their transactions.  But I
think that cost would be more than covered with fees they include in any
transactions they originate (but if they rarely originate fee bearing
transactions, they might need to pay something to keep receiving an
incoming transaction feed...it could be as simple as an artificial
transaction they pay to themselves, but that includes a fee).

A while back everyone was worried that a tragedy of the commons situation
would develop whereby all transactions that carried any fee at all would
get included by miners, thus destroying the mining business as the block
reward diminished...but I think the cost involved in relaying and
validating transactions ensures that situation won't develop...mining nodes
will have to only connect to relaying and validating nodes such that they
can filter down the volume to something that's profitable for them...and
relaying and validating nodes will ignore transactions with fees that are
too low to be profitable.

It will be a few years before we see the kinds of volumes that will force
this infrastructure to evolve...I don't think there is an issue with
lifting or even eliminating the block size limit...there may be a point at
which the volume is sufficient enough that full nodes start dropping
offline...and the nodes that do remain will have to increasingly find ways
to cover their costs...which will be a forcing function for solutions
similar to these.  There is no doubt that Bitcoin will be a lot more
valuable if it can handle very large volumes of transactions.

Also, Mike Hearn has done some analysis that suggests that even at Visa
scales, the hardware requirements to do full validation and relay may not
all that substantial (enabling lots of small, but profitable, node
operators and low transactions fees...the key to profitability would be
access to a sufficient number of original transactions bearing fees).
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

[Stephen Pair]

On Wed, Feb 13, 2013 at 7:28 PM, Gregory Maxwell  wrote:

> 
>

I understand your arguments, but don't agree with many of your conclusions.

The requirement for everyone to hear the history doesn't get talked
> about much


One of the beauties of bitcoin is that the miners have a very strong
incentive to distribute as widely and as quickly as possible the blocks
they find...they also have a very strong incentive to hear about the blocks
that others find.  There will not be an issue with blocks being "jealously
guarded"...what miners will want is a good feed of transactions that they
want to mine.  They will be willing to pay for those feeds (either by
sharing the proceeds with highly connected "relay" nodes or by operating
highly connected nodes themselves).  Because miners will only want to pay
to get a feed of profitable transactions, they will not pay to receive
transactions whose miner fee does not cover the "relay" fee (by which I
mean the fee or cost associated with the bandwidth and validation that a
transaction requires) with some amount of profit.  This means that the
relay node will not fetch and propagate those transactions whose fee is too
small (unless there was some other fee structure outside the miners fee).

These are relatively easy businesses to operate...which means there will be
a lot of them and they'll compete on fees (with wallets automatically
discovering the cheapest of the services).  If the businesses of relaying
and mining ever became too centralized, other businesses with a vested
interest in the success of bitcoin would take the necessary steps to ensure
there remained adequate decentralization.

It's important to remember that the centralization that currently exists in
the fiat currency world benefits one set of businesses to the detriment of
many others.  Having a functioning and trustworthy payment system benefits
far more people and businesses than a centralized system would.

It is good to be wary of these potential issues, but I don't see how the
economics are likely to yield the outcome you fear.  And, really, there's
not a lot that can be done to prevent economics from dictating the ultimate
outcome.  In fact, what I write above is not so much about what I think
*should* be built, it's more about what I *predict* will be built.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

[Stephen Pair]

On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen wrote:

> On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell wrote:
>
>>  Since, in the long run,
>> Bitcoin can't meet its security and decenteralization promises without
>> blockspace scarcity to drive non-trivial fees and without scaling
>> limits to keep it decenteralized— it's not a change that could be made
>> more lightly than changing the supply of coin.
>>
>
> I disagree with Gregory on this.  I believe that Bitcoin CAN meet its
> security and decentralization promises without any hard limit on block
> size.
>
> I had a fruitful discussion about this with an economist friend this
> weekend, and I'll eventually getting around to writing up why I believe
> raising the block size limit will not be a problem.


If you've already validated the majority of transactions in a block, isn't
validating the block not all that compute intensive?  Thus, it's really not
blocks that should be used to impose any sort of scarcity, but rather it's
the costs associated with the validation and propagation of the
transactions themselves...which is the way it should be.

When I think about issues like this, I like to remind myself that the mesh
network isn't really an essential part of Bitcoin.  It is a way to
disseminate transactions and blocks, but it's by no means the only possible
way and could certainly be improved in various ways.  Nodes can at some
point start to charge fees to collect and distribute transactions and
blocks.  Collectives of such nodes could pool together fees to ensure
connected nodes can propagate and hear about transactions and blocks.
 These nodes would charge based on the bandwidth and the work required to
validate transactions.  They would also charge for the propagation of
blocks based on the work required to validate them.  Miners would of course
have a lot of incentive to pay for such services since they will want to
get access to as many fee bearing transactions as possible (and filter out
the transactions they don't want to include in blocks).  They will also
want the blocks to ensure they're always building on the latest valid
block.  That in turn would give these relay nodes a window into the fees
needed to ensure fast inclusion into the block chain (something that
wallets could use to automatically set fees on transactions).

Note, I think the bitcoin protocol might actually be ideally suited for
this type of thing...nodes would broadcast INV messages all day long, but
as soon as one of your peers wants the actual transaction or block, well,
then you have to pay up.  Two relay nodes sending transactions between each
other would pay each other when they have to download the transaction
body...if they trade roughly equal amounts of transactions, they wouldn't
end up owing each other anything...for a given transaction they would pull
the data exactly, but would then turn around and provide that transaction
to many connected peers, earning a fee for each delivery.

P.S. such a fee structure would address the spam issue with economics
rather than rules about spammy transactions

P.P.S. micropayment channels could be used as the payment method for nodes
that validate and relay transactions...this would actually be a very good
first use of that technology (people have talked about micropayment
channels for renting bandwidth...why not use them to pay for the bandwidth
and CPU needed to validate and relay transactions)
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
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

[Stephen Pair]

The more I think about this topic, the more I think the first task at hand
is to implement secure, private messaging...the nature of any messages
(payment requests or otherwise) sent between wallets is such that it needs
to be secured.  And the great thing is that it's easy to do and you don't
need to solve the PKI problem.  Have the wallet maintain one or more ECC
key pairs for the purposes of signing and encrypting messages.  Allow these
to be shared between wallets, or exported/imported, etc.  You can punt on
the whole topic of verifying the others' public keys using PKI (I mean,
people use bitcoin addresses today without the use of any formal or
explicit PKI to verify them...people will make do without it for
communications keys just fine...and they can always use PGP or other PKI if
they feel the need...most people would just pick up the phone to verify a
friend's public key)...this also doesn't preclude the use of X.509 for the
merchant/customer scenario...

For a payment protocol, you could do something like this: use https & ssl
certificates/CAs as one method of obtaining an ECC public key...pki_type
could be "https" and pki_bytes could be a url for the https location to
download the ECC public key.  The software would reject (or warn) if the
SSL certificate isn't considered valid by the normal CA validation process.
 The wallet would not necessarily need to permanently store ECC public keys
obtained in this manner.  This approach doesn't require people to obtain
new certificates just for bitcoin.

In fact, there would be very little difference to the proposed payments
protocol if this approach were taken...instead of using X.509 directly for
signing and encrypting messages, you are using it for signing and
encrypting the ECC public key exchange.  And this allows people that don't
have web servers or SSL certificates to exchange their ECC public keys by
other means and be able to use this payment protocol as well as any others
that one could imagine.  So, I actually think this is a better way of
keeping PKI out of the scope of the proposal.

Payment requests are just one kind of messaging between wallets.  I've also
mentioned the "cheques" feature.  I'm sure there are many more
possibilities.  Having a uniform method of securing messages sent between
wallets (that doesn't depend on external tools) would be a great step
forward IMO.
--
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

[Stephen Pair]

On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn  wrote:

> > you may find yourself in a situation needing to parse a protobuf
> > message in a web browser
> Nothing stops you converting them into whatever form you want on the
> server side. If you don't care about the signature checking then it's
> no problem to use a server. If you do then you'd need to ship all the
> code for verifying signatures that to the client anyway, at which
> point a small protobuf parser is hardly a deal killer.


No, it's not a killer...just a hassle.  JSON is convenient and ubiquitous
and there is something to be said for that (and I wanted to point out that
the JOSE objection was invalid).  Protobufs are nice and efficient, but who
cares.  You're talking about direct communications rather than something
that will be bounced around every node in the mesh network.  I don't really
care much either way, it's not worth debating.  I'm just thankful no one is
arguing for XML or IIOP.  :)

> ...like what about the casual user that wants to create a payment request
> to
> > send to their friend over email
>
> They can send an unsigned payment request. Note that if you mail it as
> an attachment from a competent, up to date email provider then the
> attachment isn't really unsigned. The whole thing is covered by the
> emails DKIM signature which is applied transparently by the ESP. If
> the signature fails to verify then the mail client can show that or
> treat the mail differently (as Gmail does). This is easy to use for
> the end user - they don't have to think about cryptography or PKI. As
> long as their email account is secure then they can send signed mails
> asserting to their identity.
>

This leaves too much to chance for my taste.  Forget email, what about
jabber, ICQ, skype, IRC?  Email is just one communications medium, there
are many others for which there would be no assurance that the payment
request hasn't been tampered with.  You could at a minimum allow a person
to create a normal ECC key, but have it used as an identity in
communications rather than a payment address.  You store it in a separate
file in ~/.bitcoin/id  ...you don't have to solve the whole set of PKI
problems, people could exchange identities using any secure channel they
are comfortable with (email + phone verification of a short hash id would
be sufficient).  In another scenario, an id could be made available over
https, using the normal SSL certificate and CA infrastructure to verify
authenticity.  This way all messages could be signed and/or encrypted
without the user having to go out of their way to use external tools or
infrastructure that is often not very user friendly.  You also need
encryption for the "cheque" feature...asking people to use GPG would be too
much of a burden (and email DKIM doesn't offer encryption).

>>> wandering off topic >>>
Indeed, "cheques" could become the dominant method of person to person
payments...first, you would obtain someone's id, which you might already
have on file (rather than obtaining a bitcoin address), then you would
generate a "cheque" for the amount desired and send it to them...the
recipient then has full control over what address they want to sweep the
funds to as well as whether they'd like to include a miner fee to speed the
confirmation along. Despite the fact that you may send many payments to the
same identity, the only thing showing up on the p2p network and the block
chain is the one time use address for the cheque and the recipient's wallet
address.  This means the recipient has much more control over the address
policy used (compared with simply giving out a bitcoin address that may be
reused).
<<<

> Refund addresses...this is not going to be as useful as people might
> > think...most refunds that bitpay needs to process happen days or even
> months
> > after the initial purchase
>
> Useful feedback, thanks. Still, there may be other types of merchants
> for whom it's useful, and many users won't change their wallet. It
> certainly simplifies things if you can present the refund address and
> give a one-click option to use it. If the user wants to use a
> different address, then they can go onto the slow/complicated path.
>
> This current spec deliberately punts on the topic of identifying end
> users. It's a difficult problem.
>

I know, but as I was responding, I began to realize this is a mistake.
 It's worthwhile to tackle that problem first...if done right, it would pay
huge dividends.  Also, identity is one thing, an elaborate trust based
identity verification system (like CA's) is a whole other thing.  I think
the former is pretty simple actually...and it's all that's really needed
for the time being (as I alluded, a bitcoin identity could be communicated
or verified using the existing X.509/CA infrastructure if desired...you
could also use the PGP infrastructure).


> > I like the use of merchant_data...this means that you no longer will
> need a
> > unique bitcoin address for every in

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

[Stephen Pair]

Here are my (mostly half baked) thoughts on the payments protocol proposal.

My first observation is that the proposal is too heavily oriented around a
merchant/customer interaction.  I think it's equally important to consider
the person to person scenarios.  It would be very cool if people could
send/receive payments by copying and pasting stuff on facebook or email
(you can kind of do it now, but it's not safe unless you go to
extraordinary lengths using PGP signatures and the like).

Protobufs vs JSON: Protobufs are fine, although I will mention that the
serialization/JOSE arguments are irrelevant...you only need that if you
need a reliable way of signing an in memory object structure...in this case
you would be signing a serialized form of the object...the recipient
doesn't have to be able to reproduce the serialized form, they only need to
verify the signature on the already serialized bytes...I see protobufs as a
good serialization format for storage, while JSON being more practical for
communications in a web oriented environment...with protobufs & a web
wallet, you may find yourself in a situation needing to parse a protobuf
message in a web browser...the protobuf parsing and serializing code is
just going to add bloat to the web page...personally, I probably would have
gone with JSON, but hey, I'm not writing the code.

X.509 - nasty, but maybe ok ...as long as you can add root CAs to your
Bitcoin client or explicitly trust a certificate, I don't see that it poses
any privacy issues...but there are some other things to think about here
...like what about the casual user that wants to create a payment request
to send to their friend over email (wrapped in a clear text block similar
to PGP...it could also be sent as a file attachment)?  Are you now
requiring them to go and setup a certificate?  Btw, I really like the use
of a payment request in this manner because you have a signed payment
request that can be verified against an address book of known identities.
 This could be much safer than simply emailing an unsigned bitcoin address
around.

Refund addresses...this is not going to be as useful as people might
think...most refunds that bitpay needs to process happen days or even
months after the initial purchase...in that span of time, people can change
wallets, rendering such a refund address useless...so, as I think about the
situation, we would still need to contact the buyer to confirm a refund
address anyway.  What we really need is to verify the identity of the
person we're potentially sending the refund to...we need a way of
determining that the person we're sending the refund to is the same person
that paid the original invoice.  Bitcoin addresses are identities, but they
are too low level.  HD wallets come to mind...the top level or intermediate
levels of a deterministic hierarchy could be used for identity
purposes...but it also seems like it might be conflating payments and
identity (which for many reasons you might want to keep separate).  What if
bitcoin clients could manage one or more identities used for the purpose of
communications?  You could have a bitcoin identity file that could be used
by multiple wallets.  These identities would be used for signing messages
and verifying the authenticity of communications...when sending a payment,
instead of a refund address, you would include one of these identities
which could later be used to confirm a refund address.  In fact, the refund
would be processed by the buyer generating another payment request message
signed by the identity used in the original payment.

People would understand that their identities are important for
communications and they would keep those even when changing to new wallets
and such (identities could be stored in ~/.bitcoin/id or something
(encrypted of course)).

There are some other interesting possibilities if messaging and identities
are done right...for example, I could add "check" feature (analogous to
paper checks).  It would work like this...you create a transaction that
spends to a newly generated address...you put that transaction, along with
the private key into an encrypted container (sent to the identity of the
person you want to pay).  The recipient can open it and their wallet would
go ahead and generate and broadcast a transaction moving the funds into
their wallet (optionally including a fee).  But, if the recipient never
cashes the check, the sender could pull those funds back after a certain
period of time.  This also eliminates the possibility of accidentally
sending the funds to the wrong address (or an old address) and the bitcoins
being forever lost...the recipient can sweep the transaction into any
wallet of their choice.

As I'm writing this, I'm beginning to wonder if the identity management
problem is unavoidable.  Maybe that needs to be dealt with first.  It would
enable so many other interesting possibilities.

I like the use of merchant_data...this means that you no longer will nee

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

[Stephen Pair]

On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn  wrote:

> Second thing, it's best to carefully separate "anonymity" from
> "privacy". Privacy is supposed to be a feature of the system (it says
> so in Satoshis paper) because people demand it. If I loan a tenner to
> my friend and he is able to find out what I earned last month, then
> that trade was neither anonymous nor private. In this case I want
> privacy but anonymity isn't useful. Mixing up anonymity with privacy
> is not only a public relations problem, but can lead to confusion from
> users when they, eg, try and buy Bitcoins from an exchange and are
> asked to provide ID proofs.


I would like to second this point...privacy is essential because the market
demands it.  If Bitcoin doesn't do it well (and I would argue that it
doesn't today), then eventually a competitor to Bitcoin will do it better
and that would be the beginning of the end for Bitcoin.  Debates about
whether it was or wasn't a core feature are pointless.
--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] test (ignore)

[Stephen Pair]

Test post.
--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development