- Dec 16, 2015
- 2,806
- 6,088
Maybe it's time to open a specific thread related to the ordering topic.
It seems completely off-topic to this thread.
It seems completely off-topic to this thread.
Should members of Bitcoin Unlimited be expelled when they no longer follow Articles of Federation?
- Thread starter Jonathan Silverblood
- Start date
@freetrader
"It seems completely off-topic to this thread."
"Should members of Bitcoin Unlimited be expelled when they no longer follow the Bitcoin Unlimited articles of federation?"
The very political topic of discussing whether to expel members hinges on whether BU members are working on Bitcoin or working on something else. At minimum.
The reason why people want to avoid defining "Bitcoin" is because the consequences challenge their world view and may take them to someplace they feel uncomfortable.
That's why many here would rather discuss how to "ignore" and "delete" because "off-topic" instead of addressing the central most important question of "what is Bitcoin" will reveal the hypocrisy of those seeking to purge members.
This thread is encouraging a purge of the last remaining Bitcoin-supporting members.
Many are using the whole "But CG is threatening lawsuits and are statist". That's neither here nor there who is threatening "lawsuits" while using the TCP protocol. Either a company is working on TCP (or Bitcoin) or not.
It's a diversion from the real issue of whether BCH can be used as cash and whether the chronological ordering can be computationally verified efficiently for companies implementing cash use-cases at scale.
This is in the realm of science and inquiry. Answering this question will reveal what to do with the BU members that are no longer interested in working on Bitcoin.
ps. Before people come in and say "But a Bitcoin is what users choose", then you may as well say that I'm a giraffe if the majority of people decide I'm a giraffe. Just because the majority is deluded into voting on a fallacy does not make it reality.
"It seems completely off-topic to this thread."
(emphasis mine)
"Should members of Bitcoin Unlimited be expelled when they no longer follow the Bitcoin Unlimited articles of federation?"
The very political topic of discussing whether to expel members hinges on whether BU members are working on Bitcoin or working on something else. At minimum.
The reason why people want to avoid defining "Bitcoin" is because the consequences challenge their world view and may take them to someplace they feel uncomfortable.
That's why many here would rather discuss how to "ignore" and "delete" because "off-topic" instead of addressing the central most important question of "what is Bitcoin" will reveal the hypocrisy of those seeking to purge members.
This thread is encouraging a purge of the last remaining Bitcoin-supporting members.
Many are using the whole "But CG is threatening lawsuits and are statist". That's neither here nor there who is threatening "lawsuits" while using the TCP protocol. Either a company is working on TCP (or Bitcoin) or not.
It's a diversion from the real issue of whether BCH can be used as cash and whether the chronological ordering can be computationally verified efficiently for companies implementing cash use-cases at scale.
This is in the realm of science and inquiry. Answering this question will reveal what to do with the BU members that are no longer interested in working on Bitcoin.
ps. Before people come in and say "But a Bitcoin is what users choose", then you may as well say that I'm a giraffe if the majority of people decide I'm a giraffe. Just because the majority is deluded into voting on a fallacy does not make it reality.
- Dec 16, 2015
- 2,806
- 6,088
Does it say in the Articles that BU members cannot also work on something else than Bitcoin?
Nice red herring though.
@freetrader
"Does it say in the Articles that BU members cannot also work on something else than Bitcoin?"
Obviously the members are free to work on making a sandwich, or working on art, or also other software projects (including altcoins).
Influential BU members are posting threads about expelling the last remaining developers in BU that are actually working on Bitcoin.
Instead of actually pointing this out, other influential members would rather silence an outsider and side step this very inconvenient fact and pretend like nothing happened.
My hope is that people will see that Bitcoin's time keeping mechanism is important and that being able to get a timeline of transactions at scale is important. My hope is that once this is clarified, then those hostile to Bitcoin can leave BU so that BU can continue focusing on competing with other implementations for the best Bitcoin node.
"Does it say in the Articles that BU members cannot also work on something else than Bitcoin?"
Obviously the members are free to work on making a sandwich, or working on art, or also other software projects (including altcoins).
Influential BU members are posting threads about expelling the last remaining developers in BU that are actually working on Bitcoin.
Instead of actually pointing this out, other influential members would rather silence an outsider and side step this very inconvenient fact and pretend like nothing happened.
My hope is that people will see that Bitcoin's time keeping mechanism is important and that being able to get a timeline of transactions at scale is important. My hope is that once this is clarified, then those hostile to Bitcoin can leave BU so that BU can continue focusing on competing with other implementations for the best Bitcoin node.
its not an ignore/censor attitude. its the unstoppable force meets an immovable object scenario. unless you are talking about the question on mods removing posts, in which case its not censorship so much as moving it somewhere else because the entire conversation was off topic
I've put up a 1 BCH bounty for this "trivial to distinguish" algorithm:
I'm looking forward to seeing a solution and understanding how businesses can use BCH as cash.
It's a saying about when two people are debating something but at no point are either one of them going to change their minds.
So the force and object in this scenario would be attila and I on the topic of "does transaction ordering in a block affects the timeline of the transactions or is time purely kept track of by the block timestamp and transaction ordering inside of a block not matter because only the block has time data?"
We have both presented our cases, neither one of us is going to budge, and thus the conversation has died. It would be a waste of time to continue it. Others reading will see the information we have presented and make their own decision.
> So the force and object in this scenario would be attila and I on the topic of "does transaction ordering in a block affects the timeline of the transactions or is time purely kept track of by the block timestamp and transaction ordering inside of a block not matter because only the block has time data?"
I just told you what the two things were. I do not understand how explicitly stating it is being vague
I just told you what the two things were. I do not understand how explicitly stating it is being vague
It does affect it. I've presented a O(n) algorithm for verifying the chronological order of transactions with Bitcoin.
I've offered a bounty for someone to present an algorithm for verifying the chronological order of transactions with BCH.
If the "time purely kept track of by the block timestamp"... then I guess it should be no problem to use that as your working assumption and claim the 1 BCH bounty.
I'll repeat the algorithm here for Bitcoin for convenience:
tx_history = get_timeline_for_address(block, address) {
timeline = []
for (tx in block) {
return timeline
}for (tx in block) {
if (tx.address == address) {
}timeline.append(tx)
}return timeline
The tx_history now contains the ordered sequence of transaction id's in chronological order.
I'm not an 'immovable object' or 'unstoppable force". I've even offered 1 BCH for someone to show me how to do a timeline of transactions that merely reconstructs the order of parent-child transactions in a block.
Let's focus on science and mathematics instead of rhetoric. It's someone elses turn to present this so called trivial algorithm for BCH.
You might argue that businesses and auditors don't need to know the order of their 1,000's of transactions in single block. That would be another angle. But that would be going against GAAP and other accounting practices.
Since you failed to state it and are using an array to store the timeline instead of a tree, im going to assume the chain of transactions each have 1 input and 1 output. I will also assume you already fetched the blocks from the node and have them stored in an array. if u want to include code for fetching a block, then just include some loop that calls getblock for each block before this. I also will assume we have a tx called Z in block j that we want to build the history for since you failed to specify a starting point.
CTransaction Z; // this is a complete valid tx found in j to start
std::vector<CBlock> vBlocks; // this is already populated and in order from 0 to j;
std::vector<CTransaction> vTxTimeline; // this is empty to start
vTxTimeline.emplace_back(Z);
for (size_t i = vBlocks.size() - 1; i >= 0; --i)
{
while(true)
{
auto iter = std::find(i.vtx.begin(), i.vtx.end(), Z.vin[0].prevout.hash);
if (iter == i.vtx.end())
{
break;
}
vTxTimeline.emplace_back(*iter);
Z = *iter;
}
}
this would be your algorithm for the parents of Z stored in vTxTimeline where the first element is Z and the last is the coinbase from which the original output is stored.
i could have emplace front to go from parent -> child order in the array instead of child -> parent. you can also expand to not use the first hard coded output (search each input prevout hash not just the first) and store in a tree if the transaction history you want to build has more than 1 input and 1 output per transaction. but the general algorithm remains the same.
this works regardless of tx ordering inside a block. It takes more cpu cycles compared to chronological ordering but i never said that it wouldnt. just that it was a fairly simple algorithm
[doublepost=1554167417][/doublepost]wow spacing formatting did not keep. i dont know how to make a code block on the forum
@Griffith Nice! Thank you. I'm reviewing it now
[doublepost=1554167845][/doublepost]@Griffith
"im going to assume the chain of transactions each have 1 input and 1 output."
This is a good start, but we need the full algorithm for arbitrary blocks i through j.
"I will also assume you already fetched the blocks from the node and have them stored in an array. if u want to include code for fetching a block, then just include some loop that calls getblock for each block before this."
Yes, that's fine.
"I also will assume we have a tx called Z in block j that we want to build the history for since you failed to specify a starting point."
The problem statement is to produce a chronological timeline of all transactions for blocks i through j. Not just the history of a single tx.
A company may have K addresses that they wish they know the chronological history of transaction for between blocks i through j (to make it more concrete and applying it to a real world use case).
The algorithm above provides it for only a single transaction and makes the (overly) simplifying assumption that there are 1 input and 1 outputs.
To claim the bounty please provide the solution to the original problem statement as stated. In particular the original problem statement asks for:
1. Provide the causal (ie: chronological) ordering of transactions for blocks i through j
2. Assume real-world usage scenarios where there can be many inputs and outputs.
[doublepost=1554167845][/doublepost]@Griffith
"im going to assume the chain of transactions each have 1 input and 1 output."
This is a good start, but we need the full algorithm for arbitrary blocks i through j.
"I will also assume you already fetched the blocks from the node and have them stored in an array. if u want to include code for fetching a block, then just include some loop that calls getblock for each block before this."
Yes, that's fine.
"I also will assume we have a tx called Z in block j that we want to build the history for since you failed to specify a starting point."
The problem statement is to produce a chronological timeline of all transactions for blocks i through j. Not just the history of a single tx.
A company may have K addresses that they wish they know the chronological history of transaction for between blocks i through j (to make it more concrete and applying it to a real world use case).
The algorithm above provides it for only a single transaction and makes the (overly) simplifying assumption that there are 1 input and 1 outputs.
To claim the bounty please provide the solution to the original problem statement as stated. In particular the original problem statement asks for:
1. Provide the causal (ie: chronological) ordering of transactions for blocks i through j
2. Assume real-world usage scenarios where there can be many inputs and outputs.
Last edited:
you can change the code above to search for each input prevout hash instead of hardcoding to 0 to accommodate for multiple input txs.
> Provide the causal (ie: chronological) ordering of (all) transactions for blocks i through j
you could either run this for each interested transaction, or i am confused on the requirement. if the history of tx Z and Y never intertwine how do i determine which came first? neither the old ordering nor LTOR make this distinction.
> Provide the causal (ie: chronological) ordering of (all) transactions for blocks i through j
you could either run this for each interested transaction, or i am confused on the requirement. if the history of tx Z and Y never intertwine how do i determine which came first? neither the old ordering nor LTOR make this distinction.
@Griffith
you can change the code above to search for each input prevout hash instead of hardcoding to 0 to accommodate for multiple input txs.
It's alright if you do not have the time to produce the working algorithm. Perhaps some other time.
"you could either run this for each interested transaction, or i am confused on the requirement. "
The requirement is to present the chronological ordering of (all) transactions within blocks i through j.
The old ordering is the chronological order because it respects parent-child dependency order.
For simplicity, you can assume that the non-dependent transactions in a block can be ordered anyway that you wish as the output of your algorithm.
you can change the code above to search for each input prevout hash instead of hardcoding to 0 to accommodate for multiple input txs.
It's alright if you do not have the time to produce the working algorithm. Perhaps some other time.
"you could either run this for each interested transaction, or i am confused on the requirement. "
The requirement is to present the chronological ordering of (all) transactions within blocks i through j.
The old ordering is the chronological order because it respects parent-child dependency order.
For simplicity, you can assume that the non-dependent transactions in a block can be ordered anyway that you wish as the output of your algorithm.
@attila ahhh. i see the disconnect. I will reference one of my earlier posts...
The other day when i stated:
```
In the original ordering if the block contained 3 transactions (not including the coinbase) and none of them spend the outputs of the other then
123
132
321
312
213
231
were all valid orderings of the transactions in the block. the only timeline you are guaranteed is that they were all within the block. which tx of the 3 was generated first is not stored in the block information.
```
this is because when miners in legacy ordering pack transactions into a block it is not chronological with respect to transactions in the same block that are not children/parents of each other. if a block contained no transactions that held a child/parent relationship they were ordered by fee density, not time. the only case where chronological ordering was respected was when one tx was the child/parent of another.
to extend the previous example of 3 transactions, we now add a 4th that is the child of tx 2.
valid orderings would be:
1234
1324
3124
3241
2431
2413
as long as tx 4 which is the child of 2 comes after 2, the rest is at the discretion of the miner. that was the only rule regarding chronological ordering.
i can provide source code citation on fee density packing if you would like.
The other day when i stated:
```
In the original ordering if the block contained 3 transactions (not including the coinbase) and none of them spend the outputs of the other then
123
132
321
312
213
231
were all valid orderings of the transactions in the block. the only timeline you are guaranteed is that they were all within the block. which tx of the 3 was generated first is not stored in the block information.
```
this is because when miners in legacy ordering pack transactions into a block it is not chronological with respect to transactions in the same block that are not children/parents of each other. if a block contained no transactions that held a child/parent relationship they were ordered by fee density, not time. the only case where chronological ordering was respected was when one tx was the child/parent of another.
to extend the previous example of 3 transactions, we now add a 4th that is the child of tx 2.
valid orderings would be:
1234
1324
3124
3241
2431
2413
as long as tx 4 which is the child of 2 comes after 2, the rest is at the discretion of the miner. that was the only rule regarding chronological ordering.
i can provide source code citation on fee density packing if you would like.
