Dear Marko, NONE of the transactions stored in Bitcoin are invalid in the sense of it chain code (that is its script language). Those in orphan blocks are just not part of the ordering

Dear Tamas, Re "invalid" in Bitcoin I precisely said "unsuccessful" as in orphaned blocks - not invalid in the sense of chaincode. Anyway, coupling chaincode and consensus is certainly a

I am not sure we should discuss coupling of chain code and consensus as I am not sure this was the consequence of my ask. Using the terminology of your writeup I ask, that endorsers should not forward

I am not sure we should discuss coupling of chain code and consensus as I am not sure this was the consequence of my ask. Using the terminology of your writeup I ask, that endorsers should not forward

For an honest peer - this is trivial to ask for - and we should do it the problem is one cannot ask a malicious peer to comply with this. But one could track his actions via separate mechanism (cf.

For 1, it's could be an option in permissioned blockchain for complete auditability, not debugging. For 2, it's been implemented in the client SDK - Binh Tamas Blummer ---06/02/2016 06:07:40 AM---It

1) storing invalid transactions should certainly not be the default behaviour. I wish options like this would be introduced once there is a use case requesting for it. 2) Please point me to the code

We created a noop system chain code that does nothing but store an invoke transaction. Since it is a system chain code written in go and deployed at startup, it does not require the grpc-docker

Tamas, I am in the learning mode and appreciate your patience 1. I understand and agree with construction time comment as time stamp is not always equal as I understand it (and for lack of a

Tamas, the sdk code/doc here: https://github.com/hyperledger/fabric/tree/master/sdk/node tx id is set in this module https://github.com/hyperledger/fabric/blob/master/sdk/node/src/hlc.ts (search for

Tamas, In my experience maximizing throughput requires running multiple clients. You should be able to at least double if not triple your throughput by running 16 clients - assuming you have the

Description Cancel this repeated meeting to create weekly meeting each week to include newly joined membersCancel this repeated meeting to create weekly meeting each week to include newly joined

Description https://meetings.webex.com/collabs/meetings/join?uuid=M7ME8OZ0FX8ZY45U79CEWHFSOD-9VIB Meeting number: 195 533 376 Audio Connection: +1-415-655-0001 US TOLL Access code: 195 533 376 Can't

Hi Binh, I do not think this addresses the same problem. Generating uuid for queries is unrelate to the requirement of being able to compute tx id at its construction for invoke. I am surprised to see

Hi Tamas, We probably should chat on slack as I don't follow your comment > Generating uuid for queries is unrelate to the requirement of being able to compute tx id at its construction for

Tamas, Can you elaborate a little on the intended form and usage of this client-specified tran-id? I'm going to imagine what your requirement is about, but perhaps I'll get it wrong: It seems

Tamas, Just for clarity, could you describe how you ran this test? Perhaps, with details sufficient for reproduction? --chet--

Hi Chet, the purpose is that constructor of a transaction, the client, knows what id the tx will have on block chain. I do not suggest client specified id, but client specified derivation of the id

We will submit a pull request within days, that allows reproduction on its branch. Tamas Blummer CHIEF LEDGER ARCHITECT Digital Asset T: +36 1 883 0300 E: tamas@... W:

Tamas, Oh ... let me say back to you: (1) you DO NOT mean that the client gets to specify the tran-id directly (or even any part of it) (2) you DO mean, that the client can itself compute the