|
The number of api calls is capped (caps are defined as #requests per mn, per hour and per day). I may raise current limits in the future if I can secure a more powerful infrastructure.
I'll check why the message doesn't disappear. This is clearly a bug.
Thanks for the feedback !
|
|
|
|
Interesting. This looks like it is a bug.
What is happening is that decoderawtransaction is not decoding the transaction as a segwit transaction but rather as a normal transaction.
Agreed This is on testnet I presume.
Yes |
|
|
|
I'm currently doing a few tests with bitcoin core 0.13.2 and I've noticed that decoderawtransaction has a strange behavior when used on some segwit txs (e.g: a24cec50d5cf861d1af4b634f8ed1968c0e9484724bfef5af7f8c383605978c8) Everything seems ok if I call getrawtransaction in verbose mode for this txid > getrawtransaction "a24cec50d5cf861d1af4b634f8ed1968c0e9484724bfef5af7f8c383605978c8" 1
{
"hex": "02000000000101c564a62f94c025ac80137817d8658aabceaaad30412facecba1bd2255182e1c40000000000ffffffff01ca124c000000000016001443aac20a116e09ea4f7914be1c55e4c17aa600b7024730440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c012103335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd5600000000",
"txid": "a24cec50d5cf861d1af4b634f8ed1968c0e9484724bfef5af7f8c383605978c8",
"hash": "54ad9b3b24064c4033814ddc712a393cfa4e011eb7ac24374687511cd056eac5",
"size": 191,
"vsize": 110,
"version": 2,
"locktime": 0,
"vin": [
{
"txid": "c4e1825125d21bbaecac2f4130adaaceab8a65d817781380ac25c0942fa664c5",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"30440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c01",
"03335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd56"
],
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.04985546,
"n": 0,
"scriptPubKey": {
"asm": "0 43aac20a116e09ea4f7914be1c55e4c17aa600b7",
"hex": "001443aac20a116e09ea4f7914be1c55e4c17aa600b7",
"type": "witness_v0_keyhash"
}
}
],
"blockhash": "0000000000001f21187cb667bdb30109a24bf42821f58b0cedf8c7d5641cbc33",
"confirmations": 172230,
"time": 1467400024,
"blocktime": 1467400024
}
Now, here is what I get if I call decoderawtransaction with the hex of this tx > decoderawtransaction "02000000000101c564a62f94c025ac80137817d8658aabceaaad30412facecba1bd2255182e1c40000000000ffffffff01ca124c000000000016001443aac20a116e09ea4f7914be1c55e4c17aa600b7024730440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c012103335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd5600000000"
{
"txid": "54ad9b3b24064c4033814ddc712a393cfa4e011eb7ac24374687511cd056eac5",
"hash": "54ad9b3b24064c4033814ddc712a393cfa4e011eb7ac24374687511cd056eac5",
"size": 191,
"vsize": 191,
"version": 2,
"locktime": 0,
"vin": [
],
"vout": [
{
"value": 27203371073.07775233,
"n": 0,
"scriptPubKey": {
"asm": "OP_LEFT 7817d8658aabceaaad30412facecba1bd22551 OP_SIZE OP_UNKNOWN OP_UNKNOWN 0 0 0 0 0 OP_INVALIDOPCODE OP_INVALIDOPCODE OP_INVALIDOPCODE OP_INVALIDOPCODE -74 4c000000000016001443aac20a116e09ea4f OP_PICK be1c55e4c17aa600b7024730440220679eaf5e41 OP_UNKNOWN OP_UNKNOWN OP_BOOLOR f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d3556 12 33 3428659 OP_UNKNOWN [error]",
"hex": "80137817d8658aabceaaad30412facecba1bd2255182e1c40000000000ffffffff01ca124c000000000016001443aac20a116e09ea4f7914be1c55e4c17aa600b7024730440220679eaf5e41eee49b38f3112ec90b49a655db21677db4d7fa80de67aeb987161102204024b85730fc106d0b870623fc221946e624413363eb627fe90eb5047d35565c012103335134d7414e1d1a154600b124a96f5ef2c6ca21434d2622469a96bd5262fd56",
"type": "nonstandard"
}
}
]
}
From my observations, everything seems ok for txs with P2WPKH or P2WSH nested in P2SH. Do I miss something ? Is it a known issue (or temporary limitation or decoderawtransaction) ? Thanks in advance ! |
|
|
|
|
Hi there,
A (stupid) question about segwit : what happens if I use a P2SH script (HASH160 <20-byte-hash> EQUAL) as the witness script of a P2WSH scriptpubkey ? Is it processed as a simple validation of a hash or does it also trigger the evaluation of the P2SH script ?
Thanks in advance !
|
|
|
|
The whole point of the blockchain is to validate balances. Sorry but this is wrong. Without balance data there's nothing to validate.
...
In short, the script is a lock that requires a key to spend the balance. This is also wrong because the concept of balance data don't exist in the blockchain. We're using abstract terms to simplify the details but that doesn't mean the terms are inaccurate or complete fiction. You're right. The thing is that DannyHamilton is absolutely right when he writes that balances, addresses and coins don't exist at protocol level (and in the blockchain). But we're humans and the concepts managed at protocol level are a bit hard for every day use by a human person !  Therefore, a layer of abstraction has been built on top of the protocol with wallets, blocks explorers, ... Concepts defined by these tools (addresses, balances, ...) are more human friendly and are really useful but remains this truth: balances or addresses don't exist at protocol level or in the blockchain. Actually, the same thing happens in software development. If you use an object-oriented language, you talk about classes and object all day long and these concepts are really useful for developers. But fact is that at CPU level, the concepts of class or object don't have any sense (and ultimately everything in a computer is just about electrons). EDIT: Note that some proposals were made to introduce the concept of utxos commitment in the protocol. It doesn't introduce the concept of balances but it allows to achieve something similar to your proposition (it builds a "snapshot" of the utxo set at a given height of the chain). This is often thought as a possible solution to reduce the disk space consumed by the blockchain. |
|
|
|
That's supposed to tell us what exactly? That under the most optimal technical environment "the network" can substain large blocks? I'm shocked  Actually, no, they've been having huge problems with it; with nodes crashing all over the place and such. Of course: Bitcoin Core nodes on testnet are unaffected: They're just ignoring the XT chain entirely, banning those peers, and continuing on as if they didn't exist. I'm a bit surprised to read this. I'm not fond of Bitcoin XT & BIP101 but having being vocal about the lack of tests, I've decided to setup a XT node on a VPS for this test. This node is pretty weak (1 vCore, 2Go RAM, windows as OS) but so far everything has been fine with no crash. Anyway, it doesn't change my mind that BIP101 without prior works on the P2P protocol isn't a good idea. |
|
|
|
hence, miners do have an incentive to keep it decentralized whilst mining the longest VALID chain, which, by definition means the one that has the more value potential.
so they better not screwing around with some power grabbing fork, else they loose everything...
A short parenthesis about the miners and the market. What really matters to miners is a market thinking that mining is decentralized, not a really decentralized mining ecosystem. It's important to remember that most (all ?) available statistics describing the (de)centralization of mining rely on weak (and easy to cheat) heuristics. End of the parenthesis  |
|
|
|
Do you agree that this conclusion applies to the way the network is now and the way it has always been?
I ask, just because I want it to be clear to readers that this "point of contention" is about a hypothetical future scenario. And that we already know that there are hypothetical future scenarios, such as mining centralized around a single super pool, that would be bad for Bitcoin.
Actually, I'm interested by your work because if the model is sound, it's useful for the present...and the future. Anyway. One step at a time. The next step should be to validate the model against actual data. |
|
|
|
Will mining centralize around one single miner? No one knows. This is why Bitcoin is still a risk.
But if this doesn't happen--if there remains more than a single miner--then the fee market does exist.
I think the point of contention is really about this conclusion. My understanding is that it may also happen with several miners if they have an incentive to synchronize their mempools (with a mechanism like IBLT). See this post written by Gavin (chapter "Will this skew incentives ?" of https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2) |
|
|
|
i'm not saying that the relay network has been bad for Bitcoin; it may even have been good. except that it is encouraging this non-verification scheme I'm not sure to understand your logic here. by encouraging non verification of blocks simply to increase the speed of propagation of blocks thru the network increases the risk of forking, imo. Where did you read that the relay network encourages mining pools to skip the verification of transactions ?  Imho, knowing that the relay network doesn't verify transactions, a rational mining pool should feel strongly encouraged to verify transactions. 1 If this turns out to be frequent, the difficulty would adjust.
2 If there are no transactions, a block is really not needed. 1. Agreed 2. I'm not sure that users waiting for their N confirmations would agree with your point of view Anyway, I don't see this point as the most urgent issue and I guess there will be many others challenges to be solved before this one is considered as an urgent problem. |
|
|
|
Anyways, to really understand what happens when R->0 I think we need to make a new model that takes into account what we just learned from your chart above (that miners won't necessarily be hashing all the time). That seems to be an interesting point illustrating how the best interest of users and miners incentives could diverge. For users, an empty block is always better than no block because it adds work to the chain and increases the security of the previous transactions. |
|
|
|
i'm not saying that the relay network has been bad for Bitcoin; it may even have been good. except that it is encouraging this non-verification scheme I'm not sure to understand your logic here. |
|
|
|
One could argue that the Shannon Entropy in a new block will not in general be proportional to the size of the block, but that doesn't make any sense to me I fear there's a misunderstanding here. The key point is the relation between the number of transactions and the size of the block (or the associated Shannon Entropy). With mechanisms like IBLT, the quantity of information transmitted on the wire (Shannon Entropy) is constant, whatever the number of transactions in the block. EDIT: Do you plan to participate in this event ? Unfortunately, "kicking the can" is a common pejorative term which can be thrown like mud at any interim solution. Well, my intention was not to offend anyone with this term. Actually, I felt safe to write it because it was used by Gavin to describe its first proposal (as an interim solution). I agree with you that there's nothing bad with a temporary solution... as long as the target solution is known beforehand. And that's one of my problems with the current proposals. For now, there's no target solution which has been proposed and agreed by "everyone". i agree with this view. the relay network is cutting corners and making risky shortcuts in relaying w/o essentially verifying. it only recently added a node in Beijing within the GFC. i wonder though if it's origins were a means of compensating for the top 5 largest miners being in China?
again, one of my reasons for wanting to increase blocksize is to increase competition in mining outside of China to those who have greater bandwidth. this would help level the playing field. Imho, it's good that the relay network doesn't verify transactions. These verifications must be done by miners and this is an important part of their job in the decentralized network. Verifications done by the relay network would be a very bad incentive for miners, leading us to a very centralized system. |
|
|
|
If my understanding of IBLT is correct, its main advantage is that the quantity of information transmitted on the wire is constant, whatever the number of transactions inside the block. IMHO, it's fair to say that propagation of these data is not the whole story. There's a reconciliation to be done between the new block and the local mempool but I think it's also fair to make the hypothesis that with such a mechanism in place, mining pools may have an incentive to keep an exhaustive mempool (in order to avoid the burden of requesting missing transactions and to increase their performances/profits). Anyway, I think we can say that with an IBLT, some operations will depend on the number of transactions (in mempool and new block) but for now, I don't know how the delay introduced by these operations would compare with the delay related to the propagation in the network (in term of order of magnitudes). This study is very interesting, because from an engineering point of view, having a mechanism requiring constants resources (time or space) is the "holy grail" but according to your paper that may also imply the birth of an unhealthy fee market (and a new challenge for bitcoin . As said many times by others, current solutions just kick the can down the road and a proper solution for propagation in the network remains to be found and implemented (imho the relay network should be considered as a temporary "patch" (no offense intended to its creator) and shouldn't become a replacement of the p2p network). Understanding the economic consequences of future solutions is really needed before we decide to go down the road and not so much has been done until now. So, keep up the good work ! |
|
|
|
@Peter R: Having followed the discussion on this thread, I must say that I'm quite impressed by the work done for this paper. Bravo ! I still have to read the end of the paper but I've got a question related to the impossibility of an unhealthy fee market (chapter 7). According to you, what would be the consequences of a new propagation mechanism like IBLT (see https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2) ? |
|
|
|
Is there any other transaction patterns that we can identify its ownership?
Here it is ! |
|
|
|
for each block in the Blockchain, which will help answering Q1. Does anyone know where I can get comprehensive data on the typical node's mempool size versus time to help answer Q2?
statoshi.info might help ! EDIT: Export feature is in the "wheel" entry of the menu |
|
|
|
|
Show Posts
