mmm #poll




See Who Responded




..*Sorry, We.made a_mistake_Use this approval!*.. #poll




























































































View email in your browser

Last Friends & Family before Christmas! Hurry, use your coupon before it's gone!

Big Lots
Weekly Deals
Weekly Ad
Store Locator
For The Home
All Departments
Last day to save
Get your coupon
Shop now
Shop Departments
Customer Care
Buzz Club Rewards
My Account

*Promotional offer valid only at Big Lots stores and on pre-tax purchases. Limit one coupon per customer, per transaction. This offer does not apply to shipping charges, previous transactions, price holds, non-purchases such as rentals, deposits, charitable donations, purchases of milk, dairy products, eggs and/or purchases of gift cards. Cannot be used in combination with any other offer, coupon, discount or associate discounts. Value is forfeited if item is returned. By attempting to redeem this offer, user unconditionally agrees that decisions of Big Lots are final on all matters of interpretation, fact and procedure with respect to this offer. Valid only on in stock goods. Void where prohibited. No cash value or cash back. Coupon may not be sold. Buzz Club Rewards member 10/01/16 online offer valid @ 12:00 am EST until 11:59 pm EST only. To redeem online, sign in to Buzz Club Rewards account before checkout, and offer will be automatically applied. Buzz Club Rewards member 10/01/16 in store offer valid all day open until close. To redeem in store, present Buzz Club Rewards card at checkout. For all customers, 10/02/16 online offer valid @ 12:00 am EST until 11:59 pm PST. To redeem online, enter promotion code FRIENDS at checkout. For all customers, 10/02/16 in store offer valid all day open until close. To redeem in store, present coupon to cashier at checkout.

Due to the nature of our business, Buyouts, Closeouts and Special Buys, we must limit our sale to stock on hand. Sorry, no rainchecks. Comparative pricing on new items is based on same or similar items sold elsewhere. Comparative pricing on reconditioned items reflects savings when compared to same or similar factory new items sold elsewhere. "Extreme Values…well below prices found elsewhere" applies to comparative pricing for products specifically identified in this ad as "Extreme Values." We do not accept manufacturers‘ coupons.

Please do not reply to this message. Replies to this message are routed to an unmonitored mailbox. We're happy to help you with any questions or concerns you may have. Please contact us directly 24/7 via

Visit    Weekly Ad   |  Store Locator   |   My Account   |   Help   |   Contact Us  |   Privacy Policy

This email was sent to: martin.boss16@...
This email was sent by: Big Lots Stores, Inc., 300 Phillipi Rd, Columbus, OH, 43228-5311, USA
Your favorite store:Please login and select a favorite store to view local deals.   Update   |   Map

To ensure delivery to your inbox, please add biglots@... to your address book.

You are receiving this email because you signed up to receive emails at one of our stores or via

If you would like to change or modify your email subscription, please visit My Account. If you would like to cancel your email subscription, click UNSUBSCRIBE now and we will promptly remove you from our list.


See Who Responded

sdfsdfsdfsdf #poll


sdfsdf sfsdf sdfsd f


See Who Responded

Scorex 2.0 Pre-Announce

Alexander Chepurnoy

Dear maillist reader,

Last release 1.2.8 was on Jun, 9th. Does that mean development is not active at the moment? No! We are working hard towards a very major release 2.0.

Scorex 1.x was built with an idea expressed by L.M. Goodman. The idea is that a cryptocurrency design is about few protocols: network, consensus and transactional (my article on that: ). Implementation of the idea in Scorex is described in "On the Way to a Modular Cryptocurrency" blog series ( ) and wiki.

There are still some problems about flexibility of design in Scorex 1.x

- Full block is signed with pre-defined signature scheme. In Bitcoin there is no signature for a block or a blockheader (in PoW that is an overkill). Full block/blockheader separation is impossible, as well as Bitcoin-NG microblocks etc.
- Signature scheme is hardcoded into transactions, only simple signing is possible(no Bitcoin-like scripts).
- Node state being updating via impure functions returning just Unit(so hiding all the effects). Even worse, updates are spread around the codebase.

What is coming:

- The most abstract authentication model possible, just (trait Proposition) and (trait Proof[P <: Proposition]) in the bottom.
- Abstract state elements, just (Box[P <: Proposition]) in the bottom(you can get Bitcoin-like output or Ethereum-like account from a Box)
- Very abstract transaction notion in the bottom as well
- Updates return new version of an entity.
- Centralized storage of a stable reference to a node state. Node state is a quadruple (State, History, MemoryPool, Wallet). On block processing, for example, all the components are to be updated. Update semantics is to be defined clearly. We can get laws checking easily for such approach. For example, with property testing we can check the law: "for any quadruple, if we apply N valid blocks and then go back for N version, the resulting quadruple will be the same as original one". Then a machine will generate thousands of test samples and check the law against them. Also, it would be much easier to find bugs of read-when-update kind (very painful to find usually).
- Flexible hierarchy of node state modifiers: transaction, full block, block header, state snapshot, key and micro blocks etc.
- All the modules are to be extracted. So Scorex core (with < 4K LoCs) will fit in the dedicated repository. Maybe some example micro-application will be provided (really micro, with in-memory storage etc).
- Wallet reworked

