Bitcoin price today, BTC marketcap, chart, and info ...

Does RBF implementation change the likelihood that a "non-RBF" (max value nSequence) transaction can be double-spent? /r/Bitcoin

Does RBF implementation change the likelihood that a submitted by BitcoinAllBot to BitcoinAll [link] [comments]

12-13 15:04 - 'Read this went the opposite way' (self.Bitcoin) by /u/fukya40 removed from /r/Bitcoin within 38-48min

'''
// Copyright (c) 2008 Satoshi Nakamoto // // Permission is hereby granted, free of charge, to any person obtaining a copy // of this software and associated documentation files (the "Software"), to deal // in the Software without restriction, including without limitation the rights // to use, copy, modify, merge, publish, distribute, sublicense, and/or sell // copies of the Software, and to permit persons to whom the Software is // furnished to do so, subject to the following conditions: // // The above copyright notice and this permission notice shall be included in // all copies or substantial portions of the Software. // // THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR // IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, // FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT // SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR // OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS // IN THE SOFTWARE.
class COutPoint; class CInPoint; class CDiskTxPos; class CCoinBase; class CTxIn; class CTxOut; class CTransaction; class CBlock; class CBlockIndex; class CWalletTx; class CKeyItem;
static const unsigned int MAX_SIZE = 0x02000000; static const int64 COIN = 1000000; static const int64 CENT = 10000; static const int64 TRANSACTIONFEE = 1 * CENT; /// change this to a user options setting, optional fee can be zero ///static const unsigned int MINPROOFOFWORK = 40; /// need to decide the right difficulty to start with static const unsigned int MINPROOFOFWORK = 20; /// ridiculously easy for testing
extern map mapBlockIndex; extern const uint256 hashGenesisBlock; extern CBlockIndex* pindexGenesisBlock; extern int nBestHeight; extern CBlockIndex* pindexBest; extern unsigned int nTransactionsUpdated; extern int fGenerateBitcoins;
FILE* OpenBlockFile(unsigned int nFile, unsigned int nBlockPos, const char* pszMode="rb"); FILE* AppendBlockFile(unsigned int& nFileRet); bool AddKey(const CKey& key); vector GenerateNewKey(); bool AddToWallet(const CWalletTx& wtxIn); void ReacceptWalletTransactions(); void RelayWalletTransactions(); bool LoadBlockIndex(bool fAllowNew=true); bool BitcoinMiner(); bool ProcessMessages(CNode* pfrom); bool ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv); bool SendMessages(CNode* pto); int64 CountMoney(); bool CreateTransaction(CScript scriptPubKey, int64 nValue, CWalletTx& txNew); bool SendMoney(CScript scriptPubKey, int64 nValue, CWalletTx& wtxNew);
class CDiskTxPos { public: unsigned int nFile; unsigned int nBlockPos; unsigned int nTxPos;
CDiskTxPos() { SetNull(); }
CDiskTxPos(unsigned int nFileIn, unsigned int nBlockPosIn, unsigned int nTxPosIn) { nFile = nFileIn; nBlockPos = nBlockPosIn; nTxPos = nTxPosIn; }
IMPLEMENT_SERIALIZE( READWRITE(FLATDATA(*this)); ) void SetNull() { nFile = -1; nBlockPos = 0; nTxPos = 0; } bool IsNull() const { return (nFile == -1); }
friend bool operator==(const CDiskTxPos& a, const CDiskTxPos& b) { return (a.nFile == b.nFile && a.nBlockPos == b.nBlockPos && a.nTxPos == b.nTxPos); }
friend bool operator!=(const CDiskTxPos& a, const CDiskTxPos& b) { return !(a == b); }
void print() const { if (IsNull()) printf("null"); else printf("(nFile=%d, nBlockPos=%d, nTxPos=%d)", nFile, nBlockPos, nTxPos); } };
class CInPoint { public: CTransaction* ptx; unsigned int n;
CInPoint() { SetNull(); } CInPoint(CTransaction* ptxIn, unsigned int nIn) { ptx = ptxIn; n = nIn; } void SetNull() { ptx = NULL; n = -1; } bool IsNull() const { return (ptx == NULL && n == -1); } };
class COutPoint { public: uint256 hash; unsigned int n;
COutPoint() { SetNull(); } COutPoint(uint256 hashIn, unsigned int nIn) { hash = hashIn; n = nIn; } IMPLEMENT_SERIALIZE( READWRITE(FLATDATA(*this)); ) void SetNull() { hash = 0; n = -1; } bool IsNull() const { return (hash == 0 && n == -1); }
friend bool operator<(const COutPoint& a, const COutPoint& b) { return (a.hash < b.hash || (a.hash == b.hash && a.n < b.n)); }
friend bool operator==(const COutPoint& a, const COutPoint& b) { return (a.hash == b.hash && a.n == b.n); }
friend bool operator!=(const COutPoint& a, const COutPoint& b) { return !(a == b); }
void print() const { printf("COutPoint(%s, %d)", hash.ToString().substr(0,6).c_str(), n); } };
// // An input of a transaction. It contains the location of the previous // transaction's output that it claims and a signature that matches the // output's public key. // class CTxIn { public: COutPoint prevout; CScript scriptSig;
CTxIn() { }
CTxIn(COutPoint prevoutIn, CScript scriptSigIn) { prevout = prevoutIn; scriptSig = scriptSigIn; }
CTxIn(uint256 hashPrevTx, unsigned int nOut, CScript scriptSigIn) { prevout = COutPoint(hashPrevTx, nOut); scriptSig = scriptSigIn; }
IMPLEMENT_SERIALIZE ( READWRITE(prevout); READWRITE(scriptSig); )
bool IsPrevInMainChain() const { return CTxDB("r").ContainsTx(prevout.hash); }
friend bool operator==(const CTxIn& a, const CTxIn& b) { return (a.prevout == b.prevout && a.scriptSig == b.scriptSig); }
friend bool operator!=(const CTxIn& a, const CTxIn& b) { return !(a == b); }
void print() const { printf("CTxIn("); prevout.print(); if (prevout.IsNull()) { printf(", coinbase %s)\n", HexStr(scriptSig.begin(), scriptSig.end(), false).c_str()); } else { if (scriptSig.size() >= 6) printf(", scriptSig=%02x%02x", scriptSig[4], scriptSig[5]); printf(")\n"); } }
bool IsMine() const; int64 GetDebit() const; };
// // An output of a transaction. It contains the public key that the next input // must be able to sign with to claim it. // class CTxOut { public: int64 nValue; unsigned int nSequence; CScript scriptPubKey;
// disk only CDiskTxPos posNext; //// so far this is only used as a flag, nothing uses the location
public: CTxOut() { nValue = 0; nSequence = UINT_MAX; }
CTxOut(int64 nValueIn, CScript scriptPubKeyIn, int nSequenceIn=UINT_MAX) { nValue = nValueIn; scriptPubKey = scriptPubKeyIn; nSequence = nSequenceIn; }
IMPLEMENT_SERIALIZE ( READWRITE(nValue); READWRITE(nSequence); READWRITE(scriptPubKey); if (nType & SER_DISK) READWRITE(posNext); )
uint256 GetHash() const { return SerializeHash(*this); }
bool IsFinal() const { return (nSequence == UINT_MAX); }
bool IsMine() const { return ::IsMine(scriptPubKey); }
int64 GetCredit() const { if (IsMine()) return nValue; return 0; }
friend bool operator==(const CTxOut& a, const CTxOut& b) { return (a.nValue == b.nValue && a.nSequence == b.nSequence && a.scriptPubKey == b.scriptPubKey); }
friend bool operator!=(const CTxOut& a, const CTxOut& b) { return !(a == b); }
void print() const { if (scriptPubKey.size() >= 6) printf("CTxOut(nValue=%I64d, nSequence=%u, scriptPubKey=%02x%02x, posNext=", nValue, nSequence, scriptPubKey[4], scriptPubKey[5]); posNext.print(); printf(")\n"); } };
// // The basic transaction that is broadcasted on the network and contained in // blocks. A transaction can contain multiple inputs and outputs. // class CTransaction { public: vector vin; vector vout; unsigned int nLockTime;
CTransaction() { SetNull(); }
IMPLEMENT_SERIALIZE ( if (!(nType & SER_GETHASH)) READWRITE(nVersion);
// Set version on stream for writing back same version if (fRead && s.nVersion == -1) s.nVersion = nVersion;
READWRITE(vin); READWRITE(vout); READWRITE(nLockTime); )
void SetNull() { vin.clear(); vout.clear(); nLockTime = 0; }
bool IsNull() const { return (vin.empty() && vout.empty()); }
uint256 GetHash() const { return SerializeHash(*this); }
bool AllPrevInMainChain() const { foreach(const CTxIn& txin, vin) if (!txin.IsPrevInMainChain()) return false; return true; }
bool IsFinal() const { if (nLockTime == 0) return true; if (nLockTime < GetAdjustedTime()) return true; foreach(const CTxOut& txout, vout) if (!txout.IsFinal()) return false; return true; }
bool IsUpdate(const CTransaction& b) const { if (vin.size() != b.vin.size() || vout.size() != b.vout.size()) return false; for (int i = 0; i < vin.size(); i++) if (vin[i].prevout != b.vin[i].prevout) return false;
bool fNewer = false; unsigned int nLowest = UINT_MAX; for (int i = 0; i < vout.size(); i++) { if (vout[i].nSequence != b.vout[i].nSequence) { if (vout[i].nSequence <= nLowest) { fNewer = false; nLowest = vout[i].nSequence; } if (b.vout[i].nSequence < nLowest) { fNewer = true; nLowest = b.vout[i].nSequence; } } } return fNewer; }
bool IsCoinBase() const { return (vin.size() == 1 && vin[0].prevout.IsNull()); }
bool CheckTransaction() const { // Basic checks that don't depend on any context if (vin.empty() || vout.empty()) return false;
// Check for negative values int64 nValueOut = 0; foreach(const CTxOut& txout, vout) { if (txout.nValue < 0) return false; nValueOut += txout.nValue; }
if (IsCoinBase()) { if (vin[0].scriptSig.size() > 100) return false; } else { foreach(const CTxIn& txin, vin) if (txin.prevout.IsNull()) return false; }
return true; }
bool IsMine() const { foreach(const CTxOut& txout, vout) if (txout.IsMine()) return true; return false; }
int64 GetDebit() const { int64 nDebit = 0; foreach(const CTxIn& txin, vin) nDebit += txin.GetDebit(); return nDebit; }
int64 GetCredit() const { int64 nCredit = 0; foreach(const CTxOut& txout, vout) nCredit += txout.GetCredit(); return nCredit; }
int64 GetValueOut() const { int64 nValueOut = 0; foreach(const CTxOut& txout, vout) { if (txout.nValue < 0) throw runtime_error("CTransaction::GetValueOut() : negative value"); nValueOut += txout.nValue; } return nValueOut; }
bool ReadFromDisk(CDiskTxPos pos, FILE** pfileRet=NULL) { CAutoFile filein = OpenBlockFile(pos.nFile, 0, pfileRet ? "rb+" : "rb"); if (!filein) return false;
// Read transaction if (fseek(filein, pos.nTxPos, SEEK_SET) != 0) return false; filein >> *this;
// Return file pointer if (pfileRet) { if (fseek(filein, pos.nTxPos, SEEK_SET) != 0) return false; *pfileRet = filein.release(); } return true; }
friend bool operator==(const CTransaction& a, const CTransaction& b) { return (a.vin == b.vin && a.vout == b.vout && a.nLockTime == b.nLockTime); }
friend bool operator!=(const CTransaction& a, const CTransaction& b) { return !(a == b); }
void print() const { printf("CTransaction(vin.size=%d, vout.size=%d, nLockTime=%d)\n", vin.size(), vout.size(), nLockTime); for (int i = 0; i < vin.size(); i++) { printf(" "); vin[i].print(); } for (int i = 0; i < vout.size(); i++) { printf(" "); vout[i].print(); } }
bool TestDisconnectInputs(CTxDB& txdb, map& mapTestPool) { return DisconnectInputs(txdb, mapTestPool, true); }
bool TestConnectInputs(CTxDB& txdb, map& mapTestPool, bool fMemoryTx, bool fIgnoreDiskConflicts, int64& nFees) { return ConnectInputs(txdb, mapTestPool, CDiskTxPos(1, 1, 1), 0, true, fMemoryTx, fIgnoreDiskConflicts, nFees); }
bool DisconnectInputs(CTxDB& txdb) { static map mapTestPool; return DisconnectInputs(txdb, mapTestPool, false); }
bool ConnectInputs(CTxDB& txdb, CDiskTxPos posThisTx, int nHeight) { static map mapTestPool; int64 nFees; return ConnectInputs(txdb, mapTestPool, posThisTx, nHeight, false, false, false, nFees); }
private: bool DisconnectInputs(CTxDB& txdb, map& mapTestPool, bool fTest); bool ConnectInputs(CTxDB& txdb, map& mapTestPool, CDiskTxPos posThisTx, int nHeight, bool fTest, bool fMemoryTx, bool fIgnoreDiskConflicts, int64& nFees);
public: bool AcceptTransaction(CTxDB& txdb, bool fCheckInputs=true); bool AcceptTransaction() { CTxDB txdb("r"); return AcceptTransaction(txdb); } bool ClientConnectInputs(); };
// // A transaction with a merkle branch linking it to the timechain // class CMerkleTx : public CTransaction { public: uint256 hashBlock; vector vMerkleBranch; int nIndex;
CMerkleTx() { Init(); }
CMerkleTx(const CTransaction& txIn) : CTransaction(txIn) { Init(); }
void Init() { hashBlock = 0; nIndex = -1; }
IMPLEMENT_SERIALIZE ( nSerSize += SerReadWrite(s, (CTransaction)this, nType, nVersion, ser_action); if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(hashBlock); READWRITE(vMerkleBranch); READWRITE(nIndex); )
int SetMerkleBranch(); int IsInMainChain() const; bool AcceptTransaction(CTxDB& txdb, bool fCheckInputs=true); bool AcceptTransaction() { CTxDB txdb("r"); return AcceptTransaction(txdb); } };
// // A transaction with a bunch of additional info that only the owner cares // about. It includes any unrecorded transactions needed to link it back // to the timechain. // class CWalletTx : public CMerkleTx { public: vector vtxPrev; map mapValue; vector > vOrderForm; unsigned int nTime; char fFromMe; char fSpent;
//// probably need to sign the order info so know it came from payer
CWalletTx() { Init(); }
CWalletTx(const CMerkleTx& txIn) : CMerkleTx(txIn) { Init(); }
CWalletTx(const CTransaction& txIn) : CMerkleTx(txIn) { Init(); }
void Init() { nTime = 0; fFromMe = false; fSpent = false; }
IMPLEMENT_SERIALIZE ( /// would be nice for it to return the version number it reads, maybe use a reference nSerSize += SerReadWrite(s, (CMerkleTx)this, nType, nVersion, ser_action); if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(vtxPrev); READWRITE(mapValue); READWRITE(vOrderForm); READWRITE(nTime); READWRITE(fFromMe); READWRITE(fSpent); )
bool WriteToDisk() { return CWalletDB().WriteTx(GetHash(), *this); }
void AddSupportingTransactions(CTxDB& txdb); void AddSupportingTransactions() { CTxDB txdb("r"); AddSupportingTransactions(txdb); }
bool AcceptWalletTransaction(CTxDB& txdb, bool fCheckInputs=true); bool AcceptWalletTransaction() { CTxDB txdb("r"); return AcceptWalletTransaction(txdb); }
void RelayWalletTransaction(CTxDB& txdb); void RelayWalletTransaction() { CTxDB txdb("r"); RelayWalletTransaction(txdb); } };
// // Nodes collect new transactions into a block, hash them into a hash tree, // and scan through nonce values to make the block's hash satisfy proof-of-work // requirements. When they solve the proof-of-work, they broadcast the block // to everyone and the block is added to the timechain. The first transaction // in the block is a special one that creates a new coin owned by the creator // of the block. // // Blocks are appended to blk0001.dat files on disk. Their location on disk // is indexed by CBlockIndex objects in memory. // class CBlock { public: // header uint256 hashPrevBlock; uint256 hashMerkleRoot; unsigned int nTime; unsigned int nBits; unsigned int nNonce;
// network and disk vector vtx;
// memory only mutable vector vMerkleTree;
CBlock() { SetNull(); }
IMPLEMENT_SERIALIZE ( if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(hashPrevBlock); READWRITE(hashMerkleRoot); READWRITE(nTime); READWRITE(nBits); READWRITE(nNonce);
// ConnectBlock depends on vtx being last so it can calculate offset if (!(nType & (SER_GETHASH|SER_BLOCKHEADERONLY))) READWRITE(vtx); else if (fRead) const_cast(this)->vtx.clear(); )
void SetNull() { hashPrevBlock = 0; hashMerkleRoot = 0; nTime = 0; nBits = 0; nNonce = 0; vtx.clear(); vMerkleTree.clear(); }
bool IsNull() const { return (nBits == 0); }
uint256 GetHash() const { return Hash(BEGIN(hashPrevBlock), END(nNonce)); }
uint256 BuildMerkleTree() const { vMerkleTree.clear(); foreach(const CTransaction& tx, vtx) vMerkleTree.push_back(tx.GetHash()); int j = 0; for (int nSize = vtx.size(); nSize > 1; nSize = (nSize + 1) / 2) { for (int i = 0; i < nSize; i += 2) { int i2 = min(i+1, nSize-1); vMerkleTree.push_back(Hash(BEGIN(vMerkleTree[j+i]), END(vMerkleTree[j+i]), BEGIN(vMerkleTree[j+i2]), END(vMerkleTree[j+i2]))); } j += nSize; } return (vMerkleTree.empty() ? 0 : vMerkleTree.back()); }
vector GetMerkleBranch(int nIndex) const { if (vMerkleTree.empty()) BuildMerkleTree(); vector vMerkleBranch; int j = 0; for (int nSize = vtx.size(); nSize > 1; nSize = (nSize + 1) / 2) { int i = min(nIndex1, nSize-1); vMerkleBranch.push_back(vMerkleTree[j+i]); nIndex >>= 1; j += nSize; } return vMerkleBranch; }
static uint256 CheckMerkleBranch(uint256 hash, const vector& vMerkleBranch, int nIndex) { foreach(const uint256& otherside, vMerkleBranch) { if (nIndex & 1) hash = Hash(BEGIN(otherside), END(otherside), BEGIN(hash), END(hash)); else hash = Hash(BEGIN(hash), END(hash), BEGIN(otherside), END(otherside)); nIndex >>= 1; } return hash; }
bool WriteToDisk(bool fWriteTransactions, unsigned int& nFileRet, unsigned int& nBlockPosRet) { // Open history file to append CAutoFile fileout = AppendBlockFile(nFileRet); if (!fileout) return false; if (!fWriteTransactions) fileout.nType |= SER_BLOCKHEADERONLY;
// Write index header unsigned int nSize = fileout.GetSerializeSize(*this); fileout << FLATDATA(pchMessageStart) << nSize;
// Write block nBlockPosRet = ftell(fileout); if (nBlockPosRet == -1) return false; fileout << *this;
return true; }
bool ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions) { SetNull();
// Open history file to read CAutoFile filein = OpenBlockFile(nFile, nBlockPos, "rb"); if (!filein) return false; if (!fReadTransactions) filein.nType |= SER_BLOCKHEADERONLY;
// Read block filein >> *this;
// Check the header if (nBits < MINPROOFOFWORK || GetHash() > (~uint256(0) >> nBits)) return error("CBlock::ReadFromDisk : errors in block header");
return true; }
void print() const { printf("CBlock(hashPrevBlock=%s, hashMerkleRoot=%s, nTime=%u, nBits=%u, nNonce=%u, vtx=%d)\n", hashPrevBlock.ToString().substr(0,6).c_str(), hashMerkleRoot.ToString().substr(0,6).c_str(), nTime, nBits, nNonce, vtx.size()); for (int i = 0; i < vtx.size(); i++) { printf(" "); vtx[i].print(); } printf(" vMerkleTree: "); for (int i = 0; i < vMerkleTree.size(); i++) printf("%s ", vMerkleTree[i].ToString().substr(0,6).c_str()); printf("\n"); }
bool ReadFromDisk(const CBlockIndex* blockindex, bool fReadTransactions); bool TestDisconnectBlock(CTxDB& txdb, map& mapTestPool); bool TestConnectBlock(CTxDB& txdb, map& mapTestPool); bool DisconnectBlock(); bool ConnectBlock(unsigned int nFile, unsigned int nBlockPos, int nHeight); bool AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos, bool fWriteDisk); bool CheckBlock() const; bool AcceptBlock(); };
// // The timechain is a tree shaped structure starting with the // genesis block at the root, with each block potentially having multiple // candidates to be the next block. pprev and pnext link a path through the // main/longest chain. A blockindex may have multiple pprev pointing back // to it, but pnext will only point forward to the longest branch, or will // be null if the block is not part of the longest chain. // class CBlockIndex { public: CBlockIndex* pprev; CBlockIndex* pnext; unsigned int nFile; unsigned int nBlockPos; int nHeight;
CBlockIndex() { pprev = NULL; pnext = NULL; nFile = 0; nBlockPos = 0; nHeight = 0; }
CBlockIndex(unsigned int nFileIn, unsigned int nBlockPosIn) { pprev = NULL; pnext = NULL; nFile = nFileIn; nBlockPos = nBlockPosIn; nHeight = 0; }
bool IsInMainChain() const { return (pnext || this == pindexBest); }
bool EraseBlockFromDisk() { // Open history file CAutoFile fileout = OpenBlockFile(nFile, nBlockPos, "rb+"); if (!fileout) return false;
// Overwrite with empty null block CBlock block; block.SetNull(); fileout << block;
return true; }
bool TestDisconnectBlock(CTxDB& txdb, map& mapTestPool) { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.TestDisconnectBlock(txdb, mapTestPool); }
bool TestConnectBlock(CTxDB& txdb, map& mapTestPool) { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.TestConnectBlock(txdb, mapTestPool); }
bool DisconnectBlock() { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.DisconnectBlock(); }
bool ConnectBlock() { CBlock block; if (!block.ReadFromDisk(nFile, nBlockPos, true)) return false; return block.ConnectBlock(nFile, nBlockPos, nHeight); }
void print() const { printf("CBlockIndex(nprev=%08x, pnext=%08x, nFile=%d, nBlockPos=%d, nHeight=%d)\n", pprev, pnext, nFile, nBlockPos, nHeight); } };
void PrintTimechain();
// // Describes a place in the timechain to another node such that if the // other node doesn't have the same branch, it can find a recent common trunk. // The further back it is, the further before the branch point it may be. // class CBlockLocator { protected: vector vHave; public:
CBlockLocator() { }
explicit CBlockLocator(const CBlockIndex* pindex) { Set(pindex); }
explicit CBlockLocator(uint256 hashBlock) { map::iterator mi = mapBlockIndex.find(hashBlock); if (mi != mapBlockIndex.end()) Set((*mi).second); }
IMPLEMENT_SERIALIZE ( if (!(nType & SER_GETHASH)) READWRITE(nVersion); READWRITE(vHave); )
void Set(const CBlockIndex* pindex) { vHave.clear(); int nStep = 1; while (pindex) { CBlock block; block.ReadFromDisk(pindex, false); vHave.push_back(block.GetHash());
// Exponentially larger steps back for (int i = 0; pindex && i < nStep; i++) pindex = pindex->pprev; if (vHave.size() > 10) nStep *= 2; } }
CBlockIndex* GetBlockIndex() { // Find the first block the caller has in the main chain foreach(const uint256& hash, vHave) { map::iterator mi = mapBlockIndex.find(hash); if (mi != mapBlockIndex.end()) { CBlockIndex* pindex = (*mi).second; if (pindex->IsInMainChain()) return pindex; } } return pindexGenesisBlock; }
uint256 GetBlockHash() { // Find the first block the caller has in the main chain foreach(const uint256& hash, vHave) { map::iterator mi = mapBlockIndex.find(hash); if (mi != mapBlockIndex.end()) { CBlockIndex* pindex = (*mi).second; if (pindex->IsInMainChain()) return hash; } } return hashGenesisBlock; }
int GetHeight() { CBlockIndex* pindex = GetBlockIndex(); if (!pindex) return 0; return pindex->nHeight; } };
extern map mapTransactions; extern map mapWallet; extern vector > vWalletUpdated; extern CCriticalSection cs_mapWallet; extern map, CPrivKey> mapKeys; extern map > mapPubKeys; extern CCriticalSection cs_mapKeys; extern CKey keyUser;
'''
Read this went the opposite way
Go1dfish undelete link
unreddit undelete link
Author: fukya40
submitted by removalbot to removalbot [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-10-15)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Mempool limiting sendheaders BIP versionbits dev/discuss list policy CHECKSEQUENCEVERIFY
Mempool limiting
When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short. Like we could see during the spam-attack if there's a big back-log of transactions that couldn't make it in the blockchain this mempool can get pretty big resulting in nodes crashing.
To stop this from happening devs are trying to find a way to limit this mempool, so a mechanism to reject and/or remove transactions from the mempool. The hard part here is to make it so nodes can't be attacked by abusing this mechanism. So far the devs are going with TheBlueMatt's proposal of throwing away the cheapest txn and setting the min relay fee to it
While testing, sipa encountered transactions that took 200ms to be accepted into the mempool. As it's the first time he has benchmarked this and the pull-request shouldn't make an impact on these times it likely doesn't have anything to do with this. However, such times are bad either way. The average time in sipa's tests is 4ms. (After the meeting Morcos did some benchmarking and confirmed it was not specific to this PR, and pointed out the outliers come from CheckInputs and HaveInputs (as you might guess, having to do with checking the inputs) Question on why we should revert the minrelay (minimum fee for nodes to relay a transaction) back to 1000 (it has been set to 5000 to quick-fix the mempool issues), sipa thinks it should be floating as well or the dust limit becomes ineffective.
Review PR 6722 Limit mempool by throwing away the cheapest txn and setting min relay fee to it Morcos/sipa will do some more benchmarks and comment on the PR ( morcos' benchmark results )
sendheaders BIP
send headers BIP Copy/paste from the BIP: Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless they are able to connect to a (valid) headers chain. Consequently, block relay generally works as follows:
  1. A node (N) announces the new tip with an "inv" message, containing the block hash
  2. A peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itself
  3. N responds with a "headers" message (with the header for the new block along with any preceding headers unknown to P) and a "block" message containing the new block However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator).
Question on how to move forward. How to let the nodes know you want the blockheader instead of the blockhash. Options:
  1. Extend the version message.
  2. Have an "options" message that can send flags.
  3. Send a "sendheaders" message early when connecting so the way peers want their block announcement is immediately known.
  4. Send a "sendheaders" message at any time, changing the way peers want their block announcement from hashes to headers.
No one likes to extend the version message further. There's no strong advantage to have an "options" message over a "sendheaders" message. Having the message being sent early on might be too constraining. Possible usecase from morcos: "its entirely possible some future optimization may say, i want to send sendheaders to these peers b/c they announce a lot of new stuff to me and not these others b/c they don't". Most people like this to be enable-only, so no message to get back to receiving blockhashes. Which is how the BIP was drafted.
sdaftuar does a pull-request for the BIP to get a number assigned and proceeds with the BIP as drafted.
versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
copy/paste from IRC, since I don't know what this specifically means: CodeShark: so right now it's just a unit that implements the versionbits logic but does not demonstrate its usage I thought it would be better to actually integrate in a separate PR, but I can add a demonstration sipa: separate commit, same PR - i think we need something that's mergable as a whole, to be able to see whether the whole thing easily backports
Codeshark (who's implementing versionbits) had some more remarks but no one present had seemed to reviewed it, so not much use in discussing things further.
review versionbits implementation
dev/discuss list policy
The bitcoin-dev mailing list is intended for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden. For the things that don't belong on bitcoin-dev, but need to be discussed anyway there's a new list being created namely bitcoin-discuss as well as clear policies and moderation for both.
Bitcoin-discuss was created, but the admin password wasn't distributed to jgarzik who's willing to guide the moderation. Seperate moderation-proposals have been done meanwhile. People just want it to move on.
Since none of the people who proposed a moderation-scheme are present we'll let them discuss it among each other and post their decisions publicly.
CHECKSEQUENCEVERIFY
CheckLockTimeVerify (CLTV) repurposes the nSequence field (nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used). However, there's no way use these values in a bitcoin script. CheckSequenceVerify (CSV) makes this field accessible to bitcoin scripts.
EDIT: Turns out this is not entirely correct as it is relative locktime that repurposes the nSequence field.
CLTV is pretty much done. Check to see maaku moving one of the bits to allow for other implementations to have better granularity has any objections. As long as we're using as few bits as possible the exact semantics are less important for most people. sipa points out a possible bug that influences the wallet. CSV is not on target for the end of of the month, although a lot of work and progress has been made.
Review and ACK/NACK of 6312 BIP-68: Mempool-only sequence number constraint verification Review and ACK/NACK of 6566 BIP-113: Mempool-only median time-past as endpoint for lock-time calculations
Participants
wumpus Wladimir J. van der Laan sipa Pieter Wuille btcdrak btcdrak gmaxwell Gregory Maxwell morcos Alex Morcos maaku Mark Friedenbach CodeShark Eric Lombrozo BlueMatt Matt Corallo sdaftuar Suhas Daftuar warren Warren Togami GreenIsMyPepper Joseph Poon davec Dave Collins cfields Cory Fields jonasschnelli Jonas Schnelli
Comic relief
19:21 sdaftuar it sounds like everyone is ok with the BIP as drafted then? 19:21 wumpus yes 19:21 gmaxwell I think so. 19:22 davec yes 19:22 sipa well, the only person with concerns was cfields, who doesn't seem to be here :) 19:22 gmaxwell sipa: he can raise concerns later too! 19:22 cfields dammit! 19:22 sipa cfields: too late! 19:22 gmaxwell ha 19:23 cfields did i really miss my third one of these in a row?
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev meeting in layman's terms (2015-10-8)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bare in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs link to meeting minutes
Main topics discussed this week where:
Mempool limiting: chain limits Low-S change CLTV & CSV review Creation of bitcoin discuss mailing list
off-topic but important notice
This issue has made most JS bitcoin software vulnerable to generating incorrect public keys. "This is an ecosystem threat with the potential to cause millions of dollars in losses that needs higher visibility; though it's not a bitcoin core / bitcoin network issue. Common, critical, JS code is broken that may cause the generation of incorrect pubkeys (among other issues). Anyone who cares for a JS implementation should read that PR."
Mempool limiting: chain limits
(c/p from last week) Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is reffered to as "packages".
As said in "Chain limits" last week Morcos did write a proposal about lowering the default limits for transaction-chains. 2 use cases came up which are currently in use or happened before: As example: someone buys bitcoin from a website and can spend those bitcoin in the marketplace of the same website without waiting for confirmation in order to improve the bitcoin user-experience. This leaves a sequential transaction chain. They don't need to chain more than 5 transactions deep for this, and it falls within the proposed limits. What's not within the proposed limits is the chain of +/- 100 transactions a company had during the spam-attacks. These where simply increased activities by end-users while not enough UTXO's where available (3 to be precise)(UTXO: unspent transaction output, an output that can be used as input for a new transaction). Notably this is with the best practices of using confirmed transactions first. Ways this can be solved from the company's end is to have more UTXO's available before hand, bundling transactions (which requires delaying customer's request) or using replace-by-fee to add payees (which saves blockchain space, is cheaper in fees and gets transactions through quicker, but is not widely deployed by miners atm). Bare in mind these proposals are for default values for the memorypool, not in any way hard limits.
Sense of urgency. Quoting sipa: "my mempool is 2.5G... we better get some solution!" Current attack analysis assumes child-pays-for-parent mining, it should probably be done again without. Higher limits on number of transactions increase attack-vectors. Proposed number of transactions gets some push-back, total size limit not. Mixing default values (for example having a 50% of a 10/10 limit and 50% of a 100/100 limit) wastes bandwidth while there are too many factors that limit utility of long chains as well. 25 transaction limit ought to be enough for everyone (for now).
Review & test Limit mempool by throwing away the cheapest txn and setting min relay fee to it Provide support for Lower default limits for tx chains aka convince people 25 should be enough.
Low-S change
This is in regards to the recent malleability attack. Which is caused by a value 'S' in the ECDSA signature which can be 2 values, a high and low value and still be valid. Resulting in different transaction id's. more info A solution for this is to require nodes to have the "low-s" encoding for signatures. Downside is that it will block most transactions made by sufficiently out of date software (+/- pre-march 2014) This does not replace the need for BIP62, it only eliminates the cheap DOS attack.
95% of transactions already confirm to this, and more fixes have been applied since. BlueMatt has a node which several people are running that auto-malleates to low-s transactions. Questions whether we release it ASAP or wait for the next release and get it to a couple of miners in the meantime (possibly with auto-lowS-malleating)
Contact miners about "Test LowS in standardness, removes nuisance malleability vector" Release scheduled for the end of the month, together with likely check-lock-time-verify and possibly check-sequence-verfiy.
CLTV & CSV backport review
CLTV: checkLockTimeVerify CSV: checkSequenceVerify Both new time-related OP-codes. Been discussed heavily last week.
Concerns whether CSV will be ready enough for release later this month. There's no clarity on how things look when all 3 time related pull-requests are merged. There's a number of people still reviewing the pull-requests. Uncertainty and confusion about whether the semantics are final or not (in regards to using bits from nSequence). nSequence are 4 bytes intended for sequencing time-locked transactions, but this never got used. Now these bytes are being repurposed for a mixture of things. Currently the plan is: " bits 0..15 are the relative locktime, bit 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on, 1: off). bits 16..29 are masked off and can take any value."
Clarification from maaku regarding nSequence for BIP68. (after the meeting he explained he was waiting for opinions, but not enough people seemed to know the issue at hand) Continue review of pull requests 6312, 6564 and 6566
Creation of bitcoin discuss mailing list
The bitcoin-dev mailing list is intented for technical discussions only. There's things that don't belong there but need to be discussed anyway. Now this is done in bitcoin-dev, but the volume of this is getting too big. There's recently also an influx of really inappropriate posts, level kindergarden.
No clarity about who are the moderators. Next week there'll be a bitcoin-discuss list created. Decisions are needed as to who'll become the moderators for that and bitcoin-dev. Decisions are needed as to what will be the list and moderation policies.
The bitcoin-discuss list will be created as well as a simple website listing all the lists and corresponding policies. A meeting is scheduled on monday to discuss the moderation and policies of said lists.
Participants
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille BlueMatt Matt Corallo btcdrak btcdrak petertodd Peter Todd warren Warren Togami phantomcircuit Patrick Strateman dstadulis Daniel Stadulis GreenIsMyPepper Joseph Poon bsm117532 Bob McElrath
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-12)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines".
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
transaction priority for 0.12 Opt-in replace-by-fee Versionbits Chain limits
transaction priority for 0.12
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free. This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can't expect miners to include 0-fee transactions.
Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming. sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release. petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all. Most wallet-software outside of bitcoin-core don't implement priority calculations. As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome. Luke-Jr doesn't agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool. Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee.
While most agree with the proposal to remove the current priority, there's still much debate on whether it needs to be replaced for 0.13, and if so, how.
Review "Improve usage of fee estimation code" BlueMatt will mail the developer mailinglist announcing the changes. ( https://www.mail-archive.com/[email protected]/msg02790.html )
Opt-in replace-by-fee
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.
Peter Todd wrote some tools to use replace-by-fee. link It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns. Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and neveopt-in/always. Since there are possibly some objections with the "always" toggle it should be a separate pull-request.
review and merge nSequence-based Full-RBF opt-in Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions.
Versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
There are 2 different implementations. One from Codeshark and one from Rusty jtimon thinks both implementations are more complicated than they need to be. There needs to be a minor revision namely a starting time for proposals. In general we'd like to get this in soon, but existing softforks need to complete first.
CodeShark adds a starting time to versionbits.
Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
Wumpus doesn't feel comfortable with merging it because there's some controversy from companies who exceed the limits (or could be/want to). jgarzik does feel comfortable with it, and many think it should be merged as it's easy to revert if needed. There's little choice as it's not safe from attacks without limits. We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won't show up in users wallet yet and block-explorers probably aren't ready to display it correctly. Emphasis on the fact it's a change in default values, not a consensus change, however default values have a lot of power. The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.
jgarzik will merge the pull-request. Morcos will mail the list once it's merged.
Participants
BlueMatt Matt Corallo petertodd Peter Todd morcos Alex Morcos jgarzik Jeff Garzik gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan Luke-Jr Luke Dashjr jtimon Jorge Timón btcdrak btcdrak phantomcircuit Patrick Strateman sipa Pieter Wuille CodeShark Eric Lombrozo sdaftuar Suhas Daftuar jg_taxi jg_taxi gavinandresen Gavin Andresen cfields Cory Fields bsm1175321 Bob McElrath 
Comic relief
19:53 sipa new topic? 19:53 wumpus any other topics? 19:53 petertodd  19:53 jgarzik did we cover jonas while I was in the taxi? 19:54 sdaftuar ? 19:54 jtimon ? 19:54 CodeShark not sure I want to know 19:54 jgarzik proposal for new GUI maintainer 19:54 CodeShark sounds kinky, though 19:54 petertodd CodeShark: GUI's are pretty kinky 19:56 BlueMatt ok, end meeting? 19:56 btcdrak if we can remember the command this week :-) 19:56 wumpus #meetingend 19:56 gmaxwell #destroymeeting 19:56 wumpus #endmeeting 19:56 Luke-Jr #endmeeting 19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 19:56 BlueMatt #magicmeetbotincantation 19:57 petertodd #DoWhatIMean 
submitted by G1lius to Bitcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-12)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
transaction priority for 0.12 Opt-in replace-by-fee Versionbits Chain limits
transaction priority for 0.12
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which currently makes some transactions free. This currently has a large amount of code, which makes it harder to maintain, and is not that optimal since you can't expect miners to include 0-fee transactions.
Most people seem fine with removing priority in the mempool, but people should be notified ahead of time this is coming. sdaftuar proposed a staggered approach, setting the default value for priority to 0, and remove it entirely in the next release. petertodd notes there will be a natural staggered process since not everyone will upgrade to 0.12 instantly and some implementations might not remove priority at all. Most wallet-software outside of bitcoin-core don't implement priority calculations. As fee estimation becomes more important and many wallet providers use the bitcoin-core fee estimation, improvements on that are welcome. Luke-Jr doesn't agree with removing priority, particularly with changing the mining code to use the priority a transaction has when it enters the mempool. Sipa has the idea to add a small fraction of bitcoin days destroyed divided by the average UTXO age to the fee, so that non-spam-attack transactions are viewed as if they have a larger fee.
While most agree with the proposal to remove the current priority, there's still much debate on whether it needs to be replaced for 0.13, and if so, how.
Review "Improve usage of fee estimation code" BlueMatt will mail the developer mailinglist announcing the changes. ( https://www.mail-archive.com/[email protected]/msg02790.html )
Opt-in replace-by-fee
Currently when a node sees a transaction that spends the same output it ignores it. With replace-by-fee it replaces the current transaction in the mempool if it has a higher fee. This allows for things like spending "stuck" transactions, adding more recipients to a transaction in order to prevent chaining, etc.
Since there are people that accept 0-confirmation transactions and this would make it extremely easy to double spend them, this is made opt-in. The sender can choose to opt-in to replace-by-fee by changing an input in the nSequence field.
Peter Todd wrote some tools to use replace-by-fee. link It would be nice to have opt-in per output instead of the whole transaction, however that would be very hard to implement and would have some privacy concerns. Luke-Jr would like to see an option to toggle between first-seen-safe/full RBF and neveopt-in/always. Since there are possibly some objections with the "always" toggle it should be a separate pull-request.
review and merge nSequence-based Full-RBF opt-in Peter Todd will write a mail to the list to explain how it works and how people can not accept opt-in transactions.
Versionbits
BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than Y the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.
There are 2 different implementations. One from Codeshark and one from Rusty jtimon thinks both implementations are more complicated than they need to be. There needs to be a minor revision namely a starting time for proposals. In general we'd like to get this in soon, but existing softforks need to complete first.
CodeShark adds a starting time to versionbits.
Chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
Wumpus doesn't feel comfortable with merging it because there's some controversy from companies who exceed the limits (or could be/want to). jgarzik does feel comfortable with it, and many think it should be merged as it's easy to revert if needed. There's little choice as it's not safe from attacks without limits. We should communicate the replace-by-fee sendmany alternative to long chains (adding new recipients on existing non-confirmed transactions), although it won't show up in users wallet yet and block-explorers probably aren't ready to display it correctly. Emphasis on the fact it's a change in default values, not a consensus change, however default values have a lot of power. The final limits are 25 transactions and 101kb total size for both ancestor and descendant packages.
jgarzik will merge the pull-request. Morcos will mail the list once it's merged.
Participants
BlueMatt Matt Corallo petertodd Peter Todd morcos Alex Morcos jgarzik Jeff Garzik gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan Luke-Jr Luke Dashjr jtimon Jorge Timón btcdrak btcdrak phantomcircuit Patrick Strateman sipa Pieter Wuille CodeShark Eric Lombrozo sdaftuar Suhas Daftuar jg_taxi jg_taxi gavinandresen Gavin Andresen cfields Cory Fields bsm1175321 Bob McElrath 
Comic relief
19:53 sipa new topic? 19:53 wumpus any other topics? 19:53 petertodd  19:53 jgarzik did we cover jonas while I was in the taxi? 19:54 sdaftuar ? 19:54 jtimon ? 19:54 CodeShark not sure I want to know 19:54 jgarzik proposal for new GUI maintainer 19:54 CodeShark sounds kinky, though 19:54 petertodd CodeShark: GUI's are pretty kinky 19:56 BlueMatt ok, end meeting? 19:56 btcdrak if we can remember the command this week :-) 19:56 wumpus #meetingend 19:56 gmaxwell #destroymeeting 19:56 wumpus #endmeeting 19:56 Luke-Jr #endmeeting 19:56 lightningbot Meeting ended Thu Nov 12 19:56:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 19:56 BlueMatt #magicmeetbotincantation 19:57 petertodd #DoWhatIMean 
submitted by G1lius to btc [link] [comments]

Generalised Replay Protection for Future Hard Forks | Mats Jerratsch | Nov 05 2017

Mats Jerratsch on Nov 05 2017:
Presented is a generalised way of providing replay protection for future hard forks. On top of replay protection, this schema also allows for fork-distinct addresses and potentially a way to opt-out of replay protection of any fork, where deemed necessary (can be beneficial for some L2 applications).

Rationale

Currently when a hard fork happens, there is ad-hoc replay protection built within days with little review at best, or no replay protection at all. Often this is either resource problem, where not enough time and developers are available to sufficiently address replay protection, or the idea that not breaking compatibility is favourable. Furthermore, this is potentially a recurring problem with no generally accepted solution yet. Services that want to deal in multiple forks are expected to closely follow all projects. Since there is no standard, the solutions differ for each project, requiring custom code for every fork. By integrating replay protection into the protocol, we advocate the notion of non-hostile forks.
Users are protected against accidentally sending coins on the wrong chain through the introduction of a fork-specific incompatible address space. The coin/token type is encoded in the address itself, removing some of the importance around the question What is Bitcoin?. By giving someone an address, it is explicitly stated I will only honour a payment of token X, enforcing the idea of validating the payment under the rules chosen by the payee.

Iterative Forks

In this schema, any hard fork is given an incremented id, nForkId. nForkId starts at 1, with 0 being reserved as a wildcard. When project X decides to make an incompatible change to the protocol, it will get assigned a new unique nForkId for this fork. A similar approach like for BIP43 can be taken here. Potentially nForkId can be reused if a project has not gained any amount of traction.
When preparing the transaction for signing or validation, nForkId is appended to the final template as a 4B integer (similar to [1]). Amending BIP143, this would result in
```
Double SHA256 of the serialization of:
 1. nVersion of the transaction (4-byte little endian) 2. hashPrevouts (32-byte hash) 3. hashSequence (32-byte hash) 4. outpoint (32-byte hash + 4-byte little endian) 5. scriptCode of the input (serialized as scripts inside CTxOuts) 6. value of the output spent by this input (8-byte little endian) 7. nSequence of the input (4-byte little endian) 8. hashOutputs (32-byte hash) 9. nLocktime of the transaction (4-byte little endian) 10. sighash type of the signature (4-byte little endian) 11. nForkId (4-byte little endian) 
```
For nForkId=0 this step is ommitted. This will immediately invalidate signatures for any other branch of the blockchain than this specific fork. To distinguish between nForkId=0 and nForkId hardcoded into the software, another bit has to be set in the 1B SigHashId present at the end of signatures.
To make this approach more generic, payment addresses will contain the fork id, depending on which tokens a payee expects payments in. This would require a change on bech32 addresses, maybe to use a similar format used in lightning-rfc [2]. A wallet will parse the address, it will extract nForkId, and it displays which token the user is about to spend. When signing the transaction, it will use nForkId, such that the transaction is only valid for this specific token. This can be generalised in software to the point where replay protection and a new address space can be introduced for forks without breaking existing clients.
For light clients, this can be extended by enforcing the coinbase/block header to contain the nForkId of the block. Then the client can distinguish between different chains and tokens it received on each. Alternatively, a new P2P message type for sending transactions could be introduced, where prevOut and nForkId is transmitted, such that the lite client can check for himself, which token he received.
Allowing signatures with nForkId=1 can be achieved with a soft fork by incrementing the script version of SegWit, making this a fully backwards compatible change.
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
[2]
https://github.com/lightningnetwork/lightning-rfc/blob/maste11-payment-encoding.md https://github.com/lightningnetwork/lightning-rfc/blob/maste11-payment-encoding.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171105/41f5276f/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171105/41f5276f/attachment.sig
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Novembe015258.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection | Peter Todd | Aug 24 2016

Peter Todd on Aug 24 2016:
Bitcoin-based honeypots incentivise intruders into revealing the fact they have
broken into a server by allowing them to claim a reward based on secret
information obtained during the intrusion. Spending a bitcoin can only be done
by publishing data to a public place - the Bitcoin blockchain - allowing
detection of the intrusion.
The simplest way to achieve this is with one private key per server, with each
server associated with one transaction output spendable by that key. However
this isn't capital efficient if you have multiple servers to protect: if we
have N servers and P bitcoins that we can afford to lose in the compromise, one
key per server gives the intruder only N/P incentive.
Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
single txout protected by a 1-N tree of keys, with each server assigned a
specific key. Unfortunately though, tree signatures aren't yet implemented in
the Bitcoin protocol.
However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can implement
this functionality with the existing Bitcoin protocol using the following
script:
2 2 CHECKMULTISIG 
The honeypot secret key is shared among all N servers, and left on them. The
distriminator secret key meanwhile is kept secret, however for each server a
unique signature is created with SIGHASH_SINGLE, paying a token amount to a
notification address. For each individual server a pre-signed signature created
with the distriminator secret key is then left on the associated server along
with the honeypot secret key.
Recall the SIGHASH_SINGLE flag means that the signature only signs a single
transaction input and transaction output; the transaction is allowed to have
additional inputs and outputs added. This allows the thief to use the honeypot
key to construct a claim transaction with an additional output added that pays
an address that they own with the rest of the funds.
Equally, we could also use SIGHASH_NONE, with the per-server discriminator
being the K value used in the pre-signed transaction.
Note that Jeff Coleman deserves credit as co-inventor of all the above.
Censorship Resistance

A potential disadvantage of using non-standard SIGHASH flags is that the
transactions involved are somewhat unusual, and may be flagged by
risk analysis at exchanges and the like, a threat to the fungibility of the
reward.
We can improve on the above concept from Todd/Coleman by using a pre-signed
standard transaction instead. The pre-signed transaction spends the honeypot
txout to two addresses, a per-server canary address, and a change address. The
private key associated with the change addres is also left on the server, and
the intruder can then spend that change output to finally collect their reward.
To any external observer the result looks like two normal transactions created
in the process of someone with a standard wallet sending a small amount of
funds to an address, followed by sending a larger amount.
Doublespending

A subtlety in the the two transactions concept is that the intruder doesn't
have the necessary private keys to modify the first transaction, which means
that the honeypot owner can respond to the compromise by doublespending that
transaction, potentially recovering the honeypot while still learning about the
compromise. While this is possible with all honeypots, if the first transaction
is signed with the opt-in RBF flags, and CPFP-aware transaction replacement is
not implemented by miners, the mechanics are particularly disadvantageous to
the intruder, as the honeypot owner only needs to increase the first
transaction's fee slightly to have a high chance of recovering their funds.
With CPFP-aware transaction replacement the intruder could in-turn respond with
a high-fee CPFP second transaction, but currently no such implementation is
known.
Scorched Earth

We can use the "scorched earth" concept to improve the credibility of the
honeypot reward by making it costly for the honeypot owner to doublespend. Here
a second version of the honeypot pre-signed transaction would also be provided
which sepnds the entirety of the honeypot output to fees, and additionally
spends a second output to fees. An economically rational intruder will publish
the first version, which maximizes the funds they get out of the honeypot. If
the owner tries to dishonestly doublespend, they can respond by publishing the
"scorched earth" transaction, encouraging the honeypot owner's honesty and
making CPFP-aware transaction replacement irrelevant.
Of course, miner centralization adds complexity to the above: in many instances
honeypot owners and/or intruders will be able to recover funds from altruistic
miners. Equally, the additional complexity may discourage intruders from making
use of the honeypot entirely.
Note that as an implementation consideration CHECKSEQUENCEVERIFY can be used to
ensure the honeypot output can only be spent with transaction replacement
enabled, as CSV requires nSequence to be set in specific ways in any transation
spending the output.
References

1) https://blockstream.com/2015/08/24/treesignatures/

