Skip to content
Lashaantadze edited this page Mar 28, 2016 · 2 revisions

Decentralised System of Blockchain - Auctions eAuction

Whitepaper (draft)

Overview Goals and purpose of creating System

The aim of the project is The aim of the project is to build up a transparent, decentralised e-Auction system for state property privatisation and lease, for minimising the existing corruption and mismanagement risks, eliminate corruption reduce the state budget expenditure and give barrier less access for participation in the process.

The system is created for performing the following tasks:

  • Maximum transparency. Any document, any information relating to the rent and sale of state property should be available online for all interested parties.
  • Simple, understandable and easy to use method of state-owned property rent and sale - an open auction.
  • All auctions should be only electronic.
  • Starting price of the auction should be known in advance. Closed information leads to corruption.
  • A participant cannot offer the price less than starting oriented price.
  • The documents from administrative agencies (such as the company registration license, tax clearance certificate, credential of absence of bankruptcy proceedings etc.) are provided only at the end and only by the candidate who offered the highest price.
  • The auction winner is determined under the rule pass/fail, e.g. on the principle of plus/minus the matching of participant and his offer with the technical requirements are valued. Consecutive participants assessment begins from the highest with regards to price. E.g. not all bids are assessed at once but only the participant with the highest price. If he corresponds to technical and qualifying requirements he is considered as a winner and other participants are not considered.
  • Any participant of the system may request clarification to the auction documentation. The auction organizer is obliged to answer the question within the time limits set. All answers should be available for all participants, as well as become an element of the auction documentation at once;
  • Any member may appeal any trade. In the case of not satisfied appeal the participant has the right to use the transactional data from the blockchain to start a court case;
  • Self sustainable economic model. Financial support should be ensured by self-financing mechanisms, and legal independence.
  • Any concerned person should have possibility to receive all the information connected to the specific auctions through Internet, including: * Auction announcements; * Auction documentation; * Offers of the auction participants; * Auctions records; * Payment confirmations of deposits and registration fees * All the correspondence relating to the auction; * Agreements with winners.

Terms definition

  • Electronic auction organizer (Organizer) - a public authority or a state-owned enterprise, which puts on the sale or rent a state property, licences through an electronic auction.
  • Electronic auction participant (Participant) - organization or individual on behalf of which the submission of the bid proposal in the electronic auction is performed.
  • Decentralized electronic auction system is the information-telecommunication system, through online web mode operation; automatic authorization of auction participants through bank confirmations.
  • Lot is the selling object defined in the electronic auction system, containing information about the initial value of the object, minimum auction start, time of beginning and end of the pre-exposition, exhibition and auction bidding.
  • Bid is a stake proposal from a participant of the electronic auction on the lot of the electronic auction.
  • Auction step is a range of minimum single bid increase on own previous proposal.
  • Electronic auction lot (Auction lot) is a corresponding transaction in the system, which includes information about the lot and the conditions of its purchase, defining the procedure for Decentralized electronic auction in automatic mode.
  • The electronic auction participant bid (auction bid) is the appropriate transaction in the system that includes information on the stake proposals from a participant of the electronic auction on the lot of the electronic auction.
  • The auction participant bid is accepted by the system only on the condition that it is higher than the own previous stake and the participation fee is payed.
  • Guarantor bank institution (guarantor account) is a state fund account, in accordance with organizer, is the holder of security deposits of the participants.
  • Registrar bank institution (registrar bank) is a bank, who provides an account to private trading platforms, in accordance with an agreement that allows the identification and receives payments of registration fees of participants.
  • Security deposit is an amount paid by physical or legal representatives on single auction lot to participate in online auction, the amount of fees is set by the law.
  • Registration fee is amount paid by the auction Participant to the trading platform operator to cover his costs. Registration fee is not subject to return to the auction Participant. The amount of fees is set by private trading platform providers.

