Beam Unique Features - Reading Assignment

Privacy Coins - Ultimate Course
#41
  1. Beam includes an upper time limit after which a transaction will not be added to a block. so this means that if a transaction doesnt turn up by time x in a block it will never be there

2 BEAM has proposed a scheme to reuse these transaction kernels to validate subsequent transactions . In order to consume the existing kernels without compromising the transaction irreversibility principle, BEAM proposes that a multiplier be applied to an old kernel by the same user who has visibility of the old kernel, and that this be used in a new transaction. In order to incentivize transactions to be built in this way, BEAM includes a fee refund model for these types of transactions.

3.BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions

4.BEAM also plans to support one-sided transactions where the payee in a transaction who expects to be paid a certain amount can construct their half of the transaction and send this half-constructed transaction to the payer. The payer can then finish constructing the transaction and publish it to the blockchain.

#42

  1. GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
    BEAM also supports the traditional timelock feature, but includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block

  2. BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
    BEAM proposes that a multiplier be applied to an old kernel by the same user who has visibility of the old kernel, and that this be used in a new transaction. In order to incentivize transactions to be built in this way, BEAM includes a fee refund model for these types of transactions

  3. In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?

BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions

  1. How does BEAM plan to support one-sided transactions?
    BEAM also plans to support one-sided transactions where the payee in a transaction who expects to be paid a certain amount can construct their half of the transaction and send this half-constructed transaction to the payer. The payer can then finish constructing the transaction and publish it to the blockchain
#43
  1. GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
  • BEAM also supports the traditional timelock feature, but includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block. This feature means that a party can be sure that if a transaction is not included in a block on the main blockchain after a certain time, it will never appear.
  1. BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
  • A fee refund incentive model.
  1. In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?
  • A Secure Bulletin Boar System which runs on Beams full nodes.
  1. How does BEAM plan to support one-sided transactions?
  • “kernel fusion” where a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction.
#44

GRIN uses a timelock. What additional functionality does BEAM add to this timelock?

" EAM supports setting an explicit incubation period on a UTXO, which limits its ability to be spent to a specific number of blocks after its creation [13]. This is different to a timelock, which prevents a transaction from being added to a block before a certain time. BEAM also supports the traditional timelock feature, but includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block [13]. This feature means that a party can be sure that if a transaction is not included in a block on the main blockchain after a certain time, it will never appear."

BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?

“In order to incentivize transactions to be built in this way, BEAM includes a fee refund model for these types of transactions. This feature will not be part of the initial release.”

In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?

Grin Uses a SBBS/ Secure Bulletin Board System to help solve this issue, it lets one user make a transaction and post it to the bulletin board so the receiver can pick up and finish their transaction with the seam ease as bitcoin or other similar cryptocurrencies.

How does BEAM plan to support one-sided transactions?

" BEAM also plans to support one-sided transactions where the payee in a transaction who expects to be paid a certain amount can construct their half of the transaction and send this half-constructed transaction to the payer. The payer can then finish constructing the transaction and publish it to the blockchain. Under the normal Mimblewimble system this is not possible, because it would involve revealing your blinding factor to the counterparty. BEAM solves this problem by using a process it calls kernel fusion , whereby a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction. In this way, the payee can build their half of the transaction with a secret blinding factor and a kernel that compensates for their blinding factor, which must be included when the payer completes the transaction [13]. "

#45

  1. GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
    BEAM supports setting an explicit incubation period on a UTXO, which limits its ability to be spent to a specific number of blocks after its creation [13]. This is different to a timelock, which prevents a transaction from being added to a block before a certain time. BEAM also supports the traditional timelock feature, but includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block [13]. This feature means that a party can be sure that if a transaction is not included in a block on the main blockchain after a certain time, it will never appear.

  2. BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?

In Mimblewimble, as transactions are added, cut-through is performed, which eliminates all intermediary transaction commitments [3]. However, the transaction kernels for every transaction are never removed. BEAM has proposed a scheme to reuse these transaction kernels to validate subsequent transactions [13]. In order to consume the existing kernels without compromising the transaction irreversibility principle, BEAM proposes that a multiplier be applied to an old kernel by the same user who has visibility of the old kernel, and that this be used in a new transaction. In order to incentivize transactions to be built in this way, BEAM includes a fee refund model for these types of transactions.

  1. In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?

BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions

  1. How does BEAM plan to support one-sided transactions?

BEAM also plans to support one-sided transactions where the payee in a transaction who expects to be paid a certain amount can construct their half of the transaction and send this half-constructed transaction to the payer. The payer can then finish constructing the transaction and publish it to the blockchain. Under the normal Mimblewimble system this is not possible, because it would involve revealing your blinding factor to the counterparty. BEAM solves this problem by using a process it calls kernel fusion , whereby a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction. In this way, the payee can build their half of the transaction with a secret blinding factor and a kernel that compensates for their blinding factor, which must be included when the payer completes the transaction

#46

Beam adds additional functionality to timelock with an upper time limit added to the transaction, after that time limit the transaction can no longer be added to the block
2:Users are encouraged to use recycled transaction kernels by including a fee refund model for the types of transactions made.
3:Beam allows both parties to be online asynchronously by having a Secure Bulletin Board System SBBS run on the Beam Full nodes allowing this asynchronous negotiation of transactions aspect.
4: Beam will support one-sided transactions by using Kernel Fusion to use as a reference to another so as to make the transaction valid …but only if both parties are there .

#47
  1. It includes an upper time limit after which the transaction can no longer be included in a block.
  2. By refunding the fee for these types of transactions.
  3. By using a Secure Bulletin Board System that runs on full nodes.
  4. By using kernel fusion, where a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction.
2 Likes
#48
  • GRIN uses a timelock. What additional functionality does BEAM add to this timelock? Beam supports the traditional time lock feature of Grin and adds the ability to specify and upper time limit, which if exceeded, will not appear on the block at all.
  • BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature? By using a fee refund model which encourages a sender to recycle an old kernel used in a previous tx, by a user who has visibility of the old kernel, and without compromising the “transaction irreversibility principle” in which BEAM uses a multiplier applied to the old kernel.
  • In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously? Grin allows the two collaborating users to connect directly through a socket based channel for real time simultaneous communication session. BEAM has further implemented a secure a Secure Bulletin Board System (SBBS), run on BEAM full nodes to allow asynchronous negotiation of transactions.
  • How does BEAM plan to support one-sided transactions? “BEAM solves this problem by using a process it calls kernel fusion , whereby a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction. In this way, the payee can build their half of the transaction with a secret blinding factor and a kernel that compensates for their blinding factor, which must be included when the payer completes the transaction.”
1 Like
#49 
GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?
How does BEAM plan to support one-sided transactions?

1 Beam supports the traditional timelock feature but includes the ability to also specify an upper time limit after which the transaction can no longer be included in a block.

2 Beam incentivises this with a fee refund model for this transaction type

3 Beam has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions.

4 Kernel fusion process: whereby a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction. In this way, the payee can build their half of the transaction with a secret blinding factor and a kernel that compensates for their blinding factor, which must be included when the payer completes the transaction.

1 Like
#50

GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
BEAM includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block

BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
By offering a fee refund for those who use it

In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?
BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions

How does BEAM plan to support one-sided transactions?
By using a process it calls kernel fusion, whereby a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction

1 Like
#51

• GRIN uses a timelock. What additional functionality does BEAM add to this timelock? The ability to also specify an upper time limit, after which the transaction can no longer be included in a block. This feature means that a party can be sure that if a transaction is not included in a block on the main blockchain after a certain time, it will never appear.
• BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature? BEAM incentivize transactions to be built in which includes a fee refund model for these types of transactions.
• In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously? Grin facilitates this process by the two parties connecting directly to one another using a socket-based channel for a “real-time” session. This means that both parties need to be online simultaneously. BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions.
• How does BEAM plan to support one-sided transactions? BEAM supports one-sided transactions where the payee in a transaction who expects to be paid a certain amount can construct their half of the transaction and send this half-constructed transaction to the payer. The payer can then finish constructing the transaction and publish it to the blockchain.

