|
Command linue usage change
Sheehan Anderson <sheehan@...>
Hi
|
|
|
|
Re: Command linue usage change
Great, that makes the usage more clearly! While considering the possible changing to REST APIs in future, should we add some version number in the URL path to keep compatibility? e.g., /v1/chain/blocks/{Block}
On Thu, May 12, 2016 at 10:43 PM, Sheehan Anderson <sheehan@...> wrote:
--
Best wishes!
Baohua
|
|
|
|
regular weekly hyperledger/fabric technical planning with maintainers
Binh Q Nguyen <binhn@...>
Hi Folks,
|
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
Haskins, Gregory <GHaskins@...>
Hi Binh,
I think that is a good idea, and Monday 11a ET works for me.
-Greg
From: Binh Q Nguyen [mailto:binhn@...]
Hi Folks, Please read these warnings and restrictions: This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence. If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000. We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities. London Stock Exchange Group plc 10 Paternoster Square Registered in England and Wales No 05369106
|
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
Sheehan Anderson <sheehan@...>
+1 Hi Binh, I think that is a good idea, and Monday 11a ET works for me. -Greg
From: Binh Q Nguyen [mailto:binhn@...]
Sent: 16 May 2016 16:50 To: Haskins, Gregory; Tamas Blummer; robert@...; Sheehan Anderson Cc: hyperledger-fabric@... Subject: regular weekly hyperledger/fabric technical planning with maintainers Hi Folks, Please read these warnings and restrictions: This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence. If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000. We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities. London Stock Exchange Group plc 10 Paternoster Square Registered in England and Wales No 05369106
|
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
+1 to support the meeing. Would like to try attending it, while hour earlier would be better for me. Thanks!
On Tue, May 17, 2016 at 4:49 AM, Binh Q Nguyen <binhn@...> wrote:
--
Best wishes!
Baohua
|
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
Tamas Blummer <tamas@...>
Good idea. Please send schedule suggestion.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.
|
|
|
|
busywork
Bishop Brock <bcbrock@...>
The busywork exerciser framework has been added to the Hyperledger fabric as fabric/tools/busywork.
|
|
|
|
Re: busywork
Great work, bishop!
On Fri, May 20, 2016 at 7:48 AM, Bishop Brock <bcbrock@...> wrote:
--
Best wishes!
Baohua
|
|
|
|
Documentation - help wanted
Hello Team,
Hyperledger has some documentation help wanted issues that you can contribute to! Simply add a comment to the issue as you start working on one, and add additional comments to keep the community informed of your progress. Collaboration in encouraged. Graphic design and text needed: https://github.com/hyperledger/fabric/issues/1536 Proposed "welcome" text with prereqs. and audience: https://github.com/hyperledger/fabric/issues/1491 Improved web / PDF / etc. output doc displays sought: https://github.com/hyperledger/fabric/issues/1262 Thanks, Josh Joshua H. Horton IBM Blockchain Information Development 2455 South Road Poughkeepsie, NY 12601 Email: joshh@... Tel: 845-433-1711
|
|
|
|
Invitation: Hyperledger Fabric Technical Planning (May 23 10:00 AM EDT)
Binh Q Nguyen <binhn@...>
Description
|
|
|
|
Action required by developers using the Vagrant environment
Sheehan Anderson <sheehan@...>
Hi
|
|
|
|
Re: Action required by developers using the Vagrant environment
Great work, sheehan! While for #1613, will we eventually trigger cmdline from `/hyperledger/build/bin`, instead of `$GOPATH/bin`? Or we will keep both? Thanks!
On Fri, May 27, 2016 at 5:01 AM, Sheehan Anderson <sheehan@...> wrote:
--
Best wishes!
Baohua
|
|
|
|
Cancelled: Hyperledger Fabric Technical Planning
Binh Q Nguyen <binhn@...>
Description
|
|
|
|
Next consensus architecture proposal
Marko Vukolic <MVU@...>
Hi all,
As discussed on the last HL Arch WG call on Wednesday - the proposal for the next consensus architecture is now published and posted here: https://github.com/hyperledger/fabric/wiki/Next-Consensus-Architecture-Proposal .There is a github issue for aggregating comments and discussion: https://github.com/hyperledger/fabric/issues/1631
As you will see, this is meant to be a live document with current version simply proposing the foundation of the design.
More work is needed, so please review, comment, discuss and contribute.
Best,
Marko Dr. Marko Vukolić email: mvu@... Research Staff Member tel: +41-44-724-8434 IBM Research - Zurich Säumerstrasse 4 CH-8803 Rüschlikon, Switzerland
|
|
|
|
Documentation - help wanted
Hello!
A new documentation proposal / Issue has been added: https://github.com/hyperledger/fabric/issues/1642 Thanks, Josh Joshua H. Horton IBM Blockchain Information Development 2455 South Road Poughkeepsie, NY 12601 Email: joshh@... Tel: 845-433-1711 ----- Forwarded by Joshua Horton/Poughkeepsie/IBM on 05/27/2016 05:30 PM ----- From: Joshua Horton/Poughkeepsie/IBM To: hyperledger-fabric@... Date: 05/20/2016 12:40 PM Subject: Documentation - help wanted Hello Team, Hyperledger has some documentation help wanted issues that you can contribute to! Simply add a comment to the issue as you start working on one, and add additional comments to keep the community informed of your progress. Collaboration in encouraged. Graphic design and text needed: https://github.com/hyperledger/fabric/issues/1536 Proposed "welcome" text with prereqs. and audience: https://github.com/hyperledger/fabric/issues/1491 Improved web / PDF / etc. output doc displays sought: https://github.com/hyperledger/fabric/issues/1262 Thanks, Josh Joshua H. Horton IBM Blockchain Information Development 2455 South Road Poughkeepsie, NY 12601 Email: joshh@... Tel: 845-433-1711
|
|
|
|
Limits to generality
Tamas Blummer <tamas@...>
It is an art to create a fabric that is generic enough for anticipated use cases but have limits such that it remains practical. I think fabric overshoot on generality on some fronts risking its viability for real world projects. Two examples: 1. It stores invoke transactions where chain code execution fails together with error report. While it might appeal for debugging this turns out to be an open door for DoS attacks or simply filling up the blockchain with junk by one misbehaving client. All network participants suffer severe performance degradation in consequence. The blockchain should not be an error log but only contain transactions that were accepted syntactically and semantically correct by their chain code. 2. Server assigned UUID of transactions While it ensures that transactions can be uniquely referenced it disallows tracking of a transaction from its originating process through the block chain. Transaction ID should instead be set at construction time, best derived with a crypto hash of its content, so it is not feasible to create a different transaction that is valid but has the same ID. This would disallow submitting identical transactions, which however is either an error or is easy to remediate at the constructing peer. One could argue for both design choices for the sake of generality and I think both would be ruled out once you would build a practical system. Do you agree with me and would reduce generality in these cases? This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.
|
|
|
|
Re: Limits to generality
Marko Vukolic <MVU@...>
Hi Tamas,
1) I would argue that all blockchains incl. Bitcoin and Ethereum store invalid transactions as well - in case of Bitcoin and Ethereum these are "orphaned blocks" that are still kept around in case their fork (branch), eventually prevails.
For me, the question of keeping only the validated ledger (in the parlance of the next consensus architecture proposal - NCAP) is the question of where one decides to make things visible to the "public". For instance, an implementation could wrap consensus service (from NCAP) together with (optimized) checkpoint as described there - and expose only the validated ledger, discarding raw ledger invisibly wrt. "public".
Re DoS, it is true that, unlike in Bitcoin or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the raw ledger. To me, the main tools we would have against this are:
a) deployment-specific currency to charge transactions fees that get submitted to consensus service (ala Bitcoin, Ethereum) b) rate-limiting the number of individual clients' outstanding requests (needs to be done by the consensus service) c) as tx are signed - hold submitting peers accountable for garbage tx by a separate mechanism. This is certainly a possibility in permissioned implementations. d) have consensus look into a transaction to say if it is a "legitimate" one. This last one goes into direction of having consenters as committers - it is not clear to me that we want this in the generic design - but this certainly remains an implementation/deployment possibility. I am not sure that we would want to make d) a mandatory approach and sacrifice the possibility of entirely decoupling the consensus service from state/chaincode.
2) I agree - In NCAP this UUID roughly corresponds to tid (tx id) - perhaps we can amend that one to fit what you have in mind.
Cheers, Marko
----- Original message -----
|
|
|
|
Re: Limits to generality
Tamas Blummer <tamas@...>
Dear Marko,
Your comparison does not hold with Bitcoin and Ethereum. Transactions in orphan blocks are valid with respect to the script rules = chain code in Hyperledger. TAMAS BLUMMER CHIEF LEDGER ARCHITECT  +36 1 883 0300 tamas @digitalasset.com
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.
|
|
|
|
Re: Limits to generality
Marko Vukolic <MVU@...>
Dear Tams,
yes - I reflected this in "unlike in Bitcoin or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the raw ledger"
yet, Bitcoin and Ethereum store invalid (in the sense of - unsuccessful) tx (in orphaned blocks)
Cheers, Marko
----- Original message -----
|
|
|
"Haskins, Gregory" ---05/16/2016 06:01:45 PM---Hi Binh, I think that is a good idea, and Monday 11a ET works for me.