Participants’ roles and their commitments Organizer is interested in:

  • Obtaining the highest possible price for the auction lot, through open competition among auction participants; Auction participant is interested in:
  • Simplicity and transparency of the auction;
  • Equality, complete and real-time access to information about all the auctions;
  • Fair competition with other participants of the auction. Trading Platform is Interested in:
  • a maximum inflow of organizers for diversity of trading lots
  • a maximum inflow of participants since they charge fixed amount of fee for participation in each auction. Observers are public and state organizations who are only tracing and monitoring the process of the auctions. They are interested in:
  • Public availability of all materials related to the organization and trading process;
  • Transparency of all processed transactions of the auction;
  • Presence of entire chain of validated transaction blocks;

Basic functions in the auction Organizers

  • Announce the auction launch date and publish additional conditions regulated by law;
  • Answer questions concerning the auction conditions;
  • Publish the results of a held auction;
  • Publish the approved agreement between the organizer and the winner;
  • Publish the court rulings in the blockchain.

Participants

  • Agree with the auction conditions;
  • Ask questions concerning the auction lots;
  • Register bids in the auction;
  • Pay registration and deposit fees; (if required)
  • File complaints; (if required)

Trading Platforms

  • Provide open access to the auctions using special app or web interface;
  • Provide additional services for: Organizers, participants, clients;
  • Notify the time for

Observers conduct online monitoring of the availability of the system data.

Proposed scenario of holding of e-auction

Requirements to the system architecture In the proposed system architecture:

  • placement and storage of data about the auction should be carried out in a virtual machine of contracts;
  • format and data exchange procedure should be used common for everyone, as well as the rules of holding of the auction, defined by public standard;
  • there should be provided the freedom of choice by each participant of the ways (themselves or through platforms) and means (with a help of self-developed software, or purchased or leased) of participation in the auction, but upon one condition - the compliance with the standards on the format and data exchange procedure and rules of holding of the auction;
  • advanced solutions should be used as basic ones, on the base of the source code operating without down time possibility access, censorship, fraud, or third party intervention. Proposed technical decisions System architecture

System components and requirements to them

  • Decentralized electronic auction meeting the requirements:
  • registers auction lots from the organizers in real-time mode;`
  • registers proposals of the auction participants (bids) in real-time mode;`
  • displays information about the appearance of new auction lots in real-time mode;`
  • guarantees the integrity of each lot and auction bids upon the Blockchain technology;`
  • allows any participant at any time to receive a copy of the lots base and auction bids;`
  • ensures high availability and failure safety levels of abovementioned services of the network due to distribution;`
  • provides the ability to store data about the lot and the auction bid in the form of interconnected electronic contracts,` the functionality of which can be easily extended and completed by the electronic services and integration with other automated systems.
  • The application of the auction Organizer.
  • Provides UI for:
  • auctions initiation;
  • addition of materials of the auction;
  • display the course of the auction in real-time mode;
  • display the results of holding of the auction.

System components and requirements to them

  • Decentralized electronic auction meeting the requirements:
  • registers auction lots from the organizers in real-time mode;
  • registers proposals of the auction participants (bids) in real-time mode;
  • displays information about the appearance of new auction lots in real-time mode;
  • guarantees the integrity of each lot and auction bids upon the Blockchain technology;
  • allows any participant at any time to receive a copy of the lots data base and auction bids;
  • ensures high availability and safety levels of abovementioned services of the network due to distribution;
  • provides the capacity to store data about the lot and the auction bid in the form of interconnected electronic contracts, the functionality of which can be easily extended and completed by the electronic services and integrated with other automated systems.
  • The application of the auction Organizer.
  • Provides UI for:
  • auctions initiation;
  • addition of materials of the auction;
  • display the course of the auction in real-time mode;
  • display the results of holding auction;
  • search and display of the auction archive. ○ Generates according to the Standard XML-packages with the data about:
  • the auction lot (including: when the auction starts, ends, links to materials available through the Internet and file checksums of these materials);
  • Answers to questions and complaints from the participants;
  • the auction result.
  • Sends XML-packages with the data for the electronic contract about the lot of the auction to a Virtual machine of the electronic auction.
  • Monitors presence of new auction lots at the decentralized electronic auction.
  • Shows information about the auction lot and the identifier of the e-contract of the auction lot at the public specialized web-site.
  • Displays the time before start and till the end of the auction.
  • The application for the auction participant
  • Provides UI for:
  • search of the auction and familiarization with its data;
  • familiarization and copying the materials of the auction;
  • registration of the auction participant;
  • submitting proposal of the participant for the auction;
  • display caring of the auction in real-time mode;
  • display the results of the auction.
  • filing of complaints and questions to the auction organizer;
  • search and display of the auctions archive.
  • Generates according to Standard XML-packages with data about:
  • questions and complaints of the participant;
  • the registration data of the participant;
  • proposals (bids) of the Participant in the course of the auction.
  • Sends XML-packages with data for the electronic contract for bid registration on the auction contact to Decentralized electronic auction.
  • Monitors the appearance of new proposals of the Participants on the auction in Decentralized electronic auction. API Standard includes:
  • Requirements to the data format;
  • requirements to the protocols of System components interaction;
  • Requirements to the procedure for holding auctions and determination of the winner.

Auction phases in proposed architecture

  • Exposition begins immediately after the registration of the lot. During the exposition period registration of the auction Participants (registration of participants in other stages is not carried out) is carried out. Only those participants are allowed to the trading stage, which have registration and security deposit proof in the system. The exposition period and the size of the security deposit for the corresponding lot depends on its value and is defined in the following amounts:
  • on the lot, cost of which is up to a hundred million Hryvnias inclusive, exposition may not exceed three months, and a security deposit is ten percent of its value;
  • on the lot, cost of which ranges from one hundred million Hryvnias to five hundred million Hryvnias inclusive - the period of exposition should be from three to six months, and a security deposit of such lot is five per cent of its value;
  • on the lot, which costs more than five hundred million Hryvnias - the period of exposition should be from three to nine months, and the security deposit of the lot is two per cent of its value;
  • on the lot, property that was the subject of a lease agreement, the period of exposition is one month and a security deposit is not required.
  • Electronic trading starts at 10.00, on the next working day after the end of the exposition period. Single time for e-trading period of two hours is set for all the lots. Bidding on the auction lot will not start and the auction is automatically removed from the trading (is closed) if there are no registered participants on the lot. If there is only one participant bidding is carried out according to the standard procedure and participant should submit at least one bid on the lot. Fee proposals of the trading participants (bids) shall comply with the following requirements:
  • The first bid should be higher than the opening price of the lot by the amount not less than the step of the auction.
  • Each subsequent bid of one trade participant should exceed his previous bid by at least one step of the electronic auction.
  • Participants of the electronic trading submit their bids independently and without any restrictions on the amount of the bids made by other participants.
  • The result of the electronic trading on a particular lot is the bid rating of participants who did not cancel their participation in the auction. The rating is automatically generated by the system upon the time expiry set for the holding of the stage of electronic trading.

Peculiarities of holding of the auction in the supposed architecture

  • Through the user interface of the Application the Organizer enters the necessary data for the registration of the auction.
  • Organizer’s application forms these data into a special structure XML and registers them in the system.
  • In a response the Application of the Organizer receives a unique ID code and the auction lot code, by means of which the auction lot (including sending and receiving messages on clarifying the conditions of the auction, the removal of the lot from the auction, etc.) is controlled.
  • After the displaying the auction lot ,its holding for all participants begins automatically at the specified moment.
  • The auction participants, through the user interface of the Participant’s Application by using the data of the auction lot identifier , received from the organizer’s web-site or from the platform where the Participants are located, or by using the search functional of the active auctions of the Participant’s Application, enter necessary data for the auction bid registration.
  • The Participant’s application forms these data in the special XML structure and sends them for registration in a form of transaction associated with the lot of the auction.
  • In return the Participant’s Application receives a unique bid identifier and a bid code by whereby the Participant may control it (including withdrawal of his bid from the auction or exit the auction).
  • after expiration of time allotted to auction bidding, the auction activity is completed, receiving bids on lot is stopped.

Vulnerabilities of proposed solution

  • Questions and complaints ignored by organizer .
  • This is solved by initiating appropriate checks in software displaying the result of the auction bidding.
  • In addition, if the participant will not be satisfied with the organizer's response to his complaint, he can always go to court by presenting the auction transaction log as the evidence of the complaint and unsatisfactory reply on it.
  • DDoS-attacks on separate sites or Participants.
  • This is solved by long trading period in order to maximize the value of the attack, and at the same time to give enough period to participants to switch to another platform/ communication channel.
  • Extreme overvalued bid and the subsequent refusal from the bid to manipulate the winner’s consideration order.
  • This is solved by independent bids acceptance from all the participants and consistent consideration of participants bid rating in the case of failure of payment of the lot of the candidate to the winner.

Model reaching consensus In order to achieve a consensus in the system of electronic auctions it is proposed to use model Proof-of-Stake, in which the ownership ratio will be the number of registered participants "standing" behind the platform. Consequences:

  • the right to form blocks will have only those platforms behind which there are registered participants;
  • formation of blocks is not tied to the platform of the organizer of the auction and the auction lot;
  • the fact of registration of the user on any auction lot should be registered and easily verifiable. At the first stage the fact of payment of the registration fee on a particular Lot in the System should be displayed by decentralized database of the bank statement signed by electronic digital signature of the registrar’s bank, which the Platform should receive at the end of Lot's exposition period from its registrar bank. Each Platform independently performs integration with its registrar bank to obtain extracts on the Lot in automatic mode. In the future, the fact of payment of the registration fee must be stored in the System database by the registrar bank through corresponding System API functions. Platforms and the Participants who integrated their relationship with crypto-currency systems can pay and receive payments of the registration fee without going through the registrar bank. In this case the payment fact should be confirmed by an extract and a Platform’s digital signature.

Activity registration Platforms which accepted registration fee from the Parties should make the registration of their activities with some periodicity to a decentralized database of auctions to provide the possibility of the platform performance determination and unauthorized switch off of the Participants (the cases when the Platform is "silent" for unknown reasons).

Identification at the auction This is done using the login and password, received by the Organizer or the Participant at the Platform at registration of the account of the e-auction system. In this case the Platform bears legal responsibility for the compliance of the user’s registration data in the system and also for documents. The private key (wollet) received with the account can be stored at the Platform (then there will be binding with a concrete platform) or at the removable device of the Organizer/ Participant (then one can work at from platform). Additionally, for the Participants who made payment of the registration fee on the auction Lot their identification by the registrar bank will be carried out upon receipt of payment as well as upon receipt of bids, the System will also carry out the validation of registration data about the Participant in the auction with the bank statement data, a mismatch of which would result in a denial of bids acceptance.

Registration fee The acceptance of the bids of auction Participants should be made by the System only when there is payment of the registration fee from the Participant on the lot (the presence of the payment is confirmed by bank statement attached with the bank’s electronic digital signature).

Security deposits For auctions connected with sales of the enterprises an integration with banking systems should be involved, so at the registration of the auction bid the system could perform verification of the presence of corresponding assets at the deposit account of the auction lot.

Auction lot data The following are the attributes and their type (in square brackets), which should be present on the auction lot:

    1. The account ID of the auction organizer
    1. USREOU code of the organizer
    1. The title of the auction lot
    1. The type of object [land/enterprise]
    1. Cadastral code (if land), USREOU code (if company) [text]
    1. Address [text]
    1. Field of activity of the company [agriculture/ industrial salt-producing industry/cattle breeding/ food and pharmaceutical industries. /Wine industry.] (complete list of Classifier of economic activities)
    1. Geolocation [GPS-coordinates]
    1. The opening price of [amount, UAH]
    1. The best price [amount, UAH] (initially equal to the opening price, is changing after taking bids)
    1. The minimum auction step (% of the lot opening price) [integer]
    1. The maximum auction step (% of the lot opening price) [integer]
    1. Date and time of the auction display [date, time (hours, minutes)]
    1. The date and time of the auction taking bids [date, time (hours, minutes)]
    1. The duration of the auction (trading) [hours, minutes]
    1. The size of the auction security (security) [amount, UAH]
    1. The conditions of return and non-return of provision [text] (required if provision size is greater 0)
    1. Information about the lawsuits and criminal proceedings [text]
    1. Debt [missing /payables/receivables]
    1. The outstanding amount [amount, UAH] (0 if absent).
    1. The description of the object of sale [text]
    1. Surname, first name and patronymic name, title and address of one or some officials of the auction organizer, authorized to public relations with participants [text];
    1. Technical Specification (link and file checksum available at the external resource through the link)
    1. Financial report if the enterprise (link and file checksum available at the external resource through the link)
    1. Other information about the object of sale link and file checksum available at the external resource through the link)
    1. The Publisher account ID (the account ID of the Platform if the Organizer works through the platform, or the Organizer's account ID, if it works independently)
    1. The Publisher USREOU code [text]

Auction rate data Here are the attributes and their type (in square brackets), which should be present on the auction bid:

    1. Participant's account ID
    1. Participant USREOU Code [text]
    1. The type of bid [bid /exit from the auction]
    1. Identifier of the connected lot
    1. The price of [the amount of UAH]
    1. Date and time of the display of the auction bid [date, time (hours, minutes)]
    1. The publisher account identifier (Account identifier of the Platform if the Participant works through the Platform, or the Account identifier Participant, if he works independently)
    1. USREOU code of the Publisher [text]

Economic model of the system functioning

When participating in the auction through the Platform, members will pay their participation directly to the Platform only by using cryptocurrency. In other cases - payment for participation (registration fee) will be made by the banks’ registrars at the account of the Platform selected by the Participant. The amount of payment for participation at the auction Platform will be determined independently depending on the quality of services and their market value. All Platforms may offer any additional services on a paid or FOC basis, aimed at:

  • involvement of the maximum number of Participants and Organizers for holding the auction;
  • improving quality of preparation and holding of the auction, service of the Participants and Organizers of the auction. These services include:
  • preparation of statistical reports (standard or by specific indicators);
  • maintaining the ratings of Participants and Organizers;
  • informing potential Participants about upcoming auctions;
  • input / data import about the terms of the auction, etc. The main services of the Platform will be the:
  • identification of the Organizers and Participants of the auction, if the Platform will serve as the publisher of the relevant data packages;
  • publication of lots and the auction bids;
  • publication of the result of the court decision on the auction, if acted as the publisher for the auction organizer.

Member’s motivation for the system development In the new system, the main motivating factor for the participants will be: Platform (Recorder):

  • funds received from the organizers and the participants for providing the access to the Application of the Organizer and the Application of the auction Participant;
  • competitive advantage with the presence of the electronic digital signature with enhanced certificate, allowing to provide services to the auction parties who do not have their own means of digital identification (becomes a legal responsibility center before the party of the auction, on behalf of which the auction data registration is carried out);
  • competitive advantage obtained by using high-speed, reliable communications channels and installing of software of Virtual machine of contracts. Organizer:
  • presence of several ready solutions on the market, provided by the platforms;
  • open standard to the system and the possibility of independent development of the necessary components. Participant, Observer:
  • presence of several ready solutions on the market, provided by the platforms;
  • open standard to the system and the possibility of independent development of the necessary components;
  • ready means of monitoring the basic functionality (transaction units) of the distributed database. Examples of the interface organization Visual display of the auction in the form of a directory Example of a visual display in the form of a catalogue, with the search functions in industry, activities, area, district (information on the current price and the time before the auction end should be added).

Visual display of the auctions in the form of map Examples of the form of the visual display in the form of the map, with the search function on the branch activity, region and district.

Visual display of the chosen auction on the map This should be added to the information about the current price and time before the auction end, as well as control to bid on the auction.

Example of detailed form of the auction lot Tab “Description”

Tab “Specification”

Support by the technology System Smart contracts & Blockchain Contracts From a technical point of view, the contract of the electronic auction should be a kind of e-mail address in an environment of decentralized electronic auction, which has its own executable code and is run with the help of this code. The activation of this code should be available for any participant who made external transaction with regard to the contract to the address of the contract. If the addressee posted the transaction will be another contract, then the contracts should be able to exchange a certain numbers of tokens, but if the contract still will be a final recipient then execution of the code of this contract should be activated. Auction’s electronic contract code should provide:

  • start of the auction trading on the date and time indicated by the Organizer of the auction;

  • end of auction trading on the date and time indicated by the Organizer of the auction;

  • registration of the related contract on the registration of the auction bid;

  • verification of compliance of the bid with the minimum value of the auction bid;

  • verification of compliance of the bid with the minimum and maximum value step growth rate of the auction bid;

  • definition of a candidate to the winner of the auction on the related contracts with the auction bids and contracts to exit the auction. The composition of the additional attributes (tags) of the auction electronic contract necessary for the implementation of these requirements are as follows:

  • <item_name> - the name of the auction lot

  • <item_description> - the description of the auction lot

  • <item_image> - a reference to the image of the auction lot

  • <item_image_hash> - picture hash of the auction lot

  • <item_doc> - a reference to the documentation of the auction lot

  • <item_doc_hash> - documentation hash of the auction lot

  • <auction_date> - date and time of the auction bidding start

  • <auction_expiration> date and time of the auction bidding

  • <min_sell> - minimum starting price

  • <bid_min_price> - minimum step of the auction price

  • <bid_max_price> - maximum step of the auction price

  • <buynow_price> - the current price of the auction lot

Transactions

  • Each transaction of the decentralized electronic auction contains a hash signed by previous transactions initiator in such a way that the previous transaction becomes the "entrance" for the current transaction. The public key or the address of the new recipient ("exit") is indicated

  • on open channels without encryption the transaction by broadcasting request is being sent to the e-auction network. Other units of decentralized electronic auction before receiving the transaction to processing are checking the signatures. The validity of the signature indicates that the initiator is really the owner of the private key to the "exit" address.

  • It is impossible to cancel a standard transaction, even with the apparent error or fraud. Transactions blocks

  • In order to avoid possible manipulations with transactions of decentralized electronic auction its individual transactions are combined with other transactions to a special structure - the block. Information in blocks is open, not encrypted, it can be quickly double checked.

  • Each unit always contains its serial number and a hash of the previous block. All units can be built in one chain containing information about all previously made operations with transactions.

  • In existing systems of distributed data bases you can find out more on specialized sites - browser block chains.

  • As a rule, the first transaction in a block is always generated automatically and transfers the remuneration for the creation of the block. Other block content is taken from the transactions queue which have not yet been written to the previous blocks.

  • Not every formed block will be accepted by the other members. It is required that the numerical value of title hash does not exceed the specified value (the setting "complexity"). The smaller the set, the less likely the possibility of condition execution. There is a place for arbitrary values in a service area. If the title hash is unsatisfactory, arbitrary values ​​are replaced with new arbitrary or random values, and hash calculation is repeated. The result of the hashing (SHA-256 function) is unpredictable, so there's no algorithm for purposeful change of arbitrary area to achieve the desired result. Typically, a large number of recalculations is required. In existing systems the parameter "complexity" is set automatically so as to maintain a constant average speed of blocks creating (but in different systems, the values ​​vary in different ways, so for Bitcoin an average speed of creation is 1 block per 10 minutes and for Ethereum - 1 block per 15 seconds). If the blocks are formed faster, so after the recalculation of "complexity" it becomes more difficult to achieve goal, and vice versa. That’s why the change of the total network computing capacity modifies the number of produced units very slightly.

  • When the appropriate variant for hash is found, the unit sends the received block to other connected units for check. If there are no errors, then each network unit that received the block writes it to his database instance.

Transactions confirmation

  • As long as the transaction is not included in the block, the system considers that the data stored by the transaction remains unchanged. At this time, it is technically possible to change the data and draw some other transactions. But as soon as one of these transactions will be included in the block, the system will ignore other transactions with the same data. For example, if the later transaction will be included in the block, then the earlier one will be considered as erroneous.
  • There is a small chance that at branching two similar transactions get into blocks of different branches. Each of them will be considered correct only if the dieback of branches one of the transaction will be considered erroneous. At the same time there will be no matter the time of the transaction.
  • Thus, entering transaction into the block confirms its authenticity regardless of whether other transactions with the same data.
  • Each new block is considered to be an additional "proof" of transactions from the previous blocks. If there are 3 blocks in the chain, the transaction from the last block will be confirmed one time and the ones placed to the first block will have 3 confirmations. It is enough to wait a few acknowledgments to reduce the likelihood of canceling the transaction to a minimum.
  • To decrease influence of such situations on the network there are boundary conditions to the modifications of the transactions data included to the last blocks at the current distribution data bases. According to the service blockchain.info, until May 2015 5 blocks was the maximum length of the rejected chain.

Example of the contents of XML structure of the electronic contract Example of the contents of XML structure of e-auction of created by the Organizer’s Application

<nym_id> ODESSA-NYM-ID-HASH </nym_id>

<node_addr> ODESSA GOROD </node_addr>

<btc_addr> 03d728ad6757d4784effea04d47baafa216cf474866c2d4dc99b1e8e3eb936e730 </btc_addr>

<item_name> State Land </item_name> <item_description>Trading house of 2,000 square meters</item_description> <item_image> https://img0.etsystatic.com/000/0/6342324/il_570xN.326696084.jpg </item_image> <min_sell> 1,000,000$ </min_sell> <bid_price> </bid_price> <buynow_price> 5,000,0000$ </buynow_price> <auction_expiration> 2014-06-25 21:00 UTC </auction_expiration>

<PGP_Public_Key>

  • -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Mailvelope v0.8.2 Comment: Email security by Mailvelope - http://www.mailvelope.com

xsFNBFODLW8BD/9rmoBRBASaZuNpPBG+Gj7/aJcE7aQ4Sti7lKaERFD7/rHd WHm+o+FnyQvxpkOuuU6G4q739tP5ZqHx/bn9rhpAKKa+o7es70jlpenHyge4 0QyIU1/9jXzwlMsXkq9XfbOhqtgiBRpeZ83/ZjUsf5/wQXhrGWvG4rnKj5kh YNq8PHzqJO21cDcD7LJy6yPuOgrBfb4MMa3+9lauIZ5Ye2kXR4m1OuWrig0M 7SwgFZwo3GbmcWe5KCK60nHW0AZh47B/yC18s/uR3t2bGrkQwL6AgTiOd2hX /K2l1ccgIPnWo1s/5fMc7HiGpPkioOYhWgDm+2bimh56D2Tq7ikZQSDZIhw4 ……………………………...= =dDLn

  • -----END PGP PUBLIC KEY BLOCK----- </PGP_Public_Key> -----BEGIN PGP SIGNATURE----- Version: BCPG v1.47

iQKBBAEBAgBrBQJTixgpZBxEciBXYXNoaW5ndG9uIFlhbWFuZHUgU2FuY2hleiAo

=O2ib -----END PGP SIGNATURE-----

Contract hash: 8f9cfa1255e4f4c1a5cc1d21c7dd7ce233aa0c9b – unique identifier of the e-contract returnable by distributed virtual machine to the Organizer’s application.

Example of XML-structure for e-contract of the auction created by the Participant’s Application

<nym_id> Kiev Oligarch </nym_id>

<node_addr> Kiev </node_addr>

<auction_contract> 8f9cfa1255e4f4c1a5cc1d21c7dd7ce233aa0c9b </auction_contract> <bid_price> 1,200,000$ </bid_price>

<PGP_Public_Key> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: BCPG v1.47

mQINBFODLW8BD/9rmoBRBASaZuNpPBG+Gj7/aJcE7aQ4Sti7lKaERFD7/rHdWHm+ o+FnyQvxpkOuuU6G4q739tP5ZqHx/bn9rhpAKKa+o7es70jlpenHyge40QyIU1/9

=nT6N -----END PGP PUBLIC KEY BLOCK----- </PGP_Public_Key> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)

iQIcBAABAgAGBQJTixr6AAoJEKnOFXGYSKNNKBcP/j9NtM5KK8/YvXfONAxBEkuB H8kM2h2WfnBh1JwiDdVEeVdU7vY7CQ SOL9iJiOUm4fkbPO141oovynn/4AZ1ORTR2Pw/godX5SsplWnuF16px7BXuDiomu 7PbH/QRFV4c5aSOZpwjb =oB4I -----END PGP SIGNATURE-----

Contract hash: 57074779f93235c88a07b7c6de8285c8478cc6a6 - unique identifier of the e-contract returnable by distributed virtual machine to the Organizer’s application

Documentation on the topic – 5-th chapter: https://ethereum.gitbooks.io/frontier-guide/content/contracts_and_transactions_intro.html

Clone this wiki locally
You can’t perform that action at this time.