dcrd/wire/msgblock.go

389 lines
13 KiB
Go
Raw Permalink Normal View History

// Copyright (c) 2013-2016 The btcsuite developers
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
// Copyright (c) 2015-2017 The Decred developers
2013-05-08 19:31:00 +00:00
// Use of this source code is governed by an ISC
// license that can be found in the LICENSE file.
package wire
2013-05-08 19:31:00 +00:00
import (
"bytes"
"fmt"
2013-05-08 19:31:00 +00:00
"io"
"github.com/decred/dcrd/chaincfg/chainhash"
2013-05-08 19:31:00 +00:00
)
// defaultTransactionAlloc is the default size used for the backing array
// for transactions. The transaction array will dynamically grow as needed, but
// this figure is intended to provide enough space for the number of
// transactions in the vast majority of blocks without needing to grow the
// backing array multiple times.
const defaultTransactionAlloc = 2048
2013-05-08 19:31:00 +00:00
// MaxBlocksPerMsg is the maximum number of blocks allowed per message.
const MaxBlocksPerMsg = 500
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
// MaxBlockPayloadV3 is the maximum bytes a block message can be in bytes as of
// version 3 of the protocol.
const MaxBlockPayloadV3 = 1000000 // Not actually 1MB which would be 1024 * 1024
// MaxBlockPayload is the maximum bytes a block message can be in bytes.
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
const MaxBlockPayload = 1310720 // 1.25MB
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
// MaxTxPerTxTree returns the maximum number of transactions that could possibly
// fit into a block per each merkle root for the given protocol version.
func MaxTxPerTxTree(pver uint32) uint64 {
if pver <= 3 {
return ((MaxBlockPayloadV3 / minTxPayload) / 2) + 1
}
return ((MaxBlockPayload / minTxPayload) / 2) + 1
}
2013-05-08 19:31:00 +00:00
// TxLoc holds locator data for the offset and length of where a transaction is
// located within a MsgBlock data buffer.
type TxLoc struct {
TxStart int
TxLen int
}
// MsgBlock implements the Message interface and represents a decred
2013-05-08 19:31:00 +00:00
// block message. It is used to deliver block and transaction information in
// response to a getdata message (MsgGetData) for a given block hash.
type MsgBlock struct {
Header BlockHeader
Transactions []*MsgTx
STransactions []*MsgTx
2013-05-08 19:31:00 +00:00
}
Remove BlockHeader.TxnCount field. This commit removes the TxnCount field from the BlockHeader type and updates the tests accordingly. Note that this change does not affect the actual wire protocol encoding in any way. The reason the field has been removed is it really doesn't belong there even though the wire protocol wiki entry on the official bitcoin wiki implies it does. The implication is an artifact from the way the reference implementation serializes headers (MsgHeaders) messages. It includes the transaction count, which is naturally always 0 for headers, along with every header. However, in reality, a block header does not include the transaction count. This can be evidenced by looking at how a block hash is calculated. It is only up to and including the Nonce field (a total of 80 bytes). From an API standpoint, having the field as part of the BlockHeader type results in several odd cases. For example, the transaction count for MsgBlocks (the only place that actually has a real transaction count since MsgHeaders does not) is available by taking the len of the Transactions slice. As such, having the extra field in the BlockHeader is really a useless field that could potentially get out of sync and cause the encode to fail. Another example is related to deserializing a block header from the database in order to serve it in response to a getheaders (MsgGetheaders) request. If a block header is assumed to have the transaction count as a part of it, then derserializing a block header not only consumes more than the 80 bytes that actually comprise the header as stated above, but you then need to change the transaction count to 0 before sending the headers (MsgHeaders) message. So, not only are you reading and deserializing more bytes than needed, but worse, you generally have to make a copy of it so you can change the transaction count without busting cached headers. This is part 1 of #13.
2014-01-19 01:37:33 +00:00
// AddTransaction adds a transaction to the message.
2013-05-08 19:31:00 +00:00
func (msg *MsgBlock) AddTransaction(tx *MsgTx) error {
msg.Transactions = append(msg.Transactions, tx)
return nil
}
// AddSTransaction adds a stake transaction to the message.
func (msg *MsgBlock) AddSTransaction(tx *MsgTx) error {
msg.STransactions = append(msg.STransactions, tx)
return nil
}
Remove BlockHeader.TxnCount field. This commit removes the TxnCount field from the BlockHeader type and updates the tests accordingly. Note that this change does not affect the actual wire protocol encoding in any way. The reason the field has been removed is it really doesn't belong there even though the wire protocol wiki entry on the official bitcoin wiki implies it does. The implication is an artifact from the way the reference implementation serializes headers (MsgHeaders) messages. It includes the transaction count, which is naturally always 0 for headers, along with every header. However, in reality, a block header does not include the transaction count. This can be evidenced by looking at how a block hash is calculated. It is only up to and including the Nonce field (a total of 80 bytes). From an API standpoint, having the field as part of the BlockHeader type results in several odd cases. For example, the transaction count for MsgBlocks (the only place that actually has a real transaction count since MsgHeaders does not) is available by taking the len of the Transactions slice. As such, having the extra field in the BlockHeader is really a useless field that could potentially get out of sync and cause the encode to fail. Another example is related to deserializing a block header from the database in order to serve it in response to a getheaders (MsgGetheaders) request. If a block header is assumed to have the transaction count as a part of it, then derserializing a block header not only consumes more than the 80 bytes that actually comprise the header as stated above, but you then need to change the transaction count to 0 before sending the headers (MsgHeaders) message. So, not only are you reading and deserializing more bytes than needed, but worse, you generally have to make a copy of it so you can change the transaction count without busting cached headers. This is part 1 of #13.
2014-01-19 01:37:33 +00:00
// ClearTransactions removes all transactions from the message.
2013-05-08 19:31:00 +00:00
func (msg *MsgBlock) ClearTransactions() {
msg.Transactions = make([]*MsgTx, 0, defaultTransactionAlloc)
2013-05-08 19:31:00 +00:00
}
// ClearSTransactions removes all stake transactions from the message.
func (msg *MsgBlock) ClearSTransactions() {
msg.STransactions = make([]*MsgTx, 0, defaultTransactionAlloc)
}
// BtcDecode decodes r using the Decred protocol encoding into the receiver.
2013-05-08 19:31:00 +00:00
// This is part of the Message interface implementation.
// See Deserialize for decoding blocks stored to disk, such as in a database, as
// opposed to decoding blocks from the wire.
2013-05-08 19:31:00 +00:00
func (msg *MsgBlock) BtcDecode(r io.Reader, pver uint32) error {
err := readBlockHeader(r, pver, &msg.Header)
if err != nil {
return err
}
txCount, err := ReadVarInt(r, pver)
Remove BlockHeader.TxnCount field. This commit removes the TxnCount field from the BlockHeader type and updates the tests accordingly. Note that this change does not affect the actual wire protocol encoding in any way. The reason the field has been removed is it really doesn't belong there even though the wire protocol wiki entry on the official bitcoin wiki implies it does. The implication is an artifact from the way the reference implementation serializes headers (MsgHeaders) messages. It includes the transaction count, which is naturally always 0 for headers, along with every header. However, in reality, a block header does not include the transaction count. This can be evidenced by looking at how a block hash is calculated. It is only up to and including the Nonce field (a total of 80 bytes). From an API standpoint, having the field as part of the BlockHeader type results in several odd cases. For example, the transaction count for MsgBlocks (the only place that actually has a real transaction count since MsgHeaders does not) is available by taking the len of the Transactions slice. As such, having the extra field in the BlockHeader is really a useless field that could potentially get out of sync and cause the encode to fail. Another example is related to deserializing a block header from the database in order to serve it in response to a getheaders (MsgGetheaders) request. If a block header is assumed to have the transaction count as a part of it, then derserializing a block header not only consumes more than the 80 bytes that actually comprise the header as stated above, but you then need to change the transaction count to 0 before sending the headers (MsgHeaders) message. So, not only are you reading and deserializing more bytes than needed, but worse, you generally have to make a copy of it so you can change the transaction count without busting cached headers. This is part 1 of #13.
2014-01-19 01:37:33 +00:00
if err != nil {
return err
}
// Prevent more transactions than could possibly fit into the regular
// tx tree.
// It would be possible to cause memory exhaustion and panics without
// a sane upper bound on this count.
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
maxTxPerTree := MaxTxPerTxTree(pver)
if txCount > maxTxPerTree {
str := fmt.Sprintf("too many transactions to fit into a block "+
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
"[count %d, max %d]", txCount, maxTxPerTree)
return messageError("MsgBlock.BtcDecode", str)
}
msg.Transactions = make([]*MsgTx, 0, txCount)
for i := uint64(0); i < txCount; i++ {
multi: Separate tx serialization type from version. Decred's serialized format for transactions split the 32-bit version field into two 16-bit components such that the upper bits are used to encode a serialization type and the lower 16 bits are the actual transaction version. Unfortunately, when this was done, the in-memory transaction struct was not also updated to hide this complexity, which means that callers currently have to understand and take special care when dealing with the version field of the transaction. Since the main purpose of the wire package is precisely to hide these details, this remedies the situation by introducing a new field on the in-memory transaction struct named SerType which houses the serialization type and changes the Version field back to having the desired semantics of actually being the real transaction version. Also, since the maximum version can only be a 16-bit value, the Version field has been changed to a uint16 to properly reflect this. The serialization and deserialization functions now deal with properly converting to and from these fields to the actual serialized format as intended. Finally, these changes also include a fairly significant amount of related code cleanup and optimization along with some bug fixes in order to allow the transaction version to be bumped as intended. The following is an overview of all changes: - Introduce new SerType field to MsgTx to specify the serialization type - Change MsgTx.Version to a uint16 to properly reflect its maximum allowed value - Change the semantics of MsgTx.Version to be the actual transaction version as intended - Update all callers that had special code to deal with the previous Version field semantics to use the new semantics - Switch all of the code that deals with encoding and decoding the serialized version field to use more efficient masks and shifts instead of binary writes into buffers which cause allocations - Correct several issues that would prevent producing expected serializations for transactions with actual transaction versions that are not 1 - Simplify the various serialize functions to use a single func which accepts the serialization type to reduce code duplication - Make serialization type switch usage more consistent with the rest of the code base - Update the utxoview and related code to use uint16s for the transaction version as well since it should not care about the serialization type due to using its own - Make code more consistent in how it uses bytes.Buffer - Clean up several of the comments regarding hashes and add some new comments to better describe the serialization types
2017-08-04 23:43:45 +00:00
var tx MsgTx
2013-05-08 19:31:00 +00:00
err := tx.BtcDecode(r, pver)
if err != nil {
return err
}
msg.Transactions = append(msg.Transactions, &tx)
}
// Prevent more transactions than could possibly fit into the stake
// tx tree.
// It would be possible to cause memory exhaustion and panics without
// a sane upper bound on this count.
stakeTxCount, err := ReadVarInt(r, pver)
if err != nil {
return err
}
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
if stakeTxCount > maxTxPerTree {
str := fmt.Sprintf("too many stransactions to fit into a block "+
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
"[count %d, max %d]", stakeTxCount, maxTxPerTree)
return messageError("MsgBlock.BtcDecode", str)
}
msg.STransactions = make([]*MsgTx, 0, stakeTxCount)
for i := uint64(0); i < stakeTxCount; i++ {
multi: Separate tx serialization type from version. Decred's serialized format for transactions split the 32-bit version field into two 16-bit components such that the upper bits are used to encode a serialization type and the lower 16 bits are the actual transaction version. Unfortunately, when this was done, the in-memory transaction struct was not also updated to hide this complexity, which means that callers currently have to understand and take special care when dealing with the version field of the transaction. Since the main purpose of the wire package is precisely to hide these details, this remedies the situation by introducing a new field on the in-memory transaction struct named SerType which houses the serialization type and changes the Version field back to having the desired semantics of actually being the real transaction version. Also, since the maximum version can only be a 16-bit value, the Version field has been changed to a uint16 to properly reflect this. The serialization and deserialization functions now deal with properly converting to and from these fields to the actual serialized format as intended. Finally, these changes also include a fairly significant amount of related code cleanup and optimization along with some bug fixes in order to allow the transaction version to be bumped as intended. The following is an overview of all changes: - Introduce new SerType field to MsgTx to specify the serialization type - Change MsgTx.Version to a uint16 to properly reflect its maximum allowed value - Change the semantics of MsgTx.Version to be the actual transaction version as intended - Update all callers that had special code to deal with the previous Version field semantics to use the new semantics - Switch all of the code that deals with encoding and decoding the serialized version field to use more efficient masks and shifts instead of binary writes into buffers which cause allocations - Correct several issues that would prevent producing expected serializations for transactions with actual transaction versions that are not 1 - Simplify the various serialize functions to use a single func which accepts the serialization type to reduce code duplication - Make serialization type switch usage more consistent with the rest of the code base - Update the utxoview and related code to use uint16s for the transaction version as well since it should not care about the serialization type due to using its own - Make code more consistent in how it uses bytes.Buffer - Clean up several of the comments regarding hashes and add some new comments to better describe the serialization types
2017-08-04 23:43:45 +00:00
var tx MsgTx
err := tx.BtcDecode(r, pver)
if err != nil {
return err
}
msg.STransactions = append(msg.STransactions, &tx)
}
2013-05-08 19:31:00 +00:00
return nil
}
// Deserialize decodes a block from r into the receiver using a format that is
// suitable for long-term storage such as a database while respecting the
// Version field in the block. This function differs from BtcDecode in that
// BtcDecode decodes from the Decred wire protocol as it was sent across the
// network. The wire encoding can technically differ depending on the protocol
// version and doesn't even really need to match the format of a stored block at
// all. As of the time this comment was written, the encoded block is the same
// in both instances, but there is a distinct difference and separating the two
// allows the API to be flexible enough to deal with changes.
func (msg *MsgBlock) Deserialize(r io.Reader) error {
// At the current time, there is no difference between the wire encoding
// at protocol version 0 and the stable long-term storage format. As
// a result, make use of BtcDecode.
return msg.BtcDecode(r, 0)
}
// FromBytes deserializes a transaction byte slice.
func (msg *MsgBlock) FromBytes(b []byte) error {
r := bytes.NewReader(b)
return msg.Deserialize(r)
}
// DeserializeTxLoc decodes r in the same manner Deserialize does, but it takes
// a byte buffer instead of a generic reader and returns a slice containing the
// start and length of each transaction within the raw data that is being
// deserialized.
func (msg *MsgBlock) DeserializeTxLoc(r *bytes.Buffer) ([]TxLoc, []TxLoc, error) {
fullLen := r.Len()
// At the current time, there is no difference between the wire encoding
// at protocol version 0 and the stable long-term storage format. As
// a result, make use of existing wire protocol functions.
err := readBlockHeader(r, 0, &msg.Header)
if err != nil {
return nil, nil, err
}
txCount, err := ReadVarInt(r, 0)
Remove BlockHeader.TxnCount field. This commit removes the TxnCount field from the BlockHeader type and updates the tests accordingly. Note that this change does not affect the actual wire protocol encoding in any way. The reason the field has been removed is it really doesn't belong there even though the wire protocol wiki entry on the official bitcoin wiki implies it does. The implication is an artifact from the way the reference implementation serializes headers (MsgHeaders) messages. It includes the transaction count, which is naturally always 0 for headers, along with every header. However, in reality, a block header does not include the transaction count. This can be evidenced by looking at how a block hash is calculated. It is only up to and including the Nonce field (a total of 80 bytes). From an API standpoint, having the field as part of the BlockHeader type results in several odd cases. For example, the transaction count for MsgBlocks (the only place that actually has a real transaction count since MsgHeaders does not) is available by taking the len of the Transactions slice. As such, having the extra field in the BlockHeader is really a useless field that could potentially get out of sync and cause the encode to fail. Another example is related to deserializing a block header from the database in order to serve it in response to a getheaders (MsgGetheaders) request. If a block header is assumed to have the transaction count as a part of it, then derserializing a block header not only consumes more than the 80 bytes that actually comprise the header as stated above, but you then need to change the transaction count to 0 before sending the headers (MsgHeaders) message. So, not only are you reading and deserializing more bytes than needed, but worse, you generally have to make a copy of it so you can change the transaction count without busting cached headers. This is part 1 of #13.
2014-01-19 01:37:33 +00:00
if err != nil {
return nil, nil, err
Remove BlockHeader.TxnCount field. This commit removes the TxnCount field from the BlockHeader type and updates the tests accordingly. Note that this change does not affect the actual wire protocol encoding in any way. The reason the field has been removed is it really doesn't belong there even though the wire protocol wiki entry on the official bitcoin wiki implies it does. The implication is an artifact from the way the reference implementation serializes headers (MsgHeaders) messages. It includes the transaction count, which is naturally always 0 for headers, along with every header. However, in reality, a block header does not include the transaction count. This can be evidenced by looking at how a block hash is calculated. It is only up to and including the Nonce field (a total of 80 bytes). From an API standpoint, having the field as part of the BlockHeader type results in several odd cases. For example, the transaction count for MsgBlocks (the only place that actually has a real transaction count since MsgHeaders does not) is available by taking the len of the Transactions slice. As such, having the extra field in the BlockHeader is really a useless field that could potentially get out of sync and cause the encode to fail. Another example is related to deserializing a block header from the database in order to serve it in response to a getheaders (MsgGetheaders) request. If a block header is assumed to have the transaction count as a part of it, then derserializing a block header not only consumes more than the 80 bytes that actually comprise the header as stated above, but you then need to change the transaction count to 0 before sending the headers (MsgHeaders) message. So, not only are you reading and deserializing more bytes than needed, but worse, you generally have to make a copy of it so you can change the transaction count without busting cached headers. This is part 1 of #13.
2014-01-19 01:37:33 +00:00
}
// Prevent more transactions than could possibly fit into a normal tx
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
// tree. It would be possible to cause memory exhaustion and panics
// without a sane upper bound on this count.
//
// NOTE: This is using the constant for the latest protocol version
// since it is in terms of the largest possible block size.
maxTxPerTree := MaxTxPerTxTree(ProtocolVersion)
if txCount > maxTxPerTree {
str := fmt.Sprintf("too many transactions to fit into a block "+
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
"[count %d, max %d]", txCount, maxTxPerTree)
return nil, nil, messageError("MsgBlock.DeserializeTxLoc", str)
}
// Deserialize each transaction while keeping track of its location
// within the byte stream.
msg.Transactions = make([]*MsgTx, 0, txCount)
txLocs := make([]TxLoc, txCount)
for i := uint64(0); i < txCount; i++ {
txLocs[i].TxStart = fullLen - r.Len()
multi: Separate tx serialization type from version. Decred's serialized format for transactions split the 32-bit version field into two 16-bit components such that the upper bits are used to encode a serialization type and the lower 16 bits are the actual transaction version. Unfortunately, when this was done, the in-memory transaction struct was not also updated to hide this complexity, which means that callers currently have to understand and take special care when dealing with the version field of the transaction. Since the main purpose of the wire package is precisely to hide these details, this remedies the situation by introducing a new field on the in-memory transaction struct named SerType which houses the serialization type and changes the Version field back to having the desired semantics of actually being the real transaction version. Also, since the maximum version can only be a 16-bit value, the Version field has been changed to a uint16 to properly reflect this. The serialization and deserialization functions now deal with properly converting to and from these fields to the actual serialized format as intended. Finally, these changes also include a fairly significant amount of related code cleanup and optimization along with some bug fixes in order to allow the transaction version to be bumped as intended. The following is an overview of all changes: - Introduce new SerType field to MsgTx to specify the serialization type - Change MsgTx.Version to a uint16 to properly reflect its maximum allowed value - Change the semantics of MsgTx.Version to be the actual transaction version as intended - Update all callers that had special code to deal with the previous Version field semantics to use the new semantics - Switch all of the code that deals with encoding and decoding the serialized version field to use more efficient masks and shifts instead of binary writes into buffers which cause allocations - Correct several issues that would prevent producing expected serializations for transactions with actual transaction versions that are not 1 - Simplify the various serialize functions to use a single func which accepts the serialization type to reduce code duplication - Make serialization type switch usage more consistent with the rest of the code base - Update the utxoview and related code to use uint16s for the transaction version as well since it should not care about the serialization type due to using its own - Make code more consistent in how it uses bytes.Buffer - Clean up several of the comments regarding hashes and add some new comments to better describe the serialization types
2017-08-04 23:43:45 +00:00
var tx MsgTx
err := tx.Deserialize(r)
if err != nil {
return nil, nil, err
}
msg.Transactions = append(msg.Transactions, &tx)
txLocs[i].TxLen = (fullLen - r.Len()) - txLocs[i].TxStart
}
stakeTxCount, err := ReadVarInt(r, 0)
if err != nil {
return nil, nil, err
}
// Prevent more transactions than could possibly fit into a stake tx
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
// tree. It would be possible to cause memory exhaustion and panics
// without a sane upper bound on this count.
//
// NOTE: This is using the constant for the latest protocol version
// since it is in terms of the largest possible block size.
if stakeTxCount > maxTxPerTree {
str := fmt.Sprintf("too many transactions to fit into a stake tx tree "+
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
"[count %d, max %d]", stakeTxCount, maxTxPerTree)
return nil, nil, messageError("MsgBlock.DeserializeTxLoc", str)
}
// Deserialize each transaction while keeping track of its location
// within the byte stream.
msg.STransactions = make([]*MsgTx, 0, stakeTxCount)
sTxLocs := make([]TxLoc, stakeTxCount)
for i := uint64(0); i < stakeTxCount; i++ {
sTxLocs[i].TxStart = fullLen - r.Len()
multi: Separate tx serialization type from version. Decred's serialized format for transactions split the 32-bit version field into two 16-bit components such that the upper bits are used to encode a serialization type and the lower 16 bits are the actual transaction version. Unfortunately, when this was done, the in-memory transaction struct was not also updated to hide this complexity, which means that callers currently have to understand and take special care when dealing with the version field of the transaction. Since the main purpose of the wire package is precisely to hide these details, this remedies the situation by introducing a new field on the in-memory transaction struct named SerType which houses the serialization type and changes the Version field back to having the desired semantics of actually being the real transaction version. Also, since the maximum version can only be a 16-bit value, the Version field has been changed to a uint16 to properly reflect this. The serialization and deserialization functions now deal with properly converting to and from these fields to the actual serialized format as intended. Finally, these changes also include a fairly significant amount of related code cleanup and optimization along with some bug fixes in order to allow the transaction version to be bumped as intended. The following is an overview of all changes: - Introduce new SerType field to MsgTx to specify the serialization type - Change MsgTx.Version to a uint16 to properly reflect its maximum allowed value - Change the semantics of MsgTx.Version to be the actual transaction version as intended - Update all callers that had special code to deal with the previous Version field semantics to use the new semantics - Switch all of the code that deals with encoding and decoding the serialized version field to use more efficient masks and shifts instead of binary writes into buffers which cause allocations - Correct several issues that would prevent producing expected serializations for transactions with actual transaction versions that are not 1 - Simplify the various serialize functions to use a single func which accepts the serialization type to reduce code duplication - Make serialization type switch usage more consistent with the rest of the code base - Update the utxoview and related code to use uint16s for the transaction version as well since it should not care about the serialization type due to using its own - Make code more consistent in how it uses bytes.Buffer - Clean up several of the comments regarding hashes and add some new comments to better describe the serialization types
2017-08-04 23:43:45 +00:00
var tx MsgTx
err := tx.Deserialize(r)
if err != nil {
return nil, nil, err
}
msg.STransactions = append(msg.STransactions, &tx)
sTxLocs[i].TxLen = (fullLen - r.Len()) - sTxLocs[i].TxStart
}
return txLocs, sTxLocs, nil
}
// BtcEncode encodes the receiver to w using the Decred protocol encoding.
2013-05-08 19:31:00 +00:00
// This is part of the Message interface implementation.
// See Serialize for encoding blocks to be stored to disk, such as in a
// database, as opposed to encoding blocks for the wire.
2013-05-08 19:31:00 +00:00
func (msg *MsgBlock) BtcEncode(w io.Writer, pver uint32) error {
err := writeBlockHeader(w, pver, &msg.Header)
if err != nil {
return err
}
err = WriteVarInt(w, pver, uint64(len(msg.Transactions)))
Remove BlockHeader.TxnCount field. This commit removes the TxnCount field from the BlockHeader type and updates the tests accordingly. Note that this change does not affect the actual wire protocol encoding in any way. The reason the field has been removed is it really doesn't belong there even though the wire protocol wiki entry on the official bitcoin wiki implies it does. The implication is an artifact from the way the reference implementation serializes headers (MsgHeaders) messages. It includes the transaction count, which is naturally always 0 for headers, along with every header. However, in reality, a block header does not include the transaction count. This can be evidenced by looking at how a block hash is calculated. It is only up to and including the Nonce field (a total of 80 bytes). From an API standpoint, having the field as part of the BlockHeader type results in several odd cases. For example, the transaction count for MsgBlocks (the only place that actually has a real transaction count since MsgHeaders does not) is available by taking the len of the Transactions slice. As such, having the extra field in the BlockHeader is really a useless field that could potentially get out of sync and cause the encode to fail. Another example is related to deserializing a block header from the database in order to serve it in response to a getheaders (MsgGetheaders) request. If a block header is assumed to have the transaction count as a part of it, then derserializing a block header not only consumes more than the 80 bytes that actually comprise the header as stated above, but you then need to change the transaction count to 0 before sending the headers (MsgHeaders) message. So, not only are you reading and deserializing more bytes than needed, but worse, you generally have to make a copy of it so you can change the transaction count without busting cached headers. This is part 1 of #13.
2014-01-19 01:37:33 +00:00
if err != nil {
return err
}
2013-05-08 19:31:00 +00:00
for _, tx := range msg.Transactions {
err = tx.BtcEncode(w, pver)
if err != nil {
return err
}
}
err = WriteVarInt(w, pver, uint64(len(msg.STransactions)))
if err != nil {
return err
}
for _, tx := range msg.STransactions {
err = tx.BtcEncode(w, pver)
if err != nil {
return err
}
}
2013-05-08 19:31:00 +00:00
return nil
}
// Serialize encodes the block to w using a format that suitable for long-term
// storage such as a database while respecting the Version field in the block.
// This function differs from BtcEncode in that BtcEncode encodes the block to
// the Decred wire protocol in order to be sent across the network. The wire
// encoding can technically differ depending on the protocol version and doesn't
// even really need to match the format of a stored block at all. As of the
// time this comment was written, the encoded block is the same in both
// instances, but there is a distinct difference and separating the two allows
// the API to be flexible enough to deal with changes.
func (msg *MsgBlock) Serialize(w io.Writer) error {
// At the current time, there is no difference between the wire encoding
// at protocol version 0 and the stable long-term storage format. As
// a result, make use of BtcEncode.
return msg.BtcEncode(w, 0)
}
// Bytes returns the serialized form of the block in bytes.
func (msg *MsgBlock) Bytes() ([]byte, error) {
multi: Separate tx serialization type from version. Decred's serialized format for transactions split the 32-bit version field into two 16-bit components such that the upper bits are used to encode a serialization type and the lower 16 bits are the actual transaction version. Unfortunately, when this was done, the in-memory transaction struct was not also updated to hide this complexity, which means that callers currently have to understand and take special care when dealing with the version field of the transaction. Since the main purpose of the wire package is precisely to hide these details, this remedies the situation by introducing a new field on the in-memory transaction struct named SerType which houses the serialization type and changes the Version field back to having the desired semantics of actually being the real transaction version. Also, since the maximum version can only be a 16-bit value, the Version field has been changed to a uint16 to properly reflect this. The serialization and deserialization functions now deal with properly converting to and from these fields to the actual serialized format as intended. Finally, these changes also include a fairly significant amount of related code cleanup and optimization along with some bug fixes in order to allow the transaction version to be bumped as intended. The following is an overview of all changes: - Introduce new SerType field to MsgTx to specify the serialization type - Change MsgTx.Version to a uint16 to properly reflect its maximum allowed value - Change the semantics of MsgTx.Version to be the actual transaction version as intended - Update all callers that had special code to deal with the previous Version field semantics to use the new semantics - Switch all of the code that deals with encoding and decoding the serialized version field to use more efficient masks and shifts instead of binary writes into buffers which cause allocations - Correct several issues that would prevent producing expected serializations for transactions with actual transaction versions that are not 1 - Simplify the various serialize functions to use a single func which accepts the serialization type to reduce code duplication - Make serialization type switch usage more consistent with the rest of the code base - Update the utxoview and related code to use uint16s for the transaction version as well since it should not care about the serialization type due to using its own - Make code more consistent in how it uses bytes.Buffer - Clean up several of the comments regarding hashes and add some new comments to better describe the serialization types
2017-08-04 23:43:45 +00:00
buf := bytes.NewBuffer(make([]byte, 0, msg.SerializeSize()))
err := msg.Serialize(buf)
if err != nil {
return nil, err
}
multi: Separate tx serialization type from version. Decred's serialized format for transactions split the 32-bit version field into two 16-bit components such that the upper bits are used to encode a serialization type and the lower 16 bits are the actual transaction version. Unfortunately, when this was done, the in-memory transaction struct was not also updated to hide this complexity, which means that callers currently have to understand and take special care when dealing with the version field of the transaction. Since the main purpose of the wire package is precisely to hide these details, this remedies the situation by introducing a new field on the in-memory transaction struct named SerType which houses the serialization type and changes the Version field back to having the desired semantics of actually being the real transaction version. Also, since the maximum version can only be a 16-bit value, the Version field has been changed to a uint16 to properly reflect this. The serialization and deserialization functions now deal with properly converting to and from these fields to the actual serialized format as intended. Finally, these changes also include a fairly significant amount of related code cleanup and optimization along with some bug fixes in order to allow the transaction version to be bumped as intended. The following is an overview of all changes: - Introduce new SerType field to MsgTx to specify the serialization type - Change MsgTx.Version to a uint16 to properly reflect its maximum allowed value - Change the semantics of MsgTx.Version to be the actual transaction version as intended - Update all callers that had special code to deal with the previous Version field semantics to use the new semantics - Switch all of the code that deals with encoding and decoding the serialized version field to use more efficient masks and shifts instead of binary writes into buffers which cause allocations - Correct several issues that would prevent producing expected serializations for transactions with actual transaction versions that are not 1 - Simplify the various serialize functions to use a single func which accepts the serialization type to reduce code duplication - Make serialization type switch usage more consistent with the rest of the code base - Update the utxoview and related code to use uint16s for the transaction version as well since it should not care about the serialization type due to using its own - Make code more consistent in how it uses bytes.Buffer - Clean up several of the comments regarding hashes and add some new comments to better describe the serialization types
2017-08-04 23:43:45 +00:00
return buf.Bytes(), nil
}
// SerializeSize returns the number of bytes it would take to serialize the
// the block.
func (msg *MsgBlock) SerializeSize() int {
// Check to make sure that all transactions have the correct
// type and version to be included in a block.
// Block header bytes + Serialized varint size for the number of
// transactions + Serialized varint size for the number of
// stake transactions
n := blockHeaderLen + VarIntSerializeSize(uint64(len(msg.Transactions))) +
VarIntSerializeSize(uint64(len(msg.STransactions)))
for _, tx := range msg.Transactions {
n += tx.SerializeSize()
}
for _, tx := range msg.STransactions {
n += tx.SerializeSize()
}
return n
}
2013-05-08 19:31:00 +00:00
// Command returns the protocol command string for the message. This is part
// of the Message interface implementation.
func (msg *MsgBlock) Command() string {
return CmdBlock
2013-05-08 19:31:00 +00:00
}
// MaxPayloadLength returns the maximum length the payload can be for the
// receiver. This is part of the Message interface implementation.
func (msg *MsgBlock) MaxPayloadLength(pver uint32) uint32 {
multi: Implement block size hard fork demo voting. This implements a new voting agenda for the testnet and simnet networks for increasing the maximum block size from 1MiB to 1.25MB. The following is an overview of the changes: - Bump the maximum protocol block size limit to 1.25MB - Bump the protocol version to 4 - Add wire tests for v3 protocol sizes and update tests for latest - Update all wire values that are defined in terms of the max block size to respect the protocol version - Update the MaxSigOpsPerBlock constant to maintain existing value regardless of the raised max protocol block size - Decouple the maximum tx size from the block size by creating a chain parameter for it with the current sizes so it is not a part of the hard fork vote - Add definition for new version 4 stake vote along with agenda to vote on block size to the testnet and simnet networks - Convert the MaximumBlockSize chain parameter to a slice in order to hold the different possible sizes - Adds a new function that returns the maximum block size based upon the result of the vote - Change the existing context-free block size check to enforce the max protocol size and introduce a context-specific check which enforces a restricted size based upon the network consensus parameters and the result of the vote - Set the max allowed size in generated block templates based upon the network params and result of the vote - Generate version 4 blocks and reject version 3 blocks after a super majority has been reached
2017-02-09 04:06:11 +00:00
// Protocol version 3 and lower have a different max block payload.
if pver <= 3 {
return MaxBlockPayloadV3
}
Remove BlockHeader.TxnCount field. This commit removes the TxnCount field from the BlockHeader type and updates the tests accordingly. Note that this change does not affect the actual wire protocol encoding in any way. The reason the field has been removed is it really doesn't belong there even though the wire protocol wiki entry on the official bitcoin wiki implies it does. The implication is an artifact from the way the reference implementation serializes headers (MsgHeaders) messages. It includes the transaction count, which is naturally always 0 for headers, along with every header. However, in reality, a block header does not include the transaction count. This can be evidenced by looking at how a block hash is calculated. It is only up to and including the Nonce field (a total of 80 bytes). From an API standpoint, having the field as part of the BlockHeader type results in several odd cases. For example, the transaction count for MsgBlocks (the only place that actually has a real transaction count since MsgHeaders does not) is available by taking the len of the Transactions slice. As such, having the extra field in the BlockHeader is really a useless field that could potentially get out of sync and cause the encode to fail. Another example is related to deserializing a block header from the database in order to serve it in response to a getheaders (MsgGetheaders) request. If a block header is assumed to have the transaction count as a part of it, then derserializing a block header not only consumes more than the 80 bytes that actually comprise the header as stated above, but you then need to change the transaction count to 0 before sending the headers (MsgHeaders) message. So, not only are you reading and deserializing more bytes than needed, but worse, you generally have to make a copy of it so you can change the transaction count without busting cached headers. This is part 1 of #13.
2014-01-19 01:37:33 +00:00
// Block header at 80 bytes + transaction count + max transactions
// which can vary up to the MaxBlockPayload (including the block header
// and transaction count).
return MaxBlockPayload
2013-05-08 19:31:00 +00:00
}
// BlockHash computes the block identifier hash for this block.
func (msg *MsgBlock) BlockHash() chainhash.Hash {
return msg.Header.BlockHash()
2013-05-08 19:31:00 +00:00
}
// TxHashes returns a slice of hashes of all of transactions in this block.
func (msg *MsgBlock) TxHashes() []chainhash.Hash {
hashList := make([]chainhash.Hash, 0, len(msg.Transactions))
2013-05-08 19:31:00 +00:00
for _, tx := range msg.Transactions {
hashList = append(hashList, tx.TxHash())
}
return hashList
}
// STxHashes returns a slice of hashes of all of stake transactions in this
// block.
func (msg *MsgBlock) STxHashes() []chainhash.Hash {
hashList := make([]chainhash.Hash, 0, len(msg.STransactions))
for _, tx := range msg.STransactions {
hashList = append(hashList, tx.TxHash())
2013-05-08 19:31:00 +00:00
}
return hashList
2013-05-08 19:31:00 +00:00
}
// NewMsgBlock returns a new Decred block message that conforms to the
2013-05-08 19:31:00 +00:00
// Message interface. See MsgBlock for details.
func NewMsgBlock(blockHeader *BlockHeader) *MsgBlock {
return &MsgBlock{
Header: *blockHeader,
Transactions: make([]*MsgTx, 0, defaultTransactionAlloc),
STransactions: make([]*MsgTx, 0, defaultTransactionAlloc),
2013-05-08 19:31:00 +00:00
}
}