Bitcoin pulse, guides and news: 12/13/19

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-12-17)

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 so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Replace-by-fee handling in wallets C++11 for 0.13
Replace-by-fee (RBF) handling in wallets
Currently when a node sees a transaction that spends the same output it ignores it. With RBF 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 RBF by changing the nSequence field of all inputs. This is a mempool policy for the upcoming 0.12 release. There's a good FAQ-ish post on reddit about it.
The feature freeze for 0.12 is in effect since December 1, outside of bugfixes, what's in the 0.12 branch now will be released. #7219 to make RBF policies optional (0 = never, 1 = always, 2 = opt-in) probably won't make it in 0.12. jonasschnelli and harding request good ideas for RBF wallet policies and ways to handle this. Android wallet bumps the fee via a click-to-bump UI (via CPFP). Adding bumping fees is fairly simple, doing more like adding in-and outputs probably hugely complicates the current wallet. For including in-and outputs you'd want to prepare a signed transaction with A+B and another signed transaction with just B spending from a change output created in A. For 0.13 we like to see at least a fee bump option and some raw transaction commands to alter a wallet transaction.
Take a look at #7062 Fix mempool limiting and replace-by-fee for PrioritiseTransaction for 0.12 Take a look at #7132 Add option to opt into full-RBF when sending funds
C++11 for 0.13
C++11 is an update of the C++ language. It offers new functionalities, an extended standard library, etc. Zerocash had to be written with some c++11 libraries and some IBLT simulation code was written in c++11, which they want to recycle for the eventual core commit.
The outstanding build issues are dependencies compatibility and Travis' compiler. There are concerns about the boost library as it's consensus critical. Removing boost usage (in consensus) before 0.13 removes that concern. A risk is that we get entrenched in C++11 irreversibly and find out when 0.13 is released a large part of the userbase can't handle it. Backports are also harder if the code starts to diverge too much. More testing would be good, but the travis pull tester is already slow, so adding more configurations might not be good. Possibly a 2nd free alternative to build more configurations in parallel. Both the zero-cash and bitcoin core team want automated testing of this stuff on many platforms, which can be done by buildbot. We can also reach out to distros for help. Wumpus is ready to switch builds to std=c++11 as soon as travis is building/passing.
Everyone wants C++11 for 0.13 swtich some builds to C++11
Participants
wumpus Wladimir J. van der Laan cfields Cory Fields sipa Pieter Wuille jonasshnelli Jonas Schnelli petertodd Peter Todd Luke-Jr Luke Dashjr nwilcox Nathan Wilcox zookolaptop Zooko Wilcox-O'Hearn sdaftuar Suhas Daftuar harding David A. Harding jgarzik Jeff Garzik btcdrak btcdrak 
Comic relief
19:03 petertodd wumpus: is the RBFhandling in the v0.12 branch what's going to be released? IE, have we feature frozen? 19:04 wumpus yes, we have feature frozen at dec 1 19:04 petertodd cool 19:04 petertodd or I should say, frozen 
( •_•) ( •_•)>⌐■-■ (⌐■_■) YYYYYYYEEEEEAAAAAAAAAAHHHHHHHHHHHH
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]

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

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 btc, Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I have altered this version very slightly to accommodate for bitcoin community 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.
link to this week logs (slightly bugged logs as you'll see)
Meeting minutes by meetbot
Main topics discussed where:
BIP68-related pull requests Eviction and onions BIP for opt-in RBF
Short topics/notes
Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly. Next year mid-february I'll be on vacation for a month, so I won't be able to do the meetings from 2016/02/18 to 2016/03/10. If there's anyone who's up for the challenge to take over during a week (and share the load with others) feel free to pm me. I'm announcing well in advance, so there's more chance to find some people and to not make this a last minute thing.
A lot of developers where traveling to the scaling bitcoin conference (videos), so this is again a shorter, and it'll likely be the same next week (as a lot of developers stay in Hong Kong for the developer meetup after the conference).
Also a reminder to anyone that's running a full node to update their node to core 11.2 or 10.4, btcd 0.12, client software which attempts to alter the Bitcoin protocol without overwhelming consensus version D, or any other node that supports BIP65 CLTV, to accommodate for the upcoming softfork. Not updating will mean you'll be trusting miners to produce valid blocks. 85% of miners advertise they support CLTV transactions and the softfork will activate when 95% is reached, currently (time of writing) +/- 30% of nodes is updated.
BIP68-related pull requests
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation. BIP 68 changes the meaning of the previously unused sequence number field to a relative locktime.
There is a pull-request for a small correction in the comments of the code. There's been work on optimizing CreateNewBlock (which does what it says). Morcos and sdaftuar are looking at two approaches, one of which will refactor the BIP68 implementation significantly. As the refactoring would be better done before BIP68 gets merged, it would be good to know which approach is better.
Look into the CreateNewBlock optimization approaches.
Eviction and onions
Starting with Tor version 0.2.7.1 it is possible to create hidden services programmatically. Bitcoin will now automatically create a hidden service to listen on if Tor is running.
Localhost peers are never evicted; so as soon as you show up on a hidden service someone can prevent anyone else from connecting to you trivially. Pull-request #7082 addresses this problem by using latency to detect actual local peers. You can also use whitelists to distinguish between real localhost connections and tor localhost connections, but that might break existing software. wumpus notes we should encourage using the whitelist for special peers in the long term.
Take a look at Pull-request #7082
BIP for opt-in RBF
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 the nSequence field of all inputs. This is a mempool policy for the upcoming 0.12 release. There's a good FAQ-ish post on reddit about it.
Question is if opt-in RBF should have a BIP or not. It is just policy code, however standardness has been covered before in BIPs. sdaftuar notes it's unfortunate that the only documentation for what wallet writers should do is in a single mailing list post. harding volunteers to write the BIP.
harding will write the BIP in coordination with petertodd.
Participants
wumpus Wladimir J. van der Laan morcos Alex Morcos btcdrak btcdrak sipa Pieter Wuille gmaxwell Gregory Maxwell cfields Cory Fields jonasschnelli Jonas Schnelli Diablo-D3 Patrick McFarland sdaftuar Suhas Daftuar harding David A. Harding jcorgan Johnathan Corgan 
Comic relief
19:26 cfields sec, i'll like the mail thread 19:26 sipa cfields: you'll "like" it, is it on facebook? 19:27 wumpus twitter has 'likes' now too :') 
submitted by G1lius to Bitcoin [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]

CHECKSEQUENCEVERIFY - We need more usecases to motivate the change | Peter Todd | Oct 03 2015

Peter Todd on Oct 03 2015:
BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY.
However, CSV does define behavior for the previously undefined nSequence
field, which is the only "free-form" field we currently have in the
transaction serialization format that can be used for future upgrades -
we should justify this new behavior carefully as it limits our options
in the future. Adding new fields to the serialization format is very
difficult, due to the very broad system-wide impact of the hard-fork
required to do so.
So we need to make the case for two main things:
1) We have applications that need a relative (instead of absolute CLTV)
2) Additionally to RCLTV, we need to implement this via nSequence
To show we need RCLTV BIP112 provides the example "Escrow with Timeout",
which is a need that was brought up by GreenAddress, among others; I
don't think we have an issue there, though getting more examples would
be a good thing. (the CLTV BIP describes seven use cases, and one
additional future use-case)
However I don't think we've done a good job showing why we need to
implement this feature via nSequence. BIP68 describes the new nSequence
semantics, and gives the rational for them as being a
"Consensus-enforced tx replacement" mechanism, with a bidirectional
payment channel as an example of this in action. However, the
bidirectional payment channel concept itself can be easily implemented
with CLTV alone. There is a small drawback in that the initial
transaction could be delayed, reducing the overall time the channel
exists, but the protocol already assumes that transactions can be
reliably confirmed within a day - significantly less than the proposed
30 days duration of the channel. That example alone I don't think
justifies a fairly complex soft-fork that limits future upgrades; we
need more justification.
So, what else can the community come up with? nSequence itself exists
because of a failed feature that turned out to not work as intended;
it'd be a shame to make that kind of mistake again, so let's get our
semantics and use-cases in the BIPs and documented before we deploy.