1 Like
#52
  1. GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
  • Instead of determining after what period transaction can be included in a block, Beam defines when it can be spent.
  • It also has the timelock like GRIN, but they added an upper time limit which the sender can specify. When that passes, the sender can be sure that if the transaction is not included yet, it will never be included (and choose other means of payment without the risk of paying double).
  1. BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
  • Through fee refunds.
  • I was thinking, why couldn’t such transactions just be cheaper? Do they still require the same computation power? If so, then where is the refund coming from?
  1. In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?
  • Full nodes run a Secure Bulletin Board System (SBBS).
  1. How does BEAM plan to support one-sided transactions?
  • Bob (receiver) constructs his side of the transaction and sends to Alice (sender). When she goes online, she constructs her side and publishes on the blockchain.
  • In normal MimbleWimble, this would mean that Alice can spend Bob’s UTXO after she has sent it to him.
  • This is solved by kernel fusion. A kernel includes a reference to another kernel, which also needs to be present in the transaction. Basically, Bob creates a blinding factor to his blinding factor.
1 Like
#53

I’m not so sure, but I think this is because it generally makes the tx cheaper as you get the fee from the reuse refunded.

2 Likes
#54

1.They included the ability to also specify an upper time limit, after which the transaction can no longer be included in a block
2. BEAM will include a fee refund model for these types of transactions
3. BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions
4. BEAM plans to use a process called kernel fusion , whereby a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction

1 Like
#55

Beam expounds upon the timelock created by Grin, by allowing the sender to specify an upper time limit to when a transaction may be appended into a block. In order to promote scalability, Beam seeks to encourage users to recycle used transaction kernels by implementing a fee refund model. Transaction kernels are stored on the blockchain similarly to the accumulator model. The more efficiently these are used, the lass data bloat to the blockchain.
Beam circumvents the need for both parties involved in a transaction to be online at the same time. While Grin uses a secure socket layer to communicate the secret information, Beam instead has implemented a secure bulletin board model to facilitate the transfer of this necessary information.
One sided transactions can now be implemented on Beam by allowing the payee to create a sort of Digital Bill by creating its half of the transaction, and the payer can complete the transaction by completing his/her/its half and then publishing it to the blockchain.

1 Like
#56
  • BEAM includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block.
  • BEAM includes a fee refund model for these types of transactions. This feature will not be part of the initial release.
  • BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions.
  • The payee in a transaction who expects to be paid a certain amount can construct their half of the transaction and send this half-constructed transaction to the payer. The payer can then finish constructing the transaction and publish it to the blockchain.
1 Like
#58

includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block [13]. This feature means that a party can be sure that if a transaction is not included in a block on the main blockchain after a certain time, it will never appear.

BEAM includes a fee refund model for these types of transactions. This feature will not be part of the initial release.

BEAM has implemented a Secure Bulletin Board System (SBBS) that is run on BEAM full-nodes to allow for asynchronous negotiation of transactions

BEAM solves this problem by using a process it calls kernel fusion , whereby a kernel can include a reference to another kernel so that it is only valid if both kernels are present in the transaction. In this way, the payee can build their half of the transaction with a secret blinding factor and a kernel that compensates for their blinding factor, which must be included when the payer completes the transaction [13].

1 Like
#59

  1. A timelock in the cryto space means that a transaction cannot added to a block before a certain amount if time has passed. Beam uses the timelock, but extends this feature by adding an upper time limit during which a transaction must be included in a block. If the upper time limit is breached and the transaction has not been included in a block, then it never will. Does this mean that it will be considered a “failed transaction”?

  2. With rewards - a fee refund model

  3. By implementing a bulleting board called the Secure Bulleting Board System. This means that person A can post their needed part of the transaction to the board, wait for person B to collect the message at their earliest convenience, remodel it and post an answer back to the board, where person A will then do their duty at their earliest convenience, and so forth and so forth, until the transaction is ready to be broadcast. Did I understand this correctly?

  4. By using something called kernel fusion - a kernel referencing another kernel is included in the one-sided transaction and both kernels must be present for the transaction to be valid. The payee sends a kernel substituting their blinding factor in their side, but how this kernel references the other kernel, or even which ernel the other kernel is, I don’t know. Help?

On a random note, can someone please explain to me what “randomized flooding” is. Much appreciated.

1 Like
#60

Since the tx doesn’t even go on the blockchain it basically just gets dropped.

Its the kernel from other pending transactions :slight_smile:

Not sure, where did you get that? Transactions are spread through the network by flooding, but I don’t think its randomized like Dandelion+.

#61

Cool, thanks again. The randomized flooding was something I was just wondering about. It had nothing to do with this particular topic.