The list is not final. I still need to figure out some things before first milestone version.

Later we will need to improve network layer(peer discovery etc). That's planned for 2.1.

And we are preparing manual for Scorex 2.0 to describe a new design with finer granularity. A current draft is about 23 pages at the moment, final version will be about 30-40 pages. The manual will be released along with the code.

I would be happy to get our concepts and code reviewed. Let's discuss them over this maillist and chat ( ).

Sincerely, kushti

Re: Some Questions about scorex

Alexander Chepurnoy

Hi Wilson! And thanks for the interest!

In the first place, I would like to say we are making progress as fast as never before. Unfortunately, the work isn't visible right now.

My plan for the summer after 1.2.x releases was to make a big refactoring in 1.3 and the to implement Ergaki. Unfortunately, I found I want to rewrite way too much, so now it is 2.0, not 1.3.

2.0 is a complete redesign. It uses Scala type system extensively and aiming to be more pure, modular and extensible. It lives in separate bunch of repositories (not sure this is the final place). We're welcoming contributions, and working on current problems list to make road to the release fully observable. Pre-release text will be published in this month hopefully. We are also working on manual, it will be released along with code. The manual is about 15 pages now, a released version will be ~30 probably.

After 2.0 release we will start to implement next testnet, Ergaki. Basically nothing is changed here, the only probable addition is Proofs-of-Proof-of-Work with sublinear complexity implementation ( ).