'peter'[:-1]@petertodd.org
00000000000000000ea95b4a24d0a510d4b5a98186f904dc16da07c41189d8b8
-------------- 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/20151003/f75f22e9/attachment.sig>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011357.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]

Alternative name for CHECKSEQUENCEVERIFY (BIP112) | Btc Drak | Nov 24 2015

Btc Drak on Nov 24 2015:
BIP68 introduces relative lock-time semantics to part of the nSequence
field leaving the majority of bits undefined for other future applications.
BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
limited to verifying transaction inputs according to BIP68's relative
lock-time[1], yet the name OP_CSV is much boarder than that. We spent
months limiting the number of bits used in BIP68 so they would be available
for future use cases, thus we have acknowledged there will be completely
different usecases that take advantage of unused nSequence bits.
For this reason I believe the BIP112 should be renamed specifically for
it's usecase, which is verifying the time/maturity of transaction inputs
relative to their inclusion in a block.
Suggestions:-
CHECKMATURITYVERIFY
RELATIVELOCKTIMEVERIFY
RCHECKLOCKTIMEVERIFY
RCLTV
We could of course softfork additional meaning into OP_CSV each time we add
new sequence number usecases, but that would become obscure and confusing.
We have already shown there is no shortage of opcodes so it makes no sense
to cram everything into one generic opcode.
TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
rather than focusing on the bitcoin internals.
[1]
https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151124/a775f63a/attachment.html
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Novembe011801.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]

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

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.
link to this week logs (slightly bugged logs as you'll see) Meeting minutes by meetbot
Main topics discussed where:
BIP68-related pull requests Eviction and onions BIP for opt-in RBF
Short topics/notes
Personal note: My weekly posts are being read by more people than I ever anticipated and people are expecting these to come weekly. Next year mid-february I'll be on vacation for a month, so I won't be able to do the meetings from 2016/02/18 to 2016/03/10. If there's anyone who's up for the challenge to take over during a week (and share the load with others) feel free to pm me. I'm announcing well in advance, so there's more chance to find some people and to not make this a last minute thing.
A lot of developers where traveling to the scaling bitcoin conference (videos), so this is again a shorter, and it'll likely be the same next week (as a lot of developers stay in Hong Kong for the developer meetup after the conference).
Also a reminder to anyone that's running a full node to update their node to core 11.2 or 10.4, btcd 0.12, bitcoinXT D, or any other node that supports BIP65 CLTV, to accommodate for the upcoming softfork. Not updating will mean you'll be trusting miners to produce valid blocks. 85% of miners advertise they support CLTV transactions and the softfork will activate when 95% is reached, currently (time of writing) +/- 30% of nodes is updated.
BIP68-related pull requests
BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers , and current implementation. BIP 68 changes the meaning of the previously unused sequence number field to a relative locktime.
There is a pull-request for a small correction in the comments of the code. There's been work on optimizing CreateNewBlock (which does what it says). Morcos and sdaftuar are looking at two approaches, one of which will refactor the BIP68 implementation significantly. As the refactoring would be better done before BIP68 gets merged, it would be good to know which approach is better.
Look into the CreateNewBlock optimization approaches.
Eviction and onions
Starting with Tor version 0.2.7.1 it is possible to create hidden services programmatically. Bitcoin will now automatically create a hidden service to listen on if Tor is running.
Localhost peers are never evicted; so as soon as you show up on a hidden service someone can prevent anyone else from connecting to you trivially. Pull-request #7082 addresses this problem by using latency to detect actual local peers. You can also use whitelists to distinguish between real localhost connections and tor localhost connections, but that might break existing software. wumpus notes we should encourage using the whitelist for special peers in the long term.
Take a look at Pull-request #7082
BIP for opt-in RBF
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 the nSequence field of all inputs. This is a mempool policy for the upcoming 0.12 release. There's a good FAQ-ish post on reddit about it.
Question is if opt-in RBF should have a BIP or not. It is just policy code, however standardness has been covered before in BIPs. sdaftuar notes it's unfortunate that the only documentation for what wallet writers should do is in a single mailing list post. harding volunteers to write the BIP.
harding will write the BIP in coordination with petertodd.
Participants
wumpus Wladimir J. van der Laan morcos Alex Morcos btcdrak btcdrak sipa Pieter Wuille gmaxwell Gregory Maxwell cfields Cory Fields jonasschnelli Jonas Schnelli Diablo-D3 Patrick McFarland sdaftuar Suhas Daftuar harding David A. Harding jcorgan Johnathan Corgan 
Comic relief
19:26 cfields sec, i'll like the mail thread 19:26 sipa cfields: you'll "like" it, is it on facebook? 19:27 wumpus twitter has 'likes' now too :') 
submitted by G1lius 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]

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]/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]

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

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 so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Replace-by-fee handling in wallets C++11 for 0.13
Replace-by-fee (RBF) handling in wallets
Currently when a node sees a transaction that spends the same output it ignores it. With RBF 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 RBF by changing the nSequence field of all inputs. This is a mempool policy for the upcoming 0.12 release. There's a good FAQ-ish post on reddit about it.
The feature freeze for 0.12 is in effect since December 1, outside of bugfixes, what's in the 0.12 branch now will be released. #7219 to make RBF policies optional (0 = never, 1 = always, 2 = opt-in) probably won't make it in 0.12. jonasschnelli and harding request good ideas for RBF wallet policies and ways to handle this. Android wallet bumps the fee via a click-to-bump UI (via CPFP). Adding bumping fees is fairly simple, doing more like adding in-and outputs probably hugely complicates the current wallet. For including in-and outputs you'd want to prepare a signed transaction with A+B and another signed transaction with just B spending from a change output created in A. For 0.13 we like to see at least a fee bump option and some raw transaction commands to alter a wallet transaction.
Take a look at #7062 Fix mempool limiting and replace-by-fee for PrioritiseTransaction for 0.12 Take a look at #7132 Add option to opt into full-RBF when sending funds
C++11 for 0.13
C++11 is an update of the C++ language. It offers new functionalities, an extended standard library, etc. Zerocash had to be written with some c++11 libraries and some IBLT simulation code was written in c++11, which they want to recycle for the eventual core commit.
The outstanding build issues are dependencies compatibility and Travis' compiler. There are concerns about the boost library as it's consensus critical. Removing boost usage (in consensus) before 0.13 removes that concern. A risk is that we get entrenched in C++11 irreversibly and find out when 0.13 is released a large part of the userbase can't handle it. Backports are also harder if the code starts to diverge too much. More testing would be good, but the travis pull tester is already slow, so adding more configurations might not be good. Possibly a 2nd free alternative to build more configurations in parallel. Both the zero-cash and bitcoin core team want automated testing of this stuff on many platforms, which can be done by buildbot. We can also reach out to distros for help. Wumpus is ready to switch builds to std=c++11 as soon as travis is building/passing.
Everyone wants C++11 for 0.13 swtich some builds to C++11
Participants
wumpus Wladimir J. van der Laan cfields Cory Fields sipa Pieter Wuille jonasshnelli Jonas Schnelli petertodd Peter Todd Luke-Jr Luke Dashjr nwilcox Nathan Wilcox zookolaptop Zooko Wilcox-O'Hearn sdaftuar Suhas Daftuar harding David A. Harding jgarzik Jeff Garzik btcdrak btcdrak 
Comic relief
19:03 petertodd wumpus: is the RBFhandling in the v0.12 branch what's going to be released? IE, have we feature frozen? 19:04 wumpus yes, we have feature frozen at dec 1 19:04 petertodd cool 19:04 petertodd or I should say, frozen 
( •_•) ( •_•)>⌐■-■ (⌐■_■) YYYYYYYEEEEEAAAAAAAAAAHHHHHHHHHHHH
submitted by G1lius to btc [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]

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]

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]

Sequence Media News - YouTube Digital Asset Investor - YouTube Christian Decker - History of the Lightning Network CQT120-Sequence Steps Facebook's Libra Cryptocurrency - YouTube

/r/Bitcoin is primarily for news and discussion. Please avoid repetition — /r/bitcoin is a subreddit devoted to new information and discussion about Bitcoin and its ecosystem. New merchants are welcome to announce their services for Bitcoin, but after those have been announced they are no longer news and should not be re-posted. Aside from new merchant announcements, those interested in ... News Transaction fee ... In this monthly feature, we highlight interesting updates to Bitcoin wallets and services. Swan supports sending to bech32 addresses: Swan, through their custodian Prime Trust, now supports withdrawals to bech32 addresses. Ledger Live adds manual coin selection support: Moving from a first-in, first-out UTXO selection model, Ledger Live now also supports manual coin ... The latest Bitcoin news has been sourced from the CoinSalad.com Bitcoin Price and News Events page. CoinSalad is a web service that provides real-time Bitcoin market info, charts, data and tools. Follow us on Twitter @CoinSalad. Posted by Unknown at 11:59 PM No comments: Email This BlogThis! Share to Twitter Share to Facebook Share to Pinterest. Labels: bitcoin events. Earn money online best ... All Bitcoin News; Analytics Firm: 200,000 Bitcoin is Currently Locked Within... News regarding the OKEx founder being arrested by the Chinese government has created some fear amongst crypto investors He holds the keys to the cryptocurrency that is locked within... Cole Petersen 12 hours ago; Macro Strength: Bitcoin’s Price Moves Higher Despite... Bitcoin faced some intense selling pressure ... Le cours du Bitcoin continue de s’accrocher au support technique des 7220$ (61.8% retracement Fibonacci), mais n’est toujours pas en mesure de dépasser une résistance. Le débat ...

[index] [47499] [30539] [19620] [40204] [29074] [13198] [10326] [50188] [5686] [26561]

Sequence Media News - YouTube

Share your videos with friends, family, and the world Sequence Media Group is an online news and information provider, we bring you the latest updates on current events plus, we also provide investigative storie... New; 45:34 # 1 MS Project 2019 Basics in 20 Minutes Easy - Duration: 29:37. ... Banking on Bitcoin YouTube Movies. 2017 · Documentary; 1:23:41. Lounge Music: Relaxing Piano Jazz Playlist - Lounge ... Freebitco.in gives users Free Bitcoins every hour. Win up to $200 in Bitcoins every hour, no strings attached! Sign Up: https://bit.ly/2BwAFpq This is the strategy I use to win endless free ... FREE Digital Asset Investor Newsletter Sign Up: https://bit.ly/31eomvA Protect Yourself From Hackers: 7-Day Pure VPN Trial For Only $.99 Click Here: https://...

#