https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/b348f953/attachment.sig
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013058.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime | Btc Drak | Aug 13 2015

Btc Drak on Aug 13 2015:
I have written the following draft BIP for a new opcode
CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
relative-locktime to Bitcoin's scripting language.
https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
BIP: XX
Title: CHECKSEQUENCEVERIFY
Authors: BtcDrak <btcdrak at gmail.com>
 Mark Friedenbach <[mark at friedenbach.org](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)> 
Status: Draft
Type: Standards Track
Created: 2015-08-10
==Abstract==
This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that in combination with BIP 68 allows execution
pathways of a script to be restricted based on the age of the output
being spent.
==Summary==
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
it compares the top item on the stack to the inverse of the nSequence
field of the transaction input containing the scriptSig. If the
inverse of nSequence is less than the sequence threshold (1 << 31),
the transaction version is greater than or equal to 2, and the top
item on the stack is less than or equal to the inverted nSequence,
script evaluation continues as though a NOP was executed. Otherwise
the script fails immediately.
BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding
input has reached the specified age, as measured in block heiht or
block time. By comparing the argument to CHECKSEQUENCEVERIFY against
the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
script execution pathway including the CHECKSEQUENCEVERIFY will fail
to validate, causing the transaction not to be selected for inclusion
in a block.
==Motivation==
BIP 68 repurposes the transaction nSequence field meaning by giving
sequence numbers new consensus-enforced semantics as a relative
lock-time. However, there is no way to build Bitcoin scripts to make
decisions based on this field.
By making the nSequence field accessible to script, it becomes
possible to construct code pathways that only become accessible some
minimum time after proof-of-publication. This enables a wide variety
of applications in phased protocols such as escrow, payment channels,
or bidirectional pegs.
==Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP3: { if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) { // not enabled; treat as a NOP3 if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) { return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS); } break; } if (stack.size() < 1) return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION); // Note that unlike CHECKLOCKTIMEVERIFY we do not need to // accept 5-byte bignums since any value greater than or // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected // anyway. This limitation just happens to coincide with // CScriptNum's default 4-byte limit with an explicit sign // bit. // // This means there is a maximum relative lock time of 52 // years, even though the nSequence field in transactions // themselves is uint32_t and could allow a relative lock // time of up to 120 years. const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal); // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKSEQUENCEVERIFY. if (nInvSequence < 0) return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); // Actually compare the specified inverse sequence number // with the input. if (!CheckSequence(nInvSequence)) return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME); break; } bool CheckSequence(const CScriptNum& nInvSequence) const { int64_t txToInvSequence; // Fail under all circumstances if the transaction's version // number is not set high enough to enable enforced sequence // number rules. if (txTo->nVersion < 2) return false; // Sequence number must be inverted to convert it into a // relative lock-time. txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence; // Sequence numbers under SEQUENCE_THRESHOLD are not consensus // constrained. if (txToInvSequence >= SEQUENCE_THRESHOLD) return false; // There are two types of relative lock-time: lock-by- // blockheight and lock-by-blocktime, distinguished by // whether txToInvSequence < LOCKTIME_THRESHOLD. // // We want to compare apples to apples, so fail the script // unless the type of lock-time being tested is the same as // the lock-time in the transaction input. if (!( (txToInvSequence < LOCKTIME_THRESHOLD && nInvSequence < 
LOCKTIME_THRESHOLD) ||
 (txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >= 
LOCKTIME_THRESHOLD)
 )) return false; // Now that we know we're comparing apples-to-apples, the // comparison is a simple numeric one. if (nInvSequence > txInvToSequence) return false; return true; } 
