Date   
Command linue usage change

Sheehan Anderson <sheehan@...>
 

Hi

A PR has been merged into the fabric project that makes some significant changes to the command line usage. You can read the details at https://github.com/hyperledger/fabric/pull/1357. Additional discussion can be found at https://github.com/hyperledger/fabric/issues/1158. The consensus from discussion was that this is a step in the right direction, but does not exclude additional changes in the future.

I'd like to thank https://github.com/lehors for his effort in making this change happen.

Regards,
Sheehan Anderson
sheehan@...

Re: Command linue usage change

Baohua Yang
 

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:

Hi

A PR has been merged into the fabric project that makes some significant changes to the command line usage. You can read the details at https://github.com/hyperledger/fabric/pull/1357. Additional discussion can be found at https://github.com/hyperledger/fabric/issues/1158. The consensus from discussion was that this is a step in the right direction, but does not exclude additional changes in the future.

I'd like to thank https://github.com/lehors for his effort in making this change happen.

Regards,
Sheehan Anderson
sheehan@...


_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--
Best wishes!
Baohua

regular weekly hyperledger/fabric technical planning with maintainers

Binh Q Nguyen <binhn@...>
 

Hi Folks,

I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.

We would document these items as issues on Boards->Current and requesting contribution from the community to implement.

I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).

Let me know if this is workable for you or propose a few time slots.

Thanks,

- Binh

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@...]
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,

I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.

We would document these items as issues on Boards->Current and requesting contribution from the community to implement.

I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).

Let me know if this is workable for you or propose a few time slots.

Thanks,

- Binh

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
London
EC4M 7LS

Registered in England and Wales No 05369106

Re: regular weekly hyperledger/fabric technical planning with maintainers

Sheehan Anderson <sheehan@...>
 

+1

-Sheehan

"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.

From: "Haskins, Gregory" <GHaskins@...>
To: Binh Q Nguyen/Raleigh/IBM@IBMUS, Tamas Blummer <tamas@...>, "robert@..." <robert@...>, Sheehan Anderson/Durham/IBM@IBMUS
Cc: "hyperledger-fabric@..." <hyperledger-fabric@...>
Date: 05/16/2016 06:01 PM
Subject: RE: regular weekly hyperledger/fabric technical planning with maintainers





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,

I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.

We would document these items as issues on Boards->Current and requesting contribution from the community to implement.

I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).

Let me know if this is workable for you or propose a few time slots.

Thanks,

- Binh

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
London
EC4M 7LS

Registered in England and Wales No 05369106


Re: regular weekly hyperledger/fabric technical planning with maintainers

Baohua Yang
 

+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:

Hi Folks,

I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.

We would document these items as issues on Boards->Current and requesting contribution from the community to implement.

I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).

Let me know if this is workable for you or propose a few time slots.

Thanks,

- Binh


_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--
Best wishes!
Baohua

Re: regular weekly hyperledger/fabric technical planning with maintainers

Tamas Blummer <tamas@...>
 

Good idea. Please send schedule suggestion.


Tamas Blummer
CHIEF LEDGER ARCHITECT



C: +36 30 4605877 

On 17 May 2016, at 00:17, Sheehan Anderson <sheehan@...> wrote:

+1

-Sheehan

<graycol.gif>"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.

From: "Haskins, Gregory" <GHaskins@...>
To: Binh Q Nguyen/Raleigh/IBM@IBMUS, Tamas Blummer <tamas@...>, "robert@..." <robert@...>, Sheehan Anderson/Durham/IBM@IBMUS
Cc: "hyperledger-fabric@..." <hyperledger-fabric@...>
Date: 05/16/2016 06:01 PM
Subject: RE: regular weekly hyperledger/fabric technical planning with maintainers





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,

I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.

We would document these items as issues on Boards->Current and requesting contribution from the community to implement.

I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).

Let me know if this is workable for you or propose a few time slots.

Thanks,

- Binh

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
London
EC4M 7LS

Registered in England and Wales No 05369106





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.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

busywork

Bishop Brock <bcbrock@...>
 

The busywork exerciser framework has been added to the Hyperledger fabric as fabric/tools/busywork.

Busywork has a few prerequisites that have been added to the setup scripts, however you don't need to recreate your Vagrant environment to use busywork. Simply SSH into Vagrant and

sudo apt-get install -y tcl tclx tcllib

and you should be all set to try some of the examples documented in the fabric/tool/busywork/README.me

I hope the community finds this to be a useful tool.

Bishop

Bishop Brock : Research Staff Member : IBM Master Inventor
IBM Research : +1 (512) 286-5453 [Office] : +1 (512) 568-9467 [Mobile]
http://researcher.ibm.com/researcher/view.php?person=us-bcbrock

Re: busywork

Baohua Yang
 

Great work, bishop!


On Fri, May 20, 2016 at 7:48 AM, Bishop Brock <bcbrock@...> wrote:

The busywork exerciser framework has been added to the Hyperledger fabric as fabric/tools/busywork.

Busywork has a few prerequisites that have been added to the setup scripts, however you don't need to recreate your Vagrant environment to use busywork. Simply SSH into Vagrant and

sudo apt-get install -y tcl tclx tcllib

