-
GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
BEAM adds a minimum and maximum threshold for timelocks. -
BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
By including a fee refund model with these transactions. -
In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?
BEAM allows asynchronous transactions by its implementation of the Secure Bulletin Board System that runs on full nodes. -
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.
-
Beam implemented a system whereby a certain number of blocks can be specified after which a transaction cannot be spent.
-
Users will get a fee refund if they re-use kernels.
-
A Secure Bulletin Board System will be run on BEAM full nodes to allow for asynchronous transactions.
-
Payees can initiate transactions using kernel fusion.
-
GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
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?
Including a fee refund model for this type of transactions. -
In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?
Implementing 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?
The payee can construct their half of the transaction and send this half-contructed transaction to the payer, that finish contructing the transaction and publish it to the blockchain; this process is called the 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.
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 - 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?
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.
3 - 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
4 - 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. 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- If a transaction doesn’t appear in a block in a certain amount of time, it never will.
- The usage of the fee refund model
- via SBBS
- " 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"
-
Beam introduced setting an incubation period on UTXO’s. This limits the ability of it to be spent until a fixed number of blocks after its creation.
-
To encourage users to recycle transaction kernels BEAM has introduced a fee refund model for these types of transactions.
-
BEAM allows for parties to be online at different times by introducing Secure Bulletin Board System(SBBS). This is run on BEAM full nodes.
-
BEAM plans to support one-sided transactions by using Kernel Fusion. A kernel refers to another kernel and as such both kernels must be present in the transaction before the transaction can be valid.
#1 - GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
There is the option to specify an upper time limit
#2 - BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
The feature is incentiviced with a fee refund model
#3 - 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 Board System (SBBS) is run on BEAM full-nodes to achieve asynchronous communication
#4 - How does BEAM plan to support one-sided transactions?
They developed a process called kernel fusion, so a reciver is able to construct one half of a transaction without revealing his blinding factors
-
Beam enhanced normal timelocks in the way that someone could specify an upper time limit after which the transaction can no longer be included in a block
-
They use a financial incentive in order to encourage user to use the feature. BEAM implemented a fee refund model when such transaction are made
-
BEAM has a Secure Bulletin Board System which runs on BEAM full-nodes. This enables asynchronous negotiation of transactions
-
With the use of “kernel fusion”. This means a kernel contains a reference to another kernel and the transaction is only valid when both kernels are present in the transaction.
- GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
- 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?
- BEAM 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?
- 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?
With a process it 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. 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.
2. BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
It has a fee refund incentive.
3. 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 Board System (SBBS) is run on BEAM full-nodes to achieve asynchronous communication.
4. How does BEAM plan to support one-sided transactions?
Through 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.
-
GRIN uses a timelock. What additional functionality does BEAM add to this timelock?
A feature to add an extra time. After this extra time a transaction can’t be included in a block anymore. -
BEAM proposes to improve scalability by letting users recycle transaction kernels. How will they encourage users to use this feature?
By offering a refund model. -
In a GRIN transaction, both parties must be online at the same time. How does BEAM allow this to be done asynchronously?
By the impelementattion of a seperate sort of Bulletin Board System where users can add there transaction for the time when one of the parties is oflline -
How does BEAM plan to support one-sided transactions?
By using a so name kernal fusion, which includes a reference in the kernal to another transaction.
• Upper time limit, meaning if a TX is not included in the blockchain within the given period, it would not be possible to do so anymore.
• By providing a fee refund model to incentive people to build this type of Tx.
• By implementing a Secure Bulletin Boar System which runs on Beams full nodes.
• By allowing the payee to start building a Tx and then sending it to the payer to finish it up and broadcast it to the ledger. This is not possible in the regular Mimblewimble protocol without revealing the blinding factor, Beam solves this problem by using a process called Kernell Fusion.
-
The functionality which BEAM added to “timelock” was the setting of an explicit incubation period on a UTXO which limited that UTXO’s ability to be spent to a specific number of blocks after its creation - after this the transaction can no longer be included in a block.
-
BEAM will encourage people to recycle transaction kernels by introducing a “fee-refund” to those who do.
-
BEAM allows transactions to be done asynchronously by implementing a “Secure Bulletin Board System” (SBBS) which is run on the BEAM full nodes.
-
BEAM plans to support one-sided transactions by using 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.
- BEAM includes the ability to also specify an upper time limit, after which the transaction can no longer be included in a block.
- BEAM encourages its use by using a fee refund model.
- BEAM has implemented a Secure Bulletin Board System (SBBS) to ensure asynchronous transaction negotiation.
- BEAM supports this type of transaction thanks to the kernel fusion. Kernel fusion allows a kernel to include a reference to another kernel, so that it is valid only if both kernels are present in the transaction.
-
The functionality which BEAM added to “timelock” was the setting of an explicit incubation period on a UTXO which limited that UTXO’s ability to be spent to a specific number of blocks after its creation. After this the transaction can no longer be included in a block. The coins will no longer be spent under this UTXO.
-
BEAM will encourage people to recycle transaction kernels by introducing a “fee-refund” to those who do.
-
BEAM allows transactions to be done asynchronously (not synchronized) by implementing a “Secure Bulletin Board System” (SBBS) which is run on the BEAM full nodes.
-
BEAM plans to support one-sided transactions by using 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.
This is an amazing reference on all things blockchain privacy.
- BEAM supports setting an explicit incubation period on an UTXO, which limits its ability to be spent to a specific number of blocks after its creation.
- Fees are refunded.
- 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 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.
- 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.
- By allowing the payee to construct his half of the transaction and send it to the payer where they can finish constructing the transaction before publishing it to the blockchain.
1: Specifying an upper. time limit after which the TRx can no longer be included in a block
2:A fee refund will be awarded to users
3: A SBBS will be used on BEAM’s full node to enable asynchronous TRx negotiations
4:By including a process adding a reference kernel to another kernel that make TRx valid only if both kernels are included a system called Kernel fusion
-
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.
-
BEAM includes a fee refund model for these types of transactions.
-
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.