https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2
==Example: Escrow with Timeout==
An escrow that times out automatically 30 days after being funded can be
established in the following way. Alice, Bob and Escrow create a 2-of-3
address with the following redeemscript.
IF 2    3 
CHECKMULTISIGVERIFY
ELSE CHECKSEQUENCEVERIFY DROP  CHECKSIGVERIFY ENDIF 
At any time funds can be spent using signatures from any two of Alice,
Bob or the Escrow.
After 30 days Alice can sign alone.
The clock does not start ticking until the payment to the escrow address
confirms.
==Reference Implementation==
A reference implementation is provided in the following git repository:
https://github.com/maaku/bitcoin/tree/checksequenceverify
==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and
66, with the same thresholds, but for nVersion = 4. The new rules are
in effect for every block (at height H) with nVersion = 4 and at least
750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
preceding a block do have nVersion = 4, nVersion = 3 blocks become
invalid, and all further blocks enforce the new rules.
It is recommended that this soft-fork deployment trigger include other
related proposals for improving Bitcoin's lock-time capabilities, including:
[https://github.com/bitcoin/bips/blob/mastebip-0065.mediawiki BIP 65]:
OP_CHECKLOCKTIMEVERIFY,
[https://github.com/bitcoin/bips/blob/mastebip-0068.mediawiki BIP 68]:
Consensus-enforced transaction replacement signalled via sequence numbers,
and [https://github.com/bitcoin/bips/blob/mastebip-00XX.mediawiki BIP XX]:
Median-Past-Time-Lock.
==Credits==
Mark Friedenbach invented the application of sequence numbers to
achieve relative lock-time, and wrote the reference implementation of
CHECKSEQUENCEVERIFY.
The reference implementation and this BIP was based heavily on work
done by Peter Todd for the closely related BIP 65.
BtcDrak authored this BIP document.
==References==
BIP 68: Consensus-enforced transaction replacement signalled via
sequence numbers
https://github.com/bitcoin/bips/blob/mastebip-0068.mediawiki
BIP 65: OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/mastebip-0065.mediawiki
BIP XX: Median past block time for time-lock constraints
https://github.com/bitcoin/bips/blob/mastebip-00XX.mediawiki
HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
==Copyright==
This document is placed in the public domain.
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010198.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Too many FUD about RBF, let me try to clear things up.

Hopefully this will get enough visibility, otherwise you guys are probably beyond saving.
Unlike block size debate, which is really contentious, RBF was passed without a hitch. Does anyone wonders why? I mean Bitpay and Coinbase are definitely raising hell about block size but not about RBF. Even Jeff Garzik who used to work for Bitpay ACKed the change. Perhaps they know something that you don't?
Here's how RBF works. Every Bitcoin transaction has a field called nSequence that indicates the precedence of a transaction. What RBF does is if that transaction is not yet confirmed and the node see that another transaction that uses the same input with higher nSequence and it fulfills the fee requirement (which is a little bit complicated, see BIP 125 for details) then replace that transaction with the new one.
You guys see how this doesn't kill 0-conf? People who rely on 0-conf can simply reject transaction that doesn't have nSequence equal to the maximum possible value. Similarly people who pays for 0-conf can simply set the nSequence equal to maximum possible value.
Satoshi actually already include this feature in first version of Bitcoin but it was later removed because it is easily DoSed. Because of the current fee requirement it is much more difficult to DoS.
What are the use cases of RBF?
  1. Bidding of space in a block, which like you guys I hope I won't be seeing in near term, or perhaps in 5-10 years.
  2. Saving fee by compressing multiple transaction into one. For example a Bitcoin exchange can add recipient anytime they want during user withdrawal and actually save fee.
  3. On-the-fly Coinjoin that will increase privacy.
If you guys don't need RBF then it's okay don't use it. But please, for the love of God don't prevent anyone who has a use case for it from using it.
Further reading:
https://bitcoincore.org/en/faq/optin_rbf/
submitted by throwaway36256 to btc [link] [comments]

[BIP Proposal] Standard address format for timelocked funds | ZmnSCPxj | Jul 08 2017

ZmnSCPxj on Jul 08 2017:
BIP: ?
Title: Standard address format for timelocked funds
Author: ZmnSCPxj
Comments-Summary: ?
Comments-URI: ?
Status: ?
Type: ?
Created: 2017-07-01
License: CC0-1.0
== Abstract ==
OP_CHECKLOCKTIMEVERIFY provides a method of
locking funds until a particular time arrives.
One potential use of this opcode is for a user to precommit
himself or herself to not spend funds until a particular
date, i.e. to hold the funds until a later date.
This proposal adds a format for specifying addresses that
precommit to timelocked funds, as well as specifying a
redemption code to redeem funds after the timelock has
passed.
This allows ordinary non-technical users to make use of
OP_CHECKLOCKTIMEVERIFY easily.
== Copyright ==
This BIP is released under CC0-1.0.
== Specification ==
This proposal provides formats for specifying an
address that locks funds until a specified date,
and a redemption code that allows the funds to be
swept on or after the specified date.
At minimum, wallet software supporting this BIP must
be capable of sweeping the redemption code on or after
the specified date.
In addition, the wallet software should support sending
funds to the timelocked address specified here.
Finally, wallet software may provide a command to create
a pair of timelocked address and redemption code.
Addresses and redemption codes are encoded using
[https://github.com/bitcoin/bips/blob/mastebip-0173.mediawiki#Bech32
Bech32 encoding].
=== Timelocked Address Format ===
The human-readable part of the address is composed of:

The four characters hodl.

A date, in YYYYMMDD form. For example,

the date August 1, 2017 is encoded as 20170801.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.
The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this

BIP.

A public key hash, 32 quintets (160 bits). As is

usual for Bitcoin, this is big-endian.
This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The funds are owned by whoever controls the private

key corresponding to the public key hash given.
=== Redemption Code ===
The human-readable part of the redemption code is
composed of:

The four characters hedl.

A date, in YYYYMMDD form.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.
The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this

BIP.

A private key, 52 quintets (260 bits). This is the

256-bit private key, prepended with 4 0
bits, in big-endian order.
This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The private key unlocks the funds.

=== Lock Time Computation ===
Given a particular lock date YYYYMMDD, the
actual lock time is computed as follows:

The day before the lock date is taken. For example,

if the lock date is 20180101 or
January 1, 2018, we take the date December 31, 2017.

We take the time 1000h (10:00 AM, or 10 in the morning)

of the date from the above step.
This lock time is then translated to a
Unix epoch time, as per POSIX.1-2001 (which removes the
buggy day February 29, 2100 in previous POSIX revisions).
The translation should use, at minimum, unsigned 32-bit
numbers to represent the Unix epoch time.
The Unix epoch time shall then be interpreted as an
nLockTime value, as per standard Bitcoin.
Whether it is possible to represent dates past 2038
will depend on whether standard Bitcoin can represent
nLockTime values to represent dates past
2038.
Since nLockTime is an unsigned 32-bit
value, it should be possible to represent dates until
06:28:15 UTC+0 2106-02-07.
Future versions of Bitcoin should be able to support
nLockTime larger than unsigned 32-bit,
in order to allow even later dates.
The reason for using an earlier lock time than the
specified date is given in the Rationale section of
this BIP.
=== Payment to a Timelocked Address ===
An ordinary P2SH payment is used to provide funds to a
timelocked address.
The script below is used as the redeemScript
for the P2SH payment:
OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Once the redeemScript is derived, the hash is
determined, and an ordinary P2SH output with the below
scriptPubKey used:
OP_HASH160 OP_EQUAL
In case of SegWit deployment, SegWit-compatible wallets
should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per
the output they would normally use in that situation.
Obviously, a timelocked address has an equivalent
Bitcoin 3 (P2SH) address.
A simple service or software that translates from a
public timelocked address to a P2SH address can be
created that makes timelocking (but not redemption)
backwards compatible with wallets that do not support
this BIP.
This proposal recommends that wallets supporting payment
to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should
reuse the same interface for paying to such addresses as
paying into timelocked addresses of this proposal.
=== Redemption of a Timelocked Redemption Code ===
To sweep a timelocked redemption code after the timelock,
one must provide the given redeemScript as
part of the scriptSig, of all unspent
outputs that pay to the given redeemScript
hash.
When sweeping a timelocked redemption code, first the
wallet must extract the private key from the redemption
code, then derive the public key, the public key hash,
the redeemScript, and finally the
redeemScript hash.
Then, the wallet must find all unspent outputs that pay
to the redeemScript hash via P2SH (and, in the
case of SegWit deployment, via P2SH-P2WSH and P2WSH).
For each such output, the wallet then generates a
transaction input with the below scriptSig, as
per usual P2SH redemptions:
The wallet then outputs to an address it can control.
As the Script involved uses OP_CHECKLOCKTIMEVERIFY,
the nSequence must be 0 and the
nLockTime must be equal to the computed
lock time.
This implies that the transaction cannot be transmitted
(and the funds cannot be sweeped)
until after the given lock time.
The above procedure is roughly identical to sweeping an
ordinary, exported private key.
This proposal recommends that wallets supporting a sweep
function should reuse the same interface for sweeping
individual private keys (wallet import format) for sweeping
timelocked redemption codes.
== Motivation ==
A key motivation for this BIP is to allow easy use of
OP_CHECKLOCKTIMEVERIFY by end-users.
The below are expected use cases of this proposal:

A user wants to purchase an amount of Bitcoin,

and subsequently wait for an amount of time before
cashing out.
The user fears that he or she may have "weak hands",
i.e. sell unfavorably on a temporary dip, and thus
commits the coins into a timelocked fund that can
only be opened after a specific date.

A user wants to gift an amount of Bitcoins to

an infant or minor, and wants the fund to not be spent
on ill-advised purchases until the infant or minor
reaches the age of maturity.

A user may wish to prepare some kind of monthly subsidy

or allowance to another user, and prepares a series of
timelocked addresses, redeemable at some set date on
each month, and provides the private redemption codes to
the beneficiary.

A user may fear duress or ransom for a particular

future time horizon, and voluntarily impose a lock time
during which a majority of their funds cannot be spent.
== Rationale ==
While in principle, this proposal may be implemented as a
separate service or software, we should consider the long
time horizons that may be desired by users.
A user using a particular software to timelock a fund may
have concerns, for example, of specifying a timelock
18 years in the future for a gift or inheritance to a
newborn infant.
The software or service may no longer exist after 18 years,
unless the user himself or herself takes over maintenance
of that software or service.
By having a single standard for timelocked funds that is
shared and common among multiple implementations of Bitcoin
wallets, the user has some assurance that the redemption code
for the funds is still useable after 18 years.
Further, a publicly-accessible standard specifying how the
funds can be redeemed will allow technically-capable users
or beneficiaries to create software that can redeem the
timelocked fund.
This proposal provides a timelock at the granularity of a
day.
The expectation is that users will have long time
durations of months or years, so that the ability to
specify exact times, which would require specifying the
timezone, is unneeded.
The actual timeout used is 1000h of the day before the
human-readable date, so that timezones of UTC+14 will
definitely be able to redeem the money starting at
0000h of the human-readable date, local time (UTC+14).
Given the expectation that users will use long time
durations, the fact that timezones of UTC-12 will
actually be able to redeem the funds on 2200h UTC-12
time two days before can be considered an acceptable
error.
The human-readable date is formatted according to
[https://www.iso.org/iso-8601-date-and-time-format.html
ISO standard dates], with the dashes removed.
Dashes may prevent double-click selection, making
usability of these addresses less desirable.
The bc or tb is after the
date since the date is composed of digits and the bech32
separator itself is the digit 1. One
simply needs to compare hedlbc202111211...
and hedl20211121bc1....
A version quintet is added in case of a...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014714.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

I think opt-in RBF is misunderstood

Ok, for starters please note that I am strongly opposed to full-RBF (ability to double spend any transaction), and I've campaigned against full-RBF and most of Peter Todd's shenanigans since they were first suggested. I also support Bitcoin Classic and a 2MB hard fork, so I'm certainly not apologizing for any of the Core developers behavior, and please don't knee-jerk downvote me :)
However, I think a lot of people misunderstand the opt-in RBF functionality coming in 0.12. As it's currently implemented (and will probably be released in the final version), there is now a way to create a transaction and specifically request for that transaction only that you would like to be able to double spend it. Yes, you could argue that it's a useless feature and most people don't need it, however you could also argue that flexibility is useful for the bitcoin network.
It's important to note that with the new opt-in RBF:
Despite this, there are lots of comments saying that opt-in RBF is dangerous/bad:
https://www.reddit.com/btc/comments/422ge4/pieter_wuille_optin_rbf_is_not_theft_its/ https://www.reddit.com/btc/comments/421ig0/wang_chun_f2pool_on_github_confirmed_chinese/ https://bitcoinclassic.consider.it/revert-opt-in-rbf
Does anyone actually disagree that people should be allowed to explicitly note on their transaction (extremely clear to the merchant) that they want to be able to double spend it? If so, what is the reason for that?
I don't personally think it's a very useful feature, but if some people want to do that then I don't have a problem with it, so long as it's clear to everyone that the sender requested the ability to double spend that transaction so the merchant knows to be cautious. It seems counterproductive trying to reduce flexibility of bitcoin transactions for different use cases (after all, that's what we want for bitcoin to succeed).
submitted by cryptoinside to btc [link] [comments]

Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) | Matt Corallo | Mar 16 2015

Matt Corallo on Mar 16 2015:
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the height of the output being spent and then has
identical semantics to CLTV.
A slightly different API (and different name) was described by maaku at
http://www.reddit.com/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
which does a better job of saving softfork-available opcode space.
There are two major drawbacks to adding such an operation, however.
1) More transaction information is exposed inside the script (prior to
CLTV we only had the sigchecking operation exposed, with a CLTV and
RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).
2) Bitcoin Core's mempool invariant of "all transactions in the mempool
could be thrown into one overside block and aside from block size, it
would be valid" becomes harder to enforce. Currently, during reorgs,
coinbase spends need checked (specifically, anything spending THE
coinbase 100 blocks ago needs checked) and locktime transactions need
checked. With such a new operation, any script which used this new
opcode during its execution would need to be re-evaluated during reorgs.
I think both of these requirements are reasonable and not particularly
cumbersome, and the value of such an operation is quite nice for some
protocols (including settings setting up a contest interval in a
sidechain data validation operation).
Thoughts?
Matt
On 10/01/14 13:08, Peter Todd wrote:
I've written a reference implementation and BIP draft for a new opcode,
CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:
https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
The reference implementation, including a full-set of unittests for the
opcode semantics can be found at:
https://github.com/petertodd/bitcoin/compare/checklocktimeverify

BIP:
Title: OP_CHECKLOCKTIMEVERIFY
Author: Peter Todd <pete at petertodd.org>
Status: Draft
Type: Standards Track
Created: 2014-10-01

==Abstract==
This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin
scripting system that allows a transaction output to be made unspendable until
some point in the future.
==Summary==
CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it
compares the top item on the stack to the nLockTime field of the transaction
containing the scriptSig. If that top stack item is greater than the transation
nLockTime the script fails immediately, otherwise script evaluation continues
as though a NOP was executed.
The nLockTime field in a transaction prevents the transaction from being mined
until either a certain block height, or block time, has been reached. By
comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we
indirectly verify that the desired block height or block time has been reached;
until that block height or block time has been reached the transaction output
remains unspendable.
==Motivation==
The nLockTime field in transactions makes it possible to prove that a
transaction output can be spent in the future: a valid signature for a
transaction with the desired nLockTime can be constructed, proving that it is
possible to spend the output with that signature when the nLockTime is reached.
An example where this technique is used is in micro-payment channels, where the
nLockTime field proves that should the receiver vanish the sender is guaranteed
to get all their escrowed funds back when the nLockTime is reached.
However the nLockTime field is insufficient if you wish to prove that
transaction output ''can-not'' be spent until some time in the future, as there
is no way to prove that the secret keys corresponding to the pubkeys controling
the funds have not been used to create a valid signature.
===Escrow===
If Alice and Bob jointly operate a business they may want to
ensure that all funds are kept in 2-of-2 multisig transaction outputs that
require the co-operation of both parties to spend. However, they recognise that
in exceptional circumstances such as either party getting "hit by a bus" they
need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny,
to act as a third-party.
With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with
either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
not to have immediate access to the funds to discourage bad actors from
attempting to get the secret keys from him by force.
However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
the form:
IF  CHECKLOCKTIMEVERIFY DROP  CHECKSIGVERIFY 1 ELSE 2 ENDIF   2 CHECKMULTISIG 
At any time the funds can be spent with the following scriptSig:
  0 
