Topic: [ANN] SMLY- smileycoin - for rewards in education - page 6. (Read 77351 times)
hello: when i put my wallet to mining in (https://icopool.club/) it appears that i am mining bdc and not smly; how do i mine this coin without errors ??
pools??
Since we split the coinbase and changed to 5 algos SMLY has been (mostly) solo mined from inside the wallets.
pools??
As a part of this listing process we have been preparing for official announcements and making sure that public information is correct.
The CMC page is much improved.
The CMC page is much improved.
We are in the process of listing with p2pb2b.io
They have impressive numbers in terms of volume. It will be our task to raise awareness and interest in SmileyCoin.
Check out the "coming soon" section: https://p2pb2b.io/
They have impressive numbers in terms of volume. It will be our task to raise awareness and interest in SmileyCoin.
Check out the "coming soon" section: https://p2pb2b.io/
We are in the process of listing with p2pb2b.io
They have impressive numbers in terms of volume. It will be our task to raise awareness and interest in SmileyCoin.
Check out the "coming soon" section: https://p2pb2b.io/
They have impressive numbers in terms of volume. It will be our task to raise awareness and interest in SmileyCoin.
Check out the "coming soon" section: https://p2pb2b.io/
News flash:
You know about the 10 income streams/donations to charity, right? Since 2017, every block generated sends 4500 SMLY to an address handled by the Smiley Charity which runs the Education in a Suitcase project.
The first two uses of these streams have been decided: split one stream up and send to the African Maths Initiative and UNICEF.
The first transmission went to AMI yesterday.
You know about the 10 income streams/donations to charity, right? Since 2017, every block generated sends 4500 SMLY to an address handled by the Smiley Charity which runs the Education in a Suitcase project.
The first two uses of these streams have been decided: split one stream up and send to the African Maths Initiative and UNICEF.
The first transmission went to AMI yesterday.
As everyone here knows, SmileyCoin has been used quite a bit for charity and education.
The Smiley Charity and Education in a Suitcase receive SMLY from every generated block, in the form of 10 income streams. We've talked about how to use it: The African Maths Initiative and UNICEF will receive some of it in sub-streams to be set up and automated.
We've also talked about possibly using one stream for Universal Basic Income. This could be really neat, but the problem is that you can't just print money for UBI -- it needs to be a part of a circular economy, something like UBI->purchase->tax->UBI, whatever "tax" means.
The SmileyCoin Fund receives applications for grants in SMLY. One grant has already been accepted: Refilling the tutor-web wallet for rewarding students for their studies.
It is time to consider the next step: Should we try to use (some of) the Transaction Fee to test a UBI economy, possibly supported by one of the 10 income streams?
Proposed implementation: Take a version of the wallet and modify it so that the TxFee is split up and sent to a bunch of UBI recipient addresses. Do this in a few iterations, starting with just a handful of addresses, then move on and have the addresses coded as UBI-addresses into the blockchain. Eventually figure out a registration mechanism.
This is neither a fork nor is it mandatory: It is just a subgroup of people who mine and send the TxFee out as a UBI. But this subgroup will probably insist on fees of at least 1 SMLY per Kb in their blocks and movements using UBI addresses
Comments are welcome as always.
The Smiley Charity and Education in a Suitcase receive SMLY from every generated block, in the form of 10 income streams. We've talked about how to use it: The African Maths Initiative and UNICEF will receive some of it in sub-streams to be set up and automated.
We've also talked about possibly using one stream for Universal Basic Income. This could be really neat, but the problem is that you can't just print money for UBI -- it needs to be a part of a circular economy, something like UBI->purchase->tax->UBI, whatever "tax" means.
The SmileyCoin Fund receives applications for grants in SMLY. One grant has already been accepted: Refilling the tutor-web wallet for rewarding students for their studies.
It is time to consider the next step: Should we try to use (some of) the Transaction Fee to test a UBI economy, possibly supported by one of the 10 income streams?
Proposed implementation: Take a version of the wallet and modify it so that the TxFee is split up and sent to a bunch of UBI recipient addresses. Do this in a few iterations, starting with just a handful of addresses, then move on and have the addresses coded as UBI-addresses into the blockchain. Eventually figure out a registration mechanism.
This is neither a fork nor is it mandatory: It is just a subgroup of people who mine and send the TxFee out as a UBI. But this subgroup will probably insist on fees of at least 1 SMLY per Kb in their blocks and movements using UBI addresses
Comments are welcome as always.
southXchange and NovaExchange have upgraded their wallets.
Again: one can not recommend messing around with over 90M SMLY in one UTXO -- but if you have to, then you also HAVE TO UPGRADE your wallet!
Again: one can not recommend messing around with over 90M SMLY in one UTXO -- but if you have to, then you also HAVE TO UPGRADE your wallet!
A wallet upgrade, to v2.2.4, is now available on github.
We would appreciate hearing if you have any problems with the new version. It contains a bug fix to what could potentially happen when handling very large amounts (over 92 million SMLY) in individual transmissions (single UTXOs).
Of course one can not recommend using such large amounts -- this is uncomfortably close to numerical overflow, the way the coins are coded in crypto wallets. It is much safer to stick to lower amounts. For example, if you look at the SmileyCoin Fund you will see that the initial transmissions to the fund were 75 M SMLY each, but there were a fairly large number of those.
But if you NEED to handle such large amounts, then you absolutely need to upgrade.
We would appreciate hearing if you have any problems with the new version. It contains a bug fix to what could potentially happen when handling very large amounts (over 92 million SMLY) in individual transmissions (single UTXOs).
Of course one can not recommend using such large amounts -- this is uncomfortably close to numerical overflow, the way the coins are coded in crypto wallets. It is much safer to stick to lower amounts. For example, if you look at the SmileyCoin Fund you will see that the initial transmissions to the fund were 75 M SMLY each, but there were a fairly large number of those.
But if you NEED to handle such large amounts, then you absolutely need to upgrade.
They are in the process of upgrading their wallet (see above).
on the stock exchange www.southxchange.com not working SMLY wallet 
A wallet upgrade, to v2.2.4, is now available on github.
We would appreciate hearing if you have any problems with the new version. It contains a bug fix to what could potentially happen when handling very large amounts (over 92 million SMLY) in individual transmissions (single UTXOs).
Of course one can not recommend using such large amounts -- this is uncomfortably close to numerical overflow, the way the coins are coded in crypto wallets. It is much safer to stick to lower amounts. For example, if you look at the SmileyCoin Fund you will see that the initial transmissions to the fund were 75 M SMLY each, but there were a fairly large number of those.
But if you NEED to handle such large amounts, then you absolutely need to upgrade.
We would appreciate hearing if you have any problems with the new version. It contains a bug fix to what could potentially happen when handling very large amounts (over 92 million SMLY) in individual transmissions (single UTXOs).
Of course one can not recommend using such large amounts -- this is uncomfortably close to numerical overflow, the way the coins are coded in crypto wallets. It is much safer to stick to lower amounts. For example, if you look at the SmileyCoin Fund you will see that the initial transmissions to the fund were 75 M SMLY each, but there were a fairly large number of those.
But if you NEED to handle such large amounts, then you absolutely need to upgrade.
Dev, please contact novaexchange at [email protected]
This is proving very difficult to compile in this Ubuntu 18 VM :/
Code:
make[5]: Entering directory '/home/******/****/smileyCoin/src/qt'
CXX libbitcoinqt_a-bitcoin.o
In file included from bitcoin.cpp:223:0:
bitcoin.moc:13:2: error: #error "This file was generated using the moc from 5.9.5. It"
#error "This file was generated using the moc from 5.9.5. It"
^~~~~
bitcoin.moc:14:2: error: #error "cannot be used with the include files from this version of Qt."
#error "cannot be used with the include files from this version of Qt."
^~~~~
bitcoin.moc:15:2: error: #error "(The moc has changed too much.)"
#error "(The moc has changed too much.)"
^~~~~
bitcoin.moc:19:1: error: ‘QT_WARNING_PUSH’ does not name a type; did you mean ‘QT_NO_WARNINGS’?
QT_WARNING_PUSH
^~~~~~~~~~~~~~~
QT_NO_WARNINGS
bitcoin.moc:30:14: error: ‘qt_meta_stringdata_BitcoinCore_t’ does not name a type
static const qt_meta_stringdata_BitcoinCore_t qt_meta_stringdata_BitcoinCore = {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bitcoin.moc: In static member function ‘static void BitcoinCore::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’:
bitcoin.moc:96:35: error: ‘IndexOfMethod’ is not a member of ‘QMetaObject’
} else if (_c == QMetaObject::IndexOfMethod) {
^~~~~~~~~~~~~
bitcoin.moc: At global scope:
bitcoin.moc:123:35: error: ‘qt_meta_stringdata_BitcoinCore’ was not declared in this scope
{ &QObject::staticMetaObject, qt_meta_stringdata_BitcoinCore.data,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bitcoin.moc:123:35: note: suggested alternative: ‘qt_meta_data_BitcoinCore’
Are you trying to build the frontend? It compiled just fine for me without the frontend on Ubuntu 18.
However, the error seems to be some kind of a Qt4/5 conflict
This is proving very difficult to compile in this Ubuntu 18 VM :/
Code:
make[5]: Entering directory '/home/******/****/smileyCoin/src/qt'
CXX libbitcoinqt_a-bitcoin.o
In file included from bitcoin.cpp:223:0:
bitcoin.moc:13:2: error: #error "This file was generated using the moc from 5.9.5. It"
#error "This file was generated using the moc from 5.9.5. It"
^~~~~
bitcoin.moc:14:2: error: #error "cannot be used with the include files from this version of Qt."
#error "cannot be used with the include files from this version of Qt."
^~~~~
bitcoin.moc:15:2: error: #error "(The moc has changed too much.)"
#error "(The moc has changed too much.)"
^~~~~
bitcoin.moc:19:1: error: ‘QT_WARNING_PUSH’ does not name a type; did you mean ‘QT_NO_WARNINGS’?
QT_WARNING_PUSH
^~~~~~~~~~~~~~~
QT_NO_WARNINGS
bitcoin.moc:30:14: error: ‘qt_meta_stringdata_BitcoinCore_t’ does not name a type
static const qt_meta_stringdata_BitcoinCore_t qt_meta_stringdata_BitcoinCore = {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bitcoin.moc: In static member function ‘static void BitcoinCore::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’:
bitcoin.moc:96:35: error: ‘IndexOfMethod’ is not a member of ‘QMetaObject’
} else if (_c == QMetaObject::IndexOfMethod) {
^~~~~~~~~~~~~
bitcoin.moc: At global scope:
bitcoin.moc:123:35: error: ‘qt_meta_stringdata_BitcoinCore’ was not declared in this scope
{ &QObject::staticMetaObject, qt_meta_stringdata_BitcoinCore.data,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bitcoin.moc:123:35: note: suggested alternative: ‘qt_meta_data_BitcoinCore’
Where does it say to use BDB 4.8? I think you gave the wrong link.
I'm pretty sure the Windows wallet is using BDB 5
I'm pretty sure the Windows wallet is using BDB 5
Oops, sorry. Here is where it says to use 4.8: https://github.com/tutor-web/smileyCoin/blob/master/doc/build-unix.md
You can just ignore it and use BDB 5. The windows and Mac wallets are using BDB 5, and you should be fine using it. You can always open an old wallet.dat file using a software using new BDB, but not the other way around.
But back up the wallet.dat file just in case something goes wrong!
Where does it say to use BDB 4.8? I think you gave the wrong link.
I'm pretty sure the Windows wallet is using BDB 5
I'm pretty sure the Windows wallet is using BDB 5
Oops, sorry. Here is where it says to use 4.8: https://github.com/tutor-web/smileyCoin/blob/master/doc/build-unix.md
Compiling on Ubuntu 18 LTS.
This file: https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
says to use BDB 4.8,
but when I look here:
https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
I see a lot of stuff about BDB 5.
What to do?
Which is the Windows wallet compiled using?
This file: https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
says to use BDB 4.8,
but when I look here:
https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
I see a lot of stuff about BDB 5.
What to do?
Which is the Windows wallet compiled using?
Where does it say to use BDB 4.8? I think you gave the wrong link.
I'm pretty sure the Windows wallet is using BDB 5
Compiling on Ubuntu 18 LTS.
This file: https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
says to use BDB 4.8,
but when I look here:
https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
I see a lot of stuff about BDB 5.
What to do?
Which is the Windows wallet compiled using?
This file: https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
says to use BDB 4.8,
but when I look here:
https://github.com/tutor-web/smileyCoin/blob/master/configure.ac
I see a lot of stuff about BDB 5.
What to do?
Which is the Windows wallet compiled using?
This may be a good time for a pat on the back:
We are past the fork!
Most users upgraded in time.
Only the main chain is active.
We seem to have resolved the swings in difficulty.
The mods seem to do exactly what was intended.
Many thanks to everyone who participated!
We are past the fork!
Most users upgraded in time.
Only the main chain is active.
We seem to have resolved the swings in difficulty.
The mods seem to do exactly what was intended.
Many thanks to everyone who participated!
Jump to: