Bitcoin Transaction Locktime | Dierenartsenpraktijk Deprest

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 IRC meeting in layman's terms (2015-11-12)

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

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

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

BIP68: Second-level granularity doesn't make sense | Peter Todd | Nov 24 2015

Peter Todd on Nov 24 2015:
BIP68 currently represents by-height locks as a simple 16-bit integer of
the number of blocks - effectively giving a granularity of 600 seconds
on average - but for for by-time locks the representation is a 25-bit
integer with granularity of 1 second. However this granularity doesn't
make sense with BIP113, median time-past as endpoint for lock-time
calcualtions, and poses potential problems for future upgrades.
There's two cases to consider here:
1) No competing transactions
By this we mean that the nSequence field is being used simply to delay
when an output can be spent; there aren't competing transactions trying
to spend that output and thus we're not concerned about one transaction
getting mined before another "out of order". For instance, an 2-factor
escrow service like GreenAddress could use nSequence with
CHECKSEQUENCEVERIFY (CSV) to guarantee that users will eventually get
their funds back after some timeout.
In this use-case exact miner behavior is irrelevant. Equally given the
large tolerances allowed on block times, as well as the poisson
distribution of blocks generated, granularity below an hour or two
doesn't have much practical significance.
2) Competing transactions
Here we are relying on miners prefering lower sequence numbers. For
instance a bidirectional payment channel can decrement nSequence for
each change of direction; BIP68 suggests such a decrement might happen
in increments of one day.
BIP113 makes lock-time calculations use the median time-past as the
threshold for by-time locks. The median time past is calculated by
taking median time of the 11 previous blocks, which means when a miner
creates a block they have absolutely no control over what the median
time-past is; it's purely a function of the block tip they're building
upon.
This means that granularity below a block interval will, on average,
have absolutely no effect at all on what transaction the miner includes
even in the hypothetical case. In practice of course, users will want to
use significantly larger than 1 block interval granularity in protocols.
The downside of BIP68 as written is users of by-height locktimes have 14
bits unused in nSequence, but by-time locktimes have just 5 bits unused.
This presents an awkward situation if we add new meanings to nSequence
if we ever need more than 5 bits. Yet as shown above, the extra
granularity doesn't have a practical benefit.
Recommendation: Change BIP68 to make by-time locks have the same number
of bits as by-height locks, and multiply the by-time lock field by the
block interval.

'peter'[:-1]@petertodd.org
000000000000000001a06d85a46abce495fd793f89fe342e6da18b235ade373f
-------------- 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/20151123/4e2a25bf/attachment.sig
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Novembe011798.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

#bitcoin-dev Weekly Development Meeting Minutes 2015-10-08 | Daniel Stadulis | Oct 09 2015

Daniel Stadulis on Oct 09 2015:
More readable Google Doc version with html links here:
https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit?usp=sharing
Meeting Title:

bitcoin-dev Weekly Development Meeting

Meeting Date:
2015-10-08
Meeting Time:
19:00-20:00 UTC
Participants in Attendance:
dstadulis
wumpus
btcdrak
morcos
petertodd
bsm117532
BlueMatt
gmaxwell
GreenIsMyPepper
phantomcircuit
warren
sipa
IRC Chat Logs:
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/08#l1444329019.0
———------------------------------
Topics to be discussed:
  1. Mempool limiting
  2. Partial transaction malleability fix: Low-S change (releases 0.10.3, 0.11.1
backport)
  1. CHECKLOCKTIMEVERIFY (CLTV) backport reviews
  2. CHECKSEQUENCEVERIFY (CSV) reviews
  3. Creation of [bitcoin-discuss] mailing list planning
———------------------------------
2015-10-08 Meeting Conclusions:
Ecosystem Warnings & Alerts:
There is a Bitcoin ecosystem threat with the potential to cause millions of
dollars in losses that needs higher visibility. It's not a Bitcoin Core /
Bitcoin network issue but most Javascript-based Bitcoin software is
affected. The issue, documented here
https://github.com/feross/buffepull/81, is about common, critical,
Javascript code that is broken and may cause the generation of incorrect
pubkeys (among other issues). If Javascript is part of your implementation,
you should read the referenced pull request.
Action items
Responsible Parties
ETA/Due Date
1
Review/test code for Pull Request #6722 "Limit mempool by throwing away the
cheapest txn and setting min relay fee to it".
All
Unspecified
2
Provide ACK’s/support for low limits on PR #6771 "Policy: Lower default
limits for tx chains".
All
Unspecified
4
Urgent code review and ACKs of CLTV backports PR:

6706 “CLTV IsSuperMajority() soft-fork, rebased for v0.10.2”

6707 “CLTV IsSuperMajority() soft-fork, rebased for v0.11.0”

All
Unspecified
5
Contact miners about PR #6769 "Test LowS in standardness, removes nuisance
malleability vector" and turning on the long-existing anti-malleability
standardness rules in Bitcoin Core
Bluematt & Gmaxwell
Unspecified
6
Clarification from maaku regarding nSequence for BIP68
Continue review and ACKs of PR

6312 “BIP-68: Mempool-only sequence number constraint verification”

6564 “BIP-112: Mempool-only CHECKSEQUENCEVERIFY”

6566 “BIP-113: Mempool-only median time-past as endpoint for lock-time

calculations”
All
Unspecified
7
Mailing Lists: [bitcoin-discuss] creation, moderators assignment of discuss
and dev list, simple website for mailing list policy.
Warren
Discussion meeting scheduled for: 2015-10-12 19:00-20:00 UTC
Meetingbot Minutes
Minutes(HTML)
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.html
Minutes(text)
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.txt
IRC Log:
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-08-18.59.log.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151009/6a9cdac3/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Octobe011494.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

How to get 100% FREE UNLIMITED Bitcoin in 2020!  New Easy Working Method Cryptocurrency converter and calculator Where is Bitcoin Going? bitcoin calculator How to Calculate Bitcoin Transaction Size

Bitcoin puts the current compact-format target and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the block header overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction. The extranonce contributes to enlarge the domain for the proof of work function. 比特币源码阅读笔记【基础篇】出差坐火车ing,正好利用这段时间学习一波比特币源代码,比特币源码的主要语言是C++,测试代码语言主要是Python。一、区块链数据结构和数字签名算法1. 数据结构 Merkle树区块链, 顾名思义是由一个个区块按一定规则组成的链。 Bitcoin's peer-to-peer protocol, on the other hand, is a new distributed algorithm. Prior to Bitcoin, no distributed algorithm existed capable of maintaining an agreed-upon blockchain of transactions in perpetuity. EDIT: Removed the word "kind of" in response to mayank's and axus's comments below. Each OP_CHECKSIG and OP_CHECKSIGVERIFY is counted as 1 sigop.. Each OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY, is counted as 20 sigops if they are found in an output or scriptSig and not part of a redeemScript, i.e. not P2SH.. If OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY are in a redeemScript (i.e. it's P2SH), then the number of sigops is the number of public keys in the multisig redeemScript. Merrill waives its commissions for all online stock, ETF and option trades placed in a Merrill Edge ® Self-Directed brokerage account. Brokerage fees associated with, but not limited to, margin transactions, special stock registration/gifting, account transfer and processing and termination apply.

[index] [1736] [17467] [14873] [17068] [17372] [27220] [2496] [29490] [16558] [1089]

How to get 100% FREE UNLIMITED Bitcoin in 2020! New Easy Working Method

*DISCLAIMER* I am not your financial adviser! I am just Ticker Symbol Crypto showing you what I am doing with my crypto. Cryptocurrencies are extremely volatile, and crypto programs and platforms ... Dollar Crash Prediction - When & How it will happen according to Billionaire Ray Dalio - Duration: 12:07. Roger James Hamilton 116,277 views Every time we send a bitcoin transaction, we pay a fee relative to its size. Strangely, this has almost nothing to do with how much money is being sent -- the blockchain world just isn't that simple! Market Pulse - SPX & $BTC Correlation Strikes Again! 👉 Subscribe so you don't miss the next one: http://bit.ly/2QKVDdV Check below for events and news ... The main function of a Bitcoin calculator is to compute how much processing power it will take to generate Bitcoins with a given hardware setup. Because of the deterministic nature of all the ...

Flag Counter