The basic idea of Ergaki is blockchain without a bloat, so it would be extremely good for key-value databases. It will use special Proof-of-Work (, I'm writing a new version now) though, so not much suitable for a private environment.

On a "private blockchain", in most cases if you need for replicated append log there are more suitable options in the field of PBFT algorithms, like Zyzzyva, Aardvark etc. In certain cases a blockchain with Proof-of-Stake would be useful though.

I think Scorex 1.x could be used for a prototype implementation. Also Alan McSherry has implemented a ledger constructor using something like Raft(he started with some early version Scorex, but have rewritten it heavily). The link is .

Sincerely, Alexander

Some Questions about scorex

Wingston Sharon

Hi all,

Just stumbled onto your github and had some queries about scorex and permacoin implementation and current state.

i wish to develop a (private) local key value distributed storage mechanism running on a blockchain. 
by private i mean in a blockchain that is not bitcoin or ethereum etc.

can a proof of concept be estabilished for such a network upon scorex or Lagonaki testnet implementation in its current state?

Also what is Ergaki? you make no mention of it outsite an old email.

Is this project under current development? Or is it a project looking for an owner?

[Wilson Wingston Sharon]

Scorex: plans for the next few months

Alexander Chepurnoy

Hi folks!

Here I want to outline Scorex development plans until September-October. I'm happy to see the plans correspond to previously published roadmap for April (archive: [1] )

Versioned Merkle trees are more or less done in Scrypto(current version is 1.2.0-M3), there are few bugs to fix and few tests to be written. We have new Scorex minor releases weekly, 1.2.6 coming will be last planned in 1.2.x row(unplanned bugfix releases could be after 1.2.6 as well).

1.3.0 draft is mostly ready(it is in "txrework" branch), and this version about more flexible transactional layer, specifically, Scorex will support box-based(i.e.  Bitcoin-like) transactional models, not only account-based(think of Nxt & Ethereum), and instead of "signature" a transaction will have more general "proof" field.

After 1.3.0 release we will start to work on Ergaki, a next testnet release. It will be totally innovative concept unlike Lagonaki(which is Permacoin + simplified Nxt payment transactions basically).

Ergaki's main planned features were described briefly in  the April roadmap [1]. Before implementation I'll work on specifications and hope to finish during May, then we will hopefully implement it before September. for transactional layer, I'm thinking about non-interactive zero-knowledge proofs of knowledge for some particular problems.

Ergaki is planned to be a backend for protocols, a "public bulletin board" aiming to handle number of requests unimaginable in Bitcoin/Ethereum during peak-time.


Best regards, kushti

Scorex 1.2.2 and roadmap for April

Alexander Chepurnoy

Dear Scorex maillist subscribers,

In the first place I am happy to announce new Scorex release 1.2.2 published on GitHub and Sonatype on last Sunday. Release notes could be found in [1].  the most significant modification is the exclusion of a runnable application. So from now Scorex is modular framework for developers only, and to launch application connecting to our first public testnet called Lagonaki, there is another repository for that [2]. Note that Permacoin implementation is externalized into another repository as well [3]. 

On Monday a new paper of mine has been published on Arxiv [4]. Basically it is about a new Proof-of-Work scheme reminds Permacoin but using state snapshots in the past instead of static dataset. Thus we can get some interesting bonuses, e.g. fast trustless bootstrapping and safe blockchain pruning(with purging old full blocks).

For Permacoin implementation we have developed static Merkle trees with on-disk persistence(as Permacoin is about huge trees). Later a Merkle tree functionality was extracted into Scrypto framework [5]. Now I'm working on versioned updateable Merkle trees within Scrypto.

Why authenticated data structures(and Merkle trees specifically) are important in a blockchain development? There are so many applications of them actually:

1. Light clients could get transactions and state elements along with proofs(see Buterin's "Merkling in Ethereum" [6]
). In Proof-of-Stake cryptocurrencies light clients could exist only if a state being Merklized(see White's paper[7]).

2. With Merklized state even fullnodes can store only a part of state(White's paper, again [7]). As a drawback that means increased transaction size and heavy transaction validation(due to Merkle proof check), the latter could be solved with SNARKs though.

3. They are needed in some consensus protocols, namely Permacoin and the new scheme of mine [4].

So I'm working on reworking Merkle trees implementation and will finish that work with benchmarking(e.g. 40M elements with few K updates, somewhat like block processing with current Bitcoin state).

After that I'll start to work on Ergaki specification. Ergaki is the next public testnet to be launched somewhen in the summertime. Unlike Lagonaki, it will be innovative in every aspect and based on work done in IOHK Research:

1. New proof-of-work scheme from [4], or, more likely, Bitcoin-NG - like scheme with proof-of-stake or some BFT algo for microblocks. Maybe Interactive Proof-of-Stake, also from me [8]. Rational behaviour by default, i.e. a node deletes blocks not needed for mining.

2. New transactional module. It will be about boxes [9], but not UTXOs from Bitcoin. Concrete proposal is to be decided yet.

3. New fees model. Basically, a fee will be not about transaction size, but state increasement size. So if a transaction is about state size lowering, it is about minimal or no fee at all. And storing boxes in a state will be charged not for size, but for life timespan also(with possible exception for a minimal template box). This way Ergaki would be intended to be not a digital gold but a public bulletin board for protocols mixed with an economy.

4. New difficulty adjustment algo. A paper on that is basically ready and will be released before summer.

As you can see, Ergaki could be called freaky in comparison with cryptocurrencies of today(especially because of the fees model I guess). But I believe that would be an interesting experiment. Also it would be a good test for Scorex flexibility.

Back to Scorex, we aim to have a minor release weekly. Next release will be about some bugfixing, and then we'll implement peers blacklisting(for now the network is vulnerable to rogue peers). For Lagonaki, we need to fix some issues with a Debian package and Docker image.

Summarizing, plans for April are to finish efficient updateable persistent Merkle trees, write down Ergaki specification, ensure Scorex is flexible enough for Ergaki implementation(and refactor if not), also bugfixing and network layer improvements in Scorex.


Best regards, Alexander.

Scorex Modules: implementing Best Backend for SMCs / SMPs

Alexander Chepurnoy

Hi dear subscribers!

At the moment Scorex has only the simplest transactional module, basically about token transfers from one pubkey to another. It is possible to implement Bitcoin-like transactions as the next step, but I would like to swing with experiments instead.

In the first place I would like to apologize for my lack of knowledge in SMCs/SMPs, it is basically about half of (the awesome) Lindell/Harzay book, few papers, lectures and some experiments with ScAPI framework from Lindell&his students.

I would like to implement a blockchain system which is optimal as backend for protocols safe against covert adversaries(so a cheating adversary would be caught with overwhelming probability). I would like to gather requirements for such a system. 

Please share your thoughts, and after that I'll propose a draft spec.

Best regards, Alexander

Coordinated Contributions

Alexander Chepurnoy

Hi dear subscribers!

We are still changing basic structures in order to achieve greatest level of flexibility, but it is a good time to start contributions I guess!

One guy outside our core team is implementing block explorer for the Lagonaki public testnet release.

For now Scorex has only simplest Account-based transactional model, which is basically about tokens transfer from one pubkey to another. It would be great to see someone implemented Bitcoin transactional model. Basic interfaces are in the core(box transactional model). I think it is possible to implement is as module using BitcoinJ classes for Bitcoin-specific things.

We don't have resources and a wish to implement it within our core team. Having time to implement a transactional model, it makes more sense to implement something more experimental.

Best regards. Alexander.

21 - 31 of 31