and you should be all set to try some of the examples documented in the fabric/tool/busywork/README.me

I hope the community finds this to be a useful tool.

Bishop

Bishop Brock : Research Staff Member : IBM Master Inventor
IBM Research : +1 (512) 286-5453 [Office] : +1 (512) 568-9467 [Mobile]
http://researcher.ibm.com/researcher/view.php?person=us-bcbrock


_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--
Best wishes!
Baohua

Documentation - help wanted

Josh Horton
 

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


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 access your meeting? Get help:
https://meetings.webex.com/collabs/#/support


Other Hyperledger meetings:
https://github.com/hyperledger/hyperledger/wiki/PublicMeetingCalendar

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 access your meeting? Get help:
https://meetings.webex.com/collabs/#/support


Other Hyperledger meetings:
https://github.com/hyperledger/hyperledger/wiki/PublicMeetingCalendar

Action required by developers using the Vagrant environment

Sheehan Anderson <sheehan@...>
 

Hi

Two pull requests were merged today that require some additional steps for developers using the Vagrant environment.

https://github.com/hyperledger/fabric/pull/1529
https://github.com/hyperledger/fabric/pull/1613

1529 changes the mapped REST port in Vagrantfile from 3000 to 5000. This is now the same as the peer's default REST port. This was done to reduce confusion that was being caused by Vagrant mapping the REST port to a different port on the host machine. To pick up the change, simply run "vagrant halt" followed by "vagrant up". The default REST port will now always be 5000 in all environments.

1613 adds /hyperledger/build/bin to the PATH. This will eventually be used for build artifacts so developers can simply run commands such as "peer node ..." from any location. This requires no immediate action, but eventually it will be necessary to run "vagrant destroy" "vagrant up" when build artifacts are added to this directory. Thanks to Greg Haskins for this change.

These changes were merged in tandem to reduce the impact on developers. Please reach out if you encounter any issues.

Thanks,
Sheehan Anderson
sheehan@...

Re: Action required by developers using the Vagrant environment

Baohua Yang
 

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:

Hi

Two pull requests were merged today that require some additional steps for developers using the Vagrant environment.

https://github.com/hyperledger/fabric/pull/1529
https://github.com/hyperledger/fabric/pull/1613

1529 changes the mapped REST port in Vagrantfile from 3000 to 5000. This is now the same as the peer's default REST port. This was done to reduce confusion that was being caused by Vagrant mapping the REST port to a different port on the host machine. To pick up the change, simply run "vagrant halt" followed by "vagrant up". The default REST port will now always be 5000 in all environments.

1613 adds /hyperledger/build/bin to the PATH. This will eventually be used for build artifacts so developers can simply run commands such as "peer node ..." from any location. This requires no immediate action, but eventually it will be necessary to run "vagrant destroy" "vagrant up" when build artifacts are added to this directory. Thanks to Greg Haskins for this change.

These changes were merged in tandem to reduce the impact on developers. Please reach out if you encounter any issues.

Thanks,
Sheehan Anderson
sheehan@...


_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--
Best wishes!
Baohua

Cancelled: Hyperledger Fabric Technical Planning

Binh Q Nguyen <binhn@...>
 

Description


US Memorial Day US Memorial Day

Next consensus architecture proposal

Marko Vukolic
 

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

Josh Horton
 

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?

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.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Re: Limits to generality

Marko Vukolic
 

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 -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: hyperledger-fabric@...
Cc:
Subject: [Hyperledger-fabric] Limits to generality
Date: Thu, Jun 2, 2016 12:07 PM
 
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?
 
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.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
 

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



On 02 Jun 2016, at 13:19, Marko Vukolic <ZRLMVU@...> wrote:

Dear 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 that get submitted to consensus service (ala Bitcoin, Ethereum)
b) rate-limiting 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 is certainly an implementation 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




From:        Tamas Blummer <tamas@...>
To:        hyperledger-fabric@...
Date:        06/02/2016 12:07 PM
Subject:        [Hyperledger-fabric] Limits to generality
Sent by:        hyperledger-fabric-bounces@...




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?

TAMAS BLUMMER
​CHIEF LEDGER ARCHITECT​


<Mail Attachment.png>
+​36 1 883 0300
​tamas@
digitalasset.com
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.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message._______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




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.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Re: Limits to generality

Marko Vukolic
 

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 -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: Marko Vukolic/Zurich/IBM@IBMCH
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Limits to generality
Date: Thu, Jun 2, 2016 1:25 PM
 
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
 
 
On 02 Jun 2016, at 13:19, Marko Vukolic <ZRLMVU@...> wrote:
 
Dear 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 that get submitted to consensus service (ala Bitcoin, Ethereum)
b) rate-limiting 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 is certainly an implementation 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




From:        Tamas Blummer <tamas@...>
To:        hyperledger-fabric@...
Date:        06/02/2016 12:07 PM
Subject:        [Hyperledger-fabric] Limits to generality
Sent by:        hyperledger-fabric-bounces@...



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?

TAMAS BLUMMER
​CHIEF LEDGER ARCHITECT​


<Mail Attachment.png>
+​36 1 883 0300
​tamas@
digitalasset.com
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.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message._______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...

https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

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.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric