On Sun, Apr 26, 2015 at 03:01:10AM +0300, s7r wrote:
It's true that malleability is not the end of the world, but it is
annoying for contracts and micropayment channels, especially refunds
spending the fund tx before it is even in the blockchain, relying
solely on its txid.
Agreed, needing
Payment codes establish the identity of the payer and allow for simpler
methods for identifying the payee, and automatically provide the payee with
the information they need to send a refund.
If merchants and customers were using payment codes, they would not need
the BIP70 equivalents.
I think
On Sat, Apr 25, 2015 at 11:51:37PM -0700, Joseph Poon wrote:
signs the sigScript of the redeemed output.
Err, typo, I meant:
... signs the *scriptPubKey* of the redeemed output.
--
Joseph Poon
--
One dashboard for
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote:
There's another possibility that could keep the utxo out of Script
verification:
class CTxIn
{
public:
COutPoint prevout;
CScript scriptSig;
uint32_t nSequence;
}
could turn into:
class CTxIn
{
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd p...@petertodd.org wrote:
Thus we have a few possibilities:
1) RCLTV against nLockTime
Needs a minimum age COINBASE_MATURITY to be safe.
2) RCLTV against current block height/time
Completely reorg safe.
Yes, can we call this one OP_MATURITY
Could you maybe write a short bit of text comparing this approach to
extending BIP70 and combining it with a simple Subspace style
store-and-forward network?
--
One dashboard for servers and applications across
On 4/22/2015 1:03 PM, Kalle Rosenbaum wrote:
I've built a proof-of-concept for Proof of Payment. It's available at
http://www.rosenbaum.se:8080. The site contains links to the source
code for both the server and a Mycelium fork as well as pre-built apk:s.
There are several scenarios in
7 matches
Mail list logo