After 3 months have passed Lenny and one of either Alice or Bob can spend the
funds with the following scriptSig:
  1 
===Non-interactive time-locked refunds===
There exist a number of protocols where a transaction output is created that
the co-operation of both parties to spend the output. To ensure the failure of
one party does not result in the funds becoming lost refund transactions are
setup in advance using nLockTime. These refund transactions need to be created
interactively, and additionaly, are currently vulnerable to transaction
mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the
interactive setup with a non-interactive setup, and additionally, making
transaction mutability a non-issue.
====Two-factor wallets====
Services like GreenAddress store Bitcoins with 2-of-2 multisig scriptPubKey's
such that one keypair is controlled by the user, and the other keypair is
controlled by the service. To spend funds the user uses locally installed
wallet software that generates one of the required signatures, and then uses a
2nd-factor authentication method to authorize the service to create the second
SIGHASH_NONE signature that is locked until some time in the future and sends
the user that signature for storage. If the user needs to spend their funds and
the service is not available, they wait until the nLockTime expires.
The problem is there exist numerous occasions the user will not have a valid
signature for some or all of their transaction outputs. With
CHECKLOCKTIMEVERIFY rather than creating refund signatures on demand
scriptPubKeys of the following form are used instead:
IF  CHECKSIGVERIFY ELSE  CHECKLOCKTIMEVERIFY DROP ENDIF  CHECKSIG 
Now the user is always able to spend their funds without the co-operation of
the service by waiting for the expiry time to be reached.
====Micropayment Channels====
Jeremy Spilman style micropayment channels first setup a deposit controlled by
2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends
the output of tx1 to payor and payee. Prior to publishing tx1 a refund
transaction is created, tx3, to ensure that should the payee vanish the payor
can get their deposit back. The process by which the refund transaction is
created is currently vulnerable to transaction mutability attacks, and
additionally, requires the payor to store the refund. Using the same
scriptPubKey from as in the Two-factor wallets example solves both these issues.
===Trustless Payments for Publishing Data===
The PayPub protocol makes it possible to pay for information in a trustless way
by first proving that an encrypted file contains the desired data, and secondly
crafting scriptPubKeys used for payment such that spending them reveals the
encryption keys to the data. However the existing implementation has a
significant flaw: the publisher can delay the release of the keys indefinitely.
This problem can be solved interactively with the refund transaction technique;
with CHECKLOCKTIMEVERIFY the problem can be non-interactively solved using
scriptPubKeys of the following form:
IF HASH160  EQUALVERIFY  CHECKSIG ELSE  CHECKLOCKTIMEVERIFY DROP  CHECKSIG ENDIF 
The buyer of the data is now making a secure offer with an expiry time. If the
publisher fails to accept the offer before the expiry time is reached the buyer
can cancel the offer by spending the output.
===Proving sacrifice to miners' fees===
Proving the sacrifice of some limited resource is a common technique in a
variety of cryptographic protocols. Proving sacrifices of coins to mining fees
has been proposed as a ''universal public good'' to which the sacrifice could
be directed, rather than simply destroying the coins. However doing so is
non-trivial, and even the best existing technqiue - announce-commit sacrifices
create outputs that are provably spendable by anyone (thus to mining fees
assuming miners behave optimally and rationally) but only at a time
sufficiently far into the future that large miners profitably can't sell the
sacrifices at a discount.
===Replacing the nLockTime field entirely===
As an aside, note how if the SignatureHash() algorithm could optionally cover
part of the scriptSig the signature could require that the scriptSig contain
CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed.
(the CODESEPARATOR opcode came very close to making this possible in v0.1 of
Bitcoin) This per-signature capability could replace the per-transaction
nLockTime field entirely as a valid signature would now be the proof that a
transaction output ''can'' be spent.
==Detailed Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP2: { // CHECKLOCKTIMEVERIFY // // (nLockTime -- nLockTime ) if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) break; // not enabled; treat as a NOP if (stack.size() < 1) return false; // Note that elsewhere numeric opcodes are limited to // operands in the range -2**31+1 to 2**31-1, however it is // legal for opcodes to produce results exceeding that // range. This limitation is implemented by CScriptNum's // default 4-byte limit. // // If we kept to that limit we'd have a year 2038 problem, // even though the nLockTime field in transactions // themselves is uint32 which only becomes meaningless // after the year 2106. // // Thus as a special case we tell CScriptNum to accept up // to 5-byte bignums, which are good until 2**32-1, the // same limit as the nLockTime field itself. const CScriptNum nLockTime(stacktop(-1), 5); // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKLOCKTIMEVERIFY. if (nLockTime < 0) return false; // There are two times of nLockTime: lock-by-blockheight // and lock-by-blocktime, distinguished by whether // nLockTime < LOCKTIME_THRESHOLD. // // We want to compare apples to apples, so fail the script // unless the type of nLockTime being tested is the same as // the nLockTime in the transaction. if (!( (txTo.nLockTime < LOCKTIME_THRESHOLD && nLockTime < LOCKTIME_THRESHOLD) || (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD) )) return false; // Now that we know we're comparing apples-to-apples, the // comparison is a simple numeric one. if (nLockTime > (int64_t)txTo.nLockTime) return false; // Finally the nLockTime feature can be disabled and thus // CHECKLOCKTIMEVERIFY bypassed if every txin has been // finalized by setting nSequence to maxint. The // transaction would be allowed into the blockchain, making // the opcode ineffective. // // Testing if this vin is not final is sufficient to // prevent this condition. Alternatively we could test all // inputs, but testing just this input minimizes the data // required to prove correct CHECKLOCKTIMEVERIFY execution. if (txTo.vin[nIn].IsFinal()) return false; break; } 
https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4
==Upgrade and Testing Plan==
TBD
==Credits==
Thanks goes to Gregory Maxwell for suggesting that the argument be compared
against the per-transaction nLockTime, rather than the current block height and
time.
==References==
PayPub - https://github.com/unsystem/paypub
Jeremy Spilman Micropayment Channels - http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html
==Copyright==
This document is placed in the public domain.
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-March/007714.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

BIP 68 (Relative Locktime) bug | Tom Harding | Jul 05 2015

Tom Harding on Jul 05 2015:
Since you're removing a working capability, you should be the one to
prove it is unneeded.
But the simple example is the case where the input is also locked.
On 7/5/2015 9:17 AM, Mark Friedenbach wrote:
Can you construct an example? Are there use cases where there is a
need for an enforced lock time in a transaction with inputs that are
not confirmed at the time the lock time expires?
On Jul 5, 2015 8:00 AM, "Tom Harding" <tomh at thinlink.com
> wrote:
BIP 68 uses nSequence to specify relative locktime, but nSequence also continues to condition the transaction-level locktime. This dual effect will prevent a transaction from having an effective nLocktime without also requiring at least one of its inputs to be mined at least one block (or one second) ahead of its parent. The fix is to shift the semantics so that nSequence = MAX_INT - 1 specifies 0 relative locktime, rather than 1. This change will also preserve the semantics of transactions that have already been created with the specific nSequence value MAX_INT - 1 (for example all transactions created by the bitcoin core wallet starting in 0.11). _______________________________________________ bitcoin-dev mailing list 
bitcoin-dev at lists.linuxfoundation.org
 
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150705/7e1dd1b2/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009347.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin dev meeting in layman's terms (2015-10-8) | G1lius Caesar | Oct 10 2015

G1lius Caesar on Oct 10 2015:
Once again my attempt to summarize and explain the weekly bitcoin developer
meeting in layman's terms.
Link to last weeks layman's summarization:
https://www.mail-archive.com/[email protected]on.org/msg02445.html
Disclaimer
Please bare in mind I'm not a developer and I'd have problems coding "hello
world!", so some things might be incorrect or plain wrong.
Like any other write-up it likely contains personal biases, although I try
to stay as neutral as I can.
There are no decisions being made in these meetings, so if I say "everyone
agrees" this means everyone present in the meeting, that's not consensus,
but since a fair amount of devs are present it's a good representation.
The dev IRC and mailinglist are for bitcoin development purposes. If you
have not contributed actual code to a bitcoin-implementation, this is
probably not the place you want to reach out to. There are many places to
discuss things that the developers read, including this sub-reddit.
link to this week logs (
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/08#l1444330778.0 )
link to meeting minutes (
https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit
)
Main topics discussed this week where:
Mempool limiting: chain limits
Low-S change
CLTV & CSV review
Creation of bitcoin discuss mailing list
off-topic but important notice
This issue ( https://github.com/feross/buffepull/81 ) has made most JS
bitcoin software vulnerable to generating incorrect public keys.
"This is an ecosystem threat with the potential to cause millions of
dollars in losses that needs higher visibility; though it's not a bitcoin
core / bitcoin network issue.
Common, critical, JS code is broken that may cause the generation of
incorrect pubkeys (among other issues). Anyone who cares for a JS
implementation should read that PR."
Mempool limiting: chain limits
(c/p from last week)
Chain in this context means connected transactions. When you send a
transaction that depends on another transaction that has yet to be
confirmed we talk about a chain of transactions.
Miners ideally take the whole chain into account instead of just every
single transaction (although that's not widely implemented afaik). So while
a single transaction might not have a sufficient fee, a depending
transaction could have a high enough fee to make it worthwhile to mine both.
This is commonly known as child-pays-for-parent.
Since you can make these chains very big it's possible to clog up the
mempool this way.
The first unconfirmed transaction is called the ancestor and the
transactions depending on it the descendants. The total amount of
transactions is reffered to as "packages".
As said in "Chain limits" last week Morcos did write a proposal about
lowering the default limits for transaction-chains.
2 use cases came up which are currently in use or happened before:
As example: someone buys bitcoin from a website and can spend those bitcoin
in the marketplace of the same website without waiting for confirmation in
order to improve the bitcoin user-experience. This leaves a sequential
transaction chain. They don't need to chain more than 5 transactions deep
for this, and it falls within the proposed limits.
What's not within the proposed limits is the chain of +/- 100 transactions
a company had during the spam-attacks. These where simply increased
activities by end-users while not enough UTXO's where available (3 to be
precise)(UTXO: unspent transaction output, an output that can be used as
input for a new transaction).
Notably this is with the best practices of using confirmed transactions
first.
Ways this can be solved from the company's end is to have more UTXO's
available before hand, bundling transactions (which requires delaying
customer's request) or using replace-by-fee to add payees (which saves
blockchain space, is cheaper in fees and gets transactions through quicker,
but is not widely deployed by miners atm).
Bare in mind these proposals are for default values for the memorypool, not
in any way hard limits.
Sense of urgency. Quoting sipa: "my mempool is 2.5G... we better get some
solution!"
Current attack analysis assumes child-pays-for-parent mining, it should
probably be done again without.
Higher limits on number of transactions increase attack-vectors.
Proposed number of transactions gets some push-back, total size limit not.
Mixing default values (for example having a 50% of a 10/10 limit and 50% of
a 100/100 limit) wastes bandwidth while there are too many factors that
limit utility of long chains as well.
25 transaction limit ought to be enough for everyone (for now).
Review & test "Limit mempool by throwing away the cheapest txn and setting
min relay fee to it" ( https://github.com/bitcoin/bitcoin/pull/6722 )
Provide support for "Lower default limits for tx chains" (
https://github.com/bitcoin/bitcoin/pull/6771 ) aka convince people 25
should be enough.
Low-S change
This is in regards to the recent malleability attack. Which is caused by a
value 'S' in the ECDSA signature which can be 2 values, a high and low
value and still be valid. Resulting in different transaction id's. more
info:
http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high
A solution for this is to require nodes to have the "low-s" encoding for
signatures.
Downside is that it will block most transactions made by sufficiently out
of date software (+/- pre-march 2014)
This does not replace the need for BIP62, it only eliminates the cheap DOS
attack.
95% of transactions already confirm to this, and more fixes have been
applied since.
BlueMatt has a node which several people are running that auto-malleates to
low-s transactions.
Questions whether we release it ASAP or wait for the next release and get
it to a couple of miners in the meantime (possibly with
auto-lowS-malleating)
Contact miners about "Test LowS in standardness, removes nuisance
malleability vector" ( https://github.com/bitcoin/bitcoin/pull/6769 )
Release scheduled for the end of the month, together with likely
check-lock-time-verify and possibly check-sequence-verfiy.
CLTV & CSV backport review
CLTV: checkLockTimeVerify
CSV: checkSequenceVerify
Both new time-related OP-codes.
Been discussed heavily last week.
CSV doesn't seem ready enough for release later this month.
There's no clarity on how things look when all 3 time related pull-requests
are merged.
There's a number of people still reviewing the pull-requests.
Uncertainty and confusion about whether the semantics are final or not (in
regards to using bits from nSequence). nSequence are 4 bytes intended for
sequencing time-locked transactions, but this never got used.
Now these bytes are being repurposed for a mixture of things. Currently the
plan is: " bits 0..15 are the relative locktime, bit 30 determines units
(0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on,
1: off). bits 16..29 are masked off and can take any value."
Clarification from maaku regarding nSequence for BIP68. (after the meeting
he explained he was waiting for opinions, but not enough people seemed to
know the issue at hand)
Continue review of pull requests 6312 (
https://github.com/bitcoin/bitcoin/pull/6312 ), 6564 (
https://github.com/bitcoin/bitcoin/pull/6564 ) and 6566 (
https://github.com/bitcoin/bitcoin/pull/6566 )
Creation of bitcoin discuss mailing list
The bitcoin-dev mailing list is intented for technical discussions only.
There's things that don't belong there but need to be discussed anyway.
Now this is done in bitcoin-dev, but the volume of this is getting too big.
There's recently also an influx of really inappropriate posts, level
kindergarden (
https://www.mail-archive.com/[email protected]/msg02539.html
).
No clarity about who are the moderators.
Next week there'll be a bitcoin-discuss list created.
Decisions are needed as to who'll become the moderators for that and
bitcoin-dev.
Decisions are needed as to what will be the list and moderation policies.
The bitcoin-discuss list will be created as well as a simple website
listing all the lists and corresponding policies.
A meeting is scheduled on monday to discuss the moderation and policies of
said lists.
Participants
morcos Alex Morcos
gmaxwell Gregory Maxwell
wumpus Wladimir J. van der Laan
sipa Pieter Wuille
BlueMatt Matt Corallo
btcdrak btcdrak
pe...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011496.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Private "Merkle" Vaults for the Bitcoin system | Jérôme Legoupil | Apr 24 2016

Jérôme Legoupil on Apr 24 2016:
In Febuary, an email intitled "Bitcoin Vaults" was addressed to this mailing list linking to a paper on “covenants” (see mail below) describing a way to apply recursive restrictions temporarily or permanently on bitcoins (for digital asset use-cases) and Bitcoin Vaults were offered as an application (thanks to the authors for sharing their work with the community, I personally found this paper insightful and inspiring). Unfortunately, this proposal isn’t fungibility friendly and could lead Bitcoin to undesirable outcomes.
What follows is an attempt to design Vaults that preserve Bitcoin’s fungibility and keep their defensive attributes private from blockchain observers and from potential insider participants: the Vault’s defence is incrementally revealed when executed. If I am a war chief defending a castle, I’m certainly not going to show my defence strategy to the world and if it leaked to the enemy, it would greatly weaken my chances to succeed: greater privacy leads to greater security.
Vaults enable important use-cases for Bitcoin as a store of value, in particular the tricky but critical use-case of successions (heritages).
— General idea —
This design restricts the bitcoins in a Vault to a private, predefined, finite (no patterns) and unforgeable set of authorized actions defined by the Vault creator at the setup.
Definition: an authorized action (or action) is an authorized address the bitcoins inside a Vault can be sent to, with an authorized timelock.
Action = < timelock>
The Vault can be defined as a set of parent/child authorized actions. This enables the Vault creator to construct a Merkle tree of his Vault. During the setup, the creator computes the hashs of every authorized action, and builds his Merkle tree from the bottom, up to the top Merkle root. The Vault creator must give the appropriate Merkle proofs (authorizations) to the Vault participants (if any) according to the authorizations he grants them, and when someone wants to move funds inside or out of the Vault, he needs to provide to the network (in addition of a valid signature) the Merkle proof that demonstrates that his action is authorized by the Vault. The network can verify that:
Hash [ Merkle_proof(Action) + Hash(Action) ] == Merkle_proof(Parent_Action)
The Merkle tree must be destroyed once the setup is completed. Storing the tree anywhere is unnecessary and endangers the Vault's privacy.
— Example —
In this example, the Vault is composed of the actions A, B, C, D:
A-B-C
 \ `-D 
If H is the hash function, the Merkle tree is:
 Merkle_root / \ H(H(H(H(D)+H(1)) + H(H(C)+H(1))) + H(B)) H(A) / \ 
H(H(H(D)+H(1)) + H(H(C)+H(1))) H(B)
 / \ 
H(H(D)+H(1)) H(H(C)+H(1))
 / \ 1 1 
Note: 1 are terminations to signal to the network that the coins are now allowed to exit the Vault. If the 1-terminations were not added, the bitcoins would be locked forever in the Vault because it would require to reverse H to spend them.
With notations:
 Merkle_root / \ Merkle_Proof(A) H(A) / \ 
Merkle_Proof(parent of C) = Merkle_Proof(B) H(B)
 / \ Merkle_Proof(C) H(H(C)+H(1)) \ 1 
— nSequence —
nSequence has different timelock meanings for the different time related OP codes:
OP_CLTV: a tx spending the outputs of a [parent tx with nSequence] is invalid if current block number <= nSequence
OP_CSV: a tx spending the outputs of a [parent tx with nSequence] is invalid if current block number <= block number of the parent tx + nSequence
New meaning of nSequence for OP_VAULT:
OP_VAULT: a tx with nSequence is invalid if current block number <= block number of the parent tx + nSequence
—OP_VAULT—
This opcode checks if the tx timelock allows the tx to be included in a block and outputs a hash.
OP_VAULT (nSequence, Merkle_proof(Action), pubKeyHash)
{
IF (current block number >= Max(block number of the parent outputs) + nSequence of current tx)
 hAction=H(H(pubKeyHash)+H(nSequence)); h=H(Merkle_proof(Action)+hAction); return h; 
ELSE
 return H(0); // the tx cannot be included in a block yet 
}
—Vault transaction structures—
Funding tx
scriptSig=
scriptPubKey=
<3> OP_PICK OP_HASH160 OP_VAULT OP_EQUALVERIFY OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Vault tx
scriptSig=
scriptPubKey=
<3> OP_PICK OP_HASH160 OP_VAULT OP_EQUALVERIFY OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Exit tx
scriptSig=
scriptPubKey=
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Note: The exit tx can also use OP_VAULT if it is exiting the Vault while funding another Vault.
—New consensus rules— (enforcement of OP_VAULT txs)
IF
// this new rule concerns only Vault txs...
(parent tx VAULT_FLAG_ENABLE)
AND
// ...that are not permitted to exit the Vault if the action is not terminated by 1 in the Merkle tree
(
H( in tx’s scriptSig + H(H(H(pubKeyHash)+H(nSequence))) + H(1))) != in parent tx’s scriptSig
)
AND
{
// the tx must be flagged as a Vault tx
(tx VAULT_FLAG_DISABLE)
OR
// the tx violates the Merkle tree data structure
( in tx’s scriptSig != in tx’s scriptPubKey)
}
THEN the transaction is INVALID.
—Privacy—
In this design, Vault txs are CoinJoin/CT compatible (joining with other Vault txs) and perhaps Vault users will be willing to way for days or weeks to achieve maximum privacy, as they are susceptible of holding significant value in these structures.
—Use-cases—
"Smart successions" : a morbid yet critical use-case for Bitcoin as a store of value
Bitcoin currently struggles in dealing with successions in a trustless manner. How does the Bitcoin system know when the succession should be executed ? What happens in case of conflict between the heirs ? It’s a tricky but important use-case.
Bitcoin successions are dealt with by either sharing decrypted private keys with the heirs (trusting they won’t take the coins before due time or won’t have them stolen), renting a safe at the bank and making a testament (trusting the bank) or simply hiding the keys and hoping the heirs will find them when you disappear. None of these schemes are satisfying, especially when dealing with multiple heirs. This gap could likely hold back investors from investing a significant portion of their wealth in Bitcoin if they don’t have a trustless and secure mechanism that guarantees their succession will be executed according to their will.
Funding addr
\ `->Transfert addr—0—>Alice addr (1) | \ | `-50000—>Multisig2/2—>Bob addr | \ (2) | `—>Carol addr | `-100000—>Multisig2/3—>Bob addr \ (3) `—>Carol addr 
(1) Alice’s recovery address in case Bob and Carol were too impatient to spend the heritage.
(2) Alice added a Multisig2/2 controlled by Bob and Carol. Alice gave Bob and Carol each, half of the Merkel proof to pull the funds into Multisig2/2: first Bob and Carol need to agree on the conditions of the succession and sign the exit transaction from the Multisig2/2, than they can share their Merkel proof halves and pull the funds.
(3) Arbitration in case of disagreement (or if Bob or Carol is uncooperative, or disappeared): Alice added a Multisig2/3 involving an arbitrator in case Alice and Bob couldn’t find an agreement after 20’000 blocks or something. The arbitrator has no information on the succession until Bob or Carol asks for his assistance. Alice gave each Bob and Carol the full Merkel proof to pull the funds to Multisig2/3.
We can imagine services assisting in the Vault setups and in the blockchain monitoring, enabling successions to occur entirely on-chain, in a trustless, private and peer-to-peer manner, outside of the current financial system.
Scorched earth policies if the Vault defender is entirely compromised
The following defence strategy is inspired from the paper mentionned in the introduction :
Funding addr
\ `->Transfert addr-1000->Spending addr \ `-0->Recovery addr1-100->Recovery addr2-1000->Recovery addr3 ...[message truncated here by reddit bot]... 
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012617.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Does RBF implementation change the likelihood that a "non-RBF" (max value nSequence) transaction can be double-spent?

From this convo with bits-of-change:
If a post-RBF node sees a higher-fee double-spend of a max value nSequence transaction already in its mempool, does it drop the newer transaction as it does now?
submitted by tsontar to Bitcoin [link] [comments]

The use of tx version field in BIP62 and 68 | jl2012 at xbt.hk | Aug 08 2015

jl2012 at xbt.hk on Aug 08 2015:
BIP68 rules and some of the BIP62 rules are applied only if the tx
version is >=2 and >=3 respectively. Therefore, it is not possible to
create a tx which follows BIP62 but not BIP68. If we introduce v4 tx
later, BIP62 and BIP68 will all become mandatory.
Some rules, e.g. "scriptPubKey evaluation will be required to result in
a single non-zero value" in BIP62, will cause trouble when we try to
introduce a new script system with softfork.
I suggest to divide the tx version field into 2 parts: the higher 4 bits
and lower 28 bits.
BIP62 is active for a tx if its highest bits are 0000, and the second
lowest bit is 1.
BIP68 is active for a tx if its highest bits are 0000, and the third
lowest bit is 1.
So it will be easier for us to re-purpose the nSequence, or to take
advantage of malleability in the future. If this is adopted, the
nSequence high bit requirement in BIP68 becomes unnecessary as we could
easily switch it off.
The low bits will allow 28 independent BIPs and should be ample for many
years. When they are exhausted, we can switch the high bits to a
different number (1-15) and redefine the meaning of low bits. By that
time, some of the 28 BIPs might have become obsoleted or could be
merged.
(I'm not sure if there are other draft BIPs with similar interpretation
of tx version but the comments above should also apply to them)
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Opt-in Full Replace-By-Fee (Full-RBF) | Peter Todd | Nov 17 2015

Peter Todd on Nov 17 2015:
Summary
Opt-In Full-RBF allows senders to opt-into full-RBF semantics for their
transactions in a way that allows receivers to detect if the sender has
done so. Existing "first-seen" mempool semantics are left unchanged for
transactions that do not opt-in.
At last week's IRC meeting(1) we decided to merge the opt-in Full-RBF
pull-req(2), pending code review and this post, so this feature will
likely make it into Bitcoin Core v0.12.0
Specification
A transaction is considered to have opted into full-RBF semantics if
nSequence < 0xFFFFFFFF-1 on at least one input. Nodes that respect the
opt-in will allow such opt-in transactions (and their descendents) to be
replaced in the mempool if they meet the economic replacement criteria.
Transactions in blocks are of course unaffected.
To detect if a transaction may be replaced check if it or any
unconfirmed ancestors have set nSequence < 0xFFFFFFFF-1 on any inputs.
Rational
nSequence is used for opting in as it is the only "free-form" field
available for that purpose. Opt-in per output was proposed as well by
Luke-Jr, however the CTxOut data structure simply doesn't contain any
extra fields to use for that purpose. nSequence-based opt-in is also
compatible with the consensus-enforced transaction replacement semantics
in BIP68.
Allowing replacement if any input opts in vs. all inputs opting in is
chosen to ensure that transactions authored by multiple parties aren't
held up by the actions of a single party. Additionally, in the
multi-party scenario the value of any zeroconf guarantees are especially
dubious.
Replacement is allowed even if unconfirmed children did not opt-in to
ensure receivers can't maliciously prevent a replacement by spending the
funds. Additionally, any reasonable attempt at determining if a
transaction can be double-spent has to look at all unconfirmed parents
anyway.
Feedback from wallet authors indicates that first-seen-safe RBF isn't
very useful in practice due to the limitations inherent in FSS rules;
opt-in full-RBF doesn't preclude FSS-RBF from also being implemented.
Compatibility
Opt-in RBF transactions are currently mined by 100% of the hashing
power. Bitcoin Core has been producing transactions with non-maxint
nSequence since v0.11.0 to discourage fee sniping(3), and currently no
wallets are known that display such transactions yet do not display
opt-in RBF transactions.
Demonstrations
https://github.com/petertodd/replace-by-fee-tools#incremental-send-many
1) http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2015-Novembe000010.html
2) https://github.com/bitcoin/bitcoin/pull/6871
3) https://github.com/bitcoin/bitcoin/pull/2340

'peter'[:-1]@petertodd.org
00000000000000000f30567c63f8f4f079a8ecc2ab3d380bc7dc370e792b0a3a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151116/d33dde25/attachment.sig
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Novembe011783.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-10-15) | G1lius Caesar | Oct 19 2015

G1lius Caesar on Oct 19 2015:
Once again my attempt to summerize and explain the weekly bitcoin developer
meeting in layman's terms.
Link to last weeks summerization (
https://www.reddit.com/Bitcoin/comments/3o7bi6/bitcoin_dev_meeting_in_laymans_terms_2015108/
)
Link to this weeks on reddit:
https://www.reddit.com/Bitcoin/comments/3pcinz/bitcoin_dev_irc_meeting_in_laymans_terms_20151015/
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello
world!", so some things might be incorrect or plain wrong.
Like any other write-up it likely contains personal biases, although I try
to stay as neutral as I can.
There are no decisions being made in these meetings, so if I say "everyone
agrees" this means everyone present in the meeting, that's not consensus,
but since a fair amount of devs are present it's a good representation.
The dev IRC and mailinglist are for bitcoin development purposes. If you
have not contributed actual code to a bitcoin-implementation, this is
probably not the place you want to reach out to. There are many places to
discuss things that the developers read, including this sub-reddit.
link to this week logs
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444935660.0
Meeting minutes by meetbot
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.html
Main topics discussed where:
Mempool limiting
sendheaders BIP
versionbits
dev/discuss list policy
CHECKSEQUENCEVERIFY
Mempool limiting
When a transaction is relayed across the network it is held by the nodes in
memory, until it gets into a block. All these transactions that sit in
memory are called the memorypool or mempool for short.
Like we could see during the spam-attack if there's a big back-log of
transactions that couldn't make it in the blockchain this mempool can get
pretty big resulting in nodes crashing.
To stop this from happening devs are trying to find a way to limit this
mempool, so a mechanism to reject and/or remove transactions from the
mempool. The hard part here is to make it so nodes can't be attacked by
abusing this mechanism.
So far the devs are going with TheBlueMatt's proposal of throwing away the
cheapest txn and setting the min relay fee to it
https://github.com/bitcoin/bitcoin/pull/6722
While testing, sipa encountered transactions that took 200ms to be accepted
into the mempool.
As it's the first time he has benchmarked this and the pull-request
shouldn't make an impact on these times it likely doesn't have anything to
do with this. However, such times are bad either way.
The average time in sipa's tests is 4ms. (After the meeting Morcos did some
benchmarking (
https://github.com/bitcoin/bitcoin/pull/6722#issuecomment-148874040 ) and
confirmed it was not specific to this PR, and pointed out the outliers come
from CheckInputs and HaveInputs (as you might guess, having to do with
checking the inputs)
Question on why we should revert the minrelay (minimum fee for nodes to
relay a transaction) back to 1000 (it has been set to 5000 to quick-fix the
mempool issues), sipa thinks it should be floating as well or the dust
limit becomes ineffective.
Review PR 6722 Limit mempool by throwing away the cheapest txn and setting
min relay fee to it https://github.com/bitcoin/bitcoin/pull/6722
Morcos/sipa will do some more benchmarks and comment on the PR ( morcos'
benchmark results
https://github.com/bitcoin/bitcoin/pull/6722#issuecomment-148874040 )
sendheaders BIP
send headers BIP
https://github.com/sdaftuabips/blob/add-sendheaders/bip-sendheaders.mediawiki
Copy/paste from the BIP:
Since the introduction of "headers-first" downloading of blocks in 0.10,
blocks will not be processed unless they are able to connect to a (valid)
headers chain. Consequently, block relay generally works as follows:
  1. A node (N) announces the new tip with an "inv" message, containing the
block hash
  1. A peer (P) responds to the "inv" with a "getheaders" message (to request
headers up to the new tip) and a "getdata" message for the new tip itself
  1. N responds with a "headers" message (with the header for the new block
along with any preceding headers unknown to P) and a "block" message
containing the new block
However, in the case where a new block is being announced that builds on
the tip, it would be generally more efficient if the node N just announced
the block header for the new block, rather than just the block hash, and
saved the peer from generating and transmitting the getheaders message (and
the required block locator).
Question on how to move forward. How to let the nodes know you want the
blockheader instead of the blockhash.
Options:
Extend the version message.
Have an "options" message that can send flags.
Send a "sendheaders" message early when connecting so the way peers want
their block announcement is immediately known.
Send a "sendheaders" message at any time, changing the way peers want their
block announcement from hashes to headers.
No one likes to extend the version message further.
There's no strong advantage to have an "options" message over a
"sendheaders" message.
Having the message being sent early on might be too constraining. Possible
usecase from morcos: "its entirely possible some future optimization may
say, i want to send sendheaders to these peers b/c they announce a lot of
new stuff to me and not these others b/c they don't".
Most people like this to be enable-only, so no message to get back to
receiving blockhashes. Which is how the BIP was drafted.
-meeting conclusion
sdaftuar does a pull-request for the BIP to get a number assigned and
proceeds with the BIP as drafted.
versionbits
BIP 9 https://github.com/bitcoin/bips/blob/mastebip-0009.mediawiki
Currently softforks have been done by the isSuperMajority mechanism,
meaning when 95% of the last X blocks has a version number higher than Y
the fork is deployed.
A new way of doing this is currently being worked on and that uses all bits
of the version number, appropriately being called versionbits. So instead
of a fork happening when the version is larger than (for example)
00000000011 (3), a fork happens when (for example) the 3rd bit is up (so
00100000011).
This way softforks can be deployed simultaneous and independant of each
other.
copy/paste from IRC, since I don't know what this specifically means:
CodeShark: so right now it's just a unit that implements the versionbits
logic but does not demonstrate its usage
I thought it would be better to actually integrate in a separate PR, but I
can add a demonstration
sipa: separate commit, same PR - i think we need something that's mergable
as a whole, to be able to see whether the whole thing easily backports
Codeshark (who's implementing versionbits) had some more remarks but no one
present had seemed to reviewed it, so not much use in discussing things
further.
review versionbits implementation
https://github.com/bitcoin/bitcoin/pull/6816
dev/discuss list policy
The bitcoin-dev mailing list is intented for technical discussions only.
There's things that don't belong there but need to be discussed anyway.
Now this is done in bitcoin-dev, but the volume of this is getting too big.
There's recently also an influx of really inappropriate posts, level
kindergarden
https://www.mail-archive.com/[email protected]/msg02539.html.
For the things that don't belong on bitcoin-dev, but need to be discussed
anyway there's a new list being created namely bitcoin-discuss as well as
clear policies and moderation for both.
Bitcoin-discuss was created, but the admin password wasn't distributed to
jgarzik who's willing to guide the moderatation.
Separate moderation-proposals have been done meanwhile.
People just want it to move on.
Since none of the people who proposed a moderation-scheme are present we'll
let them discuss it among each other and post their decisions publicly.
CHECKSEQUENCEVERIFY
CheckLockTimeVerify (CLTV) repurposes the nSequence field (nSequence are 4
bytes intended for sequencing time-locked transactions, but this never got
used). However, there's no way use these values in a bitcoin script.
CheckSequenceVerify (CSV) makes this field accessible to bitcoin scripts.
CLTV is pretty much done.
Check to see maaku moving one of the bits to allow for other
implementations to have better granularity has any objections.
As long as...[message truncated here by reddit bot]...
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011562.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

GossipRoom - YouTube Facebook's Libra Cryptocurrency - YouTube Christian Decker - History of the Lightning Network Bitcoin Price Prediction using Sentiment Analysis Bitcoin: How Cryptocurrencies Work - YouTube

Miniscript is a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, ... (NUM): Require that the nLockTime/nSequence value is at least NUM. NUM cannot be 0. sha256(HEX), hash256(HEX): Require that the preimage of 64-character HEX is revealed. The special value H can be used as HEX. ripemd160(HEX), hash160(HEX): Require that the preimage of 40-character HEX ... A Bitcoin transaction consists of a version number, a locktime value, a list of inputs and a list of outputs.. The primary functionality of a Bitcoin transaction is to transfer custody of bitcoin from one to another. A Bitcoin transaction can also serve as a vehicle for smart contracts, recording data, attestation and many other secondary functionalities. Bitcoin is a distributed, worldwide, decentralized digital money … Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts. r/Bitcoin. log in sign up. User account menu. 12. CheckSequenceVerify versus nSequence. Close. 12. Posted by. u/junzhli. 1 year ago. Archived. CheckSequenceVerify versus nSequence. What are the difference? As I know, both stand for ... The nSequence value is specified in either blocks or seconds, but in a slightly different format than we saw used in nLocktime. A type-flag is used to differentiate between values counting blocks and values counting time in seconds. The type-flag is set in the 23rd least-significant bit (i.e., value 1<<22). If the type-flag is set, then the nSequence value is interpreted as a multiple of 512 ... An transaction is a transfer of Bitcoin value that is broadcast to the network and collected into blocks. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions are buried ...

[index] [42878] [48202] [39818] [37302] [16478] [3522] [48680] [3554] [47609] [43791]

GossipRoom - YouTube

Whether or not it's worth investing in, the math behind Bitcoin is an elegant solution to some complex problems. Hosted by: Michael Aranda Special Thanks: Da... Christian Decker describes the history of off-chain protocols built on Bitcoin, from incrementing nSequence numbers to eltoo. "The Bitcoin Sequence" Bitcoins next crash may be $8000. Fibonacci retracements, elliot waves, the golden ratio but is an obvious and predictable bitcoin price pattern right in front of our faces? Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. Is bitcoin mining profitable? YES! if you have good multiple GPU's you can make some really good money... Thank you! for watching this video please leave a l...

#